On 2025-04-13 20:40, Michael Prorock wrote:
Very big +1 to Orie
dCBOR (featuring Carsten Bormann and Laurence Lundblade as co-editors), was explicitly designed to support cryptographic operations. dCBOR accomplishes this through deterministic encoding which is not the same as canonicalization. Unlike canonicalization, deterministic encoding is trivial, a mere 300 lines of JavaScript is needed for a full-blown CBOR encoder: https://github.com/cyberphone/simple-cbor-encoder.js/blob/main/cde.js Anders
On Sun, Apr 13, 2025, 12:04 Orie <o...@or13.io <mailto:o...@or13.io>> wrote: 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 <anders.rundgren....@gmail.com <mailto:anders.rundgren....@gmail.com>> wrote: On 2025-04-13 17:52, Carsten Bormann wrote: > On 2025-04-13, at 16:37, Rohan Mahy <rohan.m...@gmail.com <mailto:rohan.m...@gmail.com>> 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 <https://www.rfc-editor.org/rfc/rfc9338#section-1-2> > _______________________________________________ CBOR mailing list -- c...@ietf.org <mailto:c...@ietf.org> To unsubscribe send an email to cbor-le...@ietf.org <mailto:cbor-le...@ietf.org> _______________________________________________ COSE mailing list -- cose@ietf.org <mailto:cose@ietf.org> To unsubscribe send an email to cose-le...@ietf.org <mailto:cose-le...@ietf.org>
_______________________________________________ COSE mailing list -- cose@ietf.org To unsubscribe send an email to cose-le...@ietf.org
