Peter,
Although I can't speak for other toolkit providers, our recent release of the
(FREE!) Novell Certificate Server 2.0 on NetWare/NDS, to be followed
by cross-platform implementations of NCS on NT, Solaris, and
Linux, make me believe that the number of certificates issued by
organizational CAs will soon increase sharply.
The train wreck between what the DN in the certificate should look like vs.
the directory schema for a DN has been looming for about ten years,
and the screeching and metal bending is now beginning to happen.
It's like watching The Fugitive in slow motion.
Because our cert server is tightly integrated with NDS, a more-or-less but
not quite (for good reasons) X.500 directory, we had to make some design
decisions in this area that might be of interest.
First of all, we decided that if we couldn't convince our own IS organization
to rename all of the objects in our DIT to conform to someone else's view
of what a DN ought to look like, when we only had 4000+ employees, we didn't
stand a ghost of a chance trying to convince say the US Navy to change theirs.
So the directory rules, and the DN in the certificate exactly matches the DN
of the user's object in the directory. Period.
(Well, actually that's just the default. In fact, the system administrator can
type in anything (s)he likes. But then some other things might not work
as well, like X.509 authentication.)
This means that the DN in my certificate is the not very informative
cN=bjueneman, ou=nsrd, ou=prv, o=Novell. But at least it maps directly to
my DN in the directory, and therefore can very easily be used to
authenticate my access to NDS and to other servers.
Unfortunately, perhaps, the order of the attributes in the certificate isn't
explicitly spelled out in X.509 or RFC 2459, and so by default they are
included in the certificate in the conventional NDS presentation order,
little-endian first, rather than in top-down DIT order.
Contrary to how most public CAs do it, at least so far, the e-mail
address is included in the subjectAltName as per the PKIX RFC,
and to our pleasant surprise all of the e-mail packages we have
encountered to date have been able to handle that format correctly.
Although we could have, we chose not to include an e-mail address of the form subjectAltName="Robert R. Jueneman" <bjueneman@novell.com> ,
in part because most e-mail packages would just as easily accept
"President William Jefferson Clinton" <bjueneman@novell.com>.
(According to my reading of RFC822, the name field that precedes the actual
RFC822 mailbox address is supposed to be a GROUP name, and whether the
inclusion of such a name in the semantics of a PKIX e-mail address attribute
is legitimate or not really isn't clear.)
The present version of the cert server GUI doesn't support the creation of
multiple subjectAltNames, but the API does, and I hope we will be able
to provide that capability in the GUI and the bulk certificate creation
method in the next release.
I believe that an additional subjectAltName is the "correct" place for
the subject's "real" geopolitical or organizational name in a form that is
intended for human consumption, e.g, c=US, o="Novell, Inc.",
ou=Network Security R&D, {cN="Robert R. Jueneman"+employeeID=123456}
(Or, for that matter, the infamous MPEG movie (now upgraded to 16x9 HDTV
MPEG-2, with Dolby Digital 5.1) of me playing with my cat, the ASN.1
encoding of which I expect to be on my tombstone. :-)
Finally, with regard to the uniqueness of e-mail addresses, although I don't
know what practices the various public CAs may follow, I would NOT
assume that they are one-to-one with user's identities.
Certainly an individual user may wish to have two or more certificates
containing the same DN and same "real" name, but with different e-mail
addresses depending on which account he uses to send the mail – just
for the convenience of the recipient in validating the signature, and also
for the user's convenience if he uses two computers and doesn't want to
transport the private key for his "home" computer to his work computer,
where it might conceivably be more easily compromised.
Vice versa, although I wouldn't recommend it, I would certainly understand if
an entire family shared one-e-mail account (because of pricing considerations),
and yet they each had their own certificates. Certainly better to do that than
to share the private key!
And of course the user might reasonably have two certificates containing
precisely the same DN, and precisely the same subjectAltNames, but
perhaps with different validity periods, private key usage periods, different
algorithms or other attributes. including proprietary ones.
For all of these reasons, I would suggest that certificates be referred to by
a shorthand name, to simplify selecting the right one for a given purpose.
Regards,
Bob
>Spurred by recent questions on another mailing list about how to identify
>certificates in a useful-to-humans manner, I've been doing a bit of poking
>around to see how others solve the problem because I have no idea myself how to
>make anything meaningful to the average end user from a DN. By the looks of it
>this is a problem which has occupied a number of people in the past, so I'll
>try and put something coherent in the style guide to summarize the situation
>and provide advice. The following is based on a survey of a (somewhat small)
>number of online repositories, most CA's either don't seem to publish their
>certs or if they do they hide them really well, so I haven't been able to
>check too many implementations of cert lookup:
>
>-- Add to end of section on DN's --
>
>As the above text has probably indicated, DN's don't really work - there's no
>clear idea of what they should look like, most users don't know about (and
>don't want to know about) X.500 and its naming conventions, and as a
>consequence of this the DN can end up containing just about anything. At the
>moment they seem to be heading in two main directions:
>
> - Public CA's typically set C=CA country, O=CA name, OU=certificate type,
> CN=user name
> - A small subset of CA's in Europe which issue certs in accordance with
> various signature laws and profiles with their own peculiar requirements
> can have all sorts of oddities in the DN. You won't run into many of
> these in the wild.
> - Private CA's (mostly people or organisations signing their own certs)
> typically set any DN fields supported by their software to whatever makes
> sense for them (some software requires all fields in the set
> {C,O,OU,SP,L,CN} to be filled in, leading to strange or meaningless
> entries).
>
>Generally you'll only run into certs from public CA's, for which the general
>rule is that the cert is identified by the CN and/or email address. Some CA's
>issue certs with identical CN's and use the email address to disambiguate them,
>others modify the CN to make it unique. The accepted user interface seems to
>be to let users search on the CN and/or email address (and sometimes also the
>serial number, which doesn't seem terribly useful), display a list of matches,
>and let the user pick the cert they want. Probably the best strategy for a
>user interface which handles certs is:
>
> if( email address known )
> get a cert which matches the email address (any one should do);
> elseif( name known )
> search for all certs with CN=name;
> if( multiple matches )
> display email addresses for matched certs to user, let them choose;
> else
> error;
>
>[Question for CA's: Do you require unique email addresses? I managed to find
> some duplicates at Verisign, but not two active certs with the same email
> address]
>
>[Some sort of recommendation here, probably telling people to assume that the
> email address is unique, CN's are non-unique, and other DN components can't be
> relied upon. If you need something unique (for example for a database key),
> use an X.500 serialNumber in an altName directoryName or define your own
> otherName. I'm trying to come up with one-size-fits-most guidelines on how to
> identify a cert in practice]
>
>Peter.
>
Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
bjueneman@novell.com
1-801-861-7387
DISCLAIMER:
If this message (with or without attached documents) is digitally signed, and/or if certificates are attached, the intended purpose is to
(1) Ensure that e-mail came from the apparent sender
(2) Protect e-mail from tampering
(3) Ensure that the content of e-mail sent to me and encrypted in my dual-use key cannot be viewed by others.
It is explicitly NOT the intent of any such signed message or document to represent any type or form of legally binding contract or other representation, and any such interpretation should not be considered commercially reasonable and WILL BE REPUDIATED, notwithstanding any wording or implications to the opposite effect in the text of the message itself; due in part, but not exclusively, to the fact that the security of my workstation and its associated cryptography is not judged adequately strong for such purposes at present.
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606=0A= USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature