Re: [TLS] TLS 1.2 clarification requested

Johannes Merkle <johannes.merkle@secunet.com> Wed, 02 October 2013 09:43 UTC

Return-Path: <Johannes.Merkle@secunet.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173E21F9E9D for <tls@ietfa.amsl.com>; Wed, 2 Oct 2013 02:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thEO31fThmH5 for <tls@ietfa.amsl.com>; Wed, 2 Oct 2013 02:43:29 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6740021E8254 for <tls@ietf.org>; Wed, 2 Oct 2013 02:43:03 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7CB7A1A0081; Wed, 2 Oct 2013 11:43:01 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p2mK6atnd1YU; Wed, 2 Oct 2013 11:43:00 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 490B51A0080; Wed, 2 Oct 2013 11:43:00 +0200 (CEST)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 11:43:00 +0200
Message-ID: <524BEAA3.8020108@secunet.com>
Date: Wed, 02 Oct 2013 11:42:59 +0200
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> <A2B75A91-EBFC-415A-9671-81E939819ACF@checkpoint.com>
In-Reply-To: <A2B75A91-EBFC-415A-9671-81E939819ACF@checkpoint.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Oct 2013 09:43:00.0526 (UTC) FILETIME=[C8602CE0:01CEBF53]
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Wed, 02 Oct 2013 09:43:41 -0000

> Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certificate for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respectively, and also MUST be signed by ECDSA and RSA respectively. I'm not sure why that last restriction is needed, but it's there. For non-EC ciphersuites, there is no restriction, but you still need to negotiate an algorithm that works with the public key.
> 

As you noted in your other post, RFC 5246 relaxes this restriction. And you don't have to go down until appendix A.7, it
is clearly stated in Section 4.2

 Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).

Appendix A.7 only points out that this changes the rules of RFC 4492.

Johannes