Re: [jose] Signed HTTP Requests @ IETF-104

Bret Jordan <jordan.ietf@gmail.com> Tue, 26 March 2019 07:12 UTC

Return-Path: <jordan.ietf@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C364812028D for <jose@ietfa.amsl.com>; Tue, 26 Mar 2019 00:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMH2J6qWH0YM for <jose@ietfa.amsl.com>; Tue, 26 Mar 2019 00:12:24 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E0412028C for <jose@ietf.org>; Tue, 26 Mar 2019 00:12:23 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id q16so11373416wmj.3 for <jose@ietf.org>; Tue, 26 Mar 2019 00:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9f9pE63AgdAxpdKVI633kIa5BtAL39eBPnlnbiI3GDw=; b=QGpvAXroog+tLCkXqsE5CaX3Jfmttg1e2XeYMMa3xj13FFsvU26jHYKfhdAgOzGFRb ALE9LNTxpxtKbcmBSdLo8Qp35wR1itHIv6Fz2/6XStXHFI3Qw/Kd5LSx+2mOTMVadG2q Awah+rxbWknFEznIWu42W3/2gm/1U2b1cGb93f3XavA8EYayuRPZh9w7iBhqJSg+Am/g e6lJoQ63K+tS5+TBLCqwQ2Og9U91panSV3WL2Un/pZAFBIWAGWkwZyYV3xCtcEcQ5fx1 I1ScD7QbzPok4Dz0cyyYqJUGIJ+x8/OCVKsIV0F0276CkbHLN5KNCNTecP68+1lclAc2 hrkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9f9pE63AgdAxpdKVI633kIa5BtAL39eBPnlnbiI3GDw=; b=GanS/g3ln3AwByQnuIgQgDCFVqi43IhmfdOLqReKPZFQv7OWuvC8EMjP95l+tEj9Uo aqhMXBJSMq5NUHzn+s4y7R5xtNOvzjxHOjbiMBm6rh5Ql5d8v/VqrczUM5qWTbZ5iXxU 3u1DkrmuXKeDBH6c2eNHsM+YGXE7WEi6lJYYFcG3zhnJJ6E7KaMi8GPGGa/CQ45S9xIO mKxQccxLaWshmxUYZbyuWovNejZfYGIhXCRvS/XzY1i/US8i+fOc6XbYHjJ8llhpkcMI y1fdyU7eOMBzHr3RixDlOVNLQMTHjUOEqt5ePLgZeAY8I4VvFPFBhFMHxI9D2AJ9hMQB AZPg==
X-Gm-Message-State: APjAAAW5uVzri4nuE3PNUj36gKVPfNtzO+5yCDhCvdAl+9nN9ySwxYKU KkFw/LrdfAYoUKxYQLD9YNQ=
X-Google-Smtp-Source: APXvYqziDyM0/VWMa36HJRf4o0aDUtEA8taQHU+pOCiXouFih+uUoSSlqKgk25IKBnOwN/FE60Lnyw==
X-Received: by 2002:a1c:7dd7:: with SMTP id y206mr7941432wmc.81.1553584342083; Tue, 26 Mar 2019 00:12:22 -0700 (PDT)
Received: from [172.20.1.61] ([89.24.97.133]) by smtp.gmail.com with ESMTPSA id j1sm21537038wme.4.2019.03.26.00.12.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 00:12:20 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-A339A93E-4AAF-4866-9810-28C1B4DFBF8B
Mime-Version: 1.0 (1.0)
From: Bret Jordan <jordan.ietf@gmail.com>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <86b31b82-9b3f-e441-efc6-9d260a522832@gmail.com>
Date: Tue, 26 Mar 2019 08:12:20 +0100
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, Anthony Nadalin <tonynad@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <B7DB8A46-BFCA-42C3-86E3-6E3292F630CE@gmail.com>
References: <3afd27b3-c095-3188-89d3-58d8be177c5e@gmail.com> <DM5PR00MB0391CF9D87A9CE6F9CC36FF0A64A0@DM5PR00MB0391.namprd00.prod.outlook.com> <194bf99a-d5aa-d342-d110-3d66daf50d6e@gmail.com> <05237AAD-FB1F-4A06-A2BF-D4020B1F2799@gmail.com> <D6152153-D4B4-4EA5-B02C-CD01870EE4B2@lodderstedt.net> <86b31b82-9b3f-e441-efc6-9d260a522832@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/hCQ73vQepbz9-RZ1fbNmaqQnf5Y>
Subject: Re: [jose] Signed HTTP Requests @ IETF-104
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 07:12:29 -0000

I would love to have a side meeting here in Prague.  

I can not stress enough how important this JCS work is.  Anders talks about the banking industry using this.  But In addition to the banking sector, the entire international cyber threat intelligence community will be using JCS, which includes hundreds of major and small vendors, nearly every industry vertical, and many governments around the globe.  

Like so many things, we should quit trying to censor technology because a few people do not like it, or because we wish the industry would go in a different path.  Anders has done amazing and brilliant work here.  Is it going to cover ever corner case? Probably not.  But honestly it does not need to.  It just needs to solve the problems people need, and it does. 

How can we get this group to reconsider it? 


Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Mar 26, 2019, at 7:16 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
>> On 2019-03-25 15:31, Torsten Lodderstedt wrote:
>> Will there be a side meeting on Wednesday?
> 
> I can try to arrange that.
> 
> I'm still curious to hear what for example FAPI suggest for the future.  https://openid.net/specs/openid-financial-api-part-2.html#request ?
> Convincing all open banking system developers out there to dress their precious business messages in base64 as an alternative to their current clear text solutions including the-not-as-bad-as-claimed https://tools.ietf.org/html/draft-cavage-http-signatures-10 may turn out bad.
> 
> JSON canonicalization as described in the current 05 draft is based on a concluded (and technically pretty successful) research effort verified by multiple implementations including one made externally [1].  There is a single fully documented issue [2] which do requires some considerations by clients to work.
> 
> Number serialization have been addressed by true specialists in this field (=not me).  Recently I verified my original algorithm (copied from V8) with 5 billion random values against a new algorithm developed by Google which Microsoft intends to use in a coming updates to their C# tool chain.
> 
> No such information was available during the operational time of the JOSE WG which is a rather important thing to keep in mind.
> 
> A bunch of people at the IETF meeting privately propose that new developments should drop JSON/JWS and rather go for CBOR/COSE.  That's actually quite logical since with Base64-encoded messages, you anyway need a decoder to make messages human readable. Personally I'm doing the opposite namely applying canonicalization to the JWS itself [3]
> 
> Anders
> 
> 1] https://github.com/dryruby/json-canonicalization
> 
> 2] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05#appendix-E
> 
> 3] User payment authorization in "Saturn".  Similar to XML DSig but at 10% of the complexity:
> {
>  "requestHash": {
>    "alg": "S256",
>    "val": "cA-QNdJHcynjuM44ty-zXgXwx100AZVRFLmYx1So0Xc"
>  },
>  "domainName": "demomerchant.com",
>  "paymentMethod": "https://bankdirect.net",
>  "accountId": "8645-7800239403",
>  "timeStamp": "2019-03-23T10:33:02+01:00",
>  "signature": {
>    "alg": "ES256",
>    "jwk": {
>      "kty": "EC",
>      "crv": "P-256",
>      "x": "rQ4WXMB6_wQKHSiY_mbJ4QkGpfWLssF7hvIiiFpDEx8",
>      "y": "Fh2rl0LGTtvaomOuhuRNo9Drz9o0--WXV2ITvdVQFRY"
>    },
>    "val": "j2LL9pr2RyrPxvFlj8IzMhno5vvgGIgf2xi23dA5u_XwjYlIvT9qwIVKaCKYwjb26J5mMUL5zV02lqQGjZRClw"
>  }
> }
> 
> 
>>> Am 13.03.2019 um 06:36 schrieb Bret Jordan <jordan.ietf@gmail.com <mailto:jordan.ietf@gmail.com>>:
>>> We should for sure setup a side meeting on Wednesday to talk about JCS.  That would be good.  We could also talk a bit after the HotRFC session.
>>> 
>>> 
>>> Thanks,
>>> Bret
>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
>>> 
>>>> On Mar 12, 2019, at 11:03 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>>>> 
>>>> On 2019-03-13 04:46, Anthony Nadalin wrote:
>>>>> I'm not sure why you say that FAPI is rolling it's own as we are not, please explain
>>>> 
>>>> I was referring to this part of FAPI/OpenID:
>>>> https://openid.net/specs/openid-financial-api-part-2.html#introduction-3
>>>> 
>>>> Is that a proposed standard?  It claims to be RESTFul but does not deal with HTTP Method and URI which are fundamental parts of REST.
>>>> 
>>>> In addition, one of the major interested parties behind FAPI, Open Banking in the UK, have selected another method (https://tools.ietf.org/html/draft-rundgren-signed-http-requests-00#appendix-B.3), while other players in this field including French banks and the Berlin group are betting on: https://tools.ietf.org/html/draft-cavage-http-signatures-10
>>>> 
>>>> This is the motivation behind this work.  If you are in Prague, maybe we can talk about this?
>>>> 
>>>> regards,
>>>> Anders
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: jose <jose-bounces@ietf.org <mailto:jose-bounces@ietf.org>> On Behalf Of Anders Rundgren
>>>>> Sent: Monday, March 11, 2019 8:57 AM
>>>>> To: jose@ietf.org <mailto:jose@ietf.org>
>>>>> Subject: [jose] Signed HTTP Requests @ IETF-104
>>>>> I will be there Saturday evening - Thursday 13.00 in case you are interested in this topic.
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-rundgren-signed-http-requests-00&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=gXhXwQOm0vwPvXbQUQj%2FwD3%2FrsDU%2BB95SF6CjfR80CA%3D&amp;reserved=0
>>>>> 4 minute "lightning" talk: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcyberphone.github.io%2Fietf-signed-http-requests%2Fhotrfc-shreq.pdf&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=Al4bQN9BkM8ESKwqIZD6q1ZeQhYc5PrlXDR7vuRy6JQ%3D&amp;reserved=0
>>>>> On-line "laboratory":
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmobilepki.org%2Fshreq%2Fhome&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=bLjKK%2FcGsB54%2B%2FVbbQQDrrgxdCooQp0%2BfJDBBsRIg8M%3D&amp;reserved=0
>>>>> thanx,
>>>>> Anders
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org <mailto:jose@ietf.org>
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjose&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=Ah7rSZOWkkeTs%2Byi76vkqK1O5iN%2FckkCRoGvtsUDWYc%3D&amp;reserved=0
>>>> 
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org <mailto:jose@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org <mailto:jose@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/jose
>