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

Re: [raph@cs.berkeley.edu: Re: SDSI syntax]

Ron Rivest wrote:
> 
> I'm confused by your remarks regarding SDSI // VeriSign // PGP
> 
> Have you read the SDSI document?  The DNS!! stuff is not at all
> central to the SDSI proposal; it's merely a suggestion for accomodation
> for those who want to deal with hierarchies.  SDSI in no way "depends on
> a big rigid hierarchy"...  Were you commenting based on the document, or
> just based on your reading of the spki mail you'd seen.  If the former,
> can you please explain further???

   Yes, I did read the document. I apologize for not being more specific
in my criticism. However, Hal Finney has explained most of my concerns,
more clearly than I would have. Even so, I'll take another stab at it.

   My primary concern is the key distribution problem, by which I mean
translating an e-mail address into a public key without manual
intervention. Obviously, I'd like to be able to delegate the task.
However, I don't see any way of doing this in SDSI. For example, I want
to find the key for joe@bob.com, and it's not in my local namespace, but
it is in yours. I can always do a lookup on ( ref:
rivest@theory.cs.mit.edu joe@bob.com ), but then I'm not solving my
original problem - I'm starting from something different than an e-mail
address. Alternatively, I could add a link in my namespace, so that
joe@bob.com points to the ref: structure I mentioned above. But then I'm
not solving the problem either, because it requires a manual
intervention to link the names. What I would like to be able to do is to
say that my name space includes yours "by reference". Of course, doing
this right is not easy - for one, you'd want to be able to specify how
deeply these transitive inclusions go, and for another, efficient
database lookup is nontrivial.

   While SDSI doesn't seem to _depend_ on the DNS!! mapping, it does
include it. However, as Hal pointed out, this depends on principals
existing for DNS!!, ( ref: DNS!! com ), and ( ref: DNS!! com bob ), and
signed certificates linking them all. This is what I call a rigid
hierarchy. Perhaps such a thing could be implemented, but that's a big
assumption. I don't consider it to be a solution to the key distribution
problem. To solve that problem, I consider it necessary to be able to
specify locally who I trust to certify bindings between keys and e-mail
addresses.
   By the way, the DNS!! mapping you propose has an ambiguity. It
doesn't happen to be the case, but it's easy to imagine that there are
two valid e-mail addresses for different people, kiwi@cs.berkeley.edu
and raph@kiwi.cs.berkeley.edu. In such a case, you'd probably want to
have two different principals named kiwi, but the mapping you propose
doesn't seem to be able to support that.

   I'd be happy to be shown wrong about the question of whether SDSI
solves the key distribution problem. It's just that it wasn't at all
clear to me how it would be done.

   I liked a lot of the ideas in SDSI. For example, there is a pressing
and immediate need for auto-certs in both the PGP and S/MIME worlds. In
the former, you need an auto-cert to say whether you're happy getting
PGP-encrypted mail (I'm happy because I have a mail client that
automatically decrypts them, but Tim May of cypherpunks fame is not,
because he has to do it by hand), and also to say whether you've got
PGP/MIME capability. When PGP 3.0 comes out, it probably will include
Triple-DES, and you'll need a bit to specify whether you can handle
that. On the S/MIME side, the main thing you need an auto-cert for is
algorithm selection - at present, the spec calls for 40-bit RC2 as the
default, and it requires a manual override to change. Unless some form
of auto-cert is defined and implemented, this ensures that the vast
majority of S/MIME encrypted messages will be 40 bits.

   I've cc'ed spki. I hope you don't mind.

Raph
Follow-Ups: