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

[Dmitry Belyavsky <[e-mail]>]

Dear Daniel,

On Thu, Aug 5, 2021 at 8:34 PM Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Thu 2021-08-05 14:48:58 +0200, Dmitry Belyavsky wrote:
>
> > It's not my repo, it's a Red Hat PKCS12 test corpse :)
>
> Thanks for the clarification, and the history about it. :)  It's
> distressing to learn that there are no implementations capable of
> importing all of the objects in this repo.
>

Malformed files were created by NSS and are not expected to be importable
by anything but NSS, so just that alone means no implementation will be
able to import all of them.
The malformed files are there as NSS has special code to handle those
malformed files.
and since those include stuff like aes-128-cbc (i.e. quite sensible choice)
they may happen "in the wild" but realistically only NSS needs to read them.

NSS should accept these files and all the others except those encrypted
with the algorithms unsupported by NSS (seed, blowfish).
GnuTLS also supports only a limited set of algorithms for PKCS#12.

OpenSSL is able to import pretty much all of them and here's a PR for
openssl that tries to include it in the upstream CI:
https://github.com/openssl/openssl/pull/15188


>
> Has anyone set up an interoperability test suite to document which tools
> fail in which ways, or filed bug reports against the different
> implementations that fail?
>
> The four F/LOSS pksc12 implementations that seem straightforward to test
> in an automated way are:
>
>  - "certtool --p12-info" from GnuTLS
>  - "openssl pkcs12" from OpenSSL
>  - "pk12util" and "certutil" from NSS
>  - "keytool" from the Java JDK
>

We do test all those 3 libraries with those files, and file bugs to add
support for missing things
(e.g. https://gitlab.com/gnutls/gnutls/-/issues/723 and
https://gitlab.com/gnutls/gnutls/-/issues/724)

We don't run our tests against the keytool.


> Are there other tools i should consider testing?  Does anyone know of an
> automated way of testing macOS's Keychain Access, or the Windows
> equivalent?
>
> > On Thu, Aug 5, 2021 at 2:49 AM Daniel Kahn Gillmor <
> [e-mail]> wrote:
> >
> >> I'll set aside the multiple-key case for now, to focus for the moment
> >> on a single-private-key use case so that we can try to evaluate
> >> encodings.
> >
> > I've never seen PKCS12 with multiple private keys so I totally agree
> > with you.
>
> I encourage you to read draft-ietf-lamps-samples 😉, which has included
> these objects since February 17th of this year (back when it was
> draft-dkg-lamps-samples-03)!
>

My fault :)

-- 
SY, Dmitry Belyavsky