[openpgp] Re: Analysis document

Am 10.07.25 um 19:00 schrieb Daniel Huigens:
> On Thursday, July 10th, 2025 at 17:25, Andrew Gallagher wrote:
>> If this were forbidden, it would add some novel failure modes. For 
>> example, if I sign over a UTF-8 document with a text signature, and 
>> it turns out that there is an invalid UTF-8 character in it (say, a 
>> mishandled surrogate), is the signature invalid? Even if there’s no 
>> malleability risk?
>
> That's not a new question, due to the text in section 4.6 Falko quoted 
> as saying:
>
>     For text document signatures (type ID 0x01), the implementation
>     MUST first canonicalize the document by converting line endings to
>     <CR><LF> and encoding it in UTF-8 (see [RFC 3629]). The resulting
>     UTF-8 byte stream is hashed.
>
>
> So basically it's already forbidden, the main thing we're discussing 
> is just to make it more explicit.

I don’t read quote like that. As I wrote before: The UTF-8 re-encoding 
is formulated exactly analogously to the line-ending conversion. Both 
are required to be performed /before hashing/. And that means: before 
hashing for signature generation and also before hashing for the 
signature /verification/. The encoded data in the LIT packet is /not 
changed/ in this course.

This means that the verifier will validate positively the signature for 
all messages {mᵢ} that are mapped to the same message m’, with

m’ = convert-line-endings(UTF-8-re-encode(mᵢ))

This is what for instance GnuPG and RNP are doing for the line-ending 
conversion according to my tests.

Interpreting the quote as saying that signing non-UTF-8 messages is 
forbidden, would also implicate that it is saying that signing messages 
with line-endings other than <CR><LF> is forbidden. Again: this is not 
how the GnuPG and RNP developers (and most likely that of other tools) 
and also Johannes and me as the writers of the report read the quote. 
The quote is specifying a recoding operation in both cases.

What UTF-8 re-encoding means concretely, however, seems to remain a mystery.

Falko

>
> But also, forbidding signing over non-UTF-8 data doesn't automatically 
> require failing to verify in that case, instead the verifier could 
> just assume that the data that was signed over is UTF-8, and I think 
> that'd probably be simplest & safest as well.
>
> Best,
> Daniel
>
>
> _______________________________________________
> openpgp mailing list [email protected]
> To unsubscribe send an email [email protected]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
Web: mtg.de <https://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: Privacy policy 
<https://www.mtg.de/en/privacy-policy>

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