[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cme@cybercash.com: Re: Certs // RW vs CS]
Hi Ron.
I think we're in excellent agreement. There is a need for both type I and
type II certificates, alongside non-certificate [?type 0?] (familiarity
flowing from key to human body rather than from human body to key). As
long as we allow for the type 0, I'm happy to let the marketplace decide
which is more important than the other.
The user needs to know which kind of binding between person and key someone
has assumed in a given certificate. The problem I see here is that if the
binding is by type I, then there is a certificate to that effect, but if
the binding is type 0, there is no cert. Perhaps we need to create a
place-holder cert [?self-signed?] which means "this is a type 0 binding".
At 09:18 3/1/96, Ron Rivest wrote:
>Carl, I think we are in pretty good agreement on the principles. Type I
>certificates (binding people to keys) are, I agree, not necessary in principle.
>One can have a cleaner system in some ways by skipping type I certificates
>altogether, and just work with keys, using type II certificates.
>
>However, a process needs to know which statements to believe. This
>process may be implementing a security policy of some individual. If
>I want my mail reader to show me only messages signed by Carl Ellison,
>my mother, or Madonna, I need to set up my reader to know which are
>the corresponding public keys. I can do this manually, with keys
>handed to me in person, or I can use auxiliary information (e.g. type
>I certificates) to derive confidence in some keys I've obtained
>directly from cyberspace. The point is that there is often an initialization
>process whereby appropriate ``seed'' or ``root'' public keys need to be
>identified, so a process will implement the intended security policy.
Back in the PGP world, there are a few keys on my keyring which have
acquired meaning for me by virtue of the messages they've signed. I have
signed those keys accordingly. I'm careful not to give those signatures
out, however, because there's no way to note in a PGP signed key that I
"trust" this key because of the messages it signed [familiarity flowing
from key to person] rather than because I met the human body associated
with the key [familiarity flowing from person to key]. I would like to be
able to make that distinction clearly.
>Conversely, and more bluntly: if all you have in CS is a set of unlabelled
>public keys, some of which certify each other in various ways, how do you
>start identifying which ones you trust?
It's worse than that, I'm afraid. What do you mean by "trust"? When all
you say is "I trust X", you aren't saying enough. That's part of my
problem with PGP signed keys and we need to be careful to define what we
mean without giving each certificate a long story or philosophical
treatise. {I remember a co-worker of mine, decades ago. She was married
but I took her to various events her husband wasn't interested in. I asked
him once if it bothered him. "No, I trust her," was his answer. I trusted
her too. I happened to know she was having affairs [not with me -- we were
just buddies]. I trusted her to be the person I had come to know -- not
the person her husband wanted her to be.}
My hope is that if we stick to concrete permissions -- like the ability to
open an office door, the permission to become root on a UNIX system,
permission to spend company money or money from a bank account, etc. --
it'll be straight-forward. For my personal e-mail, the personal trust
issue is one of establishing the mapping between a public key and my own
internal label [nickname] for a given friend/acquaintance. There are many
people named "John" in the world, but only one on my nickname list. I also
have one "Jon", one "Jonathan" and one "johnster". I don't know any way to
bind nicknames to PKs except with certs I sign myself, since I define the
nickname. [There are cheaper, bulk methods of securing that binding, but
logically they're certs.]
What other kind of trust do you think we need to worry about?
>I think it is good to minimize reliance on type I certification to the
>extent possible, as you suggest. I think type I certs can be quite
>useful, although not strictly necessary (given alternatives such as
>manual keying) during the initialization of a process, whereby the
>"axioms" declaring the trusted keys are established, particularly when
>the security policy is one that is created by a person.
There's one use for a type I certificate which I believe has an immediate
market, in case there are budding young entrepreneurs out there [VeriSign,
even :) ] -- and that's the dating service. How do you know with some
assurance the picture, height, weight and marital status of the digital
presence you just met in a chat group and with whom you think you're
falling in cyber-love?
There are bound to be others, although I'm inclined to believe that
electronic commerce keys aren't as heavily tied to type I certificates as
people once assumed.
Enjoy,
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 |
+--------------------------------------------------------------------------+