[openpgp] Re: AD review of draft-ietf-openpgp-pqc-12

Hi Paul and DKG,

thanks for you comments and answers. Stavros and I created GitHub issues 
for each of the topics raised in the review and entered also the 
existing answers from the list: 
https://github.com/openpgp-pqc/draft-openpgp-pqc/issues

We suggest to move the discussion of the review comments to the 
respective GitHub issues for better overview. The weekly report mails 
will give everyone a an overview of the changes on the list. If deemed 
necessary, we can give a summary of the resolution of each issue on the 
list.

Best regards,
Falko

Am 15.09.25 um 19:56 schrieb Daniel Kahn Gillmor:
> Hi Paul, OpenPGP, and PQC folks--
>
> Paul, thanks for the close read and your feedback here!
>
> My comments are inline below.  I hope other folks from the WG (including
> editors of the draft) will also weigh in.
>
> On Fri 2025-09-12 16:22:55 -0400, Paul Wouters wrote:
>> Section 3.2 / 3.3
>>
>> Why are multiple signature packets not treated the same as composite signatures?
>> That is, if both traditional and PQ signature packets by the same sender are
>> availablle, why not require them both just like if they were send as a composite
>> signature in the same signature packet? (eg the 3.2 MUST vs the 3.3 MAY). Especially
>> if this is needed as claimed in 3.2 to support legacy clients. Otherwise, one would
>> have to include a legacy signature packet, and a signature packet with legacy+PQ
>> coposite to accomplish the same?
> The presence or absence of a signature isn't something that the
> recipient can rely on.  For instance, an attacker might completely
> remove one of the signatures, and leave no trace.
>
> If you wanted to require the two always be present together, you'd need
> some signalling in each signature packet to indicate that it expects its
> twin to also be present, and then all verifiers would need to understand
> that signalling in order to not fail open.
>
> Another approach would be to ensure that an OpenPGP certificate that has
> multiple signing-capable subkeys could indication that signatures from
> certain subkeys needed to be coupled with signatures from each
> subkey. This would also prevent an attacker from stripping one of the
> signatures on a signed object, but it would introduce novel subkey
> semantics into an OpenPGP certificate, which again would require
> widespread adoption before such subkeys could be safely deployed.
>
> The working group elected to not build out any of this potentially
> delicate machinery, and simply tie the underlying cryptographic objects
> together in a single OpenPGP signature for the hybrid signature formats.
>
> This retains the traditional OpenPGP semantics where multiple OpenPGP
> signatures may be present in any signing scenario, and at least one of
> them needs to be valid, from an expected signer, in order for the object
> to be considered correctly signed.
>
>>   	with the single exception of ML-KEM-768+X25519 (algorithm ID 35),
>>   	which is also allowed in v4 encryption-capable subkeys.
>>
>> What is the reason / justification of this exception? (this also appears in 4.3.2)
> As noted in on 2025-04-15 in
>
>      https://mailarchive.ietf.org/arch/msg/openpgp/02A6UOphJwk0npU_qOZ6IppwaTc
>
> this decision was made "to allow for a pq-upgrade path without rotating the primary key".
>
> Prior to the exception, PQC was only available in v6 certificates.
>
>> Section 4.2.1
>>
>> Should the symbol "||" be explained?
> I think "||" is widely understood in wireframe specifications to be the
> concatenation operator, but i have no objection to writing it down.
>
> I've offeredhttps://github.com/openpgp-pqc/draft-openpgp-pqc/pull/225
>
>>   	The value domSep is a constant set to the UTF-8 encoding of the string "OpenPGPCompositeKDFv1", that is:
>>
>>   	domSep = 4F 70 65 6E 50 47 50 43 6F 6D 70 6F 73 69 74 65 4B 44 46 76 31
>>
>>
>> $ echo -n OpenPGPCompositeKDFv1| hexdump
>> 0000000 704f 6e65 4750 4350 6d6f 6f70 6973 6574
>> 0000010 444b 7646 0031
>>
>> Should a note be added about the byte string being network/host order ?
> I don't think there is a "network host order" for text strings in
> US-ASCII (or in its superset UTF-8).  As falko noted, the view you're
> seeing is an artifact of your hexdump implementation:
>
> ```
> 0 dkg@bob:~$ echo -n OpenPGPCompositeKDFv1| hd
> 00000000  4f 70 65 6e 50 47 50 43  6f 6d 70 6f 73 69 74 65  |OpenPGPComposite|
> 00000010  4b 44 46 76 31                                    |KDFv1|
> 00000015
> 0 dkg@bob:~$ echo -n OpenPGPCompositeKDFv1| hexdump
> 0000000 704f 6e65 4750 4350 6d6f 6f70 6973 6574
> 0000010 444b 7646 0031
> 0000015
> 0 dkg@bob:~$
> ```
>
>> 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?
> OpenPGP has used the empty context string for other algorithms (see
> https://www.rfc-editor.org/rfc/rfc9580.html#section-12.7-3 for example),
> so this is in line with other OpenPGP behavior.
>
> I don't know how many implementations of these primitves actually
> support the signing context string.  If there are some that only support
> an empty context string during either signing or verification, then
> those wouldn't be usable with OpenPGP if we require a non-empty string.
>
> With no hats on, i would have no objection to requiring a uniform
> context string like "OpenPGP" for both ML-DSA and SLH-DSA assuming all
> significant cryptographic implementations of those algorithms make it
> easy to support. It would mean requiring every OpenPGP implementation to
> adjust their signing and verification code, but i don't think that would
> be a particularly complex change.
>
> Note that for within-OpenPGP uses, the objects being signed are already
> clearly distinguished from one another by means of including the
> signature type, algorithm ID, etc. in the octet stream representation of
> the signed message.
>
>> Section 7
>>
>> Why is AES-256 specifically bound to certificates that contains a PQ(/T) key ?
>> Why that might be appropriate for a CCNSA profile, why would it be done in
>> the generic PQ case? [I see this is answered in Section 8.5]
> I think it's answered in section 9.5, not 8.5 ☺
>
>> Section 8.1
>>
>>   	An implementation should not abort the encryption process when
>>   	encrypting a message to both PQ(/T) and traditional keys to
>>   	allow for a smooth transition to post-quantum cryptography.
>>
>> I think this really depends on the usage/profile and I am not sure if
>> this generic advise is best or even allowable in some cases. As with
>> other migrations, people sometimes implement these separately, and in
>> this case it might make sense to not allow a hybrid to fall back to
>> encrypting to one participant with only classic encryption.
> The working group has discussed this primarily in the context of the
> e-mail ecosystem, and we reached the conclusion that "cannot encrypt
> this message" when doing "reply all" would be actively harmful today.
>
> This is under "Migration considerations" after all.
>
> In the future, when support is more widely deployed, this guidance might
> change.
>
> What if we phrased it like:
>
>     During the transition to post-quantum cryptography, an implementation
>     attempting to encrypt a message to both PQ(/T) and traditional keys
>     should generally proceed by default (perhaps logging a warning) to
>     avoid disruption to communications.  A future revision of this
>     specification may prohibit encrypting a given message to both PQ(/T)
>     and traditional keys.
>
>> I am also confused by the lowercase "should not" for an "implementation".
>> Usually we use strict RFC 2119 language for implementations and lower
>> case guidance for (human) process/choices during operations.
> I could see this using RFC 2119 SHOULD instead of "should", since we are
> concerned it will effect interoperability.  The document uses 2119
> RECOMMENDED in section 8.3.
>
>> Section 8.2
>>
>> Similar with the lowercase "may" here.
> Sure, i wouldn't object to MAY here.
>
> Re-reading these sections in the migration considerations section, it
> occurs to me that verification nuance is subtly different from signing
> nuance during the transition period.  I've proposed some text that might
> account for that nuance here:
>
>    https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/227
>
>> Section 8.3
>>
>> Why is the RECOMMENDED not a MUST? What is a possible valid exception case?
> The working group could see no way to critically enforce the MUST here
> -- it certainly wouldn't break interoperability unless each
> implementation were to keep track of all asymmetric public keys (as
> cryptographic objects) used in OpenPGP, and prepared some sort of
> blocklist based on objects that showed up more than once.  And the WG
> didn't want a MUST NOT BUT WE KNOW SOME OF YOU WILL 😉
>
> Apparently some users might find key generation expensive; for
> example, those who are in need of using a key stored in some sort of
> hardware module that can't be cheaply re-generated.
>
>> Section 9.1
>>
>>   	Furthermore, it is also not possible to craft a new signature
>>   	for a message that was signed twice with a composite algorithm
>>   	by interchanging (that is, remixing) the component signatures,
>>   	which would classify as a weak existential forgery. This is due
>>   	to the fact that each v6 signature also includes a random salt
>>   	at the start of the hashed meta data, as also specified in the
>>   	aforementioned reference.
>>
>> Couldn't I simply choose to use the same "random salt" ?
> Upon re-read, i'm also not sure I understand this paragraph.  The prior
> section (which describes the protections offered by the algorithm ID
> field) makes more sense to me.  Perhaps the editors can clarify?
>
>
>> Section 11
>>
>> The reference column only lists Section, but should list RFC-TBD plus Section.
> I've proposed this inhttps://github.com/openpgp-pqc/draft-openpgp-pqc/pull/226
>
>> Appendix A
>>
>> As I cannot verify these test vectors myself, did the WG have at least two
>> independent implementations confirm these vectors are correct?
>
> Yes, you can see interoperability testing of 5 different implementations
> at:
>
> https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?q=pqc&impls=16970
>
> (search for draft-ietf-openpgp-pqc to find the explicit test vectors)
>
> They are indicated as being from draft-ietf-openpgp-pqc-09, but the test
> vectors haven't changed between that draft and -12, as you can see here:
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-openpgp-pqc-09&url2=draft-ietf-openpgp-pqc-12&difftype=--html
>
>
>> Comments / NITS
>>
>> Abstract:
>>
>>   	advent of quantum computers
>>
>>   	in the presence of quantum computers.
>>
>> Can we use the same terminology as PQUIP recommends? eg here we should use
>> cryptographically relevant quantum computer (CRQC) and "protect against CRQCs"
>>
>> (seehttps://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-engineers)
>>
>>
>> Introduction:
>>
>>   	Such cryptographic algorithms are referred to as post-quantum cryptography. Th
>>
>> Perhaps introduce the acronym here, too eg post-quantum cryptography (PQC) to align it
>> with PQUIP?
>>
>>
>>   	For the two ML-* schemes, this document follows the conservative
>>   	strategy to deploy post-quantum in combination with traditional
>>   	schemes such that the security is retained even if all schemes
>>   	but one in the combination are broken.
>>
>> Maybe add a sentence that this is called a hybrid? (you do refer to I-D.ietf-pquip-pqt-hybrid-terminology
>> later on int the document but not yet here)
>>
>>
>>   	from the respective elliptic curve specification.
>>
>> Can this get a normative reference appended?
> I agree it would be good to resolve all of these nits.
>
> Regards,
>
>          --dkg
>
> _______________________________________________
> 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]