How to update a self-signature?

["Michael Young" <mwy-opgp97@xxxxxxxxxxxxxx>]

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