CKM_ECDH_AES_KEY_WRAP vote

[Michael StJohns <msj@nthpermutation.com>]

The new mechanism uses CKM_ECDH1_DERIVE as the underlying ECDH mechanism.

During 2.30 we changed the text for CK_ECDH1_DERIVE_PARAMS to remove an 
ambiguity on what the format of the provided public key (from the other 
side) was.  It turned out that there were at least two different 
interpretations including treating it as an ASN1 encoded EC_POINT and as 
an X9.63 public key (1 byte of format), and possibly three (raw x and y 
values without the format).

What we probably should have done was deprecate the mechanism and create 
two new ones with the new interpetation (ala what we did with PBKDF2).

In addition, the current mechanisms don't include definitions for 
generic KDFs and for the SP800-56A ECDH variants.


pkcs11-kdf-ecdh addresses those issues.

For CKM_ECDH_AES_KEY_WRAP, I'd like to actually defer this if there's 
any chance we're going to deprecate CKM_ECDH1_DERIVE and its ilk and 
then rewrite it so it can use either the X9.63 or the SP800-56A ECDH 
variants.

Mike