[openpgp] Re: Analysis document

I agree that creating a text signature over binary data is generally problematic. Section 5.2.1.2 also implies not to do this:

> The signature is calculated over the text data (...)

But, I agree it would be valuable to more explicitly forbid signing over arbitrary binary data (and text data that is not encoded using UTF-8) using a signature of type=text. Perhaps this could be included in Andrew's [signature semantics draft](https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-signatures), as well.

And, I'd argue it's also the responsibility of OpenPGP library developers to expose sensible API's, that pick the signature type based on the type of value being passed (e.g. only pick type=text when a Unicode string is passed), or at least check the input data, rather than letting application developers decide arbitrarily, let alone end users.

This is also what the [sop spec](https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-08.html#section-3.3.7) requires, for example:

> --as defaults to binary. If --as= is set to either text or clearsigned, and the input DATA is not valid UTF-8 ([Section 9.7](https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-08.html#utf8)), sop inline-sign fails with EXPECTED_TEXT.

Ideally, GnuPG and RNP should do the same, I'd argue. That being said,

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

With clearsigned messages, the text that's signed over is included in cleartext in the signed message. So, <LF> and <CRLF> are indistinguishable in that context, so I don't think it's a huge concern there. Though of course that doesn't mean that we can't add a warning for other contexts, indeed.

Best,
Daniel

On Thursday, July 10th, 2025 at 13:53, Falko Strenzke <[email protected]> wrote:

> 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]>](mailto:[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 (see[Section 5.2.1](https://www.rfc-editor.org/rfc/rfc9580.html#signature-types)), itMAYset the format octet tou. Otherwise, itMUSTset the format octet tob.
>>
>> 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 to
>> [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]