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

["Dr. Pala" <[e-mail]>]

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