[openpgp] Re: Analysis document

Hi Daniel,

I think we are mostly in agreement. See my comments inline.
----------------------------------------

*Von: *Daniel Huigens <[email protected]>
*An: *Falko Strenzke <[email protected]>
*Kopie: *Andrew Gallagher <[email protected]>; Johannes Roth <[email protected]>; [email protected]
*Datum: *16.07.2025 13:51:10
*Betreff: *[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 [https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/111]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.

Thanks for clarifying the process of how the current text came about. That shows that we have  the same view of what the verifier should do. But how the text is meant by the authors is not relevant for our matter. Implementers will only read RFC 9580.

> 
>> 
>> 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.

I still read RFC 9580 specifying a re-encoding step during verification. But as I wrote before, I also don't see how it could be implemented reasonably.
> 
> 
> 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.
> 
I think in order to have clear instructions for the implementation of the verification, an erratum would be useful. But I'm not really requesting it, I'm only trying to explain how we came to classify this in our document as a potential security issue. If I can help with/by filing an erratum I will happily do.

Best regards,
Falko
> 
> 
> Best,
> Daniel

-- 

MTG AG
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000-24
E-Mail: [email protected]
Web: www.mtg.de


MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised
copying or distribution of this email is not permitted.

Data protection information: www.mtg.de/en/privacy-policy

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