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

Re: Summary Trust x Delegation

To: rivest@theory.lcs.mit.edu (Ron Rivest)
Subject: Re: Summary Trust x Delegation
From: Bryce <bryce@digicash.com>
Date: Fri, 30 May 1997 12:45:06 +0200
Cc: szabo@best.com, warlord@athena.mit.edu, spki@c2.net
In-Reply-To: Your message of "Thu, 29 May 1997 17:27:08 EDT." <199705292127.AA09237@swan.lcs.mit.edu>
Reply-To: bryce@digicash.com
Sender: owner-spki@c2.net


> Users need to be motivated not to give away their secret keys, or
> restricted not so as not to be able to do so.  If the public key
> serves multiple authorization functions, that may be sufficient to
> deter disclosure.  Tamper-proof hardware can keep most users from
> giving away their keys.  Or, in some applications, one might only
> certify "bonded" keys.  (I use the key to sign a statement saying that
> anyone (or at least the first one) in possession of the corresponding
> secret key can claim $1000 from my checking account.)


These are three good ideas about ways to discourage people from 
sharing their private keys, but I think they merely serve to 
underscore Bill Frantz's point: that there is no way to 
_generally_, _securely_, _cryptographically_ prevent delegation, 
and thus we should avoid giving the appearance of being able to do
so.


Regards,

Zooko

Disclaimers follow:  I am not a crook.  NOT speaking for DigiCash 
or any other person or organization.  No PGP sig follows.

Follow-Ups:

Re: Summary Trust x Delegation

From: Kent Crispin <kent@songbird.com>

References:

Summary Trust x Delegation

From: rivest@theory.lcs.mit.edu (Ron Rivest)

Prev by Date: redirection
Next by Date: Re: Summary Trust x Delegation
Prev by thread: Re: Summary Trust x Delegation
Next by thread: Re: Summary Trust x Delegation
Index(es):
- Main
- Thread