RE: Basic Cert-2-Directory mapping question

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

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.

He said:
>
>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.

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
Novell, Inc. -- the leading provider of Net services software
>
>
>
>
>
>
>
>>>> "Slone, Skip" <skip.slone@xxxxxxxx> 01/15/01 09:08AM >>>
>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:oscar.jacobsson@xxxxxxxxxxx] 
>Sent: Thursday, January 11, 2001 5:16 PM
>To: Slone, Skip
>Cc: 'Sharon Boeyen'; ietf-pkix@xxxxxxx 
>Subject: RE: Basic Cert-2-Directory mapping question
>
>
>> From: Slone, Skip [mailto:skip.slone@xxxxxxxx] 
>> 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