Re: [Medup] On Extra Keys in pEp

"Neal H. Walfield" <neal@walfield.org> Thu, 30 March 2023 07:34 UTC

Return-Path: <neal@walfield.org>
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 337B9C15C28B for <medup@ietfa.amsl.com>; Thu, 30 Mar 2023 00:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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 fP0f3uZO1LyY for <medup@ietfa.amsl.com>; Thu, 30 Mar 2023 00:34:26 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de [202.61.250.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B34AC14CEFC for <medup@ietf.org>; Thu, 30 Mar 2023 00:34:25 -0700 (PDT)
Received: from p5de9289a.dip0.t-ipconnect.de ([93.233.40.154] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <neal@walfield.org>) id 1phmne-0007NC-Mf; Thu, 30 Mar 2023 09:34:22 +0200
Received: from grit.huenfield.org ([192.168.20.9] helo=grit.walfield.org) by forster.huenfield.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <neal@walfield.org>) id 1phmne-001XCO-5S; Thu, 30 Mar 2023 09:34:22 +0200
Date: Thu, 30 Mar 2023 09:34:21 +0200
Message-ID: <87y1ner8ua.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: "\"Hernâni Marques (p≡p foundation)\"" <hernani.marques@pep.foundation>
Cc: medup@ietf.org
In-Reply-To: <6cb4bf8e-50c3-8b0d-212b-918c4abb0e00@pep.foundation>
References: <6cb4bf8e-50c3-8b0d-212b-918c4abb0e00@pep.foundation>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-SA-Exim-Connect-IP: 192.168.20.9
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Scanned: No (on forster.huenfield.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/medup/1Qp72V6FQL3UDvKioJB_TotC4_A>
Subject: Re: [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: Thu, 30 Mar 2023 07:34:28 -0000

Hi Hernani,

On Wed, 29 Mar 2023 06:05:11 +0200,
Hernâni Marques (p≡p foundation) wrote:
> 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]

Can you explain what a non-org account is, please.

> Any thoughts on that approach?

I see two aspects to this problem: when internal users (e.g.,
employees) send an encrypted message, and when external users send an
encrypted message (e.g., customers).

When an internal user sends a message, they can be trained to accept
the additional key.  That's easy.

But,when a customer sends an encrypted message to an employee, do they
automatically use the additional key?  If they have to opt in, how
does an organization decrypt messages for employees who are sick or on
vacation?

Thanks,

Neal