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

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIdq-0008CR-Ou; Wed, 17 May 2006 05:48:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIdp-0008CH-3L for tls@lists.ietf.org; Wed, 17 May 2006 05:48:29 -0400
Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgIdo-00061t-Lt for tls@lists.ietf.org; Wed, 17 May 2006 05:48:29 -0400
Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4H9lq7M019522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 May 2006 11:47:52 +0200
From: Simon Josefsson <jas@extundo.com>
To: EKR <ekr@networkresonance.com>
References: <B356D8F434D20B40A8CEDAEC305A1F2402A7978F@esebe105.NOE.Nokia.com> <87slna3wkc.fsf@latte.josefsson.org> <86mzdiowgo.fsf@raman.networkresonance.com> <200605161907.51448.nmav@gnutls.org> <20060516165736.ddc57b83.smb@cs.columbia.edu> <867j4lptqm.fsf@raman.networkresonance.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:060517:ekr@networkresonance.com::rY70MpE5I76IBhqj:r9G
X-Hashcash: 1:22:060517:smb@cs.columbia.edu::TM1IaFElGBIjU+OX:2SuH
X-Hashcash: 1:22:060517:tls@lists.ietf.org::ggt16xlM4mWo6o7e:vbM8
Date: Wed, 17 May 2006 11:47:52 +0200
In-Reply-To: <867j4lptqm.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Tue, 16 May 2006 14:03:45 -0700")
Message-ID: <87psid6kzb.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: 0ddefe323dd869ab027dbfff7eff0465
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:

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

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.

Regards,
Simon

[1] I'm guessing here.  If what PGP does is documented and part of
some standard, the situation would be different.

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls