Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)

[Daniel Kahn Gillmor <[e-mail]>]

I've just published draft-ietf-lamps-samples-05 after figuring out what
i needed to do to make Keychain Access accept the PKCS#12 objects.

The necessary change was to make the PKCS#12 MAC
(https://www.rfc-editor.org/rfc/rfc7292.html#appendix-A) use SHA1
instead of SHA512.

I have no idea why Keychain Access would fail when the MAC is SHA512
instead.  I have not yet experimented with other digests with Keychain
Access.

Before I figured out that this specifically was the issue, i modified
the certficate generation code in GnuTLS to account for all the
divergences i could account for that were *not* due to indefinite
encoding.

This included these two differences:

On Wed 2021-08-04 20:48:42 -0400, Daniel Kahn Gillmor wrote:

>  a) The order of the certificates and encrypted pkcs8 blobs might
>     matter.
>
>  b) The absence of the friendlyName on bob.p12[bag[1]] might matter.

And all the rest here:

 c) the PKCS-8 keys in the original bob.p12 contain a PKCS#8 Provable
    Seed attribute (1.3.6.1.4.1.2312.18.8.1) to indicate their origin,
    but the laundered form does not retain those attributes.

 d) the original bob.p12 file has a separate bag with just the
    certification authority cert in it, whereas bob.laundered.p12 has
    the CA's cert prepended to both EE bags.

 e) embedded PKCS-8 encryption uses different choices for password-based
    key derivation (both use:
     - laundered: 16 octet salt, 600000 iterations
     - bin: 8 octet salt, 5126 iterations

 f) cert bags use different encryption choices:
     - laundered: PKCS12-RC2-40-SHA1 (1.2.840.113549.1.12.1.6),
       16-octet salt and 6000000 iterations
     - bin: PKCS12-3DES-SHA1 (1.2.840.113549.1.12.1.3),
       8-octet salt and 5301 iterations

 g) overall MAC parameters:
     - laundered:  16-octet salt and 600000 iterations;
     - bin:         8-octet salt and 10240 iterations

There is a tremendous amount of multidimensional flexibility in the
PKCS#12 spec, so i thought it might be worthwhile to publicly note all
the different axes of permutation that i considered before landing on
the quirk specific to this particular implementation.

Anyway, i think this particular issue has been resolved for the draft.
I'll follow up in a separate thread about what i think remains for the
WG here.

    --dkg