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
- [jose] http://www.rfc-editor.org/info/rfc7517 Ahmet Soormally
- Re: [jose] http://www.rfc-editor.org/info/rfc7517 Jim Schaad
- Re: [jose] Consensus call on charter for JSON Web… nadalin