[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key vs. Signature revocation & Trust Webs
> *signature* revocation certificates are not.
> this a signor issues (in theory) if he thinks he has been betrayed
While signature revocation certificates have not been implemented,
their precense is possible within PGP. There is a packet header that
defines such an animal!
I have been a fervent supporter of having such certificates
implemented. I've even, with some others, developed a fairly good way
to do them: You put a timestamp on it, and if the revocation timestamp
is after the signature timestamp, then the revocation takes
precedence. If the signature timestamp is greater than the revocation
timestamp, then the signature is kept and the revocation is thrown
out.
In fact, this same design can be used for UserID revocations as well,
in order to get rid of bogus userIDs.
> also, notice how keys spread between servers `like a virus'. the
> revocation certificates should do so as well. I don't know if key
> revocation certificates do so in today's servers. I don't really trust
> these servers!
Keys, revocations, new userIDs, signatures. *ALL* of these act like a
virus. Once anything is added to a keyserver, all the keyservers get
them. Revocations are propagated as quickly as new signatures, or new
keys. As for trusting the servers, well, you don't seem to trust
anybody, but besides that point, you should trust the cryptographic
material you get back from the keyservers in that you can verify the
signatures on those certificates. In other words, you should not
blindly accept data you get from a keyserver as correct, without
verifying the signatures on it.
Anyways, hopefully this will get implemented sometime soon. Although
I'm not holding my breath; there are more pressing matters.
-derek
Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory
Secretary, MIT Student Information Processing Board (SIPB)
PGP key available from [email protected]
[email protected] PP-ASEL N1NWH