[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to update a self-signature?
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
> > 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.
David Shaw | Technical Lead
<dshaw@xxxxxxxxxx> | Enterprise Content Delivery
617-250-3028 | Akamai Technologies