Thanks Simo for the review. Please see inline On Tue, 7 Oct 2025 at 01:06, Simo Sorce <[email protected]> wrote:
> On Sun, 2025-10-05 at 14:38 +0530, tirumal reddy wrote: > > The revised draft ( > https://www.ietf.org/archive/id/draft-ietf-jose-pqc-kem-04.html) has been > updated to use the “AKP”; the update is intended to initiate further > discussion within the WG. > > > > -Tiru > > > > A few comments on this draft: > > 1) In the draft the terms "" and the "decapsulater" are > defined. I think a better spelling would be "encapsulator" and > "decapsulator" ("or" instead of "er" suffix, similar to calculator, > insulator, escalator, etc..). Although most online dictionaries to do > not carry either form I found some that mention "encapsulator" (with > the or suffix) and none that mention "encapsulater". > Also note that after having defined these terms they are actually never > used in the rest of the text, so perhaps the last paragraph could > simply be dropped. (section 2.1) > I will remove the last paragraph in Section 2.1. > > 2) In the Key derivation the optional customization label is defined as > empty. Wouldn't it make sense to define it as "JOSE" / "COSE" > respectively to achieve domain separation ? (sections 5.1 and 5.2) > Yes, it can be defined as "JOSE KDF" and "COSE KDF". > > 3) The use of AKP here really shows how AKP is not a great option > (IMHO), as it forces a distinction that makes little or no sense, given > there is no risk of confusion or misuse between direct agreement and > key wrap uses with the same keypair. I can see how some protocols may > want to use either/or with the same key depending on the other > circumstances (section 10). > The WG needs to discuss and decide whether to use AKP or OKP for this purpose. The key trade-off seems to be between enforcing algorithm binding in the key structure to reduce misuse and keeping flexibility to avoid layering issues. If JWK starts enforcing operational policies (like “this key must only be used for this algorithm”), it may interfere with higher layers (such as application logic or key management) that should be making those decisions. One possible balanced approach would be to continue using AKP, but make the "alg" field optional when the key is used for key agreement. > 4) I object to the characterization that forcing the use of SEED only > as a private key promotes interoperability, so I would drop that > preamble from the phrase that defines what the specification mandates > in this area (last paragraph of section 10). No, it simplifies key transport and allows keying material to be encrypted, exported/imported between HSMs without ambiguity. Cheers, -Tiru > > > > -- > Simo Sorce > Distinguished Engineer > RHEL Crypto Team > Red Hat, Inc > >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
