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 <[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]
Date: Wed, 15 Feb 2023 16:59:31 -0800
From: Christopher Allen <[email protected]>
To: Credentials Community Group <[email protected]>, W3C Verifiable
Credentials WG <[email protected]>
CC: Wolf McNally <[email protected]>, Shannon Appelcline
<[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
* *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
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
