[openpgp] Re: Analysis document

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 (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]