- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 21 Feb 2014 10:40:50 -0800
- To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CAEnTvdDSqzN1qYJObRcUmrcdr0L7oWbBX8+HgJxrciw2Qer4=g@mail.gmail.com>
All, The DH section includes the note: "TODO: This interface is broken for import/export. Generate is defined in terms of PKCS#3 - meaning it takes base/g and prime/p - whereas the dhpublicnumber used by X.509/RFC 3279 uses the X9.42 form - meaning it takes base/g, prime/p, and subprime/q. The inconsistency here needs to be resolved before this can be reliably implemented." Two things are not clear to me after reviewing PKCS#3, RFC3279 and X.9.42. First, in what context do we need to support export of domain parameters in WebCrypto ? Export of the public key of the generated pair presumably obtains us the public value and the only appropriate key format is "raw" (or is there standard serialization from X.509?). Export of the private key of the generate key pair would presumably export the private value (referred to as x in PKCS#3) again with "raw" being the only appropriate format. In all cases the domain parameters are available as explicit members of the key.algorithm interface. Second, it seems that the parameter q is not necessary for DH. But, without the input parameter, m, in X.9.42 (which determines the size of q, which in turn is the order of g), there is no way to specify the required strength of the private key. It is not necessary for both parties to use the same value of q for DH or to know which value the other party used, so it is not clear to me why it is included in the X.9.42 domain parameters, except for the other algorithm described there, MVQ, or for ensuring that both parties use private values of similar strength (or for some form of validation?). Can anyone help me here ? I think the above note is probably not an issue, but we need to determine whether we should support an input, m, to generate a private key of a specified strength (IIUC). I'd be interested to know what the common libraries support. ...Mark
Received on Friday, 21 February 2014 18:41:19 UTC