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

<Pasi.Eronen@nokia.com> Wed, 10 May 2006 17:21 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsNi-00050K-8v; Wed, 10 May 2006 13:21:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsNh-0004yM-5B for tls@ietf.org; Wed, 10 May 2006 13:21:49 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdsNe-0007ls-Kh for tls@ietf.org; Wed, 10 May 2006 13:21:49 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4AHLj5E011062 for <tls@ietf.org>; Wed, 10 May 2006 20:21:45 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 20:21:45 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 20:21:45 +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
Date: Wed, 10 May 2006 20:21:46 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402A0838F@esebe105.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-tls-openpgp-keys-08
Thread-Index: AcZ0VjcYzQVrx2j2RLC8mjAin9T0MQ==
From: <Pasi.Eronen@nokia.com>
To: <tls@ietf.org>
X-OriginalArrivalTime: 10 May 2006 17:21:45.0600 (UTC) FILETIME=[3670A800:01C67456]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc:
Subject: [TLS] 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

The document looks mostly OK, but I think some details need 
clarification/polishing before we send this to the IESG.

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
   with RFC4346, even though usually one key is enough. In other 
   words, something like this:

      struct {
          PGPKeyDescriptorType descriptorType;
          select (descriptorType) {
              case key_fingerprint: opaque fingerprint<16..20>; 
              case key:             opaque key<0..2^24-1>; 
          }
      } PGPCert;

      struct {
          PGPCert certificate_list<0..2^24-1>;
      } Certificate;

2) Section 3.5: "then a Certificate that contains an empty PGPKey
   should be sent": If the change suggested above is made, a 
   Certificate message that contains one zero-length PGPKey is 
   not the same thing as a Certificate message that contains zero 
   certificates (and it's the latter that should be sent).

3) Section 3.4: I don't think there is any need to define a new
   CertificateRequest message (the "certificate_authorities" part
   doesn't make much sense for OpenPGP, but RFC4346 clarified that
   it can be empty; and I believe many TLS 1.0 implementations also
   did this). So I'd suggest rewriting this section as follows:

   "If the certificate request message is sent, and the negotiated
   certificate type is OpenPGP, the certificate_authorities list 
   MUST be empty."

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

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.

6) Section 4: I'd suggest merging this section (only four lines)
   with Section 3.1. Also, the text should apply to all ciphersuites
   using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just
   those in RFC 2246. (And with this change, the text about
   exportable ciphersuites is no longer necessary.)

Purely editorial comments:

7) Overall: I believe nowadays the RFC Editor recommends using 
   symbolic citations [RFC2119] instead of numeric ones [1].

8) Section 1, 2nd paragraph: extra comma before "provide"

9) Sections 3.6..3.8: I'd suggest removing these.  

10) Section 3.3: "The process of fingerprint generation is described 
   in OpenPGP [2]": I'd suggest adding a more specific pointer:
   Section 11.2 of [RFC2440].

11) Section 6.1: RFC 3546 is obsoleted by RFC 4366.

12) Section 6.1: Should include RFC 2119 and RFC 2434 here.

13) Section 6.2: Reference [5] is never cited in the text (and
   IMHO could be removed)


Best regards,
Pasi

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