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

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

--- Comment #3 from Eric Roman <ericroman@google.com> ---
Thanks for the response Ryan!

I agree this may be more relevant to just publicExponent rather than BigInteger
in its general use. I am also fine with leaving things as they are for the
resolution.

That said I think the argument for disallowing it is inconsistent with our use
of numbers elsewhere in WebCrypto.

 > "it would also allow things like "65537" or "no" to be accepted as inputs,"

Correct.

I agree with you this is completely bonkers. Nevertheless this is idiomatic
Ecmascript/WebIDL, and a behavior that callers expect. Moreover it is a
behavior that WebCrypto inherits elsewhere for places that take numbers.

If we are going to argue that Ecmascript/WebIDL deals with numbers poorly
(which I wholeheartedly agree with), then we need to look carefully at other
places which already inherit this unsafe behavior for security critical
parameters.

Why should it be OK for other parameters to have this unsafe behavior, and yet
not BigInteger?

For instance key lengths, modulus sizes, a KDF's iterations, salt length, etc
are all taken as numbers, and can be abused in the same manner. Should we not
then disallow unsafe integer casting here too? For instance if you call PBKDF2
with "iterations: false" implementations will happily set iterations to 1. Or
worse if you call "iterations: null", we will set iterations=0 (in fact I need
to follow-up on this behavior in implementations...)

Admittedly supporting a union allows for more incorrect usages (all the ways
Ecmascript's ToNumber() lets you shoot a hole in your foot). The one that
concerns me more is the handling of null, since it seems an easy mistake to
pass an (accidentally) null uint8array, and now that would be auto-magically
interpreted as 0.

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

Received on Tuesday, 22 September 2015 20:04:50 UTC