On Tue, Aug 8, 2017 at 8:56 PM, Dave Cridland <dave@xxxxxxxxxxxx> wrote:
The root problem:
How will S/MIME work with delegation?
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.
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.
Regards,
On 14 July 2017 at 15:42, Yoav Nir <ynir.ietf@xxxxxxxxx> 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.
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.
Vaibhav Singh
Dave.