Subject: URN in subjectAltName

From: Milan Sova <[email-masked]>
Date: Fri, 26 Jan 2007 01:25:10 +0100

Hi.

	In our project, we mark end entities with URNs and need to include
these names in the certificates. We started with using
subjectAltName.URI field for this (as URN is a "subtype" of URI).
However, this practice clashes with RFC 3280 which explicitly requires
absolute URL for the field.

	Is there any specific reason for excluding URNs from subjectAltName?

	Regards
-- 
						Milan Sova

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 Jan 2007 08:41:39 -0800

>	Is there any specific reason for excluding URNs from subjectAltName?

Yes, but it is not a good one in my opinion. The URI use in 
subjectAltName is only meant to be a host computer reach by a 
protocol, not a vanilla identifier such as a URN. Thus, there is the 
restriction that there has to be a host name.

If you want a URN, you should consider using otherName instead. This, 
of course, shows the silliness of the specificity of the 
uniformResourceIdentifier type, but it is needed if you want to 
follow 3280.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 27 Jan 2007 10:06:14 +0100

Hi
You can put whatever you want including URNs in a serialNumber attribute.
I would though also consider using a scheme where you separate the identity
part from the authority/registry.  Like if your URN is:

         serialNumber=urn:com:example:id:3456

 you might as well use something like:

    serialNumber=<guid registry="urn:com:example:id">3456</guid>

[some "-mangling removed for brevity]
which has the advantage that it is a universal XML-ish way of specifying
a globally unique id where you don't have to know how the registry part
is constructed in order to get the id.  Although true URNs are cool, I
would still not rule out using HTTP URIs because then the registry part
would typically point to a web-page showing data associated with the
identity name space.

Anders

----- Original Message ----- 
From: "Milan Sova" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 26, 2007 01:25
Subject: URN in subjectAltName

Hi.

Regards
-- 
Milan Sova

---

From: Russ Housley <[email-masked]>
Date: Sun, 28 Jan 2007 02:16:21 -0500

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.

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.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 28 Jan 2007 20:39:20 -0800

At 2:16 AM -0500 1/28/07, Russ Housley wrote:
>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.

>2) Define a way to carry URNs in an other name.

Anders and I have suggested two legal ways to do this already.

--Paul Hoffman, Director
--VPN Consortium

---

From: Milan Sova <[email-masked]>
Date: Tue, 30 Jan 2007 01:43:03 +0100

Hi Anders.
> You can put whatever you want including URNs in a serialNumber attribute.

	Yes. But we've already decided to move the URN out of the certificate
subject for a couple of reasons.

[...]

> Although true URNs are cool, I

	You're right again. But our naming system is already built on URNs. And
we are looking for a way to include them in certificates which would be
acceptable by a common CA.

	Regards
-- 
						Milan Sova

---

From: Milan Sova <[email-masked]>
Date: Tue, 30 Jan 2007 01:43:56 +0100

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

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

	Regards
-- 
						Milan Sova

---

From: Milan Sova <[email-masked]>
Date: Tue, 30 Jan 2007 01:47:19 +0100

Paul Hoffman wrote:
> This seems like overkill given the low usage of URNs as identifiers that
> are associated with public keys.

	Couldn't it be a kind of a chicken-egg problem?
> Anders and I have suggested two legal ways to do this already.

	I'm not sure I consider storing URNs in X502SerialNumber fully legal.
IMO there is/should be a difference in how a CA verifies those two
pieces of information.

	In principle, I'm not against using a subjectAltName.otherName.URN if
it was standardized. I'd prefer the URI  as a more natural place, though.

	Regards
-- 
						Milan Sova

---

From: "David Simonetti" <[email-masked]>
Date: Tue, 30 Jan 2007 09:31:13 -0500 (EST)

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.

-- 
Regards,
David Simonetti
Jacob & Sundstrom, Inc.
410-356-1067

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Jan 2007 19:59:52 -0500

David:

Can you document what you are doing so that everyone that needs a URN 
can do it the same way?

Russ

---

From: "David Simonetti" <[email-masked]>
Date: Wed, 31 Jan 2007 12:51:19 -0500 (EST)

Russ,

We're using Active Directory UPNs, not URNs.  I was wondering why this was
a big deal.

Dave S.

-- 
Regards,
David Simonetti
Jacob & Sundstrom, Inc.
410-356-1067