Re: Need for secured email delegation workflow

> On 14 Jul 2017, at 7:30, vaibhav singh 
> <vaibhavsinghacads(_at_)gmail(_dot_)com> wrote:
>
>
>
> On Thu, Jul 13, 2017 at 12:42 AM, Michael Richardson 
> <mcr+ietf(_at_)sandelman(_dot_)ca <mailto:mcr+ietf(_at_)sandelman(_dot_)ca>> 
> wrote:
>
> vaibhav singh <vaibhavsinghacads(_at_)gmail(_dot_)com 
> <mailto:vaibhavsinghacads(_at_)gmail(_dot_)com>> wrote:
>     > First of all, I am kind of new and still learning how email
>     > infrastructure fits in, so please feel free to highlight any glaring
>     > issues with my logic.
>
>     > I was working on implementing Email Delegation for my email server, and
>     > felt a need to highlight a couple of things.
>
>     > 1.) I could not find a place where this workflow is outlined. It seems
>     > like everyone, from Microsoft to Google, have an implementation for
>     > email delegation, and they are all kind of doing their own thing.
>
> I think that when you say "email delegation", you mean where a manager
> (or other person) authorizes their "PA" (personal assistant, formerly known
> as "secretary") to send email on their behalf.  Back in the days of BNR COCOS
> it was very common thing for middle management, but even in those dark days
> of mainframe based email, it was usually accomplished by having the PA log in
> with the manager's email.
>
> It's good that microsoft(outlook) and google(gmail) have realized that
> sharing passwords is a dumb thing.  I think that in the walled gardens of
> those systems, that the email delegation is accomplished entirely within
> their MUA/MTA.
>
> Exactly!! That is the workflow I am talking about. However, I feel that this 
> could be something which could be used for other things as well, for example, 
> in the place where I work, we have some automated tools where a user can 
> input certain data and the tool will send mails to our group email address on 
> behalf of the user.
>
> Couple of terms:
>
> manager = The user who wants to delegate some other user to manage his 
> account on his behalf.
I think “principal” is a better term. I would expect “manager” to authorize b 
to manage on behalf of c.
> delegate = The user who has to get access to the manager's account.
>
> entity = Any email user.
>
> Please note that email delegation could also cover cases like creating 
> folders, deleting folders etc in the manager's account.
>
>
> This concept, in my opinion, could be generalized to include "entities" which 
> could request permission to send mails on behalf of some other "entity". Sort 
> of like OAUTH with emails, if you will. I am still hazy with all the details 
> and not sure about how useful this could be, but it seems promising to me.
>
> Another question which I was not clear about was how S/MIME would be 
> integrated with delegation. For example, suppose the delegate were to create 
> a signed email on behalf of the manager, in which case the manager would have 
> to share his private key with the delegate. This would definitely not be 
> secure.
This is part of a wider issue. Even without delegation, if I use my own email 
account with several MUAs (say, my laptop and my phone), where is the private 
key stored?  Is it shared between laptop and phone?

You end up reading encrypted mail only using one MUA, which is one more thing 
dragging the use of S/Mime down.

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.

Yoav

signature.asc
Description: Message signed with OpenPGP