[TLS] TLS 1.2 clarification requested

"Kain, Michael T" <Michael.Kain@unisys.com> Tue, 01 October 2013 18:59 UTC

Return-Path: <Michael.Kain@unisys.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7911E81AD for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 11:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hmotNNW7Uo51 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 11:59:03 -0700 (PDT)
Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8791211E81B9 for <tls@ietf.org>; Tue, 1 Oct 2013 11:59:03 -0700 (PDT)
Received: from [] by server-9.bemta-7.messagelabs.com id CA/48-13769-57B1B425; Tue, 01 Oct 2013 18:59:01 +0000
X-Env-Sender: Michael.Kain@unisys.com
X-Msg-Ref: server-4.tower-200.messagelabs.com!1380653940!16309641!2
X-Originating-IP: []
X-StarScan-Version: 6.9.12; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22357 invoked from network); 1 Oct 2013 18:59:01 -0000
Received: from unknown (HELO USEA-NAEDGE1.unisys.com) ( by server-4.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2013 18:59:01 -0000
Received: from usea-nahubcas3.na.uis.unisys.com ( by USEA-NAEDGE1.unisys.com ( with Microsoft SMTP Server (TLS) id; Tue, 1 Oct 2013 13:59:00 -0500
Received: from USEA-EXCH7.na.uis.unisys.com ([]) by usea-nahubcas3.na.uis.unisys.com ([]) with mapi; Tue, 1 Oct 2013 13:58:51 -0500
From: "Kain, Michael T" <Michael.Kain@unisys.com>
To: "'tls@ietf.org'" <tls@ietf.org>
Date: Tue, 1 Oct 2013 13:58:50 -0500
Thread-Topic: TLS 1.2 clarification requested
Thread-Index: Ac6+19Gy7ubypu9bSN6R9OEEKLlUhA==
Message-ID: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01F4_01CEBEB6.BD028F70"
MIME-Version: 1.0
Subject: [TLS] TLS 1.2 clarification requested
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2013 18:59:11 -0000

I'm trying to understand the TLS 1.2 restrictions and signature algorithms
and how they interact.  Is there a relation between the signature algorithm
that is negotiated between client and server and the algorithm which signed
the server certificate?

Does that affect the hash algorithm of TLS 1.2 - or is that always SHA256?


For example, if I've got a server configured with a server certificate
signed with SHA256, can it still establish a connection using the


Does the signature algorithm for a certificate affect which Ciphersuites can
be negotiated and used?