Re: Basic Cert-2-Directory mapping question

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

>>>> "Anders Rundgren" <anders.rundgren@xxxxxxxxx> 01/09/01 12:13AM >>>
>Guys!
>The response on this "basic" question has simply been overwhelming!
>
>Even if you can force CAs to obey certain rules regarding DNs, I still believe
>that this inability to use certificates created in "one regime",  as credentials in
>another Win2K or NetWare "regime" calls for *some* kind of action.
>
>At least those who are into TTPs (commercial or not) should be interested.
>
>/anders
>


Anders, I won't attempt to speak for Microsoft -- Bill has more money than I
do, and can speak for himself.

But although I certainly share some of your frustration, it isn't clear as yet
that most of our customers have this problem, although perhaps we wish they 
did.

Whether someone within the enterprise is trying to log on to Win2K, NetWare, 
or our NDS/eDirectory, 95% to 99% of the time they are using access control
solutions established BY the enterprise FOR the enterprise.

In that type of closed environment, it simply doesn't matter all that much what 
the directory schema or the PKI schema looks like, as they will be designed to 
match each other.

Notice that this really isn't a "closed PKI" as Steve discusses -- it's even more closed 
than that, because the access control is almost entirely within ONE enterprise,
and not multiple enterprises, much less the much broader retail consumer
or residentialPerson marketplace.

Now, I'm certainly not arguing that it wouldn't be interesting to talk about
extranet access control, and PKI-based authorizations that extend beyond the 
boundaries of one organization.  It would be interesting, and I and others have 
been talking about that for what seems like eons.

But by and large, it isn't happening.

Is this, as some would claim, due to the fact that we haven't solved the directory 
naming problem?

No, the problem is deeper than that.

The problem is one of TRUST.

And I would claim, with some regret, that PKI isn't about TRUST, it is about 
IDENTITY.

Unfortunately, when it comes to making an access control decision, it isn't 
sufficient to have a chain of certificate stretching back to some ubiquitous
issuer of low-cost certificates which attests to the fact that the holder of
a given private key is in fact cn="Village Idiot #13", even if he really is.

If I'm the system administrator, I don't care who someone IS, I want to 
know what that person is permitted to DO.

At least at present, the way that people are controlling those decisions is to 
pre-enroll that individual into an authoritative directory or database, and then 
assign or share some secret with that individual which can be used to
authenticate that person as the same individual that was authorized, assuming
he hasn't shared that secret with someone else.

Granted, there are nuances of security and control, but the bottom line is
that it isn't the person's DN that matters, assuming that DN can be found
somehow.  The only thing that really matters is the shared secret, and 
the fact that the person who knows that secret has been granted certain 
permissions or authority.

Whether that secret is a password, a private key, or some token device
is of secondary importance to the fact of pre-enrollment and the granting of
access authority.

So the lack of a universal naming solution, although irritating to those of us
in the profession, hasn't yet reach the point of being a crisis with our customers,
because those customers either don't allow external users into their system at
all, or they base their decisions on other things than identity, such as whether or 
not the person has a valid credit card account, and it isn't maxed out.

Note that I have been talking exclusively about access control, and not 
legally-binding transactions or other aspects of a more global use of PKI,
where identity may (someday) play a larger role.  But even in that context,
I would claim that trust comes first, and is anchored by identity, and not
the other way around.

Regards,

Bob

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