[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

Ben Wilson ben at digicert.com
Fri Mar 22 20:54:54 UTC 2013


Moving this pre-proposal to the public list for more discussion.

 

From: management-bounces at cabforum.org
[mailto:management-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Wednesday, March 20, 2013 4:08 PM
To: CABFMAN
Subject: [cabfman] OCSP Stapling and Short-Lived Certificates

 

All,

 

Before moving this toward a ballot, attached are a few redlined pages of the
Baseline Requirements to address OCSP stapling and short-lived certificates.
After you've had the chance to look at them, please review some of the
reasoning below that is in support of the proposed changes.   

 

As background, the language being modified was originally intended to
address the omission of the AIA for OCSP if the CA and the customer properly
configured retrieval of OCSP responses in a must-staple scenario.  However,
since then our Forum discussions have revealed that the server software
handles stapling best by pulling the OCSP server address from the
certificate (manual configuration errors are more likely to occur if the
certificates do not contain an AIA pointer to the OCSP Server).  

 

Section 13.2.1

1.       The Baseline requirements should not imply that OCSP stapling is
restricted to high-traffic sites.  Also, we think that defining
"high-traffic" is problematic. 

2.       A customer is not required to always staple.  It's not the sine qua
non, and as mentioned above, CAs won't have as much control here as the
current language seems to imply.  

3.       If the customer requests the MustStaple OID because it is confident
enough in its capabilities to provide stapling consistently, then we should
make that available - but the mustStaple identifier should not be required
or prohibited.  So this language should be a "MAY."   The existing language
only partially explains what the MustStaple OID can be used for (i.e. it's a
step toward preventing a downgrade attack when OCSP response are being
blocked), but again, the suggested revision does not require anything unless
the CA includes the OID in the certificate at the request of the customer.
We're welcome to suggestions on how to word this better.

 

Appendix B Section (2)C - Subordinate CA Certificate

"With the exception of stapling" should be deleted because it neglects the
need for the AIA for OCSP, as discussed above.   (The language in the last
paragraph is also an incorrect description of the Sub CA's AIA contents.)

 

Appendix B Section (3)C. - Subscriber Certificate

Again, deleting exception for AIA for OCSP stapling, but replacing it with
exception for short-lived certificates ("certificates with validity periods
of 168 hours or less").  It has been argued that this type of short-lived
certificate presents the same risk profile as certificates supported by CRLs
and OCSP responses, which are valid and cached for a week to 10 days.
Because at least some form of testing should be allowed, and the Baseline
Requirements should only set a floor and not prohibit innovative solutions,
short-lived certificates without revocation information should not be
prohibited.  

 

Thanks,

 

Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130322/600029bc/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BRv.1.1.3-Issue7.pdf
Type: application/pdf
Size: 28778 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130322/600029bc/attachment-0002.pdf>


More information about the Public mailing list