This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27591 - Must the reflected "publicExponent" for generated RSA keys exactly match input?
Summary: Must the reflected "publicExponent" for generated RSA keys exactly match input?
Status: RESOLVED MOVED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-12 02:56 UTC by Eric Roman
Modified: 2016-05-24 00:04 UTC (History)
3 users (show)

See Also:


Attachments

Description Eric Roman 2014-12-12 02:56:46 UTC
The Generate key operation for RSASSA-PKCS1-v1_5 says:

7. Set the publicExponent attribute of algorithm to equal the publicExponent attribute of normalizedAlgorithm.

I am unsure if this implies that publicExponent is a normalized BigInteger or not.

The section on BigIntegers says that "Values read from the API SHALL have minimal typed array length"

Does this assignment count as such a "read"?

Example:

If generateKey() is called with publicExponent = 00000000000000010001, an implementation should be able to reflect key.algorithm.publicExponent as 010001 and not preserve the zeros.
Comment 1 Eric Roman 2014-12-12 03:01:16 UTC
By comparison, the importKey operation is a bit clearer on this as it says:

"Set the publicExponent attribute of algorithm to the BigInteger representation of the RSA public exponent."

(Keys imported from format="jwk" can't have leading zeros in the public exponent, however those from format="pkcs8" or "spki" could I believe)
Comment 2 jimsch 2016-03-04 03:29:31 UTC
I have do not know what is meant by the phrase "read from the API".  If I was going to guess, I would say that it applies to any value returned to the user from the API.  Thus in step 7 there would be an implied normalization of the BigInteger value to remove any leading zero bytes.

Yes you are correct that the exponent could in theory have a leading zero value if this is needed to make sure that it does not look like a negative number as ASN.1 only encodes signed numbers.  I would assume that this leading byte would be stripped in this case as well.
Comment 3 Mark Watson 2016-05-24 00:04:34 UTC
Moved to https://github.com/w3c/webcrypto/issues/61