[cabfpub] Pre-Ballot - Short-Life Certificates
rob.stradling at comodo.com
Mon Nov 10 07:18:43 MST 2014
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
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
3. You propose that "CAs are still required to provide revocation
information for such certificates (during their life)", and I agree with
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
> 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 = 22.214.171.124.126.96.36.199.1). It
> SHOULD also contain the HTTP URL of the Issuing CA’s certificate
> (accessMethod = 188.8.131.52.184.108.40.206.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 =
> 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 provided
> that the Subscriber “staples” OCSP responses for the Certificate in its
> TLS handshakes [RFC4366].
> Public mailing list
> Public at cabforum.org
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
COMODO CA Limited, Registered in England No. 04058690
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
More information about the Public