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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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

Since in this discussion people repeatedly call PKCS#12 a “protocol”, I think that we do.

 

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