Re: [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)]

[Michael Richardson <[e-mail]>]

On 2021-08-05 8:17 a.m., Daniel Kahn Gillmor wrote:
> 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.

+1

> 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.

Also, keys might get backed up differently from the rest of "C:",
(I've printed them to QRcode for instance), and when the disk is 
restored, sometimes software is different versions, or one chooses 
different software, or as you say, different MUAs.

The need to go back to my key twenty years ago and reload it so that I 
can decrypt old email.

With multiple mail user agents, I like to have different signing keys.

> For myself, I only use a single MUA.  So my personal workflow would be

My situation is a single MUA with ssh access, but also scripts that move 
where my MUA is... but different keys... so if I have to decrypt I have 
to ssh.

> 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.

unreliable in the long-term.  Physical interfaces change over the years.

>   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.

Not mutually exclusive to (a).

> (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.

This is still worthwhile doing, even if we don't fix pkcs12.

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

My preference is to say, in an RFC, that PKCS12 is obsolete, and that 
PKCS8 is the right answer.  Then we can beat up the Java/NSS/etc. 
vendors who are still stuck on PKCS12.

Also, whatever we do, it will need some variety of PQC algorithms/OIDs 
added.   I also have operational concerns about the read-modify-write
cycle needed by HSS.   Cold-storage/backup of HSS keys could be an 
operational nightmare, and while it hopefully will never affect mail 
user agents, doing code signing on a desktop is completely realistic for 
smaller companies.

> 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.
>