[openpgp] Re: Analysis document

Daniel Huigens <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <g4NAso2z0FU2KgqyGogn7e5VRfLJQrlqEkZxf0NyTKQsvtvJLXX44UUO21iZsNmBXIfmhYW1KmzJMyIyww8NUdugiM06FelPZc3XEQyjpiU=@protonmail.com>
Hi Falko & Johannes,

Thanks for the detailed analysis!

Section 4.2 makes a fair point about the literal data packet metadata not being signed; and notes that this is risky if an application accidentally relies on these fields. This is true, but note that the spec strongly warns against doing so by saying:

> A receiving implementation MUST NOT treat those fields as though they were cryptographically secured by the surrounding signature when either representing them to the user or acting on them.

There is also a [proposal to address this](https://andrewgdotcom.gitlab.io/draft-gallagher-openpgp-literal-metadata), though not adopted yet.

Then, regarding section 4.6; it quotes the RFC 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]). Theresulting UTF-8 byte stream is hashed.

And interprets it as saying that non-UTF-8 text must be re-encoded. However, both RFC4880 and RFC9580 state in section 3.4 that

> Unless otherwise specified, the character set for text is the UTF-8 [RFC3629] encoding of Unicode [ISO10646].

There are some caveats to this left open by the "unless otherwise specified", e.g. in section 6.2.2.4 ("Charset" Armor Header); but that section also says that an implementation is allowed to assume that all text is UTF-8.

Essentially, RFC9580 merely strengthens this requirement for text signatures by saying that they MUST be made over UTF-8 encoded text, only.

If you want to make a signature over differently-encoded text, the easiest solution is to create a binary signature, rather than re-encoding the text during signing. That way, there also aren't any concerns about EUF-CMA.

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.

All of that being said, some additional security analysis on this topic may have been warranted, indeed, along witha recommendation to use the binary signature type rather than the text signature type, perhaps.

Best,
Daniel

On Tuesday, July 8th, 2025 at 14:51, Falko Strenzke <[email protected]> wrote:

> As an FYI note: In the course of our project for the BSI Johannes and I have created [this report](https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison/releases/download/v1.4/opgp-lpgp-comp.pdf) comparing RFC 9580, LibrePGP, and RFC 4880. Even if the comparison to a non-IETF spec might not have much relevance in this forum, some of the analysis results pertaining to RFC 9580 might. We are looking forward to receiving feedback and corrections. We apologise for any errors we might have made in advance.
>
> Best regards,
> Johannes and Falko
>
> --
>
> 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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.