[openpgp] Re: PQC composite sig context string? [was: Re: Re: AD review of draft-ietf-openpgp-pqc-12]

Falko Strenzke <[email protected]>
Newsgroups gmane.ietf.openpgp
Organization MTG AG
Message-ID <[email protected]>
I also agree with the previous voices to not introduce a wire format 
change at this point. While the context parameter would in principle 
bring an improvement of the formal security properties of the protocol, 
there are a these reasons why I suggest not to do it:

- A successful cross-protocol attack would require key-reuse across two 
protocols (e.g. CMS with X.509 certificates additionally to OpenPGP).
- It would also require the signer to sign the crafted data. Blindly 
signing the crafted data is in most cases already a security problem.
- The protection through the context parameter can be circumvented if 
the other protocol allows to set it freely.
- Maybe minor: Putting it into use with ML-DSA would also raise the 
question why we don't use it with the EdDSA.
- Most importantly in my view: The question was already decided on a 
while ago, as documented in the GitHub issue 
<https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/231>. I do not 
really see a substantial change in the circumstances that justifies the 
revision of the decision. Crypto library support for the context 
parameter might have increased, but we also heard that there a still 
black spots, and so far we haven't gathered exhaustive feedback from all 
implementers.

So I think it is better to now stick to the decision.

Falko

Am 25.09.25 um 13:44 schrieb Jakub Jelen:
> Hi,
> we, Red Hat, are on the same boat, quite close to the shipping the 
> current version and rehashing everything from scratch would make it 
> quite a hassle.
>
> My understanding is the same key reuse in different contexts is 
> generally discouraged. While I agree that adding the context would 
> make it another layer of defense, I think doing it now is quite late, 
> especially with the CNSA 2 requirements vendors need to go through.
>
> Jakub
>
> On Thu, Sep 25, 2025 at 10:07 AM Daniel Huigens 
> <[email protected]> wrote:
>
>     Hi dkg & all,
>
>     We (Proton) would strongly prefer option A.
>
>     We are close to shipping PQC and would prefer not to delay this :)
>
>     Best,
>     Daniel
>
>
>     On Wednesday, September 24th, 2025 at 19:10, Daniel Kahn Gillmor
>     wrote:
>
>     > Thanks for this cleanup work, Aron and the rest of the authors. The
>     > draft is better for Paul's review and for your responses to it.
>     >
>     > I just wanted to draw the WG's attention to this open question
>     which has
>     > the potential to invalidate existing implementations and test
>     vectors:
>     >
>     > On Tue 2025-09-23 15:08:17 +0000, Aron Wussler wrote:
>     >
>     > > > Section 5.1.2. ML-DSA Signatures
>     > >
>     > > > Why is the context string empty and not set to "OpenPGP" or
>     something? Wouldn't
>     > > > this strengthen against cross protocol attacks?
>     > >
>     > > This was decided because of library support, that has since
>     partly changed.
>     > > Full discussion here:
>     https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/231
>     > >
>     > > I personally oppose wire format changes at this stage if not
>     > > necessary, especially given this would still give implementation
>     > > headaches with Botan and delay adoption by months.
>     >
>     >
>     > Paul, the consensus of the WG was OK with the decision to omit the
>     > context string in the past, but that was due in part to
>     limitations in
>     > underlying crypto libraries, some of which now do support the
>     context
>     > string for ML-DSA and SLH-DSA.
>     >
>     > WG, we need to make a decision between these two choices:
>     >
>     > A) Retain the old consensus (and move forward with the draft and
>     test
>     >     vectors as planned, perhaps noting in the draft the historical
>     >     reason for the empty context string), or
>     >
>     > B) Select a context string (invalidating existing test vectors and
>     >      implementation branches)
>     >
>     > Please give feedback on the list here about whether you prefer A
>     or B.
>     >
>     > If you prefer B, please also indicate whether you are OK with
>     the fixed
>     > context string "OpenPGP", or if you prefer some other context
>     string.
>     >
>     > We can see from Aron's message that he prefers A.
>     >
>     > Please respond in the coming week so we can move this draft along.
>     >
>     > Regards,
>     >
>     >         --dkg
>     > _______________________________________________
>     > openpgp mailing list -- [email protected]
>     > To unsubscribe send an email to [email protected]
>
>     _______________________________________________
>     openpgp mailing list -- [email protected]
>     To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> 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]
smime.p7s (application/pkcs7-signature, 4.9 KB) - not displayed
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.