[jose] Re: I-D Action: draft-ietf-jose-json-web-proof-12.txt

David Waite <david@alkaline-solutions.com> Wed, 05 November 2025 17:11 UTC

Return-Path: <david@alkaline-solutions.com>
X-Original-To: jose@mail2.ietf.org
Delivered-To: jose@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A03AA83ACF1B for <jose@mail2.ietf.org>; Wed, 5 Nov 2025 09:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.305
X-Spam-Level:
X-Spam-Status: No, score=-1.305 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, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=alkaline-solutions.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO9f_ZZWpcO4 for <jose@mail2.ietf.org>; Wed, 5 Nov 2025 09:11:19 -0800 (PST)
Received: from caesium6.alkaline.solutions (unknown [157.230.133.164]) (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 mail2.ietf.org (Postfix) with ESMTPS id 5798F83AB899 for <jose@ietf.org>; Wed, 5 Nov 2025 09:05:37 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1762362329; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xv7P2NGmx5gThV07CTr+tyK4i7OYP/s7PCUFoQxYbwI=; b=WcxHYRES+mqJpGsJUzm8IskegeQFnf/JhCKZnfvaQTLKT0pLgboiKsknx5Rr7TcOjvQCma OywbXs5d8A2l7rqcgsYwgZSK1KgQiyor9ceRZNi6n4Klo2+9cwOOMY3aIVxeGctfykUNoi qWdlOi9K3R2kepnuNEBy6gseSe34eXEJOcagPMfnQ3Ab0iWhEv91yTviDYv29XwdLfYDGJ qHkqfJxeU7fXrpbDALvzqmnIxb4J6xhlo7GlPMSt28JCr6LDv9N2DUTiA132k9STGgEqKt qzCH7/wx+wD4tXwKplGYOcSo6oF3QXsqWWKNrau9kWMbaoN0ahWQ+ot/szPsAw==
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com
Mime-Version: 1.0
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <2fff93e711e621960abe362cebd58b16a2080b6c.camel@redhat.com>
Date: Wed, 05 Nov 2025 10:05:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F38BEF8-F635-4001-A594-F9648139A85A@alkaline-solutions.com>
References: <176230476293.658394.8309587942982495635@dt-datatracker-5df8666cb-7l4w5> <2fff93e711e621960abe362cebd58b16a2080b6c.camel@redhat.com>
To: Simo Sorce <simo=40redhat.com@dmarc.ietf.org>
X-Spamd-Bar: --
Message-ID-Hash: Q56TN47W5HV36R3H4E26RNKW5ULTML7N
X-Message-ID-Hash: Q56TN47W5HV36R3H4E26RNKW5ULTML7N
X-MailFrom: david@alkaline-solutions.com
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: jose@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [jose] Re: I-D Action: draft-ietf-jose-json-web-proof-12.txt
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/eIpmWyDwJZQaSUmAonrY__g9FSM>
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>

Hello Simo!

The expectation is that within a particular application, one or the other would be chosen. As such, implementors also would be expected for the most part to target one or the other as mandated by the application domain. I think it would be appropriate adding text to that effect.

The JOSE WG is chartered to create CBOR representations of JWP and JPT, and to leverage COSE and CWT where feasible. The changes in the scope of these documents largely come to different header data serialization for CBOR-encoded JWP, different payload data serialization when creating CPT, and media types to distinguish JSON from CBOR. Several headers also have slightly different representations (but the same semantics) under the assumption of leveraging JOSE vs COSE infrastructure.

Editorially, the decision was made to keep JSON and CBOR in the same documents to better illustrate when there are differences and to simplify creation of common registries, but also as a conscious choice to not represent CBOR serialization as being a secondary or lesser goal when the work is being done under JOSE rather than COSE.

-DW

> On Nov 5, 2025, at 8:05 AM, Simo Sorce <simo=40redhat.com@dmarc.ietf.org> wrote:
> 
> FWIW as an implementer of the JOSE suite of algorithms and protocols I
> am *not* in favor of adding a binary serialization (CBOR) to JOSE, as
> it is completely antithetical to the rest of the specification and
> would force implementations to add a completely new and complex parsing
> and serialization subsystem that is fundamentally different from the
> rest of the protocol.
> 
> On Tue, 2025-11-04 at 17:06 -0800, internet-drafts@ietf.org wrote:
>> Internet-Draft draft-ietf-jose-json-web-proof-12.txt is now available. It is a
>> work item of the Javascript Object Signing and Encryption (JOSE) WG of the
>> IETF.
>> 
>>   Title:   JSON Web Proof
>>   Authors: David Waite
>>            Michael B. Jones
>>            Jeremie Miller
>>   Name:    draft-ietf-jose-json-web-proof-12.txt
>>   Pages:   33
>>   Dates:   2025-11-04
>> 
>> Abstract:
>> 
>>   The JOSE set of standards established JSON-based container formats
>>   for Keys, Signatures, and Encryption.  They also established IANA
>>   registries to enable the algorithms and representations used for them
>>   to be extended.  Since those were created, newer cryptographic
>>   algorithms that support selective disclosure and unlinkability have
>>   matured and started seeing early market adoption.  The COSE set of
>>   standards likewise does this for CBOR-based containers, focusing on
>>   the needs of environments which are better served using CBOR, such as
>>   constrained devices and networks.
>> 
>>   This document defines a new container format similar in purpose and
>>   design to JSON Web Signature (JWS) and COSE Signed Messages called a
>>   _JSON Web Proof (JWP)_.  Unlike JWS, which integrity-protects only a
>>   single payload, JWP can integrity-protect multiple payloads in one
>>   message.  It also specifies a new presentation form that supports
>>   selective disclosure of individual payloads, enables additional proof
>>   computation, and adds a Presentation Header to prevent replay.
>> 
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
>> 
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-jose-json-web-proof-12.html
>> 
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-json-web-proof-12
>> 
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> _______________________________________________
>> jose mailing list -- jose@ietf.org
>> To unsubscribe send an email to jose-leave@ietf.org
> 
> -- 
> Simo Sorce
> Distinguished Engineer
> RHEL Crypto Team
> Red Hat, Inc
> 
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org