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

From: David Kemp <[email-masked]>
Date: Wed, 17 Jan 2001 16:06:23 -0500 (EST)

Skip,

I favor the implicit approach.

Existing DNs schemas have tremendous inertia, and in addition to
more intellectual reasons, registering existing country-based
DNs within DNS is overwhelmingly the path of least resistance.
In order to support Internet directory interoperability, it is far
easier to say (to the DoD PKI, for example):

  "You have to register a DNS record for OU=DoD."

rather than:

  "You have to change all of your certificates and directories to
  include a new top-level RDN."

I agree with Bob's goal of eliminating the need to pass certs in
session handshakes and messages. If there were only two options (change
the DN or add an extension), then only the first moves toward that
goal.  But you have proposed a third option: leave the cert alone!
For my part, I am simply in awe of the elegance of that approach.
It might even work.

Dave

From: "Bob Jueneman" <[email-masked]>
> 
> Ron,
> 
> I don't think we are on the same page.
> 
> I don't conceive of the dir= attribute as constituting a non-DIT RDN.  
> Instead, I am suggesting that we should add the dir= attribute as a full
> RDN component at the top of the existing DIT.
> 
> I believe that it really belongs there, to qualify the lower level entries
> as belonging to that particular directory, just as is the case with "normal" 
> DN qualification..  So yes, I believe that you ought to be able to see 
> that entry when browsing the directory, not withstanding the act that 
> it would normally be static.

> The alternative, using an LDAP-style qualifier to precede the DN, is
> what strikes me as being abhorrent.
> 
> If I have a DN that includes at the top of the DIT the name of the 
> directory root itself, then that DN can be handled by all applications
> that know how to parse DNs generally.  Otherwise, we are left with 
> protocol-specific hacks, like URLs with trailing DNs.
> 
> Bob
> 
> 
> 
> From: "Ramsay, Ron" <[email-masked]>
> 
> > Bob,
> > 
> > While it may be true that 'c=us' does not try to say something about
> > countries, I don't believe this is relevant. The importance of this RDN in
> > the DN is that, notionally, there is an entry with the DN 'c=us'. When
> > browsing an X.500 DIT, you should be able to see all the superior entries as
> > indicated bu the RDNs in the entry DN. This is the semantic meaning of the
> > DN, not 'what does country mean in this DN'. To this extent, the idea of
> > adding a non-DIT RDN to the DN is abhorrent and will create real problems.
> > (LDAP directories generally aren't browsable so I guess my remarks don't
> > apply to them.)
> > 
> > Ron.

    [ 15 additional messages snipped ... ]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Jan 2001 17:06:45 -0500

Dave,

>For my part, I am simply in awe of the elegance of that approach.

I don't agree that doing away with transmission of certs and CRLs 
inline via protocols, is a good idea in general. I understand why Bob 
wants to do this in his examples, but there is another side to the 
story. Reliance on the availability of a repository as a precursor to 
secure communications makes the secure communications more vulnerable 
to denial of service attacks, as well as creating likely greater 
delays security association creation. So, for protocols like SSL and 
IPsec, I'm more comfortable with passing this data inline, rather 
than relying on retrieving it from a server.

E-mail is the really good example of a general purpose application 
where it is necessary to retrieve a certificate for an encryption key 
from a server (or receive it inline from the peer who is the target 
of the message) prior to communication. But, for signed-only 
messages, passing cert chains and CRLs is still a reasonable strategy.

Steve