Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUF6-0006iV-OV; Thu, 06 Jul 2006 09:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUF5-0006iN-Dh for tls@ietf.org; Thu, 06 Jul 2006 09:50:07 -0400 Received: from [66.48.18.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUF3-0005SS-0O for tls@ietf.org; Thu, 06 Jul 2006 09:50:07 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 99D0B100233C4; Thu, 6 Jul 2006 09:50:01 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31320-18; Thu, 6 Jul 2006 09:49:58 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id AC6CF100233DF; Thu, 6 Jul 2006 09:49:58 -0400 (EDT) In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> To: Eric Rescorla Subject: Re: [TLS] Updated TLS 1.2 I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Thu, 6 Jul 2006 09:49:23 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/06/2006 09:49:25 AM, Serialize complete at 07/06/2006 09:49:25 AM X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1157457464==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1157457464== Content-Type: multipart/alternative; boundary="=_alternative 004C08D9852571A3_=" This is a multipart message in MIME format. --=_alternative 004C08D9852571A3_= Content-Type: text/plain; charset="US-ASCII" 7.4.3. Server key exchange message If the SignatureAlgorithm being used to sign the ServerKeyExchange message is DSA, the hash function used MUST be SHA-1. If the SignatureAlgorithm it must be the same hash function used in the signature of the server's certificate (found in the Certificate) message. This algorithm is denoted Hash below. Hash.length is the length of the output of that algorithm. Something is missing in this sentence "If the SignatureAlgorithm it must be the " ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com Eric Rescorla wrote on 06/25/2006 12:54:30 PM: > I've submitted an update TLS 1.2 I-D an in the meantime > you can find it at: > > http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt > > The big thing I know is misisng is replaceable PRFs, which > I wanted to discuss on the mailing list before I put in. > As people will recall, there was a consensus on replaceable > PRFs/KDFs in Dallas but we didn't discuss exactly how to do > them. > > My proposal is as follows: > > - All PRFs must have the same "API" as the existing TLS > PRFs. > - New cipher suites MAY have as part of their specification > a new PRF. > - There is no way to separately negotiate a new PRF for > an existing cipher suite. > > The major alternative is some kind of extension, which makes > me uncomfortable. > > Thoughts? Issues? > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 004C08D9852571A3_= Content-Type: text/html; charset="US-ASCII"
7.4.3. Server key exchange message

<snip>

If the SignatureAlgorithm being used to sign the ServerKeyExchange
message is DSA, the hash function used MUST be SHA-1. If the
SignatureAlgorithm it must be the same hash function used in the
signature of the server's certificate (found in the Certificate)
message. This algorithm is denoted Hash below. Hash.length is the
length of the output of that algorithm.

Something is missing in this sentence "If the SignatureAlgorithm it must be the "

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX : (905) 507-4230
WEBSITE: www.certicom.com

Eric Rescorla <ekr@networkresonance.com> wrote on 06/25/2006 12:54:30 PM: > I've submitted an update TLS 1.2 I-D an in the meantime > you can find it at: > > http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt > > The big thing I know is misisng is replaceable PRFs, which > I wanted to discuss on the mailing list before I put in. > As people will recall, there was a consensus on replaceable > PRFs/KDFs in Dallas but we didn't discuss exactly how to do > them. > > My proposal is as follows: > > - All PRFs must have the same "API" as the existing TLS > PRFs. > - New cipher suites MAY have as part of their specification > a new PRF. > - There is no way to separately negotiate a new PRF for > an existing cipher suite. > > The major alternative is some kind of extension, which makes > me uncomfortable. > > Thoughts? Issues? > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 004C08D9852571A3_=-- --===============1157457464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1157457464==--