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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Neal--

Thanks for this.  Having a concrete proposal to work from is really
useful.

On Sat 2015-07-25 11:44:47 -0400, Neal H. Walfield wrote:
> From 6160a4f49c23b35f8cc7105197ecb145aa6be9ad Mon Sep 17 00:00:00 2001
> From: "Neal H. Walfield" <[e-mail]>
> 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)

A couple questions about this:

 * Why structure the notation data contents as human-readable text?
   for well-structured data, binary seems more efficient.

 * Why allow "none" -- if there is no key superceding the existing key,
   then this notation would simply not be present.

 * Why use the OpenPGP fingerprint?  we're in the process of trying to
   improve things like designated revoker to avoid having cryptographic
   assertions bound to the fingerprint.  What if we just included the
   full OpenPGP public key packet here instead?  Implementations that
   care about the fingerprint can derive the fingerprint from the public
   key packet if they need to, but if we embed the full public key
   packet the cryptographic assertion doesn't need to depend on the
   strength of the fingerprinting mechanism.

Regards,

   --dkg