[openpgp] Re: Analysis document

Hi Falko,

On Wednesday, July 16th, 2025 at 08:44, Falko Strenzke <[email protected]> wrote:

> It is true that the sender has this requirement (and also that for encoding the line endings as you quote below). However, it seems clear to me that RFC 9580 at the same time defines the verification such that it includes a re-encoding operation: (...)

I don't want to make this too much into an appeal to authority but I can assure you that that was not the interpretation that was intended. Note the MR where this text was introduced is called [Clarify that textual data is encoded in UTF-8](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/111). As you can see there, this was originally even intended as an editorial / non-substantive change. In the thread, I argued that it isn't quite, and also noted the incongruity with line ending normalization, as well as existing signatures over non-UTF-8 encoded data.
In the end, we landed on (intending to) more strongly require that the signer uses UTF-8, going forward. In most cases, that should mean that the verifier doesn't have to worry about the encoding. I don't think we considered the case of a detached signature with type=text over non-UTF-8 encoded binary data, and we certainly didn't intend that this would lead to a re-encoding step for the verifier in that case. After all, that would potentially also break verifying existing signatures.

> It seems that RFC 9580 applies the well established paradigm of "be strict in what you send, be liberal in what you accept".

A simpler application of this paradigm would be: don't generate signatures over non-UTF-8 data, but if they turn out to exist anyway, accept them as-is without trying to re-encode the data, assuming that the signer thought it was UTF-8, rather than that they knew it was some other encoding but didn't tell us about it. Since the latter is also pretty much impossible to implement, I'm not sure why you keep insisting on that interpretation.

Again, if the text is not sufficiently clear that's unfortunate, and we can try to clarify it in an erratum or in draft-gallagher-openpgp-signatures-latest, as I noticed Andrew has done now: https://gitlab.com/andrewgdotcom/openpgp-signatures/-/commit/818fc2b5837b32401a8a4fd5bc85fe14c51e8847. But, I think having to implement a re-encoding step during verification would be a very unfortunate outcome.

Best,
Daniel

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