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

Ryan Hurst ryan.hurst at globalsign.com
Wed Oct 3 17:27:31 UTC 2012


IMHO a infinitesimally small number of users a actually look at certificate
viewers, this shouldn't be a consideration.

What's important IMHO is that it is obvious and cognitively consistent with
the rest of the policy expression in certs so that the few that do can tell
what's going on.

To me the semantic this represents is best put under certificate policy as
it is an issuance policy, the CA is saying the policy under which this was
issued requires that you do revocation checking on it before relying on it
and I am OK with the consequences associated with it.

I can appreciate browser hesitance to do this in certificate policies given
the complex semantics they contain and as such think the idea of a simple
extension with this semantic is not disagreeable. The key is simple though,
just like we have id-pkix-ocsp-nocheck
(http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-05) having a
id-cabf-ocsp-must-staple seems OK.

Ryan  


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

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




More information about the Public mailing list