Seeking clarification with a few GPG concepts

Peter Lebbing peter at
Wed Aug 13 13:42:26 CEST 2014

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 <uid2 at>"

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.



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 <>

More information about the Gnupg-users mailing list