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

Simon Josefsson <jas@extundo.com> Wed, 17 May 2006 16:29 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOtd-00054l-Vi; Wed, 17 May 2006 12:29:13 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOtd-00052w-Hd for tls@lists.ietf.org; Wed, 17 May 2006 12:29:13 -0400
Received: from ([] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOtc-0001Kp-2W for tls@lists.ietf.org; Wed, 17 May 2006 12:29:13 -0400
Received: from localhost.localdomain (yxa.extundo.com []) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4HGSv3o014571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 May 2006 18:28:58 +0200
From: Simon Josefsson <jas@extundo.com>
To: Eric Rescorla <ekr@networkresonance.com>
References: <87psid6kzb.fsf@latte.josefsson.org> <20060517152813.1E222222418@laser.networkresonance.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:060517:ekr@networkresonance.com::6LQdAmzfbkHksksj:AYK7
X-Hashcash: 1:22:060517:tls@lists.ietf.org::mumWBUACOEo8Iynq:Q8Uw
Date: Wed, 17 May 2006 18:28:57 +0200
In-Reply-To: <20060517152813.1E222222418@laser.networkresonance.com> (Eric Rescorla's message of "Wed, 17 May 2006 08:22:29 -0700")
Message-ID: <87y7x0ipiu.fsf@latte.josefsson.org>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
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

Eric Rescorla <ekr@networkresonance.com> writes:

> 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.

How are clients and servers, respectively, supposed to figure out
which keys to include?

Presumably, they should not send their entire key ring, right?  Some
properties of the resolution algorithms appear to be needed to pick
the "appropriate" keys, and limit the set of keys to send.

Compare RFC 4346, which says on X.509 certs:

      This is a sequence (chain) of X.509v3 certificates.  The sender's
      certificate must come first in the list.  Each following
      certificate must directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority may optionally be omitted from the chain,
      under the assumption that the remote end must already possess it
      in order to validate it in any case.

What I'm looking for are similar guidelines to decide which OpenPGP
keys to include, but I'm skeptical about the existence of useful such


TLS mailing list