[cabfpub] Pre-Ballot - Short-Life Certificates

[Gervase Markham]

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].