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

Re: Summary Trust x Delegation

if you use an electronic purse as the  secret key holder, and you make the
same PIN which unlocks the electronic purse functionality unlock the secret
key as well, this could prevent users to disclose their secret keys.
If they do, it's equivalent to let their money on the ground.

If the users absolutely want to disclose their secret key, though, they can
let the e.p. empty, so eliminating any risk to lose money.

In general the solution has to be an immediate link between money and
authentication. Who authenticates has access to money (in the case of the
electronic purse, it could be the mean by which the telecommuter gets paid,
to try to prevent users letting the e.p. constantly empty).
But in general there is no way to prevent somebody which holds  a secret to
disclose it.

At 07.28 30/05/97 -0700, you wrote:
>On Fri, May 30, 1997 at 12:45:06PM +0200, Bryce wrote:
>> > 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.
>It's merely a truth in advertising question, though.  The 
>functionality of being able to create a reduced access new cert is 
>useful.  That's why I think the bit should be renamed to something 
>that just expresses that function.
>Kent Crispin				"No reason to get excited",
>kent@songbird.com			the thief he kindly spoke...
>PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55

Entrust certificate upon request

Paolo Da Ros - CryptoNet Srl - Via Oglio, 1 - 20139 Milano - Italy - 
Phone: +39.2.57401235 - FAX: +39.2.7533220 - e-mail: daros@cryptonet.it

L' aquila non perse mai tanto tempo come quando si fece guidare dal corvo
The eagle never lost so much time as when he submitted to learn from the crow.
W. Blake, cit. in Dead Man, Jim Jarmusch