Tom and Steve,
I thought about this problem some more last night, and became
more convinced than ever.
Regardless of what X.520 says about the the name attribute in
general and commonName in particular (i.e., EQUALITY
MATCHING RULE caseIgnoreMatch), names ARE case
sensitive, and people have a right to expect that they
will be listed exactly in accordance with their preference, at
least in their certificates if not in the directory or the phone book.
The number of examples is almost endless - from
d'Alessandro to l'Hommedieu to 'mBassa to von Trapp.
In the corporate world, business law conventions include the
use of aka (also known as), dba (doing business as), and t/a
(trading as). If these common abbreviations were printed in upper
case, real (semantic) confusion could result.
I would suggest that the ONLY canonicalization that should be
performed on a user's name should be the removal of redundant
and trailing blanks, for I know of no language that has a syntactic
or semantic distinction based on the number of blanks. (The old
typewriter convention of putting two spaces after the period at the
end of a sentence but not after an abbreviation was a typographical
convention, not a linguistic construct.) Thai doesn't even insert blanks
between workds, and divides words at the ends of lines quite arbitrarily,
I understand.
In particular, case sensitivity and punctuation should be scrupulously
adhered to. Apostrophes are commonly used, and in Xhousa the
explosive ! is used as the equivalent of a letter. The number of
neologisms such as Intel's "SatisFAXtion" board are almost endless,
and may be considered a vital part of their trademark and corporate
identity program. "Foreign" (non-English) characters may also be
required. And no, Harry S Truman is NOT the same as Harry S. Truman!
(I confess that I haven't an clue as to what to do about non-European
languages, even those with alphabets such as Cyrillic, Greek, Thai,
Arabic, Hebrew, Hindi, and Katakana, much less the ideographic
languages. One would like to be politically correct, but to be
readable they are probably going to have to be transliterated into
a European character set. I'll leave that for the Internet diplomatic
corps to solve. I'm also not quite sure of what to do about names
that use irregular characters as part of their trademark, if not their
legal name, "Toys 'R' Us" being the most notorious example.)
So Jeff Kimmelman is correct when he says
Though
the two versions of the CA's name can be used when searching a
directory and MUST, according to the rules, yield the same results,
they may NOT be interchanged in X.509 certificates.
I also believe that Jeff is correct in addressing the issue raised by
Mike Roe, and that the PEM requirements for name subordination
should be for an EXACT match, not just an equivalence class match.
However, it is important to understand what will happen when we apply
these rules in the case of a directory.
As Jeff says, I could enter cn="Robert R. Jueneman" or
cn="rOBERT r. jUENEMAN" into the directory, and the same
distinguished name would result FOR DIRECTORY SEARCH
PURPOSES. However, in the second case the DN in the
certificate would not be an exact match, but only a caseIgnoreString
match of the DN that is used for searching.
If there really two different people, Sally a. Smith and Sally A. Smith,
then these two names would not be distinguished insofar as the
directory is concerned, and further qualification would be required.
But this should not trouble us too much, for the same thing may happen
in the case of an alias.
Because my father never legally changed his name (during WWI, when
having a Germanic double-N on one's name was NOT politically correct!),
his will and other important documents list his name as
Fred R. Jueneman, aka Frederick Reade Juenemann.
Should he ever get a residential person certificate, I would assume that
he would have every right to list his name in exactly that form in his
certificate.
In the directory, however, he would probably prefer to only list the
Fred R. Jueneman form. Now, what should the DN in the directory
look like? I suppose that there would be nothing wrog with listing
the full aka version as a DN, and then setting up an alias for Fred R.,
and perhaps either another alias or a seeAlso for the Frederick Reade
form.
But frankly, I can't see any particular reason why the full aka version
HAS to appear in the directory, since it is highly unlikely that anyone
would ever search for it in that form.
Another instance that might be a lot more confusing would be a dba
case.
As I understand it, GTE's Telephone Operations (Telops) organization
is technically an unincorporated GROUP under GTE Service Corp.
But the sign on the building and the letterhead says GTE Telephone
Operations, and so it will certainly be necessary to enter the Telops
name as an alias in the directory, even though the certificate will
say something like
C=US, O="GTE Service Corp.", OU="dba GTE Telephone Operations"
An even worse (but unlikely) example would be the case of an
alias O="ibm", which points to a DN of O="Itty Bitty Movers".
At present, at least, the X.509 certificates do not allow any backward
pointers or references, so in general the user may enter one name and
be presented with quite another. This could occur because of an alias,
or perhaps because the directory is screwed up! The result is that
the user is going to have to be responsibile for assuring himself that
the certificate representes the person he wishes to communicate with
and/or believe.
Ultimately, I would like to see these kinds of allowable varient names
and aliases included in the certificate to minimize this ambiguity, but this
cannot be done with the current certificate structure.
Bob