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

[Deb Cooley <[e-mail]>]

Those are fair points.  I made assumptions and you know what they say...

Perhaps I'm not creative enough to see how it would/could work.  Wouldn't
be the first time.  LOL

Deb
[e-mail]

On Thu, Aug 12, 2021 at 7:19 AM Carl Wallace <[e-mail]>
wrote:

> Inline…
>
>
>
> apologies for being late to this party....
>
>
>
> Note:  everything here is about encryption keys:
>
>
>
> Hold on a minute.  All fine and good to say that 'a message be encrypted
> for each of your end points', but how does the RP get the public key for
> all of those end points?
>
> [CW] Therein lies the work to do.
>
>
>
> not like we have a directory or anything. Do you want a signed message
> from each end point?  Who is going to do that?
>
> [CW] No, I don’t want a signed message from each end point nor is a signed
> message necessary, only the certs.
>
>
>
> It won't work.
>
> [CW] This seems premature given “it” is not defined, but if the problem
> isn’t of interest as a pursuit right now that’s fine.
>
>
>
> If the big directory in the sky had panned out, then one could push all
> the public keys you wanted to your directory entry.  A RP could encrypt to
> you including all of your encryption keys.  Is there another way?
>
> [CW] I can have a mail server send an out of office note. Why can’t I have
> a mail server send a set of keys? Maybe for some well-known + appendage, as
> an example. I don’t know, as I am not saying I have a fleshed out an
> answer.
>
>
>
> Interoperability of private keys does matter.
>
> [CW] I did not say interoperability of private keys does not matter and I
> certainly have no beef with improving or replacing PKCS12. I only
> questioned why we were focusing exclusively on slinging around private keys
> and not on a way to avoid the need to do so especially with good hardware
> crypto modules available to most folks now.
>
>
>
> Key escrow of those private (encryption) keys does matter - so that they
> can be imported into whatever MUA you need.  (where you store the keys on
> that device is a whole other conversation).
>
> [CW] I am not sure if escrow of all encryption keys matters or if it only
> matters that messages are encrypted for a key that is escrowed. Maybe the
> escrowed key isn’t on any end point that I use but simply corresponds to
> another key in the set of keys that should be used when encrypting for me.
>
>
>
> PKCS#8 will do, as long as the MUA/device/whatever can match up the
> certificate w/ the key (sometimes not entirely trivial).
>
>
>
> As far as signature keys/certs go - feel free to get a new key for every
> device, no problem...
>
> [CW] Of course, so can we get there for encryption too? Ultimately, I’d
> like to copy/export private keys around less and use end-to-end encryption
> more and this thread was in the general neighborhood of those two aims,
> hence my comment.
>
>
>
> Deb Cooley
>
> [e-mail]
>
>
>
>
>
> On Thu, Aug 5, 2021 at 12:32 PM Carl Wallace <[e-mail]>
> wrote:
>
> <snip>
>
>     I don't know how I'd use the TEE in my phone with my laptop/desktop
> for email.
>     I imagine that one could run PKCS11 across the USB cable, but I'm
> unaware of
>     any actual software to do that.  That sure would be a nice thing to do.
> [CW] I was not suggesting that but instead that a message be encrypted for
> each of your end points. I'm not sure why we are clinging to one encryption
> key per person. Amongst the keys messages for you are encrypted could be
> the key that you printed out, for example. I am not suggesting we’d not
> benefit from improved private key formats, but am suggesting we may be able
> to do better than slinging private keys around in some cases.
>
>
>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>
>