[cabfpub] Short lived certificates

Jeremy Rowley jeremy.rowley at digicert.com
Tue Oct 6 06:21:31 MST 2015


Yes - it’s backwards.  That was an error on my part. The rationale on 48 hours from issuance is that we’ve always talked about 3 days - 1 on the backend and 2 on the front.  48 was picked as a starting point for discussion purposes, not as the final proposal.

Other items mentioned by Doug previous that need to be addressed include:

1)      The timeframe should be based on notBefore since issuance date isn’t defined

2)      Simply state that short-lived certs cannot be generated more than 24 hours before the notBefore date

I’ll try to get a new draft out before tomorrow morning.
From: Richard Barnes [mailto:rbarnes at mozilla.com]
Sent: Tuesday, October 6, 2015 6:49 AM
To: Jeremy Rowley
Cc: public at cabforum.org
Subject: Re: [cabfpub] Short lived certificates

1. Isn't this backwards?  You should want to do revocation for *long* lived certs.

2. What's the rationale for 48 hours?  I don't really see any reason for this threshold to be less than the max OCSP lifetime -- which I already hear operators complaining about.

Sent from my iPhone.  Please excuse brevity.

On Oct 6, 2015, at 04:56, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
This is the language for tomorrow’s discussion on short-lived certificates. I think we’ve exhausted both sides of permitting v. disallowing short-lived certs so instead of arguing over that, I’d rather see if we can find language that people feel provide an appropriate safe-guard while still permitting the advantages given by short-lived certs. One thing we could do is require CRLs (instead of OCSP) for short-lived certs.  This won’t expand CRL size almost at all because they will pretty much fall out of the CRLs by the time the CRL issues (24 hours to issue the CRL means only one CRL before they are removed again).

I’ll be looking for endorsers tomorrow.

….

4.9.10. On‐line Revocation Checking Requirements

Effective 1 January 2013, the CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements.

For the status of Subscriber Certificates with a certificate expiration that is within 48 hours of the certificate’s issuance: The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.

7.1.2.3. Subscriber Certificate
…
c. authorityInformationAccess With the exception of stapling and  certificates that expire within 48 hours of the certificate’s issuance, 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).

The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted provided that the certificate expires within 48 hours of the certificate’s issuance or Subscriber “staples” OCSP responses for the Certificate in its TLS handshakes [RFC4366].

Jeremy
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151006/89723f0d/attachment.html 


More information about the Public mailing list