PrivateKey parameters and RFC 5915

[richardschneider]

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

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

Actual

SEQUENCE(4 elem)
  INTEGER 1
  OCTET STRING(32 byte) FD1DFE200F8133418031877BF9B54A816D9066011C426ACD46E1B8C16863FEA9
  [0](1 elem)
    SEQUENCE(6 elem)
      INTEGER 1
      SEQUENCE(2 elem)
        OBJECT IDENTIFIER 1.2.840.10045.1.1 prime-field (ANSI X9.62 field type)
        INTEGER(256 bit) 1157920892373161954235709850086879078532699846656405640394575840079088…
     SEQUENCE(2 elem) 
       OCTET STRING(1 byte) 00
       OCTET STRING(1 byte) 07
     OCTET STRING(33 byte) 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
     INTEGER(256 bit) 1157920892373161954235709850086879078528375642790749043826051631415181…
     INTEGER 1
  [1](1 elem)
     BIT STRING(264 bit) 0000001110001111011111001101110011101011001100011011010111110010001101…

This was first raised in cryptocoinjs/secp256k1-node#123

[sipa]

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

[richardschneider]

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:d=0  hl=2 l= 116 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:74B598DD666A5844A2625FB2AC3B9CF4136F53B982CB731263F56273657E96B7
   39:d=1  hl=2 l=   7 cons: cont [ 0 ]
   41:d=2  hl=2 l=   5 prim: OBJECT            :secp256k1
   48:d=1  hl=2 l=  68 cons: cont [ 1 ]
   50:d=2  hl=2 l=  66 prim: BIT STRING

[gmaxwell]

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