Subject: Re: Correct use of subject DN and subjectAltName

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Mar 1999 16:34:16 +0100

The Qualified Certificates draft has a way to handle this.

But the way is opposite to the one you propose. In QC the corporate
information is stored in the Subject field while the personal data is
stored in the SubjectAltName (PersonalData field)

Your example could be expressed:

Subject field:
---------------
Country = US
StateOrProvinceName = Delaware
Organization = Wysiwyg Corp.
OrganizationalUnitName = Internet Products Division
Address = xxxxx, San Mateo, CA
CommonName = Joe T. Soap
Title = Project Manager

PersonalData field: (SubjectAltName ext. / OtherNames)
------------------------------------------------------
RegistrationAuthority = Wysiwyg Corp. CA service
AttributeSemantics = OID xxx (declaring that the country attribute defines the
                              country within which names are registered and
                              the country within which the address is 
                              expressed.
                              Also declaring that the dNQualifier contains
                              a number locally assigned by the specified
                              registrationAuthority (Wysiwyg Corp CA)) 
Attributes:
Country = US
Surname = Soap
GivenName = Joe
GivenName = Thomas
CommonName = Joe T. Soap
Address = xxxxx, Palo Alto, CA
Gender = M
dNQualifier = 123456789
countryOfResidence = US
countryOfCitizenship = US

Some remarks:
I'm not sure if I treated the subject field entirely correct given that the
state in which the company is registered, differ from the state in the
company local address. Others may have a different solution to this.

The PersonalData field could be different and not all of the data in the
example need to be present. It must however contain a complete unmistakable
identity within itself i.e. without combining it with data from the subject
field.

/Stefan

At 01:33 PM 3/23/99 +0200, Mark Shuttleworth wrote:
>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
>Attachment Converted: "c:\internet\eudora\attach\smime5.p7s"
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108497              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 24 Mar 1999 20:36:45 -0700

Let the record show that I agree with Steve on this point. :-)

>One always ought to ask what level of detail should be put into a Subject
>(or Issuer) DN?  Putting in more details runs afoul of 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.

If anything, I believe that a number of major organizations are beginning 
to conclude that simpler certificates are better, even if it requires more of them.

More and more organizations, including major ones like the US Navy, are 
tending toward using a directory name (DN) that is very simple, like
a high level organization (people don't move from the Navy to the Army 
very often), plus a common name, plus a permanently assigned UID,
in order to manage that person's long term records (30+ year career 
plus retirement benefits).

If they need to have a certificate that shows that person's current rank, 
job title, current duty station, etc., they'll issue one.  But the primary DN is still 
the simple version, and the other facts are (probably -- it ain't over till 
the fat lady sings) included in an alternateSubjectName for display and 
reference purposes.

Bob

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 24 Mar 1999 21:04:26 -0700

Stefan,

I would suggest that BOTH of the ways you suggested may very 
well be "wrong."

IMHO, the Subject (DN) must reflect the desired index into the primary
directory/database/heap of certificates lying on the floor.  That 
preferred index necessarily has to agree with the DIT structure of the
(primary) directory owner, whoever that might be. If it doesn't, either go find 
another directory supplier, or another CA, or change employers.

IF that directory owner happens to be the corporate entity that Joe T. 
works for, then fine -- that organizationalPerson structure is perfectly 
acceptable, and in that case it is quite unnecessary to debate the 
semantics of what StateOrProvinceName is -- where the organization is
incorporated, where the headquarters is physically located, where they 
are currently doing business, etc., because IT IS ONLY A DIRECTORY
INDEX, and doesn't necessarily have to correspond to any physical 
reality.

Now, this DN may be sufficient in and of itself -- we don't necessarily 
NEED any other physical "meat space" reference, as the SPKI folks 
would happily point out to you.

On the other hand, if a human being is going to have to make the decision
as to whether the entity which is presumably bound to that public key
by the use of the corresponding private key is actually to be TRUSTED,
rather than merely authenticated, then some additional information may 
be highly desirable.

An alternateSubjectName could certainly be used for this purpose, but as
my previous message pointed out, there are at least some people who view 
that as being an attribute that is _required_ to represent a directory entry.

That is going a little further than I would recommend, although I think that 
a reasonable assumption might be that such an alt name should be
construed as being at least an alias, in at least some directory or pseudo-
directory (e.g., DNS).

So I don't have any problem with putting the user's RFC822 name in the 
alt name field, and I might even want to look up the name that way,
even if it isn't the primary entry in my directory.

I also think that the QC spec may be on to something, by trying to separate
"meat space" information that is primarily for human consumption and display,
as opposed to directory and "rights" management.

I have always objected to the cavalier way that we quibble about syntax, 
and then quietly swallow completely ambiguous and overloaded semantic 
constructs.

It now appears that Peter Gutman may have actually enshrined my infamous 
MPEG cat movie in a certificate, and I would like to have the ASN.1 
encoding of that certificate chiseled on my tombstone (probably a very large 
tombstone).  Clearly that was intended to be a horrible example of what 
_not_ to put in a DN, or, I would argue, even in an alternateSubjectName, 
but instead belongs in some kind of personal data attribute, depending 
on taste. (De gustibus ...)

To paraphrase Patrick Henry, I disagree with much of what is proposed to be
put in the QC in a personal data field, but I will defend to the death their right 
to put it there. (So long as it isn't considered mandatory to implement, at least.)

Bob

>>> Stefan Santesson <[email-masked]> 03/23/99 08:34AM >>>

Subject field:
---------------
Country = US

Some remarks:

/Stefan