Re: [openpgp] email death certificates

David Shaw <dshaw@jabberwocky.com> Fri, 23 August 2019 18:25 UTC

Return-Path: <dshaw@jabberwocky.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C57C120864 for <openpgp@ietfa.amsl.com>; Fri, 23 Aug 2019 11:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 L3V732wz4f5y for <openpgp@ietfa.amsl.com>; Fri, 23 Aug 2019 11:25:10 -0700 (PDT)
Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94E5120808 for <openpgp@ietf.org>; Fri, 23 Aug 2019 11:25:10 -0700 (PDT)
Received: from [10.51.0.10] (unknown [144.121.22.178]) by mail.jabberwocky.com (Postfix) with ESMTPSA id C0B7A207889B; Fri, 23 Aug 2019 14:25:09 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: David Shaw <dshaw@jabberwocky.com>
In-Reply-To: <5409.1566583500@dooku.sandelman.ca>
Date: Fri, 23 Aug 2019 14:25:09 -0400
Cc: openpgp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <19127C2D-F9AA-4201-9A72-8C0A43B5D767@jabberwocky.com>
References: <5409.1566583500@dooku.sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/NPGKRIQ9t83E6IPX9LLN_V7cgjQ>
Subject: Re: [openpgp] email death certificates
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 18:25:12 -0000

On Aug 23, 2019, at 2:05 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> I had the unfortunate duty to remove an email address from a community
> email list because the person had passed away.  I wonder how many other
> lists this rather active person is on, and how many years it will be
> before the lists are cleaned up.
> 
> When my dad passed away in the fall of 2003, it wasn't until the end of April
> the following year that the University cleaned up his email account.  There
> was clearly a need to keep the account open for quite some time due to
> other university business that hadn't yet closed.
> 
> I was thinking this morning about an SMTP responses, a 55x-type,
> but it rather needs to be signed.  Sigh, 2019, and still not enough
> useful email security to do this.  But still.
> 
> Is there something in openpgp spec that I'm missing here?
> I don't think that revoking the key is the right thing.
> In particular, nobody may know how to find the private key to revoke it.
> What's wanted is a revocation of the PGP signature with a reason.
> 
> Has anyone given any thought to this?
> 
> I suppose it might also apply to "does not work here anymore"

There is a "Reason for Revocation" subpacket for the revocation signature.  It contains both a machine-readable byte giving various reasons for revocation (key superseded, compromised, or retired, user ID no longer valid, or a general "other"), followed by a human-readable string.

I suppose a death notification would be "key retired", with additional information (if any) given in the human-readable string.  This works with the designated revoker feature as well as the regular (self) revocation, so even if the private key is missing (or, being dead, the owner is unable to enter a passphrase) the key can still be revoked.

David