The changes look good to me, though I'm not able to provide feedback on the use of AKP at this time.
-- *Stepan Yakimovich* čt 3. 7. 2025 v 9:04 odesílatel tirumal reddy <[email protected]> napsal: > Thanks for the detailed feedback. I raised a PR > https://github.com/tireddy2/PQC_JOSE_COSE/pull/11 to address your > comments, please have a look. > > Cheers, > -Tiru > > On Wed, 25 Jun 2025 at 17:38, Yakimovich, Stepan <[email protected]> > wrote: > >> Dear authors and JOSE WG, >> >> I am writing to provide feedback on the draft, based on my experience >> implementing >> ML-KEM JWE support >> <https://bitbucket.org/connect2id/nimbus-jose-jwt/pull-requests/128> in >> the Nimbus JOSE + JWT library. >> >> First, I'd like to point out two areas where the spec currently seems >> lacking: *test vectors* and *JWK considerations*. I hope these will be >> addressed in future versions of the spec. >> >> Next, I encountered the following ambiguities and potential issues: >> >> *1.* The spec does not say what the "ek" header parameter stands for. My >> interpretation is "encapsulated key." Could you please clarify this? >> *2.* In part 6.1, there seems to be a typo: >> >> ``` >> * The recipient MUST base64url decode the ciphertext from the JWE >> Encrypted Key and then use it to derive the CEK using the process defined >> in Section 4.3. >> * The JWE Encrypted Key MUST be absent. >> ``` >> >> I believe the first bullet point should refer to the "ek" header >> parameter instead of "JWE Encrypted Key," as the latter is stated to be >> absent. My proposed correction is: >> >> ``` >> * The recipient MUST base64url decode the ciphertext from the "ek" >> header parameter and then use it to derive the CEK using the process >> defined in Section 4.3. >> * The JWE Encrypted Key MUST be absent. >> ``` >> >> *3.* I'm struggling to interpret the change in Section 5.1 (see the diff >> between versions 00 and 01 >> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-jose-pqc-kem-00&url2=draft-ietf-jose-pqc-kem-01&difftype=--html>) >> regarding >> the use of "MAY" for mutually known private information in the KDF. In >> version 00, there is zero ambiguity -- we take data from header parameters >> and use it as an input to a KDF. In version 01, as a recipient of a JWE, >> how am I supposed to know whether to feed the mutually known private >> information to the KDF? Could you please clarify the intended behavior and >> the implications of this "MAY" keyword? >> >> Thank you for your time and consideration. >> >> -- >> *Stepan Yakimovich* >> >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
