[cabfpub] Pre-Ballot - Short-Life Certificates
kirk_hall at trendmicro.com
kirk_hall at trendmicro.com
Thu Oct 23 10:26:02 MST 2014
Gerv, without expressing opposition to this pre-ballot, two topics for discussion.
(1) Even though the short lived cert (with no revocation checking pointers) expires in 73 hours, if a CA actually revoked a 73 hour cert within 1 hour of issuance and included revocation checking pointers (especially OCSP), a lot of clients (not 100%, but potentially a lot) would get the revocation information during the remaining 72 hours. But no client will have any chance to get a revocation warning with a short lived cert that lacks checking pointers. Is this an issue?
(2) I worry that a customer that chooses to move to short lived certs and arranges for auto-downloads and auto-installation of new certs every three days could create a vulnerability in its systems. I suppose that's for the customer to worry about, but should we have a concern?
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Thursday, October 23, 2014 5:14 AM
Subject: [cabfpub] Pre-Ballot - Short-Life Certificates
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.
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.]
Update Appendix B of the CAB Forum Baseline Requirements, part (3), section C, to say:
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 = 220.127.116.11.18.104.22.168.1). It SHOULD also contain the HTTP URL of the Issuing CA’s certificate (accessMethod = 22.214.171.124.126.96.36.199.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.
For your information, the current text of B (3) C is:
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 = 188.8.131.52.184.108.40.206.1). It SHOULD also contain the HTTP URL of the Issuing CA’s certificate (accessMethod = 220.127.116.11.18.104.22.168.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
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
More information about the Public