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

Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk> Wed, 28 April 2021 09:52 UTC

Return-Path: <soiland-reyes@manchester.ac.uk>
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 8ACFC3A22C8; Wed, 28 Apr 2021 02:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 c0-C1DGLp_Vd; Wed, 28 Apr 2021 02:52:07 -0700 (PDT)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100085.outbound.protection.outlook.com [40.107.10.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965BA3A22C7; Wed, 28 Apr 2021 02:52:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UTz4tMHEvYrMl8iP+9pXyogWq9pekSXvz3YHA/m0VdlMEn3aNKQerqq0iiFOIXAdZFXJdlXOsNwEoMH+qgErdLp8dqoynhXt6F/JzxyE7it60XQGQZXTJCQt+VfKR0xmilJ73cHWX9gbE5JKS1g6UDhYE8tz6MMSDeIohxi+iW+1fr+B7Gg8jTdfY9SuWnPkxwCY6g35nDnW4YbU9Ipj1vVZT1/k8LcsqceoTb4r+2AHkFQ2lBMmEEHbINBqsZGvXymCCnRdV3PIF2WykK8DS3ueaBl4C4HslQUETbnxZ3gcbCR7nz0hgCDzUyLdQ7zfiqwrKr77U8fGUwdpfxmxKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+dzmsmH8ccztDupvbSZ4ewlgfagGHkEQbIa5m/JVpAw=; b=kLQ+ogbAXcOX31NvGVFlTMsWnwLBoGe+GdCQEtT9apucpbDuKY01HnA0l5wl5/66gAD16HV+CX2jXtvsfPJCJ9r/0Vec2y9dnKh48QOohjKmi8UNFtjyhy8eurHIt/Lwaum+ZEH9STozmZpQh4Xu7eLqDFqsQL2NpwnGJTYPtn5ksbmNmedxkBacFGcVroNWe1D2r8rU7hW74dnhLoNf+k9v1Ev7GxjKrrBWdbZNDMlk8DknjIOQgCKwqUUsBvQ0Gikvbnf4pgJAq+FKhms51UpYymuYkKYluEKgaR6DewwQZQzGpDDDJmgKCvWy690nfrmDT8gbnh+rldIltAiRSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=manchester.ac.uk; dmarc=pass action=none header.from=manchester.ac.uk; dkim=pass header.d=manchester.ac.uk; arc=none
Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:184::9) by LO2P265MB3134.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:166::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Wed, 28 Apr 2021 09:52:03 +0000
Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e]) by LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e%7]) with mapi id 15.20.4065.027; Wed, 28 Apr 2021 09:52:03 +0000
From: Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk>
To: Bret Jordan <jordan.ietf@gmail.com>, Dick Hardt <dick.hardt@gmail.com>
CC: "art@ietf.org" <art@ietf.org>, IETF SecDispatch <Secdispatch@ietf.org>, DISPATCH <dispatch@ietf.org>, "rfc-ise@rfc-editor.org" <rfc-ise@rfc-editor.org>
Thread-Topic: [art] Plain text JSON digital signatures
Thread-Index: AQHXO3n9Ux7vg67F8E+dTqNYh8wUoarJJ3GAgAAOHICAAIPpAIAACKAA
Date: Wed, 28 Apr 2021 09:52:02 +0000
Message-ID: <CA685270-A834-49AF-993A-75F0D70308DB@manchester.ac.uk>
References: <CAD9ie-v7uJOpjj+nbZCfQe+4JEQt-6=b6cm57iFPAn_enGeRCQ@mail.gmail.com> <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <FD23AA4B-4224-4162-9243-FAFD9EAD9656@manchester.ac.uk>
In-Reply-To: <FD23AA4B-4224-4162-9243-FAFD9EAD9656@manchester.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=manchester.ac.uk;
x-originating-ip: [2001:8b0:a657:68e3:4d0d:8981:d3ab:c2c3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f59d230a-262e-4ae0-2520-08d90a2b4660
x-ms-traffictypediagnostic: LO2P265MB3134:
x-microsoft-antispam-prvs: <LO2P265MB3134E294DB4FE153279F54A4DD409@LO2P265MB3134.GBRP265.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: d4B1f1LIGGhcEPO2VHzKAuz18R1oB1egQCoMb4pMcr4hjYOncZRoiNihB3BnNLDQGtijLtECL14RvKSCoygPlzOtrykqNppz+KZ2HQfKbgmm8e4Rbr8vn6PjOIn8KGTsw92YJXdPwHuB+e1N/327/2zPaeHdy3d8fAokXNzxSwF/LL5VQzyg1bo5okjL/MDWlvC0V6q73e+SpNwJEPoYxHCag6wN7DGljlxk0idIoqRxBaGAfmA1/6Y+PuOvIGHzA76/b7iLCHXfHvooPax75CPfAjEcWMclXRTIazKaTfUY/dOG16fqbm3L52m4BnGeZf2ECSGmxVSTYptdCG8P5s3ERI/aTFk3/dwcqcd2K2hk/JeJwn8r50kgseNkyKlpGirT3Knv9OykFp3JHVGOBZjMUqPJQP+YURZwnLFfrHbo7NMKVx+0t03SRLrPoe73WTG7zjkgAM/gnwQGILpnAeohQNWEpYyYnTP8ydZBM9YoTiAgmHZ7PSxyv/xs8IZ3N671O3MIakKZ7iRSLFhxjSM6eGK6zDiTWRYLpnEBHKgp4sVdexAPepIf4og+oHjIFE2xa3DXrm2K251sJK0qwC39a2SWE7L8Bg49YStNNqql1Rip7R7DS2jgNX3nEvxKnf/i65K5kelih7W8H0wR1FhPFuaIWDgiIRqzhacPVPqgLB9T+ewBEerMmtJz5LO9aB1D6CyEtalHy1sVA/1hIPtdH4LhSuiUl7UdWjAhzDk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(478600001)(4326008)(6512007)(166002)(83380400001)(8676002)(86362001)(38100700002)(33656002)(21615005)(36756003)(122000001)(2906002)(186003)(66446008)(2616005)(786003)(316002)(53546011)(71200400001)(6506007)(66946007)(66476007)(64756008)(8936002)(76116006)(54906003)(6486002)(110136005)(5660300002)(966005)(66556008)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Xsz558Bk0jqTktcaCy6/vP7anRxukxZ6dP+Ur4EdcTmwrGOPq0egfpSGQKAd5O/yl9TLsirWSjOQwiBp7sda4zpaD2lxGNj2CR/c16Z7oC8iZCxWGaknsVTsCHYMgP6qZOQFAC+YCRS0w0vX1nwkeKQppiaIwyXuQx+23SfVLpg5cyr5oIFB2Q2wh5T85m916AefAkOtuXBMAlyH04MlWbXpUuT5S4uYSjtUr09PPLvILkmDsJZSLk/9eC6pKnKhdt3oECIbhAgJ+FmPtfBsMFDxWQEkI7vYMbZztIVoPOS1JiIIZ0fV7DqpDeoN/zYZaiEtOw6+mAYepslpyopHcw1kmArrbXYcYmurHxE1tf5XUFUbRRdQZwCAA8XBvHjLJKVDZCK/l2aFE8ms8CZaHvk1ENL+tz2hggebiDL9iCpRQvQbVo0znIERFBSKDhifcJ5i/Fm+ZMhLFZhlsqSMN8Wq6D0wh5SYmDgMlLjsjUDU+fgAzRojRGhLlmL1AkXqQSoV3yDO47eu7eN4kBa2TZE3pY0ze6pukcz/f0MmL4OAAxPt3PsgH4A2jHKb0YTBBcVTPiB/4nJa/RrTnb903pyMnxbWAbVMavhuBDhek3Tn4QcVH17jcAUR4SLb3Np7XUXJhN/CV+8a6L2i65SyLdM8S2J9+4f4W9eB55VVA6nr1JrPgT/i7oLP10BXGH/ptsKt4zYQoXSaMsy6+W+nknCHXXjXgJJRWOsRh1OhJTQwtEj5YGDdMyzwIctscCQTlBq8/r2OGGlpYRE3k3fIJaAtyvhdl6LpGH13hZCG3GwUP5AcfT1rn8P3X6dR9eI5W1i0hAgPJmNCESdNKq+Eceh3qk79EbEl/YXP9ZZf32ZzXF7oLD7zl01uuTcLNUzB37Dbos6OaP0kyqUBZDPM8mMEFlcwJ0YIoHRoS5+E82H4ZSv2nACcSbm9hFC2Jj2uYsEUlnFeA9rgwpUX31wCFabGOTuJgkstScs1/70dp7qHpKh2uH2RFBs7Fq1yFR2VnvdiA2+j3MxdhidAK0j9voAR/BIp0XhtSJ0WqEVhgnB7VHXk1LmmcYnSpxdR+SLbOPhcp5yRRFsswb2/HzNTyLWUfCyLLZK1xl7cviEZkT2mLn1OmVulHFa2RgqofsHNmU2wCinHZV/dxHvoeBZKn4DgMlbPEpq+Mbuv8N2IzqwEPoI6gZZtkPfrtNw0G+WSH0azT5h+oAKYC5eHOYYDErafvULX11+YC71aBRSoAAXV+NiD2+0emZKCeCsts+zZqcESGiK3/Xe45iEnMROszsGpeYUTrCIG2Wns3tS4jWM7K+yrf6cx9hMnerUjdJA7WuF8jnAJ4ZQkgC8PqZrsEZ8n0p8lqBQHJ8vvuyPXnMi2rj3bB5fh2tCUgYio5ucEEMnI/uAnmPNnEuZTgSaGdQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CA685270A83449AF993A75F0D70308DBmanchesteracuk_"
MIME-Version: 1.0
X-OriginatorOrg: manchester.ac.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f59d230a-262e-4ae0-2520-08d90a2b4660
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2021 09:52:02.9416 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c152cb07-614e-4abb-818a-f035cfa91a77
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qXcBMOpPYOXCnjC7s6kVJCTHMipiXS5v0E6GiBLKP4VmhHxtTj6f3wJeweucqOrcHVBLFgd9yU0DUdQpMBFrLaVmRL3lcK2yRVSAKREMZiM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB3134
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/Da15a-QFCr9bchb0PBUGKi9lZEk>
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 <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Apr 2021 09:52:13 -0000

… I think I got it wrong below, as the JWS Signature if I understand it correct also needs to include the JWS header?

Perhaps this is why it needs to be clarified here! 😊

--
Stian Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
    Please note that I may work flexibly – whilst it suits me to email now,
    I do not expect a response or action outside of your own working hours.


From: art <art-bounces@ietf.org> on behalf of Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk>
Date: Wednesday, 28 April 2021 at 10:22
To: Bret Jordan <jordan.ietf@gmail.com>, Dick Hardt <dick.hardt@gmail.com>
Cc: "art@ietf.org" <art@ietf.org>, IETF SecDispatch <Secdispatch@ietf.org>, DISPATCH <dispatch@ietf.org>, "rfc-ise@rfc-editor.org" <rfc-ise@rfc-editor.org>
Subject: Re: [art] Plain text JSON digital signatures

This draft is well written and an approach we would like to use in IEEE 2791, and from your text it will fit right into our “etag” field<https://opensource.ieee.org/2791-object/ieee-2791-schema/-/blob/master/2791object.json#L129> where we hope for a consistent hashing mechanism to detect changes.

The draft seems to build on JSON Web Signature (RFC7515<https://www.rfc-editor.org/rfc/rfc7517.html>) and JSON Web Key (RFC7517<https://www.rfc-editor.org/rfc/rfc7517.html>) but the 3.1.3 is a bit too brief for readers new to these standards, perhaps give a brief summary for this example, especially as RFC7517 is quite comprehensive with many options?

In particular it is unclear if the JWS Header also needs to be JSON canonicalized – which may be a good idea for consistent “hash” purposes like in our use case?

Here’s my rough suggestion – probably wrong! My additions unindented.


3.1.3.  Generate a JWS String



   Use the result of the previous step as "JWS Payload" to the signature

   process described in Appendix F of JWS [RFC7515].



In short a detached JWS is represented as the string concatenated from



      BASE64URL(UTF8(JWS Protected Header)) || '.' ||

      || '.' ||

      BASE64URL(JWS Signature)



Notice, for comparison with the JWS Compact Serialization,

that the JWS Payload is not included in the detached JWS String,

but replaced by an empty string.



   For the example, the JWS header is assumed to be:



   {"alg":"HS256"}



The above example is equal to its own JCS canonicalization.

JSON Canonicalization is not a requirement for the

JWS Header, however this is RECOMMENDED, combined with

a fixed algorithm choice, if generating a consistent JWS/CT signature

that is s also to be used as as a canonical version identifier

of the JSON payload content, e.g. as a strong ETag (RFC7232).



The JWS Signature of the canonicalized JSON payload, using the key

specified in Section 3, is the bytes



54 75 48 b4 20 42 6f c4 39 x8 8e 3d 8a 66 ab xe

d2 5e 4b 11 f6 b8 b5 34 xe 1a 90 3f 96 63 c3





Encoding as Base64



The resulting concatenated JWS string should then read as follows:



   eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4


You may want to move my ETag recommendation to an appendix, as I don’t feel it fits well where I put it, but I think it is worth pointing out. As a use case.

I don’t know enough about RFC7515, is it possible to do something like regular SHA3 or would my fingerprint use case need to just publicly declare the signature key to use?


--
Stian Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
    Please note that I may work flexibly – whilst it suits me to email now,
    I do not expect a response or action outside of your own working hours.


From: art <art-bounces@ietf.org> on behalf of Bret Jordan <jordan.ietf@gmail.com>
Date: Wednesday, 28 April 2021 at 03:29
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "art@ietf.org" <art@ietf.org>, DISPATCH <dispatch@ietf.org>, "rfc-ise@rfc-editor.org" <rfc-ise@rfc-editor.org>, IETF SecDispatch <Secdispatch@ietf.org>
Subject: Re: [art] Plain text JSON digital signatures

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




[Image removed by sender.]ᐧ

On Tue, Apr 27, 2021 at 8:28 AM Bret Jordan <jordan.ietf@gmail.com<mailto: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<mailto:art@ietf.org>
https://www.ietf.org/mailman/listinfo/art