[jose] Re: Do you need the JWP JSON Serialization?

Carsten Bormann <cabo@tzi.org> Wed, 07 August 2024 16:32 UTC

Return-Path: <cabo@tzi.org>
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 B4A13C14F6FB for <jose@ietfa.amsl.com>; Wed, 7 Aug 2024 09:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuoJSvHa8lnY for <jose@ietfa.amsl.com>; Wed, 7 Aug 2024 09:32:30 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C22C14F6F3 for <jose@ietf.org>; Wed, 7 Aug 2024 09:32:29 -0700 (PDT)
Received: from clients-pool3-0220.vpn.uni-bremen.de (clients-pool3-0220.vpn.uni-bremen.de [134.102.69.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4WfG154vh2zDCd6; Wed, 7 Aug 2024 18:32:25 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <80D19F1D-0FCE-43B4-98E5-5D0A8225A174@alkaline-solutions.com>
Date: Wed, 07 Aug 2024 18:32:25 +0200
X-Mao-Original-Outgoing-Id: 744741145.100376-4fa5ade21f41bca8de26b986bc4654c4
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF49DEF0-BA1A-4951-A2B7-42CCA08088D7@tzi.org>
References: <B421E0DF-9951-4CF4-911C-72F796850DAA@tzi.org> <80D19F1D-0FCE-43B4-98E5-5D0A8225A174@alkaline-solutions.com>
To: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: XV3MPSMIMC7WI6ZCEWAHNSPS6LJM5FF3
X-Message-ID-Hash: XV3MPSMIMC7WI6ZCEWAHNSPS6LJM5FF3
X-MailFrom: cabo@tzi.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Orie Steele <orie@transmute.industries>, Michael Jones <michael_b_jones@hotmail.com>, Bret Jordan <bret.jordan.sdo@gmail.com>, jose@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: Do you need the JWP JSON Serialization?
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/1o7fv4z0HVL8gX7LKyGwa6KCgb4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

On 2024-08-07, at 18:19, David Waite <david=40alkaline-solutions.com@dmarc.ietf.org> wrote:
> 
> 
> Sent from my iPhone
> 
>> On Aug 7, 2024, at 8:22 AM, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> On 2024-08-07, at 15:55, Orie Steele <orie@transmute.industries> wrote:
>>> 
>>> JSON serializations might be better stored in databases, since the base64 encoded components can often be stored as binary instead of text... but CBOR would be even better.
>> 
>> It is trivial to define a CBOR-based serialization of the JWP compact form, replacing the base-64 armor by a CBOR sequence of strings (or arrays of strings for ~).  Having both means that one can have a URL-safe form (base64url + ./~) and a media-type (CBOR sequence).
> 
> Somewhat off topic, but the latest draft is beared toward expressing the serialized parts as either octet strings (each protected header) or arrays of octet strings (payloads, proofs). BASE64URL encoding is a serialization concern and a detail of dropping binary data (like public key data) into JSON. 

Right, which is why it is nearly trivial to do the CBOR outer encapsulation.  (I would prefer to do this in such a way that all formats that use base64url + . + ~ can use the same code to get rid of the outer base64url + . + ~; the _ thing makes this slightly less trivial than it otherwise would be.)

If you could supply an example document, I could write those three lines...

>> I didn’t manage to write the document yet, but it’s really trivial (and, like, three lines of code).
>> 
>> A true CWP would also get rid of base64 throughout the building of inputs for the cryptography.
> 
> The discussion points I anticipate will be whether to make the protected headers JSON or CBOR (more likely, if both should be defined e.g. a compressed JWP serialization as well as a true CWP), and whether to make the serialized form based on an overarching array or map. 

Well, I don’t know about compressed (A CBOR outer encapsulation of those byte strings and arrays would simply be “not expanded”).  Again, I think that can best be discussed based on some examples.

> I’d certainly prefer to have CWP be part of the same effort, rather than replicate the effort in another group. I think we have seen how that leads to having differing capabilities, split attention for reviews and feedback, and multiple registries. 

CWT was defined independently of JWT because JWT had been done already three years earlier.  We can do a properly joint approach this time, with a JSON-specific variant and a variant without special JSON support added.

Grüße, Carsten