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

Hi :)

Daniel Kahn Gillmor <[email protected]> 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

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----

wsC7BAEBCgBvBYJnxXsqCRCI3H4zOF95HUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmcTwYjlAehTCju92tX0tAxvI7vAbz5JWpU4SMgBZ00R
bBYhBCVqTlXkpy2XrSRo54jcfjM4X3kdAACuxAf+PKCgBRnYo7AmM7EZJripMxVa
XSQjcg3fKwVp0decZaOnS5flpmWYKK29QVh4ZuDEJYlNConyZuXdf9UeCDTxwzIG
jLK42vhsUyk8J0hzCOw/4aV07bzH2snyLy9OgrXgj9Aoja5bbe6Cb9BPrKwqki1/
yQNwyOg0GBHCzhHEnJ6CPcuoZ8Fwgfr4mQ817K/x5+O2Rjs4VbSZcUq6mk0Lh78m
3RELonFxrRaAculDMYPXsQdWPUUQ9tqQeNgAeQ89M/4Y1v6SJ/XA0I2lxBmT7By8
lX3K3pPKocefglfrDR39Z28xQNCdsqDmcgIeooOSDCIb3lLgQfQZ0EgH2YF9CA==
=/kNb
-----END PGP SIGNATURE-----