Re: CBOR versus HTTP Message Signature
Anders Rundgren <anders.rundgren.net@gmail.com> Fri, 23 December 2022 15:55 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 F3029C1516FB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Dec 2022 07:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.752
X-Spam-Level:
X-Spam-Status: No, score=-2.752 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, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, 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=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 940N_z3udjrE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Dec 2022 07:55:16 -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 CD55FC14F607 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 23 Dec 2022 07:55:16 -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 1p8kNz-002HjY-Jm for ietf-http-wg-dist@listhub.w3.org; Fri, 23 Dec 2022 15:55:03 +0000
Resent-Date: Fri, 23 Dec 2022 15:55:03 +0000
Resent-Message-Id: <E1p8kNz-002HjY-Jm@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <anders.rundgren.net@gmail.com>) id 1p8kNy-002Hia-7x for ietf-http-wg@listhub.w3.org; Fri, 23 Dec 2022 15:55:02 +0000
Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <anders.rundgren.net@gmail.com>) id 1p8kNw-00HArB-Ql for ietf-http-wg@w3.org; Fri, 23 Dec 2022 15:55:01 +0000
Received: by mail-wr1-x436.google.com with SMTP id o5so4957649wrm.1 for <ietf-http-wg@w3.org>; Fri, 23 Dec 2022 07:55:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/8a07z8+SgEuqG9e4qW8nr9vqE5t9pnS0S7m9QnUP54=; b=XNol24xXYEKH/U/Yp3sTHPBOI0ecpT5qpCZXNfafwKssfHTEKgDkPjT8uK5a8J4R3F vnzpaJvudjaReI1c4ov8Z9XYpIIeOaqnEaacBG7wdaJN1Sjd8tJx5pMbrvWA9DjJmsJE QQXfVgd3mbsDLpbdKRpgqYr93iWAWX/6mCMLDOXVg5JfITJYf4bbqOUWsIE9rniOqFxE qKG41841nyErdItNvkLpJjhzlbykQz8TgUf4Yuv1kSYJPkALdgtIdhbG87G5Yodd2Huq PW6eTaxL64rym7FjcOHwLAbqk/Uh5V58taQrxrv1+AbnpxyBDzSwVGMJgMFrrcG3qFv4 ungg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references: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=/8a07z8+SgEuqG9e4qW8nr9vqE5t9pnS0S7m9QnUP54=; b=zb1lCdIsUQcwQY+ZlMS7tGF0y18eaGZYDO5Nug43NS24ALxtb5r4dtV6e5Wv3oOwht Uxssgaasb34cmXvKL7OoYMuBe4bJOKcsLy1LDZcx1szzL7945b8nEyqRQQ3mMQ5ooyDP /v/EX0+KTR2DftvBx89e2YKflxPN/YL9IhNnDHyM/sZVvlNxD/FMvB9S3h2AaLQx6eOe audlY1Cb8MpdUpn+8aXW7Mb4uzRcHimjlcuMgawMew/7YwI1G1Mlyq5UccbTZh4Nh4JK zmZgZJlgG4WTw5tSIzskBCni8AWLoY2eo/FoI3OnfESN1L+1MPOOlVGMiFxIzSWP2EyA O95w==
X-Gm-Message-State: AFqh2kq9Wjzv990KAU5nteJGiBZK4Ber4c2cE7OFINSdCAP1vAaw7HeJ LLZYnOTADAjvBEzomwGF5fRdnXMjXoo=
X-Google-Smtp-Source: AMrXdXvPThDpM8d4CBzTxOjHhlVFiJGfoNX3HPStabx+5N/AJe72VckdoxCOkXh5fku2ilDOYr9zKA==
X-Received: by 2002:a5d:668f:0:b0:242:91e:6a78 with SMTP id l15-20020a5d668f000000b00242091e6a78mr5878869wru.34.1671810889677; Fri, 23 Dec 2022 07:54:49 -0800 (PST)
Received: from ?IPV6:2a01:e34:ec4e:5670:4823:cbd5:2d0c:95a? ([2a01:e34:ec4e:5670:4823:cbd5:2d0c:95a]) by smtp.googlemail.com with ESMTPSA id b14-20020a05600010ce00b0023c8026841csm3442754wrx.23.2022.12.23.07.54.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Dec 2022 07:54:48 -0800 (PST)
Message-ID: <b9f1f1a4-5d56-62b4-95d4-ab803d35ae4c@gmail.com>
Date: Fri, 23 Dec 2022 16:54:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
To: Justin Richer <jricher@mit.edu>, HTTP Working Group <ietf-http-wg@w3.org>
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>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
In-Reply-To: <DM6PR01MB4444A2658342DF85BCFD88B2BDE99@DM6PR01MB4444.prod.exchangelabs.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=anders.rundgren.net@gmail.com; helo=mail-wr1-x436.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=anders.rundgren.net@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-7.2
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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1p8kNw-00HArB-Ql 8507220b0015312726f13a8665cd8b3a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: CBOR versus HTTP Message Signature
Archived-At: <https://www.w3.org/mid/b9f1f1a4-5d56-62b4-95d4-ab803d35ae4c@gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40663
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>
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 >
- feedback on draft-ietf-httpbis-message-signatures… Dick Hardt
- Re: feedback on draft-ietf-httpbis-message-signat… Anders Rundgren
- Re: feedback on draft-ietf-httpbis-message-signat… Julian Reschke
- Re: feedback on draft-ietf-httpbis-message-signat… Anders Rundgren
- Re: feedback on draft-ietf-httpbis-message-signat… Julian Reschke
- Re: feedback on draft-ietf-httpbis-message-signat… Anders Rundgren
- Re: feedback on draft-ietf-httpbis-message-signat… Backman, Annabelle
- Re: feedback on draft-ietf-httpbis-message-signat… Dick Hardt
- extension for feedback on draft-ietf-httpbis-mess… Henry Story
- CBOR versus HTTP Message Signature Anders Rundgren
- Re: CBOR versus HTTP Message Signature Justin Richer
- Re: CBOR versus HTTP Message Signature Anders Rundgren
- Re: CBOR versus HTTP Message Signature Justin Richer
- Re: CBOR versus HTTP Message Signature Anders Rundgren