RE: Diffie-Hellman question

 

 

From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Monday, February 24, 2014 10:06 AM
To: Jim Schaad
Cc: Ryan Sleevi; public-webcrypto@w3.org
Subject: 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.

 

Not supporting a full set of parameters is not acceptable.  The WebCrypto
implementation can always reduce from the X9.42 parameters to PKCS#3
internally if it needs to.

 

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.

 

Again - I do not believe that raw makes any sense for asymmetric algorithms.
You always need to have the parameters with the private key value.  Before
doing a key agreement step, the implementation MUST check that both sides
have the same set of parameters.

 

RAW exists for symmetric algorithms.  Don't use it for asymmetric algorithms

 

Jim

 

 

...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).as
px )

 

[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.