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

[Phillip]

The original reason for going with the policy design was to get the camel's nose inside the PKIX tent.

That purpose being gone we could have multiple OIDs but I prefer just one place for clients to look.

As far as scope goes it seems pretty clear that we don't want to throw every possible policy in there. We want to only put the policies in the cert that make sense. In particular I think limiting the scope to statements that the server can enforce all on its own seems pretty good. The server knows if it has OCSP stapling turned on, it can tell the admin that turning it off will require a new cert (so a customer support call there to ask for a replacement). The server knows the versions it supports as well.


I do not like the idea of putting instructions for client processing into the same OID, in fact I think they are much better expressed in other channels as Jeff Hodges is doing in HTTP and as I have proposed doing in DNS. I am not really keen on the server telling the client what to do either. I think the server should say something like 'hey I am a big phishing target, take care' and let browsers decide how best to protect the user.

For some reason my new draft does not seem to have appeared. Looks like I messed up with the submitterator somewhere. I am investigating.


On Oct 3, 2012, at 11:36 AM, Paul Tiemann wrote:

> 
> On Oct 3, 2012, at 8:18 AM, Adam Langley wrote:
> 
>> On Wed, Oct 3, 2012 at 9:37 AM, Paul Tiemann
>> <paul.tiemann.usenet at gmail.com> wrote:
>>> 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.
>> 
>> That is what the semantics of the extension will be, so I believe that
>> mustStaple accurately reflects that.
> 
> What happens in those cases where a server that does support stapling happens to not staple its response?  
> 
> Will the very first nginx SSL handshake for each nginx worker get rejected for the unlucky client who tries visiting the site?  An nginx server with 16 worker processes will give out 16 SSL handshakes without a staple for each SSL certificate configured.  
> 
>>> 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)
>> 
>> We already have a mechanism in place for extensions in a certificate.
>> Grouping these things together doesn't provide much benefit, but does
>> mean more complexity cost. The AIA extension is a good example: OCSP
>> responder and CA certificate pointers should have been separate X.509
>> extensions, allowing the generic X.509 parser to do the work. Grouping
>> them together just caused more code and hardly even makes sense: AIA
>> vaguely contains "external stuff to do with the issuing certificate",
>> but then doesn't include, say, the CPS or CRL pointers.
> 
> If you make just one 'Certificate Handling Policies' extension, eventually all 
> "Cert Viewer" tools will at least know what to call it at some point in the 
> distant future.  
> 
> If you introduce a new top-level extension for each of these needs, then 
> certificate viewers may never be able to catch up.  Imagine a certificate
> with half a dozen "Unknown Extensions" appearing to the curious user,
> and what kind of consternation that will cause (and support calls to CAs)
> 
> The MS cert viewer shows critical extensions with a yellow warning triangle 
> containing exclamation point -- that causes weekly support questions.
> 
> I don't think AIA is hard to parse.  In fact, why not just put the mustStaple
> OID into the AIA itself?  Then you don't have to worry about the problem of
> the "Unknown Extension" in viewers.
> 
> Cheers,
> 
> Paul Tiemann
> CTO, DigiCert, Inc.
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public