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

<Pasi.Eronen@nokia.com> Tue, 16 May 2006 11:59 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyDN-0006ON-5r; Tue, 16 May 2006 07:59:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyDM-0006OF-9W; Tue, 16 May 2006 07:59:48 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfyDL-0002WQ-Q9; Tue, 16 May 2006 07:59:48 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4GBxcaF012470; Tue, 16 May 2006 14:59:41 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:59:39 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:59:39 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Review of draft-ietf-tls-openpgp-keys-08
Date: Tue, 16 May 2006 14:59:38 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402A799DB@esebe105.NOE.Nokia.com>
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402A7978F@esebe105.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Review of draft-ietf-tls-openpgp-keys-08
Thread-Index: AcZ4zDDR0BnIOpTbQEq3spOET+5XUgAAI11wAAPkJYA=
From: <Pasi.Eronen@nokia.com>
To: <tls-bounces@lists.ietf.org>, <nmav@gnutls.org>
X-OriginalArrivalTime: 16 May 2006 11:59:39.0523 (UTC) FILETIME=[35ADD530:01C678E0]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: tls@ietf.org
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

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

> That approach follows the way openpgp keys are used in electronic mail
> and I see no good reason to change it by introducing an openpgp key
> chain in this draft.

It does not follow the email way of using PGP: most email messages
don't contain the public key at all (only the signature), and when 
the public key is included, a single message can contain several 
keys (see e.g. RFC 3156 Section 7), presumably forming some kind of 
graph (not necessarily a single chain).

Best regards,
Pasi

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