Symmetric key storage not supported for PKCS12

[Two4]

When loading a PKCS12 keystore containing just a RAW-format symmetric key (generated via keytool with SunJCE), SunJCE obviously succeeds in retrieving the key. However, both generating such a keystore and retrieving said key fail when using BC:

keytool -genseckey -alias encryption-key -keyalg AES -keysize 256 -keystore .\keystore.p12 -storepass encryption-keystore-password -storetype PKCS12

succeeds, but

keytool -genseckey -alias encryption-key -keyalg AES -keysize 256 -keystore .\keystore.p12 -storepass encryption-keystore-password -storetype PKCS12 -providername BC -providerpath C:\Users\LocalUser\.m2\repository\org\bouncycastle\bcprov-jdk18on\1.78.1\bcprov-jdk18on-1.78.1.jar -providerclass org.bouncycastle.jce.provider.BouncyCastleProvider

does not, reporting a keytool error: java.security.KeyStoreException: PKCS12 does not support non-PrivateKeys.

Similarly, trying to open the keystore successfully generated via keytool/SunJCE with BC yields this output, and no keys are present:

extra in data 1.2.840.113549.1.12.10.1.5
Sequence
    ObjectIdentifier(1.2.840.113549.1.12.10.1.5)
    Tagged [CONTEXT 0]
        Sequence
            ObjectIdentifier(1.2.840.113549.1.12.10.1.2)
            Tagged [CONTEXT 0]
                DER Octet String[173] 
    Set
        Sequence
            ObjectIdentifier(1.2.840.113549.1.9.20)
            Set
                BMPString(encryption-key) 
        Sequence
            ObjectIdentifier(1.2.840.113549.1.9.21)
            Set
                DER Octet String[18]

When I run

openssl pkcs12 -info -nodes -in keystore.p12 -passin pass:encryption-keystore-password -noout

I get the following output:

MAC: sha256, Iteration 10000
MAC length: 32, salt length: 20
PKCS7 Data
Secret bag
Bag Attributes
    friendlyName: encryption-key
    localKeyID: 54 69 6D 65 20 31 37 32 35 30 32 33 39 38 35 31 36 38
Bag Type: pkcs8ShroudedKeyBag
Bag Value: 30 81 AA 30 66 06 09 2A 86 48 86 F7 0D 01 05 0D 30 59 30 38 06 09 2A 86 48 86 F7 0D 01 05 0C 30 2B 04 14 20 56 E5 60 6F 76 D6 50 E2 50 84 97 85 A4 CE 25 1C 1F 08 AE 02 02 27 10 02 01 20 30 0C 06 08 2A 86 48 86 F7 0D 02 09 05 00 30 1D 06 09 60 86 48 01 65 03 04 01 2A 04 10 25 F8 AE D8 82 A4 F4 AC 95 2F CB E7 34 37 13 FF 04 40 6F 7A 7A A1 D0 6B 27 F2 33 B3 B8 30 A2 D9 0A E0 E6 6E 56 E1 74 94 B0 1C 5E EE 1F 59 10 EA E6 85 E2 E5 50 89 02 94 2D C3 75 A3 66 20 BF 5A 7A 4B 95 75 4A DE E6 64 E1 70 CD 2B 0F BA 96 AA 1B 67

Is this a deviation from standards by SunJCE? Does BC plan to implement support for secret keys in PKCS12 stores?

I've looked through the issue list and can't seem to find anything regarding this, so forgive me if this has been raised and answered before

[dghgit]

It's a massive deviation from standards... I'm not sure this is something we really want to do, I'll have to look into it in more detail.

In the meanwhile, the BCFKS format allows you to store secret keys.

[Two4]

@dghgit have you perhaps had an opportunity to look into this?

[dghgit]

Not so far, we've been concentrating on meeting the new PQC standards, rather than trying to deal with a, erm.., new "interpretation" of an old one. I'd still recommend BCFKS, it is restricted to a small set of secret key algorithms, but it is easy for us to extend it if required as it's based on the use of ASN.1 identifiers.

[Two4]

Unfortunately in my case we have to use a keystore standard that's portable between tools, languages and runtimes, but I appreciate the suggestion.

[dghgit]

If you can suggest a standard we would happily use it.

[Two4]

Alas, PKCS12 is the only one I can find that fulfills this requirement as it's a common standard. If it's not meant to support symmetric key storage, so be it, we'll just have to work around that when we're using BC.

[dghgit]

As long as you recognize it does not fill the requirement.