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

Jim Schaad <ietf@augustcellars.com> Wed, 06 May 2020 20:37 UTC

Return-Path: <ietf@augustcellars.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 6BE813A0B0B for <jose@ietfa.amsl.com>; Wed, 6 May 2020 13:37:12 -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 NOGIX5KwcqVA for <jose@ietfa.amsl.com>; Wed, 6 May 2020 13:37:08 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342423A0B0A for <jose@ietf.org>; Wed, 6 May 2020 13:37:08 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 6 May 2020 13:36:56 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ahmet Soormally' <ahmet@mangomm.co.uk>, jose@ietf.org
CC: ahmet@tyk.io
References: <47375314-21e1-10c6-ccf7-d71b2a27ba46@mangomm.co.uk>
In-Reply-To: <47375314-21e1-10c6-ccf7-d71b2a27ba46@mangomm.co.uk>
Date: Wed, 06 May 2020 13:36:53 -0700
Message-ID: <044301d623e6$15925490$40b6fdb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFQ178LUWsk/YODV4erWxRC4LrQZamlyx7w
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/2UCUeQTjtL7J7aQ2Ve4tz1rKhZ4>
Subject: Re: [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 20:37:13 -0000

This is not something that could really be done.  While you are using this
in an environment that is using certificates, there are other environments
where certificates are not being used at all.  Making it required would
cause these use cases to be impossible to use.

Additionally, the JOSE working group is no longer an active working group.
Any such change would require some process steps in the IETF as well.  Such
an effort would require some minimum number of individuals who also wanted
to see this done.

Jim


-----Original Message-----
From: jose <jose-bounces@ietf.org> On Behalf Of Ahmet Soormally
Sent: Wednesday, May 6, 2020 4:23 AM
To: jose@ietf.org
Cc: ahmet@tyk.io
Subject: [jose] http://www.rfc-editor.org/info/rfc7517

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.g
o#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


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose