Re: [Cbor] [COSE] New deterministic CBOR Libraries (Rust & Swift) from Blockchain Commons

On 2023-02-16 19:13, Laurence Lundblade wrote:
> 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?
The Blockchain folks have their applications while I use enveloped signatures:
https://github.com/cyberphone/cbor-everywhere#cryptographic-operations

> Also, what is the limitation with COSE?
https://github.com/cyberphone/D-CBOR#example

> Seems like you could use a detached signature where the payload is independently and deterministically computed rather than transmitted.
Feel free taking on the example using a detached signature.

> Is there a further detailed definition of determinism, such as what to do with floats?
I started with that a while ago, but now it may be time to unify the different solutions.

Anders

>
> LL
>
>
>
>> On Feb 15, 2023, at 10:12 PM, Anders Rundgren <anders.rundgren.net@gmail.com> 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: 	public-vc-wg@w3.org
>> Date: 	Wed, 15 Feb 2023 16:59:31 -0800
>> From: 	Christopher Allen <ChristopherA@lifewithalacrity.com>
>> To: 	Credentials Community Group <public-credentials@w3.org>, W3C Verifiable Credentials WG <public-vc-wg@w3.org>
>> CC: 	Wolf McNally <wolf@wolfmcnally.com>, Shannon Appelcline <shannon.appelcline@gmail.com>
>>
>>
>>
>> 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
>>   * *dCBOR Codec for Swift:* 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
>>
>> 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
>> COSE@ietf.org
>> https://www.ietf.org/mailman/listinfo/cose
>