Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
Nicolas Williams <Nicolas.Williams@sun.com> Tue, 18 August 2009 23:10 UTC
Return-Path: <Nicolas.Williams@sun.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 82FCA3A6BBC for <tls@core3.amsl.com>; Tue, 18 Aug 2009 16:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.916
X-Spam-Level:
X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 4QAM-RcLhUf5 for <tls@core3.amsl.com>; Tue, 18 Aug 2009 16:10:18 -0700 (PDT)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 51DA23A6B14 for <tls@ietf.org>; Tue, 18 Aug 2009 16:10:18 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7INALgM001923 for <tls@ietf.org>; Tue, 18 Aug 2009 23:10:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7INALvm034673 for <tls@ietf.org>; Tue, 18 Aug 2009 17:10:21 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7IMxbUN003790; Tue, 18 Aug 2009 17:59:37 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7IMxYwu003789; Tue, 18 Aug 2009 17:59:34 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 18 Aug 2009 17:59:34 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090818225934.GW1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87ljlgbv2a.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/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, 18 Aug 2009 23:10:19 -0000
On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote: > Quoting: > > Description: The hash of the TLS server's end entity certificate > [RFC5280] as it appears, octet for octet, in the server's Certificate > message (note that the Certificate message contains a > certificate_list, the first element of which is the server's end > entity certificate.) > > I suggest replacing "server's end entity certificate" with "server's > certificate". As far as I understand, it is possibly to use non-EE > certs, e.g. proxy certs, as a server certificate. The RFC 5246 > terminology is to say "sender's certificate" and there is no requirement > to use a EE cert. OK. The thing to emphasize is that we're talking about the first cert in the certificate_list that would be sent by the server. (I say "would be" just to be mindful of the TLS client caching extensions, but I don't think the I-D has to say "would" since the certificate_list will always have been sent at one point or another.) So how about: Description: The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's certificate.) The hash function ... > Quoting: > > agility. The algorithm to be used, however, is derived from the > certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1, > else use whatever hash function the certificate uses. This > > Please say "is signed with" instead of "uses". Hash values may be > present for other purposes in a certificate, but signature fields will > typically only use one hash function. The text you quote is security considerations text; the normative text already says exactly what you ask for. But OK: ... The algorithm to be used, however, is derived from the certificate's signature as described in Section 4.1; to recap: use SHA-256 if the certificate signature algorithm uses MD5 or SHA-1, else use whatever hash function the certificate uses. Now, section 4.1 says "if the certificate's signature hash algorithm is ...". But perhaps it should say "if the hash algorithm used in the certificate's signatureAlgorithm is ...", just to be really accurate and avoid any possible confusion (with, say, the algorithm field of SubjectPublicKeyInfo). Yes? > For completeness, I would add: > > This algorithm agility resolution mechanism assumes that there is a > mapping from every Public-key signature algorithm to one hash > function algorithm. This is the case for all practically used public > key signature algorithms today, but if future public-key signature > algorithms would employ multiple hash functions (or none at all) this > specification needs to be updated to resolve which hash function > should be used. Good point. Thanks! Nico --
- Re: [TLS] "Last call" on draft-altman-tls-channel… Simon Josefsson
- [TLS] "Last call" on draft-altman-tls-channel-bin… Nicolas Williams
- Re: [TLS] "Last call" on draft-altman-tls-channel… Nicolas Williams
- Re: [TLS] "Last call" on draft-altman-tls-channel… Simon Josefsson
- Re: [TLS] "Last call" on draft-altman-tls-channel… Nicolas Williams
- Re: [TLS] "Last call" on draft-altman-tls-channel… Nicolas Williams
- Re: [TLS] "Last call" on draft-altman-tls-channel… Simon Josefsson
- Re: [TLS] "Last call" on draft-altman-tls-channel… Nicolas Williams
- Re: [TLS] "Last call" on draft-altman-tls-channel… Nicolas Williams
- Re: [TLS] "Last call" on draft-altman-tls-channel… Jeffrey Hutzelman
- Re: [TLS] "Last call" on draft-altman-tls-channel… Peter Saint-Andre
- Re: [TLS] "Last call" on draft-altman-tls-channel… Nicolas Williams
- Re: [TLS] "Last call" on draft-altman-tls-channel… Nicolas Williams