Subject: [Medup] On Extra Keys in pEp

From: Hernâni Marques (p≡p foundation)<[email-masked]>
Date: Wed, 29 Mar 2023 06:05:11 +0200

Dear folks

At yesterday's MEDUP Side Meeting the question was raised from someone  
from a Japanese University (cannot remember the name anymore...), that  
end-to-end encryption can impose issues if you've an organizational  
setting with the regulatory framework to be able to decrypt work-related  
messages for archiving purposes (in Switzerland, e.g., you need to able  
to show all relevant documentation of a company for the last 10 years).

That's of course a problem---the proposition here is to have an Extra  
Key basically being an additional public key to which you encrypt  
*additionally* all outgoing messages; the corresponding secret key is  
then hold, e.g., by a CISO or at least a very small group of people who  
hold that in a secure place with restricted access; in case mails must  
be disclosed, the corresponding secret key can be used to decrypt  
(specific) messages. UX-wise it's also important that the employees  
clearly see that the outgoing messages are also encrypted to an  
*additional* key.

We describe that in our general draft, point 7.3, briefly:

https://datatracker.ietf.org/doc/html/draft-pep-general-02#section-7.3

Running Code exists and can be found here:

https://gitea.pep.foundation/pEp.foundation/pEpEngine/src/branch/master/src/message_api.c

You also find lines like that, reflecting what's written in 7.3; e.g.,  
code line 3261 to 3263

[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]

Any thoughts on that approach?

Greets --hernani

--  
p≡p foundation: https://pep.foundation/