Subject: Re: [pkix] Criticality of Name Constraints in 5280

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Apr 2012 21:11:37 -0400

At 8:51 PM +0200 3/30/12, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  At 4:46 PM -0400 3/29/12, Adam Langley wrote:
>>  >...
>>  >
>>  >I mean that I've not encountered any path validation software that
>>  >requires that a name constraint, when present, to be critical. If
>>  >anybody knows otherwise, I'm sure Rob would be interested to hear
>>  >about it.
>>
>>  Adam, I applaud your interest in using NameConstraints to improve secruity
>>  relative to the browser public TA trust model.
>
>I'm a little confused.  The endpoint identification performed with the
>"browser public TA trust model" is based on DNS names rather than on
>distinguished directory names.

I had to read the next paragraph to figure out what point you were 
making above. Over time, there have been three ways to provide a 
browser with DNS name info for comparison against a target URL:
	- a Netscape extension
	- embedding the DNS name in the CN field of a DN
	- Subject alt name of type DNS

The first option is independent of name constraints, the final one 
works with name constraints. The middle option would be subject to 
the extension, but not in a useful way for this problem.

>  > The concern is that RPs might not follow 5280 (and its 2 predecessor
>  > cert & CRL profile RFCs) re support of this extension.
>
>rfc5280 and its predecessors "require" support for name constraints
>*ONLY* on the directory name.  Support for name constraints on
>subjectAltNames (those that are typically used for server endpoint
>identification performed with the "browser public TA trust model"
>is _not_ required, only recommended.  So rfc5280 compliance
>seem not to help here at all, see last paragraph here:

yes, this is a SHOULD, not a MUST. But if you look at the definition of SHOULD
and consider the context in question (browsers) it seems to me that this is
a context in which support ought to be present.

>   http://tools.ietf.org/html/rfc5280#page-40
>
>Looking at *real* existing certs, like the one presented by
>"https://www.google.pl" when connecting with *NO* TLS extension SNI,
>contains 436 subject alt names of type DNSName, all different.

as others have noted, this is not a valid example relative to this discussion.

>If that cert would have to be equipped with subject alt name constraints
>for each and every of those names, it would probably grow much larger
>than 16 KByte and cause a number of TLS clients to abort the handshake
>due to the size of the server certificate...

no, for the reasons cited by others.

Steve