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]

Reply via email to