Unable to parse EC private key in PKCS#8 format

Asked by Charles Cazabon

I'm trying to use dkimpy to sign messages from the commandline. I have an EC key generated with openssl which is valid (it's in use for HTTP TLS and other purposes without issues), which openssl dumps as follows (private data omitted...):

$ openssl ec -in fqdn.key -text
read EC key
Private-Key: (256 bit)
priv:
    [...]
pub:
    [...]
ASN1 OID: prime256v1
NIST CURVE: P-256
writing EC key
-----BEGIN EC PRIVATE KEY-----
[...]
-----END EC PRIVATE KEY-----

openssl can successfully parse it with ASN1:

$ openssl asn1parse -in fqdn.key
    0:d=0 hl=2 l= 119 cons: SEQUENCE
    2:d=1 hl=2 l= 1 prim: INTEGER :01
    5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:E...
   39:d=1 hl=2 l= 10 cons: cont [ 0 ]
   41:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
   51:d=1 hl=2 l= 68 cons: cont [ 1 ]
   53:d=2 hl=2 l= 66 prim: BIT STRING

I've tried with this file, as well as explicitly telling openssl to convert it to PKCS#8 format:

$ openssl pkcs8 -in fqdn.key -topk8 -nocrypt -out fqdn.key.pkcs8

$ openssl asn1parse -in fqdn.key.pkcs8
    0:d=0 hl=3 l= 135 cons: SEQUENCE
    3:d=1 hl=2 l= 1 prim: INTEGER :00
    6:d=1 hl=2 l= 19 cons: SEQUENCE
    8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
   17:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
   27:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:3...

However, using dkimsign with either file as the private key results in an "unparsable private key" error. I'm calling it as:

$ dkimsign s1 fqdn <keyfile_path> < <rfc822_message_file>

When testing like this, I'm not sure what to use as the selector - I've tried various things, but it doesn't seem to be getting far enough for that to matter - it's dying in the ASN1 parsing function.

With the original file, it gives:

Unparsable private key (are your sure it is encoded in PKCS#1 or PKCS#8 standard ?):
Unexpected tag (got 04, expecting 30)

With the PKCS#8 format file, it gives:

Unparsable private key (are your sure it is encoded in PKCS#1 or PKCS#8 standard ?):
Unexpected tag (got 06, expecting 05)

I realize it's not ideal that I've elided the actual domain name in use here. If you like, I can provide it.

The only thing "unusual" about my setup that I can think of is that it's an EC key, rather than RSA. Is that supported?

Any ideas on what's wrong here?

Thanks,

Charles

Question information

Language:
English Edit question
Status:
Solved
For:
dkimpy Edit question
Assignee:
No assignee Edit question
Solved by:
Scott Kitterman
Solved:
Last query:
Last reply:
Revision history for this message
Scott Kitterman (kitterman) said :
#1

See the related bug (Bug #1978835). This will be fixed in the next release. In the meantime, if you add "-traditional" to the openssl call to generate the key, it will work.

Revision history for this message
Charles Cazabon (charlesc-web-register-launchpad-net) said :
#2

I saw that one. But I'm using the current head of the master branch, cloned today, so that fix should already be in my copy, should it not? At least none of the other active branches look like they might be holding the change.

commit 0540d3cb17bf4f43ed5a1f9fd8f41f9ef03346b7

Charles

Revision history for this message
Best Scott Kitterman (kitterman) said :
#3

I missed that it's an EC key in your original question.

The only two valid crypto algorithms for DKIM are RSA and ed25119. For ed25119 we don't use openssl (since it didn't have at ed25119 at the time support for it was added). For ed25119, you have to use the provided dknewkey script to generate the private key and it's not in any standardized format (which also didn't exist at the time).

Revision history for this message
Charles Cazabon (charlesc-web-register-launchpad-net) said :
#4

Ah, okay - thank you.

Revision history for this message
Charles Cazabon (charlesc-web-register-launchpad-net) said :
#5

Thanks Scott Kitterman, that solved my question.