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

<Pasi.Eronen@nokia.com> Tue, 16 May 2006 07:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fftlq-0007ru-6B; Tue, 16 May 2006 03:15:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fftlo-0007kN-8K for tls@ietf.org; Tue, 16 May 2006 03:15:04 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fftlm-0005KB-Ol for tls@ietf.org; Tue, 16 May 2006 03:15:04 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4G7ErMJ021555; Tue, 16 May 2006 10:14:53 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:14:52 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:14:51 +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 10:14:47 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402A7952B@esebe105.NOE.Nokia.com>
In-Reply-To: <200605111642.57275.nmav@gnutls.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Review of draft-ietf-tls-openpgp-keys-08
Thread-Index: AcZ1Cd5+q5I0mCBsTYmtGvNbu5KfugDrBxNw
From: Pasi.Eronen@nokia.com
To: nmav@gnutls.org, tls@ietf.org
X-OriginalArrivalTime: 16 May 2006 07:14:51.0646 (UTC) FILETIME=[6C82B9E0:01C678B8]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc:
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:

> > Somewhat substantive comments:
> > 1) Section 3.3: The TLS Certificate message defined in RFC4346
> >    contains a list of X.509 certificates, while this section allows
> >    only a single PGPKey structure. IMHO we should keep this aligned
> 
> This was a deliberate change. The rationale behind this change was
> that there is no point in sending more than one pgp keys. There is no
> notion of certificate chain in openpgp, thus having a list of 
> certificates would confuse on what should be sent.

If Alice signs (certifies) Bob's key, and Bob signs Carol's key,
isn't that a certificate chain? (The whole notion of "web of trust"
seems to imply a certificate graph, which again implies chains...)

> > 4) I'd suggest moving whole Section 2 to later in the document
> >    (e.g., after Security Considerations), renaming it to "IANA
> >    Considerations", and rewriting it something like this:
> >    "This document defines a new TLS extension, "cert_type", assigned
> >    a value of TBD-BY-IANA (the value 7 is suggested) from the TLS
> >    ExtensionType registry defined in [RFC4366].
> >    This document establishes a new registry, to be maintained by
> >    IANA, for TLS certificate types. Initially, the registry contains
> >    the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223
> >    are assigned via IETF Consensus [RFC2434]. Values from the range
> >    224-255 are reserved for Private Use [RFC2434]."
> 
> Will be addressed.
> (I just noticed that in http://www.iana.org/numbers.html there is 
> nothing about the TLS extension numbers. Is restristration possible?)

For some reason, the index page doesn't have a link to the registry
(I'll notify IANA about this), but the registry is there:

http://www.iana.org/assignments/tls-extensiontype-values

> > 5) Section 3.1: "...extension SHOULD be omitted if the client only
> >    supports X.509 certificates" and "Servers that only support X.509
> >    certificates MAY omit... ": Unnecessary options are a recipe for
> >    interoperability problems; unless there are good reasons to keep
> >    these, I'd suggest changing these to MUSTs.
> 
> I agree for the first one. But the second is only to address the case 
> where the server doesn't support this extension (thus he doesn't add 
> the extension reply to his hello). But I'd expect a server that is 
> aware of this extension to properly reply with an extension that 
> indicates that he selected the X509 certificate choice.

Sounds reasonable to me.

Best regards,
Pasi

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