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

Wan-Teh Chang <wtc@google.com> Thu, 19 September 2013 15:43 UTC

Return-Path: <wtc@google.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 9FB3521F9399 for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 08:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 8WvG-ybjO1YN for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 08:43:35 -0700 (PDT)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B103521F8F9A for <tls@ietf.org>; Thu, 19 Sep 2013 08:43:35 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id k4so3683514qaq.6 for <tls@ietf.org>; Thu, 19 Sep 2013 08:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d42lvA/I4a7W7NeAjF4Yx0bODKOphSHuL9fqVwKhP4Y=; b=c2VtJSVx9anpItyay2RwDgsqtqy4BBDDDmUZzFiANXj0uBLpNJAAT08ItOxxjJV9tu XyJiKwBIyZMyG2lP+ZU25OggRZJ7hUcmkSwgooZ85tdXIHHEW3L2l07U1Hw9tw8V05vM RWgVERkLWsTk+YM3mIfJPf+Pqyp+9aPoqwR9XNu65zuFNsiI5M6FKSkt0GQ8OxdMaCto 6Sv5LJVgf/NDzAJCJtoneJxEY+0vtjZjPSts1jMc0LsCpDgrjkO50rLO6K1TjCzkNZiI QtDG+gVuWIkuodS24T6Jmk9zojTpSFyQJLEWQuohNu9SB7mx0ZkkQE+RY5cHs7vmR335 /HFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d42lvA/I4a7W7NeAjF4Yx0bODKOphSHuL9fqVwKhP4Y=; b=ifI3NTDMzDESqRysA8BJ6P8Sqedld4pFss/VUAAvPHSqnXQAYQ5DcPa5R0zAjg3zc6 YEJyC3HJVvH6doZO0w5ziXO87b5NdDTxZMgkAhPbvRsDd3GLpRdPa4J+IziFLLvu9khs pyC0fywx3T2yyxd01yp7OguJ76E65lu05YsBC510MRTyvFyYdKKq6lOI9u2fVOpHebpM 12uliein2eV9d7+fcJVTeZyqsqJktnnVZzzRcQv2UUiQKPTm+ADxVZXbzaNJW6q0XoUV eIIf3BmCxkKyCnfKPTLmzMjhI/UKn3MfWsOoLddw/V+vYqHqFyGwA9y2ESLY4vmNumc4 4ubw==
X-Gm-Message-State: ALoCoQkQOUWLRiHCKISC0nf70lRbJf465zc4b9IfK3pVYSgbfywT/tQFBPMoe8smTQHYEOPTpEdqz2oGmQ2EIx37+MNumYQIqTAiFwtdZmnll4KVHokpgph9oJ1Z2JkUZPMxpYTdhQ00jL/+QyemAjK3Iq6pTQ2JtujgGOvaQk5BQ0NuMPcOsDtcIaRjUYJtrr7ozlIMusQD
MIME-Version: 1.0
X-Received: by 10.49.58.174 with SMTP id s14mr4724994qeq.73.1379605412992; Thu, 19 Sep 2013 08:43:32 -0700 (PDT)
Received: by 10.229.176.133 with HTTP; Thu, 19 Sep 2013 08:43:32 -0700 (PDT)
In-Reply-To: <20130919095434.D99621A986@ld9781.wdf.sap.corp>
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp>
Date: Thu, 19 Sep 2013 08:43:32 -0700
Message-ID: <CALTJjxHSak1aPWms3vct3nq5Ls9MpBHHH-2wkXh8Up6rrBHjhw@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
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 15:43:36 -0000

On Thu, Sep 19, 2013 at 2:54 AM, Martin Rex <mrex@sap.com> wrote:
> I'm wondering which ssl/tls alert would be the most appropriate
> for a TLS server to send if the server requested a client cert
> and the client presents a certificate with a keyUsage that
> does not have digitalSignature asserted.
>
> OpenSSL seems to send "illegal parameter" alert when processing
> CertificateVerify.  I might have chosen "bad certificate" alert.

I would also choose an alert related to certificates, such as
bad_certificate, unsupported_certificate, or certificate_unknown.

As far as I can tell, NSS intends to send certificate_unknown under
this condition (and similarly for a server certificate with the wrong
keyUsage), but I don't know if it actually does that.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.207&mark=2886,2895-2897#2885

> A related issue would be that a TLS server is using a server
> certificate with an RSA key and a keyUsage attribute with just
> keyEncipherment.  Such a TLS server cert seems to preclude
> its use for DHE_RSA and ECDHE_RSA cipher suites.

Yes. The TLS 1.0 RFC says:

       Key Exchange Algorithm  Certificate Key Type

       RSA                     RSA public key; the certificate must
                               allow the key to be used for encryption.

       ...

       DHE_RSA                 RSA public key which can be used for
                               signing.

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."

Wan-Teh Chang