Re: [TLS] TLS 1.3 certificate delegation?
Peter Sylvester <peter.sylvester@edelweb.fr> Sat, 09 November 2013 09:55 UTC
Return-Path: <peter.sylvester@edelweb.fr>
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 5867A11E81BA for <tls@ietfa.amsl.com>; Sat, 9 Nov 2013 01:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 12dBdgYvTncq for <tls@ietfa.amsl.com>; Sat, 9 Nov 2013 01:55:14 -0800 (PST)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6325611E81B8 for <tls@ietf.org>; Sat, 9 Nov 2013 01:55:14 -0800 (PST)
Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 52FD15E05E; Sat, 9 Nov 2013 10:49:42 +0100 (CET)
Received: from [127.0.0.1] (unknown [192.168.11.68]) by mx1.on-x.com (Postfix) with ESMTP id D5B465E04B; Sat, 9 Nov 2013 10:49:41 +0100 (CET)
Message-ID: <527E067F.9010209@edelweb.fr>
Date: Sat, 09 Nov 2013 10:55:11 +0100
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20131108163432.AE6371AA71@ld9781.wdf.sap.corp>
In-Reply-To: <20131108163432.AE6371AA71@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sat, 09 Nov 2013 09:55:19 -0000
On 11/08/2013 05:34 PM, Martin Rex wrote: > Johannes Merkle wrote: >>>> 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. Taking this out of context is not helpful The specificatiosn makes staements about what the sender has to do, not what the receiver has to verify. 7.4.2. Server Certificate When this message will be sent: > 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? > > One can not "violate" rfc2119 Section 6 more than with the above > statement, so it is null and void. Be strict in what you send, that's violated by some, be liberal in what to receive, this enhances interop in some cases. > > Not only is this method "must be the same algorithm" not required > for interop, it is the the worst possible way to impair interop > without a cause.NO Only if a receiver misinterpretes the rulles about what a sender MUST do as 'you have to verify this and reject if you can detect it'. But that is not what is written. By default a receiver can accept any kinf of garbage, not verify signatures, etc.
- 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