Re: [lamps] HP Issue: Bcc Handling
Russ Housley <housley@vigilsec.com> Fri, 02 October 2020 14:33 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7E3A10D8 for <spasm@ietfa.amsl.com>; Fri, 2 Oct 2020 07:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVVfC9fvr1hO for <spasm@ietfa.amsl.com>; Fri, 2 Oct 2020 07:33:12 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55F43A108B for <spasm@ietf.org>; Fri, 2 Oct 2020 07:33:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2C6C0300B53 for <spasm@ietf.org>; Fri, 2 Oct 2020 10:33:10 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qobDHM_SYdTv for <spasm@ietf.org>; Fri, 2 Oct 2020 10:33:08 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C8E79300ADB; Fri, 2 Oct 2020 10:33:08 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <alpine.DEB.2.22.394.2010021410290.55994@softronics.hoeneisen.ch>
Date: Fri, 02 Oct 2020 10:33:10 -0400
Cc: IETF LAMPS WG <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F39D531C-A777-4318-93A7-C8C95F39A94E@vigilsec.com>
References: <alpine.DEB.2.22.394.2010021410290.55994@softronics.hoeneisen.ch>
To: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/xg4EHgnnS-0CmVp9BaH1qbNauI4>
Subject: Re: [lamps] HP Issue: Bcc Handling
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 14:33:14 -0000
Bernie: Please take a look at RFC 5322, Section 3.6.3. The proposed direction seems to be consistent, but you probably want to cite this section. Russ > On Oct 2, 2020, at 8:24 AM, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> wrote: > > Below a summary of the issue on 'Bcc Handling'. If anybody wishes to discuss this topic further or does not agree with the conclusion, please speek up within the next 10 days! > > At the bottom of this email there are some open questions that need answers. > > cheers, > Bernie > > > Text from slide: > > - Encrypted Messages with Bcc need to be split: > > 1) The same Message to all To and Cc recipients, without Bcc HF > > 2) Message(s) to Bcc recipient(s) vary among implementations > > a) One Message per Bcc recipient > Bcc HF contains recipient address the message is sent to > > b) The same Message for all Bcc recipients > Bcc HF with an indication, e.g. "Undisclosed recipients" > > c) The same Message for all Bcc recipients > without Bcc HF (same as same as 1) > > - No specification on this found in S/MIME > > - 2a is most privacy-preserving, but may result in many Messages > > - 2b and 2c are easier/more efficient to handle, but leak privacy > information via encryption keys and certs > > > Conclusion at IETF-108 (as I understood): > > - 2a is the way forward > > - 2a has been claimed to be already part of the S/MIME standards > > > Open questions: > > - Where (RFC & Section) is it standardized that 2a is to be used, > so that we could refer to? > > - What is the standardization state of 2b and 2c that appear to > be implemented? forbidden, discouraged, deprecated, ... ?
- [lamps] HP Issue: Bcc Handling Bernie Hoeneisen
- Re: [lamps] HP Issue: Bcc Handling Russ Housley
- Re: [lamps] HP Issue: Bcc Handling Daniel Kahn Gillmor
- Re: [lamps] HP Issue: Bcc Handling Russ Housley
- Re: [lamps] HP Issue: Bcc Handling Alexey Melnikov