signature verification when literal data packet format octet does not match type of signature
the literal data packet is a single octet that (according to RFC 4880 and other drafts) can be the following values:
octet (in ASCII) | meaning |
---|---|
u |
UTF-8 text |
t |
ambiguously-encoded "text" |
b |
binary data |
l or 1
|
"local" (deprecated) |
m |
MIME (from rfc4880bis-draft-10, probably not widely adopted) |
This format octet isn't included in v4 signatures and probably won't be included in v5 signatures either (see openpgp-wg/rfc4880bis#49 (closed)).
OpenPGP data signatures can be sigtype 0x00 ("binary") or 0x01 ("canonical text"), which seem to correspond to format flag b
on the one hand, and t
or u
on the other.
It would be good to have some tests that include signature verification where the literal data packet's format octet doesn't match the signature octet, as well as some tests where the data format octet is some previously-undefined value, like \x00
to see how implementations handle them.
Given that sop
currently only handles detached cleartext signatures (see dkg/openpgp-stateless-cli#25 (closed)) this can probably only be done today if the messages are encrypted, but that's ok.
I suggest adding message decryption + verification test that covers the cross-product of literal data format octets \x00
, b
, t
, u
, l
, and 1
, with sigtypes 0x00 and 0x01.