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

Nikos Mavrogiannopoulos <> Thu, 11 May 2006 14:43 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FeCO1-0005iP-9y; Thu, 11 May 2006 10:43:29 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FeCO0-0005iK-HC for; Thu, 11 May 2006 10:43:28 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1FeCNz-0004zq-5k for; Thu, 11 May 2006 10:43:28 -0400
Received: by with SMTP id m2so160873uge for <>; Thu, 11 May 2006 07:43:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:x-spam-checker-version:x-spam-status:x-gmail-received:from:to:subject:in-reply-to:mime-version:content-disposition:references:delivered-to:date:content-type:content-transfer-encoding:message-id:sender; b=F7/KzCBBcpwwkAhDMAd/jrYjqPw6HqHiEuNu9cks2jIif890V446n07895KcSeCbMfmnv8ljkBgmXjChWZg/MdIU6iL+fGk6wuIehKKiN8oTWdt2Ftun1uNLYVdKho/BlLsEUvAfCTY2xi9gzSaoBPFQK63qT7UMpqU4W3fZv5k=
Received: by with SMTP id f4mr706612ugn; Thu, 11 May 2006 07:43:26 -0700 (PDT)
Received: from ? ( []) by with ESMTP id m1sm1768562ugc.2006.; Thu, 11 May 2006 07:43:26 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on
X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,NO_RELAYS,RCVD_BY_IP autolearn=no version=3.1.0
X-Gmail-Received: f7cb71e352b19065c4507726035a9f6c6e8c5a88
Received: by with HTTP; Wed, 10 May 2006 23:42:39 -0700 (PDT)
From: Nikos Mavrogiannopoulos <>
Subject: Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <>
Date: Thu, 11 May 2006 16:42:56 +0200
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On 5/10/06, <> wrote:

Hello Pasi,
 Thank you for the comments. I address them below.

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

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

I will address this.

> 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 there is 
about the TLS extension numbers. Is restristration possible?)

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

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

True. I'll update it.

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

Thanks I'll try to address the comments in a new draft.

TLS mailing list