On 2025-03-09 19:28, lgl island-resort.com wrote:
Hi Anders,
I think bstr wrapping for a general signing structure like COSE is the better
choice.
I don't have an answer to that since this discussion(?) is about signing CBOR
"documents".
COSE embeds the document in the signature container. This is fine from a
security point of view but much less attractive from a system point of view.
Yeah, I'm a SYSTEM architect :)
I have actually worked with this concept since 2000:
https://www.w3.org/TR/xmldsig-core2/#def-SignatureEnveloped
This solution required tons of very complex canonicalization code, giving
canonicalization a bad name.
Then I switched to JSON. Although the IETF never accepted it, my RFC 8785 is a
working solution that has some uptake as well. However, RFC 8785 only works
with I-JSON and also requires special tooling to work.
2022 I cut my ties with JSON (for good), in favor of Deterministically Encoded CBOR. It
was a breeze, no "gotchas" or limits of any kind.
This extract from [*] shows how ridiculously simple validation gets from a CBOR
point of view:
/////////////////////////////////////
// Validate the signed CBOR object //
/////////////////////////////////////
let object = CBOR.decode(cborBinary); // Decode
let csf = object.get(APP_CSF_LBL); // Get CSF container
let alg = csf.get(CSF_ALG_LBL).getInt(); // Get COSE algorithm
let sig = csf.remove(CSF_SIG_LBL).getBytes(); // Get and remove embedded
signature value
let res = hmac(alg, SHARED_KEY, object.encode()); // Note that object.encode()
// reserializes all but sig.
if (CBOR.compareArrays(res, sig)) {
throw "Didn't validate";
}
Anders
*]
https://cyberphone.github.io/doc/research/draft-rundgren-universal-cbor.html#name-code-example
*
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>
<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
<https://www.w3.org/ns/credentials/v2>", {
"id": "http://university.example/credentials/3732
<http://university.example/credentials/3732>",
"type": ["VerifiableCredential", "ExampleDegreeCredential",
"ExamplePersonCredential"],
"issuer": "https://university.example/issuers/14
<https://university.example/issuers/14>",
"@context": ["https://www.w3.org/ns/credentials/v2 <https://www.w3.org/ns/credentials/v2>",
"https://www.w3.org/ns/credentials/examples/v2 <https://www.w3.org/ns/credentials/examples/v2>"],
"validFrom": "2010-01-01T19:23:24Z",
"credentialSchema": [{
"id": "https://example.org/examples/degree.json
<https://example.org/examples/degree.json>",
"type": "JsonSchema"
}, {
"id": "https://example.org/examples/alumni.json
<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 <https://test.webpki.org/csf-lab/home>
On Sat, Mar 8, 2025, 10:03 Anders Rundgren <[email protected]
<mailto:[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] <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>
<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]
<mailto:[email protected]>>
To unsubscribe send an email to [email protected] <mailto:[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]
