Re: [TLS] TLS 1.2 clarification requested

Yoav Nir <ynir@checkpoint.com> Wed, 02 October 2013 10:44 UTC

Return-Path: <ynir@checkpoint.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 1A66621E8254 for <tls@ietfa.amsl.com>; Wed, 2 Oct 2013 03:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.633
X-Spam-Level:
X-Spam-Status: No, score=-9.633 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 zuWCZf7UT1rh for <tls@ietfa.amsl.com>; Wed, 2 Oct 2013 03:43:59 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD7121F9BA4 for <tls@ietf.org>; Wed, 2 Oct 2013 03:43:43 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r92AhbED006935; Wed, 2 Oct 2013 13:43:37 +0300
X-CheckPoint: {524BF8D9-2-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Wed, 2 Oct 2013 13:43:37 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Thread-Topic: [TLS] TLS 1.2 clarification requested
Thread-Index: Ac6+19Gy7ubypu9bSN6R9OEEKLlUhP//2+0AgADps4CAABDxgA==
Date: Wed, 2 Oct 2013 10:43:37 +0000
Message-ID: <5A2B4148-4DB3-429F-944E-D8EEE513ACE9@checkpoint.com>
References: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> <A2B75A91-EBFC-415A-9671-81E939819ACF@checkpoint.com> <524BEAA3.8020108@secunet.com>
In-Reply-To: <524BEAA3.8020108@secunet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.116]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <0E99272459ABA64092624BCEBC3AFE9E@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 10:44:22 -0000

On Oct 2, 2013, at 12:42 PM, Johannes Merkle <johannes.merkle@secunet.com> wrote:

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

And that also means that such certificates are OK for TLS 1.2, but not for TLS 1.0 or 1.1.

Yoav