Re: Separate method for key agreement?

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.

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.

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






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

> Richard,
> 
> Your proposal does not seem to address multi-party key agreement scenarios, where the original does.
> 
> How would you propose to address them?
> 
> 
> On Tue, Apr 2, 2013 at 9:26 AM, Acar, Tolga <tolga.acar@intel.com> wrote:
> I'd side with Richard in separating key agreement and key derivation into separate APIs, similar to CNG's approach. There are protocols, such as TLS, more than one symmetric key is derived from an agreed-upon (or transported) secret Z. Combining KDFs with agreement would minge these together; that doesn't seem like a primitive/low-level API, but gets close to being coupled with a protocol. Recalling the other high/low level API discussion, I am suggesting the low-level approach here, and a higher level API, if one is compelled to do so, can be built on it.
> 
> - Tolga
> 
> > -----Original Message-----
> > From: Richard Barnes [mailto:rbarnes@bbn.com]
> > Sent: Tuesday, April 02, 2013 9:11 AM
> > To: Vijay Bharadwaj
> > Cc: Wan-Teh Chang; Ryan Sleevi; public-webcrypto@w3.org Group
> > Subject: Re: Separate method for key agreement?
> >
> > I don't think I had worked out the details that far :)
> >
> > The "derivedKeyType" is perhaps misleading (copy/paste error).  I didn't
> > mean to imply that derivation would be included in this method.  You would
> > actually need another field to specify the KDF, since "derivedKeyType"
> > indicates the algorithm that the new key is to be used with, not the KDF.
> >
> > I actually think it would be simpler to have this just be the secret agreement,
> > then do key derivation with deriveKey().  Using a secret handle isn't an issue
> > here; you get back a Key object, which is essentially a secret handle anyway.
> >
> > Yet another case where a Promises-style API would be nice to have...
> >
> > let derive = function(key) {
> >   window.crypto.deriveKey(..., key, ...); }
> > window.crypto.agreeKey(...)
> >   .then(derive)
> >   .then(doStuff);
> >
> > --Richard
> >
> >
> > On Apr 2, 2013, at 4:57 AM, Vijay Bharadwaj
> > <Vijay.Bharadwaj@microsoft.com> wrote:
> >
> > > Windows CAPI is unique in its handling of DH. It is not a great example to
> > emulate.
> > >
> > > CNG is a better example. As I understand it, the proposal below combines
> > the secret agreement and key derivation steps (which are distinct in CNG)
> > into a single step. This seems like a good idea - CNG has to use a secret
> > handle to allow the caller to link these two steps without exposing the raw
> > secret, but this would be harder to do neatly in JS. Am I understanding the
> > proposal correctly?
> > >
> > > -----Original Message-----
> > > From: Wan-Teh Chang [mailto:wtc@google.com]
> > > Sent: Monday, April 1, 2013 5:45 PM
> > > To: Ryan Sleevi
> > > Cc: Richard Barnes; public-webcrypto@w3.org Group
> > > Subject: Re: Separate method for key agreement?
> > >
> > > On Mon, Apr 1, 2013 at 12:25 PM, Ryan Sleevi <sleevi@google.com> wrote:
> > >>
> > >> I'm not sure I'd agree here. Do you also see separate functions for
> > >> ECDH agreement?
> > >
> > > No.  The function that Richard proposed can handle both DH and ECDH:
> > >
> > > """
> > > KeyOperation agreeKey(Key privateKey,
> > >                      Key publicKey,
> > >                      AlgorithmIdentifier? derivedKeyType,
> > >                      bool extractable = false,
> > >                      KeyUsage[] keyUsages = []); """
> > >
> > > Richard's proposal is consistent with Windows CNG:
> > > http://msdn.microsoft.com/en-
> > us/library/windows/desktop/aa833130(v=vs.
> > > 85).aspx
> > >
> > > Note: Windows CAPI does Diffie-Hellman in a non-obvious manner (using
> > CryptImportKey), so Widows CAPI is not worth being consistent with:
> > > http://msdn.microsoft.com/en-
> > us/library/windows/desktop/aa381969(v=vs.
> > > 85).aspx
> > >
> > > Wan-Teh
> > >
> > >
> >
> 
>

Received on Tuesday, 2 April 2013 18:49:54 UTC