- From: <bugzilla@jessica.w3.org>
- Date: Tue, 22 Sep 2015 20:19:05 +0000
- To: public-webcrypto@w3.org
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