[cabfpub] Pre-Ballot - Short-Life Certificates

Jeremy.Rowley jeremy.rowley at digicert.com
Thu Oct 23 21:46:46 MST 2014


The data Rob Stradling posted last time this was discussed showed a 
fairly significant clock skew issue.  Here's the data he sent back in 2012:

0.03% have clocks ahead (0.03%) or behind (0.002%) by >365 days.

0.11% have clocks ahead (0.11%) or behind (0.003%) by >180 days.

0.29% have clocks ahead (0.23%) or behind (0.06%) by >90 days.

0.66% have clocks ahead (0.42%) or behind (0.24%) by >28 days.

0.77% have clocks ahead (0.46%) or behind (0.31%) by >14 days.

0.96% have clocks ahead (0.54%) or behind (0.42%) by >7 days.

1.08% have clocks ahead (0.58%) or behind (0.49%) by >4 days.

1.24% have clocks ahead (0.66%) or behind (0.58%) by >2 days.

2.11% have clocks ahead (1.27%) or behind (0.84%) by >1 day.

4.48% have clocks ahead (3.04%) or behind (1.43%) by >12 hours.

5.51% have clocks ahead (3.78%) or behind (1.73%) by >6 hours.



Jeremy

On 10/23/2014 12:20 PM, Rick Andrews wrote:
> I would say that 73 hours is to cover not just clock skew, but the possibility of a CA service interruption (for example, if the customer refreshes every day, and "fetch new daily cert" service fails, and the customer can't get an updated cert until the next day, the customer wouldn't have an interruption of their service).
>
> Gerv, I'm not sure that forbidding CAs to pre-issue short-lived certs is auditable, or even desirable. If an attacker can get in to the CA's database and extract information, that CA is in big trouble, not specifically related to short-lived certs.
>
> -Rick
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
> Sent: Thursday, October 23, 2014 10:32 AM
> To: kirk_hall at trendmicro.com; Gervase Markham; CABFPub
> Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
>
> The 72 hours isn't the refresh time, the refresh time would be at least every 24 hours, and the 72 hours is to cover clock skew, but I think 100-120 hours provides a better margin of error, but then that extends the vulnerability window--so a balanced approach would be needed.
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
> Sent: Thursday, October 23, 2014 11:26 AM
> To: Gervase Markham; CABFPub
> Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
>
> 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?
>
> -----Original Message-----
> 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
> 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
>
> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> 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.
> </pre></td></tr></table>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141023/1fe63d4d/attachment-0001.html 


More information about the Public mailing list