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

[Daniel Kahn Gillmor <[e-mail]>]

On Sun 2021-08-01 19:54:01 -0400, Ryan Sleevi wrote:
> PKCS#7 is widely supported and avoids the "many forms" of PKCS#12's
> silliness. Or just import directly (e.g. PEM and PKCS#8).

What i'm getting from this thread is that including any attempt at the
PKCS#12 form of the objects in this draft might be a mistake.

I'm pretty much certain now that even if a PKCS#12 object is included in
this draft, it should come with warnings that this format is NOT
RECOMMENDED.

If we drop the PKCS#12 objects entirely, the draft will be shorter, but
will still retain all the same information.  But I confess i don't know
how to import a corresponding secret key into some clients.

For example, Thunderbird appears to *only* support pkcs#12 import for
secret keys:

   https://bugzilla.mozilla.org/show_bug.cgi?id=1723617

Thunderbird can clearly handle PKCS#7 itself (it can render the contents
of encrypted and signed messages, and can even extract and import
certificates included in a message's certificate list), but i can't see
how to use PKCS#7 to get a secret key into its data store.

How would you use PKCS#7 to transport secret keys between two clients?

To the WG more broadly:

What approach do you prefer we take on this draft?  I see three options
(i welcome hearing suggestions for others):

 a) Drop PKCS#12 from this draft entirely

 b) Keep the PKCS#12 objects as they are but explicitly warn against
    their use due to interoperability concerns.

 c) Adjust the creation of the PKCS#12 objects so that they have the
    double OCTET STRING wrapper (one for RFC 5652 and one for RFC 7972),
    without moving them into the indefinite encoding.  (maybe also warn
    against PKCS#12 use here?)

Do folks have a preference on what should happen with the draft?

   --dkg