Separate method for key agreement?

• From: Richard Barnes <rbarnes@bbn.com>
• Date: Mon, 1 Apr 2013 11:27:58 -0400
• To: "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
• Message-Id: <872763F4-CF99-4F88-A1F7-54B0BCEBD644@bbn.com>

In the current spec, key agreement is treated as a special case of key derivation.  Should we call it out as a separate function under SubtleCrypto?

The current situation leads to the public key used in key agreement being a parameter of the key agreement *algorithm*.  This seems awkward and backward.

As Mark has noted elsewhere, we already have duplication of algorithms around.  I took a look at CMS for comparison, and RFC 5652 sides with Mark: KeyAgreeRecipientInfo has the algorithm specified as part of the public key:

OriginatorPublicKey ::= SEQUENCE {
    algorithm AlgorithmIdentifier,
    publicKey BIT STRING }

It seems like this would be a little easier to handle if we could create a separate method for key agreement vs. other types of key derivation.  Straw-man syntax:

"""
KeyOperation agreeKey(Key privateKey,                         
                      Key publicKey,
		      AlgorithmIdentifier? derivedKeyType,
                      bool extractable = false,
                      KeyUsage[] keyUsages = []);
"""

... and delete EcdhKeyDeriveParams and DhKeyDeriveParams.

Cheers,
--Richard

Received on Monday, 1 April 2013 15:28:27 UTC