On 2022-07-11 13:05, Carsten Bormann wrote:
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.
IMO, that is perfect because it is free from policy and application-specific
details that (in my mind...) do not fit in an otherwise general purpose
specification.
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.
Well, if you are about to create large-scale ecosystems that function without human intervention or
AI, you may have to stick to fairly strict and simple methods. "Predecessors" to IoT
like SIM and EMV which were extremely constrained did not require any "tricks" for
securely verifying signatures.
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.
As I wrote, my comments were more targeted at LAKE and it use and
interpretation of COSE.
If saving bytes is the primary objective I would consider a custom schema
centered around identity, making algorithm- and key-identifiers redundant. If
both sides of the LAKE (no pun intended) are constrained, I'm out of good (or
bad) ideas :)
Cheers,
Anders
Grüße, Carsten
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
