[cabfpub] Pre-Ballot - Short-Life Certificates

[Rob Stradling]

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
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   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.