[openpgp] Re: text vs. binary in an OpenPGP "Signed Message"

[Daniel Huigens <[e-mail]>]

Hi dkg & all,

In my opinion:

On Saturday, February 22nd, 2025 at 01:25, Daniel Kahn Gillmor wrote:
> - Is it a bug if a signer produces (c) or (d)?

It's not forbidden by the spec so I wouldn't quite call it a bug but
it's a strange thing to do for sure.

> - Should a verifier reject (c) or (d) automatically as malformed?

I'd argue no.

> - If not, should a verifier that encounters (d) attempt to apply CRLF
> line endings to the LITb?

Yes. Both RFC9580 and RFC4880 say quite clearly that a text signature
(...) is calculated over the text data with its line endings converted
to <CR><LF>, both in section 5.2.1 and 5.2.4.

Btw, this is why in our implementations "normalizing line endings" is an
operation on bytes rather than text, and just means replacing instances
of 0x0A not preceded by 0x0D with 0x0D 0x0A. Of course this only makes
sense when assuming that the binary literal data packet contains UTF-8
encoded text, which RFC9580 requires in this case:

> If the implementation is certain that the data is textual and is
> encoded with UTF-8 (for example, if it will follow this Literal Data
> packet with a Signature packet of type 0x01 (see Section 5.2.1), it
> MAY set the format octet to u. Otherwise, it MUST set the format
> octet to b.

Btw2, I'm somewhat surprised that GnuPG does something different as I
remember us (a long time ago) changing OpenPGP.js's implementation to
conform better with both the spec and GnuPG's behavior; but I might be
misremembering or perhaps GnuPG's behavior changed.

Btw3, the interop test suite has some test cases about this [1][2].
Unfortunately they don't tell us much about GnuPG's behavior since the
SOP layer doesn't seem to support inline-verify nor text signatures
inside encrypted data, weirdly enough.

Best,
Daniel

[1]: https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html#Signed_messages
[2]: https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html#Signed__and_encrypted__messages