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

[Paul Tiemann]

On Oct 3, 2012, at 11:07 AM, Ryan Hurst wrote:

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

I think fetch-on-startup was one of the options they considered but never implemented.

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

It used to fail on startup if 'ssl_stapling on' was specified in the config file and the certificate did not have an OCSP URI in the AIA.

That was changed so it will now log a warning but not block startup.  (Blocking startup would have only served to force the administrator to set 'ssl_stapling off' in order to get the server up and running.)

> 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
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public