Subject: Q: re: subjectAlternativeName URI encoding.

From: Timothy J Miller <[email-masked]>
Date: Fri, 8 Feb 2008 12:52:41 -0600

3280, 4.2.1.7 says:

"""
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 1738].  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.

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

A URI may be a URL *or* a URN, and URN can be effectively anything at  
all--i.e., a URN scheme-specific part need not contain a FQDN.   
3280's language here would seem to prohibit a SAN like, frex,  
"urn:isbn:0451450523", or "urn:uuid:67ea2e2a-677f-4be3- 
b667-26eb1ab21ecf", both of which are perfectly legal URIs (ref.  
RFC4122 for UUID URN namespace).

Coincidentally, this is exactly what I want to do: I want to put  
UUIDs in certs, and SAN would be the natural place.  And I'd rather  
not have to define my own otherName.

As it's currently formulated, 4.2.1.7 is limited to URLs only.  Which  
doesn't seem to be particularly as useful, especially when I have  
millions of devices to name and issue certs.

So the question is: Is the SAN URI type intended to allow arbitrary  
URI, including URNs?

-- Tim

---

From: Russ Housley <[email-masked]>
Date: Sat, 09 Feb 2008 15:17:57 -0500

I wish that X.509 had not put URLs and URNs in the same name 
form.  It seems to me that name constraints for them are quite different.

Russ