[OAUTH-WG] Clarification on validation of the "x5c" parameter in JWKS

Yakov Shafranovich <yakov@nightwatchcybersecurity.com> Fri, 25 September 2020 14:04 UTC

Return-Path: <yakov@nightwatchcybersecurity.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 9ECA13A0E23 for <oauth@ietfa.amsl.com>; Fri, 25 Sep 2020 07:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 8zB4NWv9FXKH for <oauth@ietfa.amsl.com>; Fri, 25 Sep 2020 07:04:40 -0700 (PDT)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 157A73A0E28 for <oauth@ietf.org>; Fri, 25 Sep 2020 07:04:40 -0700 (PDT)
Received: by mail-pj1-x102a.google.com with SMTP id t7so1908200pjd.3 for <oauth@ietf.org>; Fri, 25 Sep 2020 07:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=BYpYngNWtnXOsh5Ou8lIatJR3fNfOBV3bNe7pE1WQzQ=; b=DrjAYBz6uCd0zDieLeAa8vXaMAj5MDQm0+5ud4pHNpcUhi1aAmYS7rYLcsVvfHTDM3 YlyIoy5+V9waPSmb4TF7F+2lEtwOSbQ4JejnBcsCKLS+qsOT4nvpfz5vgd0Wni/B4IiL KbEvBX+BUUKDReLKBrh6930VgUFkGM0CCjxGyf5ZMzVyYo5iEzh63Co9j3fTWi78e5Ci e5WZ2RdbWhZcWwj7Xjc6/F90QoN/CsnoKHKboAJ/d5fS63ajfz4nCD+XtSGnBnUFbHLA un4Jk3tBP1lfi16yaQiaPhvQdJXz8hQEPTjs/S9aPIzGJqks93q+gtK9ERPrmtbM0PS+ zJDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BYpYngNWtnXOsh5Ou8lIatJR3fNfOBV3bNe7pE1WQzQ=; b=c4KvBm8NikTqlnC50WYbqZMIylYFaX/C4WJwLSHZM38QMoG8PerTD08IMt4DzjjgdI S9iOGJHRsHzKr6l9cEHaj4LrAR7ANIkC6nGYFmVEYB8liGEw5USRm0/yJzoLYi+wxj7r HVUDMgJNZ3LkWrDB6RYx9/F8tV+vXPHEw3fJcapBEEQTwjYTkJ65rK1K4Bg7meP3jmac 5cvfBDRqunb/VivC02R87FYpvHm6W6Kp90lOac2lkVhDK8phbpB+daPxoIDEyKYVX4BT LA1D3VnSbGJguY2PYra6Z3TZ7irgnbYfwFoc/laHvkjBGG1Cst7C4jQFohH43fnANsXQ piZg==
X-Gm-Message-State: AOAM533nL6gMtrI2sr2sldu+w2nPWlLfzM7oYpNd4StlnfJFKyPy7IoP xAkVd40B7eWout0JHoM1pZkKSYTHivAtRECUVfuniJrI8hw2ig==
X-Google-Smtp-Source: ABdhPJzAItRypU9yXHF29DbDMyFkrBh/Q9latwR9b36+YAGZZl9k1kmlkYdxFrtRVJguha3DBEbgzEUhvG1Nq8hoVXU=
X-Received: by 2002:a17:90a:bc8d:: with SMTP id x13mr446864pjr.229.1601042678843; Fri, 25 Sep 2020 07:04:38 -0700 (PDT)
MIME-Version: 1.0
From: Yakov Shafranovich <yakov@nightwatchcybersecurity.com>
Date: Fri, 25 Sep 2020 10:04:03 -0400
Message-ID: <CAAyEnSNHJW+bybP5MMJbpSvu5-uHoVpujbQPqVD19vFvdJBDCA@mail.gmail.com>
To: oauth@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/sMUFAtq8rfs5D9on4z-LvdfMLBY>
Subject: [OAUTH-WG] Clarification on validation of the "x5c" parameter in JWKS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 25 Sep 2020 14:04:42 -0000

Hi,

I am trying to reconcile the security guidance provided by RFC 7517
and RFC 8725. My question is how to validate a key received from a
JWKS endpoint if it contains a "x5c" parameter. In RFC 8725, section
3.8 it states:
https://www.rfc-editor.org/rfc/rfc8725.html#name-validate-issuer-and-subject

"When a JWT contains an "iss" (issuer) claim, the application MUST
validate that the cryptographic keys used for the cryptographic
operations in the JWT belong to the issuer. If they do not, the
application MUST reject the JWT.

The means of determining the keys owned by an issuer is
application-specific. As one example, OpenID Connect [OpenID.Core]
issuer values are "https" URLs that reference a JSON metadata document
that contains a "jwks_uri" value that is an "https" URL from which the
issuer's keys are retrieved as a JWK Set [RFC7517]. This same
mechanism is used by [RFC8414]. Other applications may use different
means of binding keys to issuers."

However, RFC 7517, section 9.1 states:
https://tools.ietf.org/html/rfc7517#section-9

"For instance, the creator of a JWK can include a PKIX certificate in
the JWK's "x5c" member.  If the application validates the certificate
and verifies that the JWK corresponds to the subject public key in the
certificate, then the JWK can be associated with the attributes in the
certificate, such as the subject name, subject alternative   names,
extended key usages, and its signature chain."

My confusion is due to the fact that there are two certificates that
are in play here:
- Certificate A: used to secure the TLS connection for the JWKS endpoint
- Certificate B: used within the "x5c" attribute of the key within JWKS

The two examples in RFC 8725 seem to imply that it is sufficient to
validate the subject name of "certificate A" against the  "jwks_uri"
then trust the key material. However, in RFC 7517, it seems that
"certificate B" needs to be validated as well but it doesn't say how
to verify that "the JWK corresponds to the subject public key in the
certificate".

Thank you