Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature

Michael D'Errico <> Thu, 19 September 2013 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F8B321F93D4 for <>; Thu, 19 Sep 2013 10:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1yULM+gfJn0K for <>; Thu, 19 Sep 2013 10:01:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 58CB521F93C4 for <>; Thu, 19 Sep 2013 10:01:32 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id EA941D5C6; Thu, 19 Sep 2013 13:01:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1KbgnwsmRYGr lWSaqUKHsnZJbGI=; b=GCulLxhMFG6Nat0mSNZt5aN8rcDtpVHiK6xgrinaLYPQ QVx0Bwv4Fk4jomHm1nBAZU3QOLoYl+D/JaYTW2zclYwb+MEj5WJTf8kRQiFS95NH wX+pgbvzEbbwq0PAr5l6EK51z+OJ8U+xL+BdDO70XtvQTRopKqQmYFPu1eByQgA=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=TbbPWS dcWdv5bYLjm7lLmeBhXzLq54SWsGuazc74yOeLNxdHpEwwUUXqWq2Z03sb4HNE+q n4Vvvs+ie5YZTMoG6aWqzWTWAMDPjb9wvyHuQhMXMNa9FY9FY+7YxmMjs22T7xQ4 FSDcfOOkbTx658e9xrWK/md6o0KdDFbpDvC5g=
Received: from (unknown []) by (Postfix) with ESMTP id E0C48D5C5; Thu, 19 Sep 2013 13:01:31 -0400 (EDT)
Received: from iMac.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DBAB4D5C4; Thu, 19 Sep 2013 13:01:30 -0400 (EDT)
Message-ID: <>
Date: Thu, 19 Sep 2013 10:01:29 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Daniel Kahn Gillmor <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 21A2A1CE-214D-11E3-B4EC-CE710E5B5709-38729857!
Cc: "" <>
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Sep 2013 17:01:38 -0000

Daniel Kahn Gillmor wrote:
> 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.

Page 47 of RFC 5246 hints at these rules:

    If the client does not send the signature_algorithms extension, the
    server MUST do the following:

    -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
       DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
       sent the value {sha1,rsa}.

    -  If the negotiated key exchange algorithm is one of (DHE_DSS,
       DH_DSS), behave as if the client had sent the value {sha1,dsa}.

    -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
       ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.

Prior to TLS 1.2 it could be assumed that all clients supported RSA, and
if any supported DSA, they would be asking for DSS cipher suites.  Once
people started wanting to use new algorithms (ECC), it became necessary
to have a way for a client to indicate which algorithms it could process.