[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to identify certs to users



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.