Re: CBOR versus HTTP Message Signature
Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 24 December 2022 07:11 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 DF169C14F722 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Dec 2022 23:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.749
X-Spam-Level:
X-Spam-Status: No, score=-7.749 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_DNSWL_HI=-5, 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
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 N2R5NJJ2NX5v for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 23 Dec 2022 23:11:29 -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 2A2A0C14F6E5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 23 Dec 2022 23:11:28 -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 1p8ye6-0047oL-0c for ietf-http-wg-dist@listhub.w3.org; Sat, 24 Dec 2022 07:08:38 +0000
Resent-Date: Sat, 24 Dec 2022 07:08:38 +0000
Resent-Message-Id: <E1p8ye6-0047oL-0c@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 <anders.rundgren.net@gmail.com>) id 1p8ye2-0047nN-QP for ietf-http-wg@listhub.w3.org; Sat, 24 Dec 2022 07:08:34 +0000
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by titan.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 1p8ye0-00FLOo-Pd for ietf-http-wg@w3.org; Sat, 24 Dec 2022 07:08:34 +0000
Received: by mail-wm1-x334.google.com with SMTP id ay40so4886946wmb.2 for <ietf-http-wg@w3.org>; Fri, 23 Dec 2022 23:08:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:from:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=W5ur6ipbudfLbAhSBuIdACigjGxM1D8VKvzWXd9b4XA=; b=GBNxoQZxbBqZ90U6g6UgMzaTpEL7pqWWHOOnPsLmA6NDAUS/WS25EX9x6oCDblzrCa IOuZr6RwgRhTTgPYUhM9a6Q5TzAZTvskSuAUzI6/oIWrbu6WTjibkt7MzZ05sIzL5i2h obRbz+Tg6bL5GfIAx9t0vYAO8kWk3m5YQhy21z2iGZclD7KlY/eTr7+zGQh3D9e0RiIs b9yTyyG7U3CHKzr8hVq5AYwqGjfSz1oXEXmZvbPgIBUW9iY5NF3XVzsME1VjjNurNCm5 VJioK8eS6w5XsAmB/uRLrR/XouyT4hZ6R4/n3mc75erWdpivtr2ubLL7IhcfDnv2U/AJ cJuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W5ur6ipbudfLbAhSBuIdACigjGxM1D8VKvzWXd9b4XA=; b=LOPwnaJIamGchd6Bgk7Pj9AUfUlUb88W28SAnajiUgMVKaGgBFBkKeDukLQ0lfZZ/k ENpHh0sj5afoP54SQaktridhpH3IWD94wqD0qeHSErbalq3c6z1BCnruIVwWnsuR4s+v CrCkQLlJXT0WrEBaoDmk18WjdUtV17V1JjrcMmRmdx3q9KNFHVXISMDXTzjPJ1IVtd/y dTPS00jvBVEvt4Aoz8Ilb3AendK0czAeMe/v0GTD7v8Gs+C+o2MYnULxv5Fg2eWZQ3rW V4KKp60j45KOQqPgk47M2RBqIKfOYyxHF7LJ8roVHbJo0lUWV6Ndoq9a/i+0ajmc5i7z 1jMg==
X-Gm-Message-State: AFqh2kqW66n4WUhZXjpQtJuMXPDcDvQbbUEgDtwv+XhQW46+lWezkFe5 ML5jhDpVsxRnKMIVq1CJYdI=
X-Google-Smtp-Source: AMrXdXuffYoTgKbHN0CEWEKvSUlnp7QElVgqNCMGtj9Sa+5OLKmufDkBqFIcXEYp2/AU2xWcqcro6g==
X-Received: by 2002:a05:600c:540b:b0:3d9:6b72:39c8 with SMTP id he11-20020a05600c540b00b003d96b7239c8mr5084488wmb.31.1671865701362; Fri, 23 Dec 2022 23:08:21 -0800 (PST)
Received: from ?IPV6:2a01:e34:ec4e:5670:dcb7:d7f0:caa5:9f49? ([2a01:e34:ec4e:5670:dcb7:d7f0:caa5:9f49]) by smtp.googlemail.com with ESMTPSA id z1-20020adfdf81000000b00268aae5fb5bsm4851840wrl.3.2022.12.23.23.08.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Dec 2022 23:08:20 -0800 (PST)
Message-ID: <9001a7da-6a11-4de1-0038-c8163b73dca4@gmail.com>
Date: Sat, 24 Dec 2022 08:08:19 +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
From: Anders Rundgren <anders.rundgren.net@gmail.com>
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> <b9f1f1a4-5d56-62b4-95d4-ab803d35ae4c@gmail.com> <DM6PR01MB44448F6E36796A6B794940FBBDE99@DM6PR01MB4444.prod.exchangelabs.com>
Content-Language: en-US
In-Reply-To: <DM6PR01MB44448F6E36796A6B794940FBBDE99@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::334; envelope-from=anders.rundgren.net@gmail.com; helo=mail-wm1-x334.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.147, 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: titan.w3.org 1p8ye0-00FLOo-Pd e59165c4c8d11571cb933c153aff5ddc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: CBOR versus HTTP Message Signature
Archived-At: <https://www.w3.org/mid/9001a7da-6a11-4de1-0038-c8163b73dca4@gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40665
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>
On 2022-12-23 18:22, Justin Richer wrote: I guess we can agree on that for every solution there is almost always another solution? No solution have all the benefits. CBOR has (IMO) yet to reach its full potential. > 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. Well, copying URL and method may also be a feature. Headers may in some applications also remain unsigned. FWIW, the designs I'm working with only use POST; URI is an integral part of the message. JSON based predecessor: https://cyberphone.github.io/doc/saturn/bank2bank-payment.html#4 RPC is not dead, it is just RESTing :) It might be interesting knowing that the referenced system builds on an extended VISA/MasterCard EMV concept. Since EMV challenges OAuth2, it has not been possible having a "conversation" about why and what. > 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. The idea is having a signature method (and container) that for all but HTTP header data would be identical to the method used for stand-alone objects. Anders > > -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> <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