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

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 09 Jan 2001 09:50:18 -0700

>>>> "Anders Rundgren" <[email-masked]> 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.

---

From: Janus Liebregts <[email-masked]>
Date: Tue, 09 Jan 2001 22:36:18 +0100

> Novell, Inc. -- the leading provider of Net services software.

Bob,

when taking privacy aspects into account, for several services, you even
don't want to give your identity as a credential for access control. 
For the access control SERVICE trust comes first anchored by identity.
For the access control USER trust comes first, anchored by guaranteeing
the service and privacy.

Indeed in the closed enterprise environment privacy is a non issue.
In an inter business environment privacy isn't really an issue, you want
to have a guarantee which role a person has.
I think both can be addresses with the Privilege Management
infrastructure using attribute certificates, for the time being access
control providers misuse the identity certificate for giving privileges!

Where identity really is an issue, are those type of actions where in
real life you have to show your passport or similar paper or where a
handwritten signature is required.

I would claim that the LEVEL of trust is dependable of the SERVICE and
on which side of the service you are.
The current LEVEL of trust of access control solutions (established BY
the enterprise FOR the enterprise) has to be a little bit higher as the
username/password scheme has, for the user (employee) trust is a non
issue.
Access control solutions established by the enterprise for the public
have other requirements, here trust is really an issue. 

I agree on some action about: 
1. defining (attribute) certificate profiles for access control 
2a. defining some sort of Attribute Authority or credential Service for
generating the certificates based on a identity certificate and taken
into account of the privacy wishes of the identity.
2b or defining some sort of gateway or proxy which can be fed by an
identity certificate and spits out some sort of other credential, based
on the identity's wishes.

And in my view, as I would build a pki for our domain, the origin of
this information is controlled by the identity, using his bare identity
certificate, which is as basic as can be. All the other attributes are
stored in the identity's corresponding ldap-entry using the same DN. One
of them could be the access control attribute (certificate), maybe one
want to generate this privilege on the fly.

I think identity certificates are usable as we do today, not for win2k
but who cares ;-)

btw the EU has released a eye-opening working document on privacy issues
on the Internet:  
http://europa.eu.int/comm/internal_market/en/media/dataprot/wpdocs/index.htm

regards,
janus

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 09 Jan 2001 19:01:57 -0800

>http://europa.eu.int/comm/internal_market/en/media/dataprot/wpdocs/index.htm

Thanks Janus!

A readable, educational and enlightened document!

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900