[jose] http://www.rfc-editor.org/info/rfc7517

Ahmet Soormally <ahmet@mangomm.co.uk> Wed, 06 May 2020 11:23 UTC

Return-Path: <ahmet@mangomm.co.uk>
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 4EC683A094A for <jose@ietfa.amsl.com>; Wed, 6 May 2020 04:23:32 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MM44Ra7Yy4yP for <jose@ietfa.amsl.com>; Wed, 6 May 2020 04:23:30 -0700 (PDT)
Received: from smtp73.ord1c.emailsrvr.com (smtp73.ord1c.emailsrvr.com [108.166.43.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DF03A0945 for <jose@ietf.org>; Wed, 6 May 2020 04:23:29 -0700 (PDT)
X-Auth-ID: ahmet@mangomm.co.uk
Received: by smtp26.relay.ord1c.emailsrvr.com (Authenticated sender: ahmet-AT-mangomm.co.uk) with ESMTPSA id D4BB5E009E; Wed, 6 May 2020 07:23:28 -0400 (EDT)
X-Sender-Id: ahmet@mangomm.co.uk
Received: from Ahmets-MBP-2.Home ([UNAVAILABLE]. [90.209.122.248]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.7.12); Wed, 06 May 2020 07:23:29 -0400
To: jose@ietf.org
From: Ahmet Soormally <ahmet@mangomm.co.uk>
Cc: ahmet@tyk.io
Message-ID: <47375314-21e1-10c6-ccf7-d71b2a27ba46@mangomm.co.uk>
Date: Wed, 06 May 2020 12:23:27 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-Classification-ID: 1d1d71bd-a7f2-48b9-92f9-36bfa0801ff0-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/XVeD1sLxm_jrsKZ7SPdWdUODKCU>
X-Mailman-Approved-At: Wed, 06 May 2020 06:38:52 -0700
Subject: [jose] http://www.rfc-editor.org/info/rfc7517
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: Wed, 06 May 2020 11:33:27 -0000

Hello Jose,

Hope you are well.

I am writing with regards to proposing a change to rfc7517.

It appears that some identity providers are very purist, and do not
return x5c. It's an optional field.

Whilst other identity providers do provide the x5c certificate.


The x5c certificate is extremely useful. It negates the need for a
library or application to be able to translate the
modulus and exponent.

Many libraries do not support this natively, meaning custom code needs
to be written in order to perform this translation of formats in order
to provide a standardised, interoperable interface & more easily foster
interoperability & federation between multiple IdPs.

https://github.com/asoorm/tyk-go-plugins/blob/master/merge_jwks/merge_jwks.go#L143-L194


It would be great if you could consider making the x5c certificate
mandatory for RSA public keys, or provide any guidance in this regard.


For example, as an API Gateway, I need to be able to support obtaining
JWT public keys from the jwks_uri. and if each IdP does it differently,
then this puts the onus on the gateway to perform the translation, where
it could be very easily implemented at the issuer of the certificate's
side. Further, it will ensure separation of concerns, where the gateway
doesn't need to perform these operations, because the required data is
already presentable in a consistent format.

The certificate issuer will only ever need to update the certificates
upon rotation. But the client using them will need to perform the
translation every time.


With thanks

Ahmet