RE: Basic Cert-2-Directory mapping question

["Slone, Skip" <skip.slone@xxxxxxxx>]

Dave,

You wrote:

"For my part, I am simply in awe of the elegance of that approach.
It might even work."

Thanks for the vote of confidence. In theory, the approach I've outlined
could actually be extended to the entire set of possible DNs by taking it up
one level.  That is -- and remember I'm talking theory, here -- by extending
the concept to include the registration of "AVA RRs" under "." any
syntactically valid DN could be resolved in this fashion.  Of course,
there's a difference between "theoretically possible" and getting it through
IANA...

 -- Skip

-----Original Message-----
From: David Kemp [mailto:dpkemp@xxxxxxxxxxxxxx]
Sent: Wednesday, January 17, 2001 4:06 PM
To: ietf-pkix@xxxxxxx
Subject: RE: Basic Cert-2-Directory mapping question


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" <bjueneman@xxxxxxxxxx>
> 
> 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" <Ron.Ramsay@xxxxxx>
> 
> > 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 ... ]