Re: [TLS] TLS 1.2 and CertificateRequest message

Michael D'Errico <> Thu, 22 October 2009 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73A8E3A67DA for <>; Thu, 22 Oct 2009 15:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WCM2nBgaUxAl for <>; Thu, 22 Oct 2009 15:06:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F05D3A67C0 for <>; Thu, 22 Oct 2009 15:06:25 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 11F4382020 for <>; Thu, 22 Oct 2009 18:06:35 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=O+99f9kc8AM4 4JPoCEojKoT2144=; b=aIuNyTMlQ60D2nYy3d6opGngldHY2OotmnH8mkingzV4 Cqk+jDr8xD1zpNfV+q+ZBVt0UWSmLSwU2b5RavMNXYQ8YKhnWnWUI+JwgFMHm4nb G0yWATfyGC4JKBPEbusbXYNc9EnD2qSP+Q3buHdNHciEhzylyEGDKmWC1fQ9pNE=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=R60dbH rfyUt9jNSubG+ZbOEmyrdhslshu0GE9y6GJvykREBIljix+N0xgTu5KpAwIXQosl dY29Ngd9prl74HuuAJpXyWHpFg2dU481DgLmfQ8/gsS4qPAYliiPOwUbY/SO/is1 6h03UltqgKxc/5tfsmrukZ+JUQKKhOBFEiV5Q=
Received: from (unknown []) by (Postfix) with ESMTP id 0E09F8201F for <>; Thu, 22 Oct 2009 18:06:35 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 55C8E8201E for <>; Thu, 22 Oct 2009 18:06:33 -0400 (EDT)
Message-ID: <>
Date: Thu, 22 Oct 2009 15:07:22 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 29AFF3DC-BF57-11DE-B468-A67CBBB5EC2E-38729857!
Subject: Re: [TLS] TLS 1.2 and CertificateRequest message
X-Mailman-Version: 2.1.9
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: <>, <>
X-List-Received-Date: Thu, 22 Oct 2009 22:06:26 -0000

I remember participating in the discussion that led to this design.  I
argued that since we added a signature algorithms extension to allow
negotiation of the client's preferred algorithms, it made the most
sense to make the extension symmetric so the server could notify the
client of its preferred algorithms in its hello message as well.

There was opposition to my argument, that the list of algorithms belongs
where it is needed, in the certificate request message.  The term
"locality of reference" was thrown around as a justification.  Not being
an official member of the working group, and since nobody else seemed to
prefer my idea, I forfeited the point.

To solidify this design choice the definition of the signature algorithms
extension states that the server MUST NOT send it.

My own implementation holds onto all the handshake messages and calculates
the hashes of them when needed.  If you'd like to test interoperability
with my server, will ask you for a client


Nikos Mavrogiannopoulos wrote:
> Hello,
>  I've been taking a look at TLS 1.2 and it seems that there is some new
> negotiation added at the CertificateRequest message. At this message the
> server is supposed to send a list of allowed algorithm for signature
> calculation, and the client should respond with a signature that depends
> on the previously exchanged handshake messages.
> In previous versions of TLS a client could just start the hash
> calculation for this signature during the exchange to avoid storing the
> actual messages up to this point. However with this negotiation at this
> point it is quite impossible to do that approach and as far as I
> understand needs to follow the store approach.
> My questions now are:
> 1. How is this implemented in compliant software today?
> 2. Why this negotiation was added? I see no added value of having such
> negotiation at a so late point.
> regards,
> Nikos