Abstract doesn't highlight the need of crypto expertise to use the Web Crypto API directly

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