Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwk-thumbprint-uri-01.txt> (JWK Thumbprint URI) to Proposed Standard

Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> Wed, 11 May 2022 12:46 UTC

Return-Path: <rifaat.s.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF37C1594B4; Wed, 11 May 2022 05:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLv3KUYq74NM; Wed, 11 May 2022 05:46:18 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8059C1850EB; Wed, 11 May 2022 05:46:08 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id c1-20020a17090a558100b001dca2694f23so1972916pji.3; Wed, 11 May 2022 05:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qYBVCNipQg5W2JsP9aToHZIZ5EYNGV4sPIuCJD+PE7M=; b=Z4bQCLMOMws7Dyr74CYZKklSxkfy8uZwIleo9Zy+5wcAXG0SBt8Q6ToHC3O08O1DMt ESMhJiv1OhKS8UFRazFMdD2e6cfcE37iKAZIM764H8O41i6a9aAf1l/qPDdCcBeXwfYq OwQws/oG68uXft0j1tl5sajiySpASzyrCcZn2ves7PnFCeBpYww5QF4ehFimCLEWZqgY C/FVwI60uvqdjCocmA8DEPxLgs+T/mZl3e+KOtDXdeIQfGcT9IA/hmMRQi85RxwsNbNs PfZZg1zdutW0sWHAL1PFsozrvw9DBLTa0M1fSkUNTC1ybLUikX4Izq0z/5R5zL3MS9T3 vwLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qYBVCNipQg5W2JsP9aToHZIZ5EYNGV4sPIuCJD+PE7M=; b=awIEjCwR+b12t2/Zy23mmV/cFD/s+GjnAZhDOOV/2bedliA1pfVICjm7NICYigUwY4 RzurFX9M8W+9Ku0BLF2XBREspQi2aokq81xDktsq9qvB9+v4i4vPZlakHaKbdxGBBRlb jZHG3IgvJcyKwFkzJ6zvLpkpPo/Lto0D2B6HBtZl2wait3ITgWIMkmcTdnMXgJYMz6Ws GTXZZAe8B2nb7NSqjy5kGQXhtcWKUKUKrG8VVdi/AeXSQ0lKWUodzdC36I/CK7Qq9A10 TQyMjjWlasKVTQyGGcWeoXG2RCXMr4PArJfgEUHgpbzIW6NcRTAT3byep42a1BuojvOX BFTg==
X-Gm-Message-State: AOAM533XIK/un/q3MEZ8VWCpi5KdnskKpQS71OJKoqq9/4mP2NeAvvQo VEG+pOdj90YnyHfRoSHZZAyC9fmync6aEahL35g=
X-Google-Smtp-Source: ABdhPJxC6+umbdUG7jTIlGFRxO86R1dRV86Q+8YGxuAVcoZQkHHTO+ZUye7VutxHmbYnszOIoKolyFaQC2OmigqLSUc=
X-Received: by 2002:a17:90b:1e4f:b0:1dc:847d:38b5 with SMTP id pi15-20020a17090b1e4f00b001dc847d38b5mr5274024pjb.3.1652273167907; Wed, 11 May 2022 05:46:07 -0700 (PDT)
MIME-Version: 1.0
References: <165092137918.1385.17213010140457783707@ietfa.amsl.com> <ME3PR01MB59734146D665E8834FE3FC40E5FB9@ME3PR01MB5973.ausprd01.prod.outlook.com> <SJ0PR00MB10056834E04389B9C5A918B2F5C09@SJ0PR00MB1005.namprd00.prod.outlook.com> <CADNypP8ZwqeXJGabGVhKamsQa9JQqD=10dB57++cDZFuQXUuDg@mail.gmail.com> <600A7327-CEDD-433B-B457-319CE36827E9@alkaline-solutions.com>
In-Reply-To: <600A7327-CEDD-433B-B457-319CE36827E9@alkaline-solutions.com>
From: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Date: Wed, 11 May 2022 08:45:56 -0400
Message-ID: <CADNypP93Ut4zpRvhjotTwBZ6+MgXasugB1nWbCfvcb-3k5bQRg@mail.gmail.com>
To: David Waite <david@alkaline-solutions.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, "Manger, James" <James.H.Manger=40team.telstra.com@dmarc.ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-oauth-jwk-thumbprint-uri@ietf.org" <draft-ietf-oauth-jwk-thumbprint-uri@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ebe2305debbd34f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4Y-y2QYAD2s0C5i0SnUksyNi2Mc>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwk-thumbprint-uri-01.txt> (JWK Thumbprint URI) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2022 12:46:21 -0000

On Wed, May 11, 2022 at 4:53 AM David Waite <david@alkaline-solutions.com>
wrote:

> RFC 7517 does define an "application/jwk+json" media type which could be
> used with the ct= query parameter for ni-scheme uri. The resulting
> ni-scheme URI could be used to refer to a specific generated JWK document.
>
> However, I do not believe this would be a sufficient way to indicate that
> this is the pre-hash minimized, canonicalized form required for thumbprint
> generation in RFC 7638 (e.g. non-required members removed, JSON documents
> in lexicographical key order represented as UTF-8).
>
> The information dropping of the canonicalization in JWK thumbprints
> results in a few important properties - in particular, a local JWK document
> representing a private key and the shared JWK document representing the
> corresponding public key will have the same thumbprint.
>

Can you elaborate on this? how would two different documents produce the
same hash?

Regards,
 Rifaat




> This enables the JWK Thumbprint to serve as an algorithmic key identifier
> for all participating parties.
>
> This creates the issue with using the ni scheme - a NI URI could be used
> to refer to a single JWK document. However, the semantics when interpreting
> a thumbprint are that it references potentially multiple data forms with
> different binary representations, and that a software ‘lookup’ operation
> taking a JWK thumbprint may result in data which does not have the
> specified hash value. My interpretation would be that these behaviors go
> against the spirit of RFC 6920.
>
> -DW
>
> On May 6, 2022, at 6:27 AM, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
> wrote:
>
> Mike,
>
> RFC6920 defines an optional query parameter, in section 3:
> https://www.rfc-editor.org/rfc/rfc6920.html#section-3
>
> I guess you could have added a query parameter to add that specificity.
>
> Regards,
>  Rifaat
>
>
>