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

[Justus Winter <[e-mail]>]

Hi :)

Daniel Kahn Gillmor <[e-mail]> writes:

> So, we still have four different valid kinds of "Signed Message" with a
> single signature:
>
> - (a) OPS0 LITb SIG0
> - (b) OPS1 LITt SIG1
> - (c) OPS0 LITt SIG0
> - (d) OPS1 LITb SIG1
>
> Every implementation i've tested appears to agree how to verify (a) and
> (b).  I've yet to find an implementation that generates (c).  But i've
> found multiple implementations that produce (d):
>
>     https://gitlab.com/sequoia-pgp/sequoia-sop/-/issues/46 and
>     https://github.com/pgpainless/pgpainless/issues/465, so far…
>
> There are at least two different interpretations about what to do with
> (d): GnuPG attempts to verify the unmodified bytestream within the LITb,
> without converting the line-endings to CRLF, while every other
> implementation i've tried (including at least RNP, Sequoia, PGPainless,
> rpgp, and gosop) appears to try to convert the bytestream to CRLF before
> verification.

Just to shed some light on what we do:

- We don't use the literal data's format specifier for anything.  It
  defaults to binary, you can set it to anything when producing PGP
  data, and we parse it and you can query it on consumption, but nothing
  in Sequoia will act on the format specifier.

- Notably, we make no attempt of validating whether the message is UTF-8
  encoded or anything, nor do we try to do any kind of encoding / line
  ending conversion.  For us, literal data is a stream of bytes, and
  that is what we'll hand down to consumers.

- In fact, we consider the literal data metadata a bug in the
  specification: it is neither protected by signatures, nor does it have
  documented semantics.

- If we compute/verify a text signature, we transform the data stream on
  the fly for hashing purposes, but the downstream consumer gets the
  data as is.

In short, if you use Sequoia, what bytes go in come out again,
unvalidated and unchanged.

> So i guess my questions for the WG are:
>
> - Is it a bug if a signer produces (c) or (d)?

No.

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

No.

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

No.

> What do you think?

The literal data packet's header fields are a mis-feature, and should be
treated as such.  Implementations should produce literal data packets
with "inert" values: Sequoia uses binary, zero-length file name,
timestamp 0 by default.  Implementations should not act on the values of
these fields on consumption.  The next revision of OpenPGP should
reflect this more clearly.

Best,
Justus