Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits

Martin Rex <mrex@sap.com> Tue, 15 February 2011 17:01 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352F53A6CB7 for <tls@core3.amsl.com>; Tue, 15 Feb 2011 09:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.211
X-Spam-Level:
X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5BrVw1k8WMK for <tls@core3.amsl.com>; Tue, 15 Feb 2011 09:01:18 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C7E433A6D13 for <tls@ietf.org>; Tue, 15 Feb 2011 09:01:17 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1FH1gb9002193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2011 18:01:42 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201102151701.p1FH1gVM025768@fs4113.wdf.sap.corp>
To: lists@drh-consultancy.demon.co.uk
Date: Tue, 15 Feb 2011 18:01:42 +0100
In-Reply-To: <4D5AAD0C.5050900@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Feb 15, 11 04:42:52 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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/listinfo/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: Tue, 15 Feb 2011 17:01:19 -0000

Dr Stephen Henson wrote:
> 
> [FIPS 186-3] also says:
> 
> "In addition, an RSA digital signature key pair shall not be used for other
> purposes (e.g., key establishment)."
> 
> I can't imagine many servers using two distinct certificates for ephemeral and
> static RSA ciphersuites, even is the server software supports it.

I noticed that as well.  :)

So I looked at the next best SSL Server cert (happened to be issued
by Thawte SGC) and noticed that it does not contain a KeyUsage
extension (only ExtendedKeyUsage and BasicConstraints cA=FALSE).

static RSA ciphersuites need KeyUsage "keyEncipherment", and
DHE_RSA would need "digitalSignature".  But asserting both in a
cert seems literally incompatible with FIPS 186-3.  


I also noticed the distinction between PKCS1-v1.5 and PKCS1-PSS signatures,
and that RSA keys should be used for only one of the two for their entire
lifetime.  While it is sensible in general to distinguish credentials for
online authentication and credentials for longterm digital signatures,
PKCS1-v1.5 is hardwired into SSLv3 and all current versions of TLS.
I didn't see reference to or definition of an ExtendedKeyUsage OID
to recognize/distinguish RSA PKCS1-PSS keys in FIPS 186-3, which
looks somewhat inconsequential for the v1.5/PSS issue.


-Martin