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 25387 - BigInteger
Summary: BigInteger
Status: RESOLVED WONTFIX
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-18 08:00 UTC by Anne
Modified: 2014-05-12 08:38 UTC (History)
3 users (show)

See Also:


Attachments

Description Anne 2014-04-18 08:00:15 UTC
Was https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#big-integer reviewed by TC39? Might be worth asking on es-discuss.

Also, since it's a view on an ArrayBuffer, why are you saying it's big-endian? That should not matter with views.
Comment 1 Boris Zbarsky 2014-04-18 15:43:21 UTC
Anne, I don't think this is defining a view.  What this is saying is that the Uint8Array holds the bytes that represent an integer, in big-endian order.

So for example, the representation of 5 million would be a Uint32Array of length three, containing the values 76, 227, 215, since 76*255^2 + 227*255 + 215 = 5000000.  Consumers would be expected to do that sort of computation themselves to reconstruct the integer.  That's why the endianness matters.
Comment 2 Boris Zbarsky 2014-04-18 15:44:56 UTC
> would be a Uint32Array

Uint8Array, of course.
Comment 3 Domenic Denicola 2014-05-09 16:26:10 UTC
I was confused by this too. If you search for "big" in https://github.com/w3ctag/spec-reviews/issues/3 you'll find some back-and-forth where its purpose was clarified.

I think if it were renamed ByteSequence, or just left as Uint8Array, it would be clearer. But it doesn't really matter since it's just a typedef, so I defer to the spec editors as to what they think best balances confusion vs. clarity.
Comment 4 Ryan Sleevi 2014-05-12 05:57:33 UTC
I'm going to close this as WontFix, as the original issue was related to adding the type to TC-39, which we're not trying to do, merely describe a typographic convention and short-hand.

Boris' explanation in Comment 1 is spot on. The proposed wording in Comment 3 (ByteSequence or Uint8Array) isn't ideal, since ByteSequence leaves ambiguity about the structure of the data, and Uint8Array is sometimes-structured-as-BigInt and sometimes-not.

If there are specific proposals on where there is confusion, I'd be happy to revisit and incorporate.
Comment 5 Anne 2014-05-12 08:33:12 UTC
The main problem I think is that you want a bigint, and are inventing one on top of a Uint8Array. Ideally there would at least be some coordination with TC39 so that they know this is going on.
Comment 6 Ryan Sleevi 2014-05-12 08:38:04 UTC
(In reply to Anne from comment #5)
> The main problem I think is that you want a bigint, and are inventing one on
> top of a Uint8Array. Ideally there would at least be some coordination with
> TC39 so that they know this is going on.

This isn't really accurate, for the reasons explained on https://github.com/w3ctag/spec-reviews/issues/3#issuecomment-41630590

This WG has spent a lot of time debating BigInteger - whether it's a first class type or not. You can see in the archives a previous proposal by Microsoft during the eBay/PayPal F2F that demonstrated a number of problems with trying to describe BigInteger for cryptographic operations.

As explained during the W3C TAG review, the typedef here is to annotate a binary format (akin to the ASN.1 DER-encoding of SPKI/PKCS#8)

If you're performing cryptographic operations using these, then we've failed as a WG.