Re: Diffie-Hellman question

So, if the libraries people are using to implement WebCrypto right now
support only PKCS#3, shouldn't we stick with that for this first version ?
Just as we have "RSASSA-PKCS1-v1_5" we could have "DH-PKCS3" and later
introduce X9.42.

That would mean that in this version we would not be able to support export
except in raw format. I would then suggest that we support import only in
that format too. It's not quite clear what import is for, though, except
perhaps to enable use of the DH Phase II primitive with a private value
generated some way other than deriveKey: we would need a DhImportParams
dictionary to provide the prime and generator. Importing a DH public key is
useless, because the only think a Key object representing a DH public key
can be used for is to export the Public Value.

...Mark



On Friday, February 21, 2014, Jim Schaad <ietf@augustcellars.com> wrote:

>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com<javascript:_e(%7B%7D,'cvml','sleevi@google.com');>]
>
> *Sent:* Friday, February 21, 2014 11:16 AM
> *To:* Mark Watson
> *Cc:* public-webcrypto@w3.org<javascript:_e(%7B%7D,'cvml','public-webcrypto@w3.org');>
> *Subject:* Re: Diffie-Hellman question
>
>
>
>
>
>
>
> On Fri, Feb 21, 2014 at 10:40 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> 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?).
>
>
>
> I'm not sure how you reached "raw" being the only appropriate format after
> reading RFC3279 Section 2.3.3
>
>
>
> First, recall that:
>
>
>
> SubjectPublicKeyInfo  ::=  SEQUENCE  {
>      algorithm            AlgorithmIdentifier,
>      subjectPublicKey     BIT STRING  }
>
> AlgorithmIdentifier ::= SEQUENCE {
>         algorithm               OBJECT IDENTIFIER,
>         parameters              ANY DEFINED BY algorithm OPTIONAL  }
>
>
>
> Section 2.3.3 dictates that this looks like
>
>
>
> SubjectPublicKeyInfo = {
>
>   algorithm: {
>
>     algorithm: dhpublicnumber,
>
>     params: {
>
>       p: <some_value>,
>
>       g: <some_value>,
>
>       q: <some value>,
>
>       j: (optional),
>
>       validationParams: (optional){
>
>         seed: <some_value>,
>
>         pgenCounter: <some_value>
>
>       },
>
>     },
>
>     subjectPublicKey: <DH public value as integer>
>
> }
>
>
>
> 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.
>
>
>
> Again, no. PrivateKeyInfo is a valid format here.
>
>
>
>
>
> Second, it seems that the parameter q is not necessary for DH.
>
>
>
> It is for X9.42. It's not for PKCS#3.
>
>
>
> 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 o
>
> CNG - Only supports PKCS#3 (
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa375534(v=vs.85).aspx)
>
>
>
> [JLS] Once again Microsoft has demonstrated that it has not real security
> people in the cryptographic division of the company.   I am always
> frustrated by the number of problems that it has.   However I would note
> that for DSA it did get it right.
>
>
>
> Also it is easy to go from X9.42 to PKCS #3, but the other direction is
> impossible.
>
>
>
> OS X Common Crypto - PKCS#3 (as of 10.8) (although it doesn't actually
> support import/export of params yet)
>
>
>
> The point being that all the APIs support PKCS#3, whereas all the
> useful-for-certificate bits expect inputs/outputs in the form of X9.42
>
>
>
> Hence why I added that TODO.
>
>
>