Subject: Re: Need for secured email delegation workflow

From: Dave Cridland <[email-masked]>
Date: Tue, 8 Aug 2017 16:26:53 +0100

On 14 July 2017 at 15:42, Yoav Nir <[email-masked]> wrote:
> While it may be OK to share a key with my phone (but too difficult to do
> securely in practice), sharing with a delegate is hairy on many different
> layers. But still it’s the same issue.

I think it's all solvable using Proxy Re[en]cryption, but that seems
to be a little fraught with patents at the moment.

Dave.

---

From: vaibhav singh <[email-masked]>
Date: Tue, 8 Aug 2017 22:55:03 +0530

> to be a little fraught with patents at the moment.

I am not comfortable with sharing my private key with anyone, be it the
proxy user itself. I believe that is a requirement for Proxy Reencryption,
please correct me if I may have interpreted it wrongly.

The root problem:

*How will S/MIME work with delegation? *
For sending emails on behalf of the principal/manager:

The delegate will have access to his private key, plus all the receiver's
public keys. Encryption here is trivial, encrypting the mail can be done
only with the delegates' private key. On the other side, the receivers will
be verifying the delegates' signature, and as the delegate is authorized to
act on behalf of his manager, the receivers may not have issues trusting
the delegate. The only thing that has to be ensured here is that there has
to be a provision for all the receivers to know that this delegate is
acting and signing mails on behalf of his manager, as in,
* the list of *all* delegates and managers has to be openly accessible by
any user within the network.*
For receiving mails on behalf of the principal/manager:

Here lies the main issue of* the delegate not able to decrypt any encrypted
messages coming for the Manager. *Reason: The delegate will not have the
manager's private key.

However, given that the list of every manager and delegate is openly
available in the network, what can happen is while creating a message, the
MUA could use the delegate's public key while encrypting the message, or,
in case of multiple delegates for that manager, could generate a one time
use key which could be used to encrypt the message, copy the key n number
of times(where 'n' is the number of delegates), encrypt all new key copies
with the public key of the delegates and bundle them along with the
encrypted message. This is how key-encryption-key (KEK) works while sending
an encrypted S/MIME message to multiple receivers; we can use the same
logic with multiple delegates here.

The only issue here is that I feel the concept of public-private keys is
getting diluted here; when a person is getting a signed mail, he is not
getting the mail from the manager as such, he is getting the mail signed by
his delegate/PA. Similar is the case when creating the mail on the other
side.

The other issue is the MIME could get really big, but then again, most
people would not have multiple delegates/PA.

Atleast, I am not sharing my private key with anyone here. This would
definitely make me sleep better at night.

Regards,
Vaibhav Singh

---

From: Dave Cridland <[email-masked]>
Date: Tue, 8 Aug 2017 21:57:13 +0100

> please correct me if I may have interpreted it wrongly.

You have interpreted it incorrectly.

The proxy holds a key that will change a message encrypted to its
proxy key into a message encrypted for an authorized key. It cannot
decrypt the message to plaintext itself.

All quite bleeding edge, all quite patent-encumbered, but look at
Mathew Green's work for details - he's been researching very heavily
in this field.

Dave.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Aug 2017 20:45:12 -0400

> Mathew Green's work for details - he's been researching very heavily

​Proxy re-encryption has been around for 25 years. It is hardly cutting
edge.

There is a patent on the DRM use expiring soon. But the original Blaze
scheme does everything I need. It certainly isn't 'all' encumbered.

It seems to me that the cryptographers got a particular mathematical
property into their head as 'essential' which really isn't if you design
protocols. So I don't need the paired stuff.

I wrote some stuff on this:
http://www.defaultdenysecurity.com/Professional/Patents/Recryption.html

If you know of patent claims on the DH based scheme I describe, please let
me know.

---

From: Dave Cridland <[email-masked]>
Date: Sat, 12 Aug 2017 11:44:24 +0100

On 12 Aug 2017 01:45, "Phillip Hallam-Baker" <[email-masked]> wrote:

I'm not sure if I have ever been so happy to be proven wrong,  thanks.