Re: How to update a self-signature?

[Derek Atkins <[e-mail]>]

Keep in mind that you DON'T want to over-ride a revocation
self-signature.  That would be bad.

-derek

David Shaw <[e-mail]> writes:

> 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
> <[e-mail]>  |  Enterprise Content Delivery
> 617-250-3028        |  Akamai Technologies

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available