ee1fc420fb9741b2cfaea6fa820a00be2923f514 contains a proposed fix for this.

Revocation certificates consist of *only* the revocation packet, right? Claiming that the revocation cert contains more than the revocation packet (when it doesn't) seems more troubling from an API perspective than just telling people to expect a single rev: line if they are looking at a revocation certificate.

a fix for this is necessary for me to complete the transition for enigmail to avoid having to use OpenPGP.js, btw, so understanding the plan for how it is going to be fixed would be really helpful to me.

As long as we don't check the signature we don't need the pubkey. That would make it actually easier becuase we have only one case and not 3 or more (bad signature, no pubkey, etc).

Do you really see a problem with first printing a dummy "pub" line? That would make the output format consistent and avoid the question whether a "rev" record is stand-alon or part of the last key.

By "dummy pub line" I think you're proposing output that looks something like this instead of just the rev: line.:

pub:::A57E4460FD08E224::::::::::::::::
rev:!::1:A57E4460FD08E224:1528750759::::this is a test:20x::473003A5FBBB54BC4C717B7CA57E4460FD08E224:::10:

Is that right?

I have three main concerns with printing a dummy pub: line:

• it might imply to the user that if they import this revocation certificate into a keyring they'll also get a copy of the public key packet. A revocation certificate that contains both the pubkey packet and the revocation self-sig might be a nice thing to have in some contexts (e.g. when you have no copy of the pubkey in the first place), and with a dummy pub: line there's no clear way to distinguish between that case and the current case of the simple revsig-only certificate.
• The only thing we can reliably populate is the algorithm and the key ID, right? how would we populate the other fields of the pub: line safely? If we don't have a copy of the pubkey packet itself, then we're left to guess at the status of the key, creation date, expiration date, usage flags, key size (for RSA/DSA), etc. The --with-colons format has no way to indicate "unknown".
• if the user has set --with-fingerprint or --with-keygrip, and we don't have the primary key, we have no principled way of generating the fpr: or grp: lines. so this leads to a situation where you have a pub: line but no fpr: or grp: lines even though they've been explicitly requested. So there's still a special corner case scenario introduced.

If we're introducing a new corner case scenario it seems simpler to just say "revocation certificates may appear as a single rev: line without a preceding pub:." because it avoids these other questions.

If you don't think those are serious concerns, or if there's some way to clearly indicate that it's a dummy pub: line and that the other shift in expectations are not likely to cause problems, then i'm open to being convinced otherwise.

can i get a confirmation that the options you're considering for --with-colons --show-keys when confronted with a revocation certificate will be either:

• the rev: line on its own, or
• a dummy pub: line followed by the rev: line?

or is there a third option?

What about another record type for standalone revocations, something line "rev0" or "revx"? This would solve the problem on how to distinguish merged revocation signatures (ie with a preceding "pub") from standalone revocations.

thus far every packet type has been a three-letter string, right? I'm looking at "Field 1" in doc/DETAILS. adding a 4-letter packet type seems like it could be trouble if someone has done the dumb thing of assuming the field is fixed-length.

how about rvc: for "standalone revocation certificate" ? would the fields be the same as they are for rev: ?

can you let me know what you're planning so i can plan my work on enigmail?

Although "certificate" is used for OpenPGP revocations, it is technically a signature.

Thus I would go for "rvs" because this fits to the "rvk" (revocation key). Fields are the same as with "rev". If something is missing the field will be empty.

thanks, that works for me. I look forward to seeing the patches :)

I implemented it in master and if you agree I will backport it to stable. This is the new output:

$ sed 's/^://' openpgp-revocs.d/61B60AF9FEEB07441FF450923CA56FA24AC0403F.rev | ../g10/gpg --show-keys --with-colons
rvs:!::1:3CA56FA24AC0403F:1529584829::::rvs-sig-test1@example.org:20x::61B60AF9FEEB07441FF450923CA56FA24AC0403F:::8:

If the key is not in the local keyring you will see a '?' or nothing in the second field.