Peter, It was my understanding of this that the request was that the DNS name constraints be applied to a CN-ID that is being treated as a DN. This would not be standard 5280 behavior.
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Peter Saint-Andre > Sent: Wednesday, September 29, 2010 2:38 PM > To: Matt McCutchen > Cc: [email protected] > Subject: Re: [certid] CN-ID and name constraints > > 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/ > > > _______________________________________________ > certid mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/certid _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
