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

[Rob Stradling]

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