[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
How to update a self-signature?
-----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
-----END PGP SIGNATURE-----