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

Paul Tiemann paul.tiemann.usenet at gmail.com
Wed Oct 3 18:21:01 UTC 2012


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

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

That may be the case, but SSL is already confusing enough for admins who are trying to figure out what's in their certs.

> 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 think we ran this past some of the PKIX folks and they said that the Certificate Policies extension was for policies which define the validation criteria that must be achieved before issuing the certificate.  

Personally though, I would prefer to see a mustStaple oid thrown into Certificate Policies than as a new top-level extension.  

Cheers,

Paul

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




More information about the Public mailing list