Re: CBOR versus HTTP Message Signature

Justin Richer <jricher@mit.edu> Fri, 23 December 2022 17:22 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16818C1516E9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Dec 2022 09:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu
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 r9tIpdrlHBV0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Dec 2022 09:22:50 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AC2C1516E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 23 Dec 2022 09:22:49 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1p8lke-002nAS-Nv for ietf-http-wg-dist@listhub.w3.org; Fri, 23 Dec 2022 17:22:32 +0000
Resent-Date: Fri, 23 Dec 2022 17:22:32 +0000
Resent-Message-Id: <E1p8lke-002nAS-Nv@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <jricher@mit.edu>) id 1p8lkc-002n9V-LP for ietf-http-wg@listhub.w3.org; Fri, 23 Dec 2022 17:22:30 +0000
Received: from outgoing-exchange-5.mit.edu ([18.9.28.59]) by titan.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <jricher@mit.edu>) id 1p8lka-00F8Wb-5S for ietf-http-wg@w3.org; Fri, 23 Dec 2022 17:22:30 +0000
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 2BNHMGcD024966; Fri, 23 Dec 2022 12:22:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1671816137; bh=3BVBfXs2lB+hPTKDMdehU63zNOnZGRNfyYCm+1Xsyww=; h=From:To:Subject:Date:References:In-Reply-To; b=MzBUwpndPvvFAVELiGvb8KaQfJfUYMz9R3IRfZn6zCaGx0z3Dv3U2CUwGwDtr33+E PjFM03JxGBEPjIfUSChj5REZ+3HM2GeclXapV6DQ/gE2Ghuf+12cv0BdNN3FcIYMgE fcfPY5zQovO0OAv1Fcz+bS64Ax1EscZCujBofytCZ7gdzUjZ6JXeHP9PwBU/AhkUCk xNgyC4o2LKcs0dzVByy7JRjVww5e4NH3zUmfXKK1vQrvx3PwiqsBvRqdBuWR8Irhlp 4WnE9n2c6ke49Urp2Gnv8JL0GvOoRx611Oo4PRZ8mnvwIuEMXOhIdxJ/kH/d6IKmS1 dgJZghvfjHaWA==
Received: from oc11expo9.exchange.mit.edu (18.9.4.14) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Fri, 23 Dec 2022 12:21:59 -0500
Received: from oc11exhyb5.exchange.mit.edu (18.9.1.110) by oc11expo9.exchange.mit.edu (18.9.4.14) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Fri, 23 Dec 2022 12:22:16 -0500
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.40) by oc11exhyb5.exchange.mit.edu (18.9.1.110) with Microsoft SMTP Server (TLS) id 15.0.1497.42 via Frontend Transport; Fri, 23 Dec 2022 12:22:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i3/uy0ECaveRaP7SZp+eB1WWA5xQMQGJvtRIQJiQ1IgD5WKFSud6VJ/t4krJ6uDXZNS5uIHhbBHZsivbCFld79o0BnJcIOBR29gshTPtEXLzw4Ley5tmu9OdMYt4JFgma/xr9en4RzbiwasYsssI2Tmr0YideykJAbBCGTm1F39JwYIFRyZiUl+r1XEQuW2GYg7DzFWdiZonKz06YsQYuwZ5wdrq+/rPCfBEEGphPL9EVbdoGsGWzm9kgkWT5UZAssgb05XZnPyc0KOrwXgps/KG4veQIJrd/ebZdBA4SY+yZkOyWwZgCT0XRg5rU8pP1DcwsdQ92Q69bUu/5K2cKg==
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=3BVBfXs2lB+hPTKDMdehU63zNOnZGRNfyYCm+1Xsyww=; b=D+kvrNWP3HbH0QmrmxYJmL++rFdD7K+trAV7dE8eI90MqRT5UQZ8VW3VF2G2VKO1kiiVOLQtwb9WyAbVUHnvo9+ssHE3Y4/OFyi5zVWKO4Pp9PbOcCz5bseXpgFfVWbzgTTdeTin0BhkyN+10dWaCP4YyJ/kl4XdODlhsAlM0Qwi0FC7u3/gda3ap8wZqCtEw3g9I8IAv9SECo4GZZoBszq57avumSebNbxXkyLL3lwN5f8Sod6syyyJCYaerdm7KHuTb1E2UBXDQedaedApJR3LK1xJ8mNxQUBHwmrm6rP17Ir5Lcnth5Hq3A9P6f2NrnOW7u5KKqTQY7IiZmPFfw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none
Received: from DM6PR01MB4444.prod.exchangelabs.com (2603:10b6:5:78::15) by SN6PR01MB5104.prod.exchangelabs.com (2603:10b6:805:b8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.16; Fri, 23 Dec 2022 17:22:14 +0000
Received: from DM6PR01MB4444.prod.exchangelabs.com ([fe80::62:d23d:3d8d:88d3]) by DM6PR01MB4444.prod.exchangelabs.com ([fe80::62:d23d:3d8d:88d3%5]) with mapi id 15.20.5924.016; Fri, 23 Dec 2022 17:22:14 +0000
From: Justin Richer <jricher@mit.edu>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: CBOR versus HTTP Message Signature
Thread-Index: AQHZE3FhLQmH685owE2q35UtFr+WSa57fuHTgAAoAACAABaC9Q==
Date: Fri, 23 Dec 2022 17:22:14 +0000
Message-ID: <DM6PR01MB44448F6E36796A6B794940FBBDE99@DM6PR01MB4444.prod.exchangelabs.com>
References: <CAD9ie-uvOK_-JxDjtZrPXGqdHUSYFNdKsaGKp6jNNhZB5bVXuA@mail.gmail.com> <9A670797-BEF3-41A5-A73F-3715F1617EF0@amazon.com> <930cc3b5-7d12-16cb-3538-d31545de8f54@gmail.com> <DM6PR01MB4444A2658342DF85BCFD88B2BDE99@DM6PR01MB4444.prod.exchangelabs.com> <b9f1f1a4-5d56-62b4-95d4-ab803d35ae4c@gmail.com>
In-Reply-To: <b9f1f1a4-5d56-62b4-95d4-ab803d35ae4c@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=mit.edu;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR01MB4444:EE_|SN6PR01MB5104:EE_
x-ms-office365-filtering-correlation-id: bd68df0d-1861-45c1-1887-08dae50a3bc6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hxsArNBnLjAayvcjm0sTc1hvgj6EUb9mNYPU7WxKkLjGgmhaoPsdJ1JH4/xoEaShLVL+J8ZZvlEuo+ncF3vidqYb7T1tuLuFhdCAE0Gp5Decq3man+tm8MuZfHQ9Sua93FCemq6vgimNHi+wfWH4OAWqPSHI2RIoDzgYtS67zKlsNJ7OV8dGnb9dyFpN3jxidhvRlznpyAEB1l3IhcTuSBKG2I8CiE8b9JZq8Csk8MrElgl/mCiFXiQ5NPJJ8hrV0Zkl4v5bNsRruBNZtk1YWcvSEQ9nKWB6ZqY6Jgq/CoM2vAxkDonGeDnIc0q071wduhQrbN4dkNHUqADbIkUJ4tU55bRMFRG5WxR1cyFNQCVaV8soTp/wVj4CzOdvYjFH1KCBjKB6RSZsnrqAShhXCmApXjarrwp0exbf0/ajibpDC3fj9B1PrNl8Y6g0OV/JAHuzCLEPrXSOhnai5D6u4s4OC40q0QUtWxgAynfRCutkkGfClG8JygtlhjwqwmJgIjDEz5KxqPpZkBTzePGyXbBWur9xIGksRwRePMpnILfAbTCyC2c3Lz17/ICUMQ4bbR+b786QdkbolNEZRZY89MwVu+ySnRqiOi9lgehssmnHeXY5jumEjFuYMGkL0YOTw8bkb1oO52ck+DRo67WNDb6XaKdVrz0PaEj36SAofd0TGlGAJ7HsSbsciUKFrat4X5p1sHnWF8qbzjG8qAOtVfdR5gR5CscAWxfyoCiegRs=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR01MB4444.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(39860400002)(376002)(366004)(136003)(396003)(346002)(451199015)(71200400001)(6506007)(38070700005)(166002)(7696005)(75432002)(2906002)(9686003)(478600001)(26005)(83380400001)(33656002)(966005)(38100700002)(122000001)(66574015)(55016003)(86362001)(186003)(76116006)(4001150100001)(5660300002)(8936002)(52536014)(66446008)(66556008)(66476007)(8676002)(64756008)(66946007)(41300700001)(53546011)(91956017)(316002)(786003)(110136005)(15650500001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: moFJPeDCtyQRNhbRkKdH5UH9BKqHnZqw+tWmGXESIVwmOUvcJ9hcs3yP57QNWllgshOjbFq7m5bFfLhjGIcNStrk/7o7nHozrc3AVxVdvmp+O+WITQPf38URpYdGZHUKzDQgW1lafG54CrQcbn1DjEWO4GLBW87Y7G2hffnyUadxbYkg73qmIcZvRv7BmdDkN+l7ATEtA1Dp7AoozeouJWrxkNZIJTQPv6QPkSrpolOcZibN4c7JXmq86W6M6/oirFRgNGZWzDm3mCaK6tL8gEo2kxoOOnv09a5aLAfT2CVqu/uCWOtyiFzH+O2SOzq8+hgg+9LqeMa2zPwmrHN/NxjnRTfOEgrfz5iaiNZzusoKneaQvOhdUYFWncUP6vNLw6fmLT5bwfkH9ERST8aGACp6Jjnukd8X9Ax4grFN+5OD6Qtd84ZkHCKaesxSbCLUnzy3hrapqTOd+dVmrWMOlEANXgqDParkEouKJQnS/VWG1z4XbUkxNOM/6vYQlW2gilJEGdDffjNw5iGcUii5alcM8qaQde2IfsOATpAUPXoJZ4tVBM0vq9WTMDYTrGGNbWE8FyjgBOB3OMoP2vWxuFWrv8cGBSCzmTgMNE4rt9PgvIjORjo1qeb01jct8XWTO526+r9s/+L/fyYUM8LVJIh/WMkfM0svvk12KuJuy5a+6diGyxFAZ8xng/11cbuVoNoMs6dK69CBvE5pipKXITyjcxE16et0g9NsCqn54kWl0YcR8CkXeRy+01I4InDkPgIK5rZpM70xO0DNNNXTcChUpYon2aZJ7HsGG4ZiBNqN1mlKqsSgfD3VD7eJ3sh1vETcEPRbtTLt+SIXpBM9hEaw+6ho9d0DpciPnbmoRNhvQkNACHeKXnB9evrOe6rAzrcLTogYkdJcgUpBby+iFFLpDKCqsWfYR4drcHRBrWBEvEb1dbnU22VLvu/3Y/0I48EXEDL5NFTVJEiwMJis0Sez3OwBzmX/VGVObf+N+sTc0G47NeLdayI24z8yiM0sRfVDNTr8fExg+KDg+z4oS7CGNUSHF6++k0nwhVoFSGrHyxhbuZLg0zsAzrbJjlqUnvWyKAFp6VAdExTIsSV/kB7DOOfMMoq9tbG99Fc9PF824vOpU6YPHZL0vxfF7YUCRzgsY8SzythLjBpeD+EmryTcNay8h44frG2mioAeFltlNQZQKkigacI/LJ0K5YgjMNk2TqcwoRhLgYNZx81R802RJKR49GPc/HVZQNTR7Ghm2BeX0jv1XWphmi7Xbazu/kcgFzAv7FyG+hyj8UTS/fKMYtBx0AgFFvxprLa+O87AZYoEvn7u0X+C8o7l8uSSCohlcsoOShC7oaEk5jc6gnZ+MDG98kgAXHHWpm7KAsXL5lHkYqlGc9QOBWcuBFxBv19a326iy817CZTakT5uBzdEJf81g0XfDiTjvxnIdEhjkk0CbVxmy7lyZkNKdYeUlPOkiBgxVY75+ATnUaMkFCmeaGpbcXfwXUNfdeEHJY4UFMaWNRvyAF2vOHnJYTqBWiQ9yeV7MsX1s0rUKwkh7o5wrbP29inhVdcvb+8eM/c=
Content-Type: multipart/alternative; boundary="_000_DM6PR01MB44448F6E36796A6B794940FBBDE99DM6PR01MB4444prod_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR01MB4444.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bd68df0d-1861-45c1-1887-08dae50a3bc6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2022 17:22:14.0993 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HTeI1bza0Ltn+uo7R2il1La+CMWK0xmcmAzaZ6POC84NRlyy2PYGkA95o6MS2rkc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB5104
X-OriginatorOrg: mit.edu
X-W3C-Hub-DKIM-Status: validation passed: (address=jricher@mit.edu domain=mit.edu), signature is good
X-W3C-Hub-Spam-Status: No, score=-7.4
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1p8lka-00F8Wb-5S 14b101a448ccdbf75355c89a0422730e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: CBOR versus HTTP Message Signature
Archived-At: <https://www.w3.org/mid/DM6PR01MB44448F6E36796A6B794940FBBDE99@DM6PR01MB4444.prod.exchangelabs.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40664
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Thank you For that. One of the biggest problems with a fully self contained signature format like this is that it necessitates copying information from the transport layer into the payload area. For example, you'd need to copy the method and header values and effectively transfer them twice, while also needing to make sure they matched.

About a decade ago, I deployed a system that did exactly that but using jose. This was for a healthcare exchange. We found the process to be awkward at best, and at worst it easily lends itself to lazy developers not checking the consistency of the message components between the HTTP Message itself and the cryptographic payload. This leads to a whole family of problems that the HTTP spec avoids by using a completely detached mechanism. Plus we were limited to JSON messages, and had to replace all our processors to handle only Jose payloads. In fact, it was my experience deploying this system that largely led to my favoring the detached approach in practice. Both have tradeoffs but having done both, I'd pick the detached method every time.

-Justin
________________________________
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Sent: Friday, December 23, 2022 10:54 AM
To: Justin Richer <jricher@mit.edu>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: CBOR versus HTTP Message Signature

Hi Justin,
I fully support the WG item.

What I did found out though, is that for designs standardizing on CBOR as data interchange format, there are alternatives like the one I provided in the sample.

- In the RATS WG, "objectId" has been defined through the combination of 1) parameterized content-type, 2) CBOR tags 3) profile URI.  However, the XML/XSD world (including the ISO 20022 folks), managed just fine with a single URI which also became a part of the object data itself, effectively decoupling objects from their transport.

- To not leave HTTP headers in the dark, I'm suggesting copying the this part from your excellent draft.

- Finally, by building on CBOR deterministic serialization, bstr/B64 "armoring" of data becomes redundant, enabling enveloped signatures at no additional cost or risk.

Although object serialization is probably a no-issue for most designs, it is a pretty useful feature for systems creating attested (and potentially stateless) tokens. This is the origin of this concept.

Anders

On 2022-12-23 14:37, Justin Richer wrote:
> The HTTP Message Signatures draft is not specific to JSON or any other data encoding format, so I'm not sure what you're trying to say here. Are you saying that cbor/cose would be a replacement for a general purpose HTTP signing mechanism? But: You don't need any JSON processing to implement the specification. That was one of the smaller goals of the spec, the larger aspect being that it should live natively in HTTP space and not be tied to API or data use cases.
>
> Yes, there are lots of other ways to sign things, and they've got different properties that make sense in different environments. I suppose if you're doing something entirely in cbor already, something else might make sense, but that isn't the goal here.
>
> - Justin
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Anders Rundgren <anders.rundgren.net@gmail.com>
> *Sent:* Monday, December 19, 2022 1:12 AM
> *To:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* CBOR versus HTTP Message Signature
>
> Dear List,
> I hope you don't mind me elaborating a bit on an alternative to the current IETF WG item.
> A decode ago I converted from XML/XSD to JSON.
> Now I have converted to CBOR for many reasons including support for a wider set of data items, and last but not least deterministic serialization.
>
> If you put all these things together you can obtain similar results as with HTTP Signatures, but in a package that may better match the rest of a typical system.
>
> https://github.com/cyberphone/cbor-everywhere#signed-http-requests <https://github.com/cyberphone/cbor-everywhere#signed-http-requests>
>
>
> There are probably not many who are prepared scrapping their huge investments in JSON based systems.  JSON also remains the [currently] only viable alternative for browser based applications.
>
> Cheers,
> Anders
>