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

From: Hal Lockhart <[email-masked]>
Date: Mon, 8 Jan 2001 11:36:17 -0500

> I've always wondered what those "Kerberos Certificates" are, 
> or do you mean
> tickets?  They have nothing to do with PKI, since Kerberos 
> doesn't use PKC. 

This is not true. The Kerberos working group has developed a scheme for
allowing an initial PKI handshake in place of the original symmetric key
scheme. Once the exchange is over, symmetric key-based tickets are used as
always. The spec is:

http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-12.txt

certificates may or may not be used. If they are used, there are special
requirements. For example, the DN must correspond to a Kerberos name/realm.

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [email-masked]
F: 1-508-229-0338             www.entegrity.com
=======================================================

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 08 Jan 2001 14:56:58 -0700

This has been a train wreck about the happen for nearly ten years.
It's like watching "The Fugitive" one still frame at a time.  The NADF
tried to address this problem and gave up, and PKIX hasn't even tried.

To quote Pogo, "We have met the enemy, and they is us."

The first problem is not the DN -- that's secondary.  As you correctly 
state, the first problem is knowing the location of a directory service 
provider that is supposed to contain the DN, so we can at least get 
to the right point and start browsing around for a certificate.

I don't know that we need to name a Registration Point for a DN -- that 
might get all tangled up in naming issues, who has the right to name 
someone, etc.

What I proposed more than a year ago, and what I think you are in 
essence saying, was that DNs in certificate should really be URLs, 
in essentially the same fashion as CRLDistributionPoints are.

I don't particularly care what the exact syntax is -- something like

    ldap://ldap.mycompany.com/c=us, ....cn="My Name" 

would do just fine, I think, but I'll let other people debate that.

Once we finally locate the directory, then we can have all of the religious 
arguments about my RDN schema vs. yours, and why yours is wrong and mine 
is the only one that any right-thinking system administer could possibly
support, yada, yada, yada.

Unfortunately, since the contents of PKI certificates are generally viewed 
as supposedly providing some degree of specificity with regard to a geopolitical
identification and location of an end-entity, those schemas sometimes conflict with
directory structures which are often organized around completely different 
principles, such as more or less reflecting the network structure or topology
or span of control issues.

But those issues, although certainly important, could reasonably be resolved by 
aliases, etc., no matter how painful  But if a consumer of certificates doesn't even
know where the directory can be found to start looking, then schema problems 
won't matter.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> "David P. Kemp" <[email-masked]> 01/08/01 11:29AM >>>
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: "Bob Jueneman" <[email-masked]>
Date: Mon, 08 Jan 2001 15:08:24 -0700

Unfortunately, the model you cite, with naming authorities that 
are truly authoritative, and in addition a monopoly, is in fact NOT the 
case the United States, and in a number of other countries in the 
world as well.

If the government decrees what DNs are allowable, and perhaps where 
they have to be stored, then the problem is certainly simplified.  
Unfortunately, usually isn't the case.

Bob

>>> Janus Liebregts <[email-masked]> 01/08/01 01:36PM >>>
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: "Bob Jueneman" <[email-masked]>
Date: Mon, 08 Jan 2001 15:48:09 -0700

>>> "Anders Rundgren" <[email-masked]> 01/08/01 01:41PM >>>
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?

Sorry, I don't think we have any magic bullet in this space yet either.

For those RP applications that matter, typically applications that are authenticating 
a user to the directory itself, perhaps in order to authenticate themselves to other 
resources, we tend to require a unique 1:1 mapping between the DN in the 
certificate and the DN of the directory.  Of course the customer, or perhaps
one of our consulting partners, may develop more complex solutions to fit
particular requirements.

How we get them into the directory in the first place is one of those
infamous "local matters".

The real telling issue is when you start to go beyond the intranet, and launch 
into the extranet or internet space.  In the intranet space, it generally isn't too
difficult to persuade the CA to issue certificate with the right schema, or to modify
your directory schema to fit that of the PKI vendor or CA.

What you do with a bunch of certificates from different CAs and/or toolkit
vendors, none of which necessarily match the schema of your directory, is 
still an unsolved problem.  We've started down the path of non-global schemas,
and we have some other solutions that involve DirXML, which is a way of 
synchronizing two directories and/or databases via XML, but the basic
problem is still with us.

Yes, you could arbitrarily store the certificate somewhere, using for example 
the keyID a hash of the public key, or perhaps of the certificate itself, but 
is that what we really want to do?

Maybe I'm making too big a point of this, but I don't necessarily want to import 
your certificate into MY directory.  Instead, I think that I want to retrieve
your certificate from your directory, or perhaps your CA's directory,
where ever that might be.  If I don't have to actually import the cert,
most of these schema issues tend to go away.

BTW, Tom Gindin just asked me why pkixrep didn't solve that problem,
and I confess that I am clueless about that spec, so perhaps I've missed 
something fundamental here.

But at the risk of oversimplifying, when it comes to extranet access,
my preference is to base access control decisions on role-based criteria
such as are embodied in the Novell Security Attributes, and to AUDIT
the action of that user based on the information provided in his certificate,
whatever that might be, assuming I have validated and accepted it.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 9 Jan 2001 20:35:17 (NZDT)

Stephen Kent <[email-masked]> writes:
 
>I think your analysis shows that we have a lot of folks playing CA who are 
>not "qualified" to do so.  
 
            (Wibbly-wobbly effect, fade to shot of John Cleese being turned on 
             a spit by some nuns)
JOHN CLEESE:     And now for something completely different...
            (Fairly empty generic modern room.  End entity being rushed into 
             the room on a dolly.  PKI architects are flipping through 
             standards documents)
PKI ARCHITECT 1: commonName qualified with a serialNumber in the same RDN!
PKI ARCHITECT 2: firstName + surname + generationQualifier (if required) + 
                 dnQualifier!
            (Sysadmin enters and interrupts them)
SYSADMIN:        The end entity is ready.
PKI ARCHITECT 1: Good, take her into the PKI frightening room.
SYSADMIN:        Right.
PKI ARCHITECT 2: I say, it's a bit barren in here isn't it?
PKI ARCHITECT 1: Yes, more junk please sysadmin.  The smart cards, the 
                 Safekeyper, and the biometrics.
SYSADMIN:        Yes, most certainly.
PKI ARCHITECT 1: And get the machine that issues certificates!
            (Sysadmin wheels in a cart containing a PC which has "Intel 
             Inside" and "Designed for Microsoft Windows" stickers on it)
END ENTITY:      What's that for?
PKI ARCHITECT 1: That's the machine that issues certificates
            (Machine goes PING and pops up a "Save certificate as..." dialog)
PKI ARCHITECT 1: You see, that means the end entity has been certified!
PKI ARCHITECT 2: And that is the most expensive machine in the whole building!
PKI ARCHITECT 1: Yes, it cost over three quarters of a million pounds.
PKI ARCHITECT 2: Aren't you lucky?!
SYSADMIN:        The CEO is here doctor.
PKI ARCHITECT 1: Switch everything on!
            (Bleep... whirrr... bing... rumble rumble)
CEO:             Ah very impressive, very impressive, and what are you doing 
                 this morning?
PKI ARCHITECT 2: It is a certification.
CEO:             Ahhh,.. and what sort of thing is that?
PKI ARCHITECT 2: Well, that's where we certify uncontestably and undeniably 
                 that someone we've never met before who lives on the other 
                 side of the planet and who we know only as a (possibly 
                 forged) email address really is who they claim to be and can 
                 be trusted to write good cheques, buy alcohol, sign 
                 contracts, and run a dot-com selling PKI services.
CEO:             Wonderful what you can do nowadays. (PING)  Ahh, I see that 
                 you have the machine that issues certificates.  This is my 
                 favorite.  You see we leased it back from the company we sold 
                 it to and that way it comes out of the monthly current budget 
                 and not the capital account.
            (Applause)
                 Thank you, thank you, we try to do our best, well do carry 
                 on.  
            (CEO leaves)
PKI ARCHITECT 1: Lovely, lovely, jolly good, that's better, much much better.
PKI ARCHITECT 2: Yes, that's more like it.
PKI ARCHITECT 1: Uhh... still something missing though.
PKI ARCHITECT 1+2:END ENTITY!
PKI ARCHITECT 2: Yes, where's the end entity?
PKI ARCHITECT 1: Anyone seen the end entity?
SYSADMIN:        Ahhh... here she is!
PKI ARCHITECT 1: Bring her over here.
PKI ARCHITECT 2: Mind the machine.
PKI ARCHITECT 1: Hello, now don't you worry.
PKI ARCHITECT 2: We'll soon have you certified!
PKI ARCHITECT 1: Leave it all to us, you'll never know what hit you.
END ENTITY:      Will it be a nonRepudiation certificate?
PKI ARCHITECT 1: Now I think it's a little early to start imposing roles on it,
                 don't you?  Now a word of advice, you may find that you 
                 suffer for some time a totally irrational feeling of 
                 depression, PKID as we call it.  So, it's lots of happy pills 
                 for you and you can find out all about the certification when 
                 you get home.  It's available on Betamax, VHS, and Super-8.
            (Reporters and photographers enter the PKI frightening room)
PKI ARCHITECT 1: Who are you?
NOTARY PUBLIC:   I am the end entity's notary public.
PKI ARCHITECT 1: I am sorry, only people involved are allowed in here.
END ENTITY:      What do I do?
PKI ARCHITECT 2: Yes?
END ENTITY:      What do I Do?
PKI ARCHITECT 2: Nothing dear, you're not "qualified"!
            (Machine that issues certificates blue screens, camera zooms in to 
             reveal text that says "And now for something completely 
             different...")

Peter :-).

---

From: Janus Liebregts <[email-masked]>
Date: Tue, 09 Jan 2001 15:30:32 +0100

Bob,

every country has its own monopoly on local law, every country has a tax
department which have to distinguish which company and which citizen has
to pay tax.

There should be some sort of distinguishing between companies and
citizens done by authorities. Mapping of names, which can be used under
this law, has to be done in every country.

I think the problem is really simple, you can use a name not recognized
by your law, but one of the CA's in your pki-hierarchy has to give some
guarantee of this CA is operating under a CPS AND a certain law to be
trustworthy. Some kind of company or citizen has to provide this
guarantee. How do you sue a CSP if you don't know under which identity
(recognized by some law) he operates?

This is a main issue when doing business using pki-technology in between
2 or more legal systems.

janus

---

From: [email-masked]
Date: Tue, 9 Jan 2001 09:32:03 -0500

Bob,

Accepting the fact that the X.500 dream of a single global directory is not
going to happen any time soon, DNs can still be turned into globally
significant pointers into a federation of directories in the way you
suggest, but it doesn't require altering the DN syntax (and therefore
doesn't have to break existing implementations).  All that's needed is a DN
attribute that names the particular directory within which the name
resides.  e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
directory access point.

John

"Bob Jueneman" <[email-masked]> on 01/08/2001 04:56:58 PM

To:   <[email-masked]>, <[email-masked]>
cc:
Subject:  Re: Basic Cert-2-Directory mapping question

Unfortunately, since the contents of PKI certificates are generally viewed
as supposedly providing some degree of specificity with regard to a
geopolitical
identification and location of an end-entity, those schemas sometimes
conflict with
directory structures which are often organized around completely different
principles, such as more or less reflecting the network structure or
topology
or span of control issues.

But those issues, although certainly important, could reasonably be
resolved by
aliases, etc., no matter how painful  But if a consumer of certificates
doesn't even
know where the directory can be found to start looking, then schema
problems
won't matter.

Regards,

Bob

Robert R. Jueneman
Security Architect

Peter,

not:

Dave

painful").

---

From: "John McGarvey" <[email-masked]>
Date: Tue, 9 Jan 2001 09:30:08 -0500

Janus,
In describing the Microsoft case, you put your finger right on the problem.
There is no guarantee that the LDAP directory to be used by a given
application, and the CA that issues a certificate, adhere to the same
namespace rules or are administered by the same processes or people.  So
the certificate DN may not correspond to any DN in the directory.  This
problem will often occur in eBusiness or B2B applications, when the
certificates may be issued by well known public CAs, but the directory in
which policies, preferences, and whitepages information is stored is
maintained by a given enterprise or web hosting service.  Also, there is no
guarantee that the DNs in the certificates uniquely identify the same
principal.  Different well known CAs might use the same DN to describe
different principals.

If one is building a CA infrastructure and a directory infrastructure
together, of course one can make the certificate DNs match the LDAP DNs.
But, as it is often the case that the two are constructed separately, there
needs to be a means of mapping from one to the other.

Regards,
John McGarvey

Janus Liebregts <[email-masked]>@terena.nl on 2001/01/09
08:56:44 AM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   Anders Rundgren <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked], "Bosch,
      J.C.F.v.d." <[email-masked]>
Subject:  [tf-lsd] Re: Basic Cert-2-Directory mapping question

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

Anders Rundgren wrote:
> due to this mapping problem.  Does Novell offer a more flexible use of
> /anders

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 09 Jan 2001 08:42:03 -0700

Peter, it's obvious that your talents are being wasted.  You could easily
be the Michael Crichton of the PKI industry, and go on to fame and fortune.

I can see it now -- first a book, which lays out in layman's terms what ASN.1 is
really all about, then a mild little spin -- nothing too far fetched or provably wrong --
and then the story line commences.  Suddenly, certificates are stretching
endlessly throughout all time, the inevitable consequence of "nonrepudiation"
being stretched, not too implausibly, both forwards and backwards.

Then the movie begins, with a subterranean bass that requires Dolby 5.1 and 
at least 40,000 watts of powered subwoofer to do it justice.  Without warning
(well, maybe a bit of Carnival of the Animals leitmotiv), an innocent MPEG movie 
of a cat playing with its master, embedded in an antique certificate DN like a 
mosquito in a bit of amber, is morphed back through time to the ancestral 
saber-tooth tiger, devouring its prey in the carbonaceous (as opposed to 
siliconaceous) Internet jungle, complete with T3 vines and monolithic (one rock) 
servers.

Man, that ASN.1 is really, really powerful stuff!  Who needs XML?!

Bob

>>> Peter Gutmann <[email-masked]> 01/09/01 08:35PM >>>

Peter :-).

---

From: "Slone, Skip" <[email-masked]>
Date: Wed, 10 Jan 2001 14:17:44 -0500

As the traffic on this topic points out, there are a lot of people who see
this as an issue.  Whether we can agree on exactly what the issue is and how
to proceed may be another matter ... :-)

As have many others on this list, I've been giving this issue some thought
lately, focusing on the problems as seen from the perspective of a large
user like my company. Although I've come to a different set of conclusions
from those discussed so far in this thread, my energy has been focused on
the same problem that Bob Jueneman pointed out: knowing the location of a
directory service provider that is supposed to contain the DN. 

My basic premise is that if we can come up with a deterministic algorithm
that takes an arbitrary (but reasonably well structured) DN and resolves it
to a set of FQDNs where one can find LDAP services, we can deterministically
get from the DN to the associated directory entry.  As Steve Kent pointed
out, there exists a body of work to do this in the limited case of DNs based
on (DNS) domainComponent naming.  My thoughts are along that line, but
expand to cover the so-called "civil" naming constructs in DNs, such as
country, organization, and so on.  I think that's the goal Anders originally
stated, starting this whole thread.

If people are interested, I'll summarize the algorithm I've come up with so
far and distribute it for review.  If need be, we could consider whether
this is worthy of an I-D, or a BOF at Minneapolis, or whatever...

Regards,

 -- Skip Slone
    Lockheed Martin

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 10 Jan 2001 14:50:40 -0500 (EST)

Skip,

Doesn't the existence of a deterministic algorithm depend on users
of civil (Country-based) names following the rules?

As Michael Ströder pointed out, everyone wants a short name in a
flat namespace.  But not every Joe's Bar & Grill in the US can
have certificates with the name "C=US, O=Joe's Bar & Grill".  If
TTP CAs are willing to issue such certificates without evidence
that the name has been registered with the US national authority,
what algorithm can possibly find all the directory entries for
that DN?

Dave

> From: "Slone, Skip" <[email-masked]>
> Subject: RE: Basic Cert-2-Directory mapping question
> To: [email-masked]
>

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 10 Jan 2001 16:12:43 -0500

I'm not convinced that name mapping would actually satisfy the requirement
because 
the issuer and the subject of a certificate may have DNs that are not 
linked in the manner you are expecting (e.g. a service provider (lets call 
it c=us; o=certpump) might issue certificates to users who have DNs such 
as cn=Skip Slone, o=Lockheed Martin, c=US. It might very well be the public
provider that maintains the repository for the certificates it issues and 
the fact that Lockheed Martin also maintains a directory with entries for 
those users doesn't necessarily mean you'll get to the right place.

That is one of the reasons the PKI repository locator service draft is
different
from the SRV draft the LDAP group defined. Specific to PKI, a domain places 
SRV records for the different protocols that can be used to reach their PKI 
repository. At present it can provide LDAP records, and others but is
queried on domain name
and perhaps what would help would be a way to get you to a domain domain
name so 
that you could then query for the SRV records for that domain's PKI
repository?

One more point, that I think Steve already mentioned is that there are hints
available
already in the SIA and AIA. If we take this back to a "what are we 
trying to achieve" level it would sure help me. 

If you are verifying a signature, you already have the EE cert and are
either 
retrieving revocation information or an intermediate cert. These extensions
should be 
useful for that. If you need to encrypt for another user (e.g. an email),
that is where
the PKI repository locator issue seems to be the biggest. For email, you
have the email 
address so you know the domain name and can use PKI repository locator
service to obtain 
SRV records that give you the necessary information to connect to the
repository that holds
the PKI data for that domain. 

If you can outline the type of environment where none of the above provides
what is needed 
that will at least help focus the discussion better. I've skimmed very
quickly through the 
messages in this thread and apologize in advance if this is already stated
but I missed it.
I do tend to pay more attention to the shorter messages than the longer ones
:-(

Thanks 
Sharon

> -----Original Message-----
> From: Slone, Skip [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 3:27 PM
> To: 'David P. Kemp'; [email-masked]
> David, 
> Only somewhat tongue-in-cheek, I'll say the answer to your 
> question is "only
> if you want the right answer" ;-) 
> 
> As I see it, we're dealing with the fact that we have extant 
> DNs all over
> the map with no semblance of a registration authority. 
> Consequently, we have
> no reasonable way of getting from an arbitrary DN to a 
> directory service.
> The closest thing to a global registration authority that 
> exists is DNS
> (including, of course, its whole supporting cast). As such, 
> it made sense
> for the Internet community to tackle those names found within 
> the current
> DNS struture.  What I would like to propose is that we build 
> on that success
> and extend the authority of DNS into other parts of the DN 
> namespace.  To do
> so requires the definition of some mappings (namely c=XX to 
> <ccTLD>) and the
> creation of a way (i.e., a new DNS RR type) to use DNS to 
> register names
> traditionally associated with X.500/LDAP.
> 
> By way of example, what I'm talking about is the ability to 
> take a DN of the
> form "cn=Skip Slone, o=Lockheed Martin, c=US" and determine 
> that the LDAP
> server to check is found at (for example) ldap1.external.lmco.com. 
> 
> That said, such registration in DNS, combined with a 
> deterministic algorithm
> will return a result of the following form:
>  a) the DN maps to an LDAP server found at foo.com, OR
>  b) the DN does not map to a registered LDAP server
> 
> If you get answer "a" you then send an LDAP query to 
> foo.com:389 to find the
> entry itself. 
> 
> To answer your question properly, I would contend that if 
> "o=Foo, Inc." is
> not registered under these rules, you would get answer "b".  
> Even though you
> don't find the entry, you still get a deterministic response.
> 
>  -- Skip
> 
> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 2:51 PM
> To: [email-masked]
> > this as an issue.  Whether we can agree on exactly what the 
> issue is and
> how
> > that takes an arbitrary (but reasonably well structured) DN 
> and resolves
> it
> > out, there exists a body of work to do this in the limited 
> case of DNs
> based
> > If people are interested, I'll summarize the algorithm I've 
> come up with
> so

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 12 Jan 2001 00:19:53 (NZDT)

I've got a slightly older copy of the papers I mentioned a few days ago 
available online, they're linked via my home page 
http://www.cs.auckland.ac.nz/~pgut001/, with the text extracted below.  There 
are also some slides from my talk at ACSAC which cover some things I didn't 
have room for in the paper, I'll put those online within the next week.  I'd 
be interested in feedback.
 
-- Snip --
 
One section of my thesis, which covered certificate stores, had to be dropped 
due to size constraints.  As with the work in the other chapters, it begins by 
analysing the requirements (in this case for a reliable, scalable, 
general-purpose certificate store), and then examines various potential 
candidates which might meet these requirements.  The single chapter ended up 
broken down into two papers because of its size, the first paper (published at 
ACSAC 2000) mostly stands by itself but the second one, not yet published, is 
rather lopsided and needs the first paper to lean against.  Both have had some 
minor revisions made based on feedback which postdate the online versions, in 
addition the second one (which was put together in a bit of a hurry at the 
same time my thesis was due and definitely isn't my best work) covers a 
slightly older design than what's currently being used and needs some changes 
to bring it up to date.  I also need to add pointers to work which has 
appeared after it was written such as the CCS 2000 papers on undeniable 
attestations and fault-tolerant revocations, which is similar to the scheme 
which I examine in the second half of the paper.  Don't treat this as a 
finished work.
 
The first paper, http://www.cryptoengines.com/~peter/09a_cert_store.pdf A 
Reliable, Scalable, General-purpose Certificate Store has a pretty 
self-explanatory title.  The second one, 
http://www.cryptoengines.com/~peter/09b_cert_store.pdf Certificate Management 
as Transaction Processing looks at certificate and certificate 
status/revocation management from a TP perspective.
 
-- Snip --
 
Peter.

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 11 Jan 2001 09:53:49 -0500

For item 1, clearly a non-issue. For 2, it might still be helpful to 
have search base information in an SRV record, especially if it is in the
same PKI repository locator service record. It will eliminate that extra
call to the directory to get the naming context info and might also help in
cases where a third party service provider is operating the directory and
has a large number of naming contexts, only one of which is of interest for
a specific domain's PKI data. I agree that the basics are already there, but
as PKI deployments grow to very large scale, some efficiency could be be
achieved by reducing the number of calls required to a directory and the
amount of data returned from each call.

Sharon

> From: Michael Ströder [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 9:15 AM
> To: [email-masked]
> Sharon Boeyen wrote:
> > Finding a particular certificate is
> > one problem and determining whether or not to 'trust' and make use
> > of it is another.
> 
> Agreed.
> 
> > I do agree that 2377 and the PKIX repository locator document are
> > a nice fit and will satisfy a lot of the requirement for many
> > environments.
> > [..]
> > we don't yet have an answer is the provision of search base
> > data for LDAP SRV records for PKI repositories.
> 
> ??? You simply don't have to provide the LDAP search base in DNS.
> 
> 1. If you are using RFC2377 naming and RFC2782 SRV records you're
> looking up the server's DNS entry/IP address by already knowing the
> dc-style search base. If you want to locate the entry of a given
> e-mail address I would suggest that one searches all the sub-domains
> up to top-level domain if you can find a SRV record. After that you
> do a search for the e-mail address with this matching search base.
> 
> 2. If you contact a given LDAPv3 server you can retrieve his search
> base(s) by looking at the namingContexts attribute in the RootDSE.
> (A similar non-standard work-around exists for UMich-derived LDAPv2
> servers.)
> 
> Example for 1.:
> 
> a) Assuming you want to locate an entry for
> [email-masked] for retrieving the certificate and your
> client implementation is capable of searching the SRV RR in the DNS.
> 
> 1. You search for SRV record _ldap._tcp.www.stroeder.com. -> no
> result
> 
> 2. You search for SRV record _ldap._tcp.stroeder.com. -> RR points
> to LDAP server directory.adm.stroeder.com.
> 
> 3. You're doing the LDAP search
> ldap://directory.adm.stroeder.com/dc=stroeder,dc=com??sub?(mai
l=[email-masked])
> 
> b) If your client implementation is not capable of searching the SRV
> RRs itself but is able to follow LDAPv3 referrals (search
> continuations) it uses a service like described on
> http://www.openldap.org/faq/data/cache/393.html and gets redirected
> to the right server when doing a search like
> ldap://root.openldap.org/dc=www,dc=stroeder,dc=com??sub?(mail=
[email-masked]).
> 
> Now what's the problem? This can all be done without writing a new
> draft or modifying an existing one. Just a matter of implementing
> it...
> 
> Ciao, Michael.
>

---

From: "Slone, Skip" <[email-masked]>
Date: Thu, 11 Jan 2001 10:19:34 -0500

RFC 2377 proposes using dc-based naming as an alternative to "civil" naming
schemes. Such naming schemes (using RDNs constructed from attributes such as
country, stateOrProvince, organization, etc.) were originally published in
an Informative Annex to X.521. Neither scheme is mandated anywhere (civil is
documented in an Informative Annex; RFC 2377 is an Informational RFC).
Consequently, in the real world, we have both.

As you have suggested, RFC 2377-style names are readily resolved using the
approach outlined in pkixref; X.521-style names are not. If we could assume
the whole world would convert to RFC 2377-style naming, we wouldn't have to
worry about resolving civil names. However, as long as we have civil names
lying around in certificates and elsewhere, we have to either deal with them
or choose to ignore them. 

 -- Skip

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:47 AM
To: Slone, Skip
Cc: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
> Since civil-to-DNS name mapping typically fails to yield to a
> character string transliteration algorithm (e.g., "o=Joe's Bar and
> Grill" does not readily translate to are-you-hungry.com), this leaves
> us with a choice of either registering the translations or
> complaining that it can't be done.

Pardon my ignorance of these matters, but where exactly is this civil
naming scheme outlined?

IMHO the DNS-based naming scheme for in RFC 2377 has been around for a
couple years now, and when combined with the repository locator
documents I'd say it provides the information necessary for an RP to
locate the relevant repository.

//oscar

---

From: "Slone, Skip" <[email-masked]>
Date: Thu, 11 Jan 2001 13:02:39 -0500

One example is to find associated attribute certs.  See the following sample
paragraph taken from
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-06.txt:

   In other cases, it is more suitable for a client simply to
   authenticate to the server and for the server to request or "pull"
   the client's AC from an AC issuer or a repository. <<<<------- !!

 -- Skip

-----Original Message-----
From: Robert Klerer [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 12:12 PM
To: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Please excuse my ignorance, but if I have the certificate why would I need a
repository where the certificate is stored? I need CRLs, but there is an
extension for that and has little to do with the subject DN in EE cert.  The
only use I have for a repository is to find certificates if I know an EE's
name -- which brings up the real problem of mapping an EE name to a DN.  The
"other attributes" is meaningless in this discussion since they would be
unsigned and I would have an apriori trust of the repository, thus I know
where to go beforehand.

Here's a use case that fits my scenario:

An RP needs to find a directory entry corresponding to a given certificate,
where:
 - the certificate subject name uses civil-style naming,
 - the RP's known directories have no knowledge (direct or indirect), and
 - the subject's domain name is not known and cannot be derived.

With today's tools, this use case fails:
 - LDAPv3 referrals fail due to the lack of knowledge,
 - PKIXREP fails due to the lack of a domain name.

Am I overlooking some tool that can do the job?

 -- Skip

-----Original Message-----
From: Michael Ströder [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 10:31 AM
To: [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
>
> If LDAPv3 referrals were sufficient, we wouldn't be having this
> conversation.

Who said that LDAPv3 referrals are the overall solution without
prior configuration?

> LDAPv3 referrals WILL work in the following two cases:
>
> 1) where my server's administrator already knows how to
> find the target name
> space, or
> 2) where my server and the server holding the target name space
> participate in some fully-connected DIT
> [..]

Yes.

> What I'm discussing is a way to fill in the gap where (1) my server does
not
> already know how to find a certain name space, and (2) there's a knowledge
> disconnect between my server and the server holding the target. In this
> case, LDAPv3 referrals WILL NOT work.

Yes.

And RFC2377 does not work without SRV RRs. Yes. And I can't access
http://www.ietf.org without somebody having added the entry
www.ietf.org to DNS. Yes.  And... Yes.

No doubt, if you do not know any service access point or you don't
have any rule how to derive the service access point from an
information at hand you can't access the service. Yes.

Now about which *use-case* are we talking here?

Ciao, Michael.

---

From: Sharon Boeyen <[email-masked]>
Date: Fri, 12 Jan 2001 09:18:43 -0500

OK now we're getting to the 'focal' point I was hoping we would.
 
It seems that we are basically in agreement that both the 'civil attributes'
type of DNs and the domain 
component attributes for DNS structured DNs are currently being used and
will likely continue to be used. We also seem to be in agreement that both
are hierarchical name structures. I think it is also fairly safe to say that
the extensions we already have in certificates, combined with the PKI
repository locator service seem adequate for identifying and locating the
PKI repository of interest in most cases for both types of DN structures.
The single exception to this is, as pointed out by Skip, the one where all
the following conditions are met: A relying party needs to obtain an
end-entity certificate for which it does not know the domain name and it
cannot be easily derived from information the relying party does have (and
therefore the PKI repository locator service won't provide the required
information) and the relying party's local environment does not have a
priori knowledge of the remote domain's repository. I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense. 
 
While I don't disagree with Skip's assertion that the mapping of civil DNs
to DNS names might be useful in the general directory sense, I agree with
Steve that this directory issue is not one that PKIX needs to tackle in
general. However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do. Otherwise, we already
have all the tools we need to satisfy the PKI information retrieval problem.
 
Sharon 
 
 -----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip, 

I would just like to add that, in addition to X.521 and some LDAP specs, the
ability to recognize civil naming attributes in the issuer and subject
fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and
in son-of-2459. 

Ironically, the requirement for support for Issuer names (DNs) vs. allowing
an Issuer alname in lieu of a DN, arose because the S/MIME WG was relying on
the presence of an Issuer DN in their design, and I believe the motivation
for it (Russ can confirm or correct this notion) was to facilitate directory
lookup for certs in S/MIME! 

<snip> 

Steve

---

From: "Ed Reed" <[email-masked]>
Date: Fri, 12 Jan 2001 17:16:16 -0700

As a case in point, nobody really needed those
32 bit ip addresses with all that subnetting and such...

48 bit mac addresses (flat addressing, with hierarchical
subregistration for manufacturers) are surely sufficient...

And if not, then the 128 bit UUIDs of IDL/IIOP/msRPC
will certainly do, right?

Yes, flat works within a context.

Yes, directory weenies like me tend to create too many
contexts, and stack them hierarchically to support delegation.

Interestingly, what the world keeps returning to is a roughly
4 level stack:

some naming scheme (dns, joint-iso-ccitt, broadcast SMB or SAP)
some top level thing (o, .com or .co.uk, c=us, whatever)
some organizational association (aol.com, Visa, ietf.org)
some individual name (eer@, skip.slone@, etc).

Commerce has a similar hierarchy:

earth or government
industry or other community of interest
company
individual

But flat don't work when you want to ask "earth" what "Ed's" email address
is, and repeated attempts to make it work shouldn't be suffered to survive.

E

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COMd
>>> Stephen Kent <[email-masked]> 01/10/01 02:55PM >>>
At 9:08 AM +0100 1/10/01, Michael Ströder wrote:
>
><snip>
>
>=> People are used to flat name spaces. X.500 DNs does not work.

Flat name spaces scale poorly, lead to confusion, and are thus not 
attractive in various ways.  People do like flat name spaces, until 
they trip over the limitations they embody, then they complain and 
look for magic solutions. I've seen no appropriate magic for this 
problem.

Steve

---

From: "Slone, Skip" <[email-masked]>
Date: Mon, 15 Jan 2001 11:08:50 -0500

Oscar,

No offense taken, thus no apology needed. 

My comments from the soapbox last week were actually intended for the
community at large, and were meant to convey frustration at the apparent
unwillingness of solution providers in general to hear about -- and solve --
real world problems that are faced by users like myself in large, complex
environments.  

When I say "my environment is not so simple," the response I hear is "let's
not talk about the complexity; let's make some simplifying assumptions
instead."  

When I say "I have a nail AND a screw and need to put them both in the
wall," the response I hear is "we have provided you with a perfectly
adequate hammer, therefore you don't have a screw."

As I was using the nail/hammer analogy, dc-based names are the nails;
civil-attribute-based names are the screws. No matter how good a job my
company does of using nails and nails alone, we still have tens of thousands
of trading partners, many of whom prefer screws to nails and will continue
to use them indefinitely. Without a screwdriver, it's hard to do business
with them.

I don't really care what the screwdriver looks like.  I've suggested a
fairly simple design that I think will work. So far, no one has commented on
the design. What I've heard instead is a chorus of "we still don't like
screws."  Well, I don't like them either, but I still have to deal with
them.  If I'm simply overlooking a screwdriver that we have lying around
somewhere, I would appreciate someone pointing it out to me. 

 -- Skip 

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 5:16 PM
To: Slone, Skip
Cc: 'Sharon Boeyen'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

> In response to this, I'm inclined to join Sharon on Marshall's soapbox and
> echo her words:
>
> "... I believe a more constructive approach is to accept the fact that
> different parts of the world and different environments will use a variety
> of nameforms ... We are not the global naming police either and should not
> try to impose the rules that anyone uses to name entities to which they
> issue certificates."

I'm sorry if I came across as clamouring for rules be imposed. I know that
this working group has a tendency to be wary of suggestions that don't cater
for distinguished names containing cat MPEGs, so I should probably have been
more careful. The requirements I suggested were for a possible naming
standards document, conformance to which need not be enforced.

The case at hand is not, IMHO, one of dictating that "all distinguished
names must be according to our will, or you shall feel our wrath". A
document however, outlining a naming strategy that would require of the
users of certificates named accordingly no a-priori knowledge of their
issuer (save for eventually having to reach something explicitly trusted in
the chain) in order to perform path validation, is something I would
personally consider very valuable indeed. I'm reasonably confident that
organizations intending to act as certification authorities or trusted third
parties would agree.

> And to quote someone Sharon and I both know, "If all you have is a hammer,
> every problem looks like a nail."

It seems I was less than clear here as well. :-(

My intention was to point out that there are actually two separate problems
here (one nail, if you will, and one screw) each looking for its own
solution:

1. Defining a repository, and subsequently entry, discovery process for
arbitrarily named entries.

2. Defining a naming scheme that _if applied_ would automate this repository
and entry discovery process.

I am only trying to address the second of these problems. The first is only
an issue because nobody seems to have properly addressed the second before
deploying certificates on the Internet en masse. The further we wait before
addressing number two, the more of a problem number one will become.

I should probably make a habit of pointing out that the opinions stated here
are my very own, and not necessarily those of my employer.

Cheers,

//oscar

---

From: "Slone, Skip" <[email-masked]>
Date: Mon, 15 Jan 2001 12:54:26 -0500

[Sharon]  It seems that we are basically in agreement that both the 'civil
attributes' type of DNs and the domain 
component attributes for DNS structured DNs are currently being used and
will likely continue to be used. 
 
[Skip]  Agreed.
 
[Sharon]  We also seem to be in agreement that both are hierarchical name
structures. 
 
[Skip]  Agreed.
 
[Sharon]  I think it is also fairly safe to say that the extensions we
already have in certificates, combined with the PKI repository locator
service seem adequate for identifying and locating the PKI repository of
interest in most cases for both types of DN structures. 
 
[Skip]  I'm not sure I understand what you mean by "the [tools] we already
have ... seem adequate ... for both types of DN structures."  Maybe I'm
overlooking the obvious, but I don't see support structures for
civil-attribute-based DNs.
 
[Sharon]  The single exception to this is, as pointed out by Skip, the one
where all the following conditions are met:  <snip> I guess typically this
would be an environment where there is more than one internediary
certificate in a path because if two domains directly cross-certify with
one-another they would provide repository access information to each other,
otherwise the cross-certification makes no sense. 
 
[Skip] I see this need most acutely in those instances that occur near the
boundaries of a business relationship. That is, when a relationship is in
the early stages of being formed, or if some break has occured in a business
relationship (due to mergers, acquisitions, etc.), there is a sharp drop in
the likelihood that the requisite knowledge is already in place.  Once a
relationship has been established, the whole repository locator issue
becomes a moot point. Until then, it can be a big deal.  The "problem certs"
are not the ones that are commercially issued; the problem arises when
certificates are issued by a private CA that is certified (directly or
indirectly) by a commercial CA that I happen to trust. 
 
[Sharon] While I don't disagree with Skip's assertion that the mapping of
civil DNs to DNS names might be useful in the general directory sense, 
 
[Skip] In the absence of a well-connected DIT (complete with globally
accessible first-level DSAs, a functional c=US, etc.) distributed X.500/LDAP
name resolution has been, and will continue to be an unmitigated failure.
By leveraging an existing, global, ubiquitous infrastructure, the mapping
I've suggested is intended to solve a big portion of this name resolution
problem.
 
[Sharon]  I agree with Steve that this directory issue is not one that PKIX
needs to tackle in general. 
 
[Skip] While I completely agree that the charter of PKIX is NOT to solve
general directory issues, it seems to me that it is within the charter of
PKIX to consider problems that users report with PKIX as currently defined,
and to give due consideration to whether any proposed solution does indeed
solve the reported problem.  If the solution is then deemed to be too
general, the work can, of course, be moved elsewhere.
 
[Sharon] However, if the scenario above is one that PKIX needs to find a
solution to (as opposed to determining that its not relevant since Internet
applications will generally have domain names and can therefore use PKI
repository locator service regardless of the DN structures in the certs or
the directory entries), then we have some work to do. 
 
[Skip] Agreed.  I can offer some cycles to do some of this work.
 
[Sharon] Otherwise, we already have all the tools we need to satisfy the PKI
information retrieval problem.
 
[Skip] I'm still looking for something other than a hammer :-)
 
 -- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

 
 
Sharon 
 
 -----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip, 

<snip> 

Steve

---

From: "Slone, Skip" <[email-masked]>
Date: Tue, 16 Jan 2001 09:16:13 -0500

Bob,

I'm glad to hear we agree on the nature of the problem.  From that point of
agreement, we can move the discussion to one of "what do we do about it?"

In abstract terms, it appears to me that "what we can do about it" falls
into two broad categories:
 1) we can create a mechanism for explicitly identifying the appropriate
directory, or 
 2) we can remove the barriers that currently prevent the directory from
being discovered implicitly based upon existing information

I would say that your approach fits in category 1, while my approach fits in
category 2. Either approach has validity IMHO and is worthy of
consideration. 

As I read your suggestion, you want to add an element to the DN that directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different.  The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.  

Assuming we're on the same page up to this point, I'll say that my concern
with this approach is that it changes the semantics of DN, potentially
causing interoperability problems in that both clients and servers that
understand the semantics as currently defined would have problems when
encountering the new-style name.  If we were to go with a "category 1" fix
to the problem, I would rather see a new mechanism employed, such as a new
PKIX-defined certificate extension that explicitly gives repository location
information.  As a new construct, we would be free to define whatever
semantics we want, and could readily use existing concepts such as URLs.

Now, in defense of my approach, I think we can all probably agree that *IF*
the original concept of X.500-style distributed, global name resolution were
a practical reality, we would be able to plug into the nearest DSA and find
the named entry regardless of where it resides physically. Of course I
emphasized the word "if" to imply that we can also probably agree that that
original X.500 concept is not going to occur anytime soon, if ever. What I
was proposing instead, was a "category 2" fix -- a way of removing that
barrier by providing an alternative way of doing distributed name
resolution.  The alternative mechanism I proposed was one which builds upon
an existing, working, global infrastructure that already has the requisite
registration infrastructure in place.  Without digging into the specifics, I
would like to know if you or others believe that this *concept* has merit.

 -- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip, 

I don't particularly like the mechanism you've proposed, at least as 
I understand it. But I absolutely and completely agree with you
as to the nature of the problem that has to be solved.

Civil attribute type names will always be with us, and hence must be
dealt with, for at least two fundamental reasons:

1.  An address is not a name, although it may be a pseudonym.  I 
don't want to be forced to change my identity, or to an extent
my basis "self-hood," every time I change my ISP.  And I especially
don't want some system administrator telling me that my name
must be limited to 8 characters, or that I have to change my name
because someone else has already used that same name within 
that same system administrator's ill-conceived naming scheme.

2.  E-mail address and other cyberspace identifiers fail to provide the
essence of PKI from a nonrepudiation standpoint, i.e., what I call the
"where do you send the sheriff" question.

Granted, not all uses of PKI will or should involve legal nonrepudiation.
But to the extent that at least some uses WILL have legal consequences, 
then the establishment of a globally unique and credible identity that is
grounded in "meat-space" rather then cyberspace is absolutely essential.

For those legally binding transaction to be worth anything at all, they 
have to be enforceable. And that means that a judgement may have
to be enforced upon someone, either by seizing the assets or putting 
them in jail.  And only in science fiction does the sheriff ride off into 
cyberspace to arrest someone.

If I as a relying party wish to trade with someone, then I either want to 
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere St,
Metropolis, NY.

The inclusion of that civil address not only servers to distinguish her 
from the other Mary Smiths, but more importantly it establishes a nexus
or link between her identity and her probable whereabouts, and 
probably valuable real property as well.

So civil addresses, both corporate or "organizationalPerson", or the 
harder-to-deal-with residentialPerson type will presumably always 
be with us, and will have to be dealt with.

And unfortunately, perhaps, here int he US the simple and inescapable
fact of the matter is that neither the federal nor the state governments 
operate the type of presumptively authoritative name registration 
authorities that are relatively common in other countries. I am perfectly 
free to move from one city to another, or from address to another in 
the same city, and to never notify anyone in authority at all, including 
the tax authorities.  No one will ever say, "Papers, please."

(Granted, if I choose to do that I may not be able to register to vote, 
but over half the population doesn't vote anyway.  And the last time 
I registered, no one checked to see that I actually lived there -- that 
one of the problems we have with our voting system, even outside 
of the State of Florida.. And I may not be able to get a driver's license 
in order to legally drive a car, but a lot of illegal immigrants don't have 
driver's licenses either, although that doesn't keep them from driving.)

So merely trying to ignore the problem of civil addressing schemes 
won't solve that problem.  And neither will various approaches that 
make certain assumptions about monopoly name registration 
authorities, or try to divine or impute where a directory containing 
a particular name might be found based on some kind of a Karnak
mentalist act.

The primary issue is not the question of whether the name space
is flat or hierarchical, or how hierarchical, much less what the 
"approved" schema is.  What will be, will be, for reasons that
are beyond our scope and power to influence, even if we wanted
to.

So.

We cannot force a person to deposit his certificate or other useful 
information into a specific directory, even if we wanted to.  Nor can 
we reliably impute a likely directory where such information might
be found, at least in the absence of a monopoly or governmental
mandate.

The best we can do is to ASK the user where he has deposited
such information, if anywhere, and to include that information
EXPLICITLY in any directory or pseudo-directory reference, such 
as a DN.

Although at one time I liked the notion of prefixing the DN with a 
URL, I have come to believe that John Wray's suggestion is the
better way forward.

>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a

By including an explicit directory qualifier of the form dir="directory URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest 
of the RDN, which is a Good Thing.

By defining the syntax of the "dir" attribute appropriately, we could
include 
both the access type (LDAP, http, etc.) and port number appropriately,
either a default or explicitly indicated.

And by making the dir component multivalued, we could accommodate
a choice of multiple directories and multiple directory types.

Once again -- the essence of the problem is not the format of the directory
name but where a directory containing that name can be found.
Including that information as a top-level qualifying component solves that
problem (and potentially several others, such as name scope qualification) 
very neatly.

Bob

Robert R. Jueneman
'Security Architect
>
>
>
>
>
>
>
>>>> "Slone, Skip" <[email-masked]> 01/15/01 09:08AM >>>
>Oscar,
>

---

From: "Slone, Skip" <[email-masked]>
Date: Tue, 16 Jan 2001 09:17:33 -0500

Sharon, I think I can say that we're on the same page at this point.  See my
recently posted note to Bob for my thoughts on what we can do in those
instances when we need a screwdriver.
 
 -- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Monday, January 15, 2001 3:13 PM
To: 'Slone, Skip'; 'Stephen Kent'
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Hi Skip, 
 
What I meant by the tools was that the SRV records are populated by CAs,
some of which use the geopolitical DN style and others that use the dc
style. Regardless of what style of DN they use, all queries for SRV records
are based on a domain name. If that domain name is known, or can be derived
(e.g. by the email application from the email address), then the SRV records
can direct you to the right PKI repository. 
 
The need for a screwdriver is when you don't know the domain name and can't
derive it, but need to identify and locate the PKI repository for a
geopolitically structured DN that you do know.
 
Cheers,
Sharon

-----Original Message-----
From: Slone, Skip [mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:54 PM
To: 'Sharon Boeyen'; 'Stephen Kent'
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

[Skip]  Agreed.

[Skip]  Agreed.

 

 

 

 
 
 -- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Friday, January 12, 2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

 
 
Sharon 
 
 -----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip, 

<snip> 

Steve

---

From: "Slone, Skip" <[email-masked]>
Date: Tue, 16 Jan 2001 09:26:05 -0500

Oscar,

Just a quick response to your specific critique...

[Oscar] One issue I have with this is that it violates one of the central
premises of Sharon's "soapbox address" by placing the assumption on DNs
that they employ a specific naming scheme, in this case one with a
"C=xxx, O=xxx" root.

[Skip] Actually, this was not where I was coming from at all. As I see it,
we currently have two documented approaches to naming, neither of which is
mandatory, both of which are in use: (1) RFC 2377, which recommends the use
of dc-style naming, and (2) the X.521 informative annex that recommends the
use of C=xx, O=xxx -style naming. What I was doing was acknowledging that
both name styles exist and will probably continue to exist indefinitely.
Based on that recognition, I was proposing that a relatively simple
modification to DNS could conceivably (with some more work, of course) help
resolve the latter type of names to a point where pkixrep can take over and
get us to the repository.

 -- Skip

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 5:18 AM
To: Sharon Boeyen
Cc: 'Slone, Skip'; 'Stephen Kent'; [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

All,

this thread has progressed a bit since last I checked, so I hope you'll
forgive me for skipping to the front.

Regarding our precious screwdriver, the primary functional requirement
for said tool, to paraphrase Sharon, would then appear to be:

"The screwdriver shall identify and locate PKIX repositories for
Distinguished Names."

Or is it important that this method only be used failing derivation or
a-priori knowledge of the repository location?

Is it also important that the DN be "geopolitically" structured, or can
I interpret that as "non-domainComponent" structured?

Skip has already proposed a solution, which I'd like to address:

"What I'm proposing is the development of a new DNS RR type that allows
the registration of arbitrary attribute value assertions (such as
"o=Something" or "ou=Something Else"). These new RRs (let's call them
AVA RRs) would resolve to a domain name that could subsequently be used
to construct the right hand portion of a PKIXREP query (or some other
SRV-seeking query).  A remaining critical piece is the specification of
c=XX as equivalent to a corresponding ccTLD. As an example, when
resolving a DN ending in o=Entrust, c=CA, one would first query .ca for
an AVA record matching "o=Entrust", and would get a response such as
"entrust.com" which would then be used to generate a query along the
line of _PKIXREP._LDAP.entrust.com."

One issue I have with this is that it violates one of the central
premises of Sharon's "soapbox address" by placing the assumption on DNs
that they employ a specific naming scheme, in this case one with a
"C=xxx, O=xxx" root.

Regards,

//oscar

Sharon Boyen wrote:
> Hi Skip,
>
> What I meant by the tools was that the SRV records are populated by
> CAs, some of which use the geopolitical DN style and others that use
> the dc style.  Regardless of what style of DN they use, all queries
> for SRV records are based on a domain name. If that domain name is
> known, or can be derived (e.g. by the email application from the
> email address), then the SRV records can direct you to the right PKI
> repository. 
> 
> The need for a screwdriver is when you don't know the domain name
> and can't derive it, but need to identify and locate the PKI
> repository for a geopolitically structured DN that you do know.
> 
> Cheers,
> Sharon

---

From: "Slone, Skip" <[email-masked]>
Date: Tue, 16 Jan 2001 15:45:17 -0500

John,

You wrote, "I don't think the proposed "dir" attribute is semantically very
different
from any other naming attributes" and that "the mechanism for searching has
to treat the "dir" RDN somewhat differently from the other RDNs."

My concern with different semantics is not a matter of degree; it's the fact
that the semantics of DN must change -- at all -- to incorporate this
concept. If there are other ways to deal with the problem, I see no
compelling reason to change the semantics of something so fundamentally and
deeply entrenched in dozens of standards as DN. 

I must add here that I have not always opposed this concept. I actually
pursued this line of thinking two or three years ago in a different forum
(X.500) while working a different problem (Related Entries). At that time, I
was proposing that a "dnQualifer" be added to a DN to specify an access
point through which the entry named by the DN could be found. While pursuing
that line of thinking (which explored several syntactic/semantic variants),
the semantic-shift problem kept getting in the way. In the end, we settled
on a separate mechanism rather than change the semantics of DN. Flawed as it
may be, DN is still a widely accepted concept; changing it will be an uphill
struggle.

 -- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

>As I read your suggestion, you want to add an element to the DN
>that directs the user to the appropriate directory. The new
>element is syntactically an RDN, but semantically is something
>different.  The resulting new-style DN appears to me to
>semantically comparable to an LDAP URL.

I don't think the proposed "dir" attribute is semantically very different
from any other naming attributes.  What we're trying to do with names in
certificates is to maintain the X.500 illusion that a DN uniquely
identifies an entry in some global directory.  But we don't have a single
global directory; instead we have a collection of directories which don't
talk to one another - i.e. instead of the single DN root assumed by X.500,
we actually have multiple roots, one for each directory.

The obvious way to resolve this sort of problem is to introduce a new
"meta-root" that sits above all the directory roots.  This corresponds to
adding an RDN to the most significant end of each DN that names the
particular directory within which the named entry lies.  Precisely how a
directory is named is TBD, but it must give an end-system enough
information to for a query for that directory, without requiring prior
knowledge of the directory, so an obvious possibility (for an LDAP
directory) is scheme and hostport portions of an LDAP URL.

Individual directories could either store this attribute explicitly within
the entry (which would mean that these directories could be directly
searched using the full DN) or, more likely, the "dir" attribute would have
to be removed before searching an individual directory.  So yes, the
mechanism for searching has to treat the "dir" RDN somewhat differently
from the other RDNs, but in terms of a naming model, it behaves just like
any other RDN.

As Bob points out, the "dir" attribute could be multi-valued, allowing
information about an entry to reside in multiple directories (provided that
the directories can all agree to use the same name for the entry).

John

"Slone, Skip" <[email-masked]> on 01/16/2001 09:16:13 AM

To:   "'Bob Jueneman'" <[email-masked]>
cc:   [email-masked]
Subject:  RE: Basic Cert-2-Directory mapping question

Bob,

I would say that your approach fits in category 1, while my approach fits
in
category 2. Either approach has validity IMHO and is worthy of
consideration.

As I read your suggestion, you want to add an element to the DN that
directs
the user to the appropriate directory. The new element is syntactically an
RDN, but semantically is something different.  The resulting new-style DN
appears to me to semantically comparable to an LDAP URL.

PKIX-defined certificate extension that explicitly gives repository
location

the original concept of X.500-style distributed, global name resolution
were
registration infrastructure in place.  Without digging into the specifics,
I

 -- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

If I as a relying party wish to trade with someone, then I either want to
charge her credit card (in which case PKI is demonstrably not necessary)
or I want to know that she is the Mary Smith who resides at 123 Anywhere
St,
Metropolis, NY.

So.

>Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a

By including an explicit directory qualifier of the form dir="directory
URL"
at the root (top) of the RDN chain, we have implicitly qualified all of the
rest
of the RDN, which is a Good Thing.

Bob

Robert R. Jueneman
'Security Architect

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 17 Jan 2001 14:09:40 +1100

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.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Wednesday, 17 January 2001 13:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

Just so it's clear, I probably should have defined at least one use 
model for what we have been talking about -- at least the use 
that I have in mind.

what I'm trying to get away from this the necessity of wasting all
of the bandwidth that is currently being used to repetitively 
download entire certificate chains containing the same information,
over and over again to the same client.  This is particularly the 
case in SSL/TLS and S/MIME, and I predict that when we start 
sending signed EDI transactions it will be the case there as well.

What I want to do to minimize all of this is to send only two things 
with a given transaction -- the digital signature itself, stripped down 
as far as possible; and the name of the signer, in a minimal form 
as possible without imposing a rigid repository schema.

ideally, the name of the signer should be a DN, whether in the form
of a classical civil name structure, and DNS name, or some other form
that is searchable, such as a DUNS number. 

Ideally, the structure of the DN should be compatible with existing 
RDN syntax, but perhaps with the addition of a new attribute type.
I think that we are agreed that SOMETHING new is going to be 
required, and if that is the case a new attribute that is consistent with
the
current RDN syntactic structure would to my mind be preferable to 
introducing something else, such as a URL or URI.

Although I don't want to get completely hung up on the use of a 
dir= RDN qualifier vs. a more explicit URL-type qualifier, I'm don't 
think I agree with your concern about the paradigm shift in the 
DN semantics a dir= type of qualifier would cause.  Maybe I just 
don't understand.

I am inclined to say that "DN semantics" is close to being an oxymoron.
The fact is that the semantic definitions of most of the usual DN 
attributes are conspicuously vague.  Consider "serial", "locality",
commonName,
or even "country".  Yes, we all understand what a country is -- it's 
whatever the UN says it is, or isn't, and questions about disputed
territories
are brushed aside.  But that isn't a semantic definition, that is simply a
name to
territory definition or mapping.  The real question is what is the
relationship
between the country and the end-entity identified by the rest of the DN -- 
is it merely a directory qualifier, or is it the country of residence?,
citizenship? 
place of doing business? location of the home office? country of 
incorporation of an enterprise? If I am referring to a ship, for example,
that 
is owned an operated by a UK company, registered in Liberia ,and 
is currently docked in Miami, what country should I use for the RDN
of that ship?  

Since X.500 doesn't attempt to answer that question, I would claim that 
the only effective semantics for country is as a directory qualifier, under
the 
old universal X.500 directory-in-the-sky assumption of a monopoly directory
service, or at least a monopoly naming infrastructure per country.

Since we know by now that the original assumption is no longer valid, 
if indeed it ever was, we can certainly use country to mean whatever 
we choose it to mean in terms of semantics, just as people have 
distorted the semantics of organization, and particularly
organizationalUnit, to contain just about anything they want.

(I'm not really suggesting an RDN containing a MPEG of my cat, but 
things that are nearly as strange have been done in the past.  
That doesn't make them "right", of course, just ubiquitous.)

But what that leaves us with is the need to qualify what used to be a root,
i.e., country, and to supply a new root, meaning basically who owns, 
operates, and defines the semantics and schema for all of the rest of t
he RDNs which follow.

I would submit that despite the semantic "recommendations" provided by 
the standards organizations, it is really the directory service provider who

defines such things, or in some cases the Certificate Authority who creates
a 
certificate, whether or not they actual deposit that certificate in an X.500

directory

From this point of view, I believe that using a dir= type of directory
service 
provider is not some kind of an ugly hack, but a reflection of reality, and
a 
completely legitimate RDN qualifier.  It specifies in a consistent DN syntax
what the root of the DIT really is -- the name of the directory that
contains 
and defines it.

Now I'll grant that it isn't very likely that existing X.500 directories
would 
suddenly change their DIT structure to explicitly include a dir=  component
at the Top.  But I don't think that would be at all necessary, either -- it
can be
done implicitly.

I wouldn't think it would be all that hard to define the attribute matching 
rules so that if the dir attribute (or one of the multi-=valued RDN
components)
is the DNS address of the directory that is being accessed, the result is 
TRUE, and otherwise FALSE.

Another approach which might or might not work would be to use an alias,
although I don't know whether it is possible to define an alias for a node, 
rather than for a leaf.

For example, in Novell's own DIT, we don't even define c=US as the top 
component, although perhaps we "should".

But I would assume/hope that if we were concerned about that, we could 
define an alias of c=us, o=Novell Inc. to point to the o=Novell node that is

actually at the top of our DIT.

Since you said that you actually considered this type of an approach
at one time, perhaps you can say more about what led you away from 
that approach.  I think you were right the first time.

Regards,

Bob

>>> "Slone, Skip" <[email-masked]> 01/16/01 01:45PM >>>
John,

 -- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked] 
Subject: RE: Basic Cert-2-Directory mapping question

John

Bob,

 -- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked] 
Cc: [email-masked] 
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

So.

Bob

Robert R. Jueneman
'Security Architect

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 17 Jan 2001 07:34:39 -0700

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

>>> "Ramsay, Ron" <[email-masked]> 01/16/01 08:09PM >>>
Bob,

Ron.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Wednesday, 17 January 2001 13:35
To: [email-masked]; [email-masked] 
Cc: [email-masked] 
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

directory

Regards,

Bob

John,

 -- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked] 
Subject: RE: Basic Cert-2-Directory mapping question

John

Bob,

 -- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked] 
Cc: [email-masked] 
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

So.

Bob

Robert R. Jueneman
'Security Architect

---

From: "Slone, Skip" <[email-masked]>
Date: Wed, 17 Jan 2001 12:55:29 -0500

Bob,

A couple of thoughts come to mind while reading your response and subsequent
responses to your response.

First, with respect to your bandwidth conservation approach, it seems like
what you're after is not too far afield from the DPV/DPD discussions going
on in a separate thread. Have you considered that work as a possible way of
addressing your requirement?

Second, given the different directions this discussion is going, I'm having
a hard time telling whether we're saying the same thing or not.  My concern
with DN semantics is only a concern if we introduce a new RDN construct that
behaves differently from any other RDN. That is, if the RDN is constructed
using the distinguished attribute value(s) in an entry, and if that RDN
names an actual entry (or at least something modelled as a DSE), then I have
no concerns about semantic drift. On the other hand, if the thing that is
syntactically an RDN has no relevance to a directory entry, but is actually
closer to the concept of a DSA's access point, then I have a problem since
such a construct would cause breakage to occur with existing clients and
servers.  At one point, I thought you were proposing such a new construct.
After reading your response to Ron, I don't think that's what you were
saying.

Are you suggesting instead that we simply come up with a new attribute type
to be used in naming objects in a way that facilitates location of the
relevant repository? If so, how does this differ from the domainComponent
attribute type which already does just that? Further, how does this move us
closer to finding repositories for the gazillions of DNs whose most
significant RDN is something other than dc or this new thing?

Separately, it seems much of this discussion is drifting steadily away from
the PKIX charter.  Can I suggest that, in order to improve the SNR for
people with little to no interest in directories, we move the pure naming
discussion to another forum such as ldapext? With this in mind, I would like
to draw your attention to a note I just posted there on the topic of
LDAP/X.500 alignment. IMO, that note provides an adequate segue into the
topic.

 -- Skip  

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 9:35 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

directory

Regards,

Bob

John,

 -- Skip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2001 10:52 AM
To: Slone, Skip
Cc: 'Bob Jueneman'; [email-masked] 
Subject: RE: Basic Cert-2-Directory mapping question

John

Bob,

 -- Skip

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, January 15, 2001 2:11 PM
To: [email-masked] 
Cc: [email-masked] 
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

So.

Bob

Robert R. Jueneman
'Security Architect

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 18 Jan 2001 11:28:16 +0100 (MET)

> 
> 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.

If the goal is to limit the size of for example an S/MIME signature,
a signer MAY add an attribute (signed or unsigned) to the signature if
it is necessary which is similar to an access method in an AIA or SIA.

Whether the attribute is actually part of some cert, is another question.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 9 Jan 2001 20:35:17 (NZDT)

Peter :-).

--=_mh.ndn.15da.3a5abe7f_=--

--=_mh.ndn.15da.3a5abe7f_=--

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 19 Jan 2001 05:12:38 (NZDT)

[Repeated message from a week or two back]

Sorry about the duplicate folks, but that wasn't from here, from the headers it
came from a Gemplus site in Singapore.

>Received: from difool.gemplus.com (difool.gemplus.com [195.25.133.180])
>        by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11463
>        for <[email-masked]>; Thu, 18 Jan 2001 06:46:00 -0800 (PST)
>Received: from mail-prod.singapore.asp.gemplus.com (mail-prod.singapore.asp.gemplus.com [172.27.101.72])
>        by difool.gemplus.com (Postfix) with ESMTP id D0B14C1E7
>        for <[email-masked]>; Thu, 18 Jan 2001 15:50:59 +0100 (MET)
>Received: by mail-prod.singapore.asp.gemplus.com; Thu, 18 Jan 2001 22:46:43 +0800

Peter.

---

From: "Slone, Skip" <[email-masked]>
Date: Thu, 18 Jan 2001 13:17:04 -0500

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:[email-masked]]
Sent: Wednesday, January 17, 2001 4:06 PM
To: [email-masked]
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."

Dave

From: "Bob Jueneman" <[email-masked]>

> From: "Ramsay, Ron" <[email-masked]>
> 
> > Bob,
> > 

    [ 15 additional messages snipped ... ]