Re: Diffs for next draft
Jon Callas <jon@callas.org> Sat, 25 August 2001 00:05 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17161 for <openpgp-archive@odin.ietf.org>; Fri, 24 Aug 2001 20:05:41 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id f7ONhJx09651 for ietf-openpgp-bks; Fri, 24 Aug 2001 16:43:19 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7ONhID09647 for <ietf-openpgp@imc.org>; Fri, 24 Aug 2001 16:43:18 -0700 (PDT)
Received: from [192.168.1.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 24 Aug 2001 16:43:16 -0700
Mime-Version: 1.0
X-Sender: jon@merrymeet.com
Message-Id: <p0510031fb7ab945664e5@[192.168.1.180]>
In-Reply-To: <008601c12c52$1b6181c0$c23fa8c0@transarc.ibm.com>
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$c23fa8c0@transarc.ibm.com>
Date: Fri, 24 Aug 2001 16:42:36 -0700
To: Michael Young <mwy-opgp97@the-youngs.org>, ietf-openpgp@imc.org
From: Jon Callas <jon@callas.org>
Subject: Re: Diffs for next draft
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
At 12:06 AM -0400 8/24/01, Michael Young wrote: >It seems that the most likely reason for a second "primary" >is that it has been updated. If so, it seems that one should >defer to the most recent valid signature. Can we say >that an implementation "SHOULD" do that, rather than leaving >it open? As I remember it, when we introduced this, there were people who thought it should be a MUST that there be exactly one of them. I thought this was a bit fussy, myself -- as it requires the implementations to verify that there's only one. I came up with the present wording as a way to subtly admonish the practice without presuming to know the answer. The simple and obvious way to deal with the problem of multiple primaries is don't do that. This is the Henny Youngman Solution (from the old joke: HY goes into the doctor and says, "Doc, it hurts when I do this," waving an arm. The doctor replies, "Then don't do that"). The penalty for writing multiple primaries is that the receiver may do something perverse, and you can't use the standard as a stick. Don't do that. 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 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 last? I can make a convincing argument that it should be the last one, too. But why the last. Why not the one with the latest date? I think I can argue that the latest date is even more correct than either the first or 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. 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 construction manual. It tells implementers the things they have to do to be compliant. What this really says that if you ever see a key with multiple primary user names, then your guess is as good as mine, and I'm not going to wag my finger at you for whatever rationale makes sense for you. Jon
- Diffs for next draft Jon Callas
- Re: Diffs for next draft Werner Koch
- Re: Diffs for next draft Jon Callas
- Re: Diffs for next draft Edwin Woudt
- Re: Diffs for next draft Jon Callas
- Encoding of "features" subpacket Michael Young
- Re: Diffs for next draft Michael Young
- Re: Encoding of "features" subpacket Jon Callas
- Re: Diffs for next draft David Shaw
- Re: Diffs for next draft David Shaw
- Re: Diffs for next draft Jon Callas
- Klima/Rosa attack (was: Re: Diffs for next draft) Edwin Woudt
- Encoding "secret key is hashed" Michael Young
- Re: Klima/Rosa attack (was: Re: Diffs for next dr… Ingo Luetkebohle
- Re: Encoding "secret key is hashed" Edwin Woudt
- Re: Encoding "secret key is hashed" Werner Koch
- Re: Encoding "secret key is hashed" Michael Young
- Re: Encoding "secret key is hashed" Michael Young
- Re: Encoding "secret key is hashed" Ingo Luetkebohle
- Re: Encoding "secret key is hashed" Werner Koch
- Re: Encoding "secret key is hashed" Michael Young
- Re: Diffs for next draft Jon Callas
- Re: Diffs for next draft David Shaw
- Re: Diffs for next draft Werner Koch
- How to update a self-signature? Michael Young
- Re: How to update a self-signature? David Shaw
- Re: Diffs for next draft Florian Weimer
- Re: How to update a self-signature? Werner Koch
- Re: How to update a self-signature? Derek Atkins
- Re: How to update a self-signature? Florian Weimer
- Re: How to update a self-signature? David Shaw
- Re: How to update a self-signature? David Shaw
- Re: How to update a self-signature? Derek Atkins
- Re: How to update a self-signature? Werner Koch
- Re: How to update a self-signature? David Shaw
- Re: How to update a self-signature? Werner Koch
- Keyserver thoughts (was Re: How to update a self-… David Shaw
- Certification revocation -- identifying the revok… Michael Young
- Re: Certification revocation -- identifying the r… Thomas Roessler