[lamps] On the need for standardization of software-based interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)]

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

On 8/4/21, 17:44, Michael Richardson wrote:
>     I would be happy if pkcs12 just died.

On Wed 2021-08-04 22:28:17 +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> - PKCS#12 cannot "just die" because there's a ton of software that cannot import private keys, unless they're in .p12 or such.
> - I concur that interoperation for private keys is nonsense.

I think i understand the sentiment about wanting PKCS#12 to die, given
what a disaster the implementations are and how poorly we collectively
understand the format.

However, i don't understand how interoperation for private keys is
nonsense.

Many people with e-mail accounts use multiple mail user agents to access
the same account (e.g. one MUA on their phone, another on a laptop).  If
those accounts are supposed to be able to use end-to-end secure
communication then at least one of them needs to be able to export its
private key material and the other needs to be able to import it.

For myself, I only use a single MUA.  So my personal workflow would be
entirely satisfied if we as a standards body were to declare that there
is no interop need for private keys.  But if we want to ensure that
end-to-end cryptographic protections are usable and secure for actual
e-mail users, then we need to figure out the interop issues for private
key material, even if each e-mail user only encounters this interop
scenario once, as they provision their second MUA.

The only way I understand S/MIME to work today is for all the MUAs
attached to a given e-mail account to have access to the same private
keys, at the very least for those private keys used for message
decryption.

Assuming that we want people to be able to read their encrypted e-mail
in any MUA in which they read e-mail, the other two usable architectural
alternatives i see are:

 a) private keys are only ever stored on a hardware token which moves
    between devices with the user.

 b) different MUAs use different private keys for decryption, and the
    sender of an e2e encrypted e-mail encrypts each message to *all* the
    encryption-capable certificates it knows about for the user.

(a) still requires us to standardize private key interop, though it's
more of the PKCS#11-style than PKCS#12.  And it requires work on
hardware interfaces too.

(b) is a major systems change, requiring MUAs to change what
certificates they advertise for the user (each MUA *must* learn about
the other MUAs attached to the account and advertise the corresponding
encryption certificates as well), and all senders to adjust behavior by
sending messages encrypted to multiple keys per recipient.

Compared to either of these, standardizing software-based private key
interop seems like an easy lift.

I sympathize with the grumbling about it, but I'd hope that the experts
in the IETF LAMPS WG can at least come to a consensus that there is
value in standardizing interop for decryption-capable private keys.

       --dkg