Re: [TLS] TLS 1.3 certificate delegation?

Johannes Merkle <johannes.merkle@secunet.com> Fri, 08 November 2013 14:29 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 1633411E8189 for <tls@ietfa.amsl.com>; Fri, 8 Nov 2013 06:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level:
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 9Dbk0jIXwyxH for <tls@ietfa.amsl.com>; Fri, 8 Nov 2013 06:29:21 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 58DB011E8128 for <tls@ietf.org>; Fri, 8 Nov 2013 06:29:21 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2E3071A0066; Fri, 8 Nov 2013 15:29:19 +0100 (CET)
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 78hEOSsdOIPl; Fri, 8 Nov 2013 15:29:18 +0100 (CET)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 7C5E81A0075; Fri, 8 Nov 2013 15:29:15 +0100 (CET)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 15:29:15 +0100
Message-ID: <527CF53B.7010908@secunet.com>
Date: Fri, 08 Nov 2013 15:29:15 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: mrex@sap.com, Andy Lutomirski <luto@amacapital.net>
References: <20131108072109.CA6061AA6A@ld9781.wdf.sap.corp>
In-Reply-To: <20131108072109.CA6061AA6A@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2013 14:29:15.0871 (UTC) FILETIME=[E6F696F0:01CEDC8E]
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 14:29:27 -0000

>>
>> FWIW, there's precedent for using new TLS versions to expand the set
>> of allowable certificates.  If I"m reading it correctly, TLS 1.2
>> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
>> will reject those.
> 
> TLSv1.1 will certainly not reject those.
> It is only rfc4492 that incorrectly alleges that those should be rejected.

I think you are wrong: Section 7.4.2 of RFC 4346 states

                              Unless otherwise specified, the signing
      algorithm for the certificate MUST be the same as the algorithm
      for the certificate key.


Section 7.4.2 of RFC 5246 states
                                                                  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).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.

Johannes