- From: Richard Barnes <rbarnes@bbn.com>
- Date: Thu, 7 Feb 2013 00:44:47 -0500
- To: Ryan Sleevi <sleevi@google.com>
- Cc: public-webcrypto-comments@w3.org
<trimmed>
>> On a related note: It seems a little awkward to have the public key represented directly as octets here, when every other public key we use is a Key object. Suggest changing type of EcdhKeyDeriveParams.public to Key. That way I could importKey from SPKI or JWK. You might also want to add an 'x9.62' format to importKey / exportKey, although SPKI is arguable a better format for that sort of thing, since it includes algorithm info.
>>
>> --Richard
>
> We explicitly removed PKCS#1 from the spec in favour of PKCS#8. I
> don't see why we'd want to add x9.62 when SPKI is sufficient, and
> seems entirely inconsistent with the discussion during Lyon.
It sounds like you're agreeing with the following PROPOSAL (with the idea that EcdhKeyDeriveParams.public would be populated via importKey, say of an SPKI or JWK value):
REMOVE:
"""
The ECPoint typedef is a Uint8Array holding an elliptic curve point. An elliptic curve point is converted to an array of Uint8 elements using the procedure specified in X9.62 Annex A.5.7.
"""
OLD:
"""
dictionary EcdhKeyDeriveParams : AlgorithmParameters {
// The peer's EC public key.
ECPoint public;
};
"""
NEW:
"""
dictionary EcdhKeyDeriveParams : AlgorithmParameters {
// The peer's EC public key.
Key public;
};
"""
Received on Thursday, 7 February 2013 05:45:23 UTC