From nobody Thu Feb 16 11:26:08 2023 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30810C187997; Thu, 16 Feb 2023 11:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVhkpjrJV8U9; Thu, 16 Feb 2023 11:26:04 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C6EC1BE88F; Thu, 16 Feb 2023 11:26:04 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id l2so2915473wry.0; Thu, 16 Feb 2023 11:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=KifGx+XAu0oizyj5xj7MDVjq+pdl0yWJhJhNemR0Ka0=; b=V2QDEd1YCkb3EXZttLIeTpq5g/3+B8sYSiHGX/3L4UaCayzaBeUwjFZjrYjkiwD99h IpTk4YQOUs//fFSNNcrDQlZf+rIjCYFUt/PECNxqNdHPLix+wQKp9Gi+aWG3SKZ58uYI NAMvgGfeX0zIIPaqHd4nvlh1j42HxcPrdffqMLxghElT8Dq1t0BljdAWDn57ys3RA7SZ p9WhlhznZzCDnznaXlwkiTRQDlhpnQMsX0jHQsA5giPoNHnVKCWhlOl+y1jYc0o6Agyu MNC741Hf7uJKiu+5Xx2G7TPg/C+CxMXIYjL7PTOOyt87pusQRaw61CqPgmPs3pV0Etld zThA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=KifGx+XAu0oizyj5xj7MDVjq+pdl0yWJhJhNemR0Ka0=; b=b2KqG29itiPmvxZ8YytYn2/iskYv1sUzl+ore976Blb+Cmk/gEN2JItJutXx2HQ/cn OuJPJinVa8B1HPAx7d2re6y8jlfYQCfVtUFeXnpmrVt78fYJkVNYpYJb+Mb9ba59c/gJ B9mPv4vuqAKRjdrM3l3eo+qc70A89/5p/VUcbr0HQt4boUdd+JYSLBPHAImN3m091RMB Wd0ROwoJTEiPSXCB/DoCD6tibmsLY5jXqDwWjcw8vcxYhnYqgOxirW1EbsglNJT3e0n9 BRg7r1RXPHalg7m6k2n4jbxaL1Wzxlx/lMaPYwo98BRhRDb66hZITtsyzT0Q4FMkueF9 yuaA== X-Gm-Message-State: AO0yUKUN2GEVtYmgGJa+/5+6MysqdrpxGzPVF0N4Hq5nIcwRSdDRhr9e b0NGjN/uNXE1eO0tD1kFkoY= X-Google-Smtp-Source: AK7set9GEcrgLjBFA16xO4E3jpk3u9m42oADl9gNoYYwI6jUdLAgg0YzXrbGiJYU2FaN0c1/HNRi9Q== X-Received: by 2002:a5d:4304:0:b0:2c5:5878:8fb7 with SMTP id h4-20020a5d4304000000b002c558788fb7mr4633625wrq.13.1676575562418; Thu, 16 Feb 2023 11:26:02 -0800 (PST) Received: from ?IPV6:2a01:e34:ec4e:5670:989c:3e40:8ae0:8050? ([2a01:e34:ec4e:5670:989c:3e40:8ae0:8050]) by smtp.googlemail.com with ESMTPSA id g9-20020adff3c9000000b002c54d8b89efsm2375863wrp.26.2023.02.16.11.26.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Feb 2023 11:26:02 -0800 (PST) Content-Type: multipart/alternative; boundary="------------dOpQpTHc0tXam0lZr3ssKwb0" Message-ID: Date: Thu, 16 Feb 2023 20:26:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: Laurence Lundblade Cc: cbor@ietf.org, "cose@ietf.org" References: From: Anders Rundgren In-Reply-To: Archived-At: Subject: Re: [Cbor] [COSE] New deterministic CBOR Libraries (Rust & Swift) from Blockchain Commons X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2023 19:26:08 -0000 This is a multi-part message in MIME format. --------------dOpQpTHc0tXam0lZr3ssKwb0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 >> To: Credentials Community Group , W3C Verifiable Credentials WG >> CC: Wolf McNally , Shannon Appelcline >> >> >> >> 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 because of our specific need to produce deterministically repeatable hashes in the Merkle Tree underlying our Gordian Envelope 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 as a data format and why dCBOR is particularly advantageous, either here or in our discussion forums at GitHub . >> >> Thanks! >> >> -- Christopher Allen >>    Blockchain Commons >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > --------------dOpQpTHc0tXam0lZr3ssKwb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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:
We've also produced a CLI app using our Rust library, which can be used to test parsing and validation:
We focused on the deterministic flavor of CBOR per §4.2 of RFC-8949 because of our specific need to produce deterministically repeatable hashes in the Merkle Tree underlying our Gordian Envelope 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 as a data format and why dCBOR is particularly advantageous, either here or in our discussion forums at GitHub.

Thanks!

-- Christopher Allen
   Blockchain Commons
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


--------------dOpQpTHc0tXam0lZr3ssKwb0--