According to a crypto expert who spoke up at an in-person JOSE meeting when
this was discussed (I think it was Russ Housley), the high-order bit of a
correctly formed RSA mantissa must always be 1. (If it weren't then the key
pair would contain less than the required number of bits of information.)
Thus, there are no leading zeroes to strip, for what it's worth.
Also the value is unsigned, not signed.
Best wishes,
-- Mike
-----Original Message-----
From: jose [mailto:[email protected]] On Behalf Of Berry, Matt
Sent: Monday, April 14, 2014 2:36 PM
To: [email protected]
Subject: [jose] Question about minimual unsigned big endian representation of
JWK parameters
Throughout JWA Section 6.3 "Parameters for RSA Keys" the following phase occurs
repeatedly:
> The octet sequence MUST utilize the minimum number of octets to represent the
> value.
I understand the rationale for such a phase, which is to minimize the overall
size of JWKs.
This is a core tenant of the JSOE working group. However I have concerns about
the practice of striping leading zeroes from RSA parameters.
The benefit of stripping these leading zeroes is likely negligible. Consider
this RSA key I just generated (included below). The total benefit of stripping
the leading zeroes is 5 bytes before base64 encoding.
Although I believe the attempt to reduce the overall size of the JWK is
commendable, I think this will introduce more confusion and non-compliance than
anything. An example would be Google, who currently does not strip the leading
zeroes (or even base64url-encodes).
> https://www.googleapis.com/oauth2/v2/certs
I suggest rewording relevant sections to the following, to allow for the
minimum amount of padding octets required to make the keys unambiguous.
> The octet sequence MUST utilize the minimum number of octets to
> represent the value as if it was a signed integer.
Sincerely,
Matt Berry
== The referenced RSA Private key. ==
Generating RSA private key, 2048 bit long modulus
.........................................................+++
..................................+++
e is 65537 (0x10001)
Private-Key: (2048 bit)
modulus:
00:ba:5c:82:f9:26:34:e3:4b:e3:d2:d4:81:5a:c6:
...
publicExponent: 65537 (0x10001)
privateExponent:
00:9d:23:3c:5c:90:d6:af:81:62:0c:77:9a:ca:cb:
...
prime1:
00:ee:b8:c9:5f:ca:8d:9e:1a:a8:9b:6c:34:2f:c4:
...
prime2:
00:c7:d9:8d:57:17:6c:a4:46:1a:9a:c0:2d:93:da:
...
exponent1:
54:c8:b4:5c:9d:27:e6:fb:38:de:da:73:3e:74:08:
...
exponent2:
00:c7:7f:c6:f6:5f:ad:d6:37:1d:2b:ca:18:35:76:
...
coefficient:
74:a4:07:7c:4f:04:be:40:62:2e:af:ff:37:b5:9d:
...
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
