Hi, With not hats.
I first encountered the style of extracting, cannonicalizing, and signing in JSON-LD data integrity proofs, which are a new W3C standard way to secure JSON-LD by converting it to RDF before signing it... Having the graph isomorphism problem as a dependency for a cryptography operation seems questionable to me, but beauty is in the eye of the beholder. I gather XML signatures had a similar structure. Anything other than signing / verifying the bytes is error prone, and opens the verifier up to deserialization / canonicalization issues on attacker controlled messages. You can imagine creating something like XML dsig in yaml, json-ld, toml or cbor. Just because it's easy to imagine doesn't mean it's a good idea. Regards, OS On Sun, Apr 13, 2025, 12:41 PM Anders Rundgren < [email protected]> wrote: > On 2025-04-13 17:52, Carsten Bormann wrote: > > On 2025-04-13, at 16:37, Rohan Mahy <[email protected]> wrote: > >> > >> enveloped signature > > > > That term has a meaning in XML, but “enveloped” appears to mean > something different in CMS. > > So I’ll talk about “embedded” signatures. > > Fine. > > > > > The problem with adding a map entry with a fixed map key is that you > can’t have multiple embedded signatures in your data (or the value of the > data needs to be an array). > > Using an array for his purpose is obvious. > > > > More generally speaking, please do think about and fully specify the > actual transform you think you are using when erasing the signature before > verifying it; don’t take that for granted. > > The transformations using CBOR Core are fortunately quite simple. > > > > > There is a semantic difference between multiple independent signatures > and a countersignature, as detailed in RFC 9338 [1]. The countersignature > must not erase the signature to be countersigned! > > I'm aware of that. Here enveloped/embedded signatures really shine; an > easy solution is just embedding the original document in a new one: > > CSF 👍: > > { > 1: { > 1: "Hello signed world!", > 2: [2.0, true], > simple(59): { > 1: -50, > 6: > h'0e537463c12db5feb1641b04ee48db476dda95e8b999121c508527beeee8f69ce453143418e6d6c6d00f1f7bb437f974026f68d8704f5fdc6ed6bc18daa4f80e' > } > }, > simple(59): { > 1: -50, > 6: > h'739155e7c8bf391f04db17e52e365ee323b5854966740fbfa0af9692c07bbc80533af3e7d90f04d5096deb7a78c4225227cbe58d81b52f2bc1c7e03d841e600f' > } > } > > > > COSE 😱: > > 97([h'a10105', { > 11: [h'a10127', { > 4: h'3131' > }, > h'602566f4a311dc860740d2df54d4864555e85bc036ea5a6cf7905b96e499c5f66b01c4997f6a20c37c37543adea1d705347d38a5b13594b29583dd741f455101'] > }, h'546869732069732074686520636f6e74656e742e', > h'2bdcc89f058216b8a208ddc6d8b54aa91f48bd63484986565105c9ad5a6682f6', [[h'', > { > 1: -6, > 4: h'6f75722d736563726574' > }, h'']]]) > > Anders > > > > > Grüße, Carsten > > > > [1]: https://www.rfc-editor.org/rfc/rfc9338#section-1-2 > > > > _______________________________________________ > 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]
