[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Private Key replacement
-----BEGIN PGP SIGNED MESSAGE-----
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
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
>Regards, Francesco Zambon
>Francesco Zambon mailto:email@example.com
>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
-----END PGP SIGNATURE-----