From 777momo333@docomo.ne.jp Thu Feb 01 11:14:13 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeZh-0006gM-KV for tls-archive@lists.ietf.org; Thu, 01 Feb 2007 11:14:13 -0500 Received: from [220.194.47.148] (helo=kimu03.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCeZc-00087W-KR for tls-archive@lists.ietf.org; Thu, 01 Feb 2007 11:14:13 -0500 Subject: =?ISO-2022-JP?B?g4GBW4OLgqCC6IKqgsaCpIKygrSCooLcgrWCvYH0?= From: 瑞奈 To: tls-archive@lists.ietf.org Message-ID: 20070202011348 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Fri, 2 Feb 2007 01:14:04 +0900 (JST) X-Spam-Score: 3.4 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 お久し振りです。瑞奈です。 先日はメールありがとうございました。 返事が遅くなってしまい、申し訳ありません。 前のメールで質問されていた仕事の話ですが・・・ 私は専業主婦なんです。 去年の12月からずっと家のことをやってて、それで忙しかったんです。 家事は楽しいんですが、さすがに疲れが・・・（＞＜ こんな生活なので出会いもないし、誰かに甘えたくなっちゃう事も多くて。 それで、急にこんな事をいうと変に思われるかもしれませんが 一度会ってお話をしたいのですが、ご迷惑でしょうか？ 私は世田谷区に住んでいる31歳です。 一緒にゴハンを食べたり、たくさんお話がしたいです♪ できれば今週末、新宿か渋谷あたりが私は都合がいいのですが いかがでしょうか？ http://mic.chu.jp/mizuna/ 最近、このサイトを利用しているので ここからメールを下さいませんか？ mixiもやっているのですが、こちらの方が居心地がいいので このサイトばかりを使ってます（＾＾； それでは、お返事をお待ちしていますね。 瑞奈 From tls-bounces@lists.ietf.org Thu Feb 01 13:10:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgN8-0001Qd-BR; Thu, 01 Feb 2007 13:09:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgN6-0001Jt-VQ for tls@ietf.org; Thu, 01 Feb 2007 13:09:20 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCgN5-00043o-I1 for tls@ietf.org; Thu, 01 Feb 2007 13:09:20 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 1 Feb 2007 18:09:18 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 1 Feb 2007 18:09:18 +0000 From: Stefan Santesson To: Eric Rescorla , "tls@ietf.org" Date: Thu, 1 Feb 2007 18:09:16 +0000 Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: Acc+YydFJXSvnnDOR+i2EMwn5y51OAHwpByA Message-ID: References: <20070122202751.CCBC45C01E@laser.networkresonance.com> In-Reply-To: <20070122202751.CCBC45C01E@laser.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Errors-To: tls-bounces@lists.ietf.org Eric, Thank you for the review and the initiative to get a discussion going on th= is draft. All of your comments are valid and lines up with what I thought would be th= e critical issues to discuss. In the end it's a question of whether these c= hanges to TLS are defendable in relation to the benefit to the industry and= the usability of the protocol. Response to your comments 1-3. 1) TLS gets no guarantee of the quality of parameters given by GSS-API. But= TLS is no entity so in a way that is the wrong question. The implementers = of this protocol choose to trust the properties of their GSS-API based tech= nology. The solution of this draft enables them to extend the trusted authe= ntication methods for TLS sessions to the GSS-API methods they already use = and trust. This can't accidently degrade the security for regular TLS users= . But this is nothing new. This line was already crossed by RFC 2712. 2) The extended roundtrips is an un-escapable consequence. If necessary I b= elieve we can define an upper boundary of the number of roundtrips. You are= right that the TLS state machine must rely on GSS-API for validating and c= oncluding the GSS-API exchange. Without being handed the resulting key mate= rial from the GSS-API layer, the TLS state machine must fail. I feel convin= ced that it is possible to define the appropriate set of rules for the TLS = state machine on when to close the connection and fail graciously. 3) I believe the precedent was set by RFC 2712. Security wise we do nothing= worse than RFC 2712 already do. This draft do however solve a number of pr= oblems with RFC 2712. I do not agree that this makes a hole in TLS. This fe= ature will not be enabled unless its specifically agreed between the partie= s who thereby make the decision to trust GSS-API to provide authentication = and keying material. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 22 januari 2007 21:20 > To: tls@ietf.org > Subject: [TLS] Review of draft-santesson-tls-gssapi-00 > > $Id: draft-santesson-tls-gssapi-00-rev.txt,v 1.3 2007/01/22 20:27:34 > ekr Exp $ > > I have reviewed this document and as I indicated in San Diego, I have > serious architectural concerns about the way that it interconnects TLS > and GSS-API. > > 1. It's totally unclear what security guarantees TLS is supposed > to be getting from GSS. In fact, it's not possible to be clear > because there is just some set of mechanism IDs. That may be > fine in limited environments but it's not fine in the general case > where other extensions might be used with TLS. > > 2. TLS assumes a fixed number of round trips which is determinable > from the resumption state. By contrast, once this draft establishes > that GSS is to be used, an arbitrary number of round trips may occur > in some way that is invisible to TLS. First, that's a big change to > the state machine and second it's architecturally problematic. It's > true that there's an indicator in the message for whether it's the > last payload or not, but there's no way for the TLS state machine to > independently determine whether that has been tampered with. It needs > to rely on the GSS state machine. That's problematic both from an > engineering and security standpoint. > > 3. It sets a precedent that the way to interconnect TLS to external > security mechanisms is via creating a hole in TLS to carry their > mechanisms. This makes TLS more complicated, which is of course > the enemy of security protocols. > > > TLS provides a generic mechanism for linking up to externally exchanged > keys, courtesy of RFC 4279. All you need to do is arrange for your > mechanism to create a PSK-Identity binding on both sides and then > you can do an ordinary TLS exchange using TLS PSK. > > In the WG meeting, I heard concerns from the proponents of this draft > that they then needed to arrange a way to carry the GSS handshake and > that since their application protocols already had a cutout for TLS > they wanted to exploit that cutout. I'm not insensitive to this point, > but that doesn't make it architecturally sound. > > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From 888momo444@docomo.ne.jp Fri Feb 02 22:28:36 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDBZs-0006XQ-Sc for tls-archive@lists.ietf.org; Fri, 02 Feb 2007 22:28:36 -0500 Received: from [220.194.47.148] (helo=kimu03.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDBZr-0008MO-Ev for tls-archive@lists.ietf.org; Fri, 02 Feb 2007 22:28:36 -0500 Subject: =?ISO-2022-JP?B?g4GBW4OLgqCC6IKqgsaCpIKygrSCooLcgrWCvYH0?= From: 瑞奈 To: tls-archive@lists.ietf.org Message-ID: 20070203122832 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Sat, 3 Feb 2007 12:28:32 +0900 (JST) X-Spam-Score: 3.4 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 お久し振りです。瑞奈です。 先日はメールありがとうございました。 返事が遅くなってしまい、申し訳ありません。 前のメールで質問されていた仕事の話ですが・・・ 私は専業主婦なんです。 去年の12月からずっと家のことをやってて、それで忙しかったんです。 家事は楽しいんですが、さすがに疲れが・・・（＞＜ こんな生活なので出会いもないし、誰かに甘えたくなっちゃう事も多くて。 それで、急にこんな事をいうと変に思われるかもしれませんが 一度会ってお話をしたいのですが、ご迷惑でしょうか？ 私は世田谷区に住んでいる31歳です。 一緒にゴハンを食べたり、たくさんお話がしたいです♪ できれば今週末、新宿か渋谷あたりが私は都合がいいのですが いかがでしょうか？ http://chu.punyu.jp/mizuna/ 最近、このサイトを利用しているので ここからメールを下さいませんか？ mixiもやっているのですが、こちらの方が居心地がいいので このサイトばかりを使ってます（＾＾； それでは、お返事をお待ちしていますね。 瑞奈 From 777momo333@docomo.ne.jp Sun Feb 04 18:53:17 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrAb-0006eB-2T for tls-archive@lists.ietf.org; Sun, 04 Feb 2007 18:53:17 -0500 Received: from [220.194.47.148] (helo=kimu03.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDrAZ-00075Q-LE for tls-archive@lists.ietf.org; Sun, 04 Feb 2007 18:53:17 -0500 Subject: =?ISO-2022-JP?B?g4GBW4OLgqCC6IKqgsaCpIKygrSCooLcgrWCvYH0?= From: 瑞奈 To: tls-archive@lists.ietf.org Message-ID: 20070205084500 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Mon, 5 Feb 2007 08:45:20 +0900 (JST) X-Spam-Score: 3.4 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 お久し振りです。瑞奈です。 先日はメールありがとうございました。 返事が遅くなってしまい、申し訳ありません。 前のメールで質問されていた仕事の話ですが・・・ 私は専業主婦なんです。 去年の12月からずっと家のことをやってて、それで忙しかったんです。 家事は楽しいんですが、さすがに疲れが・・・（＞＜ こんな生活なので出会いもないし、誰かに甘えたくなっちゃう事も多くて。 それで、急にこんな事をいうと変に思われるかもしれませんが 一度会ってお話をしたいのですが、ご迷惑でしょうか？ 私は世田谷区に住んでいる31歳です。 一緒にゴハンを食べたり、たくさんお話がしたいです♪ できれば今週末、新宿か渋谷あたりが私は都合がいいのですが いかがでしょうか？ http://dalir.noor.jp/848908.htm 最近、このサイトを利用しているので ここからメールを下さいませんか？ mixiもやっているのですが、こちらの方が居心地がいいので このサイトばかりを使ってます（＾＾； それでは、お返事をお待ちしていますね。 瑞奈 From tls-bounces@lists.ietf.org Mon Feb 05 12:31:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7ep-0007yK-26; Mon, 05 Feb 2007 12:29:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7en-0007xA-Ne for tls@ietf.org; Mon, 05 Feb 2007 12:29:33 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7em-0006Q0-Hw for tls@ietf.org; Mon, 05 Feb 2007 12:29:33 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 7EE49B422D for ; Mon, 5 Feb 2007 12:29:52 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id DC644B422B for ; Mon, 5 Feb 2007 12:29:51 -0500 (EST) Message-ID: <45C769D9.3000004@pobox.com> Date: Mon, 05 Feb 2007 09:31:05 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] Certificate Hash Types extension 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: , Errors-To: tls-bounces@lists.ietf.org Somehow I missed this extension when I read the TLS 1.2 spec. (I probably skipped it thinking they were the same as the TLS extensions spec.) Now I'm adding support for it in my server and I have a question about it: should the client order the list of supported hash algorithms in its order of preference? I would think this is a good idea, instead of leaving it up to the server to decide. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 05 14:55:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9uz-00037d-Ee; Mon, 05 Feb 2007 14:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9uy-00037W-QN for tls@ietf.org; Mon, 05 Feb 2007 14:54:24 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE9ux-0002pB-Ks for tls@ietf.org; Mon, 05 Feb 2007 14:54:24 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id F05A8B4307 for ; Mon, 5 Feb 2007 14:54:44 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id BD36BB4327 for ; Mon, 5 Feb 2007 14:54:44 -0500 (EST) Message-ID: <45C78BCE.6090002@pobox.com> Date: Mon, 05 Feb 2007 11:55:58 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [TLS] CertificateRequest in TLS 1.2 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: , Errors-To: tls-bounces@lists.ietf.org In TLS 1.2, a CertificateRequest message has a list of HashTypes specifying the acceptable hashes used in certificate signatures. There is no guidance on the ordering of these values. I would suggest that the server should specify them in the order that it prefers. The client would scan the list in order, and return a certificate using the first matching hash algorithm. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 05 16:19:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBEY-0005PJ-OX; Mon, 05 Feb 2007 16:18:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBEX-0005PD-Oa for tls@ietf.org; Mon, 05 Feb 2007 16:18:41 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEBET-0003Oi-RM for tls@ietf.org; Mon, 05 Feb 2007 16:18:41 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l15LI3tK020881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Feb 2007 22:18:05 +0100 From: Simon Josefsson To: Mike References: <45C769D9.3000004@pobox.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070205:mike-list@pobox.com::hY6tX3tUpQeq/Ohn:Uyf X-Hashcash: 1:22:070205:tls@ietf.org::a8k+KkBiAxjC6pN/:2PdG Date: Mon, 05 Feb 2007 22:18:02 +0100 In-Reply-To: <45C769D9.3000004@pobox.com> (Mike's message of "Mon\, 05 Feb 2007 09\:31\:05 -0800") Message-ID: <87y7ncfgmt.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "tls@ietf.org" Subject: [TLS] Re: Certificate Hash Types extension 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: , Errors-To: tls-bounces@lists.ietf.org Mike writes: > Now I'm adding support for it in my server and I have a > question about it: should the client order the list of > supported hash algorithms in its order of preference? > I would think this is a good idea, instead of leaving it > up to the server to decide. ... > In TLS 1.2, a CertificateRequest message has a list > of HashTypes specifying the acceptable hashes used > in certificate signatures. There is no guidance > on the ordering of these values. I would suggest > that the server should specify them in the order > that it prefers. The client would scan the list > in order, and return a certificate using the first > matching hash algorithm. I had the same reaction to both of these issues. I agree that it would be more useful if the lists are in preference order. Generally, is there a reason the certificate hash type mechanism isn't defined in a symmetrical way? I mean, by using a new extension for both directions. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 06 12:03:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEThE-0003Bl-9c; Tue, 06 Feb 2007 12:01:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEThD-0003Bg-Lz for tls@ietf.org; Tue, 06 Feb 2007 12:01:31 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HETh9-0000oo-8l for tls@ietf.org; Tue, 06 Feb 2007 12:01:31 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l16H10iX027797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Feb 2007 18:01:01 +0100 X-Hashcash: 1:22:070206:tls@ietf.org::Uao/nyKkj9NL35Io:2MrQ From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Tue, 06 Feb 2007 18:01:00 +0100 Message-ID: <87hctzdxv7.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [TLS] Test server with TLS 1.2, OpenPGP, SRP, PSK, X.509 and more 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: , Errors-To: tls-bounces@lists.ietf.org Inspired by Mike's test server, I have set up a HTTPS test server based on the latest GnuTLS release. The server implements SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 (as of -02), with authentication support for OpenPGP, X.509, SRP and PSK. For more information, see: http://www.gnu.org/software/gnutls/server.html The server itself is available from: https://test.gnutls.org:5556/ I won't be watching the logs of it, so if you have problems with, you'll need to contact me. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 06 13:57:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEVTW-0000AH-Qp; Tue, 06 Feb 2007 13:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEVTV-00008X-N4 for tls@ietf.org; Tue, 06 Feb 2007 13:55:29 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEVTR-00060n-GQ for tls@ietf.org; Tue, 06 Feb 2007 13:55:29 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id D1DF0B4D0C for ; Tue, 6 Feb 2007 13:55:45 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 9DC40B4CEF for ; Tue, 6 Feb 2007 13:55:45 -0500 (EST) Message-ID: <45C8CF74.5000605@pobox.com> Date: Tue, 06 Feb 2007 10:56:52 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] Certificate Hash Types extension supported 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: , Errors-To: tls-bounces@lists.ietf.org I added support to my test server for the certificate hash types extension. Both www.mikestoolbox.net and www.mikestoolbox.org have SHA-1 and SHA-256 certificate chains. They share an IP address, so you will need to use a server name extension to get to .org. The server returns the first matching certificate chain based on the order of the HashTypes sent by the client. Currently this is not specified in the draft spec. Please let me know if you encounter any problems. Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 06 14:03:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEVan-0003Ej-4Y; Tue, 06 Feb 2007 14:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEVam-0003Ee-7o for tls@ietf.org; Tue, 06 Feb 2007 14:03:00 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEVal-00008I-1R for tls@ietf.org; Tue, 06 Feb 2007 14:03:00 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id C5A31B4D1B for ; Tue, 6 Feb 2007 14:03:20 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 9204CB4C94 for ; Tue, 6 Feb 2007 14:03:20 -0500 (EST) Message-ID: <45C8D13A.1000300@pobox.com> Date: Tue, 06 Feb 2007 11:04:26 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Certificate Hash Types extension supported References: <45C8CF74.5000605@pobox.com> In-Reply-To: <45C8CF74.5000605@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: tls-bounces@lists.ietf.org Sorry I forgot to mention that it listens on port 443. Mike I wrote: > I added support to my test server for the certificate > hash types extension. Both www.mikestoolbox.net and > www.mikestoolbox.org have SHA-1 and SHA-256 certificate > chains. They share an IP address, so you will need to > use a server name extension to get to .org. > > The server returns the first matching certificate chain > based on the order of the HashTypes sent by the client. > Currently this is not specified in the draft spec. > > Please let me know if you encounter any problems. > > Thanks, > > Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 08 11:01:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBg9-0004Z2-Ts; Thu, 08 Feb 2007 10:59:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBg8-0004Yv-Rl for tls@ietf.org; Thu, 08 Feb 2007 10:59:20 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFBg5-0004Ur-L8 for tls@ietf.org; Thu, 08 Feb 2007 10:59:20 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 23B38B5AD2 for ; Thu, 8 Feb 2007 10:59:37 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id E6F92B5A72 for ; Thu, 8 Feb 2007 10:59:36 -0500 (EST) Message-ID: <45CB4922.1060504@pobox.com> Date: Thu, 08 Feb 2007 08:00:34 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] extension number conflict 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: , Errors-To: tls-bounces@lists.ietf.org The number used for the cert_hash_types extension in draft-ietf-tls-rfc4346-bis-02.txt is 6, but this conflicts with the user_mapping extension defined in RFC 4681. Has the IANA been asked to assign a new number for the cert_hash_types extension? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 08 11:27:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFC6a-0001JJ-PD; Thu, 08 Feb 2007 11:26:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFC6Z-0001J7-21 for tls@ietf.org; Thu, 08 Feb 2007 11:26:39 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFC6X-0001ij-QJ for tls@ietf.org; Thu, 08 Feb 2007 11:26:39 -0500 Received: (qmail 20141 invoked by uid 0); 8 Feb 2007 16:26:30 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 8 Feb 2007 16:26:30 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Feb 2007 11:26:28 -0500 To: Mike ,tls@ietf.org From: Russ Housley Subject: Re: [TLS] extension number conflict In-Reply-To: <45CB4922.1060504@pobox.com> References: <45CB4922.1060504@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: tls-bounces@lists.ietf.org Message-Id: IANA makes assignments when the documents are approved. It should have "TBD" in the document until that happens. Russ At 11:00 AM 2/8/2007, Mike wrote: >The number used for the cert_hash_types extension in >draft-ietf-tls-rfc4346-bis-02.txt is 6, but this >conflicts with the user_mapping extension defined in >RFC 4681. > >Has the IANA been asked to assign a new number for >the cert_hash_types extension? > >Thanks, > >Mike > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 08 18:01:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIFF-0004dF-80; Thu, 08 Feb 2007 18:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIFD-0004d8-Gc for tls@ietf.org; Thu, 08 Feb 2007 17:59:59 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFIFB-0001yV-JS for tls@ietf.org; Thu, 08 Feb 2007 17:59:59 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA24559; Thu, 8 Feb 2007 23:59:51 +0100 (MEZ) From: Martin Rex Message-Id: <200702082259.XAA10273@uw1048.wdf.sap.corp> Subject: Re: [TLS] extension number conflict To: housley@vigilsec.com (Russ Housley) Date: Thu, 8 Feb 2007 23:59:50 +0100 (MET) In-Reply-To: from "Russ Housley" at Feb 8, 7 11:26:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > > IANA makes assignments when the documents are approved. It should > have "TBD" in the document until that happens. Personally, I think that is somewhat late. How about defining a process to "last call" whether a feature should be added to the next revision of a document/protocol standards so that IANA could issue a number before the actual document gets last called -- so that implementors will not have to change code later on. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 08 18:43:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIuR-0004m8-Sk; Thu, 08 Feb 2007 18:42:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFIuQ-0004jC-8U for tls@ietf.org; Thu, 08 Feb 2007 18:42:34 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFIuP-0001kI-2B for tls@ietf.org; Thu, 08 Feb 2007 18:42:34 -0500 Received: from sceptre.pobox.com (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id D924BA7B for ; Thu, 8 Feb 2007 18:42:53 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id A3CCD2692E for ; Thu, 8 Feb 2007 18:42:53 -0500 (EST) Message-ID: <45CBB5B5.9020305@pobox.com> Date: Thu, 08 Feb 2007 15:43:49 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] extension number conflict References: <200702082259.XAA10273@uw1048.wdf.sap.corp> In-Reply-To: <200702082259.XAA10273@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: tls-bounces@lists.ietf.org >> IANA makes assignments when the documents are approved. It should >> have "TBD" in the document until that happens. > > Personally, I think that is somewhat late. I agree. I had to disable the code that implements this feature since there is no way to access it. This makes it difficult to test, especially between differing implementations. For a feature that will obviously be approved, shouldn't there be a way to assign it a number sooner than RFC publication? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 08 19:03:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJDN-0001ox-Dx; Thu, 08 Feb 2007 19:02:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJDI-0001lS-EB for tls@ietf.org; Thu, 08 Feb 2007 19:02:05 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJCg-0003EH-Qr for tls@ietf.org; Thu, 08 Feb 2007 19:02:04 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 9 Feb 2007 00:01:25 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 9 Feb 2007 00:01:25 +0000 From: Stefan Santesson To: Mike , "tls@ietf.org" Date: Fri, 9 Feb 2007 00:01:16 +0000 Subject: RE: [TLS] extension number conflict Thread-Topic: [TLS] extension number conflict Thread-Index: AcdL2vIfXlI6Lu6oTDW6nUwD4HiggwAAhhdw Message-ID: References: <200702082259.XAA10273@uw1048.wdf.sap.corp> <45CBB5B5.9020305@pobox.com> In-Reply-To: <45CBB5B5.9020305@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: tls-bounces@lists.ietf.org What about assigning an experimental/local range that can be used until the= real number is assigned. That should avoid conflicts effectively. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Mike [mailto:mike-list@pobox.com] > Sent: den 8 februari 2007 15:44 > To: tls@ietf.org > Subject: Re: [TLS] extension number conflict > > >> IANA makes assignments when the documents are approved. It should > >> have "TBD" in the document until that happens. > > > > Personally, I think that is somewhat late. > > I agree. I had to disable the code that implements this feature > since there is no way to access it. This makes it difficult to > test, especially between differing implementations. > > For a feature that will obviously be approved, shouldn't there > be a way to assign it a number sooner than RFC publication? > > Mike > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 08 19:44:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJrn-0008R6-1N; Thu, 08 Feb 2007 19:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJrm-0008QO-25 for tls@ietf.org; Thu, 08 Feb 2007 19:43:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJrk-0005YT-Iw for tls@ietf.org; Thu, 08 Feb 2007 19:43:54 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l190hdrI087672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Feb 2007 17:43:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200702082259.XAA10273@uw1048.wdf.sap.corp> <45CBB5B5.9020305@pobox.com> Date: Thu, 8 Feb 2007 16:43:29 -0800 To: Stefan Santesson , Mike , "tls@ietf.org" From: Paul Hoffman Subject: RE: [TLS] extension number conflict Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: tls-bounces@lists.ietf.org At 12:01 AM +0000 2/9/07, Stefan Santesson wrote: >What about assigning an experimental/local range that can be used >until the real number is assigned. >That should avoid conflicts effectively. If you want to make a change to how the numbers are assigned, you should write an Internet Draft to change the procedure and bring it to the TLS WG. "What about this" and "how about that" are fairly meaningless when there is already rules that people agreed to on how to do this. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Feb 09 05:51:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTKI-0006yd-LC; Fri, 09 Feb 2007 05:49:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTKG-0006yT-IN for tls@ietf.org; Fri, 09 Feb 2007 05:49:56 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFTKE-0000CX-3e for tls@ietf.org; Fri, 09 Feb 2007 05:49:56 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l19AkFwr002053; Fri, 9 Feb 2007 12:46:37 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 12:49:21 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 12:49:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] extension number conflict Date: Fri, 9 Feb 2007 12:49:20 +0200 Message-ID: In-Reply-To: <45CBB5B5.9020305@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] extension number conflict Thread-Index: AcdL2uSDJ/kp8mZIQDSa9g+mKhkR8wAW9Axw References: <200702082259.XAA10273@uw1048.wdf.sap.corp> <45CBB5B5.9020305@pobox.com> From: To: , X-OriginalArrivalTime: 09 Feb 2007 10:49:21.0081 (UTC) FILETIME=[F4696A90:01C74C37] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070209124637-07E03BB0-2F1FB4EE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: tls-bounces@lists.ietf.org mike-list@pobox.com wrote: >=20 > I agree. I had to disable the code that implements this feature > since there is no way to access it. This makes it difficult to > test, especially between differing implementations. >=20 > For a feature that will obviously be approved, shouldn't there > be a way to assign it a number sooner than RFC publication? I think it is *not* obvious that this feature will be exactly=20 the same (that is, interoperable with the -02 draft) in the final=20 TLS 1.2 RFC. For example, in addition to the hash algorithm, we might want to signal support for different signature algorithms=20 (e.g. there are at least three standardized ways of doing RSA=20 signatures, but the current specs sort of assume that everyone uses only PKCS#1 1.5, ignoring the PSS and ANSI variants). (But perhaps allocating one extension number for "private use" might make sense... ) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Feb 09 10:53:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFY2C-00060a-N2; Fri, 09 Feb 2007 10:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFY2B-0005xp-3D for tls@ietf.org; Fri, 09 Feb 2007 10:51:35 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFY28-0005s3-Q0 for tls@ietf.org; Fri, 09 Feb 2007 10:51:35 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 662E4B61FE for ; Fri, 9 Feb 2007 10:51:54 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 349A5B61E5 for ; Fri, 9 Feb 2007 10:51:54 -0500 (EST) Message-ID: <45CC98CF.7050405@pobox.com> Date: Fri, 09 Feb 2007 07:52:47 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] extension number conflict References: <200702082259.XAA10273@uw1048.wdf.sap.corp> <45CBB5B5.9020305@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: tls-bounces@lists.ietf.org >> For a feature that will obviously be approved, shouldn't there >> be a way to assign it a number sooner than RFC publication? > > I think it is *not* obvious that this feature will be exactly > the same (that is, interoperable with the -02 draft) in the final > TLS 1.2 RFC. Ok, that's a fair argument. > (But perhaps allocating one extension number for "private use" > might make sense... ) Wouldn't that open up a can of worms? The IANA lists extension numbers 12 thru 34 as unassigned -- maybe we are supposed to use one of those during development of the standard until the RFC is published? And once it is, the only code change is redefining a constant. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Feb 09 13:06:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFa6O-0005JH-4w; Fri, 09 Feb 2007 13:04:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFa6L-0005BJ-HC for tls@ietf.org; Fri, 09 Feb 2007 13:04:02 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFa6K-0005fO-8I for tls@ietf.org; Fri, 09 Feb 2007 13:04:01 -0500 Received: from pc6 (1Cust222.tnt24.lnd4.gbr.da.uu.net [62.188.151.222]) by ranger.systems.pipex.net (Postfix) with SMTP id 9BA42E0000D4; Fri, 9 Feb 2007 18:03:32 +0000 (GMT) Message-ID: <05a001c74c6c$06158100$0601a8c0@pc6> From: "tom.petch" To: "Stefan Santesson" , "Mike" , References: <200702082259.XAA10273@uw1048.wdf.sap.corp><45CBB5B5.9020305@pobox.com> Subject: Re: [TLS] extension number conflict Date: Fri, 9 Feb 2007 16:39:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" 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: , Errors-To: tls-bounces@lists.ietf.org You (plural) might want to look at BCP 100. Tom Petch ----- Original Message ----- From: "Stefan Santesson" To: "Mike" ; Sent: Friday, February 09, 2007 1:01 AM Subject: RE: [TLS] extension number conflict What about assigning an experimental/local range that can be used until the real number is assigned. That should avoid conflicts effectively. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Mike [mailto:mike-list@pobox.com] > Sent: den 8 februari 2007 15:44 > To: tls@ietf.org > Subject: Re: [TLS] extension number conflict > > >> IANA makes assignments when the documents are approved. It should > >> have "TBD" in the document until that happens. > > > > Personally, I think that is somewhat late. > > I agree. I had to disable the code that implements this feature > since there is no way to access it. This makes it difficult to > test, especially between differing implementations. > > For a feature that will obviously be approved, shouldn't there > be a way to assign it a number sooner than RFC publication? > > Mike > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Feb 09 13:35:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFaZn-0006v5-FO; Fri, 09 Feb 2007 13:34:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFaZm-0006tU-Az for tls@ietf.org; Fri, 09 Feb 2007 13:34:26 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFaZi-00012u-UA for tls@ietf.org; Fri, 09 Feb 2007 13:34:26 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 9 Feb 2007 18:34:11 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 9 Feb 2007 18:34:11 +0000 From: Stefan Santesson To: Paul Hoffman , Mike , "tls@ietf.org" Date: Fri, 9 Feb 2007 18:30:03 +0000 Subject: RE: [TLS] extension number conflict Thread-Topic: [TLS] extension number conflict Thread-Index: AcdL42IUPyIvVf5aTeqZul3lKAzvHwAlO6A1 Message-ID: References: <200702082259.XAA10273@uw1048.wdf.sap.corp> <45CBB5B5.9020305@pobox.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: tls-bounces@lists.ietf.org I'm not sure how to take this. Is it considered inappropriate to talk openly about possibilities. I can whitness that as implementer this can be a problem. I don't consider = it severe enought to go through the trouble of writing an I-D about it, but= it's good the hear others experiances. /Stefan ________________________________________ From: Paul Hoffman [paul.hoffman@vpnc.org] Sent: Thursday, February 08, 2007 4:43 PM To: Stefan Santesson; Mike; tls@ietf.org Subject: RE: [TLS] extension number conflict At 12:01 AM +0000 2/9/07, Stefan Santesson wrote: >What about assigning an experimental/local range that can be used >until the real number is assigned. >That should avoid conflicts effectively. If you want to make a change to how the numbers are assigned, you should write an Internet Draft to change the procedure and bring it to the TLS WG. "What about this" and "how about that" are fairly meaningless when there is already rules that people agreed to on how to do this. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Feb 09 17:35:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeJN-00029i-Di; Fri, 09 Feb 2007 17:33:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeJM-00029d-BM for tls@ietf.org; Fri, 09 Feb 2007 17:33:44 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFeJL-00056e-1b for tls@ietf.org; Fri, 09 Feb 2007 17:33:44 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id C1D075C01E; Fri, 9 Feb 2007 14:41:43 -0800 (PST) To: Nelson B Bolyard Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY? In-reply-to: Your message of "Sun, 31 Dec 2006 15:13:24 PST." <45984414.2090209@bolyard.com> X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Fri, 09 Feb 2007 14:33:42 -0800 From: Eric Rescorla Message-Id: <20070209224143.C1D075C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: tls-bounces@lists.ietf.org Nelson B Bolyard wrote: > Last August, I wrote to this list about the lack of "MUST" in the RFCs and > drafts concerning the use of error and warning alerts. That message is > quoted below. I only got one reply, from Peter Gutmann. > > I really want to see this situation get fixed in TLS 1.2. What can I do > to make that happen? Do I need to submit a draft with the suggested changes? > Erik, if I send you a set of suggested changes as edits to the current 1.2 > draft, will you incorporate them? My concern, as I think I mentioned to you privately, is that we not mandate behaviors that potentially leak security relevant information. We've had one such situation before with CBC padding. Ultimately, we really need a review of the security implications of every kind of error, but not having that I'm reluctant to require behaviors that haven't been vetted. The bottom line, then, is that I'd prefer not to change this language without explicit security analysis for each change. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 13 17:09:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5ni-00048R-13; Tue, 13 Feb 2007 17:07:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5ng-000476-Eb for tls@lists.ietf.org; Tue, 13 Feb 2007 17:07:00 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5nb-0003sV-HT for tls@lists.ietf.org; Tue, 13 Feb 2007 17:07:00 -0500 Received: by ug-out-1314.google.com with SMTP id k3so1076561ugf for ; Tue, 13 Feb 2007 14:06:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XgQSqKH3YY91IW/uN3Vu/ZjhMIDQLLgdHa5gD3g4q1ULfW+aFQh/RsQen7HewYHmy8jLetcqat8EZoaa5nqehU0HG+FYcvsvIChzKN3YDGOEDAnOQJ3ggP4zENvMHgqQs2QiN6NaUcqA27I/tK0JunGREymcZ3BgQYwhbTfPg+A= Received: by 10.82.111.8 with SMTP id j8mr13986135buc.1171404413603; Tue, 13 Feb 2007 14:06:53 -0800 (PST) Received: by 10.82.107.9 with HTTP; Tue, 13 Feb 2007 14:06:53 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 14:06:53 -0800 From: "Facundo Barrera - GMail" To: tls@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [TLS] OE + TLS support 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: , Errors-To: tls-bounces@lists.ietf.org Hi list: Does Outlook Express support TLS? cause i can't get it to work, by now Mozilla Thunderbird works just fine with my TLS SMTP. Any ideas? Thanks in advance -- _________________________ Facundo Agustin Barrera -------------------------------------- www.openlabs.com.ar "Let the penguins do the work" --------------------------------------------- Buenos Aires - Argentina _________________________ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 13 17:36:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6F6-0001yS-HL; Tue, 13 Feb 2007 17:35:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6F5-0001yJ-6D for tls@lists.ietf.org; Tue, 13 Feb 2007 17:35:19 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH6F3-0007kB-WB for tls@lists.ietf.org; Tue, 13 Feb 2007 17:35:19 -0500 Received: from sceptre.pobox.com (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 4A71725A for ; Tue, 13 Feb 2007 17:35:39 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 08CDA28860 for ; Tue, 13 Feb 2007 17:35:37 -0500 (EST) Message-ID: <45D23C81.6040607@pobox.com> Date: Tue, 13 Feb 2007 14:32:33 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] OE + TLS support References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: tls-bounces@lists.ietf.org > Does Outlook Express support TLS? cause i can't get it to > work.... I just tried it and it works (version 6). Tools -> Accounts -> Mail -> Properties -> Advanced Select "This server requires a secure connection (SSL)" It used TLS 1.0 with RC4-MD5 when I sent a test message. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Feb 14 07:01:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHInV-0000Oy-AQ; Wed, 14 Feb 2007 06:59:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHInU-0000ON-7j for tls@lists.ietf.org; Wed, 14 Feb 2007 06:59:40 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHInS-0001oh-UP for tls@lists.ietf.org; Wed, 14 Feb 2007 06:59:40 -0500 Received: from pc6 (1Cust1.tnt24.lnd4.gbr.da.uu.net [62.188.151.1]) by ranger.systems.pipex.net (Postfix) with SMTP id BBE2CE0002F2; Wed, 14 Feb 2007 11:59:34 +0000 (GMT) Message-ID: <00c501c75026$fd9aabe0$0601a8c0@pc6> From: "tom.petch" To: "Mike" , References: <45D23C81.6040607@pobox.com> Subject: Re: [TLS] OE + TLS support Date: Wed, 14 Feb 2007 10:10:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" 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: , Errors-To: tls-bounces@lists.ietf.org ----- Original Message ----- From: "Mike" To: Sent: Tuesday, February 13, 2007 11:32 PM Subject: Re: [TLS] OE + TLS support > > Does Outlook Express support TLS? cause i can't get it to > > work.... > > I just tried it and it works (version 6). > > Tools -> Accounts -> Mail -> Properties -> Advanced > > Select "This server requires a secure connection (SSL)" > > It used TLS 1.0 with RC4-MD5 when I sent a test message. > I note that for Internet Explorer there is an option to specify which of SSL2.0 SSL3.0 TLS1.0 is acceptable Tools -> Internet Options -> Advanced One government body I know has this set to the default (for their OS) of SSL2 Yes SSL3 Yes TLS1 No and can I get them to change it????? Tom Petch > Mike > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Feb 14 10:17:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLqz-0008AE-Lm; Wed, 14 Feb 2007 10:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLqy-0008A9-V1 for tls@lists.ietf.org; Wed, 14 Feb 2007 10:15:28 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHLqv-00017F-NX for tls@lists.ietf.org; Wed, 14 Feb 2007 10:15:28 -0500 Received: from sceptre.pobox.com (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id A59C12FA for ; Wed, 14 Feb 2007 10:15:42 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 6EB2028DB2 for ; Wed, 14 Feb 2007 10:15:42 -0500 (EST) Message-ID: <45D326E3.4020500@pobox.com> Date: Wed, 14 Feb 2007 07:12:35 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] OE + TLS support References: <45D23C81.6040607@pobox.com> <00c501c75026$fd9aabe0$0601a8c0@pc6> In-Reply-To: <00c501c75026$fd9aabe0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Errors-To: tls-bounces@lists.ietf.org > One government body I know has this set to the default (for their OS) of > SSL2 Yes > SSL3 Yes > TLS1 No > and can I get them to change it????? Well if you try to connect to www.americanexpress.com using TLS 1.0, it chokes, but SSLv3 works. If they can be stuck in the past, there are probably lots of others. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Feb 14 11:49:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNIJ-0007pv-GX; Wed, 14 Feb 2007 11:47:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNII-0007pq-DU for tls@lists.ietf.org; Wed, 14 Feb 2007 11:47:46 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHNIG-0005SS-WB for tls@lists.ietf.org; Wed, 14 Feb 2007 11:47:46 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id RAA19766; Wed, 14 Feb 2007 17:47:27 +0100 (MEZ) From: Martin Rex Message-Id: <200702141644.RAA26139@uw1048.wdf.sap.corp> Subject: Re: [TLS] OE + TLS support To: mike-list@pobox.com (Mike) Date: Wed, 14 Feb 2007 17:44:10 +0100 (MET) In-Reply-To: <45D326E3.4020500@pobox.com> from "Mike" at Feb 14, 7 07:12:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Mike wrote: > > > One government body I know has this set to the default (for their OS) of > > SSL2 Yes > > SSL3 Yes > > TLS1 No > > and can I get them to change it????? > > Well if you try to connect to www.americanexpress.com using TLS 1.0, > it chokes, but SSLv3 works. If they can be stuck in the past, there > are probably lots of others. On what in particular do they choke? Choking if you send them a correct SSL Hello (3.0 record protocol version, 3.1 client version) would be a problem, aborting if you do not agree to a server-asserted/chosen SSL v3.0 protocol should be OK. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Feb 14 13:26:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOod-0002L9-En; Wed, 14 Feb 2007 13:25:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOoc-0002IN-5r for tls@lists.ietf.org; Wed, 14 Feb 2007 13:25:14 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOoN-0002By-Ph for tls@lists.ietf.org; Wed, 14 Feb 2007 13:25:14 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1EIL5RW028346 for ; Wed, 14 Feb 2007 20:21:33 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 20:24:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 20:24:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] OE + TLS support Date: Wed, 14 Feb 2007 20:24:22 +0200 Message-ID: In-Reply-To: <200702141644.RAA26139@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] OE + TLS support Thread-Index: AcdQWAcXOxVhoI8yQtyvzW9wUlqzuQADMvaQ References: <45D326E3.4020500@pobox.com> from "Mike" at Feb 14, 7 07:12:35 am <200702141644.RAA26139@uw1048.wdf.sap.corp> From: To: X-OriginalArrivalTime: 14 Feb 2007 18:24:51.0770 (UTC) FILETIME=[6AD659A0:01C75065] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070214202133-6DD24BB0-52B49D3C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > On what in particular do they choke? Choking if you send them a > correct SSL Hello (3.0 record protocol version, 3.1 client version) > would be a problem, aborting if you do not agree to a > server-asserted/chosen SSL v3.0 protocol should be OK. For me, www.americanexpress.com:443 seems to work using TLS 1.0 (negotiates TLS 1.0, and seems to ignore the record protocol version). However, if I propose TLS 1.1, the server just closes the connection immediately. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Feb 14 17:26:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSYV-00052H-Ie; Wed, 14 Feb 2007 17:24:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSYT-000526-Rg for tls@lists.ietf.org; Wed, 14 Feb 2007 17:24:49 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSYS-0005Tr-Kn for tls@lists.ietf.org; Wed, 14 Feb 2007 17:24:49 -0500 Received: from sceptre.pobox.com (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id F3D6E2EF for ; Wed, 14 Feb 2007 17:25:09 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id C459627F6C for ; Wed, 14 Feb 2007 17:25:09 -0500 (EST) Message-ID: <45D38B86.8010101@pobox.com> Date: Wed, 14 Feb 2007 14:21:58 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] OE + TLS support References: <45D326E3.4020500@pobox.com> from "Mike" at Feb 14, 7 07:12:35 am <200702141644.RAA26139@uw1048.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Errors-To: tls-bounces@lists.ietf.org >> On what in particular do they choke? > > For me, www.americanexpress.com:443 seems to work using TLS 1.0 > (negotiates TLS 1.0, and seems to ignore the record protocol version). > However, if I propose TLS 1.1, the server just closes the connection > immediately. If you try TLS 1.0 with extensions, it closes the connection also, so I consider that broken. If you omit extensions, it works. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Feb 16 13:09:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI7UE-0005yc-LN; Fri, 16 Feb 2007 13:07:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI7UD-0005wz-6q for tls@ietf.org; Fri, 16 Feb 2007 13:07:09 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI7UC-0006MJ-0e for tls@ietf.org; Fri, 16 Feb 2007 13:07:09 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 3050AB9C31 for ; Fri, 16 Feb 2007 13:07:29 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id EFFB5B9C30 for ; Fri, 16 Feb 2007 13:07:28 -0500 (EST) Message-ID: <45D5F218.8010409@pobox.com> Date: Fri, 16 Feb 2007 10:04:08 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [TLS] Security of CertificateStatus? 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: , Errors-To: tls-bounces@lists.ietf.org I am concerned about the CertificateStatus extension. It only allows for one OCSP response which is the validity of the server's certificate. The problem I see is that most certificate chains have intermediate CA's and their status should also be checked by the client. I'm not too familiar with OCSP yet, so am I missing something? Does the OCSP response contain the validity of an entire certificate chain? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 17 12:58:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITna-0000cH-9x; Sat, 17 Feb 2007 12:56:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITnY-0000cC-TW for tls@lists.ietf.org; Sat, 17 Feb 2007 12:56:36 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HITnW-0000d6-NR for tls@lists.ietf.org; Sat, 17 Feb 2007 12:56:36 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 24ECDBA4B8 for ; Sat, 17 Feb 2007 12:56:54 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id E4BE3BA4B7 for ; Sat, 17 Feb 2007 12:56:53 -0500 (EST) Message-ID: <45D74243.1060004@pobox.com> Date: Sat, 17 Feb 2007 09:58:27 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Security of CertificateStatus? References: <45D5F218.8010409@pobox.com> <200702171807.34284.bradh@frogmouth.net> In-Reply-To: <200702171807.34284.bradh@frogmouth.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: , Errors-To: tls-bounces@lists.ietf.org > You either need to validate the chain (plus CRL), or you need OCSP, not both. > Either allows you to tell if the certificate presented by the server is > valid. If the certificate is valid, you can "trust" the server. When I validate a typical certificate chain, my code ends up retrieving up to 4 CRLs since the CRLs of intermediate CAs need to be checked too. Does the single OCSP response also validate these intermediate CA certificates? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 22 04:30:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKAFt-0007RI-C1; Thu, 22 Feb 2007 04:28:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKAFr-0007Dx-DX for tls@ietf.org; Thu, 22 Feb 2007 04:28:47 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKAFn-0002W4-Sb for tls@ietf.org; Thu, 22 Feb 2007 04:28:47 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1M9SFZM031716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Feb 2007 10:28:16 +0100 X-Hashcash: 1:22:070222:tls@ietf.org::apUzcJzSaSMQwEpF:GcVX From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Thu, 22 Feb 2007 10:28:17 +0100 Message-ID: <87tzxeilse.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [TLS] Authorization extension test server available 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: , Errors-To: tls-bounces@lists.ietf.org Hi all! GnuTLS now supports the TLS authorization extension, and I'm wondering if anyone is interested in interop testing of this feature? Our public test server supports RFC 4680 and draft-housley-tls-authz-extns-07 in case someone wants to point their clients towards a server: http://www.gnu.org/software/gnutls/server.html It may be too late to change the specifications, but my comments after implementing this were: - The size of authorization data, i.e., X.509 attribute certs and SAML assertions, are limited to 64kb. Is it certain that we won't need more? - There is no discussion on authorization failures. Should the handshake be aborted? This is complicated by the fact that the authorization data is sent _before_ authentication data. Typically you wait until authentication is complete before processing authorization data. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 22 11:10:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKGVH-000286-Mh; Thu, 22 Feb 2007 11:09:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKGVG-00026Q-MB for tls@ietf.org; Thu, 22 Feb 2007 11:09:06 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKGVE-000148-DB for tls@ietf.org; Thu, 22 Feb 2007 11:09:06 -0500 Received: (qmail 14809 invoked by uid 0); 22 Feb 2007 16:02:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 22 Feb 2007 16:02:15 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Feb 2007 11:02:09 -0500 To: Simon Josefsson ,tls@ietf.org From: Russ Housley Subject: Re: [TLS] Authorization extension test server available In-Reply-To: <87tzxeilse.fsf@latte.josefsson.org> References: <87tzxeilse.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: tls-bounces@lists.ietf.org Message-Id: Simon: >Hi all! GnuTLS now supports the TLS authorization extension, and I'm >wondering if anyone is interested in interop testing of this feature? > >Our public test server supports RFC 4680 and >draft-housley-tls-authz-extns-07 in case someone wants to point their >clients towards a server: > >http://www.gnu.org/software/gnutls/server.html Very cool. >It may be too late to change the specifications, but my comments after >implementing this were: > >- The size of authorization data, i.e., X.509 attribute certs and SAML > assertions, are limited to 64kb. Is it certain that we won't need > more? I have little experience with SAML, but 64K is a lot of space for attribute certificates. >- There is no discussion on authorization failures. Should the > handshake be aborted? This is complicated by the fact that the > authorization data is sent _before_ authentication data. Typically > you wait until authentication is complete before processing > authorization data. We discussed this while developing the specification. The current document is the cleanest way to use the extension mechanism that we could devise. And, no one offered a better alternative during the review process. Of course, implementation and deployment experience may show us a better way. If the authorization requirements are not satisfied, then the TLS session should be shutdown. I would expect the access_denied fatal alert to be used. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 22 11:53:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHBl-0003vs-9e; Thu, 22 Feb 2007 11:53:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHBj-0003vn-QT for tls@ietf.org; Thu, 22 Feb 2007 11:52:59 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKHBg-0007aZ-DM for tls@ietf.org; Thu, 22 Feb 2007 11:52:59 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 22 Feb 2007 08:52:55 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Thu, 22 Feb 2007 08:52:55 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Thu, 22 Feb 2007 08:52:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Authorization extension test server available Date: Thu, 22 Feb 2007 08:50:27 -0800 Message-ID: <802A881C87166D4597F9EEFC3F04F4F8041401AF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Authorization extension test server available Thread-Index: AcdWnCL/nElka6/rTlK7fD4ze4JcegABOSeQ References: <87tzxeilse.fsf@latte.josefsson.org> From: Ari Medvinsky To: Russ Housley , Simon Josefsson , X-OriginalArrivalTime: 22 Feb 2007 16:52:55.0285 (UTC) FILETIME=[E60F8A50:01C756A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: tls-bounces@lists.ietf.org It is a good idea to increase the size for SAML to be more then 64k - note that just the XML Dig Sig on a SAML assertion is around 16K; then within the SAML assertion you can have any number of attribute statements, etc. Ari Medvinsky Sr. Program Manager Windows Security -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Thursday, February 22, 2007 8:02 AM To: Simon Josefsson; tls@ietf.org Subject: Re: [TLS] Authorization extension test server available Simon: >Hi all! GnuTLS now supports the TLS authorization extension, and I'm >wondering if anyone is interested in interop testing of this feature? > >Our public test server supports RFC 4680 and >draft-housley-tls-authz-extns-07 in case someone wants to point their >clients towards a server: > >http://www.gnu.org/software/gnutls/server.html Very cool. >It may be too late to change the specifications, but my comments after >implementing this were: > >- The size of authorization data, i.e., X.509 attribute certs and SAML > assertions, are limited to 64kb. Is it certain that we won't need > more? I have little experience with SAML, but 64K is a lot of space for=20 attribute certificates. >- There is no discussion on authorization failures. Should the > handshake be aborted? This is complicated by the fact that the > authorization data is sent _before_ authentication data. Typically > you wait until authentication is complete before processing > authorization data. We discussed this while developing the specification. The current=20 document is the cleanest way to use the extension mechanism that we=20 could devise. And, no one offered a better alternative during the=20 review process. Of course, implementation and deployment experience=20 may show us a better way. If the authorization requirements are not satisfied, then the TLS=20 session should be shutdown. I would expect the access_denied fatal=20 alert to be used. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Feb 23 14:39:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKgE1-0001Le-Ij; Fri, 23 Feb 2007 14:37:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKgDz-0001L7-TN for tls@ietf.org; Fri, 23 Feb 2007 14:36:59 -0500 Received: from [194.29.32.68] (helo=michael.checkpoint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKgDx-0002Eb-Oi for tls@ietf.org; Fri, 23 Feb 2007 14:36:59 -0500 Received: from [172.31.21.20] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l1NJak5E016818 for ; Fri, 23 Feb 2007 21:36:47 +0200 (IST) Mime-Version: 1.0 (Apple Message framework v752.3) To: tls@ietf.org Message-Id: <1DFABFCE-CB27-41D0-BAA6-47BB804B387F@checkpoint.com> References: From: Yoav Nir Date: Fri, 23 Feb 2007 21:36:38 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Cc: Subject: [TLS] Fwd: I-D ACTION:draft-nir-tee-pm-00.txt 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="===============1295445853==" Errors-To: tls-bounces@lists.ietf.org --===============1295445853== Content-Type: multipart/alternative; boundary=Apple-Mail-1-678669945 --Apple-Mail-1-678669945 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello all. The documents referenced below is an attempt to leverage EAP infrastructure to provide authentication for TLS clients other than with certificates. Yaron Sheffer will make a presentation about this in Prague. Your feedback will be greatly appreciated. Thanks Yoav Nir Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: February 23, 2007 5:50:02 PM IST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-nir-tee-pm-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Protocol Model for TLS with EAP Authentication > Author(s) : Y. Nir, et al. > Filename : draft-nir-tee-pm-00.txt > Pages : > Date : 2007-2-23 > > This document describes an extension to the TLS protocol to > allow TLS > clients to authenticate with legacy credentials using the > Extensible > Authentication Protocol (EAP). > > This work follows the example of IKEv2, where EAP has been added to > the IKEv2 protocol to allow clients to use different credentials > such > as passwords, token cards, and shared secrets. > > When TLS is used with EAP, additional records are sent after the > ChangeCipherSpec protocol message, effectively creating an extended > handshake before the application layer data can be sent. Each > EapMsg > handshake record contains exactly one EAP message. Using EAP for > client authentication allows TLS to be used with various AAA > back-end > servers such as RADIUS or Diameter. > > TLS with EAP may be used for securing a data connection such as > HTTP > or POP3, where the ability of EAP to work with backend servers can > remove that burden from the application layer. > > This document is a protocol model, rather than a full protocol > specification. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-tee-pm-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-nir-tee-pm-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-nir-tee-pm-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-2-23094921.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-1-678669945 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello all.

The documents referenced = below is an attempt to leverage EAP infrastructure to provide = authentication for TLS clients other than with = certificates.

Yaron Sheffer will make a = presentation about this in Prague.

Your feedback will be = greatly appreciated.

Thanks

Yoav = Nir

Begin forwarded message:

Date: February 23, 2007 5:50:02 PM = IST
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-nir-tee-pm-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : Protocol Model for TLS with EAP = Authentication
Author(s) : Y. Nir, = et al.
Filename : = draft-nir-tee-pm-00.txt
= Pages = = :=A0
Date : 2007-2-23


=A0=A0 This document describes an = extension to the TLS protocol to allow TLS
=A0=A0 clients to authenticate = with legacy credentials using the Extensible
=A0=A0 = Authentication Protocol (EAP).

=A0=A0 This work follows the = example of IKEv2, where EAP has been added to
=A0=A0 = the IKEv2 protocol to allow clients to use different credentials = such
=A0=A0 as passwords, token cards, = and shared secrets.
=A0=A0 When TLS is used with EAP, = additional records are sent after the
=A0=A0 ChangeCipherSpec protocol = message, effectively creating an extended
=A0=A0 handshake before the = application layer data can be sent.=A0= Each EapMsg
=A0=A0 handshake record contains = exactly one EAP message.=A0 = Using EAP for
=A0=A0 client authentication = allows TLS to be used with various AAA back-end
=A0=A0 = servers such as RADIUS or Diameter.

=A0=A0 TLS with EAP may be used = for securing a data connection such as HTTP
=A0=A0 or POP3, where the ability = of EAP to work with backend servers can
=A0=A0 remove that burden from = the application layer.
=A0=A0 This document is a = protocol model, rather than a full protocol
=A0=A0 specification.


A URL for = this Internet-Draft is:

To = remove yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-nir-tee-pm-00.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-nir-tee-pm-00.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: text/plain

=

= --Apple-Mail-1-678669945-- --===============1295445853== 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 --===============1295445853==-- From tls-bounces@lists.ietf.org Mon Feb 26 12:06:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjFk-0008Nn-Cc; Mon, 26 Feb 2007 12:03:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjFj-0008Nf-2L for tls@ietf.org; Mon, 26 Feb 2007 12:03:07 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjFg-0005C6-Pl for tls@ietf.org; Mon, 26 Feb 2007 12:03:07 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 684F35C082 for ; Mon, 26 Feb 2007 09:14:09 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 26 Feb 2007 09:03:03 -0800 From: Eric Rescorla Message-Id: <20070226171409.684F35C082@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Agenda Time in Prague 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: , Errors-To: tls-bounces@lists.ietf.org If you want agenda time at TLS-WG in Prague, please forward a request to Pasi Eronen and myself by Mon Mar 5. If you've already asked for and received time there is no need to send another request. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 27 10:54:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4dC-00033P-UR; Tue, 27 Feb 2007 10:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4dB-0002zC-9l for tls@ietf.org; Tue, 27 Feb 2007 10:52:45 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4d9-0005vr-UP for tls@ietf.org; Tue, 27 Feb 2007 10:52:45 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 225831CC24 for ; Tue, 27 Feb 2007 07:50:10 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Tue, 27 Feb 2007 07:50:10 -0800 From: EKR Message-Id: <20070227155010.225831CC24@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [TLS] New IETF LC: draft-housley-tls-authz 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: , Errors-To: tls-bounces@lists.ietf.org The TLS WG should be aware of the following events regarding draft-ietf-tls-authz. Because this is a TLS-related document but not a WG item, there will be no call for input on the TLS mailing list. I encourage WG members to send in their comments on the IETF mailing list. -Ekr -------------------------------------------------------------------- On June 27, 2006, the IESG approved "Transport Layer Security (TLS) Authorization Extensions," (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. The disclosure can be found at https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=767 . The disclosure may cover technology in draft-housley-tls-authz-extns and other drafts. The claimed IPR relates to a US patent application filed September 23, 2005. The claims of this application are now public so IETF participants may examine the claims. According to section 3.2.1 of RFC 3979, "The Contributor represents that he or she has made or will promptly make all disclosures required by Section 6.1.1 of this document." Section 6.1.1 requires: Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. The IESG has been informed by Mark Brown that he had knowledge of the September 2005 patent application filed by his employer at the time he submitted draft-housley-tls-authz-extns. Accordingly, he was obligated to disclose the existence of this patent application upon making this submission. Making a required IPR disclosure after a draft is approved does not meet the requirement to promptly make the disclosure. According to section 7 of RFC 3979 failure to make a required disclosure is a failure of process. It should be noted that the above disclosure obligations apply to unpublished patent applications. When a patent application that is required to be disclosed is unpublished, the discloser must 'indicate that the claim is based on unpublished patent applications', but is not required to list the application number (see RFC 3978 Section 6.4.1). the IESG withdraws its approval of draft-housley-tls-authz-extns. The RFC editor is hereby requested to remove this draft from their publication queue. IANA is hereby requested to remove the assignments for this draft and mark the codepoints as reserved. Should this draft be approved in the future, IANA is requested to re-assign the same codepoints. The IESG is considering re-approving this draft with knowledge of the IPR disclosure from Redphone Security. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Comments can be sent to ietf@ietf.org or exceptionally to iesg@ietf.org. Comments should be sent by 2007-03-13. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ----------------------------------------------------------------------- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 27 11:15:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4yr-0003sJ-Nh; Tue, 27 Feb 2007 11:15:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4yr-0003s3-3X for tls@ietf.org; Tue, 27 Feb 2007 11:15:09 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4yp-0000jw-SQ for tls@ietf.org; Tue, 27 Feb 2007 11:15:09 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 303FA1CC29; Tue, 27 Feb 2007 08:12:34 -0800 (PST) To: tls@ietf.org Subject: Re: [TLS] New IETF LC: draft-housley-tls-authz References: <20070227155010.225831CC24@delta.rtfm.com> From: EKR Date: Tue, 27 Feb 2007 08:12:34 -0800 In-Reply-To: <20070227155010.225831CC24@delta.rtfm.com> (ekr@networkresonance.com's message of "Tue, 27 Feb 2007 07:50:10 -0800") Message-ID: <86r6sbwpe5.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org EKR writes: > > > The TLS WG should be aware of the following events regarding > draft-ietf-tls-authz. Because this is a TLS-related document Doh. draft-housley-tls-authz. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 27 11:19:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM522-0004W1-Tn; Tue, 27 Feb 2007 11:18:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM521-0004Vh-Vd for tls@ietf.org; Tue, 27 Feb 2007 11:18:25 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM520-0001DI-K0 for tls@ietf.org; Tue, 27 Feb 2007 11:18:25 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1068512ugd for ; Tue, 27 Feb 2007 08:18:23 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gsCKcSriUHgQ3VTZ8oZFIjJlxmSVWoyXg3bJG+MxlYhVyGSLqu72GPm2nBGH43KP1V1nLdZu/OOPs1U1sQepptikjDEUcgkiv+YZLrxKDPlNFvx/kNmXxG4TgD06qpaltDNYL/XnEC5NZiEtQ1hsQOqxlD1KV85FglFRl0TqzYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XYiiK/8zt6AQIG3fVFy8O9G7cxoVW4mxvDhNR2oj0RkFI6XJCUjJ+w5MYZz/KwhG1t0Qmi3BOCptAvIahcPbq+iufWgDX3AUH3MCZzkBSprT26JZXtxQfRJ4c8pKo9OdPhGn8rnT8vKynk/fQTvJu0iEjZYO86CPCyuwtYJ+bqE= Received: by 10.78.136.9 with SMTP id j9mr593366hud.1172593103083; Tue, 27 Feb 2007 08:18:23 -0800 (PST) Received: by 10.78.37.12 with HTTP; Tue, 27 Feb 2007 08:18:23 -0800 (PST) Message-ID: Date: Tue, 27 Feb 2007 17:18:23 +0100 From: Badra To: EKR Subject: Re: [TLS] New IETF LC: draft-housley-tls-authz In-Reply-To: <86r6sbwpe5.fsf@delta.rtfm.com> MIME-Version: 1.0 References: <20070227155010.225831CC24@delta.rtfm.com> <86r6sbwpe5.fsf@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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="===============0465931889==" Errors-To: tls-bounces@lists.ietf.org --===============0465931889== Content-Type: multipart/alternative; boundary="----=_Part_7348_2413319.1172593103072" ------=_Part_7348_2413319.1172593103072 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Eric, I don't know how exactly it works, but in the case of not a WG document, does the IESG have to ask the WG chair's opinion? and if yes, is the chair opinion determinative? Best regards, Badra On 2/27/07, EKR wrote: > EKR writes: > > > > > > > The TLS WG should be aware of the following events regarding > > draft-ietf-tls-authz. Because this is a TLS-related document > > Doh. draft-housley-tls-authz. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > -- Badra ------=_Part_7348_2413319.1172593103072 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Eric,

I don't know how exactly it works, but in the case of not a WG document, does the IESG have to ask the WG chair's opinion? and if yes, is the chair opinion determinative?

Best regards,
Badra
 
On 2/27/07, EKR <ekr@networkresonance.com> wrote:
EKR <ekr@networkresonance.com> writes:

> <chair hat on>
>
> The TLS WG should be aware of the following events regarding
> draft-ietf-tls-authz. Because this is a TLS-related document

Doh. draft-housley-tls-authz.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls



--
Badra ------=_Part_7348_2413319.1172593103072-- --===============0465931889== 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 --===============0465931889==-- From tls-bounces@lists.ietf.org Tue Feb 27 13:01:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6cV-0003ie-9M; Tue, 27 Feb 2007 13:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6cT-0003aN-HQ for tls@ietf.org; Tue, 27 Feb 2007 13:00:09 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6cS-0006M6-6C for tls@ietf.org; Tue, 27 Feb 2007 13:00:09 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1RI00T6099841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 11:00:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070227155010.225831CC24@delta.rtfm.com> <86r6sbwpe5.fsf@delta.rtfm.com> Date: Tue, 27 Feb 2007 09:59:57 -0800 To: Badra , EKR From: Paul Hoffman Subject: Re: [TLS] New IETF LC: draft-housley-tls-authz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: tls-bounces@lists.ietf.org At 5:18 PM +0100 2/27/07, Badra wrote: >Hi Eric, > >I don't know how exactly it works, but in the case of not a WG >document, does the IESG have to ask the WG chair's opinion? With my coauthor-of-Tao-of-the-IETF hat on: no. The IESG is asking for opinions of anyone, just as they did during the original IETF Last Call on the document. They often also specifically send the request for opinions to people they know might have higher-than-average concern for the topic. In this case, that's the TLS WG. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls