Re: [jose] JWK glitches in deployment

Mike Jones <Michael.Jones@microsoft.com> Tue, 23 September 2014 23:47 UTC

From: Mike Jones <Michael.Jones@microsoft.com>
To: Chuck Mortimore <cmortimore@salesforce.com>, "Manger, James" <James.H.Manger@team.telstra.com>
Thread-Topic: [jose] JWK glitches in deployment
Thread-Index: Ac/A+eKYNRa6AT3ORduHKtSlXvbGfAAVNPiAA2XPkdACKKIH8A==
Date: Tue, 23 Sep 2014 23:46:14 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6F745@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <255B9BB34FB7D647A506DC292726F6E127C6DE46FD@WSMSG3153V.srv.dir.telstra.com> <CA+wnMn_PO5i-A4AK2CYG-XHOgUti5R6yMPMiTH4yoH7M=iXdEA@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AEC345E@TK5EX14MBXC292.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEC345E@TK5EX14MBXC292.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6F745TK5EX14MBXC286r_"
MIME-Version: 1.0
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com;
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Rpvm0-6us_yxa-1YYyd13UlZUx0
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] JWK glitches in deployment
Precedence: list

This note to implementers has been added to the -32 draft.

                                                                -- Mike

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, September 12, 2014 5:05 PM
To: Chuck Mortimore; Manger, James
Cc: jose@ietf.org
Subject: Re: [jose] JWK glitches in deployment

I propose that we add this note to the text describing the RSA modulus representation to help implementers, as Chuck suggested below:

                      Note that implementers have found that some cryptographic libraries
                      prefix an extra zero-valued octet to the modulus representations they return,
                      for instance, returning 257 octets for a 2048 bit key, rather than 256.
                      Implementations using such libraries will need to take care to omit
                      the extra octet from the base64url encoded representation.

                                                                -- Mike

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Tuesday, August 26, 2014 9:57 AM
To: Manger, James
Cc: jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: [jose] JWK glitches in deployment

We probably could have benefited from language in the spec calling out the leading zero byte as an area of concern.    That said our ecosystem detected it pretty quickly and after some collaborate with Microsoft, we have a fix due out this week, so the growing pains are sorting themselves out rather quickly.

-cmort

On Mon, Aug 25, 2014 at 11:49 PM, Manger, James <James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>> wrote:
In March, Google’s JWK file https://www.googleapis.com/oauth2/v2/certs (used for OpenID Connect) had 3 bugs: base64 instead of base64url; 1024-bit instead of >=2048-bit; leading zero byte on moduli.
Today Google’s JWK file has 1 different bug: the base64url encoding has a trailing “=”.
Salesforce’s JWK file https://login.salesforce.com/id/keys has 1 bug: a leading zero byte on the RSA moduli.

Are these just teething problems, or do we need a stronger warning in the spec. These bugs also change the JWK’s thumbprint (another reminder not to base security on thumbprints being unique for a given key).

--
James Manger

[jose] JWK glitches in deployment Manger, James
Re: [jose] JWK glitches in deployment Chuck Mortimore
Re: [jose] JWK glitches in deployment Mike Jones
Re: [jose] JWK glitches in deployment Mike Jones