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

[Ryan Sleevi <[e-mail]>]

On Sat, Jul 31, 2021 at 8:27 PM Daniel Kahn Gillmor <[e-mail]>
wrote:

> do folks here think it's a bug that Keychain Access isn't capable of
> reading bob.p12, but is capable of reading bob.laundered.p12?  or is
> bob.p12 actually malformed in some way?


It’s PKCS#12. There is very little interoperability on the market in
general, as it is a hell format that is functionally impossible to
implement securely, and so no vendor particularly wants to touch.

I realize that sounds like my usual hyperbole, but it truly is a pernicious
format. In Mozilla NSS, it uses what is known as the “legacy” decoder,
because of the need to support BER. The “legacy” decoder is so named
because it was, and is, a security tirefire, and the whole system was
replaced everywhere in NSS - except the CMS and P12 systems, because unlike
other places, Mozilla didn’t feel they could restrict to DER only and
remain compatible.

For Apple, there’s actually a shared history: the first CMS decoder on
macOS systems began as a port of the NSS libraries. This is why, for
example, it is speculated that the FBI was able to gain access to the San
Bernardino shooters’ phones: by exploiting a bug in the legacy decoder from
NSS that had, incidentally, been ported to macOS/iOS [1].

When folks say PKCS#12 is not a place of honor [2] [3] [4], they truly mean
nothing valued is there.

Again, I realize this sounds hyperbolic, but I also do it to highlight that
there’s very little interoperability in the deployed software, in part
because it’s impossible to maintain. Since that bug, I believe Apple has
rewritten their CMS and PKCS#12 parsers twice; although rewritten may be a
bit of a stretch, as it’s more like there are three different parsers
depending on which product you’re using.

I confess i don't understand the definite length encoding vs. indefinite
> encoding question.  are these both acceptable PKCS#12 structures?


Indefinite length means BER: the format from which a thousand security bugs
bloom, because the message size is generally not known before hand, and so
you constantly end up running past the end of the message, onto the stack,
and making everyone sad along the way. Definite length may be BER or may be
DER: it means you actually send the length before the data.

The implementation details I mentioned above play into this: you should try
to always use DER, for BER is the path of doom. That said, implementations
that have an ancestral heritage to NSS, with its unmaintained (and
insecure) BER parser (not to be confused with its DER parser for certs and
things), will still prefer to encode in BER. I realize saying “use DER”
doesn’t get you closer to “interoperable PKCS#12 file”, your end goal, but
that’s mostly because many folks gave up on “interoperable PKCS#12” ages
ago, and have accepted “if it works, it works, if it doesn’t, try doing
something different.”

>
[1]
https://twitter.com/zhuowei/status/1382475494084476928
[2]
https://en.wikipedia.org/wiki/Long-time_nuclear_waste_warning_messages#Message
[3]
https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html
[4]
https://unmitigatedrisk.com/?p=543

>