From nobody Thu Feb 16 10:13:47 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 768BEC1BE86F; Thu, 16 Feb 2023 10:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 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 4_lPMrjhC0Vr; Thu, 16 Feb 2023 10:13:42 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2100.outbound.protection.outlook.com [40.107.236.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1583C17CE92; Thu, 16 Feb 2023 10:13:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IuIud+N6xj/8I5ml5xnzSEIvkIitLj8QC1WOSc5SEQdJKq2KuMiMAGCxgPwxd7GpLcckr/HT3bXwUwyoLkFN9zETjpzSdWX9jG3LeDge57QgOXeFLjezKcWh27ThJl7GUrjOH+HNmJA2vB9VDOHHPAF82EJOSuQqXdTPlZohh0Cix/4WvAhz7y3m2RkRc+TSX0V3M1bQgnIo2SIvyJeL5fBq9QKZ4kAkuFrawvXI+c3Cc8g0fR4XICNws5mSE4JtunWICXRfSeq2zoobZ+stWGfxVjlJzpMKL8MVN/bL2Rw5rNHaV0wifoYKmJgg65Jf3Z4QWdr94b2AG8i14nOD+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wcC6pjufzHBH6aQyXNmzvCQTSbKzN1neZortAfVE2w0=; b=XWXJEJ+PJY7pk1HOjWW/9FwnvrarQBpbgU8sMpM2zJiDxPjbJmRP08LJixz5DtMHO9QbgxC/CKRPeaj35wIKM56NTGM2mzUrd/HyKWJNk1/hiRJbV8ti3BXCqfWZz3w5vimRyOPtTFuQKDrwT/XcQZB8Vt5cQXApbLPPLH0lplPi+FtNxxTlc31HGRuezZOAqOPZhfDBxVbeDpduOdb6vD4/JzqYveb4DzL2znF5cl6Zde/Mquf/7sTOpeMg+0up8eP7EXHfPpMnd6pkKGSxlLowSzR4izLgm+Dc5vwVIGyN8C4A1FJYVEd3VOiou3F9GwRo3nZQLujzJEuhHXArBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=island-resort.com; dmarc=pass action=none header.from=island-resort.com; dkim=pass header.d=island-resort.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=island-resort.com; Received: from PH7PR22MB3092.namprd22.prod.outlook.com (2603:10b6:510:13b::8) by CH2PR22MB2055.namprd22.prod.outlook.com (2603:10b6:610:8f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.12; Thu, 16 Feb 2023 18:13:36 +0000 Received: from PH7PR22MB3092.namprd22.prod.outlook.com ([fe80::1aae:283a:d7b:3d58]) by PH7PR22MB3092.namprd22.prod.outlook.com ([fe80::1aae:283a:d7b:3d58%4]) with mapi id 15.20.6086.026; Thu, 16 Feb 2023 18:13:35 +0000 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EB418352-F1F4-4E63-BDBF-47FA18600F12" Date: Thu, 16 Feb 2023 11:13:25 -0700 In-Reply-To: Cc: cbor@ietf.org, "cose@ietf.org" To: Anders Rundgren References: X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ClientProxiedBy: FR3P281CA0200.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a5::15) To PH7PR22MB3092.namprd22.prod.outlook.com (2603:10b6:510:13b::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH7PR22MB3092:EE_|CH2PR22MB2055:EE_ X-MS-Office365-Filtering-Correlation-Id: fd7083ee-8f60-436d-b84a-08db1049851c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HNAzJtqc9CaWh7GTHTmhoKoqISmiq4xbKK45dmJbIrD4IY7U8V+/qs8oRu7U5xbdSBCmPAi1m4RRIxD2cOBw3uGbpbR7kUJ9FzWvmioVCpIJiI4K4B+mfwRW748uR8Vz1P3hVw75DhykKp8RMySFjBgL82YG5gwE9aIa9l4yWt0htT3fWpUothwMIw+k+qch2UEdo0L31u5y8QZ2R7eLRS3HzOXFu/6kEgsDQmQJaP2n7GuS5hh7EXlLZi9SNquPILZmPvuZfs6Qd7blLzkPAVcOn9XCBUMG6FVz48yPShYiVCcVgYMWcaPOPNJe7EK7b3jKlxi9MtbYk74zgPF9Qj/toOVw3/tek2oTqk63UbNNx7aUblWsBRVZwDLPmaOBCiApkRqG5nWUg0+7eqLd9Q6hBcnoaAKIuT2ZJeIckjnMceDRpoDzMYmQAlxAHygrbO/wTZ31fW5uDs+lzGL+UNzilvwSRUvd49US9VpZCG1mF20Hs0wf9tBPove+8ewbSnFZxO55VxzFEyvngQd7OTmGxoiNzLt1WgRjCQVNoH1d34iNj2nu6xHM203DW7KZ3Wr41NmtAkaeMb6lLM9KbBS/ASCedl60TVtTrH+D07etAJYMGbKilu4UJ/GzUj6YDyE+qoOtJOkoyayZv3L8nYnGQbJj/BSMjMOtSLVgt8X8BAt4GW/DF/RFSYV7VAv4Uf450VZgckz0867QttOiGB+flIu5Aqw12KSP9woNxhU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH7PR22MB3092.namprd22.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(396003)(346002)(39830400003)(366004)(376002)(136003)(451199018)(5660300002)(38350700002)(966005)(6486002)(36756003)(2906002)(86362001)(52116002)(6666004)(166002)(33656002)(33964004)(53546011)(6506007)(6512007)(186003)(26005)(478600001)(2616005)(4326008)(6916009)(8676002)(41300700001)(66476007)(66556008)(83380400001)(66946007)(38100700002)(8936002)(316002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZVFWd0k3M0F6dGtZMTB5QXNSMVhWcCt0QTV5YWVDZjh3UHJGbDBSbnFZc04v?= =?utf-8?B?N3IrR1RDcFlIaWtFTllSSDIzMlp3ZVgxVWkvN0Q5eGRGcHpOU0xwWmVrWWJu?= =?utf-8?B?MHhxWmpnTnNUNlBHSzVNbUR6NDVxZUhIZ3BDK01GVmlMdVlSTm0wU2N0TG9p?= =?utf-8?B?UmVuUk12QnhJTjRuRERYT3g2eWd6aVBkYUsxcDNHVytzMnZjbmNDYUhTRldQ?= =?utf-8?B?dlNYeWZMcXVKUFU2V3YxMlp1TFF3emRvZ3Z4QWhXcFM2czJ5cWd4dkVya0dG?= =?utf-8?B?MW5oZ2lmbWlDcDdFYUd0Yi9nRWhLR3R2alhxQzhXK1VTREJFREFpMThQa3NZ?= =?utf-8?B?K1UrbkM2by9pRW5QRDExc3ArN3FFcGdxSHVKSyt3NUZENEMra09yb21ONWdx?= =?utf-8?B?cUJIR0ZoU3gxY21EVXMxTU9TbzI3SmtLZlBiYzkwcDRBR0J2eFVSQ2N2c1lr?= =?utf-8?B?S1diNWZIL0RlNXhOMEhBdFZjSUVyMXNhOTN2Uml6dXVhMloyUVVKQTQyOGNx?= =?utf-8?B?ZTQyRnB1ejR3ZnZKSFd6VnF0YW80bzRXZ3FGaS90KzZWZzZwdnNvRlU1UVJP?= =?utf-8?B?cG4weHltbThFbG5iSFMrMEdOTzVBRGtiQnJhajF4MFpMWm16SXZaUGtSWUor?= =?utf-8?B?dGJVbit0Q0VQVHphMm45M1N1UEEweWV0OUJ5K3VKNkxuRzhTRVY3SzA4bTFW?= =?utf-8?B?aG9iOXZ5SmxrS2srOGtVeWN1Y2ZWZmZTWXM2Tzc1VjVMM1Z2Tjlyb2ZCRXlr?= =?utf-8?B?a1Y1WGZBRTlVT0txd2ZobTA5UFk5ZE1OL29iN0Z3TlF5VkhNQ3puaGVoRG9H?= =?utf-8?B?MWRyS2c5YnczNXQzcURGejJSZmI0eHFCWmpDa1JKb3A5Q0dOZmNxQXRKMjRH?= =?utf-8?B?ek9RZU02ZHIxWmJ1SGdwWHFRU3UzVXVoQUJPa1dVRWhaQmlRSUl4VXJYY2Qx?= =?utf-8?B?NGREV1hQUWJ1RHFzRmx0bWRaMG1HR3dUazFzeVhzdXR0dGxFaFRWREc3Tmho?= =?utf-8?B?dFFxLzJYeVZoNXBab0pqMVlaQllKSnhxS1NxVHIwVFZsQWluQWx1VmtHQ0Fa?= =?utf-8?B?VktKUlNGbEd5UUs0YjdiN2t5aUNhR3N6b0xlcnA3VnZrNlg4M2pLdnZDc1Zu?= =?utf-8?B?dDFlYzVVcmovVFZ4N2NyTlA2OGpvYndBOEFMbjlreDVNSHhwNGovUTRrODBG?= =?utf-8?B?MU9aNW5LL2JrNHVzVzI2ZXNZWXdtTlBNY0UrQmVSNGxrT2tnRWMxbG5FZDJT?= =?utf-8?B?NWF5VkZaa0lqd3ZQYkdjMFMvdlFtNkF4U0N3eFRiTU1Td2YrNG5XYWJtTGxF?= =?utf-8?B?ZFduN0RPcjdSY1BEOENXNlFvVFhHS0NEVmZlWEVrUEcrTDF0TXN6YTl0d3F3?= =?utf-8?B?aEVKcENMSnRpbzU2WFY3RStkUU4vRDVMWkVIbWNRdkFYZUtRQnNaVitHUC9U?= =?utf-8?B?T3pzeEIwOFNIT0dSYWVjL1VlRjNUK2lrTGM4LytWM2VIbXhuZENuL2Uwam5l?= =?utf-8?B?OVE5N3Rwa1hTdlpjNXFVS0ZHZmZ6dVRXekpwTUtwYytTeEo2Nmg1dVhiUGdN?= =?utf-8?B?VllTVUpNbEVtYXRJVGdCWU1vWHhRSDAyUElPL1BTd1hDZnV1SCtyUm1RdEgy?= =?utf-8?B?OWFGTlhsZkJDblA4QVZ0Nk1Gb1VkYVgzb25EUDZUaUZZMHNHU04vSThPYU9h?= =?utf-8?B?VUs1aEpiT3pKOTZHcG56bjF6cWppZU1XcEoxNlhkSnEyUHhxUm5hckN3Zm1Z?= =?utf-8?B?aFNKK2pIKzU5ZWtjMUF1UzFvYnV2YzNrSE1ZNjJ5Q0cxcUdyUkpqMS90TWdz?= =?utf-8?B?Zi9aZ2NtVFh6U2Z6bmZleUp6V0dUdTNxNkhXS3ByNDVzSXFsaFNVZkJtb0RZ?= =?utf-8?B?V1lYUnRxVzF5UDZPK01neFFxNENxNE44WVBPWnFVWSs2Zkw3QlpuRlRndlNi?= =?utf-8?B?MTNoRThKb0VGcWhkeTRxWUxGSUNjYXRDRVoybUFOMGhqVzZTV2tSaGRuaGM1?= =?utf-8?B?UXEvbW5HUmJrS245VjdWMTZNL1UyTzF0bGVPcE5pbG8rN1ZVcStxdkx3c2ht?= =?utf-8?B?QTBDQTFoS1pBbWRkN3dVUEpWM3NxaFB3RGlYTkY4L1dxVllSVjNzODdFVEhv?= =?utf-8?Q?Ib6a7Ss0JsJ1KtotLAPzAXWwH?= X-OriginatorOrg: island-resort.com X-MS-Exchange-CrossTenant-Network-Message-Id: fd7083ee-8f60-436d-b84a-08db1049851c X-MS-Exchange-CrossTenant-AuthSource: PH7PR22MB3092.namprd22.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2023 18:13:35.7778 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ad4b5b91-a549-4435-8c42-a30bf94d14a8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8lmUy9ZZ06aOsd1nnFDQKlPAk/s7T4DTF15LuwWsb2KRmhXks4L0yFl5Fj5ldwiiqmZUeUeW2kUzbjxzatmiHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB2055 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 18:13:46 -0000 --Apple-Mail=_EB418352-F1F4-4E63-BDBF-47FA18600F12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I didn=E2=80=99t read the referenced source, but I=E2=80=99m curious why = deterministic is so heavily emphasized. Seems like there=E2=80=99s two = cases: 1) You transmit the signed/hashed data with signature/hash in which case = you don=E2=80=99t 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 = wrote: >=20 > 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 >=20 >=20 > -------- 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 = >=20 > 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 =C2=A74.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! >=20 > 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. >=20 > 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 = . >=20 > Thanks! >=20 > -- Christopher Allen > Blockchain Commons > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_EB418352-F1F4-4E63-BDBF-47FA18600F12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I didn=E2=80=99t read the referenced source, but I=E2=80= =99m curious why deterministic is so heavily emphasized. Seems like there= =E2=80=99s two cases:

1) You transmit the signed/hashed data with signature/hash in which c= ase you don=E2=80=99t need determinism.
2) The sender = and receiver independently do the CBOR encoding of what is signed/hashed, i= n which case you do need determinism.

<= /div>
The encoding of Sig_structure in COSE is an examp= le 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 detach= ed signature where the payload is independently and deterministically compu= ted 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 <anders.rundgren.net@gmail.com&= gt; wrote:

=20
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 & Swi= ft) 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>, Shan= non Appelcline <shannon.appelcline@gmail.com>


Since I know that many projects in the br= oader 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 =C2=A74.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 pick= ed 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.or= g
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_EB418352-F1F4-4E63-BDBF-47FA18600F12--