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

[Ryan Sleevi <[e-mail]>]

On Tue, Aug 3, 2021 at 6:59 PM Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Tue 2021-08-03 17:55:56 -0400, Daniel Kahn Gillmor wrote:
> > I've been using GnuTLS to generate the objects in the draft thus far,
> > and they've been open to code changes that i've suggested in the past
> > based on input from this WG.
>
> I should note that i'm not stuck on using GnuTLS to generate the pkcs12
> objects for this draft, though i would prefer to make them deterministic
> (that is, byte-for-byte reproducible from the tooling), and GnuTLS has
> been friendlier to reproducibility than other certificate/key management
> tools i've encountered.


Hey Daniel,

Sorry for letting this thread slip by. First, an apology for some confusion
due to my earlier reply, but that I see others have picked up on and
clarified (namely, PKCS#8 for private keys, PKCS#7/PEM/DER for certs)

As it relates to the double OCTET STRING, I didn't reply because I thought
Russ' more detailed reply had covered that I'd overlooked something,
namely, the indefinite length encoding issue, caused by NSS preferring BER.
When you're indefinite length-encoding an OCTET string, you end up having
an "outer" indefinite length octet string, and then bound chunks of data in
"inner" OCTET strings, followed by the EOC indicator. So the double
layering I mentioned is an artifact of the BER encoding Russ pointed out,
that I had overlooked.

Dmitry's reply provides a lot of wonderful insight into more of these
PKCS#12 quirks from different libraries, if you haven't had a chance to
review yet. It also helps highlight the "PKCS#12 is wildly different for
different folks". Have you had a chance to run those files through the
different implementations, to see if you can determine an interoperable
encoding for your target?

To some degree, this highlights the value of having some references for
interoperability. At the same time, it suggests, unfortunately, the need to
spend a lot of time with the decoders of these various tools and libraries,
to assess the interoperability problem and determine whether it's one of
malformed input or misbehaving implementation. Unfortunately, as I
mentioned, PKCS#12 is enough of a hell format that I've managed to
professionally stay away from it as much as possible, so I'm stumbling just
as you are here.

NSS using BER should definitely not be the reference example, even if BER
is valid (in PKCS#12 and CMS), simply because we know better now :) As it
relates to using tooling for determinism, I think the historic approach has
been to work directly from the specs building up the binary sequences by
hand, according to what's valid in the spec, rather than using an existing
OSS library and assuming it's correct, especially for a spec as
historically complex and unloved as PKCS#12.

When I compare the examples mentioned by Dmitry, it does seem that both NSS
and OpenSSL expect the PKCS#7 data (1.2.840.113549.1.7.1) to be an OCTET
STRING with the encoded SEQUENCE, rather than the SEQUENCE itself. As Russ
and I both noticed, it would appear bob.p12 is going directly to a
SEQUENCE, rather than OCTET STRING -> SEQUENCE. Dmitry's examples of what
GnuTLS generates also suggests GnuTLS outputs PKCS#7 data as OCTET STRING,
so I'm a bit curious to understand how you generated the bob.p12 in the
first place? This might help drill down further into the interoperability
issue.