openssl and jss PKCS8 compatibility

[David Stutzman]

I'm trying to export a key in PKCS8 format using JSS that is readable by
OpenSSL. Using dumpasn1, I can see that the structure of the 2 objects
are similar, but not the same. I *think* I see where the problem is but
I'm not sure.

The only thing I see different is the 3rd SEQUENCE down, which I think
is the salt. OpenSSL uses a shorter one than JSS and I wonder if when
OpenSSL tries to read the PKCS8 it's expecting the shorter version that
it uses.

The javadoc in PBEAlgorithm.getSaltLength() says:
"PKCS #5 algorithms require exactly 8 bytes of salt. PKCS #12 algorithms
take a variable length, but recommend that the salt length be at least
as long as the output of the hash function. For SHA-1, the output length
is 20 bytes."

I wonder if OpenSSL is expecting the 8 bytes and only 8 bytes of salt
even though the algorithm below is one of the PKCS12 algorithms.

Anyone have any ideas for making these 2 compatible? The PBEAlgorithm
constructor is protected, but I could set the salt length there.

First, a PKCS8 from OpenSSL (key bytes not present):
# dumpasn1 -ahitd p8-3DES.der
<30 82 02 A2>
0 674: SEQUENCE {
<30 1C>
4 28: . SEQUENCE {
<06 0A>
6 10: . . OBJECT IDENTIFIER
: . . . pbeWithSHAAnd3-KeyTripleDES-CBC (1 2 840 113549 1 12 1 3)
<30 0E>
18 14: . . SEQUENCE {
<04 08>
20 8: . . . OCTET STRING 9C 1E E6 61 52 27 65 7B
<02 02>
30 2: . . . INTEGER 2048
: . . . }
: . . }
<04 82 02 80>
34 640: . OCTET STRING

And now JSS (key bytes not present):
# dumpasn1 -ahitd ronald.w.cooper-ID.p8
<30 82 02 A9>
0 681: SEQUENCE {
<30 23>
4 35: . SEQUENCE {
<06 0A>
6 10: . . OBJECT IDENTIFIER
: . . . pbeWithSHAAnd3-KeyTripleDES-CBC (1 2 840 113549 1 12 1 3)
<30 15>
18 21: . . SEQUENCE {
<04 10>
20 16: . . . OCTET STRING 5D 97 34 E8 8D DB 90 24 5B EB 89 83 59 81
74 0F
<02 01>
38 1: . . . INTEGER 2048
: . . . }
: . . }
<04 82 02 80>
41 640: . OCTET STRING

[David Stutzman]

As an additional note on this I tried extending PBEAlgorithm so I could
create one using the constructor and I passed in 8 for the salt length
instead of the 20 that is passed in by default with the
PBE_SHA1_DES3_CBC static I am using. JSS still gave me the longer salt
when I viewed it with dumpasn1. So unless I'm totally off base in
assuming that 3rd SEQUENCE is the salt, I'm at a loss here.

Thanks,
Dave

[Nelson Bolyard]

David, for about 10 years now, the NSS team's answer to inquiries about
PKCS#8 have been that:
- NSS doesn't support bare PKCS#8 for key import or key export.
- PKCS#12 is the protocol/format which all major PKI/SSL implementations
agree to support, and for which they test interoperability.
- NSS team recommends that you use PKCS#12.

/Nelson