[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

Rich Smith richard.smith at comodo.com
Tue Mar 26 12:11:30 MST 2013


I don't think it really CAN be a SHALL.  We can put it in the guidelines
that way, but at the end of the day, the CA does not control the server that
the certificate is installed on so we can't compel anything and
realistically it's not very feasible for the CA to audit compliance by the
server operator.  It's technically possible for us to audit but what can we
do?  Revoke the cert?  To what end?  There's no revocation information in
it.

At that point it has to fall to the client software to, upon encountering
mustStaple with no accompanying stapled response, to reject the certificate
validity.

-Rich

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Ben Wilson
> Sent: Tuesday, March 26, 2013 1:37 PM
> To: 'Rob Stradling'
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates
> Proposal
> 
> Rob,
> That's only if you use the mustStaple OID -- if you were thinking about
> the ordinary case, then you're right, it is may but if everyone is in
> agreement with your position, then I can change it.  I just thought
> that based on past conversations that everyone wanted greater
> assurances that if it was mustStaple that it would be stapled, but what
> do people think?
> Ben
> 
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Rob Stradling
> Sent: Tuesday, March 26, 2013 9:42 AM
> To: ben at digicert.com
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates
> Proposal
> 
> "the CA SHALL ensure that the Subscriber staples the OCSP response"
> 
> I can imagine that some CAs will want to proactively help Subscribers
> to configure stapling, but I don't see why this needs to be a "SHALL".
> 
> On 26/03/13 13:34, Ben Wilson wrote:
> > Without prematurely cutting off debate, what if the short-lived
> > language were to be removed from subsection (3)(C) of appendix B in
> > the proposed amendment?  Would we then have consensus on at least the
> > following temporary fixes for OCSP stapling in the Baseline
> > Requirements?  Let's not make the "perfect" the enemy of the "good,"
> > and let's at least lay some groundwork for future developments in
> this
> area.
> >
> > To recap, the second paragraph of section 13.2.1 of the Baseline
> > Requirements would be amended to read,
> >
> > "A CA MAY rely on stapling, in accordance with [RFC4366], to
> > distribute its OCSP responses.  A CA MAY include the CA / Browser
> > Forum's mustStaple certificate extension OID (2.23.140.16.1) in the
> > Certificate.  If the CA includes the mustStaple extension in the
> > Certificate, then the CA SHALL ensure that the Subscriber staples the
> > OCSP response for the Certificate in its TLS handshake.  The CA SHALL
> > enforce this requirement on the Subscriber either contractually,
> > through the Subscriber Agreement or Terms of Use, or by technical
> > review
> measures implemented by the CA."
> >
> > Subsections (2)C. and (3)C. of Appendix B
> (authorityInformationAccess)
> > would be revised by deleting the phrase "With the exception of
> > stapling, which is noted below"  and deleting "See Section 13.2.1 for
> > details." and finally also deleting "The HTTP URL of the Issuing CA's
> > OCSP responder MAY be omitted, provided that the Subscriber 'staples'
> > the OCSP response for the Certificate in its TLS handshakes
> [RFC4366]."
> >
> > Thanks,
> >
> > Ben
> >
> >
> > -----Original Message-----
> > From: public-bounces at cabforum.org [mailto:public-
> bounces at cabforum.org]
> > On Behalf Of Robert Relyea
> > Sent: Monday, March 25, 2013 5:25 PM
> > To: public at cabforum.org
> > Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates
> > Proposal
> >
> > On 03/25/2013 03:42 AM, Yngve N. Pettersen wrote:
> >> On Mon, 25 Mar 2013 11:37:15 +0100, Gervase Markham
> >> <gerv at mozilla.org>
> >> wrote:
> >>
> >>> On 23/03/13 05:23, Ryan Sleevi wrote:
> >>>> If the CA has issued a valid, signed OCSP response, then they have
> >>>> no ability to revoke that certificate for any client that supports
> >>>> stapling, until that OCSP response expires.
> >>> And if I were an attacker, the very first thing I'd go, on
> obtaining
> >>> my dodgy cert, would be to grab a valid OCSP response for it so I
> >>> had that in the bank too.
> >> This is the reason why I would have preferred that OCSP stapled
> >> responses had a freshness requirement, meaning that they would have
> >> to be refetched (and regenerated) every few hours, no matter that it
> >> is nominally valid for days.
> >>
> >
> > The only date that the client can rely on for 'how fresh is this' is
> > the date on the OCSP response. Any OCSP response can come from
> > multiple sources, and the date that we actually 'fetched' the
> response
> > is irrelevant. The client can't tell if the server has refetched the
> > OCSP response or not unless the OCSP response has a fresher date in
> > the
> signed response.
> >
> > Any plan that assumes the client records or cares when the last time
> > it fetched a response is irrelevant. This whole matter is in the
> hands
> > of the CA issuing the OCSP response. If the response is issued to be
> > valid for 7 days, it would be extremely difficult for the CA to
> > confidently revoke the cert  before the end of the 7 days. Yes many,
> > even most users will see the revoked response, but a user under
> active
> > attack won't see the response until the end of the 7 days (as rsleevi
> > has
> clearly pointed out).
> >
> > bob
> >
> >
> > _______________________________________________
> > 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.
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130326/be33e234/attachment.bin 


More information about the Public mailing list