Re: [Medup] On Extra Keys in pEp (Neal H. Walfield)

["Neal H. Walfield" <[e-mail]>]

On Fri, 31 Mar 2023 10:19:07 +0200,
Metin Savignano wrote:
> I hope it's okay when I jump in to share my thoughts.

I'm happy you did.

> >> [snip]
> >> 
> >>    // Ensure we don't encrypt to extra keys if this is a non-org account
> >>     if (!(target_id->flags & PEP_idf_org_ident))
> >>         extra = NULL;
> >> 
> >> [/snip]
> > 

...

> However, I’d like to make one step back and ask: why do we need the extra key for that scenario?
> 
> The reason I’m asking is that this requirement is not new at all, and the solution to it that I am aware of is that the organization must keep a copy of the private key of all its users.
> 
> That’s why it's recommended to split keys between signing keys and encryption keys: so the organization can keep a copy of the private key, but not of the signing key, which allows it to decrypt messages, but not to step into the user’s identity.
> 
> So I think the solution should be to allow the organization to get the private key, shouldn’t it? Or am I missing something here?

Key escrow is a possible solution to this problem.  But, some
organizations don't want it, and if it is possible to come up with
alternative approaches that also satisfy other requirements like
archiving, and out-of-office employees then we should.

One of the problems that extra keys solves (I think) is that it
provides visibility to the sender that their message may be read by
someone else without the recipient having to actively pass it on to
the third party.  I'd argue that this is a good property, and I think
that is what Hernani is referring to when he wrote:

> UX-wise it's also important that the employees  
> clearly see that the outgoing messages are also encrypted to an  
> *additional* key.

Neal