[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt


anders.rundgren@xxxxxxxxx wrote:
This is indeed an interesting topic...

Essentially there are two ways to make certificates more adapted
to their working environment:

1. Clobber certificates with more "stuff" to as the draft suggests

Actually, its not "more" stuff, its different stuff. X509 certificates use a name form (RDN) designed to work with the mostly defunct X500 directory service protocols. Except for certificates and some well hidden names within things like LDAP, no one uses RDN to represent names.

[ Sidebar - I just did a google search and I couldn't find anything more recent than '99 that talked about using or developing X500 technology - except for what was already there for LDAP]

My comment related to the above - why are we still pushing these .. obsolete? .. names, especially given that we never had full consensus on their structure, content and specific relationship to things like DNS names? The subjectAltName extension was created specifically because the X500 name was neither expressive enough, nor closely enough related to how things were actually named.


2. Use a mapping facility that maps a certificate into whatever
    is needed by the working environment

A major advantage with mapping is that you can use TTP-issued
certificates (a.k.a. 100% outsourced PKI), and that the very same
certificates can be used by multiple relying parties in many different
environments.

A 100% outsourced PKI should also be able to generate certificates which use Subject and IssuerAltName extensions for at least the specified name forms (e.g. RFC822 and DNS). This is just another plugin, and if it gets into the normal PKI specification, a 100% outsourced PKI should be able to issue this type of certificate. Its not a reasonable argument to make that because it wasn't specified before no one will implement or use it. If it doesn't have sufficient functionality, or breaks something - that's the argument I'd actually like to hear.

Also, certificates are just bit strings - I don't need or want to use the same certificate over and over again to access different resources. That requires way too much centralization. Let me give you an example: Should the same certificate I use to access local company resources be the same one I use to make purchases on the internet which get charged to my Visa card? I hope not. Let's look at the trust relationships. In the former, I need a trust relationship with my local sysadmin who also has a trust relationship with the local resources. By virtue of his/her position he can establish a transitive trust relationship between me and the resources by issuing me a certificate. In the Visa case, I have a relationship with Visa as does the merchant (the transaction Acceptor). We both have credentials issued to us by Visa which allow us to participate in a commercial exchange under Visa's rules. The acceptor doesn't need to know who I am, it just needs to know that Visa accepts me (or rather the holder of the certificates private key) as someone who has a trust relationship with Visa for the purpose of commercial exchanges of a particular type. I don't need a global identity for that set of transactions. And indeed, a global identity has all sorts of privacy issues.

I guess what I'm saying is that I'm not sure why paying Verisign to issue client certificates makes a lot of sense.

A major disadvantage with mapping is that Microsoft and probably
most others as well, do not yet support this fundamental capability
except to a very limited extent.  Contributing to that, is the fact that
current PKI-standards do not offer the kind of manageble mapping
support needed for efficient usage of TTP-issued certificates.


In 15 years, this manageable mapping capability has yet to come into existence. Why would you think that there's any reason it ever will? It also requires far more infrastructure in the form of lookup capabilities (e.g. directory, directory protocol, administrative interface, client lookup interface, mapping trust interface) than simply encoding the userid (e.g. a handle into an ACL) into the certificate.


If Microsoft and others are to upgrade their PKI support
(which both solutions require), I really hope that they settle
for a mapping solution.

cheers,
Anders