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