On 05/12/2010 02:06 PM, MFPA wrote: > Although the comment could just state it was his new key from > dd/mm/yyyy without mentioning any other key(s).
even this comment would be superfluous, since the key has a "Created on"
timestamp built in. Also, his statement isn't really part of a person's
identity, which makes it more dubious to put it in the User ID as well.
> Bob could encrypt the message asking which key to both of Alice's keys
> that looked valid. But if Bob's basis for deciding Alice's keys are
> valid was simply his trust in the CAcert signatures, isn't the newer
> key with the more recent signature a better bet?
Yes, it is. Furthermore, if Alice had stored a revocation certificate
in a safe place, she could simply revoke the old key without needing to
rely on CACert (or any other certifier, for that matter).
> Maybe this indicates a good reason to use expiry dates on keys. And
> maybe a trusted revocation key that you don't actually use and that
> lives offline somewhere secure, maybe even split, in case of such
> eventualities.
Expiry dates on keys are only useful as a safeguard against accidental
destruction of the secret key material, not against loss of control of
the secret key material to a malicious party. Once an attacker gains
control of the primary key's secret key material, she can update the
expiration date by issuing a new self-sig.
This whole scenario is a good argument for what is already accepted
best-practice: generate a worst-case-scenario revocation certificate
immediately after generating your key, and store that revocation
certificate securely in an offline place (e.g. print it to good paper
and destroy the digital copy). This means there are no extra keys to
manage, and no third parties to rely on (unless you want to send a copy
of your revocation certificate to a trusted friend for use in an emergency).
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
