Inline: On Wed, Jul 31, 2024 at 1:27 PM Ilari Liusvaara <[email protected]> wrote:
> On Wed, Jul 31, 2024 at 11:03:47AM -0500, Orie Steele wrote: > > key_ops is defined to parallel to JWK and web crypto key usage: > > > > https://www.rfc-editor.org/rfc/rfc9052.html#section-7.1 > > I think key_ops is just FUBAR. > > > > I think you are asking about derive key (7) and derive bits (8). > > > > The same questions came up with COSE / JOSE HPKE. > > > > Which of these operations corresponds to KEMs?... should HPKE use > "key_ops" > > that mix both kem and symmetric key operations? ( "derive key" + > "encrypt" > > ) ? > > > > AFAIK, there is no guidance on this, and no registry of key operations > > which is extensible (which could be a good thing). > > I think it is whatever permission is required in webcrypto to implement > HPKE. Which does not make any sense any other way. > Then I think it's deriveBits for HPKE... although when importing keys for use with HPKE I think it's common to delete "key_ops", or set it to be the empty array. Should an application throw an error before doing this if it encountered "key_ops" that it did not expect for HPKE? what should it expect for HPKE or edhoc? > > > > The pop use case is a bit more specific, because pop usually means some > > form of nonce signing. > > Key_ops works for signing, but not for verification. > afaik, this would be legal in JWKs used for pop: public key ... "key_ops" "verify", "use" "sig", private key ... "key_ops" "sign" > > > I have wondered if JOSE and COSE would benefit from "more fine grained" > key > > operation restrictions. > > JOSE has "use", which is quite coarse-grained but sensible. > Unfortunately, COSE does not have equivalent. > Yep, it's "sig" or "enc"... that's pretty coarse. https://datatracker.ietf.org/doc/html/rfc7517#section-4.2 > And more fine-grained restrictions would make sense. E.g., restricting > key to a single family of properly-separated operations (which is > cryptographically kosher thing to do). > > > > I think a new concept that is not tied to web crypto might yield better > > security properties in the long run. > > I think it would lead to better security properties. > I hope this was not a typo and that we agree : ) > > > > -Ilari > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
