How to update a self-signature?

"Michael Young" <mwy-opgp97@the-youngs.org> Sat, 25 August 2001 14:59 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12253 for <openpgp-archive@odin.ietf.org>; Sat, 25 Aug 2001 10:59:12 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7PEmJH01848 for ietf-openpgp-bks; Sat, 25 Aug 2001 07:48:19 -0700 (PDT)
Received: from smtprelay2.adelphia.net (smtprelay2.adelphia.net [64.8.25.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PEmHD01844 for <ietf-openpgp@imc.org>; Sat, 25 Aug 2001 07:48:18 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GIMP5603.2DV for <ietf-openpgp@imc.org>; Sat, 25 Aug 2001 10:48:42 -0400
Message-ID: <002b01c12d74$b105fb20$c23fa8c0@transarc.ibm.com>
From: Michael Young <mwy-opgp97@the-youngs.org>
To: ietf-openpgp@imc.org
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$c23fa8c0@transarc.ibm.com> <p0510031fb7ab945664e5@[192.168.1.180]>
Subject: How to update a self-signature?
Date: Sat, 25 Aug 2001 10:46:14 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----

Florian Weimer wrote:
> This should probably go into a separate RFC.  Currently, RFC 2440 and
> RFC 2440bis deal only with syntactic issues 

and Jon Callas wrote (this and subsequent quotes):
> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software

I understand that the specification primarily covers syntax, but
if it doesn't cover at least some interpretation issues, then
interoperation is seriously hampered.  Who cares how the bits
are ordered if a sender and receiver interpret wildly different things?
We need to have a meeting of the minds on more than just formatting.

> Secondarily, one way I look at it is as a receiver. I fetch a key from a
> server and it has multiple primaries. How do I resolve this? Yeah, there's

On this specific issue, I want to know what a *sender* must do
to change its "primary" marking such that a receiver will
understand.  The same applies to any material in the self-signature,
and this need may arise several times over a key/userId lifetime.

I'd be willing to issue a revocation on the old self-signature.  Which
of the "reason" values should be used?  Neither "key is superceded"
nor "userId information is no longer valid" is quite right.  I want
"signature is superceded".  How do people feel about adding such a reason?

While on the subject: the section on "Computing Signatures"
doesn't say what the "signature data" is for a certification
revocation (0x30).  Can we add a description there?

But I also offered a "most recent prevails" policy as an alternative.
One advantage to this approach is that it works even if the sender
has lost an old self-signature.  Another is that it is more compact --
extra revocation packets aren't necessary.

> been one recommendation in the last 24 hours since I started writing this
> reply that it be the first one that counts. Why? Why the first? Why not the

If I said that, I misspoke.  I strongly believe that "most recent prevails"
is the only sensible recommendation (if we make one at all).  But again,
an agreed revocation scheme would satisfy me.

> last, unless of course it's in the future. Perhaps an even better answer is
> to have the implementation ask the user which one to use.

That's always an option, regardless what the specification suggests.

But, I don't want to *force* user interface pop-ups (or even receiver
policy decisions) when the creator has clear intentions.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4e6LmNDnIII+QUHAQEwjgf7Bq+GLsAdyxy7d4Us9aqsZQZiky5PpcCI
Mp6OGvGPpmE4uGTeFEZw9pBrxIXqNTYBnjb4XDskHYYQu+k4Zpx3fTslsZPS5zvh
HZIluAqRvqtbqME5sjA66FJB47wETM6nzkp0ngw6tYppJ5vZK9DuverN6jKuTSmW
BuMEc/RdP4OzT6l+YV+8a42EhamioRI9sn/rnL6PoXSXkc9awuHlDsalyv4XYUG5
VEOhnL4vnmaPGFtf0SZtLgICr/t27ULDYY1X1tH0M65gYJgyeQfIUbhHCabcN+tY
11fLh2USW9CXnWtuGRzDv7LRq121EKbf3FqnahaWXk/eOJIkeWEyXg==
=tL9g
-----END PGP SIGNATURE-----