Using a simple type makes sense for the purpose you describe, but it should be a different value. The semantics of simple(59) is that an array of redacted key claims from the same level of hierarchy follows.
I'm guessing your simple type (call it simple(42)) means that a map follows containing an enveloped signature and its parameters, which covers everything in the payload except the simple(42) key. Thanks, -rohan On Sun, Apr 13, 2025, 07:16 Anders Rundgren <[email protected]> wrote: > Although I initially frowned at the idea of supporting CBOR simple types, > I have subsequently changed my mind, since the core idea (a unique/reserved > label), would fit as a glove in my enveloped signature scheme as well. > Currently an application must specify an *application-specific* label > holding the signature container: > > { > 1: "Hello signed world!", # Application data > 2: [2.0, true], # Application data > -1: { # Enveloped signature container > 1: -50, > 6: h'2498d8a12e6f3fea31...b55f5ced3b5c16b24a0b' > } > } > > It would be way cooler to rather use: > > { > 1: "Hello signed world!", > 2: [2.0, true], > simple(59): { > 1: -50, > 6: h'0e537463c12db5feb1...26f68d8704f5fdc6ed6b' > } > } > > By doing this, the associated library would not need to bother with a > signature container label parameter either. > > That CBOR simple types lexicographically come after numeric and > alphanumeric labels is also an advantage. Always in the same place (last). > > So rather than making simple(59) a specific SD-CWT item, it could be a > general purpose label. What to call it? I leave that to the bikeshed > builders :) > > Anders > > _______________________________________________ > CBOR mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
