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 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" ) ? Can a P-256 key be used for 7, 8 and encap / decap (kems / tbd) ? AFAIK, there is no guidance on this, and no registry of key operations which is extensible (which could be a good thing). The pop use case is a bit more specific, because pop usually means some form of nonce signing. W3C has been developing the concept of "proofPurposes" and "verification relationships", which are basically subclasses of "sign". For example, this W3C draft distinguishes keys that are used with the "sign" operation as being for "assertions (signing claims)", "authentication (signing nonces)", "capability invocation (???)", "capability delegation (???)", and "key agreement (derive key)"... See: https://w3c.github.io/controller-document/#verification-relationships I have wondered if JOSE and COSE would benefit from "more fine grained" key operation restrictions. I think at a minimum, it would be good to add explicit support for kems / encap and decap, or relate them to "derive key", in some standard track document. I think a new concept that is not tied to web crypto might yield better security properties in the long run. Regards, OS On Wed, Jul 31, 2024 at 10:22 AM Christian Amsüss <christ...@amsuess.com> wrote: > Hello COSE key users, > (selectively putting the overlapping authors in CC to get their > attention -- or should I rather CC CoRE and LAKE?) > > implementing more and more of the full CoAP security stack, I find > myself creating a lot of private keys, practically stored as CBOR files > containing a COSE key. Using a standard format comes with the risk of > mixing up key uses, so I'd like to set key_ops on them to ensure that, > for example, a P-256 key created for EDHOC method 3 (ECDH) is not used > for method 0 (signing). > > None of the CoAP security standards that use asymmetric keys (EDHOC, > Group OSCORE) elaborate on which of their operations relate to which > key_ops: Do they match that table? Or would they, in that table, > correspond to completely new values for table 5 of RFC9052? > > > Whichever ops they relate to: How do they interact? In particular, > outside of the combination of Group OSCORE in group mode (signing) and > pairwise mode (static-static derivation), is there any combination that > is allowed, which would ease the proof-of-possession step of joining an > OSCORE group by performing that proof during EDHOC rather than in a > later PoP step? And: How does either outcome follow from the key_ops > that should be placed on a key generated for Group OSCORE? > > > Best regards > Christian > > -- > You don't become great by trying to be great. You become great by > wanting to do something, and then doing it so hard that you become great > in the process. > -- Marie Curie (as quoted by Randall Munroe) > _______________________________________________ > COSE mailing list -- cose@ietf.org > To unsubscribe send an email to cose-le...@ietf.org > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- cose@ietf.org To unsubscribe send an email to cose-le...@ietf.org
