[Bug 29139] Allow specifying numbers in place of BigInteger?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29139

--- Comment #4 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Eric Roman from comment #3)
> Why should it be OK for other parameters to have this unsafe behavior, and
> yet not BigInteger?

So, while I agree "JS Numbers are awful" (at least, from my POV, which is often
wrong), a big motivation here with the explicit BigInteger type not having
numeric conversions was about ensuring a consistent developer experience about
"When is the right time to use a primitive Number versus a BigInteger". That
is, how does one know that "65537" will not run in to any conversion issues
with an implementation (ok, this is a bad example, but given the definition of
Number from ES6 is
http://www.ecma-international.org/ecma-262/6.0/#sec-terms-and-definitions-number-value
, it is a valid concern about 'integral' representations)

The design consideration for "When to use a number" and "When to use a
BigInteger" - relevant for examples like key size vs exponent - was predicated
based on "What is most aligned to the underlying type". In this case, since the
RSA exponent is arbitrary precision, it was exposed as such, 'even though' the
most commonly-used values will be within the range of an [EnforceRange]'d
unsigned long.

I won't lie, in many ways, I tried to suggest a design that was most aligned to
the underlying types, rather than an opinionated design. That's because my
opinions are usually awful, but I also feel the same way about the opinions of
most cryptography API designers, and since we were going for something at the
'subtle', low-level, 'correct' API, I erred on the side of type accuracy rather
than developer convenience.

While I think WebRTC's exposure of/reuse of AlgorithmIdentifier is perhaps
*too* low-level for their use case (especially as they suggest MTI), my hope is
that in practice, few developers actually run in to these issues, as they are
handled by libraries that compose the underlying subtle primitives into safe,
easy to use constructs appropriately narrow for the use cases and users of said
libraries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 22 September 2015 20:19:07 UTC