Jon writes:
Adam wrote:
All useful functionality. I think you need the exception that if the
reason for revocation is private key compromise, then the new
fingerprint is ignored. (Clearly an attacker with the private key
won't create a compromise reason of "key compromise", but this
definition allows you the owner to create a competing compromise cert
which does say "key compromise" and then we can define a "compromise"
revocation to take precedence over a "key retired and here is new key
fingerprint" revocation, where more than one compromise is present on
keyring.)
When I looked at putting it in, I kept it the way it was proposed -- with
the text comment only. The reason is that if I'm retiring a key, I can sign
the new key with my old one, and then put a retiry certification on my old
one. An implementation that wants to propagate trust can easily do it, so I
kept the simpler definition.
The problem is that someone who has compromised your private keys can
also sign a new key to propogate the trust. If you allowed or defined
the semantics of multiple revocations to be that the old trust was
voided in the case that there is also a `compromise' revocation cert,
then I think you can avoid this problem.
Somewhat similar to seeing a public key on a key server with:
`Don't use compromised' as a self signed user id
followed by a new key signed by the old one anyway.
Formalising what this should imply you shouldn't take any notice of
the self signature as the keys it was made with were compromised.
The user won't create a key compromise cert unless the key is
compromised.
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`