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 2:49 AM Daniel Kahn Gillmor <[e-mail]>
wrote:

> Thanks for the ideas and suggestions, everyone.
>
> I hear the consensus of the group that any sample object
> included for reference should be in DER form, with no indefinite
> lengths.  I will definitely respect that.
>
> On Wed 2021-08-04 12:12:08 -0400, Ryan Sleevi wrote:
> > 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.
>
> I might be having a hard time understanding what's in Dmitry's repo.
> I can't tell whether it's supposed to represent PKCS#12 objects that are
> produced by these tools or consumed by these tools, though README.md
> seems to imply that it's kind of both.  I don't see any script that
> shows how they were generated.
>

It's not my repo, it's a Red Hat PKCS12 test corpse :)

I asked my colleagues for more details.

The certs in that repo were generated by openssl, gnutls or NSS, but some
of them were generated by modifying the sources of those libraries
so that's why there is no script to generate them.

They also say there is no single implementation that can import all of them.
Quoting them,
"basically it's a set of pkcs#12 files that to the best of our knowledge
are well formed (with the exception of the NSS files with unicode
passwords)."

These files mostly demonstrate various encryption options.

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.

-- 
SY, Dmitry Belyavsky