On 13/08/14 12:30, Hauke Laging wrote: > the same string is the same UID The signature is newer than the > revocation thus the UID is valid again. Unfortunately you cannot rely > on this as the RfC does not enforce using the newest signature but > GnuPG behaves this way.
The RFC says very little on a lot of important things. What is the use of not being able to double back on a UID revocation? For key revocations, it's obvious: compromise means an attacker is able to re-enable your key. I don't think there is an analogous "UID compromise". So why would an OpenPGP implementation choose to treat a UID revocation as final? Are there any that do? By the way, small correction: > "The UID" is not the packet data in the OpenPGP certificate but the > string "Alice <u...@company.com>" I take it you refer to the precise form of the data that is signed. In fact, what is signed does have a header, it's not just the bytes from the UID string. The header is somewhat unusual. It is an old-style packet header for packet tag 13 (User ID packet) with a length-of-length 0. It is followed by a 4-octect scalar length and then the UID string. The unusual thing is that length-of-length 0 means a 2-octet length, but in actuality it is a 4-octet length. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users