Re: Defaults: Getting concrete

I think it's a bad API design where the failure to properly specify
parameters results in an entirely new key being generated - especially if
key generation is expensive.

Strong -1 to Step (4). Let's not violate the "Principle of Least Surprise"



On Mon, Apr 1, 2013 at 11:51 AM, Richard Barnes <rbarnes@bbn.com> wrote:

> 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
> >
>
>
>