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

Ryan Hurst ryan.hurst at globalsign.com
Wed Oct 3 10:07:22 MST 2012


Phillip,

It does support fetching on startup there is the edge case however where it
will not be able to fetch a response and one has not already been cached on
the server.

Paul likely remembers more than I but I think it is also possible to
configure to fail to start in those cases as well.

Ryan
-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Phillip
Sent: Wednesday, October 03, 2012 9:14 AM
To: Paul Tiemann
Cc: public at cabforum.org
Subject: Re: [cabfpub] Fwd: Re: [cabfrev] Must Staple Draft

Why does nginx do that?

If it supports stapling, won't it pull the ocsp token during startup when it
is configuring the cert and getting the key and such?

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

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public



More information about the Public mailing list