> On Jun 1, 2023, at 1:48 PM, AJITOMI Daisuke <[email protected]> wrote: > > AFAIK, the first occurrence of "enc" comes from > https://www.rfc-editor.org/rfc/rfc7516.html#section-4.1.2 > > Note that COSE-HPKE use "enc" differently, and instead of identifying an aead > algorithm, it represents the output of the kem, in the case of dh kems, that > is a public key as opaque bytes. > > I feel like you're misunderstanding a bit. > The former is "enc(ryption algorithm)" and the latter is "enc(apludated > key)". They are completely different things. And the latter doesn't appear as > a top-level attribute. > > JOSE / COSE tomorrow: > { > "kty": "EC", > "crv": "P-256", > "x": "z0JJ6bYOwvIXL0RlE-0iOUUAQ1KWz2YpPvVLXY2ah-4", > "y": "eXLXYE-rH71FtvWihfOclbcSFNMRMGGDej7X8tc5_s8", > "alg": "ECDH-ES+A128KW (+A128GCM) " ~~~= > "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" > } > > ==> { > "kty":"oct", > "k":"GawgguFyGrWKav7AX4VKUg", > "alg": "A128GCM", // now you know where this came from... you learned it > when you learned their key agreement key. > } > > The "alg" value you refer to as ciphersuites has traditionally remained > within the range of operations expressed by the "key_ops" value. For example, > the key_ops value for "EdDSA" is "sign/verify," while for "ECDH-ES+A128KW," > it is "deriveKey," and for "A128GCM," it is "encrypt/decrypt". > > Your proposal deviates from this rule. If the alg value is > "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM", I feel that the > "key_ops" value should appropriately be "encrypt/decrypt". > However, the purpose of the key is KEM, so the key_ops should include > "deriveBits". If it doesn't, it may not work correctly on web browsers. It is > because the HPKE KEM operation internally needs to call the deriveBits() with > a CryptoKey object as an argument, if the key_ops attribute is present in the > CryptoKey, it must include the value "deriveBits".
Zeroing in here, as this seems like part of the philosophical disagreement. It’s true that the key is used for a KEM operation, but that’s an internal detail to HPKE. From the application’s perspective, the key is used for public key encryption. It seems a lot more intuitive (and simple) to me to just stick with that level of abstraction. Best, Chris _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
