[TLS] Re: Review of draft-ietf-tls-openpgp-keys-08

Eric Rescorla <ekr@networkresonance.com> Wed, 17 May 2006 15:21 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNqU-0006yD-M6; Wed, 17 May 2006 11:21:54 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNqT-0006y8-LH for tls@lists.ietf.org; Wed, 17 May 2006 11:21:53 -0400
Received: from laser.networkresonance.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNqS-0006tf-9B for tls@lists.ietf.org; Wed, 17 May 2006 11:21:53 -0400
Received: from networkresonance.com (raman.networkresonance.com []) by laser.networkresonance.com (Postfix) with ESMTP id 1E222222418; Wed, 17 May 2006 08:28:13 -0700 (PDT)
To: Simon Josefsson <jas@extundo.com>
In-reply-to: Your message of "Wed, 17 May 2006 11:47:52 +0200." <87psid6kzb.fsf@latte.josefsson.org>
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Wed, 17 May 2006 08:22:29 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060517152813.1E222222418@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: tls@lists.ietf.org
Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Simon Josefsson <jas@extundo.com> wrote:

> Eric Rescorla <ekr@networkresonance.com> writes:
> > "Steven M. Bellovin" <smb@cs.columbia.edu> writes:
> >
> >> On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos
> >> <nmav@gnutls.org> wrote:
> >>
> >>> On Tue 16 May 2006 16:50, Eric Rescorla wrote:
> >>> 
> >>> > > I'd disagree that it is that simple to fix that: If the draft
> >>> > > permit more than one key, I believe it has to describe how
> >>> > > implementations are supposed to use more than one key to build the
> >>> > > chain, or at least mandate some specific behaviour.
> >>> > I don't agree with this. PGP at least theoretically knows how
> >>> > to build cert chains from a "bucket of keys".
> >>> 
> >>> Maybe but I still find no point in sending a bucket of keys just like 
> >>> that. If it is to be sent it has to be clearly defined what it is 
> >>> expected in this bucket and so on. I'm quite reluctant to do it because 
> >>> I don't need nor find a use for this functionality. It can be easily 
> >>> added by anyone that need it[0], and I would be willing to include the 
> >>> required changes in this or a future update, if somebody needs it and 
> >>> defines the semantics of a key list.
> >>> 
> >> The problem is that you don't know the recipient's trust anchors or trust
> >> metrics.  Without that, you have to send the whole graph (or at least as
> >> much of it as you have), to maximize the chances of the key being accepted.
> >
> > Right, I understand that this is a problem in principle, but I'm
> > not sure that it's a problem in practice. In particular, I'm not
> > sure that it's so bad a problem in practice that the protocol should
> > be explicitly designed to prohibit people who think they understand
> > the trust graph from giving hints.
> I believe that protocol fields with undocumented semantics, and where
> the algorithms that make use of those fields are not documented [1],
> leads to poor interoperability.

It's not undocumented. It's "add these certs to your bucket of certs"
and use them in whatever resolution mechanism you have.

> As Nikos said, if someone wants this, it is easy to extend the
> PGPKeyDescriptorType enum to add a key_list(2), and then describe the
> semantics related to it.  If someone volunteers to write that, we
> could review that text to see if it seems correct, but, IMHO, the onus
> to write this should be on those who proposed this change in the
> document.

I don't agree that this should be an extension, but I am willing
to go along with the burden of work argument. Pasi, you want to
contribute text?


TLS mailing list