search

openpgp-pqc / draft-openpgp-pqc

Repository of the WIP draft-ietf-openpgp-pqc
Other
8 stars 2 forks source link

State that implicit preferred algorithm lists exist even when the corresponding subpacket is missing #106

Closed falko-strenzke closed 1 month ago

falko-strenzke commented 3 months ago

Regarding the "Preferred AEAD Ciphersuites" subpacket and "Preferred Symmetric Ciphers for v1 SEIPD" subpacket, we need a clarification in Sec. "8.1. Symmetric Algorithms for SEIPD Packets". The crypto-refresh does not clearly state that the implicit lists of preferred algorithms are in force even when the respective subpacket is missing. We should clarify this at least in the PQC specification.

dkg commented 3 months ago

I'm not sure how much this draft needs to fix this. But at a maximum, what we need to say is "a certificate with no AEAD Ciphersuite Preferences subpacket should be treated the same as an otherwise-identical certificate with an present-but-empty AEAD Ciphersuite Preferences subpacket". However, framed this way it does seem like this is something that belongs in the primary specification, and not as a clarification in the PQC draft.

What other interpretation is possible, which a wayward implementer might actually consider?

TJ-91 commented 3 months ago

"a certificate with no AEAD Ciphersuite Preferences subpacket should be treated the same as an otherwise-identical certificate with an present-but-empty AEAD Ciphersuite Preferences subpacket".

That's what I tried to do in #110 with the restriction to the PQ/T case and also including v1 SEIPD preferences. That makes it 60% longer than the quote if we skip the last optional sentence about not assuming v2 SEIPD features based on the subpacket.

What other interpretation is possible, which a wayward implementer might actually consider?

The only sane alternative would be to assume AES-128 or AES-256 for v1 SEIPD and AES-128/OCB for v2 SEIPD, I guess (currently we don't say AES-256/OCB is MTI). All in all, it is only nitpicking and I am also not sure how much this draft needs to fix this. However, I'm always happy when a specification gives way to only exactly one interpretation (as it should be).

Personally, I'm also fine if we do not make the change.

falko-strenzke commented 1 month ago

According to the discussion in #110 there is no consensus for a change based on my observation that is the subject of this issue. Thus I am closing it.