[cabfpub] Fwd: Re: [cabfrev] Must Staple Draft

Wed Oct 3 13:37:48 UTC 2012

I replied inline below, but one of my thoughts doesn't fit into a reply:

I don't like the name 'mustStaple' all that much because those words imply that the connection should be rejected completely if the client does not receive a staple.  Nginx just released 1.3.7 with stapling support, and it does not give out a stapled response on the first handshake after starting up.  It's conceivable that even servers which staple are not going to serve an OCSP response on rare occasions, and those SSL handshakes should not fail just because the staple was not present, when the actual OCSP responder is online and could provide the OCSP response in those circumstances.

Could it be called something like 'staplingSupported' or 'staplingExpected' or 'shouldStaple' or 'ocspRequired' (whether stapled or online)

<micro-rant>As an example: "Subject Alternative Name" was in my opinion a poor choice of words because it has "optional" written all over it with that big "Alternative" in the middle.  Support for SANs should have been around since the nineties, but in fact there are still problems with SAN support today among certain mobile devices, though they are fewer each year.  A better name could have been found that would have communicated the fact that every client should have had support for this extension from the start.</micro-rant>

Paul Tiemann
CTO, DigiCert, Inc.

On Oct 3, 2012, at 7:01 AM, Ryan Sleevi wrote:

> On Wed, Oct 3, 2012 at 12:42 AM, Rob Stradling <rob.stradling at comodo.com> wrote:
>> On 02/10/12 23:33, Phillip wrote:
>>> I just submitted the draft that I wrote with Rob's input back in May.
>>> 
>>> We started off with just doing 'must staple'. Then when we looked at
>>> the problem in a little more detail we started to see a potential
>>> version downgrade attack on top. So this led to a slightly more
>>> general approach (but not very).
>>> 
>>> http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-01
>> 
>> Phill, back in May I posted some further thoughts (see message below) on
>> what we could do with this extension.  The only feedback was from Eddy,
>> who said "Excellent thoughts!"
>> 
>> So, just in case it's useful...
>> 
>> 
>> -------- Original Message --------
>> Subject: Re: [cabfrev] Must Staple Draft
>> Date: Wed, 18 Apr 2012 11:12:03 +0100
>> From: Rob Stradling <rob.stradling at comodo.com>
>> To: revocation at cabforum.org
>> 
>> On 16/04/12 21:11, Phillip Hallam-Baker wrote:
>>> Once more, with the extraneous stuff dropped
>> 
>> Your draft says:
>> "The extension data is a [boolean? true/false?]"
>> 
>> 
>> On 12/04/12 19:50, Adam Langley wrote:
>>> The idea that I was supporting was an "OCSP stapling required"
>>> extension, which might be different from "require strict revocation
>>> checking" in people's minds.
>> 
>> 
>> I wonder if we maybe need more than just 1 boolean value.
>> 
>> Just brainstorming...
>> 
>> How about a more general purpose "Revocation Checking Capabilities and
>> Preferences" extension in which the CA can assert how it would prefer
>> clients to perform revocation checking?  This could cover all sorts of
>> things like…

I like the idea of an agreed-upon new extension so the main list of extensions
a user has to view in a certificate is kept to a minimum.

Perhaps broaden the extension's scope a little and call it something like 
'Certificate Handling Policies'?

> I would rather see this extension just be used to mandate behaviours
> that server operators can reliably control - such as must staple. I
> feel like introducing mandatory behaviours on clients via this
> extension - such as switching from OCSP to CRLs, mechanism
> preferences, etc - are going to introduce needless complexity and
> overhead to the discussions, let alone the implementations.

An extension that could contain multiple OID values would allow future 
expansion.  Something like how the AIA extension can contain more 
than one item within it (CA Issuer, OCSP responder)

Imagine an extension like 'Certificate Handling Policies' which contains an OID 
advertising OCSP stapling support.  Further down the road if we come up with
more OIDs to add to the list, we add them under the 'Certificate Handling Policies'
extension.

> There is no need to place everything under a single extension. The
> challenge is not in implementing support for an extension - it's in
> reaching consensus for the extension semantics, between both browsers
> and CAs - so that work can actually begin.

I do like the '1 top level extension' idea though, because it keeps the 
certificates cleaner.  We wouldn't have to agree on more than just the 
OID to advertise stapling support.

> I would rather 10 extensions, with 6 being quick, easy, and
> non-controversial, than trying to do 10 features in one extension, and
> never deploy for want of the 4.
> 
>>    - OCSP Stapling: Required or Optional.
>>    - Failure Mode: Soft (silent), Hard (warn, but allow the client to
>> get to the site) or Block (don't let the client get to the site!)
>>    - Preferred Mechanism: OCSP or CRL (or a DNS-based revocation
>> checking protocol, if/when one exists).
>>    - Switch from OCSP to CRL after encountering 50 certs from this
>> Issuer: Yes or No.
>>    - Will the CT proof for this certificate be embedded in an OCSP
>> Response extension: Yes or No.
>>    - Does the CA provide a mechanism for embedding the OCSP Responses
>> for the cert chain's intermediates into an extension in the end-entity
>> cert's OCSP Response?
>>    - Has the client indicated that they intend to host the OCSP
>> Responses for their cert at http://<domain_in_the_cert>/OCSP.bin: Yes or No.
>>    - Does the OCSP Responder support the GET method? Yes or No.
>> 
>> If we're going to the effort of defining and deploying a new certificate
>> extension, let's get the maximum benefit from it (without making it
>> unnecessarily complex, of course ;-) ).

+1 to future growth flexibility.  It may be easier to create one general extension 
now that can have OID values beneath it than to have to make a brand new 
top level extension each time.