[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[Rob Stradling]

"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.