Re: Separate method for key agreement?

On Tue, Apr 2, 2013 at 11:49 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> Good question.
>
> Are you saying that a multi-party scheme would be supported by having appropriate attributes in the AlgorithmParameters structure for that algorithm?  I just ask because there aren't any multi-party schemes in the current spec.

Yes.

>
> The most obvious solution that comes to my mind is to allow the "publicKey" argument to be an array.  So you would have "privateKey" to represent the stuff you hold locally (your contribution to the multi-party system), and everyone else's contributions would go into the "publicKey" array.
>
> That said, it seems like bilateral key agreement is the 80% solution here, so I wouldn't rule out just punting on multi-party, with the idea that we could add a separate method for that later if a suitable abstraction is apparent.

That's a sign of a bad API / API smell then.

I'm not trying to fit everything under the sun here, nor to fit all of
the unknown-unknowns, but I am trying to show that the API we have now
IS robust enough to accommodate some of the known-knowns here, whereas
the counter proposal is less so.

>
> If you want to get really crazy, you could move away from positional arguments entirely, and have a two-argument form:
>
> KeyOperation agreeKey( AlgorithmIdentifier algorithm,
>                        KeyAttributes attributes );
>
> dictionary EcdhKeyDeriveParams : AlgorithmParameters{
>   // The local EC private key.
>   Key private;
>   // The peer's EC public key.
>   ECPoint public;
> };
>
> That would sweep all of the parameters for the crypto computation -- including all the keys -- into the algorithm identifier, giving the algorithm latitude to do what you want.   Of course, if you take this idea to its logical extreme, you could just have each method take as input a JS dictionary:
>
> window.crypto.encrypt({
>   name: "AES-CBC",
>   iv: /* ABV */,
>   key: /* Key object */,
>   plaintext: /* ABV */
> });
>
> That begins to look suspiciously like a JOSE API, though.  Whether that's a bug or a feature might depend on the observer :)
>
> --Richard

I could not disagree more about the comparison to a JOSE API.

That said, there are Web APIs that have done the entirely positional
route, and others that have gone the entirely dictionary route.

The current API straddles the middle, in that it treats as positional
all of the parameters that should exist *regardless* of the operation,
then uses dictionaries for all parameters that may vary per-operation.

This is inconsistency is consistent with the existing and proposed web
APIs of WebApps. Proposing a pure-dictionary approach is something
that should, IMO, only be done in consultation with TAG and WebApps -
and not simply proposed because it's prettier/convenient. I don't have
strong objections to it, if only because I don't know the full
considerations at play and thus don't feel qualified to firmly support
or oppose, but, respectfully, I am pretty convinced that no one else
in this group knows those full considerations either - hence the TAG &
WebApps suggestion.

Cheers

Received on Tuesday, 2 April 2013 18:56:45 UTC