Creation of Oakley EC keypair produces garbled output

[johndoe31415]

I noticed today (tested with 5900679, i.e., latest master) that producing Oakley EC keypair (the ones with the questional extension field) fail because apparantly no OID is encoded into the optional part of the EC key, but garbled (?) data. This leads to the following (OpenSSL cannot read the keys it generated itself):

$ openssl ecparam -name Oakley-EC2N-3 -genkey -noout | openssl ec
read EC key
unable to load Key
139800014533056:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:crypto/asn1/a_object.c:242:
139800014533056:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:609:
139800014533056:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:237:Field=value.named_curve, Type=ECPKPARAMETERS
139800014533056:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:609:
139800014533056:error:0D08403A:asn1 encoding routines:asn1_template_ex_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:460:Field=parameters, Type=EC_PRIVATEKEY
139800014533056:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC lib:crypto/ec/ec_asn1.c:926:
139800014533056:error:100DE08E:elliptic curve routines:old_ec_priv_decode:decode error:crypto/ec/ec_ameth.c:446:
139800014533056:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1112:
139800014533056:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:274:Type=X509_ALGOR
139800014533056:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:609:Field=pkeyalg, Type=PKCS8_PRIV_KEY_INFO
139800014533056:error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib:crypto/pem/pem_pkey.c:88:

Also, this is the output of asn1parse:

$ openssl ecparam -name Oakley-EC2N-3 -genkey -noout | openssl asn1parse
    0:d=0  hl=2 l=  75 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:00402FD611A798F9CB8BC3623ED26B58E54E806C
   27:d=1  hl=2 l=   2 cons: cont [ 0 ]        
   29:d=2  hl=2 l=   0 prim: OBJECT            :BAD OBJECT:[]
   31:d=1  hl=2 l=  44 cons: cont [ 1 ]        
   33:d=2  hl=2 l=  42 prim: BIT STRING       

I don't know if anyone is actually using those curves, but I feel that OpenSSL should rather refuse to generate keypairs instead of creating broken ones.

[mattcaswell]

It appears there are no OIDs defined for those objects:

https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt#L1230

This should probably have bailed out when it tried to write out the oid and found there wasn't one.

[richsalz]

The syntax is valid, tho. Look at lines 948, 1424, etc...

[mattcaswell]

The syntax is valid, tho. Look at lines 948, 1424, etc...

Yes, the syntax is valid. We can create and use objects of this type internally. But when we try to write out an OID for this the OID data is missing. It should fail at that point I think.

[richsalz]

I misiunderstood when it should bail out. I thought you meant at build time. I don't understand why those curves are in objects.txt without OID's. That should be a build error.

[mattcaswell]

I don't understand why those curves are in objects.txt without OID's

Presumably so we can have NIDs for them. This enables us to use them - we just can't write out any ASN.1 for them. That might be perfectly valid if the application using the curve doesn't need to write out an ASN.1 encoding (perhaps it is using some application specific encoding).

[mattcaswell]

Fix in #5725. That at least means we fail when we try to write the key in the first place.