Subject: How to identify certs to users

From: [email-masked] (Peter Gutmann)
Date: Thu, 4 Nov 1999 04:59:55 (NZDT)

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 summarise 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.

---

From: [email-masked]
Date: Wed, 3 Nov 1999 15:01:00 -0600

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" <[email-masked]> ,
in part because most e-mail packages would just as easily accept 
"President William Jefferson Clinton" <[email-masked]>.

(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

>try and put something coherent in the style guide to summarize the situation

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
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.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 4 Nov 1999 16:11:18 (NZDT)

[email-masked] writes:

>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" <[email-masked]> , in part because
>most e-mail packages would just as easily accept "President William Jefferson
>Clinton" <[email-masked]>.

D'you mean they'll accept that as an rfc822Name?  Are they supposed to do that?

Peter.

---

From: [email-masked]
Date: Thu, 4 Nov 1999 11:16:26 -0500

Since an rfc822Name inside GeneralName is defined as being an RFC 822
addr-spec (see RFC 2459 section 4.2.1.7), which is defined as
local-part@domain (RFC 822 section 6.1), the form "Personal Name
<local-part@domain>" is not legal for it according to PKIX.  The
difficulty, I suppose, is that a lot of software would treat this as being
an RFC 822 mailbox, for which that form is legal, especially since X.509
(1997) calls it "an Internet electronic mail address defined in accordance
with Internet RFC 822", which could plausibly be interpreted as either
mailbox or addr-spec.  I don't know if there are any corrections to X.509
on this yet, but if not there probably should be.

          Tom Gindin