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

Vincent Breitmoser <look@my.amazin.horse> Sun, 26 July 2015 14:38 UTC

Return-Path: <look@my.amazin.horse>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844331A8949 for <openpgp@ietfa.amsl.com>; Sun, 26 Jul 2015 07:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 4XMLgFNm8HzJ for <openpgp@ietfa.amsl.com>; Sun, 26 Jul 2015 07:38:47 -0700 (PDT)
Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968A81A89AA for <openpgp@ietf.org>; Sun, 26 Jul 2015 07:38:46 -0700 (PDT)
Received: from localhost (p57B2D2F0.dip0.t-ipconnect.de [87.178.210.240]) by mail.mugenguild.com (Postfix) with ESMTPSA id 74AEF60030; Sun, 26 Jul 2015 16:34:51 +0200 (CEST)
References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> <878ua39qz5.fsf@vigenere.g10code.de>
From: Vincent Breitmoser <look@my.amazin.horse>
To: Werner Koch <wk@gnupg.org>
In-reply-to: <878ua39qz5.fsf@vigenere.g10code.de>
Date: Sun, 26 Jul 2015 16:38:34 +0200
Message-ID: <87y4i36l1x.fsf@littlepip.fritz.box>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/BaDoaQ9JsR7TLA4G8gue4UpercI>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 26 Jul 2015 14:38:49 -0000

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

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