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

Re: Private Key replacement

-----BEGIN PGP SIGNED MESSAGE-----

Francesco,

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

	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
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCUAwUBNI7HvxN3Wx8QwqUtAQFY5gP4zRbx5Yzm2qBk6sWa/rbaSc1NQACoH5/M
36RuvKZyBOLg+L/+AB5JaZm4GewBo5qknCIqehh6sshxg2lNizt3mT9UksQRb9DU
MZQyhwaOOppbGo6fjOQTCU3Jb9iOFX0NZbazeskpKOpLshfAIBxTzmWarsRciQ1R
IsOosm2eig==
=Y7/z
-----END PGP SIGNATURE-----
References: