- From: <bugzilla@jessica.w3.org>
- Date: Tue, 01 Jul 2014 14:59:10 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607 --- Comment #26 from Mark Watson <watsonm@netflix.com> --- I believe I have commented before, so perhaps this does not answer Mark's request for comments from other WG members, but anyway. First, the tone of discussion in this thread isn't exactly calculated to encourage participation. I don't see much evidence of either party acknowledging the points made by the other. There are valid points on both sides and it doesn't seem like it should be beyond us to construct a compromise that respects those points that are valid. On the one hand, cryptography is like dynamite - it can move mountains but also bring one down on your head. It should come with a clear warning labels, especially when it is known that certain things can explode in certain unexpected ways. On the other hand, our specification places normative requirements on the implementors of the specification, not on the users of the API. RFC2119 normative language with respect to the users of the API ('SHOULD not use...') makes no sense. It also makes no sense to refer to algorithms that are not supported at all by the specification. The specification should take great care not to mislead people into thinking that the dynamite is safe if only they follow our simple instructions. Providing 'simple instructions' (for example a classification of 'safe' and 'unsafe' algorithms) is not only dangerous but, as Ryan has explained, extremely difficult to do with any degree of rigor. Any classification is highly application-dependent, nuanced and ultimately a matter of opinion (albeit well-respected opinion). Ryan has provided a number of 'warning labels' in the specification. In my opinion, the remainder of this bug could be best addressed by: (1) avoiding any attempt to summarize or simplify but instead provide direct references to the state-of-the-art with respect to the algorithms we support. Users of the API should be left in no doubt that they *need to understand* this material in all its gory detail in order to use the API with any degree of confidence (2) do (1) in informative text, in a separate document that is clearly referenced from the API specification We could also make it clearer in the specification that suggestions for implementors are NOT intended to be suggestions for users of the API and be very explicit that the API supports some algorithms with known weaknesses for the purpose of implementing legacy protocols and that users should study the document mentioned above before making algorithm choices. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 1 July 2014 14:59:11 UTC