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

From: Michael StJohns <[email-masked]>
Date: Thu, 03 Oct 2002 17:44:04 -0400

[email-masked] 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

---

From: [email-masked]
Date: Thu, 3 Oct 2002 17:46:11 -0600

The bit strings are essentially r/o (typically stale and significant
subset) of trust information in some sort of trust repository.These trust
bit strings were originally designed for use in offline environments where
there was something inhibiting the access to the actual trust repository.
They can currently be useful in environments where it isn't worthwhile to
know the actual timely &/or aggregated information ... for instance you
don't need to know things like whether your online account is active, your
have sufficient funds in your account and/or you have exceeded your credit
limit (aka useful for low or no value operations).

the scenario is somewhat similar to the credit card industry of the '60s
that was non-electronic and offline. In the '70s, the online economics was
sufficient that it allowed a direct transition to electonic and online
(with some residual non-electonic/offline lingering on). The certificate
actrivity of the '80s was essentially a paradigm step backwards in time ...
to the '60s ... but with a offline electronic ... rather than a offline
non-electronic.

special purpose types of certificate are in effect the same or very similar
to the "relying-party-only" certificates that various financial (and other)
institutions were making use of by at least the mid-90s.  However, it is
trivial to show that for any kind of value, online operation the
relying-party-only certificates are redundant and superfulous (again
leaving just the domain of offline, low/no value operations).

misc. past r-p-o certificates references:
http://www.garlic.com/~lynn/subtopic.html#rpo

and of course ... the misc postings on end-game of why eventually TTPs
would even be issuing server domain name certificates
http://www.garlic.com/~lynn/subtopic.html#sslcerts

michael stjohns <[email-masked]> on 10/3/2002 3:44 pm wrote: