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

[Adam Langley]

On Wed, Oct 3, 2012 at 11:36 AM, Paul Tiemann
<paul.tiemann.usenet at gmail.com> wrote:
> What happens in those cases where a server that does support stapling happens to not staple its response?

A mustStaple certificate must be stapled. If it is not, then it's a
certificate verification failure.

(Whether it's a soft failure, which can be clicked through, I'm not
sure about. By initial inclination would be to make it a hard failure,
as a revocation would be.)

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

Sounds like the first 16 clients are going to have a bad time if the
server is sending a mustStaple cert without stapling. (Or the site
operators add a loop with 16 wgets to the startup script.)

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

Your argument seems to be that we shouldn't add new top-level
extensions because certificate viewers show them as `unknown'. Rather,
we should wedge things into existing extensions because then they'll
be hidden. But then certificate viewers can't be used at all! How is
someone going to figure out if they have a mustStaple certificate if
we can't even tell them to look for a given OID in the viewer? These
viewers show the raw hex dump of the RSA modulus etc, they are clearly
debugging aids. I can't accept that we shouldn't use X.509 extensions
until all viewing software has been updated.


Cheers

AGL