Re: Basic Cert-2-Directory mapping question

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Stephen Kent <kent@xxxxxxx> writes:
 
>I have not read your paper, but the assertion that DNs don't work, without 
>substantiation, seems a bit strong.  Certainly when people create arbitrary 
>DNs, without regard to the semantics of directory structure, bad things 
>happen. Also, it is fair to say that the grand, nations as top level 
>directory operators model that X.500 envisioned has not happened, and it 
>unlikely to ever happen in some places, e.g., the U.S. However, the 
>suggestion of hashing a DN and using it as a search key always seems to have 
>the problem of breaking the knowledge reference part of X.500 (and of all, 
>analogous, tree structure, distributed directories), which rely on looking at 
>name structure to figure out where to look for an entry that is not local.
 
This is a somewhat circular argument, that if you have a DN which has been 
artificially constructed to be meaningful it will in fact be meaningful in 
locating a cert.  In practice this never works except in the special case I 
mentioned earlier where everyone has been forced (on pain of pain) to use some 
fixed schema for their DN's.

Consider for example finding one of the certs I've acquired over time for 
testing purposes (most of them have probably expired by now).  Looking at my 
email address you'd start with C=NZ, and then perhaps O=Auckland University, 
or maybe University of Auckland, or perhaps University of New Zealand with 
another O=Auckland (the last one's definitely wrong, but non-NZers may not 
know that).  After that it gets tricky, is it OU=Computer Science, Computer 
Science Department, Department of Computer Science, CompSci, CS, or even 
Mathematics and <whatever it is this week>/School of Mathematics and 
../Faculty of... with another OU specifying the department?  (I've just 
checked and it's currently "School of Mathematical and Inforation Sciences", 
I'm sure if I asked 10 people here I'd get 15 different guesses as to how all 
this stuff is supposed to be specified in a DN).  Even if you manage to find a 
directory which contains Uni certs (good luck with that) *and* spend an hour 
or two playing guess the DN, you won't find anything because all the CAs which 
I've got certs from use DNs which are meaningful to them, not to arbitrary 
third parties.
 
It gets worse than that.  Because the DNs are meaningful to the issuing CAs 
(which is perfectly OK, they issue the certs so they get to control the DN 
space) rather than the EE, the EE generally doesn't know their own DN.  I 
can't actually tell you, without cheating and taking a look, what any of the 
DNs in the certs issued in my name are.  I'll emphasise that again: I don't 
even know my *own* DNs without looking, and I doubt most other people outside 
of .govs/.mils which force you to use fixed DNs would either.
 
The sole meaningful piece of information in any of my certs is my email 
address (my CN is vaguely meaningful, but suffers from the "Which John Smith" 
problem.  There should also be certs out there with my email address but 
apparently belonging to the Jolly Green Giant - isn't it wonderful what CAs 
will let you put in a cert?).  That's the point I made in the analysis in my 
paper, noone (well, almost noone :-) actually uses a DN in the way X.500 says 
it's supposed to be used.  It's used in a check for equality when checking an 
S/MIME sig or fetching a decryption key or whatever, but an SHA-1 hash would 
do just as well, which is why I proposed hashing the DN to a fixed-length 
value and using that instead.  Without wanting to rehash the entire paper, 
what I did was analyse the types of cert lookups which are typically performed 
and then design a scheme which handled them.  
 
A general summary of the concept is that if you design your application with 
the assuption that any DNs it encounters are meaningless blobs, you won't be 
disappointed.  If you assume the DN has some sort of magical properties, your 
application breaks for the vast majority of DNs which don't have those magical 
properties.
 
>finally, the IETF has had a standard means of encoding a DNS name as a DN for 
>several years, which suggests that there is at least one scheme that would 
>work.
 
I assume you mean the RFC 2247 domainComponent?  It's a nice theory, but since 
anyone who needs a URL/FQDN will use a GeneralName where it's available (which 
is in most cases when it's required) and where only a DN is available will 
stuff it into a CN like everyone else does and like everyone's software 
expects, I can't see it ever going beyond being a nice theory (I have a vague 
memory of actually having seen a solitary DC in a cert somewhere, but a quick 
check of my collection has failed to locate one... does anyone know of 
examples of these being used?  How does the average third-party app handle 
them?).
 
Peter.