Re: pk12util fails to import EC keys

Hubert Kario <[email protected]>
Newsgroups gmane.comp.mozilla.crypto
Message-ID <[email protected]>
On Wednesday 29 June 2016 12:45:40 Chris Richardson wrote:
> On 29 June 2016 at 12:02, Hubert Kario <[email protected]> wrote:
> 
> > On Tuesday 28 June 2016 02:59:18 chrisr wrote:
> > > Hi,
> > >
> > > I'm trying to import an EC key and cert generated with openssl into an
> > NSS
> > > DB but am getting this error from pk12util:
> > > pk12util: PKCS12 decode import bags failed:
> > > SEC_ERROR_PKCS12_UNABLE_TO_IMPORT_KEY: Unable to import.  Error
> > attempting
> > > to import private key.
> > >
> > > I've tested this on Gentoo x86 with nss versions 3.23(portage),
> > > 3.24(portage) and 3.25 (from source) with the same result. Changing the
> > key
> > > type to RSA works so I wonder if this might be bug in the EC key
> > handling?
> > >
> > > Steps to reproduce:
> > > # Create an empty NSS db
> > > mkdir nss
> > > openssl rand -base64 -out nss/pw 21
> > > certutil -d nss -f nss/pw -N
> > > # Generate an EC key/cert
> > > openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp521r1 -keyout
> > > key.pem -out cert.pem -days 3650 -nodes -subj "/CN=Test CA"
> > > # Export to pkcs12 format
> > > openssl pkcs12 -export -in cert.pem -inkey key.pem -out cert.p12 -name
> > Test
> > > # Import to nss db
> > > pk12util -i cert.p12 -d nss -k nss/pw
> > > # pk12util reports error
> >
> > Using nss 3.23.0 and openssl 1.0.1 on Fedora with slightly different
> > commands,
> > I can't reproduce it:
> >
> > mkdir nssdb
> > certutil -N --empty-password -d sql:nssdb/
> > openssl ecparam -out secp521r1.pem -name secp521r1
> > openssl req -x509 -newkey ec:secp521r1.pem -keyout localhost.key -out
> > localhost.crt -subj /CN=localhost -nodes -batch
> > openssl pkcs12 -export -passout pass: -out localhost.p12 -inkey
> > localhost.key -in localhost.crt
> > pk12util -i localhost.p12 -d sql:nssdb/ -W ''
> > certutil -L -d sql:nssdb/ -n localhost -a | openssl x509 -noout -text
> >
> > so it doesn't look to me like a problem with EC keys specifically
> >
> > which version of OpenSSL are you using?
> >
> 
> I'm using openssl-1.0.2g.
> 
> Your script also works on my environment so I'll switch to that method.
> It looks like there is a significant difference in the keys produced by
> openssl in the two cases -
> your script produces a key that looks like this:
> $ openssl pkey -in localhost.key -text -noout
> 
> Private-Key: (521 bit)
> 
> priv:
> 
>     <hex>
> 
> pub:
> 
>     <hex>
> 
> ASN1 OID: secp521r1
> 
> NIST CURVE: P-521
> 
> while mine produces this:
> $ openssl pkey -in key.pem -text -noout
> Private-Key: (521 bit)
> 
> 
> 
> priv:
> 
> 
> 
>    <hex>
> 
> 
> pub:
> 
> 
>    <hex>
> 
> 
> Field Type: prime-field
> 
> 
> 
> Prime:
> 
> 
>    <hex>
> 
> 
> A:
> 
> 
> 
>    <hex>
> B:
> 
> 
> 
>    <hex>
> Generator (uncompressed):
> 
> 
> 
>    <hex>
> Order:
> 
> 
> 
>    <hex>
> Cofactor:  1 (0x1)
> Seed:
> 
> 
> 
>    <hex>
> 
> so I assume (perhaps stating the obvious) that the problem is that in the
> latter case the key is a definition of the finite field in parametric form
> rather than using the standard curve name and that this is not supported by
> nss.

yes, NSS does support only named curves, not curves in arbitrary format

btw: you may want to consider using a smaller curve (like the P-384) - the
P-521 is not supported by Windows or Chrome

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
signature.asc (application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJXc7ZwAAoJEJKo0bgB0vX10nAP/AiOKhpTNuU1Ku8KL9sTF3uS
PSlHvt0tw51LCVHnz85rKluw1wxWUpE7u8uy7qyB+HaBQH8y8UcEtMWXhAb7u7CD
1rBCe5XdSn97jePXzXBSwHH4072axe1xLww+EnYy3bK/H9mdVmiEwo+tBj8TQgd0
nIGPUImz6FmWkZ8AKcj6kr5ePU8mogvz+1gpfcbquPawy8Uog5eOuEEALOM2JaIS
sj5GtQnX9dot8GlMmIimQx4AnZCaaMEY77LaAgSUuORv9oXgPJFYlZDOez2O9Oh7
RHz8Sswo3jatst6U2Kp+0nHRw77BDQgmoS9CgYmZO6YFkQ34bFivzjB+S3l7qBEx
7++VO6U3YiAtfkyoe40zDF3J27LPJPZIeiUU5RVL8DTYgfRf2X50BN5ASLer3NB2
RuWSqzOqkoWmqhQTfkYEMGNdY6Tx6VIn3Br6sdOKihoOYFQL9aIIW7CbnI05fB4f
Tn/rulP04M7BWjeYrcsQ/uG9ScS3hQa6TnkWUzuvfbJDQMuIT0Oe1hjI/bTzZbQ1
l1w9hNUJxJ6qRxrJ04FCWaLvynVYuMOSC/37zK42XnvXFgR2ebNCs5vGg3QIUFQz
wqYsajIgr3nqBpM67RlgUKzZPo6VSdcbzGbGNfsovGvz812DoXdHTXSGLf7akMW4
0aLd5dL7eu+0A522/zdJ
=SEhT
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.