[Medup] On Extra Keys in pEp
"Hernâni Marques (p≡p foundation)" <hernani.marques@pep.foundation> Wed, 29 March 2023 04:05 UTC
Return-Path: <hernani.marques@pep.foundation>
X-Original-To: medup@ietfa.amsl.com
Delivered-To: medup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB7C1522C8 for <medup@ietfa.amsl.com>; Tue, 28 Mar 2023 21:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqrEHhCdpgnB for <medup@ietfa.amsl.com>; Tue, 28 Mar 2023 21:05:19 -0700 (PDT)
Received: from dragon.pibit.ch (dragon.pibit.ch [185.203.114.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B99C14F726 for <medup@ietf.org>; Tue, 28 Mar 2023 21:05:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id D93F321401B4 for <medup@ietf.org>; Wed, 29 Mar 2023 06:05:15 +0200 (CEST)
Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOj4VpiTvtGt for <medup@ietf.org>; Wed, 29 Mar 2023 06:05:15 +0200 (CEST)
Received: from [192.168.30.117] (fs9875f8f8.knge201.ap.nuro.jp [152.117.248.248]) by dragon.pibit.ch (Postfix) with ESMTPSA id 35B01214007B for <medup@ietf.org>; Wed, 29 Mar 2023 06:05:14 +0200 (CEST)
Message-ID: <6cb4bf8e-50c3-8b0d-212b-918c4abb0e00@pep.foundation>
Date: Wed, 29 Mar 2023 06:05:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0
Content-Language: en-US
From: "Hernâni Marques (p≡p foundation)" <hernani.marques@pep.foundation>
To: medup@ietf.org
X-Pep-Version: 2.1
Content-Type: multipart/mixed; boundary="15e5509d278c901046501d91569db9a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/medup/kG26qHMUoXOWMB17W97bgwucbSU>
Subject: [Medup] On Extra Keys in pEp
X-BeenThere: medup@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Missing Elements for Decentralized and Usable Privacy <medup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/medup>, <mailto:medup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/medup/>
List-Post: <mailto:medup@ietf.org>
List-Help: <mailto:medup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/medup>, <mailto:medup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2023 04:05:22 -0000
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/
- [Medup] On Extra Keys in pEp Hernâni Marques (p≡p foundation)
- Re: [Medup] On Extra Keys in pEp Hernâni Marques (p≡p foundation)
- Re: [Medup] On Extra Keys in pEp Neal H. Walfield