Subject: RE: URN in subjectAltName

From: Stefan Santesson <[email-masked]>
Date: Fri, 2 Mar 2007 13:55:37 +0000

Catching up on this after having escaped on ski vacation last week.

I agree with Russ and Paul here in the sense that allowing URN in the PKIX profile using the URI alt name is problematic.
It is problematic in particular with respect to the rules of name constraining in section 4.2.1.10

I do however object to defining a new othername in rfc3280bis. I have respect for the task of defining a new otherName (by personal experience), and it is not reasonable to hold 3280bis for this issue.

If there is a real need to accommodate URN within the internet X.509 profile, then we should solve that separately.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 15 februari 2007 22:32
> To: [email-masked]
> Subject: Re: URN in subjectAltName
>
>
> At 12:47 PM -0500 2/15/07, Russ Housley wrote:
> >Peter:
> >
> >RFC 3280 does not allow a URN.  It requires a URL.
>
> Unfortunately, I now agree with Russ. RFC 3280 makes it clear that
> the URI MUST have a FQDN in it. We blew it, but it's not fatal for
> this purpose.
>
> >The changes you suggest are not backward compatible.  That is my
> concern.
>
> And my concern as well, regardless of...
>
> At 7:37 PM +0100 2/15/07, Peter Sylvester wrote:
> >Yes, but do you know any implementation that rejects a certificat?
> >i.e. one that allows any URL scheme and just rejects urn:,
> >and furthermore that rejects if the content doesn't conform
> >to the URL syntaxes?
>
> It doesn't matter if we know it or not; it matters if we are negating
> something that we made mandatory in RFC 3280.
>
> So, instead of trying to make URNs work in uniformResourceIdentifier,
> we should just put it in an OtherName with its own OID. I propose the
> following be added instead of Milan's proposal:
>
> When the subjectAltName extension contains a URN, the name MUST be
> stored in the otherName (IA5String).  The OID used MUST be:
>     id-on-URN                 OBJECT IDENTIFIER ::= { id-on TBD }
> The name MUST follow the URN syntax and encoding rules specified in
> [RFC 2141].
>
> (For those of you not familiar with the id-pkix tree, see
> <http://www.imc.org/ietf-pkix/pkix-oid.asn>.)
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 02 Mar 2007 17:30:03 +0100

> It is problematic in particular with respect to the rules of name constraining in section 4.2.1.10
IMO: If an URI does not contain a host, then permitted subtree match 
will fail,
excluded subtree match will succeed

BTW: http://localhost is not allwed but http://127.0.0.1 is allowed ?

> I do however object to defining a new othername in rfc3280bis. I have respect for the task of defining a new otherName (by personal experience), and it is not reasonable to hold 3280bis for this is…
Agree
> If there is a real need to accommodate URN within the internet X.509 profile, then we should solve that separately.
yes.