[jose] Hashing JSON Objects

Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 18 May 2019 09:09 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A61201B5 for <jose@ietfa.amsl.com>; Sat, 18 May 2019 02:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q2Z5BEfgjJto for <jose@ietfa.amsl.com>; Sat, 18 May 2019 02:09:25 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 C3B01120183 for <jose@ietf.org>; Sat, 18 May 2019 02:09:24 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id b18so9379657wrq.12 for <jose@ietf.org>; Sat, 18 May 2019 02:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=NH+OgDQVomhJ2K9RrraO1QcwNrStjb7oQVOmARZCs6A=; b=d5Tcm/bIdM1eIS0b54sRicIiHvNS2uO1mSITB8J0cPiYUgTYTieG/qOxwBniOOIaQ3 ab/D7C9b040ugoDXJ+r/pBW/V4Bya3eUJSleCIoN1HBLbEvNh+hphQ0oNBZk1JgxUcUC tVry4zPSlV42ft+EFjAHpkIjGVndyMYt1gjql6JPc0zS37ZdrahyV9UJf7VENsEnoiqw 8WUm4E5dRkgB4K1qB7FKjP3uqYZ/gAHx6MwOo+C7qTNDVcj80htjwhE6pbAtnTATEAfT dLLyRSRPKWdFMoEb/DWiJGsdmL1k6zsJnXfGFLI7qM4griIgo8jRWvWYyK4ANa/tdQmw qtOQ==
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:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NH+OgDQVomhJ2K9RrraO1QcwNrStjb7oQVOmARZCs6A=; b=oQRjlgRLSb2q2lF5j4WBwEYRBjaZrE1yMUq90SJCKCNUV8fk531Uhm0rBf5wWSOypi TzE/QrrVh/G+RM9Klirodh7Rx8PSK6mtPGQV3thQDjCJFG5TG0SMePVfkeEaK/XfSm3Q 4ML4YFEjPSAtohHvae8WZkETwYUdF9RDdWGrdYbyZQO5VDFfrxU/0j6+5a4Gs9ghXUaq VpLwht0GKbPIUHwqu1FDQrjvJvQqBnQxPt9ntojrHxK25kJDquo4eOuU9fYII7+p9TRy UbqTxoo8Nb0ki0fxE6Zq0W2ojZen3zV0fZJkuT50SzyD2fs6mI83owOxUgLqYFVsu1gx GUYw==
X-Gm-Message-State: APjAAAWSFYltTdjGLkPT5DU9xc9BsD1PnpojViEg5qCSaZZ6SOgY6oPn tWtypenVKlmbNNC9IBl/kLs=
X-Google-Smtp-Source: APXvYqzhPXF8xBFwjUAqzDKClobQIa2SVcG39LcXVneYu9L2G9GyPUcdrrJPT5484CRz/p+NAzbxiQ==
X-Received: by 2002:adf:fa4e:: with SMTP id y14mr26869638wrr.149.1558170563195; Sat, 18 May 2019 02:09:23 -0700 (PDT)
Received: from [] ( []) by smtp.googlemail.com with ESMTPSA id l2sm13936415wmf.16.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 May 2019 02:09:22 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: "jose@ietf.org" <jose@ietf.org>
References: <2c55fd23-592a-98f0-ee6f-4308a8e43e73@gmail.com>
Message-ID: <e806aec8-05ea-634e-58b7-9b379fc646be@gmail.com>
Date: Sat, 18 May 2019 11:09:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <2c55fd23-592a-98f0-ee6f-4308a8e43e73@gmail.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/jose/ZIZ0v-ggQG2rXNP0hXtvwN76JKc>
Subject: [jose] Hashing JSON Objects
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: Sat, 18 May 2019 09:09:27 -0000

Since the value of clear text messaging has been unilaterally declared to be zero, maybe other and more sophisticated uses of JCS could be of some interest?

In Saturn[1] JCS is used in many different ways including for signing and authenticated encryption.
However, the ability to only take a hash of JSON objects has also been put to good work.  Yes, "hashable" JSON is what JCS really is. Full canonicalization of JSON is something else and from a *practical point of view* essentially impossible.

Consider the following (slightly simplified) payment authorization scheme:
1. Merchant creates a signed PaymentRequest in the form of a JSON object and sends it to the User for authorization.
2. The User (SW) creates a JSON object with a set of properties including a timestamp, account ID and a hash of the received PaymentRequest.
3. The User (SW) signs the new JSON object using an account- and user-specific authorization private key.
4. The User (SW) encrypts the signed JSON object (User authorization) using a bank-specific encryption public key.
5. The User (SW) returns the encrypted authorization object + URL to the User's Bank to the Merchant.
6. The Merchant puts the PaymentRequest, the encrypted User authorization object and a Merchant receive account in a new JSON object.
7. The Merchant counter-signs the new JSON object and sends it to the User's Bank for "redemption".
8. The User's Bank verifies the inner and outer Merchant signatures and decrypts the User authorization object.
9. The User's Bank verifies that the User authorization object is signed by a key matching the claimed account ID.
10. If the hash of the Merchant-supplied PaymentRequest matches that of the hash in the User authorization object the request is considered valid.
Next follows the actual payment transaction...

Using JWS with in-line Base64Url-encoding, the PaymentRequest would need to be *duplicated* in step #2.
This may not seem like a big deal but why duplicate data if it is not necessary?

JCS is BTW used some 8 times above.

Hashed JSON is also used in other places in Saturn for privacy-enhancing purposes (selective disclosure).

*Quirky and potentially error-prone signature solutions like TEEP's OTrP* shows another limitation of plain-vanilla JWS:


1] https://cyberphone.github.io/doc/saturn