Restrictions regarding combinations of legacy and "PQC" recipients

[falko-strenzke]

Johannes pointed out that we have the following restriction:

• Since our draft restricts PQC algos to be used only with v5 PKESK (which we do not really need for the implicit rejection with AEAD through the associated v2 SEIPD because the AES Key Wrap has integrity protection RFC3394 which already provides implicit rejection ), a sender cannot send a message to both a legacy recipient that doesn't support v5 PKESK and a recipient for which the sender only knows PQC keys.
• The cryptorefresh allows in this case downgrade to v3 PKESK / v1 SEIPD.
• We have the following alternatives:
  • We can stick to this restriction,
  • or we can drop the requirement which then would allow the same downgrade as in the crypto-refresh.
  • for this we would have to add padding bytes in case of the v3 PKESK (because here the algo ID is also included). This is the same issue as discussed here for the crypto-refresh and the solution defined there should be used in our case, too.

This needs a decision.

[falko-strenzke]

I strongly vote for adopting the same behaviour as in the crypto-refresh, as otherwise the user experience may may suffer in real world applications.

[TJ-91]

I also vote for allowing v3 PKESK and include the same padding (seven zero-octets) as in the crypto refresh.

Further, I think we should add a clarifying statement that for v6 PKESK no padding is applied and we do not add checksum bytes to the session key (for both v3/v6 PKESK).

Update: Currently, there is the discussion to revert the v3 PKESK padding, see https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/266 Update2: This will be discussed in IETF 116

[TJ-91]

https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/266 is now merged and no padding is applied for X25519/X448. Instead, the algorithm identifier is not included as part of the session key in the AES Key Wrap and left unenecrypted.

I can make a MR to align our draft to the crypto refresh

[falko-strenzke]

Meeting 2023-06-05:

* v6 PQC KEM-Keys currently may not create v3 PKESK. This shall now be enabled.
* v4 PQC KEM-Keys are not currently not allowed. This shall now be enabled.
* Restricting PQC signatures to v6 keys and signatures remains as before.
* SK: v4 PQC KEM keys causes any wire format changes?
* AW: no
* AW: bind PQC KEM to AES as symm. algo ID as in the crypto refresh
* AW: for signatures there are differences regarding packet length fields, but not for encryption
* JRH will complete the PR above

[TJ-91]

I updated PR #42.

v4 PQC KEM-Keys are not currently not allowed. This shall now be enabled.

I think the current text does not disallow this (at least not at 5.3.2. Key Material Packets, maybe I've missed it somewhere else) Maybe we should write that it's allowed to use v4 kyber-ecdh keys, to make it explicit