[gnutls-devel] GnuTLS | PKCS 12 generation wraps authSafe field in one layer of OCTET STRING instead of two (#1259)

[Read-only notification of GnuTLS library development activities]

Daniel Kahn Gillmor created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1259



Over on the IETF LAMPS list, [Ryan Sleevi writes](https://mailarchive.ietf.org/arch/msg/spasm/y4W34PY3aOM8L9mZZ-_2NH1Jogw/) that for PKCS12's authSafe objects, there needs to be two layers of OCTET STRING.

> - 5652 requires that `id-data` be an OCTET STRING
> - 7292 requires that the *contents* of that OCTET STRING be a BER-encoded value of type AuthenticatedSafe, expressed as an OCTET STRING

But `certtool` produces a PKCS12 object with only one layer of OCTET STRING in each of these nested locations.

The PKCS12 object produced by `certtool` is unimportable by some PKCS12 implementations, including `pk12util` from NSS and `Keychain Access` on Mac OS X.  I believe this single layer of OCTET STRING is the reason.

(Thunderbird is willing to import the PKCS12 object produced by `certtool` for some reason, perhaps it uses a different NSS codepath than `pk12util` does; but when Thunderbird re-exports a PKCS12 object, it produces the double-layer of OCTET STRING)

Interestingly, it looks like `certtool --p12-info` can read a PKCS12 object whether it is wrapped in one layer or two layers of OCTET STRING.

My ASN.1 capacity is not strong enough to figure out how to make `certtool` emit a double-wrapped layer of OCTET STRINGs in the right places.  If anyone from GnuTLS can recommend how to do that, i'd be willing to try implementing it, but i'm lost right now.

You can find a `certtool`-generated PKCS12 object (PEM-encoded) in [draft-ietf-lamps-samples-04](https://www.ietf.org/archive/id/draft-ietf-lamps-samples-04.html) that has only a single-layer of OCTET STRING.  (i've been testing with the `bob.p12` object)

The same set of keys and certs, laundered through importing into Thunderbird and then re-exporting, yields [bob.laundered.p12](/uploads/f1e616427bcea703a59607fe60fee5e1/bob.laundered.p12).  Both p12 files have a password that is a three-letter ASCII string `bob`.  Of course the encryption parameters change between the files as well.

Here's an example of `pk12util` from NSS failing to import the `certtool`-generated file:

```console
$ pk12util -i bob.p12 -d /home/dkg/tmp/tmp.R1CukyyEk3 -W bob -K bob
pk12util: PKCS12 decoding failed: SEC_ERROR_BAD_DER: security library: improperly formatted DER-encoded message.
pk12util: PKCS12 decoding failed: SEC_ERROR_BAD_DER: security library: improperly formatted DER-encoded message.
pk12util: PKCS12 decode not verified: SEC_ERROR_BAD_DER: security library: improperly formatted DER-encoded message.
pk12util: PKCS12 decode validate bags failed: SEC_ERROR_INVALID_ARGS: security library: invalid arguments.
```

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1259
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20210803/cd07987c/attachment-0001.html>