On Wed, Nov 1, 2023 at 12:41 PM Hannes Tschofenig <[email protected]<mailto:[email protected]>> wrote: Finally, the encrypted claim, or enveloped claim as you call it, is interesting but just referencing COSE_Encrypt0 and COSE_Encrypt will give you zero interoperability because of the large number of key distribution mechanisms specified in the COSE RFC. On top of that these key distribution mechanisms need to be "profiled" in order to be used. You provide none of that information in the draft.
I’d like to offer a philosophy on how to handle this — two-phase specification 1) Define highly generic mechanisms applicable to many use cases. 2) Define very specific profiles for very specific use cases. The COSE spec itself is 1). This is very good because you can build a library for it that is usable in many use cases, particularly for low security to high security and for many different key systems. EAT is mostly 1), but does have some of 2) in the Constrained Device Standard Profile. I think we will do less of 2) here in the IETF just by nature of what the IETF does. That’s OK. I thus think it’s right that draft-lemmons-cose-composite-claims doesn’t provide any key distribution mechanism specification just like COSE and EAT don’t. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
