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