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 "encapsulater" 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)
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)
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).
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).
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
