-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MEoxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNQTE
uMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neQ=
=,02
MIC-Info: RSA-MD5,RSA,BhE5sh2DYGg9nAHj53+LzSjnGtnbiSs5hw350kx7m8L
q+xIvlFBdckhvX7lVZ3iR+N1kknyelnOFwor44vMzsBYmYk+DYh/GYSvSV4nM6+U
35QA1Nx5AF9+AFjlCrt2d
Date: Sun, 15 Aug 93 15:32:34 EDT
From: jueneman%wotan(_at_)gte(_dot_)com
...
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?
Yes and No. It might just work. But it would be wrong!
The problem is determining the canonical way (read: Distinguished) to
represent someone with multiple CN's. If you place them within the
same RDN you are probably violating Distinguished naming rules, but I
won't address this now (Steve Kent will probably be glad to!).
The real problem is that if my Distinguished Name is (names
abbreviated for brevity):
C=US
O=MIT
CN=Jeffrey I. Schiller
CN=Jeff Schiller
CN=Jeffrey Schiller
CN=Jeffrey Irwin Schiller
Then it is *not*:
C=US
O=MIT
CN=Jeffrey I. Schiller
These are two different DNs! So I either have to pick one, or I have
to create a certificate for each one (with perhaps the same key pair).
However I don't believe my X.500 directory entry can hold multiple
certificates.
In my mind, the whole point of a DN is to have one unique name that is
guaranteed to point to my directory entry, and to only my entry (this
is the definition of a DN). I may have other name attributes which
help someone find me when searching a directory, but those are not
distinguishing attributes.
Today I have a X.500 entry with all the CN's listed above. However my
distinguished name is the "Jeffrey I. Schiller" version. You can tell
this because it is the name that is contained within my certificate
(which is stored in the userCertificate attribute of my directory
entry).
I suppose that a well integrated PEM and X.500 DUA would, upon message
verification, take the DN contained in the originator's certificate
and use that to look the originator up in the X.500 directory (this is
guaranteed to find one entry). It can then display all of the names
found in the directory entry. Of course this raises the issue of how
much you are willing to trusted the X.500 directory.
Using this technique you could use employee ID numbers as the
distinguishing attributes in your certificates at GTE (i.e.,
C=US,O=GTE,EID=23456) [EID presumably would be an OID for an employee
number attribute] and have a guarantee of no overlap (unless you reuse
employee IDs). Upon verification of a message the X.500 directory
entry for EID=23456 could be queried and all appropriate attributes
displayed, including all names and restrictions that might be placed
on the individual (again you are trusting the directory here).
This is probably the proper way to solve this issue in the long run,
assuming the ubiquitous deployment of X.500. After all, information
such as what restrictions are on my signature may change very
frequently. In fact using this technique my title at the company may
change, but I still don't need to get a new certificate. Of course you
wind up putting trust in the directory, but so what. If strong
authentication is adopted as a matter of course for authenticating
directory management requests, it can be as secure as it needs to be
(read: as secure as credit databases are today).
To give an analogy to the "real world." I was at Sommerville Lumber
today (a lumberyard and mega hardware store, for those not in Mass.)
and used a credit card to pay for a hefty purchase (well actually my
wife used her card, but that doesn't matter here). The clerk in the
store called up a VISA card credit checking service to validate that
she was in fact authorized to make a purchase of that size. This
credit information was in a database (directory?) *and not burned into
the card itself* (which is how I think of information that is signed
into a certificate).
Sorry to ramble so long...
DISCLAIMER: Just because this message is digitally signed does not
imply that I am legally bound by the statements made herein.
[Sorry, couldn't help myself ;-)]
-----END PRIVACY-ENHANCED MESSAGE-----