Re: [certid] CN-ID and name constraints

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: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On Behalf
Of
> Peter Saint-Andre
> Sent: Wednesday, September 29, 2010 2:38 PM
> To: Matt McCutchen
> Cc: certid@ietf.org
> 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
> certid@ietf.org
> https://www.ietf.org/mailman/listinfo/certid