On Fri, 4 Jul 2025 at 21:13, Ilari Liusvaara <[email protected]> wrote:
> On Fri, Jul 04, 2025 at 06:04:47PM +0530, tirumal reddy wrote: > > On Thu, 3 Jul 2025 at 18:43, Ilari Liusvaara <[email protected]> > > wrote: > > > > > On Thu, Jul 03, 2025 at 12:33:40PM +0530, tirumal reddy wrote: > > > > 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. > > > > > > AKP can not be used with Direct Key Agreement algorithms in JOSE due to > > > causing serious operational issues with no workarounds. In COSE, there > > > are workarounds, but using AKP with DKA still causes operational > issues. > > > > > > The correct kty for ML-KEM keys in COSE and JOSE is OKP (yes, it looks > a > > > bit odd). > > > > > > > Please elaborate on the operational issues to use AKP. > > AKP key has to essentially select if the key is used for single or > multiple recipients. Wrong choices either do not work at all > (multiple-recipients with DKA key in JOSE) or are inefficient. > > No current key has issue like that: Encryption keys can work fine for > single and multiple recipients, as the alg footgun either does not > exist, or is not mandatory. > Got it, "OKP" won't work either, since RFC8037 mandates that "crv" must come from the "JSON Web Elliptic Curve" registry. Since ML-KEM is not an elliptic curve, it seems defining a new "kty" is necessary. > > > > > Then the KDF seems to be busted, as it does not seem to mix in the > > > context information. While many fields of standard COSE/JOSE context > > > info are useless (especially the PartyU/PartyV ones), there are still > > > some critical ones. > > > > > > Specifically, for COSE, AlgorithmID, keyDataLength and protected > > > are critical. For JOSE, AlgorithmID and SuppPubInfo are critical. > > > Then, the private context info goes to SuppPrivInfo. > > > > > > > I don't see any of those fields used in JOSE/COSE HPKE drafts (other than > > SuppPrivInfo). > > JOSE/COSE HPKE has absolutely nothing to do with how key agreement > works in JOSE/COSE. There is no "similar", only is or is not. > > And COSE-HPKE does explicitly use protected via the structures passed as > HPKE aad. > > Then RFC 9052 explicitly requires protected in context info for Key > Agreement with Key Wrap, and impiles that protected is required for > Direct Key Agreement. > > Then Direct Key Agreement is a privileged mode in both JOSE and COSE > with properties no other mode can have. Thus using KEM for deriving > CEK has to be Direct Key Agreement, it can not be anything else. > > Key Agreement with Key Wrapping is also privileged mode in JOSE. > However, Key Agreement with Key Wrap is not privileged in COSE, but > what KEM followed by Key Wrap does fits perfectly in that mode. > Thanks for the clarification. What would be the security justification for excluding PartyUInfo and PartyVInfo in both COSE and JOSE ? Cheers, -Tiru > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
