Subject: [lamps] 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: Stefan Santesson <[email-masked]>
Date: Tue, 27 Mar 2018 13:10:02 +0200

HI,

I think this discussion underlines my argument to rescope this effort from “short-lived” certificates to “no-revocation” certificates.

The concept of “short-lived” is filled with policy considerations that we can battle forever. Things like what actually is “short” and how short is good enough to skip revocation is impossible to agree on. And there is no need to agree on that. At least not in the IETF.

CAB forum and other policy related forums may want to agree on that, but not IETF.

There may be a number or good reasons to provide certificates with no revocation. One such reason is if the private key is used only once and then destroyed in a secure and controlled fashion.

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Mar 2018 11:44:01 -0400

Trimming the distribution to the LAMPS mail list ...

RFC 3281 includes the definition of noRevAvail certificate extension.  It is defined in X.509, and the definition is repeated in RFC 3281, Section 4.3.6.

If the CA is not going to publish revocation information about the certificate, I think we should include this extension to tell relying parties not to bother looking for it.

Russ

> On Mar 21, 2018, at 9:08 AM, 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).
> 
> 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:
> 
> 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.
> 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.
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Mar 2018 16:50:31 +0100

> If the CA is not going to publish revocation information about the certificate, I think we should include this extension to tell relying parties not to bother looking for it.

Makes sense to me too.  It's non-critical so shouldn't
break anything.

S.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 27 Mar 2018 21:40:42 +0200

We had a long discussion in ETSI about this.

One aspect is that the absence of revocation information actually breaks several implementations.
One idea was to publish an empty CRL + an extension with the semantics = "You may skip the rev checking, because the CRL is empty"

This way you would have the cake and eat it too. Old systems would use the CRL and work. New systems would understand the extension and skip CRL checking.

But maybe this is to overcomplicate things.

/Stefan

On 2018-03-27, 17:50, "Spasm on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    S.

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 27 Mar 2018 19:47:56 +0000

It's not widely known, but Firefox already skips revocation checking if the lifetime
is short enough (that code was added after the previous discussion of whether it
was necessary to omit the information).  You don't actually have to modify the cert 
at all if you don't want to.

-Tim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Tuesday, March 27, 2018 3:41 PM
> To: Stephen Farrell <[email-masked]>; Russ Housley
> <[email-masked]>; LAMPS <[email-masked]>
> Subject: Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-
> 01
> 
> One idea was to publish an empty CRL + an extension with the semantics =
> "You may skip the rev checking, because the CRL is empty"
> 
> This way you would have the cake and eat it too. Old systems would use the
> CRL and work. New systems would understand the extension and skip CRL
> checking.
> 
> On 2018-03-27, 17:50, "Spasm on behalf of Stephen Farrell" <spasm-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> 
> 
>     > RFC 3281 includes the definition of noRevAvail certificate extension.  It is
> defined in X.509, and the definition is repeated in RFC 3281, Section 4.3.6.
>     >
>     > If the CA is not going to publish revocation information about the
> certificate, I think we should include this extension to tell relying parties not to
> bother looking for it.
> 
> 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).
>     >> 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."
>     >>
> 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.
>     >>
>     >> "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.
>     >>
>     >> 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.
>     >> "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
>     >> 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.
>     >>
> 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.
>     >>
> 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
>     >>
> 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.
>     >>

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Mar 2018 22:19:07 -0400

> On Mar 27, 2018, at 07:10, Stefan Santesson <[email-masked]> wrote:
> 
>  “no-revocation”

Might I humbly suggest the slight more positive: "revocation-free" certificates.

spt

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 28 Mar 2018 15:47:11 +0200

Great suggestion!! (

On 2018-03-28, 04:19, "Spasm on behalf of Sean Turner" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    spt

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Mar 2018 14:28:47 -0400

Stefan:

Are us saying that it allows a relying party that does not recognize the non-critical noRevAvail extension to use the CRLDP extension to get an empty CRL?  In this way, only the relying parties that do not recognize the noRevAvail extension will get the latency hit? 

Russ

> On Mar 27, 2018, at 3:40 PM, Stefan Santesson <[email-masked]> wrote:
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Mar 2018 08:35:17 +0200

Basically yes.

At least that was the discussion. I have to check what the outcome was.
Also this discussion started as "Short-lived" certs, and ended up as "Revocation-free" certs.

This way to deal with real implementations by using both noRevAvail, combined with a CRLDP and an empty CRL probably don't need a standard, but maybe a BCP or something.

/Stefan

On 2018-03-28, 20:29, "Russ Housley" <[email-masked]> wrote:

    Stefan:

    Russ

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Mar 2018 18:24:20 +0300

This is true, but any CA issuing such certificates will have to maintain an always-on server to serve those CRLs. If the CRL DP extension is not there, they don’t need that server.

Yoav

> On 29 Mar 2018, at 9:35, Stefan Santesson <[email-masked]> wrote:
> 
> Basically yes.
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Mar 2018 17:25:42 +0200

Fully agree. 
I have never suggested that a CA should be required to provide a CRL.
I'm just saying that a CA should be allowed to if it has an interest to support legacy clients.

/Stefan

On 2018-03-29, 17:23, "Yoav Nir" <[email-masked]> wrote:

    Yoav

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 29 Mar 2018 19:04:45 +0000

One interesting point that I noticed yesterday is that eIDAS actually requires
that certificates contain a pointer to status information.

So there may be some barriers to being able to use revocation free Qualified
Website Authentication Certificates.

-Tim

> Sent: Thursday, March 29, 2018 11:26 AM
> To: Yoav Nir <[email-masked]>
> Cc: LAMPS <[email-masked]>; Russ Housley <[email-masked]>
>     This is true, but any CA issuing such certificates will have to maintain an
> always-on server to serve those CRLs. If the CRL DP extension is not there, they
> don’t need that server.
> 
>     Yoav
> 
>     > This way to deal with real implementations by using both noRevAvail,
> combined with a CRLDP and an empty CRL probably don't need a standard, but
> maybe a BCP or something.
>     >
>     > /Stefan
>     >
>     >
>     >
>     >    Are us saying that it allows a relying party that does not recognize the
> non-critical noRevAvail extension to use the CRLDP extension to get an empty
> CRL?  In this way, only the relying parties that do not recognize the noRevAvail
> extension will get the latency hit?
>     >
>     >    Russ
>     >
>     >
>     >> One idea was to publish an empty CRL + an extension with the semantics
> = "You may skip the rev checking, because the CRL is empty"
>     >>
>     >> This way you would have the cake and eat it too. Old systems would use
> the CRL and work. New systems would understand the extension and skip CRL
> checking.
>     >>
> revocation is assumed) and some wrong considerations in the document about
> validity periods of OCSP Responses and CRLs (that clearly undermine the
> equivalence claim).
> 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
> 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.
>     >>>>
>     >>>> 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
>     >>>>