Hi Anders, I think bstr wrapping for a general signing structure like COSE is the better choice.
* It is a simple way to accommodate signing data of any type (data that is not CBOR). * When signing CBOR the bstr wrap keeps the surrounding CBOR decodable even if the signed CBOR is not well formed. * It facilitates hand off of the payload to another handler as a bucket of bits, an easy hand off. Without the bstr wrap, you have to hand off an instance of the decoder. That's awkward. It also forces the COSE decoder and the payload decoder to be the same library. My decoder has a special function to handle bstr wrapped CBOR. It treats it like an array of one. So, the bstr wrap is not difficult to work with and it doesn't need any extra memory. I actually played around a lot with CBOR signing without the bstr wrap. I ran into trouble extracting the TBS bytes from various decoders. They don't like to output the raw encoded bytes of sub-parts of a sub structure. Also, you keep mentioning "add" and "delete". CBOR is protocol, not a database, so this doesn't seem so relevant. Maybe it is something with your particular API or use case. LL ________________________________ From: Anders Rundgren <[email protected]> Sent: Saturday, March 8, 2025 7:46 AM To: Michael Prorock <[email protected]> Cc: Carsten Bormann <[email protected]>; cose <[email protected]> Subject: [COSE] Re: Signing top-level data in COSE? On 2025-03-08 16:24, Michael Prorock wrote: > I don't particularly find this tone helpful, but solely from a "correcting > the record standpoint" I would say *some* Verifiable Credential cases might > choose to use the data integrity path. Others might use COSE with typ headers > > https://www.w3.org/TR/vc-jose-cose/#securing-vcs-with-cose > <https://www.w3.org/TR/vc-jose-cose/#securing-vcs-with-cose> Pardon the tone... Is this is what people are dreaming about? 18([h'a1013822', {}, h'7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c222c224578616d706c65506572736f6e43726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d2c22616c756d6e694f66223a7b226e616d65223a224578616d706c6520556e6976657273697479227d7d2c2263726564656e7469616c536368656d61223a5b7b226964223a2268747470733a2f2f6578616d706c652e6f72672f6578616d706c65732f6465677265652e6a736f6e222c2274797065223a224a736f6e536368656d61227d2c7b226964223a2268747470733a2f2f6578616d706c652e6f72672f6578616d706c65732f616c756d6e692e6a736f6e222c2274797065223a224a736f6e536368656d61227d5d7d', h'4be11e3c024f4f227f22d9cd2cb275474525330b4f3f0e34708e212cfdce2c3c392f8a4764ca9ccf22c5210e6829de7d3b11239500607ea3e8262808497efd21']) One day they may get something like this: 1010(["https://www.w3.org/ns/credentials/v2";, { "id": "http://university.example/credentials/3732";, "type": ["VerifiableCredential", "ExampleDegreeCredential", "ExamplePersonCredential"], "issuer": "https://university.example/issuers/14";, "@context": ["https://www.w3.org/ns/credentials/v2";, "https://www.w3.org/ns/credentials/examples/v2";], "validFrom": "2010-01-01T19:23:24Z", "credentialSchema": [{ "id": "https://example.org/examples/degree.json";, "type": "JsonSchema" }, { "id": "https://example.org/examples/alumni.json";, "type": "JsonSchema" }], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "name": "Bachelor of Science and Arts", "type": "ExampleBachelorDegree" }, "alumniOf": { "name": "Example University" } }, "authorizationSignature": { 1: -50, 4: { 1: 1, -1: 6, -2: h'fe49acf5b92b6e923594f2e83368f680ac924be93cf533aecaf802e37757f8c9' }, 6: h'919e60bd8ae1f76afbdde8ddbe6d9066bdf7d3b94c5dea3f8577ba7d69ac0b10379f0a5142eadbc984e60ee06681ec015a35dd72a2fc1f747f199f21e83e0706' } }]) Anders https://test.webpki.org/csf-lab/home > > > On Sat, Mar 8, 2025, 10:03 Anders Rundgren <[email protected] > <mailto:[email protected]>> wrote: > > On 2025-03-06 18:38, Carsten Bormann wrote: > > On 2025-03-06, at 17:13, Anders Rundgren > <[email protected] <mailto:[email protected]>> wrote: > >> > >> Q: How do you accomplish this in COSE? > > > > For instance, using the header parameter “typ” (16), see RFC 9596. > > Thanx! > > RFC 9596 is a pathetic workaround to fix a self-inflicted issue 🤡 > > Effectively COSE does NOT support tagged objects in a reasonable way. > > Enveloped signatures OTOH, are compatible with systems using tagging for > all kinds of objects, signed or not. > > This is what the Verified Credentials folks want to do: > > https://www.w3.org/TR/vc-data-integrity/#example-a-simple-signed-json-data-document > > <https://www.w3.org/TR/vc-data-integrity/#example-a-simple-signed-json-data-document> > However, due to ideas like "canonicalization doesn't work" they > [probably] end-up with the usual JWT base&4Url c**p anyway. > > With CBOR, we can finally give these people what they *really* want! > Isn't that good? 😀 > > Anders > > > RFC 9052 header parameter “content type” (3) solves a related, but > different problem. > > > > Grüße, Carsten > > > > _______________________________________________ > COSE mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > _______________________________________________ COSE 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]
