Re: Spec unclear about ECC (was Re: PolyCrypt )

No, I was not agreeing. I was clarifying JWK's relationship to PKCS#1.

Your proposal creates added complexity for developers for most forms of ECC
agreement, by forcing an added asynchronous diversion through the import
key phase for a value that will be immediately discarded, or forcing an
additional encoding phase into SPKI. This same concern applies to DSA
public values. In what situation or scenarios does a Key object provide any
value to authors?
On Feb 6, 2013 9:44 PM, "Richard Barnes" <rbarnes@bbn.com> wrote:

> <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;
> };
> """
>
>
>