Re: [Secdispatch] [dispatch] [art] Plain text JSON digital signatures

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 28 April 2021 09:00 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FFA3A2102; Wed, 28 Apr 2021 02:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 zG2fS327xRHc; Wed, 28 Apr 2021 02:00:15 -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 C31273A2100; Wed, 28 Apr 2021 02:00:14 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id 26-20020a05600c22dab029013efd7879b8so6819542wmg.0; Wed, 28 Apr 2021 02:00:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AnzUbNxb5tujKdkXBudu1u/IXBIzwS0gNOhT+HnKzPQ=; b=ZdC6piseFOw/QESRPtr4AEnxiZ+WxXVoeExtM08B9Ue+jmswHV7t+XL7KpCswa8bIn e1Qwj9jhC7+pOjQ2CEmssWaIYWBvrRt1LpyZKRt3jetPxImsjyuRfsUVwyOLsRmeJ4Q7 LXYKyHMJghUUctZxhq8lW1WbhxqI6ZRn9uCPjzAuGzzADQtENvky7qAvcpuT4iD32KP4 +sZaj6O9n2gHdH7+X27lURdQe5KUn29t68XW4sRe+BJcjWEt2Ia3dpQYL20PKif+GiH0 Et26GtYreBq9vvA9Lz9RUNN67gMuGxvvrkV1xeIg6QHDEGWENmfEGGiz4/9JImvgID2m 57rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AnzUbNxb5tujKdkXBudu1u/IXBIzwS0gNOhT+HnKzPQ=; b=ANe+LsVw6ZHFw6gg03kH+4W2DgkWW0wknmMhZdiVGCzM0f2yAjw01pT/l3BNT5V3wf BOZ8pqG3LmnQ0mH8emSqeOrP4w8aGyWA0TyVFY5EqVFuS3WI9/3thdmNbdHTd81MXY1C n//CMulQh49GjYtzTBHYjoMXgEPTbcJ6lJxt4NyyNECYk8E8/GzbG6bWcXRHS2yArQls UwyoUIlRfEBZilwysKYDVa429Ga3C3PmZ6FbKd2AgUvl/YoGMfI4lQwn5JGHCUTJygMV hTh9jaMzxtyzqxvUqWz0sQYYdZIjj8SusO/CEYEu+Z/v8c0fSgRcfrGE8m2k03rZnIkW DAQQ==
X-Gm-Message-State: AOAM531ZtMWI8+ciIm8s4cDVFl4CvF0YTyfgR1ij7p4ewsDV1gkYnmYK wWWrSIEObRPfE6aeWbM+xkg=
X-Google-Smtp-Source: ABdhPJxJTKzpX1hhkYmixGh4ZMiDrlS6BVDv7nFDlEDWojXG1jqW9vSZ8Zn/K4DTAW8SPdzNZPxHbA==
X-Received: by 2002:a7b:c05a:: with SMTP id u26mr3140166wmc.172.1619600408064; Wed, 28 Apr 2021 02:00:08 -0700 (PDT)
Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d5sm7256303wrv.43.2021.04.28.02.00.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 02:00:07 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: art@ietf.org, IETF SecDispatch <Secdispatch@ietf.org>, DISPATCH <dispatch@ietf.org>, rfc-ise@rfc-editor.org
References: <CAD9ie-v7uJOpjj+nbZCfQe+4JEQt-6=b6cm57iFPAn_enGeRCQ@mail.gmail.com> <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com>
Message-ID: <220475a6-1e04-107e-6327-366d48d8b420@gmail.com>
Date: Wed, 28 Apr 2021 11:00:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/DTK6cyUKMigce665QAIPn2Jpvls>
Subject: Re: [Secdispatch] [dispatch] [art] Plain text JSON digital signatures
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2021 09:00:20 -0000

On 2021-04-28 8:52, Stefan Santesson wrote:
> How is this different/better than implementing RFC 7797 and apply the header b64=false in order to carry plaintext JSON in the payload?

Good question!

Apart from the fact that the data becomes embedded in the JWS signature container (=changing the structure), you cannot really put JSON there:
https://tools.ietf.org/html/rfc7797#section-5.2

My guess that the only real-world use of this option is to save an internal-only (but technically redundant) Base64Url-operation for truly detached data, be it it JSON, PNG, etc.

JWS/CT was designed for signing JSON Objects ({}), and let them remain as such.

Thanx,
Anders

> 
> /Stefan
> 
> 
> On 2021-04-28 04:29, Bret Jordan wrote:
>> Luckily this time we have RFC8785 that solves the canonicalization problem for JSON.
>>
>> Bret
>>
>> Sent from my Commodore 64
>>
>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>>
>>> On Apr 27, 2021, at 7:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>
>>> 
>>> 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
>>>
>>>
>>>
>>>
>>> ᐧ
>>>
>>> On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <jordan.ietf@gmail.com> 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 this 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 them forward. It is just important to note that 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
>>>
>>>     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
>>>
>>
>> _______________________________________________
>> Secdispatch mailing list
>> Secdispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdispatch
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>