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

Neil Madden <neil.e.madden@gmail.com> Thu, 08 August 2024 20:26 UTC

Return-Path: <neil.e.madden@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 78767C14CEFF for <jose@ietfa.amsl.com>; Thu, 8 Aug 2024 13:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GFqmK5yA_oTQ for <jose@ietfa.amsl.com>; Thu, 8 Aug 2024 13:26:41 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A935C14F71D for <jose@ietf.org>; Thu, 8 Aug 2024 13:26:41 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a77e9bd9254so13335166b.3 for <jose@ietf.org>; Thu, 08 Aug 2024 13:26:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723148799; x=1723753599; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=DnFHOxuLCrrDGZNlTJROOzdaQHXMmwyOHezWaE4LJ1o=; b=Rs2cW/revwcRbARA5MAPo+zWnxmr7L23IcpQ0yQCkInvJgwqybHS4rI02ypg8/mW/8 bjbMvW+5wgcpVVigmlOsA8aoDmqYtpx9JWVCz/OSrft9WcWjE6N14UZap3u7Dekp8acy bSba+06YI78Q4nKYx2l0+VcFW0K/7QP69/KwYFmtm1VxA8oyCY3Ra4oxEosS1hMfNihc XRbNh7QwmyLunVjMMzlVAbZM0Ms72e23wKyDyBkuACfAYtDlsPVNbTajviXYjQwahX2P cMo45WZRQi7sX8VWMlQjBPXVh+GErRA2gU4O0jakxvNwl/tXOXCEXsMLFmf0DSWqSojv sWlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723148799; x=1723753599; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DnFHOxuLCrrDGZNlTJROOzdaQHXMmwyOHezWaE4LJ1o=; b=Skmxvea93qz0+35Yj41/R+7VVkgrZOUX2bwc/VjcTfkJsQxtZjVdKAiFNlJfi4nn6D W3oaXi56IMUX9WDwwp6LcwCOrfVonbcqE7jONUQg2gecyd+0/WaBlHQbLj4HYoiwBFAD IMCMg/W8eaqyxOmUbPyXz8jCG6yAKUlZTwymsiwS5gs5aUkIbKuOsFpJei+T7f9tVbjb KxxSoRU+dBpnT8OT9Yg0eIFFc1NF0+pxUrjc50HdP/t9ptFfcnPN5d4C0NWav0NTbf41 nMz9fWBFeN8S6le+8WHCcFfWTT3Pr8xEkpgKhz4nFugXbjpIyGReHzvqBS+lHPJFi37J gtwQ==
X-Forwarded-Encrypted: i=1; AJvYcCXR86xtVp9t+wuNm3rng1Ji2wnVKapLURfTND+CYbjoj69yLi78P2etaRCGAz0IMmEUwGwdzRHTS1zGUgBJ
X-Gm-Message-State: AOJu0YwztG05UZVzeNyzpO6G+fKTAvBSuqu50QvWEXMENCH7ugoswj4A PYFJ4MKguBwhYW4zjUSmKdlrlCKS1CIQnv/Ii2/hJ8fWRuERs/O7
X-Google-Smtp-Source: AGHT+IGeieg2WnRqQk1cMyF5M0F5U3IaJ2VaNzh74trnYOFqMg0fMLZCTgvb5kyjAWiUpeH/lRNBRA==
X-Received: by 2002:a17:907:944c:b0:a80:a31f:44be with SMTP id a640c23a62f3a-a80a31f4501mr19036066b.3.1723148798558; Thu, 08 Aug 2024 13:26:38 -0700 (PDT)
Received: from smtpclient.apple (220.60.90.146.dyn.plus.net. [146.90.60.220]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9bcf0f5sm775530866b.3.2024.08.08.13.26.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Aug 2024 13:26:38 -0700 (PDT)
From: Neil Madden <neil.e.madden@gmail.com>
X-Google-Original-From: Neil Madden <Neil.E.Madden@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-10DEE0A7-9789-43A0-A2D1-10ACED865457"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Thu, 08 Aug 2024 21:26:27 +0100
Message-Id: <53F74ECC-7317-43F7-BDA3-C2B6FBB1CB2D@gmail.com>
References: <CAN8C-_L4P=stFigYkoKG9-qEukRFA+2MWnjcYuqGrUCzMGoEaA@mail.gmail.com>
In-Reply-To: <CAN8C-_L4P=stFigYkoKG9-qEukRFA+2MWnjcYuqGrUCzMGoEaA@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
X-Mailer: iPhone Mail (21F90)
Message-ID-Hash: J6MNUKE42IEZB3AA3JVECZ4M3A6DTARA
X-Message-ID-Hash: J6MNUKE42IEZB3AA3JVECZ4M3A6DTARA
X-MailFrom: neil.e.madden@gmail.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: Brian Campbell <bcampbell@pingidentity.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/j4qdjN26zuPNlfCpFo4_mdT5v6M>
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 8 Aug 2024, at 20:44, Orie Steele <orie@transmute.industries> wrote:


That only applies to "SD-JWT+KB"

I don’t think so, otherwise SD-JWT would not be secure. The signature covers the claims, which includes the hashes of all the disclosures. Thus the disclosures are all protected (cannot be altered/forged) and immutable. 


[..]

Unless I am mistaken, there is no ordering requirement for the SD-JWT without key binding, so the disclosures are mutable, until the holder makes them immutable by applying key binding:

They are an unordered set, so this “mutability” is irrelevant. 

[…]

OS


On Thu, Aug 8, 2024 at 2:20 PM Neil Madden <neil.e.madden@gmail.com> wrote:
Maybe I’m missing something, but all of the disclosures are covered by the SD-JWT signature and so (a) are protected, and are (b) immutable.

— Neil

On 8 Aug 2024, at 19:18, Orie Steele <orie@transmute.industries> wrote:

That's fair : )

Let's replace "suspicion" with "I would have argued for a different design".

In JOSE, ~ is just used as a placeholder for "missing unprotected header".

You still need to validate that the correct mutable data was included, and that no "unexpected mutable data" was included.

That's a "verifier policy over mutable data".

In the context of SD-JWT that means checking disclosures, matching their hash to the kbt and making sure the kbt is signed by the cnf.

That is very similar to the kind of unprotected header processing that COSE supports, see:

https://www.rfc-editor.org/rfc/rfc9338.html#section-2" target="_blank" rel="nofollow">https://www.rfc-editor.org/rfc/rfc9338.html#section-2

Sure maybe it's less obvious that jwt (cnf) -> disclosures -> hash -> kbt signed by cnf is a kind of counter signature.

But it is a second signature, over a specific set of disclosures that is grouped together with the first signature, which are verified together.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-9.1" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-9.1

"""
Unprotected headers other than disclosures are not covered by the digest, and therefore, as usual, are not protected against tampering.
"""

This is similar to how values in unprotected headers in COSE are not protected, unless there is some "verification process" such as checking a counter signature, or merkle tree inclusion proof.

Isn't JWP meant to replace SD-JWT in some cases that require stronger unlinkability?

IIRC SD-JWT and OAUTH had good reasons to define a JSON Serialization, and if it's used, those users should be able to switch to JWP or CWP in the future.

OS





On Thu, Aug 8, 2024 at 12:33 PM Brian Campbell <bcampbell@pingidentity.com> wrote:


On Thu, Aug 8, 2024 at 11:27 AM Orie Steele <orie@transmute.industries> wrote:
 <snip>

If JWTs had unprotected headers, I suspect SD-JWT would have used them for the mutable part (disclosures).

That suspicion is entirely incorrect. 
 
<snip>


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


-- 

ORIE STEELE
Chief Technology Officer
http://www.transmute.industries/" target="_blank" rel="nofollow">www.transmute.industries
https://transmute.industries/" target="_blank" rel="nofollow">https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc">
_______________________________________________
jose mailing list -- jose@ietf.org
To unsubscribe send an email to jose-leave@ietf.org



--


ORIE STEELE
Chief Technology Officer
www.transmute.industries

https://transmute.industries" target="_blank" rel="nofollow">https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc">