IETF Logo Mail Archive

Re: [jose] RFC-7517 section 4.5

Neil Madden <neil.madden@forgerock.com> Tue, 07 January 2020 13:31 UTC

Return-Path: <neil.madden@forgerock.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 1E1C7120100 for <jose@ietfa.amsl.com>; Tue, 7 Jan 2020 05:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
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 kHVdvCw6Psef for <jose@ietfa.amsl.com>; Tue, 7 Jan 2020 05:31:55 -0800 (PST)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D261200E9 for <jose@ietf.org>; Tue, 7 Jan 2020 05:31:54 -0800 (PST)
Received: by mail-wr1-x436.google.com with SMTP id b6so53994497wrq.0 for <jose@ietf.org>; Tue, 07 Jan 2020 05:31:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wOQEs6nmrWuC3IitGGV8DrsMfGrDT5+jKxozNyV6N3g=; b=JU+PQSB5ryK3IfG5sSLrPOGHmVQZG+SuHMX/mnYDh0SZEQSLSO7RainJ0VtnnT0Rvb P9UMxwhWCV8Ou05V7Gw8E4atkqt/gCZ8otmCKUhCulJxfj+hrqzOM6pk5tnhBImwpHWL F8UdEn1Tsw31y7A6RsVQW2cWIPUCc7iGYWbuw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wOQEs6nmrWuC3IitGGV8DrsMfGrDT5+jKxozNyV6N3g=; b=c6OhUIEFrdIwbOPCkkgWeUYgPE4oNHOzg8HTwNgSmGIIzlZsO0yga3BjGXSayV2lQg cQk+gms5ZIQiG4xZ5pTJQgG/h2tJRds/sjoo3gnT/K/IS2qGx4npQaHWSRGPWn1g3L4I B26w5bzL6Wir0+rONkm7+SXSGN2E0iDxyn/WajOAO9NoMyl7LBGWBTHSfqfqPFOjjmeJ IFJr0W7woUvEFvoth8rJy6v72iCSQggCHqa7E1SWByF8xuSUycN2W+1OqjtJ5brSiJXS YrQhOQwW1GFKjHXL14qwQ2+4Z7FGJfTwVUIpmjPhO9Ov7WA/eXQMRdUJbGN6Fijl6Ylg Zj4A==
X-Gm-Message-State: APjAAAXFW88GyyLN45kOAg1vo5VHl+KOyYtyxfInFpufeEYTCrO8J4QL /23K3RNELWOslVQFrpNo7RwjYjnus3ihEA==
X-Google-Smtp-Source: APXvYqx5aDs2ATTQPNa9bIozoguWqBpm9eNIwDB+IQFcipExKFQ0fc5NNKadyz85KvRM5lc/D+zG7w==
X-Received: by 2002:adf:f6c1:: with SMTP id y1mr117390214wrp.17.1578403913092; Tue, 07 Jan 2020 05:31:53 -0800 (PST)
Received: from [192.168.2.122] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id p26sm26288409wmc.24.2020.01.07.05.31.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 05:31:52 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <A77EDD59-BC0F-427B-AE56-A4AFF2FEC918@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95C998A9-39EE-48FB-A62D-D143C48ED696"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Tue, 07 Jan 2020 13:31:50 +0000
In-Reply-To: <CAMg6_=zwJgN9RKngR7E397qjhJpVMyRWZPzK+h4W9PRWA8p7NQ@mail.gmail.com>
Cc: jose@ietf.org
To: Ricardo Pereira <rjoaopereira@gmail.com>
References: <CAMg6_=zwJgN9RKngR7E397qjhJpVMyRWZPzK+h4W9PRWA8p7NQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/D1D0lqcTeVF2hw_kKPfClyW4lSM>
Subject: Re: [jose] RFC-7517 section 4.5
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 13:31:57 -0000

As per the language in the RFC this is only a SHOULD (not a MUST) so the publisher of the JWK Set is free to publish keys with duplicate "kid" values. A robust client library needs to be able to handle this case as it clearly does occur in the wild. Our (ForgeRock's) authorization server has also done this in the past (publishing the same key with different "use" or "alg" values, for example).

-- Neil

> On 7 Jan 2020, at 10:46, Ricardo Pereira <rjoaopereira@gmail.com> wrote:
> 
> Hello,
> 
> I have a question regarding the section 4.5 of the RFC-7517 which states:
> 
> 4.5 <https://tools.ietf.org/html/rfc7517#section-4.5>.  "kid" (Key ID) Parameter
> 
>    The "kid" (key ID) parameter is used to match a specific key.  This
>    is used, for instance, to choose among a set of keys within a JWK Set
>    during key rollover.  The structure of the "kid" value is
>    unspecified.  When "kid" values are used within a JWK Set, different
>    keys within the JWK Set SHOULD use distinct "kid" values.  (One
>    example in which different keys might use the same "kid" value is if
>    they have different "kty" (key type) values but are considered to be
>    equivalent alternatives by the application using them.)  The "kid"
>    value is a case-sensitive string.  Use of this member is OPTIONAL.
>    When used with JWS or JWE, the "kid" value is used to match a JWS or
>    JWE "kid" Header Parameter value.
> 
> The part which is raising concerns is:
> 
> When "kid" values are used within a JWK Set, different keys within the JWK Set SHOULD use distinct "kid" values.
> 
> Context:
> 
> I am using an openid certified node library which does not allow for multiple keys with the same ID.
> An issue <https://github.com/panva/node-openid-client/issues/166> has been opened (and closed) where the author/maintainer states that the keys should have different kids and the problem is with the issuer.
> 
> The issuer (based on identity server 4) which I connect to states the opposite.. That the offending keys (the repeating ones) are not different keys but the same and, as such, can use the same kid.
> 
> Question:
> 
> Which party is correct?
> 
> Thank you for your time,
> 
> Ricardo Pereira
> 
> 
> 
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

v2.23.0 | Report a Bug | By Email