From tls-bounces@lists.ietf.org Wed Jul 13 11:51:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjWZ-0002SC-NX; Wed, 13 Jul 2005 11:51:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjWZ-0002S7-9V for tls@megatron.ietf.org; Wed, 13 Jul 2005 11:51:51 -0400 Received: from mail.ncipher.com (mail.ncipher.com [82.108.130.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25834 for ; Wed, 13 Jul 2005 11:51:48 -0400 (EDT) Received: from idaho.ncipher.com ([172.23.135.114]) by mail.ncipher.com with esmtp (Exim 3.34 #1) id 1DsjW3-0001MU-00 for tls@lists.ietf.org; Wed, 13 Jul 2005 16:51:19 +0100 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <4F4CFA2F-A1D4-49F1-B6F6-D772878A96EC@ncipher.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tls@ietf.org From: Nicko van Someren Date: Wed, 13 Jul 2005 16:51:18 +0100 X-Mailer: Apple Mail (2.733) Content-Transfer-Encoding: 7bit Cc: Subject: [TLS] (no subject) 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Mon, 20 Jun 2005 at 11:59:16 -0600, Bodo Moeller wrote: > On Mon, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote: > > >>> I have argued for a general mechanism for ciphersuite-dependent > TLS > >>> extensions in the past. That is, instead of having individual > >>> specifications defining TLS extensions provide means of > restricting > >>> certain extensions to certain ciphersuites, it would make sense to > >>> have a mechanism that can be applied to all extensions, preferably > >>> defined in the successor of RFC 3456. > > >> This is a big change and I don't want to make this a gating > factor for > >> advancing the ECC draft. > >> > >> WG members: I'd like to come to some resolution on the basic > issue of > >> whether curves should be negotiable on a per-cipher-suite basis. > >> My intuition is that the case Ari mentions is kind of a corner > >> case--most SSL/TLS implementations aren't assembled pluggably > like this. > >> But, I'm happy to listen to arguments that I'm wrong here... > > > I agree that relying on a general purpose mech. to be defined in the > > successor of RFC 3456 may introduce a long delay before the ECC > draft is > > finalized into an RFC. However, allowing third parties to plug > in their > > cipher suites is an important scenario as it facilitates security > > vendors to provide a significant value add (in terms of perf. + > cipher > > suites that adhere to local crypto standards). > > > > It is possible to address the cipher suite/curve mapping directly > in the > > ECC draft (without dependencies on a general purpose mech) as I > > suggested in the earlier msg. > > I think doing this directly in the TLS-ECC specification is not the > best option because > > - this would mean reinventing the wheel when other ciphersuites need > similar mechanisms, adding some complexity to each of the affected > specifications individually; and > > - it already fails to take into account trusted_ca_keys (an extension > defined in RFC 3456, which appears destined for ciphersuite- > dependent > use in the context of plug-ins). > > Let me point out that one alternative for how to proceed is to pass > the TLS Extensions and TLS-ECC specifications without provisions for > ciphersuite-dependent negotiation, but standardize a TLS extension for > ciphersuite-dependent TLS extensions later in a separate document > ("TLS-CD-Ext"). Obviously TLS-CD-Ext support couldn't be made a > "MUST" then, so for best interoperability ciphersuite-dependent TLS > extensions could be defined so as to allow them to extend the list of > ciphersuites given in the "cipher_suites filed" of the Client Hello > message -- i.e., clients can make ciphersuites invisible from servers > that do not support TLS-CD-Ext. > > This will keep the basic protocols simple, but optionally provide the > desired flexibility. At first, while TLS-CD-Ext is used only in the > context of TLS-ECC, the implementation overhead might be slightly > higher for putting this directly into the TLS-ECC specification (which > would, however, omit ciphersuite-dependent use of the trusted_ca_keys > extension); but as soon as some other set of ciphersuites has use for > TLS-CD-Ext, this more general approach should become easier to handle. Sorry arrive late on this one but I've been having ongoing trouble getting messages through to this list. Hopefully this message will make it. Here's a repeat of what I tried to send before: As a vendor of widely used hardware for handling the crypto in TLS session negotiations I would like to lend my support for Ari's model of being able to specify specific extensions on specific cipher suits, and in particular specifying different ECC curves on different suits. While this seems like unnecessary complication it actually saves implementers from much worse complication if you do it the other way. Here's why: When implementing crypto in hardware, and in particular when implementing ECC, it is common for various types of hardware to have quite rigid limitations regarding the curve parameters. It is also the case that software implementations of ECC often have limitations due to the patent minefield in this space. This will be worst on hardware like ECC smartcards being used for client authentication but is also the case even on big, fast ECC chips from Motorola or software libraries which have been carefully constructed to skirt around IP issues. Due to the fragmented nature of the ECC market different types of hardware and software will have different limitations; some hardware might support MQV because it has a Certicom patent license but only work on binary curves (because they are easy in hardware) while the software "fall-back" for prime curves might not support MQV at all because it lacks a license. So we are in a situation where the intersection of supported parameters across the whole set of cipher suites ends up being the empty set and we are stuck. Eric said "My intuition is that the case Ari mentions is kind of a corner case--most SSL/TLS implementations aren't assembled pluggably like this. But, I'm happy to listen to arguments that I'm wrong here...". My feeling, from dealing with a great many SSL implementations, is that they very much are modular in nature, or at least their owners would like them to be :-) and that pluggable crypto is very important. Certainly the vast majority of SSL stacks that support hardware support it through some plug-in mechanism and while I expect it is rare for any individual system to have more than one type of hardware plugged in at a time it is quite frequently the case that there will be a hardware implementation and a software implementation operating side by side and, for the reasons outlined above, this will potentially be an issue. Anyway, that's my 2p (or 3.53 cents :-) worth! Cheers, Nicko van Someren CTO, nCipher Plc. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 20 16:55:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvLbc-0007Yd-HW; Wed, 20 Jul 2005 16:55:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvLbS-0007VP-Pr for tls@megatron.ietf.org; Wed, 20 Jul 2005 16:55:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20704 for ; Wed, 20 Jul 2005 16:55:39 -0400 (EDT) Received: from 209-204-118-122.sniparpa.net ([209.204.118.122] helo=bcisse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvM4y-00077b-WE for tls@ietf.org; Wed, 20 Jul 2005 17:26:36 -0400 Received: from simon ([216.13.13.68]) by bcisse.com; Wed, 20 Jul 2005 16:54:25 -0400 From: "Simon Blake-Wilson" To: Subject: RE: [TLS] Cipher-suite specific extensions Date: Wed, 20 Jul 2005 16:53:49 -0400 Message-ID: <05d801c58d6d$36c3f210$3200a8c0@simon> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <4F4CFA2F-A1D4-49F1-B6F6-D772878A96EC@ncipher.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: quoted-printable Cc: 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi folks, I thought it might be worth considering how much of a change to RFC = 3456-bis would be required in order to specific a framework for cipher suite = specific extensions. The text below is an off-the-top-of-my-head attempt at some = text aiming to introduce support with minimal changes. Any thoughts on whether the text below would be sufficient (or whether = I'm totally missing the point) would be much appreciated. It seems to me = that if the approach is sufficient then it could be added quickly to RFC = 3456-bis. (And if this is all that has to be done to 3456-bis to close this = discussion and move forward then I can live with it!) Best regards. Simon Insert into 3456-bis in Section 2.3 below the definition of "Extension": ""extension_data" may contain any information pertinent to the extension using any syntax. All the extensions defined in this document apply generically to all cipher suites, but future extensions may be "cipher = suite dependent" - i.e. the options negotiated may differ depending on the selected cipher suite. For such cipher suite specific extensions, "extension_data" SHOULD contain "CSSpecificExtension" defined as = follows: struct { CipherSuite cipher_suites<2...2^16-1>; opaque cs_specific_extension_data<0...2^16-1> } CSSpecificExtensionInfo ; struct { CSSpecificExtensionInfo cs_specific_extension_info_list<1...2^16-1> } CSSpecificExtension ; Where: - "cipher_suites" identifies a list of cipher suites. - "cs_specific_extension_data" contains extension specific information pertinent to the preceding list of cipher suites.=20 Note that the set of cipher suites in any cipher suite specific = extension may be different from the list of cipher suites in the client hello. = This allows, for example, the extension to take a fixed value regardless of = which cipher suites are being requested by the client." > -----Original Message----- > From: tls-bounces@lists.ietf.org=20 > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Nicko van Someren > Sent: Wednesday, July 13, 2005 11:51 AM > To: tls@ietf.org > Subject: [TLS] (no subject) >=20 >=20 > On Mon, 20 Jun 2005 at 11:59:16 -0600, Bodo Moeller wrote: >=20 > > On Mon, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote: > > > > >>> I have argued for a general mechanism for ciphersuite-dependent > > TLS > > >>> extensions in the past. That is, instead of having individual=20 > > >>> specifications defining TLS extensions provide means of > > restricting > > >>> certain extensions to certain ciphersuites, it would=20 > make sense to=20 > > >>> have a mechanism that can be applied to all extensions,=20 > preferably=20 > > >>> defined in the successor of RFC 3456. > > > > >> This is a big change and I don't want to make this a gating > > factor for > > >> advancing the ECC draft. > > >> > > >> WG members: I'd like to come to some resolution on the basic > > issue of > > >> whether curves should be negotiable on a=20 > per-cipher-suite basis. My=20 > > >> intuition is that the case Ari mentions is kind of a corner=20 > > >> case--most SSL/TLS implementations aren't assembled pluggably > > like this. > > >> But, I'm happy to listen to arguments that I'm wrong here... > > > > > I agree that relying on a general purpose mech. to be=20 > defined in the=20 > > > successor of RFC 3456 may introduce a long delay before the ECC > > draft is > > > finalized into an RFC. However, allowing third parties to plug > > in their > > > cipher suites is an important scenario as it facilitates=20 > security=20 > > > vendors to provide a significant value add (in terms of perf. + > > cipher > > > suites that adhere to local crypto standards). > > > > > > It is possible to address the cipher suite/curve mapping directly > > in the > > > ECC draft (without dependencies on a general purpose mech) as I=20 > > > suggested in the earlier msg. > > > > I think doing this directly in the TLS-ECC specification is not the=20 > > best option because > > > > - this would mean reinventing the wheel when other ciphersuites need > > similar mechanisms, adding some complexity to each of the affected > > specifications individually; and > > > > - it already fails to take into account trusted_ca_keys (an=20 > extension > > defined in RFC 3456, which appears destined for ciphersuite- > > dependent > > use in the context of plug-ins). > > > > Let me point out that one alternative for how to proceed is to pass=20 > > the TLS Extensions and TLS-ECC specifications without=20 > provisions for=20 > > ciphersuite-dependent negotiation, but standardize a TLS=20 > extension for=20 > > ciphersuite-dependent TLS extensions later in a separate document=20 > > ("TLS-CD-Ext"). Obviously TLS-CD-Ext support couldn't be made a=20 > > "MUST" then, so for best interoperability ciphersuite-dependent TLS=20 > > extensions could be defined so as to allow them to extend=20 > the list of=20 > > ciphersuites given in the "cipher_suites filed" of the Client Hello=20 > > message -- i.e., clients can make ciphersuites invisible=20 > from servers=20 > > that do not support TLS-CD-Ext. > > > > This will keep the basic protocols simple, but optionally=20 > provide the=20 > > desired flexibility. At first, while TLS-CD-Ext is used=20 > only in the=20 > > context of TLS-ECC, the implementation overhead might be slightly=20 > > higher for putting this directly into the TLS-ECC=20 > specification (which=20 > > would, however, omit ciphersuite-dependent use of the=20 > trusted_ca_keys=20 > > extension); but as soon as some other set of ciphersuites=20 > has use for=20 > > TLS-CD-Ext, this more general approach should become easier=20 > to handle. >=20 > Sorry arrive late on this one but I've been having ongoing trouble =20 > getting messages through to this list. Hopefully this message will =20 > make it. Here's a repeat of what I tried to send before: >=20 > As a vendor of widely used hardware for handling the crypto in TLS =20 > session negotiations I would like to lend my support for Ari's model =20 > of being able to specify specific extensions on specific cipher =20 > suits, and in particular specifying different ECC curves on=20 > different =20 > suits. While this seems like unnecessary complication it actually =20 > saves implementers from much worse complication if you do it the =20 > other way. Here's why: >=20 > When implementing crypto in hardware, and in particular when =20 > implementing ECC, it is common for various types of hardware to have =20 > quite rigid limitations regarding the curve parameters. It is also =20 > the case that software implementations of ECC often have limitations =20 > due to the patent minefield in this space. This will be worst on =20 > hardware like ECC smartcards being used for client=20 > authentication but =20 > is also the case even on big, fast ECC chips from Motorola or =20 > software libraries which have been carefully constructed to skirt =20 > around IP issues. Due to the fragmented nature of the ECC market =20 > different types of hardware and software will have different =20 > limitations; some hardware might support MQV because it has a =20 > Certicom patent license but only work on binary curves (because they =20 > are easy in hardware) while the software "fall-back" for=20 > prime curves =20 > might not support MQV at all because it lacks a license. So we are =20 > in a situation where the intersection of supported parameters across =20 > the whole set of cipher suites ends up being the empty set=20 > and we are =20 > stuck. >=20 > Eric said "My intuition is that the case Ari mentions is kind of a =20 > corner case--most SSL/TLS implementations aren't assembled pluggably =20 > like this. But, I'm happy to listen to arguments that I'm wrong =20 > here...". My feeling, from dealing with a great many SSL =20 > implementations, is that they very much are modular in nature, or at =20 > least their owners would like them to be :-) and that pluggable =20 > crypto is very important. Certainly the vast majority of SSL stacks =20 > that support hardware support it through some plug-in mechanism and =20 > while I expect it is rare for any individual system to have=20 > more than =20 > one type of hardware plugged in at a time it is quite frequently the =20 > case that there will be a hardware implementation and a software =20 > implementation operating side by side and, for the reasons outlined =20 > above, this will potentially be an issue. >=20 > Anyway, that's my 2p (or 3.53 cents :-) worth! >=20 > Cheers, > Nicko van Someren > CTO, nCipher Plc. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 21 04:39:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWaN-0001ed-WD; Thu, 21 Jul 2005 04:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWaM-0001eV-6m for tls@megatron.ietf.org; Thu, 21 Jul 2005 04:39:18 -0400 Received: from pop03.mail.atl.earthlink.net (pop03.mail.atl.earthlink.net [207.69.200.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12201 for ; Thu, 21 Jul 2005 04:39:15 -0400 (EDT) Received: from 1cust127.tnt37.dfw9.da.uu.net ([67.234.20.127] helo=ix.netcom.com) by pop03.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DvWaI-0005Sm-00 for tls@lists.ietf.org; Thu, 21 Jul 2005 04:39:14 -0400 Message-ID: <42DF78A7.D2DE8F33@ix.netcom.com> Date: Thu, 21 Jul 2005 03:27:53 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: TLS List Content-Type: multipart/mixed; boundary="------------826B17465BC68C3D1C77383E" Cc: Subject: [TLS] [Fwd: FYI: High Assurance SSL Certificates and Next Meeting] 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------826B17465BC68C3D1C77383E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I am forwarding this as some of you may be interested and Ben gave me permission to do so. If any of you on this forum are interested the contact info is included. Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 --------------826B17465BC68C3D1C77383E Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mail.abanet.org ([205.247.33.13]) by mx-avoceta.atl.sa.earthlink.net (EarthLink SMTP Server) with SMTP id 1dVi7N4CO3Nl34k3 for ; Wed, 20 Jul 2005 13:12:51 -0400 (EDT) Received: from mail (mail.abanet.org) by mail.abanet.org (LSMTP for Windows NT v1.1b) with SMTP id <2.005C71F8@mail.abanet.org>; Wed, 20 Jul 2005 12:14:23 -0500 Received: by MAIL.ABANET.ORG (LISTSERV-TCP/IP release 14.3) with spool id 13560516 for ST-ISC@MAIL.ABANET.ORG; Wed, 20 Jul 2005 12:14:23 -0500 Received: from smtp1.abanet.org (dnsext02.abanet.org) by mail.abanet.org (LSMTP for Windows NT v1.1b) with SMTP id <1.00173350@mail.abanet.org>; Wed, 20 Jul 2005 12:14:22 -0500 Received: from omr5.netsolmail.com (localhost [127.0.0.1]) by smtp1.abanet.org with ESMTP id j6KHBxmj021014 for ; Wed, 20 Jul 2005 12:11:59 -0500 (CDT) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j6KHBvqt009650 for ; Wed, 20 Jul 2005 13:12:00 -0400 (EDT) Received: from btwpc (67.104.2.36.ptr.us.xo.net [67.104.2.36]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DRA26168; Wed, 20 Jul 2005 13:11:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Message-ID: <97763FEE10B9AA419999C5FE30040219CECC76@serv1.smithhartvigsen.com> Date: Wed, 20 Jul 2005 11:15:52 -0600 Reply-To: "Benjamin T. Wilson" Sender: Information Security Committee From: "Benjamin T. Wilson" Subject: High Assurance SSL Certificates and Next Meeting To: ST-ISC@MAIL.ABANET.ORG Precedence: list X-ELNK-AV: 0 Content-Transfer-Encoding: quoted-printable Everyone, I will be meeting with several Certification Authorities next week in Boston. Because of the ISC's work with the Digital Signature Guidelines = and the PKI Assessment Guidelines, I anticipate that they will be asking the = ISC to participate with them and the browser developers in an effort to develop/refine guidelines for the identity verification to be performed prior to the issuance of High Assurance SSL Certificates. Along with = our other projects, we will be discussing this effort at the August meeting = in Chicago--particularly on Thursday, August 4th. To better understand the issue with SSL certificates, read this article - What Is The Point Of Encryption If You Don't Know Who For? by Dr. Colin Walter | 2005-06-21 = - http://www.webpronews.com/it/security/wpn-23-20050621WhatisthePointofEncr= ypt ionifyouDontKnowWhoFor.html. If you are particularly interested in = this work, please e-mail me so I can start a list of volunteers. Even if you can't come, I am sure there will be ways that you can contribute. =20 For those of you who missed the information about our August meeting, = here are the details: =20 NEXT MEETING Wednesday, August 3 through Friday, August 5, we will be meeting in the Jackson Park Room at the Chicago Westin River North Hotel, 320 North Dearborn St. Meetings will run from 8:30 to 5:00. We will let you know when we have a final agenda. However, we expect to have at least one lunchtime speaker each day, and we anticipate discussing, among other interesting topics: * verification/authentication of business/organizational identities for electronic authentication/PKI; * protection of consumer/customer information and corporate financial = data;=20 * cybersecurity, individual privacy, homeland security and critical infrastructure protection; and * results of our membership survey and other related committee issues. You do not need to register for the ABA annual meeting to attend our committee meeting, although we would encourage it. A calendar of events hosted by the Section of Science & Technology Law is at http://www.abanet.org/scitech/annual/brochure.pdf. Please peruse the descriptions of the presentations and pick some to attend. =20 I don't think we have any special rates unless you go through the ABA's Housing Bureau, and to do that you have to register for the ABA = convention. I have been told by someone who was able to make arrangements directly = with the Westin (and got a rate of $129 plus taxes), but the normal rate is = $239. Through the ABA my rate was $169 plus tax. For lodging arrangements, = here are the phone numbers for the Westin River North and a few other hotels nearby:=20 =20 Westin River North=20 320 North Dearborn St. 877-866-9216 House Of Blues Hotel=20 333 N Dearborn St. 312-245-0333=20 Marina City Hotel Enterprises=20 333 N Dearborn St, =20 312-329-1998=20 Amalfi Hotel=20 20 W Kinzie St, (0.09 miles away)=20 312-828-0828=20 Renaissance Chicago Hotel=20 1 W Wacker Dr, (0.10 miles away)=20 312-372-7200, 312-744-1180=20 =20 Great Lakes Spa Suites=20 15 West Hubbard Street, (0.13 miles away)=20 312-527-1311=20 Premier Luxury Suites=20 200 N Dearborn St, (0.15 miles away)=20 312-578-0774, 312-578-9937, 312-321-6247, 312-379-1917=20 =20 Courtyard-Chicago Downtown=20 30 E Hubbard St, (0.18 miles away)=20 312-329-2500=20 Clarion Executive Plaza Hotel=20 71 E Wacker Dr, (0.18 miles away)=20 312-346-7100=20 Hampton Inn Suites=20 33 W Illinois, (0.19 miles away)=20 312-832-0330=20 Club Quarters Wacker Michigan=20 75 E Wacker Dr, (0.19 miles away)=20 312-357-6400=20 Courtyard by Marriott=20 30 E Hubbard, (0.19 miles away)=20 312-329-2500=20 Hard Rock Hotel=20 65 E Wacker Pl, (0.21 miles away)=20 312-345-1000=20 Wyndham Hotels & Resorts=20 333 N Michigan Ave # 2400, (0.26 miles away)=20 312-558-1971=20 Hilton Garden Inn=20 10 E Grand Ave, (0.27 miles away)=20 312-595-0000=20 Hyatt Regency Chicago=20 151 E. Wacker Dr., (0.27 miles away)=20 312-565-1234=20 Homewood Suites=20 40 E Grand St, (0.28 miles away)=20 312-644-2222 Your e-mail address will only be used within the ABA and its entities. We do not sell or rent e-mail addresses to anyone outside the ABA. To change your e-mail address or remove your name from any future general distribution e-mails you can call us at 1-800-285-2221 or write to: American Bar Association Service Center 321 N Clark Street Chicago, IL 60610 To unsubscribe send the following in the body of a message to listserv@abanet.org - unsubscribe st-isc To review our privacy statement, go to http://www.abanet.org/privacy_statement.html. --------------826B17465BC68C3D1C77383E 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 --------------826B17465BC68C3D1C77383E-- From tls-bounces@lists.ietf.org Thu Jul 21 19:34:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvkZ8-0003XI-CC; Thu, 21 Jul 2005 19:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvkZ6-0003XD-Ps for tls@megatron.ietf.org; Thu, 21 Jul 2005 19:34:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01992 for ; Thu, 21 Jul 2005 19:34:53 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvl3C-00028X-Ij for tls@ietf.org; Thu, 21 Jul 2005 20:06:04 -0400 Received: from scholes.stanford.edu (Scholes.Stanford.EDU [171.64.78.72]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j6LNYcJ5023792 for ; Thu, 21 Jul 2005 16:34:39 -0700 Received: (qmail 28996 invoked by uid 1000); 21 Jul 2005 23:35:29 -0000 To: References: <05d801c58d6d$36c3f210$3200a8c0@simon> From: Hovav Shacham In-Reply-To: <05d801c58d6d$36c3f210$3200a8c0@simon> Date: 21 Jul 2005 16:35:29 -0700 Message-ID: <87y87zhgvy.fsf@scholes.stanford.edu> Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [TLS] Re: Cipher-suite specific extensions 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org "Simon Blake-Wilson" writes: > I thought it might be worth considering how much of a change to RFC > 3456-bis would be required in order to specific a framework for > cipher suite specific extensions. What ciphersuites do we expect to need this mechanism? There's the ECC ciphersuites, for curve negotation. Anything else? I'd hesitate to increase the complexity of the extensions mechanism if it's not absolutely necessary. Hovav. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 22 12:25:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw0Kp-0002ls-Md; Fri, 22 Jul 2005 12:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw0Ko-0002lm-AM for tls@megatron.ietf.org; Fri, 22 Jul 2005 12:25:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29999 for ; Fri, 22 Jul 2005 12:25:11 -0400 (EDT) Received: from 209-204-118-122.sniparpa.net ([209.204.118.122] helo=bcisse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw0p4-00047J-7l for tls@ietf.org; Fri, 22 Jul 2005 12:56:31 -0400 Received: from simon (toronto-HSE-ppp4163755.sympatico.ca [70.51.155.127]) by bcisse.com; Fri, 22 Jul 2005 12:22:25 -0400 From: "Simon Blake-Wilson" To: Subject: RE: [TLS] Re: Cipher-suite specific extensions Date: Fri, 22 Jul 2005 12:22:22 -0400 Message-ID: <0c1c01c58ed9$8c2c5450$3200a8c0@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 MIME-Version: 1.0 In-Reply-To: <87y87zhgvy.fsf@scholes.stanford.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 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="===============0942551484==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0942551484== Content-Type: multipart/signed; boundary="----=_NextPart_000_0C18_01C58EB8.00977620"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0C18_01C58EB8.00977620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Hovav, I'm not aware of anything concrete beyond ECC curves and ECC point formats. I guess you could imagine something might be desired for things like RSA key sizes, especially if larger key sizes take off in conjunction with SHA-2. But I think there's been consensus so far that if we're going to go for CS specific ECC extensions, then it should be in the context of a generic mechanism rather than something ECC specific. Best regards. simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Hovav Shacham > Sent: Thursday, July 21, 2005 7:35 PM > To: tls@ietf.org > Subject: [TLS] Re: Cipher-suite specific extensions > > > "Simon Blake-Wilson" writes: > > > I thought it might be worth considering how much of a change to RFC > > 3456-bis would be required in order to specific a framework > for cipher > > suite specific extensions. > > What ciphersuites do we expect to need this mechanism? > There's the ECC ciphersuites, for curve negotation. Anything else? > > I'd hesitate to increase the complexity of the extensions > mechanism if it's not absolutely necessary. > > > Hovav. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_0C18_01C58EB8.00977620 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA3MjIxNjIyMThaMCMGCSqGSIb3 DQEJBDEWBBTHlgM7Vl78/7/kjkEuzl18FpT85zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgKdp4lJz3ZgcRRyGUXkqK9wkK7Qy9nQcIW8OHDMsB29cmKLaJpUSDeHA SaCD3CbzNb5R9nHzFcljvVS675GMnaa6vaWGHIhux6n4w0Paq01AZswVBfpcK3BwH48i+mM6RUqI M9eAbij6e2OboA0prUQuLK9jAMTZiDZZsokOUrr7AAAAAAAA ------=_NextPart_000_0C18_01C58EB8.00977620-- --===============0942551484== 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 --===============0942551484==-- From tls-bounces@lists.ietf.org Fri Jul 22 16:00:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3ha-0005Fo-C3; Fri, 22 Jul 2005 16:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3hY-0005Fi-Rl for tls@megatron.ietf.org; Fri, 22 Jul 2005 16:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17810 for ; Fri, 22 Jul 2005 16:00:54 -0400 (EDT) Received: from cdc-info.cdc.informatik.tu-darmstadt.de ([130.83.167.3] helo=mail.cdc.informatik.tu-darmstadt.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw4Bq-0004Zf-Nk for tls@ietf.org; Fri, 22 Jul 2005 16:32:16 -0400 Received: from cdc-ultra5.cdc.informatik.tu-darmstadt.de (cdc-ultra5 [130.83.167.9]) by mail.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 934FE2CBD; Fri, 22 Jul 2005 22:00:42 +0200 (MET DST) Received: (from moeller@localhost) by cdc-ultra5.cdc.informatik.tu-darmstadt.de (8.11.7p1+Sun/8.11.7) id j6MK0fb10274; Fri, 22 Jul 2005 22:00:41 +0200 (MEST) Date: Fri, 22 Jul 2005 22:00:41 +0200 From: Bodo Moeller To: Simon Blake-Wilson Subject: Re: [TLS] Re: Cipher-suite specific extensions Message-ID: <20050722220040.A10159@cdc.informatik.tu-darmstadt.de> References: <87y87zhgvy.fsf@scholes.stanford.edu> <0c1c01c58ed9$8c2c5450$3200a8c0@simon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0c1c01c58ed9$8c2c5450$3200a8c0@simon>; from sblakewilson@bcisse.com on Fri, Jul 22, 2005 at 12:22:22PM -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 22, 2005 at 12:22:22PM -0400, Simon Blake-Wilson wrote: > I'm not aware of anything concrete beyond ECC curves and ECC point > formats. I guess you could imagine something might be desired for things > like RSA key sizes, especially if larger key sizes take off in conjunction > with SHA-2. The "trusted_ca_keys" extension is also a candidate for ciphersuite- specific use -- if you only have the RSA key of some certification authority, then you wouldn't want to announce this CA as trusted for DSA ciphersuites as well. However, (i) depending on how ciphersuite-specific extensions are approached, "trusted_ca_keys" as an existing extension cannot be retrofitted appropriately; and (ii) in practice you'll get along quite well by circumenventing the problem: as long as CAs use different distinguished names for their different keys, nothing will go wrong. Beyond this particular extension, it depends on how pluggable TLS implementations are expected to be: Is this only about the key exchange stage? Or about the symmetric-key part as well? In the latter case, the "max_fragment_length" and "truncated_hmac" extensions would also have to be used in a ciphersuite-specific way. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls