On 2022-07-11, at 10:37, John Mattsson <[email protected]> wrote: > > >If LAKE presumes using "kid" as a hint only, > > LAKE presumes nothing more than COSE. This discussion in not really related > to LAKE at all. COSE presumes that "kid" can be used as a hint only.
That is not a presumption. This is about a lack of presumptions. The right way to say this would be: COSE puts no requirements on the mechanism a recipient uses to obtain the appropriate key to process the COSE data item. COSE does provides a kid header field that can be used by such a mechanism; no specific semantics are ascribed to this field by COSE itself. Anders: your statement > h'01' may very well mean the second key associated with the specific > sender/producer, if we are talking about signatures. reveals that you do make a couple of presumptions here: — sender and receiver have an agreed, shared way to enumerate senders/producers — a COSE data item always comes with a context that makes clear who that sender/producer is (data in the item, data in the context that somehow is securely bound to the item) — senders/producers have a way of maintaining their key space with unique key ids (not at all a given over time and space!) — recipients’ authorization policies are happy to rely on all this — (implicit, but often comes with the above): that sender/producer identity actually means something for the security semantics. COSE makes none of these presumptions. You are welcome to define a protocol on top of COSE that has all these properties; you appear to believe that is the only way to do a system design. These presumptions come with a cost, so everybody agrees; we need to keep it possible to define protocols using COSE that do not have them. Grüße, Carsten _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
