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