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

Simon Josefsson <jas@extundo.com> Tue, 16 May 2006 13:53 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzzl-0003nP-3A; Tue, 16 May 2006 09:53:53 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzzk-0003nH-JE; Tue, 16 May 2006 09:53:52 -0400
Received: from ([] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzzj-0007WT-5X; Tue, 16 May 2006 09:53:52 -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 k4GDrd2L001417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 May 2006 15:53:39 +0200
From: Simon Josefsson <jas@extundo.com>
To: Pasi.Eronen@nokia.com
References: <B356D8F434D20B40A8CEDAEC305A1F2402A7978F@esebe105.NOE.Nokia.com> <B356D8F434D20B40A8CEDAEC305A1F2402A799DB@esebe105.NOE.Nokia.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:060516:nmav@gnutls.org::q3RvZToBIBZUorM6:ZDV
X-Hashcash: 1:22:060516:tls-bounces@lists.ietf.org::G7ijCKdX0udYprAi:1lF2
X-Hashcash: 1:22:060516:pasi.eronen@nokia.com::G9QJfW+ve8vhCdQd:9Wbp
X-Hashcash: 1:22:060516:tls@ietf.org::XnMKC0lZWdahDeYW:QtUU
Date: Tue, 16 May 2006 15:53:39 +0200
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402A799DB@esebe105.NOE.Nokia.com> (Pasi Eronen's message of "Tue, 16 May 2006 14:59:38 +0300")
Message-ID: <87slna3wkc.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: cab78e1e39c4b328567edb48482b6a69
Cc: tls-bounces@lists.ietf.org, tls@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

<Pasi.Eronen@nokia.com> writes:

> Nikos Mavrogiannopoulos wrote:
>> Indeed there are situations were a list might do, but there are also
>> situations where a graph would be better, or just a single one might
>> do.  The idea in this draft is to keep the key exchange separate
>> from any local verification policy.  If one wants to use the web of
>> trust, he can use it. If somebody else wants to use openpgp keys the
>> same way as PKIX certificates, he can also use the current draft.
>> In all cases unknown keys are retrieved via a key server or by other
>> means.
> This argument would also suggest that the ability to send multiple
> X.509 certificates is unnecessary, since all the other certs could
> (in theory at least) be retrieved from directory servers. 
> You can't use this draft "the same way as PKIX certificates" unless
> you have the key server or "other means" working in practice.

I believe PGP key servers are working in practice.

> In current uses of TLS with X.509 certificates, this infrastructure
> is not necessarily present, and the ability to send several
> certificates is used.
> Thus, I would not hard-code this limitation in the specification,
> especially when it's very easy to avoid (just allow a list just
> as in normal TLS), and there's just 3 bytes of overhead for 
> implementations that send only one PGP key... (and in fact
> even this overhead could be avoided if we remove the redundant
> length field by stating that the "key descriptor type" is the
> first byte of the key data)

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 agree that limiting the protocol to carry one key is a theoretic
limitation, although I don't see anyone describing a practical
scenario where this limitation is critical.


TLS mailing list