From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 08CA46DE0EE7 for ; Sat, 25 May 2019 11:04:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.162 X-Spam-Level: X-Spam-Status: No, score=-0.162 tagged_above=-999 required=5 tests=[AWL=0.039, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgNdejBbiFK1 for ; Sat, 25 May 2019 11:04:12 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTPS id A404E6DE1098 for ; Sat, 25 May 2019 11:04:11 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1558807450; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : from; bh=iz2bfZ8OZwd29hUW585XIct1e37YrRt2rwqWch3ePZA=; b=m+KsZuSxj6G5SfVXnN2ZeqV0Wwcxjo06WIm82Dms0tnolTAkmgqkDlpU XirrnskeeBYHcoUrgQwKZcK7wwmHBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1558807450; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : from; bh=iz2bfZ8OZwd29hUW585XIct1e37YrRt2rwqWch3ePZA=; b=ZUtuIZDGsY7Oeh8dKqrkoZYsAWBXCiwj/QJDPmdTXvVwHLJZX22cc7rF e9s6fNsn5SbmkdMo+GK2fbYcoq3IyBlY17HH4h8z1pMs5avFFm/Xo+5Fnp RczmIvzWud7xhYhJB4iO1Un642t+S6TPtUaWp5BZGNjdcloAwV7K7TpPxc g+n30kihVKXY5f6fHwkiVdIK9LoJhewyz8TT2aZ1oVQBcraWBvWKa/WEY4 yT/nIc7wauDMUzaP5WnHpF9z08jih5V7KzJFCxO1exlTmno3IiMhH+tQbn alnDU2oxRxXKjgwShMhG2ckMr3tSHCK6XCMA63ddBRHNZcm+SpSnKg== Received: from fifthhorseman.net (cpe-74-71-53-242.nyc.res.rr.com [74.71.53.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id C2303F9A1 for ; Sat, 25 May 2019 14:04:10 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id DB5AB2024B; Sat, 25 May 2019 14:04:07 -0400 (EDT) From: Daniel Kahn Gillmor To: Notmuch Mail Subject: revision 3: easing access to the cryptographic envelope Date: Sat, 25 May 2019 14:04:02 -0400 Message-Id: <20190525180406.30965-1-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2019 18:04:13 -0000 This is the third revision of the series originally posted at id:20190424183113.29242-1-dkg@fifthhorseman.net (revision 2 was at id:20190520032228.27420-1-dkg@fifthhorseman.net) This series addresses comments raised by David Bremner in his review. Thanks, Bremner! The most significant change here is that notmuch-show in --format=json or --format=sexp now always emits a "crypto" member for every message, regardless of whether there is any cryptographic envelope. In the case where there is no cryptographic envelope, the "crypto" member will be empty. ------ E-mail structures are potentially arbitrarily complicated. Cryptographic protection standards like S/MIME and OpenPGP or PGP/MIME are often applicable to some elements of some messages. Last year's "E-Fail" attacks made it clear that trying to provide normal users with cryptographic protections on piecemeal parts of an e-mail message is a recipe for disaster, both from an implementation perspective and a user experience perspective. I've argued in more detail at [0] about the need to treat cryptographic protections at the message level, rather than at the subpart level. [0] https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html This series makes "notmuch show" track and emit message-wide cryptographic state, providing an interface that simple clients that use "notmuch show" can rely on for their UI and UX. It doesn't yet apply this layer to the emacs interface, because at the moment many users of the emacs interface are nerds who are as likely to understand the intricacies of MIME structure as anyone, and for the moment, just augmenting the notmuch show schemata in a sensible way is enough of a chunk to bite off. (though i'd be happy to review and support the use of this per-message cryptographic state in notmuch-emacs if/when this lands!) I'd appreciate any review and feedback! Regards, --dkg