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

[Ryan Hurst]

I feel the same, frankly i think a null extension would be suficient.

Sent from my iPhone

On Oct 3, 2012, at 6:01 AM, Ryan Sleevi <sleevi at google.com> 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 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.
> 
> 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 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 ;-) ).
>> 
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> _______________________________________________
>> Revocation mailing list
>> Revocation at cabforum.org
>> http://cabforum.org/mailman/listinfo/revocation
>> 
>> 
>> 
>> _______________________________________________
>> 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