Tom>I researched RFC1422 yet again on Distinguished Names and rediscovered a
muddle of ideas with no obvious guidance. This may be intentional, but
it leads to a variety of different interpretations.
"Muddle" isn't very complimentary, but I am afraid that you are pretty close
to the mark with respect to what DN attributes are expected and/or allowed
in a certificate.
Since we are still using PEM version 0, I am assuming we are still sticking to
the '88 version of X.500. So subjectUniqueIdentifier isn't available for my
employee number.
Tom>By the way, two cn's in a DN are not illegal under X.509 any more than
two ou's would be. That doesn't mean that I suggest that anyone do it.
Following up on your suggestion, I went back to read the definition of
Common Name in X.520. The text hasn't changed from '88 to '93:
"The Common Name attribute type specifies an identifier of an object. A Common
Name is not a directory name; it is a (possibly ambiguous) name by which the
object is commonly known in some limited scope (such as an organization) and
conforms to the naming conventions of the country or culture with which it is
attached.
"An attribute value for Common Name is a string chosen either by the person or
organization it describes or the organization responsible for the object it
describes
for devices and application entities....
"Any varients should be associated with the named object as separate and
alternative attribute values.
"Other common varients should also be admitted, e.g., use of a middle name
as a preferred first name; use of "Bill" in place of "William," etc."
The way I read that, I could reasonably and legimately use any or all of the
following in combination in my certificate.
CN=Robert Reade Jueneman,
CN=Robert R. Jueneman,
CN=Bob Jueneman,
CN=GTE Labs employee #22934.
Likewise, we might very well see something like
CN=Hillary Rodman,
CN=Hillary Rodman Clinton,
CN=Mrs. William Clinton.
This certainly offers significant advantages in the case of women (and some men)
who change their name upon marriage. Presumably in a real X.500 directory, these
various names would be aliases of each other, or perhaps the individual common
names would be aliases of the DN containing the entire set. But it appears that
there would be nothing wrong syntactically with including them all in an PEM
certificate, and there might very well be significant semantic value.
For example, my father dropped the final N in his name during the WWI
timeframe, but never did so legally although he used that form all through
his time in the Army and Air Force. So something like
CN=Frederick Reade Juenemann,
CN=Fred R. Jueneman, LTC USAF Ret.
would serve a real purpose in identifying him.
I certainly like the use of multiple Common Names better than the OU=Emp.#xxxx
hack that I had suggested earlier. And I've finally found the bounds
definitions I
was looking for (X.520 Annex C), so I now know that each of these strings can
be up to 64 characters in length.
Although Tom's previously suggested use of the Description attribute
seems intended more for disambiguation in the case of two individuals who
would otherwise have the same DN (e.g., CN=Robert R. Jueneman,
Description="The somewhat rotund but otherwise good looking fellow
with the gray beard who is NOT a horse thief."), using it for my Disclaimer:
purpose would be much less tacky than coding such awkward language into an
OU format. In addition, the Description string length is 1024 bytes, so it is
not
necessary to be so terse.
Now the questions are:
1. (Steve Kent) Is the inclusion of multiple CNs within the Distinguished Name
field of a PEM certificate a correct interpretation of X.509 and RFC 1422?
It certainly seems to be from my reading of X.520.
2. (Steve Kent, again) Is the inclusion of a Description field in the
Distinguished
Name field of a PEM certificate a correct interpretation of X.509 and
RFC 1422? Again, it seems to be.
3. (Steve Kent, the NADF, the gods of X.500 political correctness, et al.)
Given the unavailability to date of an explicit Disclaimer or similar field
to be used for the purpose of defining the limits of liability a user is
willing
to agree to, would the use of the Description attribute for the purpose of
describing such a Disclaimer be considered egregiously poor form?
4. (Steve Dussi, Steve Crocker, Jeff Schiller, and other PEM implementors)
Would the use of multiple Common Names and/or the Description attribute
break your PEM implementations? I.e., if you received such a certificate,
could you display it and validate it properly?
5. (Steve Dussi and the rest of the TIPEM implementors) Assuming that the
application program which invokes TIPEM can handle it, will TIPEM handle
such constructs correctly?
6. (George Parsons and/or Steve Kent, etc.) Will the RSA/BBN Certificate
Issuing
System allow such constructs in a user's Distinguished Name when endorsing
the user's certificate?
7. (Take home problem for everyone) Has anyone tested any of these options?
Bob