Re: How to update a self-signature?

[David Shaw <dshaw@xxxxxxxxxx>]

On Sat, Aug 25, 2001 at 10:46:14AM -0400, Michael Young wrote:

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

The draft does specify have a way to do this - rewriting the
signature(s) in place ("Since a self-signatures contain important
information about the key's use, an implementation SHOULD allow the
user to rewrite the self-signature...").  Both PGP and GnuPG do this.

The problem arises later, when the key with the new self-signatures is
added to a keyserver or sent to someone else who already has the key.
Most current implementations in the field will merge their existing
copy with the new one, resulting in two self-signatures.  It could be
argued that they should not do this, but since it's going to happen,
we should at least make a provision for it.

Like you, I favor a "most recent prevails" recommendation.  I think
that revoking and re-making self-signatures is going to result in some
massive keys if every time someone changes their preferences it means
a new revocation packet and self-signature.

I don't think that this is just a syntax issue, and therefore
inappropriate for 2440bis.  2440bis makes a point of covering syntax
issues that relate to security.  Since the information in a
self-signature can affect the security of messages sent to the key,
I'd say this is an appropriate issue to address in 2440bis.

"Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
like the sample wording I sent out a couple of days ago, rather than a
MUST.  In fact, SHOULD describes it nicely (e.g. "We recommend you do
it this way, but you can do it any way you like if you think about the
implications first.").

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

Yes.

David

-- 
David Shaw          |  Technical Lead
<dshaw@xxxxxxxxxx>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies