IETF Logo Mail Archive

[jose] JWS Counter Signatures

Anders Rundgren <anders.rundgren.net@gmail.com> Fri, 23 November 2018 07:50 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF82712D7EA for <jose@ietfa.amsl.com>; Thu, 22 Nov 2018 23:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 bxpSnD9AholP for <jose@ietfa.amsl.com>; Thu, 22 Nov 2018 23:50:22 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 1860B124BAA for <jose@ietf.org>; Thu, 22 Nov 2018 23:50:22 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id c126so11035609wmh.0 for <jose@ietf.org>; Thu, 22 Nov 2018 23:50:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=N3iJ3umLVmNUK4RtouOpGwr4LiQt82pp7rBLnyiZO5g=; b=h2C5v5wLbAmLJEnmyN2r3Zj7kk7F+7y0odna0f+fmCRv2kEcxyFyNFo73gE5aA1qFY DsqRvUR0Kf7Ez3raNL/KsOg3Q2GOl75zlsxnjXlaZ50+SBYr+6CGir3gfApocSntRxYL 8EMzd/akfUzq6NBTf3ohBcEqSXe0+K/ZWnp9Gtsd7gQQadiTfJBZwXY23BM4NOXFI1oG 8UWbo9c51z3e49RhXV5+1tKDS6izPKuS555+ccfyU1qTxSSOQtikV2mzKJ3hnG4flust 7Jexr5BN92PSMViK2GWUI4C2JAprlB17jvXxheJZCCpPnXRu9p3rb/agYaov2SsZGqEB qq6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N3iJ3umLVmNUK4RtouOpGwr4LiQt82pp7rBLnyiZO5g=; b=lzBV00vs1AVgGWrWUw8fKlGewS6NHjfzYxYCZ21e5PQZjMJSWPn6/FBu24oZKDDXpV 8XBdwyqrG4n95O4BcO91b4ZhUzslOgZXwhp6Qv1oSIr0kVIR8eWAyuDtO7yF/PKRPQ2a p7GhWwLcwqLm0u6WMFcWqgBAvZm3ZY0uOCrU5AMO31Efe8CA8xFf8HJBppeR06TE5ynN pvoYevAkiH1RchEo5BRR5ldHMjpT3MQrPacHcYYp2X5l6R4ZrhLYSDLfcTmHRZcGK5Ps t+Q5CPUVMotu8gLOl73pHhvjC00BFRGTTR4Py8xKH8O1tMogcgsoKDHmtcQRHaWYfWib PxAA==
X-Gm-Message-State: AGRZ1gKuenfa6UcG/JKldHKLsnXVPLLP52v2EcbYg3hpEGcnRAE5p+up S0htRnjZP6Eal4JbbHRj/sTy/cqp
X-Google-Smtp-Source: AFSGD/WL4PQ5dgg6IptvWxi94rOL6ksHSyhGYAIE2aleYnPA7t25jrX23roLF7D8Wip3t/H1lzJcqA==
X-Received: by 2002:a1c:7ec9:: with SMTP id z192-v6mr12319434wmc.43.1542959420026; Thu, 22 Nov 2018 23:50:20 -0800 (PST)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id s1sm34726266wro.9.2018.11.22.23.50.18 for <jose@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 23:50:18 -0800 (PST)
To: jose@ietf.org
References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <CAOASepNX4aYVmPWXyODn0E2Om_rimACPECqJBvZSOXVVd_p8LA@mail.gmail.com> <D21F3A95-0085-4DB7-A882-3496CC091B34@gmail.com> <CAOASepM=hB_k7Syqw4+b7L2vd6E_J0DSAAW0mHYdLExBZ6VBuw@mail.gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <MEAPR01MB35428606C09BF315DE04CC79E5E10@MEAPR01MB3542.ausprd01.prod.outlook.com> <CAHbuEH6DCD7Zc+PK3TnCBkKv1esnROwyCcDb8ZR+TKwgQQ+yXQ@mail.gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <CAHbuEH5oH-Km6uAjrSr0pEHswFBLuDpfVweQ+gpj472yk+8iTQ@mail.gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <A37D69B1-6B77-4E11-8BB9-A0209C77752C@tzi.org> <434fbdb6-0202-5a02-4cec-9332fbbe548c@gmail.com> <FBBFA6FA-4B0C-4239-9145-0B713120EC98@tzi.org> <01fd01d47f5f$4c4889f0$e4d99dd0$@augustcellars.com> <7b1d293c-1d97-44e4-0cd8-55ec1db6c3b5@gmail.com> <AD2DB2EB-3F06-4C55-94E4-CED60F6FF4CF@alkaline-solutions.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <222a2534-07fc-a630-99f8-bbe6f6aea29c@gmail.com>
Date: Fri, 23 Nov 2018 08:50:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <AD2DB2EB-3F06-4C55-94E4-CED60F6FF4CF@alkaline-solutions.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/z6EXKpSGniPMYDyQOamG0mOJFDk>
Subject: [jose] JWS Counter Signatures
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: Fri, 23 Nov 2018 07:50:25 -0000

Counter signatures were actually the major "inspiration" for Canonical JSON since JWS based dittos are hard to debug and document due to the deep nesting of Base64Url encoded objects but it is still fully doable.

However, in a system which I will present at Trustech 2018, I came up with a counter signature scheme where JOSE simply put ran out of gas.

https://cyberphone.github.io/doc/payments/payment-decentralization-scheme-1a.pdf

In this system (very briefly):
1. a Merchant creates a Payment Request and sends it to the Payer for authorization
2. the Payer authorizes the Payment Request with his/her signature key.  The signed authorization data includes a hash of the Payment Request
3. the Payer (for privacy reasons) encrypts the authorization data and returns it to the Merchant together with an unencrypted URL pointing to the Payer's bank
4. the Merchant sends the original Payment Request + the encrypted Payer authorization data to the Payer's banks for fulfillment
5. the Payer's bank decrypts and validates the authorization data, including verifying that the hash of the Merchant-supplied Payment Request matches the hash in the authorization data

It seems to me that a JOSE based design would have to be architected in a fundamentally different way.

Anders

v2.23.0 | Report a Bug | By Email