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

Rob Stradling <rob.stradling@comodo.com> Thu, 19 September 2013 21:19 UTC

Return-Path: <rob.stradling@comodo.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 ECE5021F85C9 for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 14:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level:
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
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 3gte5GGtKBMF for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 14:18:58 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7439521F88FB for <tls@ietf.org>; Thu, 19 Sep 2013 14:18:57 -0700 (PDT)
Received: (qmail 13472 invoked from network); 19 Sep 2013 21:18:56 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 19 Sep 2013 21:18:56 -0000
Received: (qmail 7932 invoked by uid 1000); 19 Sep 2013 21:18:56 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 19 Sep 2013 22:18:56 +0100
Message-ID: <523B6A3F.7000003@comodo.com>
Date: Thu, 19 Sep 2013 22:18:55 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp> <CALTJjxHSak1aPWms3vct3nq5Ls9MpBHHH-2wkXh8Up6rrBHjhw@mail.gmail.com> <523B2205.1040103@pobox.com> <523B23C7.4010704@fifthhorseman.net> <523B2DE9.8090403@pobox.com>
In-Reply-To: <523B2DE9.8090403@pobox.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 21:19:04 -0000

On 19/09/13 18:01, Michael D'Errico wrote:
>>> Wan-Teh Chang wrote:
>>>> Note: I don't understand why RFC 4492 says "It MUST be signed with
>>>> RSA."
<snip>
> Page 47 of RFC 5246 hints at these rules:
<snip>

RFC 5246 relaxes the "It MUST be signed with RSA" rule, doesn't it?

Appendix A.7 (Changes to RFC 4492) says:
   "As described in Sections 7.4.2 and 7.4.6, the restrictions on the
    signature algorithms used to sign certificates are no longer tied to
    the cipher suite (when used by the server) or the
    ClientCertificateType (when used by the client).  Thus, the
    restrictions on the algorithm used to sign certificates specified in
    Sections 2 and 3 of RFC 4492 are also relaxed."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online