IETF Logo Mail Archive

Re: [TLS] DSS with other than SHA-1 algorithms

Juho Vähä-Herttua <juhovh@iki.fi> Wed, 27 April 2011 10:23 UTC

Return-Path: <juhovh@iki.fi>
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 8FFC1E069A for <tls@ietfa.amsl.com>; Wed, 27 Apr 2011 03:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSMdu5G4xGfA for <tls@ietfa.amsl.com>; Wed, 27 Apr 2011 03:23:23 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2FE068F for <tls@ietf.org>; Wed, 27 Apr 2011 03:23:22 -0700 (PDT)
Received: from mail.visino.fi (84.251.121.70) by jenni2.inet.fi (8.5.133) id 4D9AC72600F66F13 for tls@ietf.org; Wed, 27 Apr 2011 13:23:22 +0300
Received: from [130.233.194.202] (tko-add-202.cs.hut.fi [130.233.194.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id D929D20395 for <tls@ietf.org>; Wed, 27 Apr 2011 13:23:21 +0300 (EEST)
Message-ID: <4DB7EE85.2090700@iki.fi>
Date: Wed, 27 Apr 2011 13:23:01 +0300
From: Juho Vähä-Herttua <juhovh@iki.fi>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: tls@ietf.org
References: <E1QDyT7-0006mk-PF@login01.fos.auckland.ac.nz> <4DB6FD14.20203@gnutls.org>
In-Reply-To: <4DB6FD14.20203@gnutls.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] DSS with other than SHA-1 algorithms
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: Wed, 27 Apr 2011 10:23:23 -0000

26.4.2011 20:12, Nikos Mavrogiannopoulos kirjoitti:
> * A single ciphersuite negotiates the ECDHE parameters
> AND the parameters of the ECDSA certificate. Could there
> be cases where one can verify any ECDSA certificate, and
> only his capabilities to ECDHE are restricted? In that
> case it might be better to allow for any ECDSA certificate
> rather than handling each different parameter
> as different algorithm. (but I repeat I don't have an
> overview of ECC in practice).

I could comment here, that both ECDSA signing and verification consist 
of ECC point multiplication and modulo operations. The ECDH operation on 
the other hand is a simple ECC point multiplication with no additional 
parameters. Therefore, if there is a case where one can verify an ECDSA 
certificate but his capabilities to ECDHE are restricted, the 
restrictions are completely artificial. Only thing coming to my mind 
would be some kind of proprietary or hardware based PKIX library 
supporting ECC but not offering an API to the low level ECC point 
multiplication. If someone knows about this kind of setup could us know 
now, but in my opinion it wouldn't make much sense...

Juho

v2.23.0 | Report a Bug | By Email