Subject: What is the right list name

From: Cullen Jennings <[email-masked]>
Date: Sat, 3 Feb 2007 10:14:43 -0800

A bunch of stuff sent to [email-masked] seems to be being  
forwarded to [email-masked]. This just seems like a recipe for  
confusion - can someone stop it ?

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 3 Feb 2007 13:14:24 -0800

Paul H followed up with me on this. Thanks, Cullen

---

From: Milan Sova <[email-masked]>
Date: Tue, 13 Feb 2007 00:02:13 +0100

On 30.01.2007 01:43, Milan Sova wrote:
> Russ Housley wrote:
> 
>> Going forward, I see two possible ways to go forward:
>>
>> 1) Revisit the uri choice, and see if people think URNs ought to be
>> permitted.  One obvious question is to determine whether existing
>> implementations would fail badly if a URN was received here.
>>
>> 2) Define a way to carry URNs in an other name.
>>
> 
> 	I would very much prefer 1). The URI seems to be the natural place for
> URNs. I don't expect any reasonable implementations to fail, but let's
> find out.
> 	BTW X.509 (08/2005) still uses RFC 1630 (mentioning URNs) as the
> reference for the uniformResourceIdentifier.
>

	As the group does not seem to have a strong opinion of the choices I
propose to include the following text just after the URI part of the
section 4.2.1.6  Subject Alternative Name:

"When the subjectAltName extension contains a URN, the name MUST be
stored in the uniformResourceIdentifier (IA5String).  The name MUST
follow the URN syntax and encoding rules specified in [RFC 2141]."

	Comments?

-- 
						Milan Sova

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Feb 2007 22:11:10 +0000

For clarification:

The UPN (Universal Principal Name) is a Microsoft defined name form, used to identify users in Active Directory in the form user@domain
Microsoft has defined an otherName subjAltName to store UPNs in certificates.

The OID for this name form is "1.3.6.1.4.1.311.20.2.3"
The blob is decoded as a UTF-8 string.

As Dave noted, this has nothing to do with URNs.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of David Simonetti
> Sent: den 31 januari 2007 09:51
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: URN in subjectAltName
>
>
> Russ,
>
> We're using Active Directory UPNs, not URNs.  I was wondering why this
> was
> a big deal.
>
> Dave S.
>
> >
> > David:
> >
> > Can you document what you are doing so that everyone that needs a URN
> > can do it the same way?
> >
> > Russ
> >
> >
> > At 09:31 AM 1/30/2007, David Simonetti wrote:
> >>A US Federal agency which I support is planning on using the
> otherName
> >>field to convey the URN.  This agency is issuing more than 80,000
> >>certificates.  I think use of URN more be more prevelant with those
> >>implementing Active Directory than is realized.
> >>
> >>I believe defining URN via otherName is sufficient.  We're conveying
> it
> >> as
> >>a UTF8String.
> >>
> >>Dave S.
> >>
> >> >
> >> > At 2:16 AM -0500 1/28/07, Russ Housley wrote:
> >> >>At the time that RFC 2459 was written, URLs were the only things
> >> >>mature enough to include here.  No one asked this question during
> >> >>the update to RFC 2459, which resulted in RFC 3280.
> >> >>
> >> > This seems like overkill given the low usage of URNs as
> identifiers
> >> > that are associated with public keys.
> >> >
> >> > Anders and I have suggested two legal ways to do this already.
> >> >
> >> > --Paul Hoffman, Director
> >> > --VPN Consortium
> >> >
> >> >
> >>
> >>
> >>--
> >>Regards,
> >>David Simonetti
> >>Jacob & Sundstrom, Inc.
> >>410-356-1067
> >
> >
>
>
> --
> Regards,
> David Simonetti
> Jacob & Sundstrom, Inc.
> 410-356-1067

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Feb 2007 17:35:55 -0800

>follow the URN syntax and encoding rules specified in [RFC 2141]."

This seems like a good addition, seeing as there were multiple 
choices given on the mailing list, and that means interoperability 
issues. Note that there are two paragraphs to the "URI part"; this 
should be added after the second paragraph, just before "When the 
subjectAltName extension contains a DN...".

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Feb 2007 13:43:35 -0500

>subjectAltName extension contains a DN...".

I thought that sever people expressed concern that implementations 
that follow RFC 3280 will only expect a URL, so the URN ought to be 
encoded in other name.  It would be a very simple (one page) specification.

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 14 Feb 2007 15:04:03 -0500

All,

I don't know very much about URIs, and I don't really have an opinion 
about what the subjectAltName section of 3280bis should say about URIs.  
My only concern is to ensure that the document is completed soon and 
that it is correct.

The latest version of idnits pointed out that RFC 1738 has been 
obsoleted, and while 3280bis still points to RFC 1738 as the 
specification for the HTTP URI syntax, I changed the text in the 
subjectAltName section to point to RFC 3986 (Uniform Resource Identifier 
(URI): Generic Syntax).  So, the relevant text now reads:

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST NOT be a relative URL, and it MUST follow the URL syntax and
      encoding rules specified in [RFC 3986].  The name MUST include both a
      scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
      scheme-specific-part MUST include a fully qualified domain name or IP
      address as the host.  Rules for encoding internationalized resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part may
      be case-sensitive.  Rules for comparing URIs are specified in section
      7.4.

While RFC 2141 is not listed as having been updated or obsoleted by any 
other RFCs, section 1.1.3 of RFC 3986 states:

      A URI can be further classified as a locator, a name, or both.  The
      term "Uniform Resource Locator" (URL) refers to the subset of URIs
      that, in addition to identifying a resource, provide a means of
      locating the resource by describing its primary access mechanism
      (e.g., its network "location").  The term "Uniform Resource Name"
      (URN) has been used historically to refer to both URIs under the
      "urn" scheme [RFC2141], which are required to remain globally unique
      and persistent even when the resource ceases to exist or becomes
      unavailable, and to any other URI with the properties of a name.

      An individual scheme does not have to be classified as being just one
      of "name" or "locator".  Instances of URIs from any given scheme may
      have the characteristics of names or locators or both, often
      depending on the persistence and care in the assignment of
      identifiers by the naming authority, rather than on any quality of
      the scheme.  Future specifications and related documentation should
      use the general term "URI" rather than the more restrictive terms
      "URL" and "URN" [RFC3305].

As I read this, the use of the term "Uniform Resource Name" is not 
limited to URIs that conform to the "urn" scheme in RFC 2141 and it is 
now recommended that specifications not try to distinguish between 
different types of URIs.

As I read the proposal below, it is recommending that 3280bis state that 
the uniformResourceIdentifier may be used to contain a name that 
conforms to the "urn" scheme of RFC 2141, but that all other URIs that 
are placed in uniformResourceIdentifier must conform to the rules 
specified in RFC 3280.  Is that correct and is it intentional?  If not, 
and it is agreed that 3280bis should allow for the inclusion in the 
subjectAltName extension of URIs that do not include host names, would 
it better to simply remove the text that specifies this requirement so 
that the text would read:

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST follow the URI syntax and encoding rules specified in [RFC 3986].
      The name MUST include both a scheme (e.g., "http" or "ftp") and a
      scheme-specific-part.  Rules for encoding internationalized resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part may
      be case-sensitive.  Rules for comparing URIs are specified in section
      7.4.

Note that 3280bis currently allows for the inclusion of LDAP URIs 
without host names in the cRLDistributionPoints, authorityInfoAccess, 
and subjectInfoAccess extensions?  Although it should also be noted that 
3280bis only provides a way for imposing name constraints on URIs that 
include a DNS name.  As I read this, any names that are placed in the 
uniformResourceIdentifier name form that do not contain DNS names are 
unconstrained, regardless of the contents of nameConstraints extensions 
in other certificates in the path, which would seem to argue against 
allowing such names to be placed in the uniformResourceIdentifier name form.

Dave

Paul Hoffman wrote:
> This seems like a good addition, seeing as there were multiple choices 
> given on the mailing list, and that means interoperability issues. 
> Note that there are two paragraphs to the "URI part"; this should be 
> added after the second paragraph, just before "When the subjectAltName 
> extension contains a DN...".
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Feb 2007 12:47:27 -0800

At 1:43 PM -0500 2/14/07, Russ Housley wrote:
>encoded in other name.

I don't know which server people those are, but there is nothing in 
RFC 3280 or 3280bis that would make me think "this is a URL and not a 
URI".

>It would be a very simple (one page) specification.

That's true, but there is no reason not to make it part of the only 
specification that most implementers will read. I still support 
putting it into 3280bis to encourage interoperability.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 14 Feb 2007 13:18:20 -0800

David,

I do not know much about URI also, but the following statement bothers
me: 

"Note that 3280bis currently allows for the inclusion of LDAP URIs
without host names in the cRLDistributionPoints, authorityInfoAccess,
and subjectInfoAccess extensions?"

I suspect it will break many applications that invoke the URI to obtain
the certificates and CRLs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Wednesday, February 14, 2007 3:04 PM
To: pkix
Subject: Re: URN in subjectAltName

All,

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST NOT be a relative URL, and it MUST follow the URL syntax and
      encoding rules specified in [RFC 3986].  The name MUST include
both a
      scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
      scheme-specific-part MUST include a fully qualified domain name or
IP
      address as the host.  Rules for encoding internationalized
resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part
may
      be case-sensitive.  Rules for comparing URIs are specified in
section
      7.4.

      A URI can be further classified as a locator, a name, or both.
The
      term "Uniform Resource Locator" (URL) refers to the subset of URIs
      that, in addition to identifying a resource, provide a means of
      locating the resource by describing its primary access mechanism
      (e.g., its network "location").  The term "Uniform Resource Name"
      (URN) has been used historically to refer to both URIs under the
      "urn" scheme [RFC2141], which are required to remain globally
unique
      and persistent even when the resource ceases to exist or becomes
      unavailable, and to any other URI with the properties of a name.

      An individual scheme does not have to be classified as being just
one
      of "name" or "locator".  Instances of URIs from any given scheme
may
      have the characteristics of names or locators or both, often
      depending on the persistence and care in the assignment of
      identifiers by the naming authority, rather than on any quality of
      the scheme.  Future specifications and related documentation
should
      use the general term "URI" rather than the more restrictive terms
      "URL" and "URN" [RFC3305].

      When the subjectAltName extension contains a URI, the name MUST be
      stored in the uniformResourceIdentifier (an IA5String).  The name
      MUST follow the URI syntax and encoding rules specified in [RFC
3986].
      The name MUST include both a scheme (e.g., "http" or "ftp") and a
      scheme-specific-part.  Rules for encoding internationalized
resource
      identifiers (IRIs) are specified in section 7.4.

      As specified in [RFC 3986], the scheme name is not case-sensitive
      (e.g., "http" is equivalent to "HTTP").  The host part is also not
      case-sensitive, but other components of the scheme-specific-part
may
      be case-sensitive.  Rules for comparing URIs are specified in
section
      7.4.

allowing such names to be placed in the uniformResourceIdentifier name
form.

Dave

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Feb 2007 16:19:13 -0500

Ooops: s/server/several/

RFC 3280 says:

    encoding rules specified in [RFC 1738].  The name MUST include both a
    address as the host.

    As specified in [RFC 1738], the scheme name is not case-sensitive
    (e.g., "http" is equivalent to "HTTP").  The host part is also not
    case-sensitive, but other components of the scheme-specific-part may
    be case-sensitive.  When comparing URIs, conforming implementations
    MUST compare the scheme and host without regard to case, but assume
    the remainder of the scheme-specific-part is case sensitive.

I think this prohibits the use of a URN like this:

    URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN

Russ

At 03:47 PM 2/14/2007, Paul Hoffman wrote:
>RFC 3280 or 3280bis that would make me think "this is a URL and not a URI".
>

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 15 Feb 2007 13:50:56 +0100

>    URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN

Indeed. But is there any problem allowing the URN scheme? We
are taking about not allowing a "universal resource name" as a name.

I think that subjectAltname should simply not make any restriction for
filling an URI according to RFC 3986, in order to keep the
explanations and rules for URLs, I propose to change:

"When the subjectAltName extension contains a URI, the name MUST be
   stored in the uniformResourceIdentifier (an IA5String). If the name
   is an URL, it MUST NOT be a relative URL, and it MUST follow the URL 
syntax and
   encoding rules specified in [RFC 1738].  The URL MUST include both a
   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
   scheme-specific-part of an URL MUST include a fully qualified domain 
name or IP
   address as the host.

   be case-sensitive.  When comparing URLs, conforming implementations

   If the URI is a URN, conforming implementations MUST follow the rules
   of [RFC 2141] when comparing them, i.e. treating the string "urn:" and
   the NID as case insensitive.  Implementations SHOULD  use the same
   case when setting URNs.

   Since internet emeil addresses are stored using the RFC822address
   alternative of GeneralName, the "mailto:" scheme SHALL not be used."

The usage of GeneralName in CRLdistributions points etc is not affected but
this change.

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Feb 2007 12:47:44 -0500

Peter:

RFC 3280 does not allow a URN.  It requires a URL.  The changes you 
suggest are not backward compatible.  That is my concern.

Russ

>   is an URL, it MUST NOT be a relative URL, and it MUST follow the 
> URL syntax and
>   scheme-specific-part of an URL MUST include a fully qualified 
> domain name or IP
>   address as the host.
>

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 15 Feb 2007 19:37:41 +0100

> suggest are not backward compatible. That is my concern.
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?

As far as I remember the request was made to allow urn: in
new contexts anyway, such certificates may (in theorie) not
be usable in old applications, I'd still like to see one.

regards

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Feb 2007 13:31:36 -0800

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...

>and furthermore that rejects if the content doesn't conform

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: Sun, 18 Feb 2007 18:45:12 +0100

Putting urn into the uri choice is legal in X.509.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 18 Feb 2007 10:16:50 -0800

>Putting urn into the uri choice is legal in X.509.

I am not questioning that. As Russ has pointed out, however, RFC 3280 
made it so that PKIX certificates do not allow that because they 
force the URI to have a hostname.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Norman <[email-masked]>
Date: Sun, 18 Feb 2007 14:28:51 -0600

> encoded in other name.  It would be a very simple (one page) 

I can certainly believe that the OpenID community would want to put
user's "identity URL" in here.  That argues for it being something
that is at least resolvable.

Eric Norman