Re: Basic Cert-2-Directory mapping question

[Janus Liebregts <Janus.Liebregts@xxxxxxxxxx>]

Bob Jueneman wrote:
> 
> >>>> "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.

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