[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[Ben Wilson]

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