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)]

[Eliot Lear <[e-mail]>]

I REALLY hope not.  Are we REALLY struggling with that point?

Eliot

On 05.08.21 15:47, Blumenthal, Uri - 0553 - MITLL wrote:
> Am I the only one who thinks there's a difference between protocols and data formats?
>
> --
> Regards,
> Uri
>   
> There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
>                                                                                                                                       -  C. A. R. Hoare
>   
>
> On 8/5/21, 08:18, "Spasm on behalf of Daniel Kahn Gillmor" <[e-mail] on behalf of [e-mail]> 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.
>
>      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
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm