Hi, I didn’t read the referenced source, but I’m curious why deterministic is so heavily emphasized. Seems like there’s two cases:
1) You transmit the signed/hashed data with signature/hash in which case you don’t need determinism. 2) The sender and receiver independently do the CBOR encoding of what is signed/hashed, in which case you do need determinism. The encoding of Sig_structure in COSE is an example of 2), and the payload of a COSE_Sign is an example of 1). Are you doing a lot of 2) here? Also, what is the limitation with COSE? Seems like you could use a detached signature where the payload is independently and deterministically computed rather than transmitted. Is there a further detailed definition of determinism, such as what to do with floats? LL > On Feb 15, 2023, at 10:12 PM, Anders Rundgren <[email protected]> > wrote: > > Deterministic CBOR will as I predicted go where JOSE and COSE did not. > What's missing (IMO) is well-defined subset where for example map keys would > either be tstr or integer. > Anders > > > -------- Forwarded Message -------- > Subject: New deterministic CBOR Libraries (Rust & Swift) from Blockchain > Commons > Resent-Date: Thu, 16 Feb 2023 01:00:25 +0000 > Resent-From: [email protected] <mailto:[email protected]> > Date: Wed, 15 Feb 2023 16:59:31 -0800 > From: Christopher Allen <[email protected]> > <mailto:[email protected]> > To: Credentials Community Group <[email protected]> > <mailto:[email protected]>, W3C Verifiable Credentials WG > <[email protected]> <mailto:[email protected]> > CC: Wolf McNally <[email protected]> <mailto:[email protected]>, > Shannon Appelcline <[email protected]> > <mailto:[email protected]> > > Since I know that many projects in the broader Credentials Community already > use CBOR, I'd like to announce Blockchain Commons' release of dCBOR libraries > for Rust and Swift. In particular, these two languages demonstrate our > support of use cases for dCBOR for mobile in Android and iOS: > dCBOR Codec for Rust: https://github.com/BlockchainCommons/bc-dcbor-rust > <https://github.com/BlockchainCommons/bc-dcbor-rust> > dCBOR Codec for Swift: https://github.com/BlockchainCommons/BCSwiftDCBOR > <https://github.com/BlockchainCommons/BCSwiftDCBOR>We've also produced a CLI > app using our Rust library, which can be used to test parsing and validation: > dCBOR CLI: https://github.com/BlockchainCommons/dcbor-cli > <https://github.com/BlockchainCommons/dcbor-cli>We focused on the > deterministic flavor of CBOR per §4.2 of RFC-8949 > <https://www.rfc-editor.org/rfc/rfc8949.html#name-deterministically-encoded-c>because > of our specific need to produce deterministically repeatable hashes in the > Merkle Tree underlying our Gordian Envelope > <https://www.blockchaincommons.com/introduction/Envelope-Intro/> data format. > We suspect that there will be others with similar needs and hope these dCBOR > libraries will prove useful for other specs & standards using CBOR! > > I'd love to get any advice, comments, or thoughts you have on our dCBOR > libraries, as well as any requirements that the libraries may need to meet. > I'd also appreciate to get any CCG-related CBOR test examples that we can use > in documents and examples, such as mDL and COSE tests. > > I'm also happy to discuss why we picked CBOR > <https://www.blockchaincommons.com/introduction/Why-CBOR/> as a data format > and why dCBOR is particularly advantageous, either here or in our discussion > forums at GitHub <https://github.com/orgs/BlockchainCommons/discussions/184>. > > Thanks! > > -- Christopher Allen > Blockchain Commons > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
