Subject: [openpgp] email death certificates

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 14:05:00 -0400

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"

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Derek Atkins" <[email-masked]>
Date: Fri, 23 Aug 2019 14:08:13 -0400

There is the "designated revoker" feature?
Not sure offhand if there are reason-codes.

-derek

On Fri, August 23, 2019 2:05 pm, Michael Richardson wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: David Shaw <[email-masked]>
Date: Fri, 23 Aug 2019 14:25:09 -0400

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Aug 2019 20:16:23 +0100

Hiya,

(bit off topic, but whatever... ;-)

On 23/08/2019 19:05, Michael Richardson wrote:
> but it rather needs to be signed.

25+ years ago I worked on X.400 mail. The X.400 specs had a
recipient deceased non-delivery notification IIRC. I had a
quick look but didn't find a reference so I guess that could
be either a figment of my imagination or another demonstration
that the OSI people's main error was being too far ahead of
the implementations I guess;-)

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 20:03:24 -0400

> 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.

The designated revoker is singular.

There is no k-of-n (or rather K) threshold the way that signature on UIDs
works.  If there was N signatures binding [email-masked] to key 0x12345678,
then it would be nice if the self-sign on the key could set a value k,
which if at least K entities revoke their signature (not just expire) with
an identical reason, would signal that the key<->UID is no longer valid.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 24 Aug 2019 12:46:28 +0000

Stephen Farrell <[email-masked]> writes:

>25+ years ago I worked on X.400 mail. The X.400 specs had a recipient
>deceased non-delivery notification IIRC

This is what an RFC822 address looks like in a certificate:

  rfc822Name     IA5String

This is what an X.400 address looks like  in a certificate:

	ITU-Braindamge ::= SEQUENCE {
		built-in-standard-attributes		SEQUENCE {
			country-name  [ APPLICATION 1 ]	CHOICE {
				x121-dcc-code				NumericString,
				iso-3166-alpha2-code		PrintableString
				},
			administration-domain-name
						  [ APPLICATION 2 ]	CHOICE {
				numeric						NumericString,
				printable					PrintableString
				},
			network-address			  [ 0 ]	NumericString OPTIONAL,
			terminal-identifier		  [ 1 ]	PrintableString OPTIONAL,
			private-domain-name		  [ 2 ]	CHOICE {
				numeric						NumericString,
				printable					PrintableString
				} OPTIONAL,
			organization-name		  [ 3 ]	PrintableString OPTIONAL,
			numeric-use-identifier	  [ 4 ]	NumericString OPTIONAL,
			personal-name			  [ 5 ]	SET {
				surname				  [ 0 ]	PrintableString,
				given-name			  [ 1 ]	PrintableString,
				initials			  [ 2 ]	PrintableString,
				generation-qualifier  [ 3 ]	PrintableString
				} OPTIONAL,
			organizational-unit-name  [ 6 ]	PrintableString OPTIONAL,
			}
		built-in-domain-defined-attributes	SEQUENCE OF {
			type							PrintableString SIZE(1..64),
			value							PrintableString SIZE(1..64)
			} OPTIONAL
		extensionAttributes					SET OF SEQUENCE {
			extension-attribute-type  [ 0 ]	INTEGER,
			extension-attribute-value [ 1 ]	ANY DEFINED BY extension-attribute-type
			} OPTIONAL
		}

Given that, I would hope that X.400 not only includes a recipient deceased
non-delivery notification but also a detailed record of what the cause of
death was, a complete autopsy report, and an address to send flowers to.

Peter.

---

From: David Shaw <[email-masked]>
Date: Sat, 24 Aug 2019 23:53:03 -0400

> an identical reason, would signal that the key<->UID is no longer valid.

Designated revoker is not quite singular.  You can have more than one designated revoker on a given key - it is true, though, that any single one of them can revoke the key.

I'd be somewhat afraid to use a scheme where people not chosen by me could "gang up" and cause a UID to be revoked.  Or for that matter, a single angry person could make N keys, sign the UID and then revoke that signature with each of those N keys.

Designated revoker lets me, as the key owner, pick who is allowed to kill my key.

David

---

From: Heiko Stamer <[email-masked]>
Date: Sun, 25 Aug 2019 10:35:26 +0200

On 25 Aug, 2019, at 05:53, David Shaw wrote:

> Designated revoker is not quite singular.

Right. Using a threshold signature scheme you can share
the trust among multiple parties: https://nongnu.org/dkgpg/

Bests,
--
Heiko

---

From: Jon Callas <[email-masked]>
Date: Tue, 27 Aug 2019 12:44:48 -0700

> On Aug 23, 2019, at 11:05 AM, Michael Richardson <[email-masked]> wrote:
> 

Yes, as others have said, designated revokers and reason-for-revocation are part of this, as would be even human-readable notations. 

In PGP, we had key-splitting and those one could with that product key-split a revoker key. It was an obvious use case for us, even.

	Jon

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 20:29:24 -0400

> Yes, as others have said, designated revokers and reason-for-revocation
    > are part of this, as would be even human-readable notations.  

    > In PGP, we had key-splitting and those one could with that product
    > key-split a revoker key. It was an obvious use case for us, even.

The designated revoker seems to require advance planning, as does the
key-splitting.   People rarely do advance planing on accidential death, nor
on getting fired.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jon Callas <[email-masked]>
Date: Tue, 27 Aug 2019 23:28:25 -0700

> On Aug 27, 2019, at 5:29 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
>>> On Aug 23, 2019, at 11:05 AM, Michael Richardson <mcr+ietf@sandelman..ca> wrote:
>>> 

You are, of course correct. 

The same issue applies to wills and inheritance, and I'm not sure there's a better solution, at least not until we get time machines. Then if you die, you can go back in time to when you were alive and set everything up then. Or so it says in the manual.

	Jon