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

From: "David P. Kemp" <[email-masked]>
Date: Mon, 8 Jan 2001 13:29:47 -0500 (EST)

Peter,

I thought what Anders asked was:
  "given an arbitrary DN, how do I find a cert stored somewhere in an
  arbitrary collection of independently-managed X.500 or LDAP directory
  servers",

not:
  "given an arbitrary DN, how do I fetch a cert which I already have a
  copy of, stored on my own server."

It shouldn't be at all surprising that a db or ISAM store, with or
without an RDBMS layer above, and with or without a DAP or LDAP access
layer, is a reasonable way to store certs on your own machine. [1]
Developing a DN-schema-independent local retrieval mechanism is all
well and good, but it doesn't solve the registration problem, and as a
result, it doesn't help you to find a cert which you don't already
have.

The real problem with finding and using certs which are stored
elsewhere is the reverse of what you stated, namely:

cause:  people fill DNs with whatever they like, and therefore
effect: those particular DN's don't work (i.e. they don't solve
        Anders' question because they aren't valid addresses in
        a global address space.)

Instead of saying "DN's don't work", with a footnote, it would
be more accurate to say "people choose not to use working DNs".

The Web works only because every Internet URL begins with
DNS-registered name. Something related to your third approach below,
requiring all certs and directories to use a standard DN registration
scheme, may be extraordinarily painful, but it's better than ad-hoc
workarounds using other certificate fields.  If PKI consumers and
providers aren't willing to standardise within a global DN space, we
will have only islands of interoperability. [2]

Dave

[1] You could also just use the native filesystem, storing each cert
as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based
flat folder.  This works as long as you keep secondary indices
synchronised with the folder contents, or if you don't need secondary
indices at all.

[2] Blue sky thought:  it might be nice if there were a "Registration
Point (RP)" DN attribute which would be analogous to the hostname
portion of a URL.  The RP attribute would be the first RDN of a
DN, and the RP value would be an OID identifying the registration
authority and the schema for the remainder of the DN.  In principle,
this is no better (except for being less verbose) than current DNs, but
in practice OIDs are better managed - people actually choose to follow
OID registration procedures instead of just poaching in somebody else's
space.

> From: [email-masked] (Peter Gutmann)
>  
> The main problem is that DN's don't work [0], so you end up with ones which 
> people have filled with whatever they feel like, odd things required by cert 
> profiles or signature laws or organisational constraints or whatever which 
> generally don't fit any known directory schema.  The current approaches to 
> this problem if you're using a directory as a cert store are:
>  
>   - Continually update the directory schema to match any new DNs which appear 
>     until the directory admin(s) go insane (hi Paul :-).
>   - Create aliases in the directory mapping DNs in certs to the (fixed) 
>     directory schema.
>   - Force all certs to use the schema used in the directory (someone who's 
>     been through this one once described it to me as "extraordinarily 
painful").
>   - Use the directory DN to identify the cert owner and store the cert as just 
>     another attribute, with the actual cert DN ignored.
>   - (There may be more, since the whole thing is badly broken there are 
>      probably lots of workarounds being used.  If anyone knows of others 
>      please let me know)
>  
> A much better approach IMNSHO, and the one I look at in my paper, is to treat 
> the DN as a blob and hash it down to a fixed-length value which you use as a 
> key to look up the cert in an RDBMS or something like dbm if you don't need 
> the full RDBMS functionality [1].  This approach just plain works no matter 
> how garbled and broken the DN is.

---

From: Janus Liebregts <[email-masked]>
Date: Mon, 08 Jan 2001 21:36:08 +0100

I fully agree with David.

I don't agree that using a standard DN registration scheme, is
extraordinarily painful. Currently we, SURFnet (as the dutch National
Research Network) use two simple rules for our pki-domain (Higher
Education & Research): 

1. only certify CA's using DN's as registered within our (LDAP)domain
using the rules of our Naming Authority.
2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified.

with this we build our pki according to the ldap-namespace ACCORDING to
SURFnet. We claim to be the Naming Authority for the C=NL namespace...

Probably every country & state have their own laws about naming
organisations, in Holland the Chambres of Commerce have such a
(delegated) task. Every country (C= or state c=US, ST=) should have some
sort of naming authority and name-registration is already taken place.
But how to make available these authorative Naming databases in a (LDAP)
way, to be the authorative name for certification....

For our community we have made available a pki-ldap cookbook which
describes a method how to organise your DIT and how to store pki-related
material http://ldap.gigacorp.nl/pkildap.html

Janus Liebregts
SURFnet

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 8 Jan 2001 21:41:42 +0100

Janus,
Unforntunately your certificates will not be useful for Win2K local authentication
due to this mapping problem.  Does Novell offer a more flexible use of
TTP-issued certificates without requiring the RP to use a 1-2-1 DN
versus directory mapping?

/anders

---

From: Janus Liebregts <[email-masked]>
Date: Tue, 09 Jan 2001 14:56:44 +0100

Anders, 

as far as we have tested: you can use certs using X.521 naming in a
win2k local authentication environment, the only restriction is that the
issuing-CA HAS to be a MS enterprise CA and thus has to use dc-naming
(in the current win2000-version).

janus

---

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

"David P. Kemp" wrote:
> DNS-registered name.

For most users the web works like this: 

  www.mycompany.com

This is a completely flat name space. And yes, I know that one can
even create valid URLs like http://host1.subdomain.domain.net... ;-)

Ciao, Michael.