(In reply to Franz Antesberger from comment #0)
> 16. BigInteger reads "A leading zero Uint8 element is not needed if the most
> significant bit of the integer is set."
> Shouldn't it be the other way around,
> "A leading zero Uint8 element is not needed if the most significant bit of
> the integer is NOT set."

I don't think that sentence is required at all. The rest of the definition is unambiguous, although "multiple-precision" could be replaced with "arbitrary magnitude" (integers have exactly the 'precision' that they have, nothing else).

We have two things to be considered:
1) What do we need for a minimum?
2) What do all the others?
First to 2)
All the others (bouncy castle, openssl)
- use big endian (as here)
- use leading zeros, when the high bit is set
- leading zeros are done bytewise, not wordwise
2nd to 1)
what should we do here?
- I think, BigInteger should be bound to ArrayBuffer, not to Uint8Array. Calculation with Uint32Arrays is MUCH faster.
- big endian is nice, but all the BigInt-Libs I know use little endian, is that an issue? We could easily build a wrapper
- X.509 Certificates use little endian, byte arrays and leading zeros, if high byte >= 0x80.

I completely agree with your "multiple-precision" argument.

I think, we have two ways:
a) we could replace "BigInteger" with "BigUnsignedInteger" -- then no leading zeros are needed. But the name does not sound well.
b) we could use "BigInteger", but then please with leading zeros, if leading >= 0x80.

I will try to make a complete proposal for this chapter next weekend

(In reply to Franz Antesberger from comment #2)
> We have two things to be considered:
> 1) What do we need for a minimum?
> 2) What do all the others?
> First to 2)
> All the others (bouncy castle, openssl)
> - use big endian (as here)
> - use leading zeros, when the high bit is set
> - leading zeros are done bytewise, not wordwise
> 2nd to 1)
> what should we do here?
> - I think, BigInteger should be bound to ArrayBuffer, not to Uint8Array.
> Calculation with Uint32Arrays is MUCH faster.
> - big endian is nice, but all the BigInt-Libs I know use little endian, is
> that an issue? We could easily build a wrapper
> - X.509 Certificates use little endian, byte arrays and leading zeros, if
> high byte >= 0x80.
> 
> I completely agree with your "multiple-precision" argument.
> 
> I think, we have two ways:
> a) we could replace "BigInteger" with "BigUnsignedInteger" -- then no
> leading zeros are needed. But the name does not sound well.
> b) we could use "BigInteger", but then please with leading zeros, if leading
> >= 0x80.
> 
> I will try to make a complete proposal for this chapter next weekend

- it seems safer to stick with big endian, since that is what we have had since the beginning
- switching to ArrayBuffer is another issue (I filed bug 24409)
- I don't understand the need for the leading 0x00 - it just introduces an error case that need not exist. I do understand why we might want to highlight to implementors that the top bit is not a sign bit, because this is an unsigned integer. A note would be sufficient for this, rather than a normative requirement.

I propose replacing the existing text of this section with:

"The BigInteger typedef is a Uint8Array that holds a arbitrary magnitude unsigned integer in big-endian order.

Implementation note: Since the integer is unsigned, the highest order bit is NOT a sign bit. Implementors should take care when mapping to big integer implementations that expected signed integers."

As discussed on call 1/27, we will require values read from the API to be in cannonical (most compact) form and will be tolerant of leading zero bits when values are passed to the API:

"The BigInteger typedef is a Uint8Array that holds a arbitrary magnitude unsigned integer in big-endian order. Values read from the API SHALL have minimal typed array length (that is, at most 7 leading zero bits). The API SHALL accept values with any number of leading zero bits.

Implementation note: Since the integer is unsigned, the highest order bit is NOT a sign bit. Implementors should take care when mapping to big integer implementations that expected signed integers."

As discussed on call 1/27, we will require values read from the API to be in cannonical (most compact) form and will be tolerant of leading zero bits when values are passed to the API:

"The BigInteger typedef is a Uint8Array that holds a arbitrary magnitude unsigned integer in big-endian order. Values read from the API SHALL have minimal typed array length (that is, at most 7 leading zero bits, except the value 0 which shall have length 8 bits). The API SHALL accept values with any number of leading zero bits.

Implementation note: Since the integer is unsigned, the highest order bit is NOT a sign bit. Implementors should take care when mapping to big integer implementations that expected signed integers."

https://dvcs.w3.org/hg/webcrypto-api/rev/33a21d9f624a

I think, it is a bad idea to restrict to unsigned -- there are a lot of funny things you can do with the Chineese Reminder Theorem, but there you need signed integers.
And I think, it is a worse idea, calling it "BigInteger", when it is unsigned. All the Typed Arrays use a "U", when unsigned. So if restricting to unsigned, it should be renamed to "BigUInteger". One day we might need signed BigIntegers.
For now we just store RSA-Keys, which really are unsigned

The leading zeros come from the ASN.1 INTEGER type, see e.g. http://luca.ntop.org/Teaching/Appunti/asn1.html

(In reply to Franz Antesberger from comment #8)
> I think, it is a bad idea to restrict to unsigned -- there are a lot of
> funny things you can do with the Chineese Reminder Theorem, but there you
> need signed integers.
> And I think, it is a worse idea, calling it "BigInteger", when it is
> unsigned. All the Typed Arrays use a "U", when unsigned. So if restricting
> to unsigned, it should be renamed to "BigUInteger". One day we might need
> signed BigIntegers.
> For now we just store RSA-Keys, which really are unsigned
> 

I think you should raise a new bug "Make BigInteger signed or rename it" for this issue.

> The leading zeros come from the ASN.1 INTEGER type, see e.g.
> http://luca.ntop.org/Teaching/Appunti/asn1.html

Done, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24430