[lamps] Transferring cryptographic information in a bundle between MUAs [was: Re: On the need for standardization of software-based interoperable private keys]

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

On Thu 2021-08-05 12:27:08 -0400, Michael Richardson wrote:
> If we can get the legacy guys to open up their code, why fix PKCS12 if they
> could just move to PKCS8? (or PKCS1 or...?)

afaict, PKCS8 and PKCS1 both only support transporting a single private
key.

PKCS12 is a bundle, which can support not only a private key, but also a
corresponding certificate and potentially other certs in the relevant
chain.

Additionally, since we want an e-mail user to have multiple certs (one
for signing and one for encryption) they may also want to transfer
multiple private keys.  As i wrote elsewhere in this thread the
decryption-capable private key is the highest-priority private key for
transfer, but there are plausible privacy arguments [0] for wanting to
share signing-keys between MUAs as well.  And once you're transferring
one private key it shouldn't be much harder technically to transfer more
than one.

But It is poor user experience to ask someone to export a multiple PKCS8
and PKCS1 objects from device X, transfer them to device Y, and then
reimport them all individually.  Any reasonable user experience for
end-to-end cryptographic MUAs should involve a bundle format.

afaict, that's what PKCS12 is -- a bundle format that specializes in
transporting PKCS8 objects and X.509 certificates.  Would some other
bundle format be better?  or is there a way to bundle PKCS8 and PKCS1
and X509 that i'm not aware of?  Is the counterproposal to PKCS12 just
to offer a series of concatenated PEM-encoded objects in a text file?

I'm definitely not sold on PKCS12, it looks like a disaster to me.  But
I want to understand what the counterproposals are that people are
seriously considering, so i can mock up what draft-ietf-lamps-samples
would look like with some other bundle format replacing PKCS12.

   --dkg

[0] https://anarc.at/blog/2018-07-27-signal-metadata/ is about receipt
    notifications in an instant messenger client, but anyone sending
    mail might prefer to not have their outbound message leak
    information about the device they composed it on.