[cabfpub] Pre-Ballot - Short-Life Certificates

Mon Nov 10 08:02:40 MST 2014

Hi,

Some more thoughts, since that is what you wanted :)

It seems that in general, we have an issue, where we cannot upgrade
certificate specifications and usage, because it will break older
clients. When legacy usage is a problem like this, it would be good to
fix it. Most likely the problem will become worse over time, and it will
take time to get the fix out to all clients, so we should start right away.

TLS SNI ensured that one server could serve different certificates
depending on which domain the client wants to connect to. If we made a
similar extension for the client to state what it supports, then the
server could serve different certificates depending on what the client
understands. In practice such an extension might say e.g. "Client
support version 1.0; Opera version 25.0.1614.68", that is sufficient for
the server to know what the client supports, and to work around any
client specific bugs. Privacy minded users/vendors can fall back to not
specifying the extension, and get old style certificates.

If we had such a specification, then the discussion around short-lived
certificates would be quite different, as we don't need to worry about
legacy clients, servers just keep serving them the old certificates. So
assume this exists, then read on :)

One of the issues I have with not specifying revocation pointers is that
it is then possible to bulk pre-issue certificates for a year, with no
way to revoke them. When things are possible to do, sooner or later
someone will want to do them, e.g. due to some old legacy system which
nobody dares change. Having rules which can be checked programmatically
is much preferable.

So here is another suggestion:
Create a special breed of short-lived certificates. They have no 'valid
from' or 'valid to' fields, nor revocation pointers. Instead they carry
a proof of the time they were issued, e.g. the latest hash from a CT
log. The certificate is valid 3 days from that timestamp. Backdating is
possible (and legal, but more than 3 days is pointless), pre-issuing is
impossible. Clients have CT log data anyhow, and can compare their local
time to the log time, and automatically account for any clock skew.
Since clock skew is handled, expired certs can be treated just as
harshly as revoked certs. Total data size on the wire should be smaller
than the original proposal.

On 10-Nov-14 15:18, Rob Stradling wrote:
> Hi Gerv.  Some thoughts...
> 
> 1. BRs 13.2.6 says that OCSP responders MUST NOT respond with a "good" 
> status for "a certificate that has not been issued" and that "The CA 
> SHOULD monitor the responder for such requests as part of its security 
> response procedures".
> If OCSP is never used (which would be the case if AIA->OCSP is omitted), 
> then "monitoring the responder" in this way cannot happen.  This could 
> mean that future CA compromises aren't spotted as early as they 
> otherwise might be.
> 
> 2. When revocation is effective (e.g. Firefox with OCSP hard-fail 
> enabled by the user), the user is prevented from accessing the HTTPS 
> site.  However, certificate expiration is treated less harshly - the 
> user can still access the site.
> For short-lived certs to be an effective revocation mechanism (for all 
> certs ideally, but definitely for short-lived certs), expiration needs 
> to be treated as harshly as revocation IMHO.
> The idea of your proposed ballot is that existing browsers will benefit 
> from omitting all revocation pointers.  But it's the existing browsers 
> that, by definition, cannot be updated to treat expiration as harshly as 
> revocation.
> 
> 3. You propose that "CAs are still required to provide revocation 
> information for such certificates (during their life)", and I agree with 
> that.
> For Google's CRLSets, Mozilla's OneCRL (I presume), and certainly 
> Phill's/my Compressed CRLSet proposal, the generator needs to be able to 
> determine the current status of every certificate that's in scope.  To 
> do this, a revocation pointer for each certificate is required.  If 
> there's no revocation pointer in a cert, what do we do?
> Phill's already expressed our hope that "If however we combine short 
> lived certs with compressed CRLs we can reduce the vulnerability window 
> from days to hours".
> 
> 4. What is preventing you from experimenting with short-lived certs that 
> _do_ contain revocation pointers?
> You could change Firefox so that it avoids doing revocation checks for 
> short-lived certs.  You could gather statistics on how much of a problem 
> clock-skew is for the use of short-lived certs in practice.  You could 
> gather user reports on how much of a pain it is to install a new cert on 
> a daily basis.
> 
> 
> But if we must omit revocation pointers, then...
> 
> 5. Possible compromise: Make AIA->OCSP optional, but require CDP. 
> Firefox doesn't check CDP, AIUI Windows intends to stop checking CDP, 
> AIUI many mobile devices have never checked CDP.
> But including CDP helps the production of CRLSets.
> 
> 6. Possible compromise 2: Specify a new mechanism for obtaining 
> revocation status, which no existing browser will use, but which CRLSet 
> generators could use.
> Perhaps use the same syntax as the CDP extension, but just change the 
> extension's OID.  Or maybe put an OCSP responder URL in the issuing CA 
> cert's Subject Information Access extension (instead of the end-entity 
> cert's Authority Information Access extension).
> 
> 
> On 23/10/14 13:13, Gervase Markham wrote:
>> Following on from discussions at the last face-to-face and in the
>> Mozilla forum, this is a pre-ballot for discussion. Comments are very
>> welcome.
>>
>> Gerv
>>
>>
>> Pre-Ballot XXX - Short-Life Certificates
>>
>> Gervase Markham of Mozilla made the following motion and XXX of XXX and
>> YYY of YYY have endorsed it:
>>
>> The CA Browser Forum believes that short-life certificates are one
>> possible option for addressing the issue of timely revocation, and so
>> wishes to remove barriers preventing CAs and browsers deploying and
>> gaining experience with them. Having a short life on a certificate is an
>> alternative method of limiting the fallout from mis-issuance while also
>> providing good performance.
>>
>> The ability to omit revocation pointers from a short-life certificate is
>> important if they are to have any benefit in clients which do not handle
>> them in a special way (that is, at the moment, all clients). So this
>> ballot permits that as an exception to the rule requiring OCSP
>> information to always be present.
>>
>> The definition of "short life" as 73 hours is intended such that sites
>> can roll over their certs every 24 hours, and for all periods of
>> operation, the cert is valid for 24.5 hours before and 24.5 hours after
>> - thus to some degree mitigating the effects of clock skew and timezone
>> issues. To prevent CAs pre-issuing a pile of sequential certificates
>> which could then potentially be stolen in one big chunk, we forbid them
>> from creating short-life certs in advance.
>>
>> For the avoidance of doubt: CAs are still required to provide revocation
>> information for such certificates (during their life), which may be
>> checked by a client which has an out-of-band method of obtaining the
>> necessary endpoint information and wishes to make the necessary
>> performance tradeoff. [Comments particularly welcome here; I wrote it in
>> part because otherwise the surgery to the BRs is rather more extensive.]
>>
>> ---MOTION BEGINS---
>>
>> Update Appendix B of the CAB Forum Baseline Requirements, part (3),
>> section C, to say:
>>
>> C. authorityInformationAccess
>>
>> Other than the exceptions noted below, this extension MUST be present.
>> It MUST NOT be marked critical, and it MUST contain the HTTP URL of the
>> Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It
>> SHOULD also contain the HTTP URL of the Issuing CA’s certificate
>> (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1 for details.
>>
>> The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted in either
>> of the following two cases:
>>
>> * the Subscriber “staples” OCSP responses for the Certificate in its TLS
>> handshakes [RFC4366]; or
>>
>> * the time period between the notBefore and notAfter fields is less than
>> or equal to 73 hours. To take advantage of this exception, the CA must
>> create the certificate at a time within 1 hour of that encoded in notBefore.
>>
>> ---MOTION ENDS---
>>
>> For your information, the current text of B (3) C is:
>>
>> C. authorityInformationAccess
>>
>> With the exception of stapling, which is noted below, this extension
>> MUST be present. It MUST NOT be marked critical, and it MUST contain the
>> HTTP URL of the Issuing CA’s OCSP responder (accessMethod =
>> 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing
>> CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1
>> for details.
>>
>> The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted provided
>> that the Subscriber “staples” OCSP responses for the Certificate in its
>> TLS handshakes [RFC4366].
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
> 

-- 
Sigbjørn Vik
Opera Software