Subject: [saag] Considerations and Clarifications about draft-nir-saag-star-01

From: "Dr. Pala" <[email-masked]>
Date: Wed, 21 Mar 2018 13:08:07 +0000

Hi all,

unfortunately I missed the sec-dispatch session, but I have some
important considerations about the document. In general, short-lived
certificates have been around for many years and for many different
applications (nothing new here), however nobody who have been working
with PKI long enough would actually made the case that the security
levels of short-lived-no-revo and any-lived-plus-revo are the same
(which seems the life-motif of the presentation and the document itself).

Other aspects that I think shall be revisited are the lack of
considerations about the usability of deployed infrastructures (when no
revocation is assumed) and some wrong considerations in the document
about validity periods of OCSP Responses and CRLs (that clearly
undermine the equivalence claim).

_*Equivalence of Short-Lived w/out Rev Support and Any-Lived w/ Rev
Support*_

The statements that made me jump on my seat is the claim that
short-lived certificates without revocation support (BTW, short-lived
does not necessarily exclude revocation support) and certificates
(short-lived or not) vs. any-lived certificates with revocation support
have the same level of security as long as the validity period of the
short-lived ones is equal or shorter than CRLs or OCSP validity. I find
this quite a puzzling statement. For once, there should be
considerations about the fact that if a key is compromised and it is
used by a malicious entity to attack/disrupt/etc. another entity, the
rightful owner of the certificate does not have any possibility to prove
that someone else did it - there is no authenticated trail (OCSP
response or CRL) that can be used in this case and this can lead, in
some environments, to legal implications. I am curious about how do the
authors address this point, maybe some considerations shall be made here.

Also the claim that:

    " it is hard to justify why the CA or a delegate needs to both sign
    blob-1 (the certificate) and also sign blob-2 (the CRL or OCSP
    response) to tell relying parties that blob-1 is still valid."

is quite curious and, I might say, misleading. Although the revocation
status (either in the form of an OCSP or CRL) does not provide
additional information besides the validity when the certificate is not
revoked, it does provide quite a lot of useful information when the
certificate is revoked (e.g., when a compromised happened, the reason
for revocation - e.g., key compromise, a person has left the
organization, a HW token is broken, etc.). I would prefer the authors to
explain what they mean in more extensive and engineering-appropriate
form. This is another evidence that the two systems are definitely NOT
equivalent from a security perspective.

Another example about the fact that some form of revocation is still
needed comes from the document itself (thus contradicting, IMO, the main
claim of the document - 5.1):

    "No matter how short-term these short term certificates are, there
    is a certain window of time when the attacker can use the
    certificate.  This can often be mitigated with application-level
    measures."

this is "application-level measures == application-level revocation".
This means that now, instead of having standardized ways to check for
the status of certificates, each application need to implement a way to
deal with it on an ad-hoc basis and being able to distribute securely
this information to all relying parties. Undoubtedly, for anybody who
has ever had to deal with such problems this becomes a quite costly and
intractable problems very quickly. Maybe some considerations about this
should be added in the document as well.

_*Usability of Deployed Infrastructures*_

One important section that is missing is: how do these no-revocation
PKIs look like? There are basically two main choices here:

 1. Deploy a 2 level-only PKI. That means having a Trust Anchor that
    issues directly the EE certificates. Besides all security
    considerations about TAs being online (as required in short-lived
    environments), this makes it very difficult to deploy. *Important
    considerations should be made in this case.

    *
 2. Deploy a 3+ level PKIs (current best practices). This approach
    involves having (usually one) intermediate CAs (there can be more).
    In this case, the TAs issue the intermediate CAs' certificates and
    the last intermediate CAs issue the EE ones. Obviously, intermediate
    CAs can not have the same short validity period as the EE certs,
    therefore the need for revocation (at least at the intermediate CAs
    level) is evident. *Important considerations shall be made also in
    this case.*

*Wrong Considerations about CRLs and OCSP Responses validity periods*

In the document, statements like the following shall be fixed and
expanded for clarity:

    "If a CRL has a nextUpdate field that is 4 days in the future, a
    typical system will not attempt to fetch a new one before those 4
    days have elapsed."

And then it continue by stating the following:

    "For this reason, moving to STAR certificates provides a similar
    level of security to what is generally practiced on the web."

Since the first statement is incomplete and, thus, misleading - the
second statement does not hold. Let me explain further for the people
that are not familiar with how CRLs and OCSP are processed. Although
there is a validity period for revocation information, it is well-known
that the expiration field indicates the time "within a new revocation
status information will be made available" and it is NOT "this is the
revocation status of the target certificate until the expiration" -
common practice is that when a revocation event occurs, new CRLs and
OCSP responses for the revoked certificates are made available
immediately or within few hours at most.

It is an important distinction that highlights also why the lack of
revocation information makes the system less secure. Although it is
quite evident why and since this is not addressed in the document, it
might be useful to spell it out.

In a multi-party environment, different applications might have (a)
different strategies when it comes to caching of the revocation
information and/or (b) check the revocation information at different
times. Let's make the case of 2 parties checking the rev info for the
same certificate. If party A accesses OCSP/CRLs at {time1} and caches it
until {time1 + delta}, party B retrieves it at {time2} and caches it
until {time2+delta}. Let's assume that time2 > time1 and that new
revocation status information is already available at {time2}. This
means that, although party A is still vulnerable until {time1+delta},
party B is not. In a short-lived cert environment w/out revocation ALL
parties are VULNERABLE until the compromised {key+certificate} expires.

It seems quite clear that the two environments (short-lived w/ no revo
and any-lived w/ revo) do not have the same security properties.

Therefore I think that the authors ought to demonstrate the equivalence
of security levels (not just assume it as hypothesis - given I just
disproved it) or to remove all claims that the two environments are
actually equivalent from as security perspective and to add specific
considerations for short-lived-no-revo about the the fact that not
supporting revocation is inherently weaker because it potentially
exposes all parties to attacks (e.g., MITM, un-authorized access to
resources, etc.) that can not be stopped (unless you implement
application-level revocation.. and, therefore, re-introduce revocation
from the backdoor in a non-standardized, ad-hoc, hard-to-manage across
application fashion).

*Final Considerations*

I am not opposed at the concept of this document to be considered for
BCP, however all the above issues MUST, IMO, be addressed before the
document can be considered further. I think I already raised these
considerations at the last IETF, but I do not think the authors missed
or have not considered the provided feedback. I hope that a more
explicit and written feedback might be taken into considerations.

Just my 2 cents form an old barnacle... :D

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Mar 2018 18:16:25 -0500

[spasm and pkix to bcc; please continue discussion on one list only]

Hi Max,

> undermine the equivalence claim).

It would probably be helpful if you included a description of what
attacker capabilities are present in your mental model.  If the
attacker is modelled as being in control of the network (and
revocation status is carried over HTTP-not-S) then the claim of
equivalence between short-lived certs and "short-lived" OCSP holds
much more weight.  When you say that a second party can get the
valid revocation status information, that implies that the attacker
does *not* have full control over the network -- so what exactly can
and cannot the attacker do?

-Ben

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Mar 2018 11:10:11 +0000

Keeping only SAAG, because PKIX does not exist yet, and LAMPS will need to recharter before taking this on.

> On 21 Mar 2018, at 13:08, Dr. Pala <[email-masked]> wrote:
> 
> Hi all,
> 
> unfortunately I missed the sec-dispatch session, but I have some important considerations about the document. In general, short-lived certificates have been around for many years and for many different applications (nothing new here), however nobody who have been working with PKI long enough would actually made the case that the security levels of short-lived-no-revo and any-lived-plus-revo are the same (which seems the life-motif of the presentation and the document itself).
> 
I disagree. The most common use of certificates by sheer volume of transactions is server authentication on the web, and some of the most popular clients avoid revocation checking on long-lived certificates unless the revocation information is supplied via stapling. No revocation checking on long-lived certificates is worse than no revocation checking on short-lived certificates. I was not making the claim that short-lived-no-revo is as good as any-lived-plus-revo, only that it is at least as good as the common practice.

When revocation is checked it is still IMO equivalent. More on that later.
> Other aspects that I think shall be revisited are the lack of considerations about the usability of deployed infrastructures (when no revocation is assumed) and some wrong considerations in the document about validity periods of OCSP Responses and CRLs (that clearly undermine the equivalence claim).
> Equivalence of Short-Lived w/out Rev Support and Any-Lived w/ Rev Support
> The statements that made me jump on my seat is the claim that short-lived certificates without revocation support (BTW, short-lived does not necessarily exclude revocation support) and certificates (short-lived or not) vs. any-lived certificates with revocation support have the same level of security as long as the validity period of the short-lived ones is equal or shorter than CRLs or OCSP validity. I find this quite a puzzling statement. For once, there should be considerations about the fact that if a key is compromised and it is used by a malicious entity to attack/disrupt/etc. another entity, the rightful owner of the certificate does not have any possibility to prove that someone else did it - there is no authenticated trail (OCSP response or CRL) that can be used in this case and this can lead, in some environments, to legal implications. I am curious about how do the authors address this point, maybe some considerations shall be made here.
> 
> Also the claim that:
> 
> " it is hard to justify why the CA or a delegate needs to both sign blob-1 (the certificate) and also sign blob-2 (the CRL or OCSP response) to tell relying parties that blob-1 is still valid."
> 
> is quite curious and, I might say, misleading. Although the revocation status (either in the form of an OCSP or CRL) does not provide additional information besides the validity when the certificate is not revoked, it does provide quite a lot of useful information when the certificate is revoked (e.g., when a compromised happened, the reason for revocation - e.g., key compromise, a person has left the organization, a HW token is broken, etc.). I would prefer the authors to explain what they mean in more extensive and engineering-appropriate form. This is another evidence that the two systems are definitely NOT equivalent from a security perspective.
> 
That is a strange property of CRLs (or OCSP responses) in that they are objects with multiple consumers. The RP does not need to know the reason - the decision for it is binary: the certificate is either valid or invalid. Other entities may use it as a slice of the database. The date property makes sense if very specific applications where there are time-stamped, signed and counter-signed messages. For the common case of authenticating entities in TLS or IKE it is irrelevant. I think the draft should have some text limiting scope to cases that don’t care about revocation time.
> Another example about the fact that some form of revocation is still needed comes from the document itself (thus contradicting, IMO, the main claim of the document - 5.1):
> 
> "No matter how short-term these short term certificates are, there is a certain window of time when the attacker can use the certificate.  This can often be mitigated with application-level measures."
> 
> this is "application-level measures == application-level revocation". This means that now, instead of having standardized ways to check for the status of certificates, each application need to implement a way to deal with it on an ad-hoc basis and being able to distribute securely this information to all relying parties. Undoubtedly, for anybody who has ever had to deal with such problems this becomes a quite costly and intractable problems very quickly. Maybe some considerations about this should be added in the document as well.
> 
> Usability of Deployed Infrastructures
> 
> One important section that is missing is: how do these no-revocation PKIs look like? There are basically two main choices here:
> 
> Deploy a 2 level-only PKI. That means having a Trust Anchor that issues directly the EE certificates. Besides all security considerations about TAs being online (as required in short-lived environments), this makes it very difficult to deploy. Important considerations should be made in this case.
> 
> Deploy a 3+ level PKIs (current best practices). This approach involves having (usually one) intermediate CAs (there can be more). In this case, the TAs issue the intermediate CAs' certificates and the last intermediate CAs issue the EE ones. Obviously, intermediate CAs can not have the same short validity period as the EE certs, therefore the need for revocation (at least at the intermediate CAs level) is evident. Important considerations shall be made also in this case.
> Wrong Considerations about CRLs and OCSP Responses validity periods
> 
> In the document, statements like the following shall be fixed and expanded for clarity:
> 
> "If a CRL has a nextUpdate field that is 4 days in the future, a typical system will not attempt to fetch a new one before those 4 days have elapsed."
> 
> "For this reason, moving to STAR certificates provides a similar level of security to what is generally practiced on the web."
> 
> Since the first statement is incomplete and, thus, misleading - the second statement does not hold. Let me explain further for the people that are not familiar with how CRLs and OCSP are processed. Although there is a validity period for revocation information, it is well-known that the expiration field indicates the time "within a new revocation status information will be made available" and it is NOT "this is the revocation status of the target certificate until the expiration" - common practice is that when a revocation event occurs, new CRLs and OCSP responses for the revoked certificates are made available immediately or within few hours at most.
> 
Sure. As soon as the CA receives a report that a certificate is compromised, a new CRL (or OCSP response) is issued. However, assuming the RP has downloaded the CRL 1 day earlier, that CRL marked as having a nextUpdate 3 days later. The RP will not download the new CRL for 3 more days, and will therefore continue to accept the compromised certificate for 3 days.

This can be mitigated by the RP having a local policy of refreshing CRLs every so often, say every day. This limits the exposure time to 24 hours, but does not eliminate it entirely.

OCSP stapling makes this worse. The compromised EE will have a cached OCSP response that is valid for 4 days. It will use this in TLS or IKE, and the RP will never check it.

That is what I mean by saying that compromised short-lived-no-rev certificates are treated as valid for as long as any-lived-with-rev certificates if you set the lifetime similarly. The new revocation information may be available, but it’s not used.
> It is an important distinction that highlights also why the lack of revocation information makes the system less secure. Although it is quite evident why and since this is not addressed in the document, it might be useful to spell it out.
> 
> In a multi-party environment, different applications might have (a) different strategies when it comes to caching of the revocation information and/or (b) check the revocation information at different times. Let's make the case of 2 parties checking the rev info for the same certificate. If party A accesses OCSP/CRLs at {time1} and caches it until {time1 + delta}, party B retrieves it at {time2} and caches it until {time2+delta}. Let's assume that time2 > time1 and that new revocation status information is already available at {time2}. This means that, although party A is still vulnerable until {time1+delta}, party B is not. In a short-lived cert environment w/out revocation ALL parties are VULNERABLE until the compromised {key+certificate} expires.
> 
> It seems quite clear that the two environments (short-lived w/ no revo and any-lived w/ revo) do not have the same security properties.
> 
> Therefore I think that the authors ought to demonstrate the equivalence of security levels (not just assume it as hypothesis - given I just disproved it) or to remove all claims that the two environments are actually equivalent from as security perspective and to add specific considerations for short-lived-no-revo about the the fact that not supporting revocation is inherently weaker because it potentially exposes all parties to attacks (e.g., MITM, un-authorized access to resources, etc.) that can not be stopped (unless you implement application-level revocation.. and, therefore, re-introduce revocation from the backdoor in a non-standardized, ad-hoc, hard-to-manage across application fashion).
> 
> Final Considerations
> 
> I am not opposed at the concept of this document to be considered for BCP, however all the above issues MUST, IMO, be addressed before the document can be considered further. I think I already raised these considerations at the last IETF, but I do not think the authors missed or have not considered the provided feedback. I hope that a more explicit and written feedback might be taken into considerations.
> 
When this becomes a LAMPS working group item, it can definitely use all the input. This is why the feel of the room in SecDispatch was that this document needed a working group and was not appropriate for AD-sponsored.
> Just my 2 cents form an old barnacle... :D
Bah! If you’re an old barnacle, what does this say about me?  :-)

Yoav

---

From: "Dr. Pala" <[email-masked]>
Date: Sat, 24 Mar 2018 15:04:48 -0600

Hi Ben,

On 3/21/18 5:16 PM, Benjamin Kaduk wrote:
> [...]
I think that the case you describe was already discussed in my brief
feedback for the document, however let me clarify a bit more.

The equivalence in the security level between the two environments would
be if and only if an attacker controls (active attacker) any possible
path to the revocation information (i.e., not just one client, but all
the clients that might retrieve the rev info are affected). On the open
internet, that would be to control all redundant links to where the
services are provided (e.g., full control over CNDs redundant links). 
In the short-lived certificates case, instead, once the keys are
compromised, they are compromised for EVERY client relying on those
certificates without the need for an attacker to have active-attacker
properties over the entire network.

Putting it in a different way: for the case with revocation information,
the attacker not only need to be able to compromise the private key, but
it also need to own all possible paths to the revocation information
whilst for the short-revo case, the compromise of the key is a
sufficient condition to successfully carry out the attack. Don't you
agree ? So, from this point of view, you need a more powerful attacker
for the case that make use of revocation information - therefore I
really do not see the equivalence. Deploying a revocation infrastructure
actually increases the resources needed by an attacker, therefore
decreasing the risk factors and increasing the security level.

Even when using formal verification methods, these two attackers really
look different. I really do not think you can carry out the same attack
with the least powerful attacker on both scenarios. If I am wrong, can
you please let me know  why this distinction in the needed resources for
an attacker does not affect your perception of equivalence?

Cheers,

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Dr. Pala" <[email-masked]>
Date: Sat, 24 Mar 2018 15:26:15 -0600

Hi Yoav,

responses inline..

On 3/22/18 5:10 AM, Yoav Nir wrote:
> [...]
> I disagree. The most common use of certificates by sheer volume of
> transactions is server authentication on the web, and some of the most
> popular clients
> avoid revocation checking on long-lived certificates unless the
> revocation information is supplied via stapling. No revocation
> checking on long-lived
That is an application-level choice that might be ok in some
environments but not all. For example, many environments (not browsers,
which are not the greatest examples when it comes to security) mandate
for checking revocation information or terminating the connections
(e.g., OCF, CMI, MulteFire, etc.) If the document is limited to a
specific scope, then it should be clearly stated - but the scope, IMHO,
is not well defined.

I guess you are restricting the use-case for TLS only, correct? I do not
think I saw this anywhere in the document.
> certificates is worse than no revocation checking on short-lived
> certificates. I was not making the claim that short-lived-no-revo is
> as good as any-lived-plus-revo, only that it is at least as good as
> the common practice.
I am a little confused, I thought that the web, because of certificate
transparency, was NOT a good use-case for short-lived certs.
> [...]
> That is a strange property of CRLs (or OCSP responses) in that they
> are objects with multiple consumers. The RP does not need to know the
> reason - the decision for it is binary: the certificate is either
> valid or invalid. Other entities may use it as a slice of the
> database. The date property makes sense if very specific applications
> where there are time-stamped, signed and counter-signed messages. For
> the common case of authenticating entities in TLS or IKE it is
> irrelevant. I think the draft should have some text limiting scope to
> cases that don’t care about revocation time.
So, this document's scope is TLS or IKE only ?
>> [...]
> Sure. As soon as the CA receives a report that a certificate is
> compromised, a new CRL (or OCSP response) is issued. However, assuming
> the RP has downloaded the CRL 1 day earlier, that CRL marked as having
> a nextUpdate 3 days later. The RP will not download the new CRL for 3
> more days, and will therefore continue to accept the compromised
> certificate for 3 days.
Maybe also here I was not really clear enough - sorry. What you are
saying is true for ONE RP, but when there are multiple RPs that might
access the revocation information at different times, what you describe
is actually a limited view of the problem.
> This can be mitigated by the RP having a local policy of refreshing
> CRLs every so often, say every day. This limits the exposure time to
> 24 hours, but does not eliminate it entirely.
It does not, however this takes off the table the equivalency in the
security of the two environments (revo vs. non-revo). Don't you agree?
> OCSP stapling makes this worse. The compromised EE will have a cached
> OCSP response that is valid for 4 days. It will use this in TLS or
> IKE, and the RP will never check it.
Actually that is not entirely true - you assume that applications all
behave like browsers. Even when the OCSP is stapled, if the
application's policy is to have < 1d old revo info available, it will
retrieve the OCSP if the stapled ones are not fresh - if no access to
the rev-info is available, then the connection shall be terminated
because the trust settings are not satisfied by the connection / validation.

Therefore "will never check it" is a limited vision, IMHO.
> That is what I mean by saying that compromised short-lived-no-rev
> certificates are treated as valid for as long as any-lived-with-rev
> certificates if you set the lifetime similarly. The new revocation
> information may be available, but it’s not used.
Again, it MAY be equivalent ONLY IF new revocation information is not
checked. This is a big difference than the blank statements that are in
the draft today.
>>
>> [...]
> When this becomes a LAMPS working group item, it can definitely use
> all the input. This is why the feel of the room in SecDispatch was
> that this document needed a working group and was not appropriate for
> AD-sponsored.
>>
I am not sure, but I have been dealing w/ PKIs from all aspects
(implementations, deployment, research, etc.) for almost 30yrs now..
Maybe we can be barnacles together! Yeah! Power to the banacles!!!!

Cheers,
Max

P.S.: There are many other points that I raised in the original feedback
- I would like them to be discussed too, if possible :D I guess that
will happen in LAMPS, at some point :D

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Mar 2018 10:45:00 -0500

> is actually a limited view of the problem.

That depends on the security model and what capabilities you are
willing to grant to the attacker.  Which relates directly to the
question I asked in my previous message on this thread -- are you
planning to reply to it?

Thanks,

Ben

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Mar 2018 20:45:05 +0300

Dr. Pala writes:
> Putting it in a different way: for the case with revocation
> information, the attacker not only need to be able to compromise the
> private key, but it also need to own all possible paths to the
> revocation information whilst for the short-revo case, the
> compromise of the key is a sufficient condition to successfully
> carry out the attack. Don't you agree ?

In most protocols there is a way to provide the revocation status
(OCSP, CRLs etc) inband in side the protocol itself, thus attacker
does not need to control anything in the network, it simply send the
certificate and the revocation information to the received, and as
long as the revocation information is still valid the receiver will
accept it and do not even try to fetch anything from the network. This
means that attacker can usually even force the receiver to accept CRLs
or OCSP responses as long as they are valid, even if there would be
new ones created already.

For the receiver point of view he will get valid certificate and
signed revocation information telling that certificate is still valid
until nextUpdate time, so why should it fetch anything from the net.
Attacker of course does not include the latest revocation information
which marks certificate revoced, but the old one which did not do that
yet, as long as the nextUpdate is not in the past.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2018 17:46:57 -0400

{BTW: I read the document, and I like it a lot. Should I be Reply-To:
lamps at this point}

    > new ones created already.

And just to add: this is an intended *feature* of CRLs and certificates.
They can be used offline, and they do not cause traffic or dependancy
upon the certificate authority.  The CA can be entirely offline if
CRLs can be delivered out-of-band.

(BUT: I thought OCSP was always supposed to be "online", never in-band?
Perhaps there are things about OCSP which I'm simply ignorant)

    > _______________________________________________
    > saag mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/saag

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 27 Mar 2018 14:00:21 +0000

> Perhaps there are things about OCSP which I'm simply ignorant)

OCSP is actually a bit of a misnomer.  The "online" part just means you can
query for only the certificate you want, when you want, instead of having 
to download and process the entire CRL.  How you get the signed OCSP 
response doesn't really matter.  This is why OCSP stapling works (well,
sort of works; webservers need to improve their support for it), where the
server fetches the OCSP response for you, and includes it in the protocol.

It's also worth mentioning that if you are worried about people giving you
still valid but not fresh OCSP responses, the OCSP protocol does support
sending a nonce to the OCSP server.

There are a variety of ways of handling revocation, and short lived 
certificates are just one possible answer.  One of the problems with
the document is that instead of explaining in a balanced way the
advantages of short-lived certificates, it tries to go overboard and claim
that all other revocation methods are inferior in all circumstances,
which isn't true.

-Tim

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Mar 2018 14:19:08 +0000

Yes, but it's also worth mentioning that this is not supported by many of the biggest OCSP responders.

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 27 Mar 2018 14:27:00 +0000

True.  This is largely because it is difficult to support with CDN 
configurations.
Although one of the top ten CAs used to do it.

It's something I'd like us to optionally support in the future, for those who
want to use it.

-Tim

> -----Original Message-----
> From: Salz, Rich [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2018 10:19 AM
> To: Tim Hollebeek <[email-masked]>; Michael Richardson
> <[email-masked]>; [email-masked]; Tero Kivinen <[email-masked]>
> Subject: Re: [saag] [lamps] Considerations and Clarifications about 
> draft-nir-
> saag-star-01
>
> Yes, but it's also worth mentioning that this is not supported by many of 
> the
> biggest OCSP responders.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Mar 2018 14:30:35 +0000

configurations.

Nah, the CDN isn't the issue.  It's having the OCSP responder online and available all the time that's the issue.

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 27 Mar 2018 14:33:37 +0000

Having worked at the company that stopped doing it, I can assure you the
CDN was in fact the issue.  Specifically, the issue was not wanting to have
an OCSP signing key on a CDN server.

-Tim

> Sent: Tuesday, March 27, 2018 10:31 AM