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

[Tim Hollebeek <[e-mail]>]

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

> -----Original Message-----
> From: Spasm [mailto:[e-mail]] On Behalf Of Stefan Santesson
> Sent: Thursday, March 29, 2018 11:26 AM
> To: Yoav Nir <[e-mail]>
> Cc: LAMPS <[e-mail]>; Russ Housley <[e-mail]>
> Subject: Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-
> 01
> 
> 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" <[e-mail]> wrote:
> 
>     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 <[e-mail]> wrote:
>     >
>     > 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" <[e-mail]> wrote:
>     >
>     >    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 <[e-mail]>
> wrote:
>     >>
>     >> 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" <spasm-
> [e-mail] on behalf of [e-mail]> wrote:
>     >>
>     >>
>     >>
>     >>   On 27/03/18 16:44, Russ Housley wrote:
>     >>> 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.
>     >>
>     >>   Makes sense to me too.  It's non-critical so shouldn't
>     >>   break anything.
>     >>
>     >>   S.
>     >>
>     >>>
>     >>> Russ
>     >>>
>     >>>
>     >>>> On Mar 21, 2018, at 9:08 AM, Dr. Pala <[e-mail]> 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."
>     >>>>
>     >>>> 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
>     >>>> <cndojoacigamfbdj.png>
>     >>>> _______________________________________________
>     >>>> Spasm mailing list
>     >>>> [e-mail]
>     >>>> https://www.ietf.org/mailman/listinfo/spasm
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Spasm mailing list
>     >>> [e-mail]
>     >>> https://www.ietf.org/mailman/listinfo/spasm
>     >>>
>     >>   _______________________________________________
>     >>   Spasm mailing list
>     >>   [e-mail]
>     >>   https://www.ietf.org/mailman/listinfo/spasm
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> Spasm mailing list
>     >> [e-mail]
>     >> https://www.ietf.org/mailman/listinfo/spasm
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Spasm mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/spasm
> 
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm