Re: Separate method for key agreement?

On Apr 2, 2013, at 2:56 PM, Ryan Sleevi <sleevi@google.com> wrote:

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

Did you have any comment on my "most obvious solution"?  I'm not an expert in multi-party key agreement schemes, so I don't know off the top of my head whether that's a good enough syntax to cover many of them.

As you note below, there's a balance to be struck here between positional / dictionary arguments.  Positional arguments make sense when there's a common abstract interface to a bunch of algorithms.  So the number of methods on window.crypto is roughly equal to the number of logical classes of algorithms out there.  If multi-party key agreement schemes are sufficiently different from bilateral key agreement schemes, then there should be a separate method for them.

You can see a similar compromise in the encrypt() method, where AAD for GCM is stored in the algorithm identifier.  I'm not sure this is the right compromise, since different components of the algorithm identifier have different re-use properties (AAD can be re-used; IV can't).  (Cf. RFC 5083, which has AAD separate from the AlgorithmIdentifier.)  You could imagine creating an AEAD interface, along the lines of RFC 5116. 

--Richard



>> 
>> 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 19:14:49 UTC