[cabfpub] Pre-Ballot - Short-Life Certificates

[Bruce Morton]

Hi Gerv,

I'm trying to understand the timeline. Here is how I understand the requirement:
- Certificate is issued every 24 hours
- Certificate is valid 24.5 hours before (the issuance time)
- Certificate is valid 24.5 hours after (the intended 24 hours)
- CA must create the certificate at a time within 1 hour of that encoded in notBefore

I'm not sure how to create the certificate within 1 hour of the notBefore and also have the certificate valid for 24.5 hours before the issuance time.

My thinking is the CA would issue a certificate NOW with a notBefore of 24.5 hours earlier than NOW and a notAfter 48.5 hours later than NOW.

Thanks, Bruce.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Thursday, October 23, 2014 8:14 AM
To: CABFPub
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.

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