Re: [certid] CN-ID and name constraints

[Peter Saint-Andre <[e-mail]>]

On 9/25/10 3:32 PM, Matt McCutchen wrote:

Cutting to the chase...

> I propose that section 4.4.4 be changed as follows:
> 
> Old: "...the client MAY as a fallback check for a string whose form
> matches that of a fully-qualified DNS domain name in the CN-ID."
> 
> New: "...the client MAY as a fallback check for a string whose form
> matches that of a fully-qualified DNS domain name in the CN-ID, provided
> that this domain name satisfies any name constraints on the
> certification path as defined by [PKIX] section 4.2.1.10."

Thank you for proposing text.

Given that the server-id-check document is downstream from RFC 5280,
it's not clear to me why we need to mention that name constraints apply.
I'm especially wondering why this spec would mention name constraints
with respect to CN-IDs but not with respect to DNS-IDs, URI-IDs, or
SRV-IDs, given that Section 4.2.1.10 of RFC 5280 states in part:

   The name constraints extension, which MUST be used only in a CA
   certificate, indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located.
   Restrictions apply to the subject distinguished name and apply to
   subject alternative names.

RFC 4985 explicitly mentions name constraints with respect to SRVNames,
but that makes sense because it is defining a new name form for the
subjectAltName extension of type otherName, which is not mentioned in
RFC 3280 / RFC 5280, as mentioned in RFC 5280:

   The syntax and semantics for name constraints for otherName,
   ediPartyName, and registeredID are not defined by this specification,
   however, syntax and semantics for name constraints for other name
   forms may be specified in other documents.

Thus I think this is out of scope for the server-id-check document, but
I'm open to being convinced otherwise (and I'm not yet sure whether my
co-author agrees with me).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/