Re: Defaults: Getting concrete

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
>