PrivateKey parameters and RFC 5915 #493

1. 
   richardschneider commented at 8:16 am on December 27, 2017: none

   The PrivateKey.parameters produced by ec_privkey_export_der currently contain the curve parameters. According to RFC 5915 section 3, it should contain the curve name (OID).

   Is it possible to change this method, or add a ec_privkey.export_RFC5480

   parameters specifies the elliptic curve domain parameters associated to the private key. The type ECParameters is discussed in [RFC5480]. As specified in [RFC5480], only the namedCurve CHOICE is permitted. namedCurve is an object identifier that fully identifies the required values for a particular set of elliptic curve domain parameters. Though the ASN.1 indicates that the parameters field is OPTIONAL, implementations that conform to this document MUST always include the parameters field.

   Expected

   0SEQUENCE(4 elem)
   1  INTEGER 1
   2  OCTET STRING(32 byte) FD1DFE200F8133418031877BF9B54A816D9066011C426ACD46E1B8C16863FEA9
   3  [0](1 elem)
   4     OBJECT IDENTIFIER 1.3.132.0.10 secp256k1 (SECG (Certicom) named elliptic curve)
   5  [1](1 elem)
   6     BIT STRING(264 bit) 0000001110001111011111001101110011101011001100011011010111110010001101…
   

   Actual

    0SEQUENCE(4 elem)
    1  INTEGER 1
    2  OCTET STRING(32 byte) FD1DFE200F8133418031877BF9B54A816D9066011C426ACD46E1B8C16863FEA9
    3  [0](1 elem)
    4    SEQUENCE(6 elem)
    5      INTEGER 1
    6      SEQUENCE(2 elem)
    7        OBJECT IDENTIFIER 1.2.840.10045.1.1 prime-field (ANSI X9.62 field type)
    8        INTEGER(256 bit) 1157920892373161954235709850086879078532699846656405640394575840079088…
    9     SEQUENCE(2 elem) 
   10       OCTET STRING(1 byte) 00
   11       OCTET STRING(1 byte) 07
   12     OCTET STRING(33 byte) 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
   13     INTEGER(256 bit) 1157920892373161954235709850086879078528375642790749043826051631415181…
   14     INTEGER 1
   15  [1](1 elem)
   16     BIT STRING(264 bit) 0000001110001111011111001101110011101011001100011011010111110010001101…
   

   This was first raised in https://github.com/cryptocoinjs/secp256k1-node/issues/123

2. 
   sipa commented at 8:18 am on December 27, 2017: contributor

   Pull requests welcome.

   That function is only provided for backward compatibility with systems that need to interact with OpenSSL, though, and the implementation matches what OpenSSL does (as far as I know).

3. 
   richardschneider commented at 8:34 am on December 27, 2017: none

   Its not just OpenSSL. I need to store the key in PKCS #8 for exchange with other system.

   As for OpenSSL, it now complies with RFC 5915

   openssl ecparam -name secp256k1 -genkey -noout -out secp256k1-key.pem openssl asn1parse -in secp256k1-key.pem

   0    0:d=0  hl=2 l= 116 cons: SEQUENCE
   1    2:d=1  hl=2 l=   1 prim: INTEGER           :01
   2    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:74B598DD666A5844A2625FB2AC3B9CF4136F53B982CB731263F56273657E96B7
   3   39:d=1  hl=2 l=   7 cons: cont [ 0 ]
   4   41:d=2  hl=2 l=   5 prim: OBJECT            :secp256k1
   5   48:d=1  hl=2 l=  68 cons: cont [ 1 ]
   6   50:d=2  hl=2 l=  66 prim: BIT STRING
   

4. 
   gmaxwell commented at 10:44 am on February 20, 2019: contributor

   @richardschneider What sipa was pointing out is that encoder inside our contrib directory is not a first class part of the library. We would rather not have that functionality at all and encourage people to not use it– but we include it (in contrib/) for sake of compatibility with OpenSSL because we needed it for that.

   If someone wants to submit PRs to make it better, that aren’t incompatible with our usage in bitcoin, and aren’t too hard to review– we’ll gladly and thankfully take them. But otherwise we are not very interested in supporting DER private key encoding.

5. gmaxwell closed this on Feb 20, 2019

   ---

Contributors
richardschneider sipa gmaxwell