- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Fri, 25 Oct 2013 14:06:24 +0300
- To: public-webcrypto-comments@w3.org
The abstract of https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html says: > This specification describes a JavaScript API for > performing basic cryptographic operations in web > applications, such as hashing, signature generation > and verification, and encryption and decryption. > Additionally, it describes an API for applications > to generate and/or manage the keying material > necessary to perform these operations. Uses for > this API range from user or service authentication, > document or code signing, and the confidentiality > and integrity of communications. It then goes on to specify a generic interface to crypto primitives and a bunch of primitives. Clearly, some of the primitives are redundant for the purpose of creating new application-specific protocols. For example, if you're creating a new application-specific protocol, you don't need the whole smorgasbord of AES modes including the old ones that are considered less good than the new ones, since for a new application-specific protocol, you should probably just use the latest good stuff. Therefore, it seems that the inclusion of some algorithms is motivated by backwards compatibility with existing systems rather than having the best primitives under the best current knowledge for the purposes mentioned in the abstract. The spec sort of acknowledges this but the acknowledgment is buried in the Security Considerations and does little to help readers to distinguish what parts are known-bad but included for backwards compatibility with existing systems and what parts you are supposed to be using in cases where you aren't encumbered by legacy systems: > This API includes a variety of cryptographic > operations, some of which may have known > security issues when used inappropriately. > Application developers should take care to > review the appropriate cryptographic > literature before making use of certain > algorithms, and should avoid attempting > to develop new cryptographic protocols > whenever possible." Of course, wordsmithing the spec doesn't help when users of the API don't read the spec, but I still think it would be appropriate to make the abstract position the spec in a way that better matches the warning from the Security Considerations section. Although technically code that uses an API counts as an "application" from the perspective of the API, since the Web Crypto API provides a set of low-level primitives that are potentially dangerous is misused, I think it would be appropriate to make the abstract position the API to be used by crypto-expert developers of higher-level libraries as opposed to being used by developers of "Web applications" directly. I suggest making the abstract say something along the lines of: "This specification describes a JavaScript API for invoking low-level cryptographic primitives such that experts familiar with the primitives can use them to build higher-level libraries for application developers. Additionally, the specification describes an API for generating and/or managing the keying material necessary to use the cryptographic primitives. Higher-level uses of the primitives provided by this API include user or service authentication, document or code signing and the confidentiality and integrity of communications. -- Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/
Received on Friday, 25 October 2013 11:06:55 UTC