[openpgp] Re: Analysis document

Hi Daniel,

thanks for your feedback. Indeed the decision whether to classify the 
UTF-8 re-encoding and lack of LIT header protection as a security issue 
is worth discussing in my view. Also I want to say that I see it as 
unfortunate that we have to bring this up in the report as a security 
issue even though I reviewed the draft of RFC 9580 back then when it 
already contained the text in question. I must have overlooked or gauged 
it differently back then.

See my comments inline.

Am 08.07.25 um 16:17 schrieb Daniel Huigens:
> 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.
>
>
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. 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.
> There is also a proposal to address this 
> <https://andrewgdotcom.gitlab.io/draft-gallagher-openpgp-literal-metadata>, 
> though not adopted yet.
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.
>
> 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]). The
>     resulting 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.

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. The verifier 
receives the signed document as a binary string. Now the question arises 
whether the verifier is supposed to change anything (besides the 
line-ending conversion) before hashing this binary string or not. As I 
read the quote from RFC 9580 that we give in Section 4.6 in the report, 
the potential UTF-8 conversion equally applies to the signer and the 
verifier. If that was not the case, I would expect a corresponding note 
in the quoted paragraph.

The main concern here is that the format octet of the LIT header, which 
is not protected by the signature, might influence the decision whether 
or not and exactly how to perform UTF-8 re-encoding. If this could be 
ruled out, I personally would not necessarily see a reason to classify 
this as a security issue.

But we should also note that the classification as a security issue in 
the report is not connected with the claim of an exploitable 
vulnerability. Rather, we made this classification dependent on whether 
the respective spec /allows/ an implementation that follows it to 
exhibit a vulnerability. On these grounds, I think the whole topic 
shouldn't be rated too high. Currently I don't expect that an 
implementation following RFC 9580 will introduce a vulnerability with 
respect to UTF-8 re-encoding. This is mainly because I doubt that any 
implementation will implement any text re-encoding during signature 
verification at all. As I see it, the verifier doesn't really have 
reliable information about how to perform it. But if that is correct, it 
raises the question of what is the point of the quote from RFC 9580 that 
– at least in our reading – suggests that a re-encoding on the side of 
the verifier might have to happen.

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

Possibly in an erratum? If everyone agrees that the idea is not that the 
verifier re-encodes the text, then this could also be clarified in an 
erratum.

Best regards,
Falko

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