Hi Andrew,
Yes, I think you are right. I was reading that case too narrowly.
With:
ADDKE1 = { PQ_KEM_1, PQ_KEM_2 } ADDKE2 = { PQ_KEM_1, PQ_KEM_2, NONE }
the responder can express the outcomes I had in mind, assuming the normal
RFC 9370 rule that the selected non-NONE algorithms are not duplicated:
- both: select PQ_KEM_1 in one ADDKE slot and PQ_KEM_2 in the other;
- only PQ_KEM_1: select PQ_KEM_1 and NONE;
- only PQ_KEM_2: select PQ_KEM_2 and NONE.
So I would retract my “not directly expressible” phrasing for that row.
The remaining implementation-facing point still seems useful: if the
initiator’s intent is “one mandatory from this set, plus at most one
optional additional method from the same set”, it should encode that with
an explicit NONE in the optional ADDKE slot, not by sending repeated
mandatory ADDKE lists and expecting the responder to repair them. A
responder should still reject outcomes that require duplicated non-NONE
algorithms or an implicit NONE that was not proposed.
Best,
Songbo
On Tue, 23 Jun 2026 09:40:09 -0400, Andrew Cagney [email protected]
wrote:
- both-or-one, meaning (PQ_KEM_1 AND PQ_KEM_2) OR PQ_KEM_1 OR PQ_KEM_2:
not directly expressible as one RFC 9370 proposal, as far
as I can tell.
addke1=kem1,kem2
addke2=kem1,kem2,none
?
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
