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

[Ryan Sleevi]

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