[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
key-centric versus person-centric certs
-----BEGIN PGP SIGNED MESSAGE-----
Bob,
I said I'd reply more fully. Sorry for taking so long.
At 11:08 AM 7/1/97 -0600, Bob Jueneman wrote:
>>1) What's a key? What can you do with it?
>
>There seem to be two different views, both of which can probably coexist,
>and neither of which is necessarily superior to the other. One views the key
>as being bound to and an extension (property of) the person named in the
>certificate and can be used to authenticate that person's control over other
>rights and privileges, some of which may be identified in or granted by that
>certificate; the other views the fact that some person may know or control
>the use of a key to be an interesting and sometimes inconvenient fact, but
>attaches properties (in the computer science sense) to the key, rather than
>to the person.
My two views of key||person are maybe what you mean, and if not, then I don't
understand you.
(1) The person is the center. In database terms, the person is the primary
index. A key is a secondary attachment to the person and the person can
acquire keys or drop them with almost no pain and no effect. The person
remains constant (until the person's death, or maybe even after). Attributes
are given to the person and acquired by any keys currently attached to that
person.
(2) The key is the center. In database terms, the key is the primary index. A
key, K, is associated with a person, called "keyholder(K)", who is the person
who has possession and control of the private key. In this model, the person
is still central, but the public key is being used as the name for the person.
Attributes are given to the key and therefore acquired by the keyholder.
I have heard ID-cert folks claim to follow model (1) while we follow (2).
Is that the difference you intended to refer to?
The problem with the ID-cert claim is that the person can not be used to index
a database. Something digital must be used. So, a name is used.
A name has the advantage that it's not subject to a factoring or discrete log
attack. The invention of a quantum computer won't invalidate the name the way
it would invalidate an RSA key.
However, that doesn't mean that I am suddenly an advocate of (1). Under ID-cert systems, the name is bound to a key by a digital signature -- so the binding is invalidated by a quantum computer equally. In fact, if you line up an ID-cert mechanism side-by-side with the SPKI key-only mechanism, you'll see that the SPKI mechanism is one step more secure, becaue it avoids the name step (which can introduce errors and permit attacks). We can also have people have permanent keys (almost never taken out and used) which are very long and very securely stored, to which their permissions get granted and those long keys can be used to pass permission on to temporary keys -- and we get exactly the same benefits claimed for (1), but with no hierarchy, no CA corporations, no money for certs, ....
--------------------
I believe the ID-cert folks are still working under the assumption, valid from
the start of human speech until about 100 years ago, that a person's name is in
a sense equivalent to the person. In a small, closed community, in which
everyone you know has not only a unique name but also knows the same people you
do and knows the same names for them that you do, a name can be thought of as
equivalent to the person -- that is, the name is the person's "identity".
In 1997, on the Internet, the original assumptions don't apply and it's not
just dangerous to use the same conclusions -- it's wrong.
>The first view follows rather naturally from centuries of
>jurisprudence,
If I've interpreted you correctly, centuries of jurisprudence have in fact
reflected what used to be true for all prior time -- that a person's name is
somehow that person's identity and meaningful to those using the name, partly
because the named person is known to those using the name -- in this case,
the court, the jury and the witnesses. ...all used to be true in small,
closed towns.
>To the extent that the concept of a keyholder makes sense, in particular the
>concept of a putative or alleged keyholder, rather than necessarily the
>real, honest, exclusive keyholder, then yes. The fact that Billy Bobs CA
>and Bait Shop creates a certificate which contains my name and some public
>key may be a total fiction with respect to the assumption that I possess and
>control that key. And if that key is used to sign a transaction for which
>the person whose identity is bound to that key may be liable (me), then I
>absolutely insist that all possible measures be taken to prevent such a
>certificate from even being created, much less disseminated.
No argument from me. However, I believe we need to make very sure that laws
getting passed recognize the truth that non-repudiation is technically
impossible and that legal assumptions of non-repudiation put such a burden on
the keyholder that the very use of public key technology might be threatened.
>>3) Given 1 and 2, does it make sense for a certificate
>> for a key to be signed with that key
>> a) never, b) sometimes, or c) always?
>
>Seems to me that a certificate which is signed by the same key that is
>contained within the certificate is a self-signed certificate. The structure
>and other features of a certificate may be useful in administering the
>validity period and other aspects of a self-signed certificate, but as far
>as I can see, a self-signed certificate has no trust associated with it in
>and of itself.
I didn't start this thread talking about certificates signed by only one key --
rather a certificate signed by both issuer and subject.
However, there is certainly a cert which can be trusted best if it is signed by
its subject: one I have called a "donation cert". If the cert is to contain
my name and address, so that you can write my name on a check and mail it to
the address given -- and you know me only by my public key (because we met on
the net and I signed all my e-mail) -- then my key is the one you can trust the
most to sign that certificate. No CA can be trusted more than I can be.
>4) Does the signature by the keyholder belong in the certificate's syntax,
>> or is a separate signed message adequate?
>
>To the (questionable) extent that a self-signed certificate makes sense, it
>could be included in the certificate. that at least makes the circularity
>of the argument painfully obvious. Putting it in a message which is
>eventually validated by the certificate makes the trust relationship much
>more obscure. Of course, if the message is signed by some other party and
>no circularity exists, then that is the moral equivalent of an X.9
>capabilities or attribute certificate, which may be tied to an identity
>certificate. In all likelihood an X9 certificate would be easier to parse
>than an e-mail message, but there I go talking about religion again.
We intentionally separate the signature of a cert from the cert body, so that a
cert might have multiple signatures, not nested but in parallel.
>What might be more interesting would be to consider what legal standing, if
>any, a certificate which did not contain any notion of identity might have.
>I would tend to argue little or none, as I would also argue in the case of a
>Kerberos ticket, except within the context o a particular
>rights-granting/rights-consuming application with human users, i.e., a very
>closed system.
No certificate can be devoid of any notion of identity. My public key is one
name for me, its keyholder. Any cert with my public key as subject refers
therefore to me.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQCVAwUBM9EcrFQXJENzYr45AQEj6wP/Y2U7nJ6VT9sWfBdpSezfencyBzKNI6RL
NkXfh5kGPA/iytvleOo+uecrU7mUlwj/6QrWAhZ4t+TGhaWgVCn7MY4SwGMSDZht
JLRQ8FjncAb1O3DJrtyC7QOovaQPMXsKx5jlVZ4Rp5x75fEKb+TS4xyGQVclqMR7
V4V2OXjbems=
=XgoL
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+------------------------------------------------------------------+
References: