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

Re: Private Key replacement



	thank you for bringing this up.  I didn't give it any attention in the 

	We addressed this during the design.  That's one reason we allow hash of a 
key to be a principal.  That way, you can generate your two keys (or any 
number, for that matter), keep one available for use and keep the others 
salted away.  However, when you get a certificate for your working key, you 
can get certs for all your keys, using key hashes to identify them, and just 
keep the certs for future keys on file.

	If/when we get around to using trusted timestamp services, we can do this 
delegation ourselves.  That is, with a trusted timestamp, we can delegate 
from a key we know will be invalidated in the future to some other key -- 
and then, after that key has been invalidated, haul out the timestamped 
certificate of delegation.  However, that's a complication we don't need at 
this time.  It's just something to look forward to and a reason to encourage 
timestamp efforts.

 - Carl

At 02:22 PM 12/9/97 +0100, Francesco Zambon wrote:
>With reference to:   draft-ieft-spki-cert-theory-01.txt  
>The protection of the private key is correctely stressed in  3.2.1 but the
>all specification derives from the assumption that "all private keys are
>kept private and bound tightly to the one keyholder to which they belong".
>If the cybersapce is going to become crowded it will certainly happen that
>sometimes also private keys are compromised.
> Possibly SPKI is the right place where one can take some precaution. 
>I found interesting the proposal included in SET (see "Secure Electtronic
>Transaction Specification - Book 1 Business specification 3.3):
>When one issues the  public/private keys he will generate also a "recovery
>key" (private and public keys).
>The recovery key can be kept in a safe "place" (a floppy in the
>strongsafe),  since they are not actually in use.
>A secure hash of the public-recovery key  will then go with all apparences
>of the "active" public key.
>When the  actual private key is compromised:
>	- The CRL can  specify when and if one has to switch to the recovery key 
>	- The "public recovery key" is published together with the hash of the
>next recovery key
>The approach helps also if also the recovery key is compromised.
>The key holder has to generate a new couple of actual and recovey keys,
>publish the actual public key (& hash of the new recovery key) and  the CRL
>has to specify that one has to switch to the recovery key and, immediately
>after,  recover again.
>I hope this suggestion can improve the specification or at least highlight
>a requirement.
>Regards, Francesco Zambon
>Francesco Zambon      mailto:zambon@enidata.it
>EniData spa - Via Medici del Vascello 26
>20138 Milano (Italy)
>Tel: +39 2 520 25369    Fax: +39 2 520 25174

Version: PGP for Personal Privacy 5.5.3


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |