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