Re: [TLS] TLS 1.3 certificate delegation?
mrex@sap.com (Martin Rex) Mon, 11 November 2013 20:27 UTC
Return-Path: <mrex@sap.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 1269B11E8102 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 12:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.178
X-Spam-Level:
X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 mfsTys0Pg-HC for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 12:27:33 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DE8B411E811D for <tls@ietf.org>; Mon, 11 Nov 2013 12:27:32 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rABKR61f025960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Nov 2013 21:27:06 +0100 (MET)
In-Reply-To: <527E067F.9010209@edelweb.fr>
To: Peter Sylvester <peter.sylvester@edelweb.fr>
Date: Mon, 11 Nov 2013 21:27:06 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131111202706.7522D1AA77@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 11 Nov 2013 20:27:40 -0000
Peter Sylvester wrote: > > Johannes Merkle wrote: > >> 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. > > Taking this out of context is not helpful > The specifications makes statements about what the sender has to > do, not what the receiver has to verify. The words in the TLS specification do not say who should to what. With your rationale, this is a mere prayer addressed at nobody. :) > > > The history of this obvious defect starts in rfc2246. > > > > There exists no such artificial limitation in SSLv3, and when I looked > > at implementations I've been using for interop testing a few > > years ago (Microsoft SChannel, OpenSSL, Firefox), they would > > happily interoperate with an RSA server cert signed by a CA with a > > DSA key. To me it looks like most implementors were either not > > aware of this bogus, backwards-incompatible requirement, > > or they applied common sense and deliberately ignored it. > > What is bogus in restricting a sender to be conservative? As if the _sender_ (implementation!!) had a choice. Which TLS implementations are prepared of handling two server certificates that differ only in the CAs signature algorithm (i.e. same server public key, same name attributes, same key usages)? That would be bridging PKIs at the end-entity level. I assume that bridging is normally done at the CA level. And how many real-world TLS servers are actually configured with such almost-twins server certificates? The vast majority of Web Servers have only a single server certificate, and those that have different certs, either have certificates ditinct by public key algorithm or distinct by (server)name. -Martin
- Re: [TLS] TLS 1.3 certificate delegation? Martin Rex
- Re: [TLS] TLS 1.3 certificate delegation? Martin Rex
- Re: [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Carl Wallace
- [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Carl Wallace
- Re: [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Carl Wallace
- Re: [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Johannes Merkle
- Re: [TLS] TLS 1.3 certificate delegation? Johannes Merkle
- Re: [TLS] TLS 1.3 certificate delegation? Bill Frantz
- Re: [TLS] TLS 1.3 certificate delegation? Salz, Rich
- Re: [TLS] TLS 1.3 certificate delegation? Martin Rex
- Re: [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Salz, Rich
- Re: [TLS] TLS 1.3 certificate delegation? Martin Rex
- Re: [TLS] TLS 1.3 certificate delegation? Johannes Merkle
- Re: [TLS] TLS 1.3 certificate delegation? Johannes Merkle
- Re: [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Michael D'Errico
- Re: [TLS] TLS 1.3 certificate delegation? Rob Stradling
- Re: [TLS] TLS 1.3 certificate delegation? Andy Lutomirski
- Re: [TLS] TLS 1.3 certificate delegation? Peter Sylvester
- Re: [TLS] TLS 1.3 certificate delegation? Martin Rex
- Re: [TLS] TLS 1.3 certificate delegation? Peter Sylvester