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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

I wonder if Keychain Access would accept SHA256 MAC.

Because it would be nicer if we could stick with SHA2, not encumbering the stack with SHA1 code (and some implementations might have a requirement to exclude "unblessed" algorithms).

TNX
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 8/5/21, 21:05, "Spasm on behalf of Daniel Kahn Gillmor" <[e-mail] on behalf of [e-mail]> wrote:

    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