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:[email protected]] On Behalf Of Chuck Mortimore
Sent: Tuesday, August 26, 2014 9:57 AM
To: Manger, James
Cc: [email protected]
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
<[email protected]<mailto:[email protected]>> 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
