Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
mrex@sap.com (Martin Rex) Fri, 20 September 2013 13:38 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 5A13E21F9A19 for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 06:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.91
X-Spam-Level:
X-Spam-Status: No, score=-9.91 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, 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 Mw1QEJEnNGza for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 06:38:03 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C549721F99FB for <tls@ietf.org>; Fri, 20 Sep 2013 06:37:56 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8KDbsw8002340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Sep 2013 15:37:54 +0200 (MEST)
In-Reply-To: <CALTJjxHSak1aPWms3vct3nq5Ls9MpBHHH-2wkXh8Up6rrBHjhw@mail.gmail.com>
To: Wan-Teh Chang <wtc@google.com>
Date: Fri, 20 Sep 2013 15:37:54 +0200
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: <20130920133754.2AFE51A98B@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
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: Fri, 20 Sep 2013 13:38:07 -0000
Wan-Teh Chang wrote: > > RFC 4492 says: > > Key Exchange Algorithm Server Certificate Type > ---------------------- ----------------------- > > ... > > ECDHE_RSA Certificate MUST contain an > RSA public key authorized for > use in digital signatures. It > MUST be signed with RSA. > > Note: I don't understand why RFC 4492 says "It MUST be signed with RSA." On my scorecard, this is a clear defect of rfc4492. But it is a defect that it inherited from a non-obvious statement in TLSv1.0 (rfc2246): http://tools.ietf.org/html/rfc2246#section-7.4.2 7.4.2. Server certificate Meaning of this message: The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509v3 certificate. It must contain a key which matches the key exchange * method, as follows. Unless otherwise specified, the signing * algorithm for the certificate must be the same as the algorithm for the certificate key. This unreasonable restriction is *NOT* present in SSLv3: http://tools.ietf.org/html/rfc6101#section-5.6.2 5.6.2. Server Certificate If the server is to be authenticated (which is generally the case), the server sends its certificate immediately following the server hello message. The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509.v3 certificate (or a modified X.509 certificate in the case of FORTEZZA(tm) [FOR]). The same message type will be used for the client's response to a certificate request message. So this artificial limitation is a hidden backwards-incompatible change in TLSv1.0, that should have never existed in the first place--and I'm not aware of a TLS implementation which "enforces" this stupidity. What is particularly strange about this defect is that EVERYONE has been using RSA certificates for SSL&TLS Servers since 1996, and the TLSv1.0 spec that was published in 1999 has (due to crypto-political reasons of that area) mandatates a DHE_DSS cipher suite: 9. Mandatory Cipher Suites TLSv1.0 http://tools.ietf.org/html/rfc2246#section-9 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLSv1.1 http://tools.ietf.org/html/rfc4346#section-9 TLS_RSA_WITH_3DES_EDE_CBC_SHA This limitation should be seen as a guidance to CAs to promote interop rather than a self-imposed crippling of TLS implementations. -Martin
- [TLS] which alert for TLS client cert w/o keyUsag… Martin Rex
- Re: [TLS] which alert for TLS client cert w/o key… Michael D'Errico
- Re: [TLS] which alert for TLS client cert w/o key… Wan-Teh Chang
- Re: [TLS] which alert for TLS client cert w/o key… Michael D'Errico
- Re: [TLS] which alert for TLS client cert w/o key… Daniel Kahn Gillmor
- Re: [TLS] which alert for TLS client cert w/o key… Michael D'Errico
- Re: [TLS] which alert for TLS client cert w/o key… Rob Stradling
- Re: [TLS] which alert for TLS client cert w/o key… Martin Rex
- Re: [TLS] which alert for TLS client cert w/o key… Martin Rex