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
_______________________________________________
COSE mailing list -- cose@ietf.org
To unsubscribe send an email to cose-le...@ietf.org
