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

[Paul Tiemann]

On Oct 3, 2012, at 11:10 AM, Adam Langley wrote:

> 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 this not guarantee that only 0.0001% of server operators will opt to put 'mustStaple' into their certificate?

I'm not aware if there are deep technical "known issues" as well for other platforms that support stapling, like IIS.

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

Sounds more likely to me that people will avoid mustStaple.  What do they stand to gain?  A certificate with an increased chance of spectacular failure if any one of a series of dependencies fails, some of which will be outside their control?  

In the case of nginx startup: I don't know if we could guarantee that each of the 16 wgets will be received by a different worker process.

Outside of this Nginx example, there may be a dozen other conditions that could keep a server from being able to fetch or refresh its OCSP response.

Example: Block access between the server and its OCSP responder (poison DNS, get in between, etc) and now clients can't access the site at all, even though the OCSP responder is perfectly capable of serving responses to the clients if they would only check.

Before failing, why not just check the OCSP responder, understanding that this is only going to happen in rare cases?  

If worried about cases where mustStaple gets used to force OCSP checking in Chrome even on servers that don't support stapling, what about some anonymous statistics gathering mechanism so it can be watched?

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

Fair enough, so don't put it in AIA and make a new top-level extension 
that does make sense for storing all these upcoming identifiers.

That's still better (though perhaps only to my mind) than creating a half-dozen new top-level 
extensions that all share a related theme.

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

This may all be moot if we design a system which encourages nobody to use it (reference to above)

> I can't accept that we shouldn't use X.509 extensions
> until all viewing software has been updated.

I'm not claiming that at all, only that I'd prefer for the world of SSL clients to only have to "learn" the name of one top-level extension so that we don't have to tell people to hunt through hex dumps for as long as we will if we invent a new top-level extension for each new cert handling statement we want to codify into certs.

Cheers,

Paul