Subject: Re: [saag] Using short term certificates (instead of revocation)

From: "Dr. Pala" <[email-masked]>
Date: Tue, 14 Nov 2017 00:13:59 +0800

Hi Yoav, all,

I quickly read the submitted draft, and I have few comments on that. In 
general, I am quite scared by the current trend to use short-lived 
certificates everywhere to avoid status checking and I would have liked 
the document to provide a more skeptical (or at least less biased) 
approach to it as it does break the trust model in PKIs and has serious 
trust consequences (especially when things go wrong...).

Here's my 2 cents...

*General Considerations*

First of all, it seems that the considerations are oriented to the use 
of certificates for network communications - I would suggest to add 
considerations about the use of short lived certificates for 
authentication and encryption (eg., signing and encrypting) of data that 
might out-live the certificate itself. What are the implications there? 
If this is out-of-scope for the document, I would explicitly say so.

Second, when describing the advantages for validating short-lived EE 
certificates, there are no considerations about the fact that the EE 
cert is only the leaf in a chain that needs to be validated up to a 
trust anchor. Therefore, the support for revocation MUST still be 
implemented to verify that CAs have not been compromised. A point that 
people usually (or conveniently) omit when talking about short-lived 
certs. IMHO, this along defeats most (if not all) the arguments related 
to not supporting revocation (at least outside closed/ad-hoc enviroments).

I also think that the I-D lacks considerations related to the fact that 
issuing a certificate has economic costs (related to operations) that 
the CA has cover - therefore the use of short-lived certificates might 
actually increase the per-certificate cost when compared to long-lived 
certificates over a comparable period of time. Operationally it requires 
more bandwidth, more signing power, etc. For small CAs (few millions 
certificates a year) this might not be a problem, however for larger CAs 
going from few hundreds millions to billions certificates issued might 
very well be.

Another very important point that I think it should be made is that by 
not having a revocation system in place, the CA (and any relying party) 
have no way to know if a key is to be trusted or not (since it is 
trusted by default). And just "stopping" the automatic renewal seems a 
solution only in the case that the same key was used in all the renewed 
certificates... If a new certificate will still use the same key, the CA 
would have no record (well, it should have the record anyway) in its 
system that would prevent issuing a certificate for an already 
compromised key. The concept of revocation actually can be quite useful 
for key management purposes at the CA level.

Another point (related to the previous one) that I think is important to 
make is that short-lived certificates SHOULD NOT allow for the same key 
to be used. This is required because otherwise you artificially extend 
the vulnerability period to the sum of the "short" validity periods of 
all certificates issued for the same keypair. I think that this is very 
dangerous and should always be avoided otherwise you end up with a 
long-lived key that can not be revoked. The same reason can be given 
also for long-lived certificates, however for long-lived certs the 
practice of re-keying is usually the norm and keys/certificates can be 
revoked.

*More Specific Comments*

It also seems to me that there are some wrong considerations about the 
validity period of CRLs and OCSP responses. For the former, the 
"nextUpdate" field indicates that the relying party should expect a new 
CRL to be published BEFORE that date but it definitely does not say that 
the information inside the CRL is valid until then (i.e., there have not 
been revocations or new CRLs issued before that time). It is, in fact, 
typical for CAs to provide a nextUpdate field that is few days after the 
lastUpdate one, but issuing CRLs every few hours and at each revocation 
event. For OCSP responses, instead, the situation is different. The 
validity period represents the time for which that information is to be 
considered valid. This is why, OCSP responses usually have quite short 
validity periods (minutes, few hours, and sometimes days) when compared 
to CRLs. I think this is an important distinction that the authors 
should consider and that maybe would change some of the considerations 
provided in the document.

In Section 2.1, "In fact, a CA for STAR does not need to keep any record 
of issued certificates" is definitely a wrong statement. CAs operations 
need usually to follow rigorous procedures to issue certificates and 
they MUST keep extensive records of the process to provide auditing 
trails for regular auditing that they undertake and to make sure that 
non-authorized issuing of certificates happens. I would suggest to 
remove this statement as it is definitely misleading.

In section 4, "The motivations for using short-term certificates are 
operational" is, IMHO, not really the full story. I would say that 
despite all the efforts from CSPs to provide solid and largely available 
infrastructures, the main issue related to revocation is that 
application developers (a) do not understand the technology and (b) they 
do not want to do the right work to begin with (despite the extensive 
support that today exists in crypto libraries like MS-CAPI or OpenSSL). 
 From the two subsequent arguments, the first one seems taken from "The 
Book of Browsers" where displaying the cool website few milliseconds 
faster is a good reason for not checking the revocation information (not 
considering that techniques like pre-fetching could be implemented today 
and that would solve that particular issue). This is definitely NOT a 
major issue in  environments other than the Web - I would suggest the 
authors to provide (a) evidence (data) that that is a problem, and (b) 
to provide the context in which those statements have been made. For the 
second argument (availability of the DP), I would argue that today CAs 
already provide (with high-availability) revocation information for 
certificates by leveraging large (and costly) CDNs deployments. If the 
COSTS is the real issue here, that could be addressed by, without 
dropping revocation support, leveraging some existing distributed system 
(e.g., DNS) as an alternative transport and caching mechanism (OCSP over 
DNS) [which also simplifies the query mechanism].

Section 4.1 tries to provide considerations about the balance between 
when a certificate should be requested and the validity period of EE 
certs. I really do not see why this would be any different than the 
long-lived certificates case (renewal of certificates usually happens 
way before the expiration date to avoid business-continuity issues). I 
would like to see an explanation as to why this is specific for 
short-lived certs and if it is not, I think this section should be removed.

Section 4.2 seems to contain considerations that (although definitely 
true) are not specific to short-lived certificates. Most ICAs provide 
infrastructures that are highly available. I would remove this section 
as it seems not specific to short-lived certificates or explain why 
these considerations are different for short-lived than long-lived 
certificates (given the status of today's ICAs).

For Section 4.5, it is commonly understood that CAs that issue 
short-lived certificates DO NOT publish those certificates in CT. This 
is a known problem that has no solution today AFAIK.

*Final Considerations

*I do think that this document is a good idea and has some initial good 
points, however it seems to me that it does not provide a complete 
picture and I would suggest the authors to seek the review of the 
document by some experts with practical experience in designing, 
deploying, and running large CAs/PKIs. It also seems (from the text - 
but it might just be a personal impression) that the authors do have a 
quite clear position about revocation and that, I think, does not help 
in providing a fair and complete description of the issue.

Looking forward to further discuss these issues and hear your point of 
view on these topics :-D

I hope this helps the discussion,

Cheers,
Max

On 10/18/17 3:03 AM, Yoav Nir wrote:
> Hi all
>
> We’ve submitted this -00 draft for your consideration. It is still very rough with several sections missing, but we feel it’s good enough for starting a conversation.
>
> There is quite a bit of interest in using short term certificates recently. There is a draft at ACME, a proposed draft at STIR, and many use cases in IT, whether these certificates are exchanged with TLS or with IKE or SSH. Some of these use cases are web, but many others are not.  The purpose of this draft is to list considerations, both operational and security, for using short term certificates without revocation.
>
> If this effort is successful, the resulting document should guide both draft writers and IT people in answering two important questions:
>   1. When is using short term certificates appropriate?
>   2. What needs to be in place for a functional, reliable and secure deployment?
>
> Any comments will be greatly appreciated.
>
> Thanks
>
> Yoav on behalf of the authors.
>

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