[openpgp] Re: Analysis document

I think the problem with the way RFC 9580 specifies the UTF-8 encoding 
on the side of the verifier for text document signatures (at least in 
theory) adds to an already existing problematic situation: Whenever type 
text signatures (0x01) are applied to binary data, this leads to the 
possibility of manipulations to the signed data that don't invalidate 
the signature. I tested this with the GnuPG and RNP command line tools 
with "--clearsign", which is the only way I found for these tools to 
emit type text signatures. I created a file consisting of a minimal byte 
sequence that contained the byte 0x0A, signed it with "--clearsign" and 
then was able to change the message by modifying the byte 0x0A to 0x0D 
0x0A without invalidating the signature. Here I am missing a clear 
warning in RFC 9580 and the tools that using a text signature on binary 
data leads to existential forgeries.

This shows that implementers read the OpenPGP spec regarding line ending 
conversion like we do in the report: the verifier is required to perform 
the conversion before hashing. As stated in the report, this conversion 
maps multiple elements from the input space to a single element in the 
output space. The UTF-8 conversion, that is specified analogously 
<https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.4-3> to the 
line ending conversion in RFC 9580, possibly adds to this problem 
further by creating more freedom in the forgeries, should the 
implementer realise it in some way.

To repeat it again, in order not to create any misunderstandings: the 
problem of existential forgeries that I describe above only arises when 
a type text signature (0x01) is used to sign binary data, which is 
obviously not intended. But it is hard to for me to believe that all 
application developers using OpenPGP or personal users of the CLI tools 
are aware of this.

Falko

Am 09.07.25 um 10:54 schrieb Daniel Huigens:
> Hi Falko,
>
> On Wednesday, July 9th, 2025 at 10:13, Falko Strenzke 
> <[email protected]> wrote:
>>
>> It is true that the specification warns about this, but first of all 
>> the risk remains that implementers of applications that use OpenPGP 
>> do not read this warning and simply query the unprotected values from 
>> via the interface to the OpenPGP implementation.
>>
> Yes, that's true. We may need to update OpenPGP implementations to 
> warn against the usage of these fields, or perhaps deprecate/remove 
> them entirely.
>
>> Second, our analysis concludes that it cannot be precluded that the 
>> value of the format octet in the LIT packet header influences the 
>> interpretation of the encoding for type document signatures and thus 
>> the potential UTF-8 transformation.
>
> In conformant implementations, the encoding/preparation of the 
> document to be hashed/signed should only depend on the signature type, 
> not the format of the literal data packet (see below for more details).
>
>> The proposal seems fine. Very importantly, it does not introduce 
>> hashed data (for the signature) that is not encoded in the signature 
>> packet. Our report warns that should there be such a signature 
>> subpacket contributing sufficiently long hashed data that is not 
>> encoded, this could result in an existential forgery vulnerability. 
>> This is due to the mod 2³² calculation of the hash length in the 
>> signature meta data in v6 signatures.
>
> FWIW, I don't think this would be a significant concern in this 
> specific case because the literal data packet filename has a 
> single-octet length field, and is therefore limited to 255 bytes. The 
> overall metadata is therefore limited to 261 bytes.
>
> But, it's a valuable point to keep in mind if we want to define a 
> signature context subpacket.
>
>>> Another (more pedantic) way to phrase this is: for the purposes of 
>>> RFC9580, "text" is a Unicode string, which is then UTF-8 encoded on 
>>> the wire. A file containing non-UTF-8 encoded data is not "text" but 
>>> rather like any other binary file.
>>
>> I can understand this interpretation in the your last sentence, if at 
>> all, only for the signature process. There we may think of a step 
>> where an "abstract" Unicode text is encoded in UTF-8. But I cannot 
>> see how we can think of such a step at the side of the verifier. (...)
>>
> It depends a bit on the details of how the message to be 
> signed/verified is passed and the API of the OpenPGP library. But, in 
> the case of a detached signature over a Unicode string, the exact same 
> step may apply.
>
> In the case of an inline-signed message, RFC9580 states in Section 5.9 
> (Literal Data Packet):
>
>     Text dataMUSTbe encoded with UTF-8 (see[RFC3629
>     <https://www.rfc-editor.org/rfc/rfc9580.html#RFC3629>]) and stored
>     with <CR><LF> text endings (that is, network-normal line endings).
>     These should be converted to native line endings by the receiving
>     implementation.
>     (...)
>     If the implementation is certain that the data is textual and is
>     encoded with UTF-8 (for example, if it will follow this Literal
>     Data packet with a Signature packet of type 0x01 (seeSection 5.2.1
>     <https://www.rfc-editor.org/rfc/rfc9580.html#signature-types>),
>     itMAYset the format octet to|u|. Otherwise, itMUSTset the format
>     octet to|b|.
>
> In other words: if a literal data packet is followed by signature of 
> type=text, then the data packet must contain UTF-8 data. Therefore, no 
> re-encoding is ever needed in that case (since the implementation can 
> assume that the data is already UTF-8 for text signatures).
>
> 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]