Subject: SAN semantics question

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 28 Jan 2009 14:04:28 -0500

A quick question to inform a discussion I'm having elsewhere:

Is there an intent behind SAN semantics?

Put another way, is it within the intent of the RFC to use an otherName to
add a qualifier to another SAN name type?  E.g., set otherName to { NULL
IDENTIFIED BY some-OID }, where some-OID semantics say something like "The
SAN must include a URI name of <some specific format>."

-- Tim

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 28 Jan 2009 15:54:03 -0500

> SAN must include a URI name of <some specific format>."
Tim,

I do not understand the purpose behind your example, but I don't believe 
that it would be appropriate.  What would be the reason for including a 
statement of the form "the SAN must include a URI ..."?  If a CA, by 
including this information in the certificate is imposing a requirement 
on itself, why would it then issue the certificate with contents that do 
not satisfy the qualifier?  A CA could possibly wish to impose such a 
constraint on certificates that appear later in the certification path, 
but any constraints (or qualifiers) should appear in another extension, 
not the SAN.  The subjectAltName extension should only contain a list of 
names for the subject.

Note that even if the subjectAltName extension is marked critical, the 
relying party is only required to be able to recognize and process at 
least one of the names that appears in the extension and may ignore any 
names with an unrecognized or unsupported name form.  So, if one chose 
to ignore the semantics of the extension and include a qualifier as an 
additional "name", relying parties may ignore the qualifier even if the 
extension is marked critical.

BTW, several name forms have already been defined for inclusion in 
otherName.  Some of these are:

1) Jabber Identifier (RFC 3920)

2) Permanent Identifier (RFC 4043)

3) hardware module name (RFC 4108)

4) KRB5PrincipalName (RFC 4556)

5) service name (RFC 4985)

6) User Principal Name (http://support.microsoft.com/kb/281245)

7) Federal Agency Smart Credential Number (FASC-N) 
(http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf)

Dave

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 28 Jan 2009 16:28:19 -0500

On 1/28/09 3:54 PM, "David A. Cooper" <[email-masked]> wrote:

> statement of the form "the SAN must include a URI ..."?

I was trying to not use the real case and ask a more general question, but
yeah, I see how it would be better to be more concrete.  So:

An project I'm involved with wants to use X.667 UUIDs as subject identifiers
(I dislike using 'names' for non-human-readable values; it helps keep
people's heads clear).  UUIDs may or may not be included in the subject DN;
an argument can be made that the DN should contain a readable name.

One natural place to include UUIDs in a cert is in the SAN as a
uniformResourceIdentifier, using RFC4122 URN syntax.

The discussion is if and how to qualify that identifier.  In part, this is
so it can be constrained--either by application logic in a direct trust
environment, or in validator logic using nameConstraints in a cross-cert
environment.  

Appending a simple namespace identifier to the UUID would work, but would
mean encoding the UUID as an otherName rather than a URI, which some of us
feel should be avoided.

I was thinking that we could define an otherName to encode *only* an
assigner (by OID) without a value, and define the OID semantics to refer to
the URI name type for the value.  This would avoid having the assigned UUID
encoded twice.  Seemed logical enough at the time, but the objection was
raised that this violates the intent of SAN.

I do see a problem if a cert has multiple URIs in the SAN.  Didn't think of
that.  :/

> extension is marked critical.

Good point.  That would apply to some other proposals on the table as well.

> 2) Permanent Identifier (RFC 4043)

I've looked at PI before, and that's of course an option, but has anyone
defined a method to apply nameConstraints to PI?

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Jan 2009 17:18:49 -0500

>SAN must include a URI name of <some specific format>."

My short answer is no. Each SAN type is nominally independent of the 
others, so it would be odd (at best) to have one SAN be used to 
qualify another.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Jan 2009 18:02:41 -0500

Tim,

RFC 5280 limits the types of SANs that a compliant RP need be able to 
process relative to the name constraints extension. OtherName is not 
included. URIs are included, but only the DNS name portion is covered.

RFC 4122 provides a URN syntax, but it does not seem to have the 
structure you seem to want, in order to impose name constraints.  If 
the node value is just a MAC address, there are extant conventions 
for representation of that value employed by DOCSIS and WIMAX folks. 
(I personally think the conventions are awful, but that's another 
matter :-)). If the UUIDs are arbitrary, then I can imagine why you 
might want a qualifier to indicate the UUID assigner.  Frankly, I 
think this is a questionable approach.

The serial number attribute for a DN is a reasonable place to put a 
device ID that is serial-number-like in form, as a series of decimal 
digits.  The UUID can be translated into such a sequence. You could 
use a common name to specify the UUID assigner.  Of course this might 
conflict with other Subject attributes you may plan to use, but since 
you didn't specify what those might be ...

Steve

---

From: Tom Gindin <[email-masked]>
Date: Wed, 28 Jan 2009 22:47:47 -0500

Why wouldn't that be an otherName with the semantics you want and 
value IA5String or UTF8String (or a choice between them)?  The semantics 
of GeneralNames don't suggest that there are any links between different 
GeneralName values within it.

                Tom Gindin

"Miller, Timothy J." <[email-masked]> 
Sent by: [email-masked]
01/28/2009 02:04 PM

To
"[email-masked]" <[email-masked]>
cc

Subject
SAN semantics question

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 29 Jan 2009 08:27:20 -0500

> think this is a questionable approach.

I've been advocating deriving the UUID from the public key (using a
variation on method 5).  This provides binding between cert and UUID, and,
in fact, we wouldn't need to put the UUID in the cert at all (the
application can derive the UUID on the fly during authZ).  I keep losing the
argument because then the identifier isn't "permanent;" though I contend
that the requirement for periodic re-validation creates the opportunity to
re-assign identifiers.

Anyway.

> you didn't specify what those might be ...

That's an idea, but I don't know if it would fly; non-sequential serial
numbers make people nervous given our existing OCSP implementation.

-- Tim

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 29 Jan 2009 08:46:18 -0500

Tim,

This serial number attribute is in the DN and has nothing to do with the
certificate serial number field.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
> Sent: Thursday, January 29, 2009 8:27 AM
> To: Stephen Kent
> Cc: David A. Cooper; [email-masked]
> Subject: Re: SAN semantics question
> 
> 
> > the node value is just a MAC address, there are extant 
> conventions for 
> > representation of that value employed by DOCSIS and WIMAX folks.
> I've been advocating deriving the UUID from the public key 
> (using a variation on method 5).  This provides binding 
> between cert and UUID, and, in fact, we wouldn't need to put 
> the UUID in the cert at all (the application can derive the 
> UUID on the fly during authZ).  I keep losing the argument 
> because then the identifier isn't "permanent;" though I 
> contend that the requirement for periodic re-validation 
> creates the opportunity to re-assign identifiers.
> 
> Anyway.
> 
> That's an idea, but I don't know if it would fly; 
> non-sequential serial numbers make people nervous given our 
> existing OCSP implementation.
> 
> -- Tim
> 
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 29 Jan 2009 08:51:15 -0500

> certificate serial number field.

I realized I'd misread that just after hitting send.  It's been a long week.

-- Tim