Defaults: Getting concrete

We've had a bunch of abstract debate about defaults, without reaching much in the way of consensus.  So I wanted to put up a straw man for a concrete change to the spec that I think would address the problem of developer-friendliness (at least in the terms I've defined).

The proposal is to make the "key" and "algorithm" parameters optional for the encrypt, sign, and digest methods, and to allow the "algorithm" value to be incomplete.  If "algorithm" is empty or incomplete, then the UA populates it with UA-chosen values.  If "key" is empty, then the UA generates one.

OLD:
"""
1. Let normalizedAlgorithm be the result of processing algorithm according to the algorithm normalizing rules.

2. If normalizedAlgorithm does not describe a registered algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm.
"""

NEW:
"""
1. Let normalizedAlgorithm be the result of processing algorithm according to the algorithm normalizing rules.

3. If the algorithm parameter is null, not present, or incomplete, populate missing fields with UA-chosen values

2. If normalizedAlgorithm does not describe a registered algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm.

4. If the key parameter is null or not present, generate a key using the generateKey method, with the algorithm parameter equal to the algorithm parameter used here, and any other parameters set to UA-chosen values.
"""

Obviously, in order for this to change to be plausible, it needs to be possible for UAs to make choices that are safe under a wide variety of circumstances.  As an existence proof, I went through all the parameters currently in the document and made a list of sensible defaults based on a collection of RFCs and NIST publications.  (We could put something like this in the spec as a recommendation, if people like that idea.)
<http://pastebin.com/mt4XXeHZ>

Ryan: Can you please detail an application where (1) these defaults are harmful, and (2) the application does not otherwise require the developer to have cryptographic clue?

While I was generating the above list, I came across a couple of other bugs, which I will put in separate threads.

Thanks,
--Richard

Received on Monday, 1 April 2013 15:29:52 UTC