Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 19 September 2013 16:18 UTC
Return-Path: <dkg@fifthhorseman.net>
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 DEFF221F92B7 for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 09:18:32 -0700 (PDT)
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 8j7Zq42lE87a for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 09:18:27 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0657021F8B9C for <tls@ietf.org>; Thu, 19 Sep 2013 09:18:27 -0700 (PDT)
Received: from [192.168.13.183] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1AD11F983; Thu, 19 Sep 2013 12:18:21 -0400 (EDT)
Message-ID: <523B23C7.4010704@fifthhorseman.net>
Date: Thu, 19 Sep 2013 12:18:15 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.com>
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp> <CALTJjxHSak1aPWms3vct3nq5Ls9MpBHHH-2wkXh8Up6rrBHjhw@mail.gmail.com> <523B2205.1040103@pobox.com>
In-Reply-To: <523B2205.1040103@pobox.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="----enig2XHSOXQWBLSGKKAACAABK"
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
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: Thu, 19 Sep 2013 16:18:33 -0000
On 09/19/2013 12:10 PM, Michael D'Errico wrote: > Wan-Teh Chang wrote: >> Note: I don't understand why RFC 4492 says "It MUST be signed with RSA." > > A certificate authority could, in theory, sign a certificate using > any algorithm it chooses. Since the client is known to have code > for dealing with RSA (it asked for ECDHE_RSA) but not whether it > has code to validate any other type of signature algorithm, it makes > (practical) sense to limit the CA signature to RSA. But do we limit the certificate signature in any other context? if not, why limit it here? for example, if the EE certificate is signed by an intermediate CA using RSA, but that CA's own cert is signed using DSA or ECDSA, is that OK? Why haven't we applied these same-algorithm constraints to EE certs used in DHE_RSA or RSA key exchanges for that matter? I can see why the spec might recommend the use of RSA signatures on certs that supply RSA keys (for the implementation-simplifying reasons you propose), but making it an RFC 2119 MUST is pretty strong stuff, and weirdly inconsistent with the rest of the specs, as i understand them. --dkg
- [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