Subject: Correct use of subject DN and subjectAltName

From: Mark Shuttleworth <[email-masked]>
Date: Tue, 23 Mar 1999 13:33:22 +0200

Hi folk

Is there an established best practice for the layout of the following
information in a PKIX end-entity certificate? This is the (fictional and
complex) scenario:

Joe T. Soap, <[email-masked]>, 
   who lives in
Palo Alto, CA, US
   and works for
Wysiwyg Corp., 
   which is registered in 
Delaware, US
   as a
Project Manager
   in the
Internet Products Division
   in their office in
San Mateo, CA, US

One way to do this would be to have personal information as the subject
name, and then the corporate info and office info as a set of
subjectAltNames, but there does not appear to be a way to identify which
subjectAltName means what kind of location. Is there a legitimate way to
represent this?

--
Mark Shuttleworth
Thawte

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 1999 09:36:39 -0500

mark,

>Joe T. Soap, <[email-masked]>,

If Joe is getting an organizal person cert, which seems to be true given
the rest of the supplied info, then I don't think Joe's home location is
not relevant, so let;'s forget about this piece of data.

>Delaware, US

Truem, but generally  not interesting.  Many companies are incorporated
under Deleware laws because of legal benefits.  Unless Wysiwyg really has
offices in DL, I would not bother with this info. But, let's assume that in
this case that the comnpany really is headquartered there.

>subjectAltName means what kind of location. Is there a legitimate way to

There is no sense that altSubjectNames are to be used to represent to
further qualify the Subject DN.  They certainly are useful for expressing a
name for the subject in other name spaces.  As I look at this list of info,
I begin to wonder if there is an effort to capture TOO MUCH info in the
subject name.  A frequent reason for this is because someone can envision a
way to use some of this data in some access control decision, even though
it may not be needed to uniquely identify Joe, find his directory entry,
etc.  So, for example, one might use the following subject DN in this case,
where parenthesese are used to group attributes that form an RDN set:

C=US, S=DL, O=Wysiwyg Corp, (S=CA, L=San Mateo, OU=Internet Products
Division), CN = Joe T. Soap.

I chose to put the indicated data into an RDN SET because that suggests
that there are multiple instances of the Internet products Division, within
CA, and thus one needs to consider all three of these attributes together
to uniquely identify the org unit in which Joe works.  If this is not the
case, e.g., if the company has just one Internet Products Division, and is
willing to manage names in that OU to ensure that the other Joe T. Soap
hired (or transferred into that division) will be uniquely identified, then
we could simplify the RDN and just make it the OU.

One always ought to ask what level of detail should be put into a Subject
(or Issuer) DN?  Putting in more details runs afould ot Steve's Rule of
Revocation, and makes the certs bigger too. Attempts to put more into a
name to simplify access control management are common, and almost always a
bad idea.

Steve

* Steve's Rule of Revocation states that the effective lifetime of a
certificate is inversely proportional to the square of the number of
attributes in the certificate.  Guess who named it?