Subject: How are S/MIME private keys handled across MUAs?

From: vaibhav singh <[email-masked]>
Date: Thu, 17 Aug 2017 00:20:35 +0530

Hi,
I was looking at RFCs for S/MIME, and had a question: What if I am logged
into multiple clients(my mobile, a web application, Thunderbird) with an
email account, and I receive an encrypted email?

I can see that the encrypted email would be created with my public key,
and, assuming one public key for one email account, I will have one private
key which I will somehow make use of across all my MUAs. I could not think
of a simple way using which I will be able to sync my private key.

Is there any good way of sharing private keys across clients (maybe some
way of securely syncing files)? How do corporate clients resolve this
issue? Is there an RFC which I may have to refer to?

Another line of thinking; is it possible to create key pairs
(triplets?quadruplets?) wherein there could be multiple private keys
generated for a single public key? And, what about the other way round?

-- 

Regards,
Vaibhav Singh

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Aug 2017 15:53:11 -0400

The Asymmetric Key Package (the successor to PKCS#8) as described in RFC 5958 would be one way to securely move the private key.

Russ

> On Aug 16, 2017, at 2:50 PM, vaibhav singh <[email-masked]> wrote:
> 
> Hi,
> I was looking at RFCs for S/MIME, and had a question: What if I am logged into multiple clients(my mobile, a web application, Thunderbird) with an email account, and I receive an encrypted email?
> 
> I can see that the encrypted email would be created with my public key, and, assuming one public key for one email account, I will have one private key which I will somehow make use of across all my MUAs. I could not think of a simple way using which I will be able to sync my private key.
> 
> Is there any good way of sharing private keys across clients (maybe some way of securely syncing files)? How do corporate clients resolve this issue? Is there an RFC which I may have to refer to?
> 
> Another line of thinking; is it possible to create key pairs (triplets?quadruplets?) wherein there could be multiple private keys generated for a single public key? And, what about the other way round?
> 
> -- 
> 
> Regards,
> Vaibhav Singh

---

From: Dave Cridland <[email-masked]>
Date: Thu, 17 Aug 2017 08:46:03 +0100

On 16 Aug 2017 19:50, "vaibhav singh" <[email-masked]> wrote:

Hi,

As Russ says, the traditional way of handling this is to encrypt the
private key and send it around each client.

Another way would be to use PRE here (see Phillip Hallam-Baker's link sent
in the other thread), so that the key other people actually get is a Proxy
key, and each client has a proxy-decryptor key of its own - one special
client, with a stronger security stance, would be acting as the Proxy
Admin. There's little practical advantage in this, except that should one
client be compromised, you could revoke just that decryptor key. You do
need the re-encryption key to be held somewhere other than the clients,
though, since otherwise you can obtain the Proxy's private key through a
client compromise.

One thing that really doesn't work well here is if you want to use
hardware-backed cryptography (HSM, smartcards, etc). Here, you'd ideally
use a PRE mechanism again, but one in which the proxy re-encrypted to a
specific key (Phillip Hallam-Baker's scheme will not do this). The closest
I can get here in practical terms is to keep the decryptor keys encrypted
using a HSM-backed private key, which isn't - quite - the same.

Of course, without PRE involved, if you want to use an HSM then you can
only decrypt your email in the one client you have the HSM at, which makes
things logistically frustrating.

Dave.

-- 

Regards,
Vaibhav Singh

---

From: Al Arsenault <[email-masked]>
Date: Thu, 17 Aug 2017 09:59:33 -0400

It's a decade in the past, but the entire SACRED working group was
established to address this exact problem.  See e.g. RFC 3767.
https://www.rfc-editor.org/rfc/rfc3767.txt