Subject: Re: Basic Cert-2-Directory mapping question

From: [email-masked] (Peter Gutmann)
Date: Tue, 9 Jan 2001 12:19:51 (NZDT)

Stephen Kent <[email-masked]> 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.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Jan 2001 19:00:40 -0500

Peter,

I think your analysis shows that we have a lot of folks playing CA 
who are not "qualified" to do so.  This is somewhat analogous to 
people who operate closed IP nets and screw up address assignment, 
subnetting etc. It's all OK until they try to connect to the rest of 
the world, and then we get NAT!

In the CA case, if you really want a closed CA environment, that's a 
more defensible practice, but then there is a responsibility to 
provide the whole environment, which includes the directory. If you 
do it right, then you can play fast and loose with names and users 
will be OK.  But, all too often we see that systems that were 
intended to never be open, start developing cracks, and then people 
see what a mess has been made. I have no sympathy for folks who get 
themselves into messes of this sort.

I think our friends at MS have adopted your attitude to DNs, i.e., 
"they're too hard to deal with properly and nobody uses them right 
anyway, so lets use a shortcut for lookups, etc." That appears to be 
at the heart of a design in which subject key ID takes on more 
significance than the names in a cert, is used as a search key in a 
local repository, and for chaining, overriding the 2459 cert path 
validation rules, etc. That will work if everyone plays by their 
rules, but does it scale well?  Also, it has unintended effects, as 
one PKIX list member already reported when he discovered differing 
behavior between Explorer and Navigator. Surprises are never good in 
a security context.

In the later half of the 1980s, Lotus (really Iris) developed its own 
cert format for use with the Notes product.  It worked just fine 
within each work group context, but they soon discovered then when 
work groups tried to interconnect and they had issued certs in their 
own little CA domains without a bigger structure in mind, collisions 
happened and problems ensued.

The problems you cite are real, and they arise for a wide range of 
reasons, some bad, some understandable. Today I encourage folks to 
use names from spaces where authoritative CAs can exist, e.g., DNS 
names, and to use DNs with caution.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 9 Jan 2001 08:13:43 +0100

Guys!
The response on this "basic" question has simply been overwhelming!

Even if you can force CAs to obey certain rules regarding DNs, I still believe
that this inability to use certificates created in "one regime",  as credentials in
another Win2K or NetWare "regime" calls for *some* kind of action.

At least those who are into TTPs (commercial or not) should be interested.

/anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 9 Jan 2001 09:37:25 -0500

Anders,

>another Win2K or NetWare "regime" calls for *some* kind of action.

Not necessarily. Personally, I'm comfortable having multiple certs 
issued by different CAs, each authoritative for a distinct PKI. 
Large, isolated PKIs are OK, if one has a clear plan for why they 
will remain isolated. SET, though a failure in many respects, is a 
good example of such an isolated PKI.  Also, although we have not 
mentioned it in this exchange, PKIX has the AIA extension, and will 
add back the SIA extension, which provide explicit pointers to 
directories once you have a target certificate, e.g., for retrieval 
of CA certs and CRLs. Many security protocols provide an ability to 
send certs as part of the protocol, which alleviates the need for 
blind searching for certs.

>At least those who are into TTPs (commercial or not) should be interested.

yes, TTPs who argue for "one person, one cert" have an interest in 
this issue, but that's not the only game in town, and if the problem 
is mostly a directory issue, then the discussion belongs in a 
directory WG, not in PKIX.

Steve

---

From: "Stefan Kelm" <[email-masked]>
Date: Tue, 9 Jan 2001 16:54:32 +0100

Peter,

> examples of these being used?  How does the average third-party app handle 

we've used certificates with DC attributes (encoded as IA5STRING) with
customers. Needless to say that applications do have problems; most
will accept the certificates but will not display the full DN, esp.
not the DC attributes...  :)

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---

From: Michael Ströder <[email-masked]>
Date: Wed, 10 Jan 2001 09:09:03 +0100

Peter Gutmann wrote:
> >substantiation, seems a bit strong. 
>
> [.. Very many valid points by Peter deleted..]

Peter, I completely agree with you. IMHO one of the main problems
with
PKIX is that there's so much X.500 in it. ;-) (I enjoyed your
writing about T.61...)

> address

Agreed again. And IMHO the e-mail address combined with fast
searching (the real
advantage of directory servers) is the only working solution for a
person's entry today.

> That's the point I made in the analysis in my
> it's supposed to be used.

And if you try it's sometimes even hard to find the "right" value
for the CN person's attribute of a person's entry. BTW: Ed Gerck
wrote a nice paper about these naming problems too (available around
'98 if I remember correctly).

> (I have a vague
> check of my collection has failed to locate one...

;-)

> does anyone know of examples of these being used?

Yes.

>  How does the average third-party app handle
> them?).

OpenSSL can handle them. Netscape Messenger seems to be able to use
them. web2ldap displays them...

Ciao, Michael.

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 10 Jan 2001 20:10:27 +0100

Michael,

> IMHO one of the main problems with PKIX is that there's so much X.500 in it. ;-)

I must put that in a frame!

/anders

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Jan 2001 16:58:00 -0500

Michael,

>PKIX is that there's so much X.500 in it. ;-) (I enjoyed your

Perhaps thinking about the WG name will clarify why there's so much 
X.500 in PKIX.  Were you looking for the SPKI WG list and wound up 
here by accident?

Steve

---

From: Michael Ströder <[email-masked]>
Date: Thu, 11 Jan 2001 09:44:50 +0100

Stephen Kent wrote:
> 
> >IMHO one of the main problems with
> >PKIX is that there's so much X.500 in it. ;-)
> 
> X.500 in PKIX.

I can also rephrase the sentence with having the same result by
saying:
The main problems with PKIX is that there's not much X.500 in
current implementations any more.

> Were you looking for the SPKI WG list and wound up
> here by accident?

Nope.

Ciao, Michael.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 11:53:34 -0500

Michael,

>current implementations any more.

That's a better statement.

Steve