Page MenuHome GnuPG

gpgsm cannot read pkcs12 files generated by certtool (from gnutls-bin)
Closed, ResolvedPublic


certtool generates pkcs12 files packaged using pkcs5PBES2
(1.2.840.113549.1.5.13) and pkcs5PBKDF2 (1.2.840.113549.1.5.12) and
aes128-CBC (2.16.840.

I've attached one of these files to this report. You can generate
them yourself with:

certtool --to-p12 \
    --load-privkey "alice.pem" \
    --load-certificate "alice-cert.pem" \
    --outfile "alice.p12.der" \
    --password 'abc123' \
    --outraw  \
    --template /dev/stdin <<EOF

pkcs12_key_name = "alice"

Trying to import this file into gpgsm fails:

0 dkg@pip:~/src/gmimetest/testkeys$ gpgsm --fixed-passphrase abc123 --import
gpgsm: gpgsm: GPG_TTY has not been set - using maybe bogus default
gpgsm: gpg-protect-tool: encryptedData error at "bag.encryptedData.keyinfo",
offset 79
gpgsm: gpg-protect-tool: error at "bag.encryptedData", offset 49
gpgsm: gpg-protect-tool: error parsing or decrypting the PKCS-12 file
gpgsm: error running `/usr/lib/gnupg2/gpg-protect-tool': exit status 2
gpgsm: total number processed: 0
2 dkg@pip:~/src/gmimetest/testkeys$

It would be really good if gpgsm could interoperate with the PKI
material produced by certtool.

fwiw, openssl seems to have no problem reading the same blob:

openssl pkcs12 -nodes -passin pass:abc123 < alice.p12.der

I tested this with gpgsm 2.0.17-2 from debian.



Event Timeline

That is quite possible. pkcs#12 is a stupid and baroque data format worse than
the usual X.509 stuff. There are dozens of variants.

What I implemented is what was needed for interoperability with other software.
I don't want to play catchup with new pkcs#12 variants. There is a reason why
the code is in a file called minip12. ;-).

werner lowered the priority of this task from Normal to Wishlist.Mar 4 2011, 10:07 AM
werner added a project: Feature Request.
werner removed a project: Bug Report.

I appreciate that PKCS#12 is stupid and baroque, but if the goal is
interoperability with other software, it seems like other GNU tools would be a
reasonable target at least :)

Is there some other format that gpgsm can use to import secret keys?

If you think that certtool should be generating PKCS#12 using a different set of
formats, could you report that to the GnuTLS team?

Frankly, I'd prefer if gnutls would use the gnupg infrastructure instead of
duplicating everything. If they have time to add their new key derivation
feature to minip12.c; I will be glad to apply such a patch.

Interchange of secret key material is a tricky business; in general that should
not be done at all. If you need it you should setup procedure organisation
rules for that; the actual format is only a minor thing. Now you are protecting
a secret key with a passphrase - how do you convey this passphrase .. we are in
the well known realm of secret key management procedures we thought to avoid by
using public key schemes. However, you all know that.

I think fixing a broken format is not the way to go; the should use CMS or
(better) OpenPGP and MIME for key exchange. Or leave it to the user to get the
secrets to their server (where they end up as unprotected blobs).

As a good GNU citizen I spent some time on it and implemented PBES2 in
minip12.c. This is in master and I don't intend to backport it to 2.0.x.

You need the latest Libgcrypt to to build GnuPG master now.

werner claimed this task.
werner removed a project: Restricted Project.