Re: Defaults: Getting concrete

Definitely.  Good idea.  (IMHO, (i) is much more important than (ii).)

(i) corresponds to adding step (3) below
(ii) corresponds to adding step (4) below





On Apr 1, 2013, at 2:39 PM, Mark Watson <watsonm@netflix.com> wrote:

> Richard,
> 
> Can we address this as two proposals: (i) defaults for operation parameters and (ii) automatic key generation ?
> 
> (i) is simply a matter of whether operation parameters can be left out in the method call, to be filled in by the UA
> 
> (ii) requires all the key-using operations to accept all the key-generation parameters. I'd prefer the simplification that I proposed on another thread, where we separate parameters for key-using operations and key-generation. Since the developer who omits the key parameter to an operation is going to need to specify the key-generation parameters anyway, it seems cleaner if they are required to specify those in an explicit generateKey call.
> 
> ...Mark
> 
> On Mon, Apr 1, 2013 at 8:29 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> 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 18:52:07 UTC