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

RE: Any more comments ...



At 03:24 PM 4/24/96 -0700, Bill Frantz wrote:
>It seems to me that there are two uses for certificates.  I suspect we want
>to support both of them.
>
>(1) Certificates as Capabilities.  In this use, I would expect that the
>entity (person or program) who wanted to exercise some capability would
>pass the certificate giving it the authority along with the request to
>exercise that authority.  There would be no need for directory lookups
>except those needed by the entity to organize the certificates it had been
>given.  In addition to having several certificates, the entity might also
>have several key-pairs, where only it knows that they represent the same
>entity.

Yes -- this sounds like a good summary.

>(2) Certificates as Identity Attributes.  This is basically the X.500/X.509
>directory lookup problem.  You have some kind of unique name for an entity
>and want to get a public key.  Or perhaps you have some kind of attribute
>and want to fetch the certificates which contain that attribute.  This use
>of certificates can use third-party signers, to validate the data, and
>perhaps some standards about the attributes (or unique name) to make
>searching system usable.  (N.B. A unique name is an attribute which is
>guaranteed to be included in only one certificate in this model.)

One of the things I am trying to point out is that case (2) is a subset of
case (1).  That is, the Meaning of a case (1) Capability cert can be "I
attest to this key's belonging to the person I know as Carl M. Ellison".

>The first use would tend to encourage certificates which have only one
>meaning, to reduce the bandwidth required to send them, while the second
>encourages certificates which say everything there is to be said about an
>entity (with possible multiple signers), because of the tendency to want
>unique names.  

I don't follow this.

There is no global unique name meaningful in the societal world.  We could
get a global unique name only through some hierarchy down to a CA and from
there to the CA's unique name for someone -- and that name isn't something
that is likely to be meaningful to me.  I think that's why you went on to
suggest that we look up a match on name AND some other information in order
to narrow the set down, hopefully to the person I care about.

I see no reason to attribute some magic to such a name assignment and load
it up with all sorts of miscellaneous attributes in the same certificate.
That's the X.509 folly.

The question I would ask of any (name,key) certificate is "What are you
doing for me?".

I can imagine some (name,key) certificates which have a concrete meaning
that might be of value:

1. CyberCash, Inc. signs a cert saying "<key> hereby acquires all the rights
and privledges of the CyberCash employee we know as Carl Ellison".  This is
the X.509 model as I originally learned it.  It requires the verifier to
track down whatever rights and privs Carl Ellison has been assigned at
CyberCash.  I, for one, as someone writing code to verify some priv would
prefer having CyberCash issue capability certs (key,priv) instead.  However,
we can imagine someone issuing such (name,key) certs -- and they have a real
meaning, to anyone who knows CyberCash employees and wants to go to the
trouble of keeping the second (name,priv) database [probably also as signed
entities, to prevent tampering].

2. Together, Inc. signs a cert saying "<key> belongs to someone named Carl,
available through Together's remailer as an95231@together.com -- and Carl is
6'2", single, 190 lb., with dark hair (thinning) and a long pony tail.  [see
picture at <URL> with hash: <hash>]".  If I were indulging in on-line
personal ads, this might be a valuable cert to hold and therefore one for
which I might pay money.  Of course, this leaves to people like Michael
Froomkin to decide how Together knows that Carl is single -- and who is
responsible if he's secretly married and out for no good.

3. The USPS issues a cert saying "Carl Ellison at <SNail address> has
demonstrated the ability to sign challenges verified with <key>".  The USPS
has authority to speak about SNail addresses, but what else would this
imply?  Would this give Carl Ellison the right to sign contracts?  I hope
not.  It says nothing about his trustworthyness or financial situation.

4. A bank might issue a cert saying "<key> belonging to Carl Ellison has
been approved for signing mortgages up to $200,000 -- subject to bank
assessment of the property."  [I don't know how mortgages work, but I
suspect this is one step in the process.]  Note that in this case, the name
is irrelevant to the verifier -- and is included just to make a human
happier if he reads the cert.

In fact, all 4 of these examples are Capability certificates -- but I said
that before.

However, you appear to see (2) as significantly different from (1).  I would
like to know in what way they are different for you.

For example, years ago a defender of (name,key) certs said that he wanted to
prove that a given person had only one key.  If that were possible via (2),
then that would be a significant difference -- but I don't believe that
desire can be satisfied so I discount that one.

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091              Tel: (703) 620-4200                         |
+--------------------------------------------------------------------------+


Follow-Ups: