From nobody Tue Apr 27 18:39:19 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CA13A0D12; Tue, 27 Apr 2021 18:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 HIkFvXT5-N-h; Tue, 27 Apr 2021 18:39:13 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 A7FCF3A0D06; Tue, 27 Apr 2021 18:39:12 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id b23so14034673lfv.8; Tue, 27 Apr 2021 18:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0LlPwsYif1ZdRk37XhKly0/3Vk0+Il3lcnWntqEHkFY=; b=LkhdzZPvGAng3qQAX0ZwvLZW9l1gQK36exdwWmKJlZFZs5ByClGuHgeAwodBYfA13Y OKIbBveJXFZ1dNV+51HyeB65Vu4X0DYGsXGLWi0nLBvzstZ1c2t7HrhPngWqpvFTqNsX TR1JQ7ofRnte1Gw5V3BUM5rugvA8CxQ7tgbFhMmii/WIW6kZGDODxDmSWvnfP0ZDCXqJ G22mHJvfsjF0S/PnFoqsQDI/GEJR+Qi+nOmgehT+mkiYhZszLPQyJDXewXB+fLx4p+SS C2DuNw+0RnwzHtcyI3NPvDOQZC1gtxsSUxtK8vkG4S0KFUYcp7kDVCWBZf4Ut06jNoTe 0NDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0LlPwsYif1ZdRk37XhKly0/3Vk0+Il3lcnWntqEHkFY=; b=gckhtn99oOwOrk2jB49xtRPoGp1DqmhrZT+pcIHKc5QX/P44yDhAtUsBOI+y5Iylru DpKmIA/alxc2JCvAkY+gQDIZWRNM4e2J3LGBy+YMkv5i+6DGg9sYK9WPaP9Db9wXvDfk mO0VEGoFmZu3DqSi2/VhEDUGBrRmxvXzUA95JldtK8mSP7DFSxY/wPG0skBFEvUAo0Ze KlG7qRgZrHyqU/F3ZLLjbGS2kzrSbO4WfcFMvSH01/NudYSmqZI7sn4saiwGj5gWMzM4 5EXoNwDV6X3vxEF3D+VqIQAr64LmRcgw5uYL8eUBEFEpy2bZ5UWKV+ncQf9h8mmTcQZ7 wDEg== X-Gm-Message-State: AOAM532zu8xI0PUtth2DYBxfOcIWW6Y7z7HVwPzRsIhWWvyBb+R7fkLo D9zlb2RumCItviw19KhxcaN7Kj25xfj/d9MKmjM= X-Google-Smtp-Source: ABdhPJw8f5eT1yM5MK/Ggfat3cQ3wyTcYolJiPv06wYMOyOecG7fHYeQkelj4Cu+KrqZh468QqAqHi1ZRKNT/CrXsYg= X-Received: by 2002:a05:6512:92e:: with SMTP id f14mr18721818lft.347.1619573949962; Tue, 27 Apr 2021 18:39:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 27 Apr 2021 18:38:33 -0700 Message-ID: To: Bret Jordan Cc: DISPATCH , IETF SecDispatch , art@ietf.org, rfc-ise@rfc-editor.org Content-Type: multipart/alternative; boundary="000000000000f9a0a505c0fe71c7" Archived-At: Subject: Re: [dispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 01:39:18 -0000 --000000000000f9a0a505c0fe71c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am supportive of this work, and would also be willing to work towards a PS. I am seeing rapid growth in the demand to embed JWS in JWS. Given my experience with XML-DSig (see below) making it more XML-DSig like does not sound like a good thing. For any interested in some JWT history, when we were brewing up what became OAuth 2.0, we did not want to tie a token format to the implementation as many deployments had their own proprietary token formats -- but we knew new deployments would benefit from standardizing a token. Our requirements were: - URL safe (access tokens at the time were often passed as a query parameter -- I know, not the best idea, but working with what people wanted= ) - HTTP header safe - richer than name / value pairs Options we considered: ASN.1 - the 60s are calling and want their data back XML-DSig - not URL safe, large size, and I personally had many scars canonicalizing XML. (An earlier company of mine had a contract to build XML-DSig libraries for a few languages) JSON was becoming very cool at that time, and with base 64 URL safe encoding the string, it was URL safe, and treating the JSON text as binary dealt with the canonicalization concerns -- and JSON canonicalization did not exist. Using a dot as the separator between header, payload, and signature made it easy to parse. The dot was URL safe, but not in the base 64 set. And Simple Web Tokens were born -- to be renamed JSON Web Tokens. /Dick =E1=90=A7 On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan wrote: > Dear Dispatch, > > Anders Rundgren, Samuel, Erdtman, and I have been working on an ID for > your consideration. This document describes how to use JWS and JCS to > create plain-text JSON signatures. The abstract reads as follows: > > This document describes a method for extending the scope of the JSON Web > Signature (JWS) standard, called JWS/CT. By combining the detached mode = of > JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON > objects to remain in the JSON format after being signed (aka "Clear Text" > signing). In addition to supporting a consistent data format, this > arrangement also simplifies documentation, debugging, and logging. The > ability to embed signed JSON objects in other JSON objects, makes the use > of counter-signatures straightforward. > > The data tracker page for this: > https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ > > As you know there are large ecosystems that needs digital signatures for > plain text JSON data, meaning where the JSON data is not base64 encoded. > This ID provides a solution using existing IETF RFCs to make this work. > Further, this work looks to be adopted by many groups and organizations > from financial services, threat intelligence, and incident response. > > We are not sure what direction would be best for this work in the IETF, > should we send to the ISE for publication or do you want to create a > working group. Ultimately there is a lot of work that could be done in th= is > space to meet the needs of the market. We would be happy with releasing > these IDs for ISE publication, or for creating a working group to move th= em > forward. It is just important to note that the market is in desperate nee= d > of these solutions. If you want to take it for a spin, there is a JWS/CT > playground at: https://mobilepki.org/jws-ct > > Thanks > Bret > > -- > > Sent from my TI-99/4A > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --000000000000f9a0a505c0fe71c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am supportive of this work, and would also be willing to= work towards a PS. I am seeing rapid growth in the demand to embed JWS in = JWS.

Given my experience with XML-DSig (see below) makin= g it more XML-DSig like does not sound like a good thing.
=C2=A0
For any interested=C2=A0in some JWT history, when we were brewing up = what became OAuth 2.0, we did not want to tie a token format to the impleme= ntation as many deployments had their own proprietary token formats -- but = we knew new deployments would benefit=C2=A0from standardizing a token.

Our requirements were:
- URL safe (access to= kens at the time were often passed as a query parameter=C2=A0-- I know, not= the best idea, but working=C2=A0with what people wanted)
- HTTP = header safe
- richer than name / value pairs

=
Options we considered:
ASN.1 - the 60s are calling and want = their data back
XML-DSig - not URL safe, large size, and I person= ally had many scars canonicalizing XML. (An earlier company of mine had a c= ontract to build XML-DSig libraries for a few languages)
=C2=A0
JSON was becoming very cool at that time, and with base 64 URL saf= e encoding the string, it was URL safe, and treating the JSON text as binar= y dealt with the canonicalization concerns -- and JSON canonicalization did= not exist.

Using a dot as the separator=C2=A0betw= een header, payload, and signature made it easy to parse. The dot was URL s= afe, but not in the base 64 set.

And Simple Web To= kens were born -- to be renamed JSON Web Tokens.

/= Dick




=E1=90=A7

On Tue, Apr 27, 2021 at 8:28 AM Bre= t Jordan <jor= dan.ietf@gmail.com> wrote:
Dear Dispatch,

Anders Rundgren, S= amuel, Erdtman, and I have been working on an ID for your consideration. Th= is document describes how to use JWS and JCS to create plain-text JSON sign= atures. The abstract reads as follows:

This document describes a met= hod for extending the scope of the JSON Web Signature (JWS) standard, calle= d JWS/CT.=C2=A0 By combining the detached mode of JWS with the JSON Canonic= alization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON f= ormat after being signed (aka "Clear Text" signing).=C2=A0 In add= ition to supporting a consistent data format, this arrangement also simplif= ies documentation, debugging, and logging.=C2=A0 The ability to embed signe= d JSON objects in other JSON objects, makes the use of counter-signatures s= traightforward.

The data tracker page for this: https://dat= atracker.ietf.org/doc/draft-jordan-jws-ct/

As you know there are= large ecosystems that needs digital signatures for plain text JSON data, m= eaning where the JSON data is not base64 encoded. This ID provides a soluti= on using existing IETF RFCs to make this work. Further, this work looks to = be adopted by many groups and organizations from financial services, threat= intelligence, and incident response.

We are not sure what directio= n would be best for this work in the IETF, should we send to the ISE for pu= blication or do you want to create a working group. Ultimately there is a l= ot of work that could be done in this space to meet the needs of the market= . We would be happy with releasing these IDs for ISE publication, or for cr= eating a working group to move them forward. It is just important to note t= hat the market is in desperate need of these solutions. If you want to take= it for a spin, there is a JWS/CT playground at: https://mobilepki.org/jws-ct

<= /div>
Thanks
Bret

--

Sent from my TI-99/4A
PGP Fingerprint:= =C2=A063B4 FC53 680A 6B7D 14= 47 =C2=A0F2C0 74F8 ACAE=C2=A07415 0050
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--000000000000f9a0a505c0fe71c7--