Subject: [openpgp] Revoking Keys: Adding a superceded-by parameter

From: "Neal H. Walfield" <[email-masked]>
Date: Mon, 20 Jul 2015 12:27:10 +0200

Hi,

Section 5.2.3.23 describes the reason-for-revocation subpacket.  One
reason is that the key has been superseded.  Unfortunately, there is
no standard, machine-readable way to indicate what the new key is.

I propose that the description field be augmented to include optional
email style headers.  Further, we specify the following header to
specify the new key:

  Superceded-by: fingerprint

Finally, we add that if this extension is used, the whole message
should be signed by the new key (to show that the user controls both
keys).

This amendment has the advantage that it is completely backwards
compatible with existing implementations.

Thoughts?

Thanks,

Neal

---

From: Werner Koch <[email-masked]>
Date: Mon, 20 Jul 2015 17:14:18 +0200

>   Superceded-by: fingerprint

I think it is better to have a signature subpacket or notation data to
the same effect.  This has the advantage that it can also be used with a
non-revoked key or data signature to declare a plan to supercede a key
in the near future.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Mon, 20 Jul 2015 22:03:04 +0200

Hi Werner,

At Mon, 20 Jul 2015 17:14:18 +0200,
> non-revoked key or data signature to declare a plan to supercede a key

This is a good point.  Either approach that you propose seems
reasonable to me.

Thanks,

Neal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 22 Jul 2015 01:13:16 +0200

On Mon 2015-07-20 22:03:04 +0200, Neal H. Walfield wrote:
> At Mon, 20 Jul 2015 17:14:18 +0200, Werner Koch wrote:

This is a great idea.  Can you suggest a patch to the 4880bis draft that
Werner started?

      --dkg

---

From: "Neal H. Walfield" <[email-masked]>
Date: Sat, 25 Jul 2015 17:44:47 +0200

Hi,

At Wed, 22 Jul 2015 01:13:16 +0200,
> This is a great idea.  Can you suggest a patch to the 4880bis draft that

I decided to use a notation rather than a new signature subpacket.
This is because the signature subpacket namespace is tiny compared to
the notation data's namespace.

Please let me know how I can improve this.

Thanks!

:) Neal

From 6160a4f49c23b35f8cc7105197ecb145aa6be9ad Mon Sep 17 00:00:00 2001
From: "Neal H. Walfield" <[email-masked]>
Date: Sat, 25 Jul 2015 17:42:23 +0200
Subject: [PATCH] RFC4880bis: Describe the superseceded-by notation.

---
 misc/id/rfc4880bis/middle.mkd | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd
index 80c0a61..6465019 100644
--- a/misc/id/rfc4880bis/middle.mkd
+++ b/misc/id/rfc4880bis/middle.mkd
@@ -1317,6 +1317,18 @@ addresses.
 If there is a critical notation, the criticality applies to that
 specific notation and not to notations in general.
 
+The following notations are currently defined:
+
+       superseded-by: This notation is used within a "Reason for
+       Revocation" subpacket to indicate the key that superscedes this
+       one.  The value of the notation SHOULD be an OpenPGP message
+       containing the fingerprint of the new key printed in
+       hexadecimal form and signed with the new key.  If no key
+       supersedes this key, the value may instead be the 4 character
+       ASCII string "none".  This notation should only be respected if
+       the "Reason for Revocation" subpacket does not indicate that
+       the key was compromised (code: 2).
+
 #### {5.2.3.17} Key Server Preferences
 
 (N octets of flags)
-- 
2.1.4

---

From: Vincent Breitmoser <[email-masked]>
Date: Sat, 25 Jul 2015 22:41:30 +0200

On 25 Jul 2015, Neal H. Walfield wrote:
> This is because the signature subpacket namespace is tiny compared
> to the notation data's namespace.

I think I disagree with this.  It's true that the signature subpacket
namespace is not very large, but the numbers are that only ~30 subpacket
ids out of 100 are actually used.  If we ever get past 70, we might want
to think about how to deal with the problem (there is always the 8th bit
left for this purpose, too), until then unused namespace is wasted
namespace and we gain nothing by avoiding its use.

Are there any other standardized uses for the notation namespace? I am
only aware of proposed ones, and none which have very widespread use
outside of closed systems.

 - V

---

From: "Neal H. Walfield" <[email-masked]>
Date: Sun, 26 Jul 2015 04:16:24 +0200

Hi,

At Sat, 25 Jul 2015 22:41:30 +0200,
> outside of closed systems.

Are you arguing that since notations aren't used in practice that they
are probably not widely supported and it would be better to use a new
signature subpacket?  If not, what is your argument against
introducing a notation?

Thanks!

:) Neal

---

From: Vincent Breitmoser <[email-masked]>
Date: Sun, 26 Jul 2015 04:45:03 +0200

On 26 Jul 2015, Neal H. Walfield wrote:
> Are you arguing that since notations aren't used in practice that
> they are probably not widely supported and it would be better to use
> a new signature subpacket?  If not, what is your argument against
> introducing a notation?

I'm mostly thinking about consistency.  The signature subpacket
namespace seems like the natural place to put this piece of information,
right next to similar data like "reason for revocation".  We should not
place it in a different place unless there is good reason to do so.

 - V

---

From: Werner Koch <[email-masked]>
Date: Sun, 26 Jul 2015 12:04:04 +0200

> right next to similar data like "reason for revocation".  We should not

At the meeting we actually started a discussion to remove those reasons
for revocations.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Sun, 26 Jul 2015 12:02:22 +0200

Hi,

the minutes from the Prague meeting have not yet been posted but you can
look at them here:

  http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-openpgp

> namespace is not very large, but the numbers are that only ~30 subpacket

subpackets denoted data required for proper operation of the protocol or
to implement extra features.  I do not consider information of a
superceeding key important for the protocol; thus a notation would the
right way.

> only aware of proposed ones, and none which have very widespread use

A small problem with the notations is that you can only use the non-IETF
namespace (e.g. using a domain name based name) which make the notation
data unnecessary long.  At the meeting it was suggested that the process
of allocating a new notation in the IETF namespace will be simplified
for example by allow expert review.  This will make it easier to add new
small notions in the future (and perhaps also key flags).

Adding new subpackets is a more delicate thing and should definitely not
be done "ad-hoc" but using a proper process.

Shalom-Salam,

   Werner

---

From: Vincent Breitmoser <[email-masked]>
Date: Sun, 26 Jul 2015 16:38:34 +0200

> At the meeting we actually started a discussion to remove those reasons

As in, deprecate the subpacket?  Or move it towards notation data?
Either way I'm in favor of this.

> subpackets denoted data required for proper operation of the
> protocol or to implement extra features.  I do not consider
> information of a superceeding key important for the protocol; thus a
> notation would the right way.

What I would like to avoid is ending up with this as the only defined
notation name while stuff like "Policy URI" and "Reason for Revocation"
exist as subpackets.  Even if notation data is the "right" place to put
this, there is at least some value in consistency.

That said, I would not mind the superceded-by data as either a subpacket
or notation data name.

> At the meeting it was suggested that the process of allocating a new
> notation in the IETF namespace will be simplified for example by allow
> expert review.  This will make it easier to add new small notions in
> the future (and perhaps also key flags).

+1 to this, especially for notations where the meaning is unambiguous
(like this case), it would be helpful to have a relatively short
assignment process.

 - V

---

From: Werner Koch <[email-masked]>
Date: Mon, 27 Jul 2015 08:22:14 +0200

> As in, deprecate the subpacket?  Or move it towards notation data?

The discussion was around the idea to deprecate the use of the reason
for revocation because it is pretty complicated to make real use of it
due to non-easy semantics.

> this, there is at least some value in consistency.

We can't avoid all inconsistencies created in the past or inherited from
existsing implementaions.

Shalom-Salam,

   Werner

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Mon, 27 Jul 2015 10:03:44 +0200

On 07/27/2015 08:22 AM, Werner Koch wrote:
> The discussion was around the idea to deprecate the use of the
> reason for revocation because it is pretty complicated to make real
> use of it due to non-easy semantics.

I can think of at least one specific use case where this information
is needed. I'm somewhat ambivalent to whether this is given as
specific subpacket or a notation; if we were to implement it again the
latter would make sense, but not sure if it is worthwhile breaking
backwards compatibility for deprecating it.

Anyways, the use case is you have a revocation certificate as part of
the will and a copy is stored with the executor. The reason for
revocation states "This key is revoked by the Power of Attorney
granted to the executor of the Last Will and Testament of Y", and
likely contains a version identifier to be able to trace any non
sanctioned use.

Obviously you wouldn't give your attorney a copy of your private key,
but you do want them to be able to follow the instructions for
revoking and notifying the appropriate channels in the event a stone
falls in the back of your head.

The reason for revocation in this case at least should be a good
indicator to other holders of the key about the situation and provides
valuable information.

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Aut disce aut discede
Either learn or leave