From stephen.farrell@cs.tcd.ie Sun Apr 1 05:03:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B84221F882F for ; Sun, 1 Apr 2012 05:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyqSBgEJO-Hz for ; Sun, 1 Apr 2012 05:03:28 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 57F8A21F881F for ; Sun, 1 Apr 2012 05:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id CEF4D171C04 for ; Sun, 1 Apr 2012 13:03:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1333281803; bh=F4uKM0yb5m8V85ewdjC/xixk +Tjg1vPkGTyjryF3wKk=; b=F0OJYW0bileo81Sos7gnO/X/zhfSwRTnyPtQSSmX q1eCn0x1zctQrx30mxCGYTaEqNk4ZcTWeP/sCflQbGXBdcJTSlBSq9Wf8VoWL2RZ Y+DSf5WvPJ88VbZb8eioGVhsNTFmwvwr6G/d0G9wOcVoeIx/Fxoc6kcZKP/13fLl Su7GZ64j5iXKcyVHfRD6bFfN6tIMgmBJ8nZ2FqtbxENGZTiGe+D4vcP9cvtyBN12 qQkoaKukoE3p+EJ9Db/lnOlfv6qX2PISWSl7Ycrcyr0SzM4HqLWCp3ph9ZOx0591 p+on6R+z+ehvA3QvJ4C+QZoDzV+HQ+JgfggcV7WprrhQtg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id I5tma4kJT8sF for ; Sun, 1 Apr 2012 13:03:23 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.31.132]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7C88C171BFD for ; Sun, 1 Apr 2012 13:03:23 +0100 (IST) Message-ID: <4F78440A.3000903@cs.tcd.ie> Date: Sun, 01 Apr 2012 13:03:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] other standards things that are important X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 12:03:29 -0000 Hiya, From time to time we get liaison statements from other standards groups that ask the IETF to do stuff, e.g. to go bother a bunch of IETF folks to produce a response detailing the work being done on topic "foo." Sean and I would like to get a feeling for how you perceive those different organisations' work so we can consume an appropriate amount of effort (ours and those we hassle) in responding, and on the basis of something a bit better than just our own hunches and opinions. So, I'd appreciate it if you could reply with an email naming other security related standards development activities and giving each marks from 10 related to their importance to the Internet. Basis of the marks-from-10 is we normalise ourselves at 5; 1 is really really bad and 10 is the best it can be. Take into account both technical excellence and pragmatic importance. Doesn't matter if the activity concerned is a producer of stuff we use, or a consumer of our stuff, we may have to deal with them in any case. Try be as specific as you can, say at the level equivalent to an IETF WG if possible. An example response might look like: w3c xkms 2 ieee 802.1x 7 You can add more detail if you like, and send your mail to the saag list, or just to Sean and/or I - whatever you prefer. Assuming we get enough inputs I'll summarise back to the list in a bit after anonymising. If we don't get enough input we'll come back with that news too. Pleae send any responses you have within one week from now if possible. Please start a separate thread if you want to discuss doing this, the methodology or anything else related but leave this thread for direct responses with numbers. Thanks, S. PS: I co-chaired xkms for w3c so I know its ok to say it's not the most important thing out there:-) PPS: We will of course continue to respond nicely to whoever liaises with us, but we'd like to know when to put in the extra effort to do it more than nicely:-) From eran@hueniverse.com Thu Mar 29 08:46:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B9921E8051 for ; Thu, 29 Mar 2012 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGi6CliKfW98 for ; Thu, 29 Mar 2012 08:46:41 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4943F21F891F for ; Thu, 29 Mar 2012 08:46:41 -0700 (PDT) Received: (qmail 26998 invoked from network); 29 Mar 2012 15:46:39 -0000 Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Mar 2012 15:46:39 -0000 Received: from P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.47]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id rTmY1i00411lQaG01Tmffu; Thu, 29 Mar 2012 08:46:39 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 08:45:05 -0700 From: Eran Hammer To: Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" Date: Thu, 29 Mar 2012 08:44:57 -0700 Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83 Thread-Index: Ac0NwHndRoLYNioVSTmLLmGEsPbr+wAAE8Wg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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-Mailman-Approved-At: Wed, 04 Apr 2012 04:16:17 -0700 Subject: Re: [saag] [OAUTH-WG] OAUTH Report for IETF-83 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:46:42 -0000 Hi Derek, Thanks for the notes. Is an audio recording available? > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Derek Atkins > Sent: Thursday, March 29, 2012 8:27 AM > To: saag@ietf.org; oauth@ietf.org > Subject: [OAUTH-WG] OAUTH Report for IETF-83 >=20 > Hi, >=20 > OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a tw= o > hour session. After introducing ourselves and welcoming me to the workin= g > group we thanked Barry and Blaine for their service. >=20 > Torsten spoke about draft-ietf-oauth-v2-threatmodel. This document has > completed WG Last Call. Torsten has applied changes based on the Last Ca= ll > Comments and has published a new revision. Barry promised to finish his > PROTO Shepard review next week so we can send this document to the > IESG. He promises to take Mike Thomas' issues from the list into account= and > make sure that everyone is happy. >=20 > [ I'd like to extend a personal thank you to Barry for continuing his rol= e > as document shephard for this draft. -- derek ] >=20 > Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and URN-Sub- > NS drafts. Except for one outstanding issue Mike believes these document= s > are ready for WGLC. Consensus in the room was to take these three docs t= o > WGLC, which the chairs will do by the end of next week. >=20 > The MAC Token draft has languished while time was spent working on the > core document. Eran was not here, nor was he online, to talk about the > status of the MAC Token draft. There were only a few people in the room > interested in reviewing the draft, which was not a clear consensus of > interest, even though this document does solve a problem that the bearer > tokens cannot. The chairs will take it to the list to evaluate if there = is enough > interest to continue with this document. As I've updated the list and chairs on multiple occasions, the draft is pra= ctically ready. There was some late arriving feedback which I did not get a= round to process. However, the main issue is lack of WG interest in this wo= rk. I am still planning to finish it by making very minor tweaks to the cur= rent draft, but would be very happy to make it an individual submission. The MAC draft has largely been my personal project to date. > In a related note, this document (as well as the v2-bearer document) is n= ot > available off the tools page even though it has not expired. I have take= n the > action item to get that sorted out. >=20 > Finally, we spent the majority of our time talking about rechartering bas= ed on > the proposed charter sent to the list by Hannes a week or two ago. > Consensus of the room was that there was enough interest to recharter > based roughly on the proposed charter. There was also consensus to inclu= de > Simple Web Discovery (in addition to, and separate from, Dynamic Client > Registration), although we will need to work with the ADs to make sure it > gets handled in the appropriate WG and Area. > Moreover, it's important to make sure the appropriate applications area > participants get involved in the SWD work. There is something very awkward about discussing SWD both in the context of= this working group, and in the context of future OAuth discovery work. The= idea of picking a discovery mechanism before the WG had a single discussio= n about what is included in discovery and what are the use cases and requir= ement is absurd. There has not been consensus on the list for including SWD in the WG charte= r. The only justification I have heard so far for this WG to be the SWD venue = is that it's easy because the author and a few other people interested are = already here. That's not a valid reason. Any further work on SWD also requires the IETF to view it in light of RFC 6= 415 (host-meta) which is a proposed standard approved in October 2011. The = IETF is not in the 'flavor of the month' business. Proper process requires = discussion about the merits of redoing the host-meta work from scratch in a= non-compatible way just because a handful of people 'like it better' with = little technical justification. Either way, this discussion does not belong here. EH From wmills@yahoo-inc.com Thu Mar 29 16:26:33 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7071921F8686 for ; Thu, 29 Mar 2012 16:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.259 X-Spam-Level: X-Spam-Status: No, score=-17.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYmAORKso++d for ; Thu, 29 Mar 2012 16:26:32 -0700 (PDT) Received: from nm14.bullet.mail.ne1.yahoo.com (nm14.bullet.mail.ne1.yahoo.com [98.138.90.77]) by ietfa.amsl.com (Postfix) with SMTP id 03F3421F861F for ; Thu, 29 Mar 2012 16:26:31 -0700 (PDT) Received: from [98.138.90.53] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2012 23:26:28 -0000 Received: from [98.138.88.238] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 29 Mar 2012 23:26:28 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 29 Mar 2012 23:26:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 777415.16519.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 52424 invoked by uid 60001); 29 Mar 2012 23:26:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333063588; bh=1sQp9B1S0sOZQS7jTkyUTw3PaXV1FLmaELJ3mLjdjf8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g55yCFk/uQUZIud12jmd9wJbti+PDLHyRfS6sq5mTvangvbazbwYxcY9LIhGftoqsfdvepgUoI6SRZGJT6b+X2fIgX7t0FiLY9pr3hanADqDdgTL05dt0Aw+rUc++QC+itPJHqlynFmTV6FMcZA/5Re1Md51zpuvvcwGAK/FLs4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=OmheZNuaHFIvRZbUaYQQbA9JlogIiQCaqJ1WnO/xc6zSDHi8LMy3ax17ZtgyP58EWJbnjAvM6tm5XR2oPrHqxQqIddCNfAkDXKekM9c6XwZWY1KMTohebuM6ab6KgESo73spZtzA7oMULBGW9kUGQzbv3D8mN4WIt1Nfod/kqBw=; X-YMail-OSG: wVjB2DEVM1m0t.EYyIautkR9Q3DhzhZUJp5xngZh5lKkSDR KpJFv9zxprlri48XOFac2KY8fSCgSX0InQA3zRDnTt1_WWPX3o5u9E6pyMuM ULbNE1I0ZPf4tdEvJ871j9Wb0L9AewuHGNisxxpg1ZWsMDeVLV0rtLWXd4Yb Aq.2.eNzkF.07rrLmus8mNI4EfdpS_Zd4C3ZEqMCngHJDMolcHfx1C8r9psA k1WdzUQg0D2rG_y4tuGsQTpH8q6PR7FeCRYTLnTebPLC16ivj1zdiQ5.gVqi uXULb3RtKV6bgqv6evSUPno1EHkB7_MMIt3ThKGuOof7WMsLuCGfnkKgYydF la.XCXZptUjzpI4LhP_i.LNQJcW5chwuU_uZTJFodmFGJWnuMIpfjHW2.fbb vCInHM8jnSfx02WwCQXOkhl8fNI0uNqv8t_hYwo.sKPa5cOSK2Zo- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Thu, 29 Mar 2012 16:26:28 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Thu, 29 Mar 2012 16:26:28 -0700 (PDT) From: William Mills To: Eran Hammer , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-2004229102-1333063588=:49896" X-Mailman-Approved-At: Wed, 04 Apr 2012 04:16:17 -0700 Subject: Re: [saag] [OAUTH-WG] OAUTH Report for IETF-83 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:26:33 -0000 ---1238014912-2004229102-1333063588=:49896 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On the SWD stuff there was general discussion about "is this the right plac= e?", and there "were issues raised".=A0 The question was also asked "well, = where is the right place?" which got crickets.=A0 It is exactly coming back= to the list for discussion to sort out the right place.=0A=0A=0A=0A=0A>___= _____________________________=0A> From: Eran Hammer = =0A>To: Derek Atkins ; "saag@ietf.org" ; "o= auth@ietf.org" =0A>Sent: Thursday, March 29, 2012 8:44 AM= =0A>Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83=0A> =0A>Hi Derek,=0A>= =0A>Thanks for the notes. Is an audio recording available?=0A>=0A>> -----Or= iginal Message-----=0A>> From: oauth-bounces@ietf.org [mailto:oauth-bounces= @ietf.org] On Behalf=0A>> Of Derek Atkins=0A>> Sent: Thursday, March 29, 20= 12 8:27 AM=0A>> To: saag@ietf.org; oauth@ietf.org=0A>> Subject: [OAUTH-WG] = OAUTH Report for IETF-83=0A>> =0A>> Hi,=0A>> =0A>> OAUTH met earlier this a= fternoon in Afternoon Session I at 13h00 for a two=0A>> hour session.=A0 Af= ter introducing ourselves and welcoming me to the working=0A>> group we tha= nked Barry and Blaine for their service.=0A>> =0A>> Torsten spoke about dra= ft-ietf-oauth-v2-threatmodel.=A0 This document has=0A>> completed WG Last C= all.=A0 Torsten has applied changes based on the Last Call=0A>> Comments an= d has published a new revision.=A0 Barry promised to finish his=0A>> PROTO = Shepard review next week so we can send this document to the=0A>> IESG.=A0 = He promises to take Mike Thomas' issues from the list into account and=0A>>= make sure that everyone is happy.=0A>> =0A>> [ I'd like to extend a person= al thank you to Barry for continuing his role=0A>>=A0 as document shephard= for this draft.=A0 -- derek ]=0A>> =0A>> Next, Mike Jones spoke about the = Assertions, SAML2 Bearer, and URN-Sub-=0A>> NS drafts.=A0 Except for one ou= tstanding issue Mike believes these documents=0A>> are ready for WGLC.=A0 C= onsensus in the room was to take these three docs to=0A>> WGLC, which the c= hairs will do by the end of next week.=0A>> =0A>> The MAC Token draft has l= anguished while time was spent working on the=0A>> core document.=A0 Eran w= as not here, nor was he online, to talk about the=0A>> status of the MAC To= ken draft.=A0 There were only a few people in the room=0A>> interested in r= eviewing the draft, which was not a clear consensus of=0A>> interest, even = though this document does solve a problem that the bearer=0A>> tokens canno= t.=A0 The chairs will take it to the list to evaluate if there is enough=0A= >> interest to continue with this document.=0A>=0A>As I've updated the list= and chairs on multiple occasions, the draft is practically ready. There wa= s some late arriving feedback which I did not get around to process. Howeve= r, the main issue is lack of WG interest in this work. I am still planning = to finish it by making very minor tweaks to the current draft, but would be= very happy to make it an individual submission.=0A>=0A>The MAC draft has l= argely been my personal project to date.=0A>=0A>> In a related note, this d= ocument (as well as the v2-bearer document) is not=0A>> available off the t= ools page even though it has not expired.=A0 I have taken the=0A>> action i= tem to get that sorted out.=0A>> =0A>> Finally, we spent the majority of ou= r time talking about rechartering based on=0A>> the proposed charter sent t= o the list by Hannes a week or two ago.=0A>> Consensus of the room was that= there was enough interest to recharter=0A>> based roughly on the proposed = charter.=A0 There was also consensus to include=0A>> Simple Web Discovery (= in addition to, and separate from, Dynamic Client=0A>> Registration), altho= ugh we will need to work with the ADs to make sure it=0A>> gets handled in = the appropriate WG and Area.=0A>> Moreover, it's important to make sure the= appropriate applications area=0A>> participants get involved in the SWD wo= rk.=0A>=0A>There is something very awkward about discussing SWD both in the= context of this working group, and in the context of future OAuth discover= y work. The idea of picking a discovery mechanism before the WG had a singl= e discussion about what is included in discovery and what are the use cases= and requirement is absurd.=0A>=0A>There has not been consensus on the list= for including SWD in the WG charter.=0A>=0A>The only justification I have = heard so far for this WG to be the SWD venue is that it's easy because the = author and a few other people interested are already here. That's not a val= id reason.=0A>=0A>Any further work on SWD also requires the IETF to view it= in light of RFC 6415 (host-meta) which is a proposed standard approved in = October 2011. The IETF is not in the 'flavor of the month' business. Proper= process requires discussion about the merits of redoing the host-meta work= from scratch in a non-compatible way just because a handful of people 'lik= e it better' with little technical justification.=0A>=0A>Either way, this d= iscussion does not belong here.=0A>=0A>EH=0A>=0A>__________________________= _____________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://ww= w.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> ---1238014912-2004229102-1333063588=:49896 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
On the SWD stuff there was general discussion about "is this the right pl= ace?", and there "were issues raised".  The question was also asked "w= ell, where is the right place?" which got crickets.  It is exactly com= ing back to the list for discussion to sort out the right place.
=

From: Eran Ham= mer <eran@hueniverse.com>
T= o: Derek Atkins <derek@ihtfp.com>; "saag@ietf.org" <saag@ietf.org>= ;; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, March 29, 2012 8:44 AM
Subject: Re: [OAUTH-WG] OAUTH Report= for IETF-83

=0AHi Derek,

Thanks for the note= s. Is an audio recording available?

> -----Original Message-----<= br>> From: oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf
> Of Derek Atkins
> Sent: Thursda= y, March 29, 2012 8:27 AM
> To: saag@ietf.org; oauth@ietf.org
> Subject= : [OAUTH-WG] OAUTH Report for IETF-83
>
> Hi,
>
>= OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a two=
> hour session.  After introducing ourselves and welcoming me t= o the working
> group we thanked Barry and Blaine for their service.<= br>>
> Torsten spoke about draft-ietf-oauth-v2-threatmodel.  This document has
> completed= WG Last Call.  Torsten has applied changes based on the Last Call
= > Comments and has published a new revision.  Barry promised to fin= ish his
> PROTO Shepard review next week so we can send this document= to the
> IESG.  He promises to take Mike Thomas' issues from th= e list into account and
> make sure that everyone is happy.
> <= br>> [ I'd like to extend a personal thank you to Barry for continuing h= is role
>  as document shephard for this draft.  -- derek = ]
>
> Next, Mike Jones spoke about the Assertions, SAML2 Beare= r, and URN-Sub-
> NS drafts.  Except for one outstanding issue M= ike believes these documents
> are ready for WGLC.  Consensus in= the room was to take these three docs to
> WGLC, which the chairs wi= ll do by the end of next week.
>
> The MAC Token draft has languished while time was spent working on the
> core document.&= nbsp; Eran was not here, nor was he online, to talk about the
> statu= s of the MAC Token draft.  There were only a few people in the room> interested in reviewing the draft, which was not a clear consensus of=
> interest, even though this document does solve a problem that the = bearer
> tokens cannot.  The chairs will take it to the list to = evaluate if there is enough
> interest to continue with this document= .

As I've updated the list and chairs on multiple occasions, the dra= ft is practically ready. There was some late arriving feedback which I did = not get around to process. However, the main issue is lack of WG interest i= n this work. I am still planning to finish it by making very minor tweaks t= o the current draft, but would be very happy to make it an individual submi= ssion.

The MAC draft has largely been my personal project to date.

> In a related note, this document (as well as the v2-bear= er document) is not
> available off the tools page even though it has= not expired.  I have taken the
> action item to get that sorted= out.
>
> Finally, we spent the majority of our time talking a= bout rechartering based on
> the proposed charter sent to the list by= Hannes a week or two ago.
> Consensus of the room was that there was= enough interest to recharter
> based roughly on the proposed charter= .  There was also consensus to include
> Simple Web Discovery (i= n addition to, and separate from, Dynamic Client
> Registration), alt= hough we will need to work with the ADs to make sure it
> gets handle= d in the appropriate WG and Area.
> Moreover, it's important to make = sure the appropriate applications area
> participants get involved in= the SWD work.

There is something very awkward about discussing SWD both in the context of this working group, and in the conte= xt of future OAuth discovery work. The idea of picking a discovery mechanis= m before the WG had a single discussion about what is included in discovery= and what are the use cases and requirement is absurd.

There has not= been consensus on the list for including SWD in the WG charter.

The= only justification I have heard so far for this WG to be the SWD venue is = that it's easy because the author and a few other people interested are alr= eady here. That's not a valid reason.

Any further work on SWD also r= equires the IETF to view it in light of RFC 6415 (host-meta) which is a pro= posed standard approved in October 2011. The IETF is not in the 'flavor of = the month' business. Proper process requires discussion about the merits of= redoing the host-meta work from scratch in a non-compatible way just becau= se a handful of people 'like it better' with little technical justification.

Either way, this discussion does not belong here.
EH

_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br>

---1238014912-2004229102-1333063588=:49896-- From eran@hueniverse.com Thu Mar 29 19:25:38 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564E921E8043; Thu, 29 Mar 2012 19:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EavrV-yvo+3K; Thu, 29 Mar 2012 19:25:33 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5521E801C; Thu, 29 Mar 2012 19:25:32 -0700 (PDT) Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id reRY1i00110TkE001eRYvo; Thu, 29 Mar 2012 19:25:32 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 19:25:32 -0700 From: Eran Hammer To: William Mills , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" Date: Thu, 29 Mar 2012 19:25:23 -0700 Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83 Thread-Index: Ac0OA2EAhhPYKnyhR0i6KLfy2HrQpQAFc/Og Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 04 Apr 2012 04:16:17 -0700 Subject: Re: [saag] [OAUTH-WG] OAUTH Report for IETF-83 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 02:25:38 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The narrative so far: The IETF has adopted host-meta as a general-purpose discovery mechanism in = RFC 6415. The OpenID Connect group, which utilizes OAuth but is out of scope for this= WG, adopted SWD as its discovery mechanism. The proposed charter references 'OAuth Dynamic Client Registration Protocol= ', which in turn references RFC 6415 as its discovery mechanism. Am I missing a WG item or proposed draft which relies on SWD at this time? = If I am, are these documents included in the proposed charter or are reques= ted to be included (e.g. not SWT itself but other documents with dependenci= es on it)? In such documents, is SWD a required component which cannot be s= ubstituted with something else such as RFC 6415? Here is how this process should work: 1. The WG agrees on including a discovery related item in its charter= . The dynamic client registration is a reasonable such item. 2. The charter references an existing proposal as foundation. 3. The WG begins discussing the proposed draft (which can happen at a= ny time on the list as long as the chairs allow it). 4. The WG discusses any required enabling technologies, their suitabi= lity, maturity, industry support, etc. In the case of dynamic registration,= I expect the WG to discuss SWD (because it is the technology selected by t= he OpenID subset of this WG), host-meta (because it is an IETF proposed sta= ndard RFC), as well as other solutions (Link headers, other well-known URIs= , etc.). The publication status of the proposed technologies is another fac= tor. 5. If an enabling technology is decided to be the most suitable, and = is not available in normative reference form, the WG will discuss the best = way to accomplish that. This includes identifying the right community, stan= dards body, working group, etc. that is best to take on the work. If no sui= table venue is found, the WG may decide to take on the work with very limit= ed scope only to enable its own use cases. I am not opposed to having this discussion, but why are *we* having it *now= *, other than the OpenID Connect group, which has nothing to do with this W= G, is stuck with the problem of finding a venue for this work, and are dump= ing it on our laps? I do not recall this WG ever decided (or even *proposed*) to use SWD for an= y of its chartered items. When we have this discussion, I expect it to incl= ude a detailed examination of host-meta and other solutions *as equal* alte= rnatives. The OpenID Connect group preference is a valid input as it covers= some potential market share with OAuth deployment, but it is *far* from an= y significant deployment worthy of bypassing this evaluation. Am I missing something here? EH From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Thursday, March 29, 2012 4:26 PM To: Eran Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83 On the SWD stuff there was general discussion about "is this the right plac= e?", and there "were issues raised". The question was also asked "well, wh= ere is the right place?" which got crickets. It is exactly coming back to = the list for discussion to sort out the right place. ________________________________ From: Eran Hammer > To: Derek Atkins >; "saag@ietf.org<= mailto:saag@ietf.org>" >; "oauth@ietf.o= rg" > Sent: Thursday, March 29, 2012 8:44 AM Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83 Hi Derek, Thanks for the notes. Is an audio recording available? > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Derek Atkins > Sent: Thursday, March 29, 2012 8:27 AM > To: saag@ietf.org; oauth@ietf.org > Subject: [OAUTH-WG] OAUTH Report for IETF-83 > > Hi, > > OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a tw= o > hour session. After introducing ourselves and welcoming me to the workin= g > group we thanked Barry and Blaine for their service. > > Torsten spoke about draft-ietf-oauth-v2-threatmodel. This document has > completed WG Last Call. Torsten has applied changes based on the Last Ca= ll > Comments and has published a new revision. Barry promised to finish his > PROTO Shepard review next week so we can send this document to the > IESG. He promises to take Mike Thomas' issues from the list into account= and > make sure that everyone is happy. > > [ I'd like to extend a personal thank you to Barry for continuing his rol= e > as document shephard for this draft. -- derek ] > > Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and URN-Sub- > NS drafts. Except for one outstanding issue Mike believes these document= s > are ready for WGLC. Consensus in the room was to take these three docs t= o > WGLC, which the chairs will do by the end of next week. > > The MAC Token draft has languished while time was spent working on the > core document. Eran was not here, nor was he online, to talk about the > status of the MAC Token draft. There were only a few people in the room > interested in reviewing the draft, which was not a clear consensus of > interest, even though this document does solve a problem that the bearer > tokens cannot. The chairs will take it to the list to evaluate if there = is enough > interest to continue with this document. As I've updated the list and chairs on multiple occasions, the draft is pra= ctically ready. There was some late arriving feedback which I did not get a= round to process. However, the main issue is lack of WG interest in this wo= rk. I am still planning to finish it by making very minor tweaks to the cur= rent draft, but would be very happy to make it an individual submission. The MAC draft has largely been my personal project to date. > In a related note, this document (as well as the v2-bearer document) is n= ot > available off the tools page even though it has not expired. I have take= n the > action item to get that sorted out. > > Finally, we spent the majority of our time talking about rechartering bas= ed on > the proposed charter sent to the list by Hannes a week or two ago. > Consensus of the room was that there was enough interest to recharter > based roughly on the proposed charter. There was also consensus to inclu= de > Simple Web Discovery (in addition to, and separate from, Dynamic Client > Registration), although we will need to work with the ADs to make sure it > gets handled in the appropriate WG and Area. > Moreover, it's important to make sure the appropriate applications area > participants get involved in the SWD work. There is something very awkward about discussing SWD both in the context of= this working group, and in the context of future OAuth discovery work. The= idea of picking a discovery mechanism before the WG had a single discussio= n about what is included in discovery and what are the use cases and requir= ement is absurd. There has not been consensus on the list for including SWD in the WG charte= r. The only justification I have heard so far for this WG to be the SWD venue = is that it's easy because the author and a few other people interested are = already here. That's not a valid reason. Any further work on SWD also requires the IETF to view it in light of RFC 6= 415 (host-meta) which is a proposed standard approved in October 2011. The = IETF is not in the 'flavor of the month' business. Proper process requires = discussion about the merits of redoing the host-meta work from scratch in a= non-compatible way just because a handful of people 'like it better' with = little technical justification. Either way, this discussion does not belong here. EH _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The narra= tive so far:

 

The IETF has adopted host-meta a= s a general-purpose discovery mechanism in RFC 6415.

<= p class=3DMsoNormal>The OpenID Connect group, which utilizes OAuth b= ut is out of scope for this WG, adopted SWD as its discovery mechanism.

The proposed charter referenc= es ‘OAuth Dynamic Client Registration Protocol’, which in turn = references RFC 6415 as its discovery mechanism.

 

Am I missing a WG item or proposed draft which relies on SWD at this tim= e? If I am, are these documents included in the proposed charter or are req= uested to be included (e.g. not SWT itself but other documents with depende= ncies on it)? In such documents, is SWD a required component which cannot b= e substituted with something else such as RFC 6415?

 

= Here is how this process should work:

 

= 1.       The WG agrees on including a discovery re= lated item in its charter. The dynamic client registration is a reasonable = such item.

2. = ;      The charter references an existing proposal as foundation= .

3.  &n= bsp;    The WG begins discussing the proposed draft (which can happen at a= ny time on the list as long as the chairs allow it).

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 l= fo1'>4.       <= /span>The WG discusse= s any required enabling technologies, their suitability, maturity, industry= support, etc. In the case of dynamic registration, I expect the WG to disc= uss SWD (because it is the technology selected by the OpenID subset of this= WG), host-meta (because it is an IETF proposed standard RFC), as well as o= ther solutions (Link headers, other well-known URIs, etc.). The publication= status of the proposed technologies is another factor.

5.      = ; If an enabli= ng technology is decided to be the most suitable, and is not available in n= ormative reference form, the WG will discuss the best way to accomplish tha= t. This includes identifying the right community, standards body, working g= roup, etc. that is best to take on the work. If no suitable venue is found,= the WG may decide to take on the work with very limited scope only to enab= le its own use cases.

 

I am not opposed to hav= ing this discussion, but why are *we* having it *now*, other = than the OpenID Connect group, which has nothing to do with this WG, is stu= ck with the problem of finding a venue for this work, and are dumping it on= our laps?

 

I do not recall this WG ever decid= ed (or even *proposed*) to use SWD for any of its chartered items. W= hen we have this discussion, I expect it to include a detailed examination = of host-meta and other solutions *as equal* alternatives. The OpenID= Connect group preference is a valid input as it covers some potential mark= et share with OAuth deployment, but it is *far* from any significant= deployment worthy of bypassing this evaluation.

 

Am I missing something here?

=  

EH

 

 

 

 =

 

<= div>

From: William Mills [mailto:wmills@yahoo-in= c.com]
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran= Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org
Subject: Re:= [OAUTH-WG] OAUTH Report for IETF-83

 

On the SWD stuff there was general discussion about "= ;is this the right place?", and there "were issues raised".&= nbsp; The question was also asked "well, where is the right place?&quo= t; which got crickets.  It is exactly coming back to the list for disc= ussion to sort out the right place.

 

<= div>

From: Eran = Hammer <eran@hueniverse.com&g= t;
To: Derek Atkins <derek@= ihtfp.com>; "saag@ietf.org= " <saag@ietf.org>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, March= 29, 2012 8:44 AM
Subject: Re: [OAUTH-WG] OAUTH Report for IETF-8= 3


Hi Derek,

Thanks for the notes. Is an audio recording= available?

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
>= ; To: saag@ietf.org; oauth@ietf.org
> Subject: [OAUTH-WG] OAUTH Repor= t for IETF-83
>
> Hi,
>
> OAUTH met earlier this = afternoon in Afternoon Session I at 13h00 for a two
> hour session.&n= bsp; After introducing ourselves and welcoming me to the working
> gr= oup we thanked Barry and Blaine for their service.
>
> Torsten= spoke about draft-ietf-oauth-v2-threatmodel.  This document has
&g= t; completed WG Last Call.  Torsten has applied changes based on the L= ast Call
> Comments and has published a new revision.  Barry pro= mised to finish his
> PROTO Shepard review next week so we can send t= his document to the
> IESG.  He promises to take Mike Thomas' is= sues from the list into account and
> make sure that everyone is happ= y.
>
> [ I'd like to extend a personal thank you to Barry for = continuing his role
>  as document shephard for this draft. = ; -- derek ]
>
> Next, Mike Jones spoke about the Assertions, = SAML2 Bearer, and URN-Sub-
> NS drafts.  Except for one outstand= ing issue Mike believes these documents
> are ready for WGLC.  C= onsensus in the room was to take these three docs to
> WGLC, which th= e chairs will do by the end of next week.
>
> The MAC Token dr= aft has languished while time was spent working on the
> core documen= t.  Eran was not here, nor was he online, to talk about the
> st= atus of the MAC Token draft.  There were only a few people in the room=
> interested in reviewing the draft, which was not a clear consensus= of
> interest, even though this document does solve a problem that t= he bearer
> tokens cannot.  The chairs will take it to the list = to evaluate if there is enough
> interest to continue with this docum= ent.

As I've updated the list and chairs on multiple occasions, the = draft is practically ready. There was some late arriving feedback which I d= id not get around to process. However, the main issue is lack of WG interes= t in this work. I am still planning to finish it by making very minor tweak= s to the current draft, but would be very happy to make it an individual su= bmission.

The MAC draft has largely been my personal project to date= .

> In a related note, this document (as well as the v2-bearer do= cument) is not
> available off the tools page even though it has not = expired.  I have taken the
> action item to get that sorted out.=
>
> Finally, we spent the majority of our time talking about = rechartering based on
> the proposed charter sent to the list by Hann= es a week or two ago.
> Consensus of the room was that there was enou= gh interest to recharter
> based roughly on the proposed charter.&nbs= p; There was also consensus to include
> Simple Web Discovery (in add= ition to, and separate from, Dynamic Client
> Registration), although= we will need to work with the ADs to make sure it
> gets handled in = the appropriate WG and Area.
> Moreover, it's important to make sure = the appropriate applications area
> participants get involved in the = SWD work.

There is something very awkward about discussing SWD both = in the context of this working group, and in the context of future OAuth di= scovery work. The idea of picking a discovery mechanism before the WG had a= single discussion about what is included in discovery and what are the use= cases and requirement is absurd.

There has not been consensus on th= e list for including SWD in the WG charter.

The only justification I= have heard so far for this WG to be the SWD venue is that it's easy becaus= e the author and a few other people interested are already here. That's not= a valid reason.

Any further work on SWD also requires the IETF to v= iew it in light of RFC 6415 (host-meta) which is a proposed standard approv= ed in October 2011. The IETF is not in the 'flavor of the month' business. = Proper process requires discussion about the merits of redoing the host-met= a work from scratch in a non-compatible way just because a handful of peopl= e 'like it better' with little technical justification.

Either way, = this discussion does not belong here.

EH

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

= --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Thu Mar 29 23:13:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D7C21F86C6 for ; Thu, 29 Mar 2012 23:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.267 X-Spam-Level: X-Spam-Status: No, score=-17.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbLjUOwau3t0 for ; Thu, 29 Mar 2012 23:13:19 -0700 (PDT) Received: from nm13-vm4.bullet.mail.ne1.yahoo.com (nm13-vm4.bullet.mail.ne1.yahoo.com [98.138.91.173]) by ietfa.amsl.com (Postfix) with SMTP id AECE321F86C1 for ; Thu, 29 Mar 2012 23:13:18 -0700 (PDT) Received: from [98.138.90.51] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 30 Mar 2012 06:13:15 -0000 Received: from [98.138.226.167] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 30 Mar 2012 06:13:15 -0000 Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 30 Mar 2012 06:13:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 727187.90308.bm@omp1068.mail.ne1.yahoo.com Received: (qmail 4543 invoked by uid 60001); 30 Mar 2012 06:13:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1333087995; bh=I17ufNYyJYdq1T+oDSryGu8u10Bn22VdrBbiE3mIoa4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WUJLa5nzo+lox2/bwPIL+Mj6zRrVHD+TO5PV8EJJzopjdJxh5WNTSeJtzFvJcUU5Q4fNLTl+Dfnrfp/mmV+yWhGBTzEHZseWacKphkify+fJfyidGpUL+FDtbsmZ/yP0bjDIfWmsUESxI8Z0nNX2V4P++BvpM/AtQ0r2hT0yN2o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=O70zux3VyurA6iW72BscfgjlRV4up9xicv/LJ94hUPbMLtvjzfv4pFW6rhjopnfCyGDigFWnFIZQBisvZ4YEJK8/GCM+g9na6VQUHmBtpXXTk2ACGa/f857S0/uozbCGMe1jq2nWfPkypI5BBr25ZTDhVtFZ6NEZ6Pd9QYCULMc=; X-YMail-OSG: QQiUBCUVM1kyxiqEHx6ZjRxLqRN.Vo7bC1QnW8viHloKhKk QIG2L5sWCLxrodQdHxqOXn_ZZXZ2imWBbJojP10q2GVcy4rML_0PQSeMBL6s 46sdtbvIufu5BkvYrygNyEUZrP8haHz3L86TeznewJJPxj0s4rGTG2BJBz7y XkkpfXajX4x53T82OJhXkc9WogvWkrrpL.oMsdRdhuPzXELh44Ay4cfLaS8z jf9tsT.Y4E1Rjke0DFoyiqhYdVvSKO8_FYZA5NTwtZBXhrR4a5vxzI.cz2wV SH2kdGsHvzlCMtWG2269MkoCmcnGO2BPOZ.ulu.a5EiPBFRtnaxkuvFGVDfc 38CijxOzBcnmMsfD_Gl9hRoBsKEn32dXXxt.pia_RlIDaIOXRgQ39gCriISY 03sVu0SHXSEM1F2khyWUw35UA_hKns.TdZHlhiVKLO_FkfPDpQnk- Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Thu, 29 Mar 2012 23:13:14 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 References: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 29 Mar 2012 23:13:14 -0700 (PDT) From: William Mills To: Eran Hammer , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-808086310-1333087994=:88149" X-Mailman-Approved-At: Wed, 04 Apr 2012 04:16:17 -0700 Subject: Re: [saag] [OAUTH-WG] OAUTH Report for IETF-83 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 06:13:21 -0000 --764183289-808086310-1333087994=:88149 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the process lecture....=C2=A0 except we already had extensive di= scussion of same in the WG meeting...=0A=0APartially this issue was raised = because my draft does a discovery thing and I want this sorted out to figur= e out what hooks I need to put in so I can get done.=C2=A0 I want to be con= sistent with whatever will be the chosen standardized usage. I really DO NO= T care how we solve the problem as long as it's solved.=0A=0AI think your p= oint that host-meta and LINK/REL solve the same problem is a fair one, it c= ame up in the room.=C2=A0 Another comment in the room was that for JS based= stuff JSON is far easier to deal with than XML, and I think that's probabl= y also really true, so there are some competing isues.=C2=A0 =0A=0A=0A-bill= =0A=0A=0A=0A=0A>________________________________=0A> From: Eran Hammer =0A>To: William Mills ; Derek Atkins= ; "saag@ietf.org" ; "oauth@ietf.org" =0A>Sent: Thursday, March 29, 2012 7:25 PM=0A>Subject: RE: [OAU= TH-WG] OAUTH Report for IETF-83=0A> =0A>=0A>The narrative so far:=0A>=C2=A0= =0A>The IETF has adopted host-meta as a general-purpose discovery mechanism= in RFC 6415.=0A>The OpenID Connect group, which utilizes OAuth but is out = of scope for this WG, adopted SWD as its discovery mechanism.=0A>The propos= ed charter references =E2=80=98OAuth Dynamic Client Registration Protocol= =E2=80=99, which in turn references RFC 6415 as its discovery mechanism.=0A= >=C2=A0=0A>Am I missing a WG item or proposed draft which relies on SWD at = this time? If I am, are these documents included in the proposed charter or= are requested to be included (e.g. not SWT itself but other documents with= dependencies on it)? In such documents, is SWD a required component which = cannot be substituted with something else such as RFC 6415?=0A>=C2=A0=0A>He= re is how this process should work:=0A>=C2=A0=0A>1.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 The WG agrees on including a discovery related item in its cha= rter. The dynamic client registration is a reasonable such item.=0A>2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The charter references an existing propos= al as foundation.=0A>3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The WG begins d= iscussing the proposed draft (which can happen at any time on the list as l= ong as the chairs allow it).=0A>4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The = WG discusses any required enabling technologies, their suitability, maturit= y, industry support, etc. In the case of dynamic registration, I expect the= WG to discuss SWD (because it is the technology selected by the OpenID sub= set of this WG), host-meta (because it is an IETF proposed standard RFC), a= s well as other solutions (Link headers, other well-known URIs, etc.). The = publication status of the proposed technologies is another factor.=0A>5.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If an enabling technology is decided to b= e the most suitable, and is not available in normative reference form, the = WG will discuss the best way to accomplish that. This includes identifying = the right community, standards body, working group, etc. that is best to ta= ke on the work. If no suitable venue is found, the WG may decide to take on= the work with very limited scope only to enable its own use cases.=0A>=C2= =A0=0A>I am not opposed to having this discussion, but why are *we* having = it *now*, other than the OpenID Connect group, which has nothing to do with= this WG, is stuck with the problem of finding a venue for this work, and a= re dumping it on our laps?=0A>=C2=A0=0A>I do not recall this WG ever decide= d (or even *proposed*) to use SWD for any of its chartered items. When we h= ave this discussion, I expect it to include a detailed examination of host-= meta and other solutions *as equal* alternatives. The OpenID Connect group = preference is a valid input as it covers some potential market share with O= Auth deployment, but it is *far* from any significant deployment worthy of = bypassing this evaluation.=0A>=C2=A0=0A>Am I missing something here?=0A>=C2= =A0=0A>EH=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A>=C2=A0=0A>From:William= Mills [mailto:wmills@yahoo-inc.com] =0A>Sent: Thursday, March 29, 2012 4:2= 6 PM=0A>To: Eran Hammer; Derek Atkins; saag@ietf.org; oauth@ietf.org=0A>Sub= ject: Re: [OAUTH-WG] OAUTH Report for IETF-83=0A>=C2=A0=0A>On the SWD stuff= there was general discussion about "is this the right place?", and there "= were issues raised".=C2=A0 The question was also asked "well, where is the = right place?" which got crickets.=C2=A0 It is exactly coming back to the li= st for discussion to sort out the right place.=0A>=C2=A0=0A>>=0A>>_________= _______________________=0A>>=0A>>From:Eran Hammer =0A>= >To: Derek Atkins ; "saag@ietf.org" ; "oaut= h@ietf.org" =0A>>Sent: Thursday, March 29, 2012 8:44 AM=0A= >>Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83=0A>>=0A>>Hi Derek,=0A>>= =0A>>Thanks for the notes. Is an audio recording available?=0A>>=0A>>> ----= -Original Message-----=0A>>> From: oauth-bounces@ietf.org [mailto:oauth-bou= nces@ietf.org] On Behalf=0A>>> Of Derek Atkins=0A>>> Sent: Thursday, March = 29, 2012 8:27 AM=0A>>> To: saag@ietf.org; oauth@ietf.org=0A>>> Subject: [OA= UTH-WG] OAUTH Report for IETF-83=0A>>> =0A>>> Hi,=0A>>> =0A>>> OAUTH met ea= rlier this afternoon in Afternoon Session I at 13h00 for a two=0A>>> hour s= ession.=C2=A0 After introducing ourselves and welcoming me to the working= =0A>>> group we thanked Barry and Blaine for their service.=0A>>> =0A>>> To= rsten spoke about draft-ietf-oauth-v2-threatmodel.=C2=A0 This document has= =0A>>> completed WG Last Call.=C2=A0 Torsten has applied changes based on t= he Last Call=0A>>> Comments and has published a new revision.=C2=A0 Barry p= romised to finish his=0A>>> PROTO Shepard review next week so we can send t= his document to the=0A>>> IESG.=C2=A0 He promises to take Mike Thomas' issu= es from the list into account and=0A>>> make sure that everyone is happy.= =0A>>> =0A>>> [ I'd like to extend a personal thank you to Barry for contin= uing his role=0A>>>=C2=A0 as document shephard for this draft.=C2=A0 -- der= ek ]=0A>>> =0A>>> Next, Mike Jones spoke about the Assertions, SAML2 Bearer= , and URN-Sub-=0A>>> NS drafts.=C2=A0 Except for one outstanding issue Mike= believes these documents=0A>>> are ready for WGLC.=C2=A0 Consensus in the = room was to take these three docs to=0A>>> WGLC, which the chairs will do b= y the end of next week.=0A>>> =0A>>> The MAC Token draft has languished whi= le time was spent working on the=0A>>> core document.=C2=A0 Eran was not he= re, nor was he online, to talk about the=0A>>> status of the MAC Token draf= t.=C2=A0 There were only a few people in the room=0A>>> interested in revie= wing the draft, which was not a clear consensus of=0A>>> interest, even tho= ugh this document does solve a problem that the bearer=0A>>> tokens cannot.= =C2=A0 The chairs will take it to the list to evaluate if there is enough= =0A>>> interest to continue with this document.=0A>>=0A>>As I've updated th= e list and chairs on multiple occasions, the draft is practically ready. Th= ere was some late arriving feedback which I did not get around to process. = However, the main issue is lack of WG interest in this work. I am still pla= nning to finish it by making very minor tweaks to the current draft, but wo= uld be very happy to make it an individual submission.=0A>>=0A>>The MAC dra= ft has largely been my personal project to date.=0A>>=0A>>> In a related no= te, this document (as well as the v2-bearer document) is not=0A>>> availabl= e off the tools page even though it has not expired.=C2=A0 I have taken the= =0A>>> action item to get that sorted out.=0A>>> =0A>>> Finally, we spent t= he majority of our time talking about rechartering based on=0A>>> the propo= sed charter sent to the list by Hannes a week or two ago.=0A>>> Consensus o= f the room was that there was enough interest to recharter=0A>>> based roug= hly on the proposed charter.=C2=A0 There was also consensus to include=0A>>= > Simple Web Discovery (in addition to, and separate from, Dynamic Client= =0A>>> Registration), although we will need to work with the ADs to make su= re it=0A>>> gets handled in the appropriate WG and Area.=0A>>> Moreover, it= 's important to make sure the appropriate applications area=0A>>> participa= nts get involved in the SWD work.=0A>>=0A>>There is something very awkward = about discussing SWD both in the context of this working group, and in the = context of future OAuth discovery work. The idea of picking a discovery mec= hanism before the WG had a single discussion about what is included in disc= overy and what are the use cases and requirement is absurd.=0A>>=0A>>There = has not been consensus on the list for including SWD in the WG charter.=0A>= >=0A>>The only justification I have heard so far for this WG to be the SWD = venue is that it's easy because the author and a few other people intereste= d are already here. That's not a valid reason.=0A>>=0A>>Any further work on= SWD also requires the IETF to view it in light of RFC 6415 (host-meta) whi= ch is a proposed standard approved in October 2011. The IETF is not in the = 'flavor of the month' business. Proper process requires discussion about th= e merits of redoing the host-meta work from scratch in a non-compatible way= just because a handful of people 'like it better' with little technical ju= stification.=0A>>=0A>>Either way, this discussion does not belong here.=0A>= >=0A>>EH=0A>>=0A>>_______________________________________________=0A>>OAuth= mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/= oauth=0A>>=0A>>=0A>=0A> --764183289-808086310-1333087994=:88149 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for the process lecture....  except we already had extensive = discussion of same in the WG meeting...

<= /div>
Partially this issue was raised because my draft does a dis= covery thing and I want this sorted out to figure out what hooks I need to = put in so I can get done.  I want to be consistent with whatever will = be the chosen standardized usage. I really DO NOT care how we solve the pro= blem as long as it's solved.

<= span>I think your point that host-meta and LINK/REL solve the same problem = is a fair one, it came up in the room.  Another comment in the room wa= s that for JS based stuff JSON is far easier to deal with than XML, and I t= hink that's probably also really true, so there are some competing isues. 

-bill=

From:<= /b> Eran Hammer <eran@hueniverse.com>
To: William Mills <wmills@yahoo-inc.com>; Derek= Atkins <derek@ihtfp.com>; "saag@ietf.org" <saag@ietf.org>; "oa= uth@ietf.org" <oauth@ietf.org>
Sent: Thursday, March 29, 2012 7:25 PM
Subject: RE: [OAUTH-WG] OAUTH Report for= IETF-83

=0A
The narrative so far:
 
The IETF has adopted host-meta as a general-purpos= e discovery mechanism in RFC 6415.
The OpenID Connect group, which utilizes OAuth but is out = of scope for this WG, adopted SWD as its discovery mechanism.
<= div class=3D"yiv117739012MsoNormal">The proposed charter references= =E2=80=98OAuth Dynamic Client Registration Protocol=E2=80=99, which in turn references RFC 6415 a= s its discovery mechanism.
 
A= m I missing a WG item or proposed draft which relies on SWD at this time? I= f I am, are these documents included in the proposed charter or are request= ed to be included (e.g. not SWT itself but other documents with dependencie= s on it)? In such documents, is SWD a required component which cannot be su= bstituted with something else such as RFC 6415?
 
Here is how this process should work:
 
1.       = The WG agrees on including a= discovery related item in its charter. The dynamic client registration is = a reasonable such item.
2.       The charter references an existing proposal = as foundation.
3.       The WG begins discussing the proposed draft = (which can happen at any time on the list as long as the chairs allow it).<= /span>
= 4.       The WG discusses any required enabling techn= ologies, their suitability, maturity, industry support, etc. In the case of= dynamic registration, I expect the WG to discuss SWD (because it is the te= chnology selected by the OpenID subset of this WG), host-meta (because it i= s an IETF proposed standard RFC), as well as other solutions (Link headers,= other well-known URIs, etc.). The publication status of the proposed techn= ologies is another factor.
5.       If an enabling technology is decided to be the most suitable, and is not= available in normative reference form, the WG will discuss the best way to= accomplish that. This includes identifying the right community, standards = body, working group, etc. that is best to take on the work. If no suitable = venue is found, the WG may decide to take on the work with very limited sco= pe only to enable its own use cases.
 
I am not opposed to having this discussion, but why are *we= * having it *now*, other than the OpenID Connect group, which has no= thing to do with this WG, is stuck with the problem of finding a venue for this work, and are dumping it on our laps?
 
I do not recall this WG ever decided (or even *proposed<= /b>*) to use SWD for any of its chartered items. When we have this discussi= on, I expect it to include a detailed examination of host-meta and other so= lutions *as equal* alternatives. The OpenID Connect group preference= is a valid input as it covers some potential market share with OAuth deplo= yment, but it is *far* from any significant deployment worthy of byp= assing this evaluation.
 
Am I missing something here?
 
EH
 
 
<= div class=3D"yiv117739012MsoNormal">  
 
 
From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Thursday, March 29, 2012 4:26 PM
To: Eran Hammer; Derek Atkins;= saag@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAUTH Repo= rt for IETF-83
 
On the SWD stuff there was general discussion about "i= s this the right place?", and there "were issues raised".  The question was also= asked "well, where is the right place?" which got crickets.  It is ex= actly coming back to the list for discussion to sort out the right place.
 
From:= Eran Hammer <eran@hueniverse.com= >
To: Derek Atkins <derek= @ihtfp.com>; "saag@ietf.org" <saag@ietf.org>; "oa= uth@ietf.org" <oauth@ietf.org> Sent: Thursday, March 29, 2012 8:44 AM
Subject: Re: [OAU= TH-WG] OAUTH Report for IETF-83

Hi Derek,

Thanks for the notes. Is an audio recording av= ailable?

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf> Of Derek Atkins
> Sent: Thursday, March 29, 2012 8:27 AM
>= ; To: saag@ietf.org; oauth@ietf.org
> Subject: [OAUTH-WG] OAUTH Report for IETF-83=
>
> Hi,
>
> OAUTH met earlier this afternoon in Afternoon Session I at 13h00 = for a two
> hour session.  After introducing ourselves and welco= ming me to the working
> group we thanked Barry and Blaine for their = service.
>
> Torsten spoke about draft-ietf-oauth-v2-threatmod= el.  This document has
> completed WG Last Call.  Torsten h= as applied changes based on the Last Call
> Comments and has publishe= d a new revision.  Barry promised to finish his
> PROTO Shepard = review next week so we can send this document to the
> IESG.  He= promises to take Mike Thomas' issues from the list into account and
>= ; make sure that everyone is happy.
>
> [ I'd like to extend a= personal thank you to Barry for continuing his role
>  as docum= ent shephard for this draft.  -- derek ]
>
> Next, Mike J= ones spoke about the Assertions, SAML2 Bearer, and URN-Sub-
> NS drafts.  Except for one outstanding issue Mike believes these docu= ments
> are ready for WGLC.  Consensus in the room was to take t= hese three docs to
> WGLC, which the chairs will do by the end of nex= t week.
>
> The MAC Token draft has languished while time was = spent working on the
> core document.  Eran was not here, nor wa= s he online, to talk about the
> status of the MAC Token draft. = There were only a few people in the room
> interested in reviewing t= he draft, which was not a clear consensus of
> interest, even though = this document does solve a problem that the bearer
> tokens cannot.&n= bsp; The chairs will take it to the list to evaluate if there is enough
= > interest to continue with this document.

As I've updated the li= st and chairs on multiple occasions, the draft is practically ready. There = was some late arriving feedback which I did not get around to process. However, the main issue is lack of WG interest in this work. I am= still planning to finish it by making very minor tweaks to the current dra= ft, but would be very happy to make it an individual submission.

The= MAC draft has largely been my personal project to date.

> In a r= elated note, this document (as well as the v2-bearer document) is not
&g= t; available off the tools page even though it has not expired.  I hav= e taken the
> action item to get that sorted out.
>
> Fi= nally, we spent the majority of our time talking about rechartering based o= n
> the proposed charter sent to the list by Hannes a week or two ago= .
> Consensus of the room was that there was enough interest to recha= rter
> based roughly on the proposed charter.  There was also co= nsensus to include
> Simple Web Discovery (in addition to, and separa= te from, Dynamic Client
> Registration), although we will need to work with the ADs to make sure it
> gets handled in the appropria= te WG and Area.
> Moreover, it's important to make sure the appropria= te applications area
> participants get involved in the SWD work.
=
There is something very awkward about discussing SWD both in the contex= t of this working group, and in the context of future OAuth discovery work.= The idea of picking a discovery mechanism before the WG had a single discu= ssion about what is included in discovery and what are the use cases and re= quirement is absurd.

There has not been consensus on the list for in= cluding SWD in the WG charter.

The only justification I have heard s= o far for this WG to be the SWD venue is that it's easy because the author = and a few other people interested are already here. That's not a valid reas= on.

Any further work on SWD also requires the IETF to view it in lig= ht of RFC 6415 (host-meta) which is a proposed standard approved in October 2011. The IETF is not in the 'flavor of the month' business. Prope= r process requires discussion about the merits of redoing the host-meta wor= k from scratch in a non-compatible way just because a handful of people 'li= ke it better' with little technical justification.

Either way, this = discussion does not belong here.

EH

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth

=


--764183289-808086310-1333087994=:88149-- From eran@hueniverse.com Fri Mar 30 00:37:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6F21F85F4 for ; Fri, 30 Mar 2012 00:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsoXUujVZthY for ; Fri, 30 Mar 2012 00:37:26 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 932A421F8600 for ; Fri, 30 Mar 2012 00:37:25 -0700 (PDT) Received: (qmail 24476 invoked from network); 30 Mar 2012 07:37:24 -0000 Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Mar 2012 07:37:24 -0000 Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id rjdQ1i0010U5vnL01jdQ03; Fri, 30 Mar 2012 00:37:24 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 30 Mar 2012 00:37:24 -0700 From: Eran Hammer To: William Mills , Derek Atkins , "saag@ietf.org" , "oauth@ietf.org" Date: Fri, 30 Mar 2012 00:37:15 -0700 Thread-Topic: [OAUTH-WG] OAUTH Report for IETF-83 Thread-Index: Ac0OPDQnyHD4N+ubRGuCp/Me96jLUgAA40mw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333063588.49896.YahooMailNeo@web31816.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1333087994.88149.YahooMailNeo@web31811.mail.mud.yahoo.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 04 Apr 2012 04:16:17 -0700 Cc: "'Paul E. Jones \(paulej@packetizer.com\)'" Subject: Re: [saag] [OAUTH-WG] OAUTH Report for IETF-83 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:37:26 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2lsbGlhbSBNaWxscyBb bWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjks IDIwMTIgMTE6MTMgUE0NCj4gVG86IEVyYW4gSGFtbWVyOyBEZXJlayBBdGtpbnM7IHNhYWdAaWV0 Zi5vcmc7IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BVVRIIFJl cG9ydCBmb3IgSUVURi04Mw0KPiANCj4gVGhhbmtzIGZvciB0aGUgcHJvY2VzcyBsZWN0dXJlLi4u LsKgIGV4Y2VwdCB3ZSBhbHJlYWR5IGhhZCBleHRlbnNpdmUNCj4gZGlzY3Vzc2lvbiBvZiBzYW1l IGluIHRoZSBXRyBtZWV0aW5nLi4uDQoNClRoZSBjb21tZW50IHNoYXJlZCB3aXRoIHRoZSBsaXN0 IHdhczoNCg0KIlRoZXJlIHdhcyBhbHNvIGNvbnNlbnN1cyB0byBpbmNsdWRlIFNpbXBsZSBXZWIg RGlzY292ZXJ5IChpbiBhZGRpdGlvbiB0bywgYW5kIHNlcGFyYXRlIGZyb20sIER5bmFtaWMgQ2xp ZW50IFJlZ2lzdHJhdGlvbikiDQoNClRoaXMgImxlY3R1cmUiIGlzIG15IGF0dGVtcHQgYXQgdW5k ZXJzdGFuZGluZyBob3cgdGhlIHBlb3BsZSBpbiB0aGUgcm9vbSAoSSB3YXMgdW5hYmxlIHRvIGFm Zm9yZCBmbHlpbmcgdG8gUGFyaXMgb3IgYmUgdXAgYXQgNGFtKSBnb3QgZnJvbSB0aGUgRHluYW1p YyBDbGllbnQgUmVnaXN0cmF0aW9uIHByb3Bvc2FsIHdoaWNoIGRvZXMgbm90IGV2ZW4gbWVudGlv biBTV0QgKGJ1dCBkb2VzIHJlbHkgb24gYW4gb3V0ZGF0ZWQgdmVyc2lvbiBvZiBSRkMgNjQxNSks IHRvIGluY2x1ZGluZyBTV0QgYXMgYSAic2VwYXJhdGUiIGl0ZW0gd2l0aG91dCBhbnkgZGlyZWN0 IGxpbmsgdG8gT0F1dGggKG90aGVyIHRoYW4gImludGVyZXN0IGluIHRoZSByb29tIikuDQoNClNp bmNlIHRoZSBjaGFpciBpbXBsaWVkIHRoYXQgdGhlcmUgd2FzIGFscmVhZHkgY29uc2Vuc3VzICh3 aGljaCBpcyBhIHZlcnkgc2lnbmlmaWNhbnQgSUVURiBwcm9jZXNzIHN0YXRlbWVudCksIHJhaXNp bmcgcHJvY2VzcyBpc3N1ZXMgaXMgb25lIHRvb2wgdGhlIElFVEYgcHJvdmlkZXMgZm9yIHRob3Nl IGluIGRpc2FncmVlbWVudC4NCg0KPiBQYXJ0aWFsbHkgdGhpcyBpc3N1ZSB3YXMgcmFpc2VkIGJl Y2F1c2UgbXkgZHJhZnQgZG9lcyBhIGRpc2NvdmVyeSB0aGluZyBhbmQgSQ0KPiB3YW50IHRoaXMg c29ydGVkIG91dCB0byBmaWd1cmUgb3V0IHdoYXQgaG9va3MgSSBuZWVkIHRvIHB1dCBpbiBzbyBJ IGNhbiBnZXQNCj4gZG9uZS7CoCBJIHdhbnQgdG8gYmUgY29uc2lzdGVudCB3aXRoIHdoYXRldmVy IHdpbGwgYmUgdGhlIGNob3NlbiBzdGFuZGFyZGl6ZWQNCj4gdXNhZ2UuIEkgcmVhbGx5IERPIE5P VCBjYXJlIGhvdyB3ZSBzb2x2ZSB0aGUgcHJvYmxlbSBhcyBsb25nIGFzIGl0J3Mgc29sdmVkLg0K DQpJIERPIGNhcmUgaG93IHdlIHNvbHZlIHRoaXMgcHJvYmxlbSwgYnV0IG1vcmUgaW1wb3J0YW50 bHksIGRlZmluaW5nIHdoYXQgdGhlIHByb2JsZW0gYWN0dWFsbHkgaXMuIA0KDQo+IEkgdGhpbmsg eW91ciBwb2ludCB0aGF0IGhvc3QtbWV0YSBhbmQgTElOSy9SRUwgc29sdmUgdGhlIHNhbWUgcHJv YmxlbSBpcyBhDQo+IGZhaXIgb25lLCBpdCBjYW1lIHVwIGluIHRoZSByb29tLsKgIEFub3RoZXIg Y29tbWVudCBpbiB0aGUgcm9vbSB3YXMgdGhhdCBmb3INCj4gSlMgYmFzZWQgc3R1ZmYgSlNPTiBp cyBmYXIgZWFzaWVyIHRvIGRlYWwgd2l0aCB0aGFuIFhNTCwgYW5kIEkgdGhpbmsgdGhhdCdzDQo+ IHByb2JhYmx5IGFsc28gcmVhbGx5IHRydWUsIHNvIHRoZXJlIGFyZSBzb21lIGNvbXBldGluZyBp c3Vlcy4NCg0KVGhpcyBqdXN0IHNob3dzIGhvdyBsaXR0bGUgdGVjaG5pY2FsIGR1ZS1kaWxpZ2Vu Y2Ugd2FzIGRvbmUgYnkgdGhpcyBncm91cC4NCg0KUkZDIDY0MTUgcHJvdmlkZXMgZnVsbCBKU09O IHN1cHBvcnQuIFRoZSBXZWJGaW5nZXIgZHJhZnQgd2hpY2ggc2xpZ2h0bHkgZXh0ZW5kcyBSRkMg NjQxNSwgbWFrZXMgSlNPTiBzdXBwb3J0IHJlcXVpcmVkIGFuZCBhZGRzIHRoZSAncmVzb3VyY2Un IHF1ZXJ5IHBhcmFtZXRlciBbMV0uIEEgYWRkaXRpb25hbCAncmVsJyBxdWVyeSBwYXJhbWV0ZXIg aGFzIGFsc28gYmVlbiBwcm9wb3NlZCBhbmQgaXMgYmVpbmcgZGlzY3Vzc2VkIG9uIHRoZSBBUFBT IGRpc2N1c3MgbGlzdC4NCg0KSSBndWVzcyBteSBxdWVzdGlvbiBpcywgd2h5IGlzbid0IFJGQyA2 NDE1IGJ5IHRoZSBzaW1wbGUgdmlydHVlIG9mIGl0IGJlaW5nIGEgcHVibGlzaCBJRVRGIHByb3Bv c2VkIHN0YW5kYXJkIFJGQyB0aGUgZGVmYXVsdCBhbmQgb2J2aW91cyBjaG9pY2UgaGVyZT8gV2h5 IGlzbid0IHRoaXMgZGlzY3Vzc2lvbiBmcmFtZWQgaW4gdGVybXMgb2YgbWFraW5nIGVuaGFuY2Vt ZW50cyB0byBSRkMgNjQxNSAoYXMgYWxyZWFkeSBpbiBwcm9ncmVzcyBieSB0aGUgV2ViRmluZ2Vy IHByb3Bvc2FsLCB3aGljaCBCVFcsIGlzIGFsc28gdW5kZXIgZGlzY3Vzc2lvbiBmb3IgSUVURiB2 ZW51ZSkgb3IgaW4gdGVybXMgb2YgZGlzY3Vzc2luZyB3aHkgUkZDIDY0MTUgaXMgbm90IHRoZSBz dWl0YWJsZSBjaG9pY2UgZm9yIHRoZSB5ZXQtdG8tYmUtZGVmaW5lZCBPQXV0aCBkaXNjb3Zlcnkg ZnJhbWV3b3JrPw0KDQpJcyB0aGlzIGdyb3VwIGV2ZW4gYXdhcmUgdGhhdCB0aGUgNSB5ZWFycyBl ZmZvcnQgKCEpIGxlYWRpbmcgdG8gUkZDIDY0MTUgd2FzIHByaW1hcmlseSBkb25lIGZvciBPQXV0 aCBkaXNjb3Zlcnk/IFRoZXJlIGlzIHNvIG11Y2ggcmVsZXZhbnQgaGlzdG9yeSBoZXJlIGJlaW5n IGNvbXBsZXRlbHkgaWdub3JlZC4NCg0KSWYgdGhlIE9BdXRoIGNoYXJ0ZXIgaXMgZ29pbmcgdG8g bWVudGlvbiBTV0QsIGl0IG11c3QgYWxzbyBtZW50aW9uIFJGQyA2NDE1IGFzIGFuIGVxdWFsIGFs dGVybmF0aXZlIHRvIGJlIGRpc2N1c3NlZCBieSB0aGUgV0cuIFRoZSBjaGFydGVyIGRpc2N1c3Np b24gaXMgY2xlYXJseSBub3QgdGhlIHBsYWNlIHRvIG1ha2UgdGhpcyBkZWNpc2lvbi4gSW4gYWRk aXRpb24sIGlmIHRoaXMgV0cgaXMgZ29pbmcgdG8gYnVzeSBpdHNlbGYgd2l0aCBoZWxwaW5nIGZp bmQgU1dEIGEgcHJvcGVyIGhvbWUsIHRoYXQgZGlzY3Vzc2lvbiBtdXN0IGFsc28gaW5jbHVkZSBm aW5kaW5nIGEgcHJvcGVyIGhvbWUgZm9yIHRoZSBXZWJGaW5nZXIgcHJvcG9zYWwsIGdpdmVuIHRo ZSBjbGVhciBJRVRGIGNvbmZsaWN0IGluIHByb21vdGluZyBib3RoLg0KDQpUaGUgZGlzY292ZXJ5 IHNvbHV0aW9uIGFkb3B0ZWQgYnkgT0F1dGggaXMgdmVyeSBsaWtlbHkgdG8gaGF2ZSBzaWduaWZp Y2FudCBpbmZsdWVuY2Ugb3ZlciBmdXR1cmUgd2ViIGRpc2NvdmVyeSBiZXlvbmQgT0F1dGguIFRo ZSBzdGFrZXMgaGVyZSBhcmUgcHJldHR5IGhpZ2guDQoNCkVIDQoNClsxXSBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1hcHBzYXdnLXdlYmZpbmdlci0wMiNzZWN0aW9uLTQu Mg0KDQo= From mcr@sandelman.ca Tue Apr 3 06:02:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03E521F8643 for ; Tue, 3 Apr 2012 06:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t06LFbL7TdjY for ; Tue, 3 Apr 2012 06:02:37 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 216F021F8620 for ; Tue, 3 Apr 2012 06:02:36 -0700 (PDT) Received: from sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id E515E34513 for ; Tue, 3 Apr 2012 08:59:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6E73B98AAF; Tue, 3 Apr 2012 09:02:34 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6232898AAE for ; Tue, 3 Apr 2012 09:02:34 -0400 (EDT) From: Michael Richardson To: "saag@ietf.org" In-Reply-To: <4F78440A.3000903@cs.tcd.ie> References: <4F78440A.3000903@cs.tcd.ie> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 03 Apr 2012 09:02:34 -0400 Message-ID: <12498.1333458154@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Wed, 04 Apr 2012 04:16:17 -0700 Subject: Re: [saag] other standards things that are important X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:02:37 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Stephen" =3D=3D Stephen Farrell writes: Stephen> From time to time we get liaison statements from other Stephen> standards groups that ask the IETF to do stuff, e.g. to go Stephen> bother a bunch of IETF folks to produce a response Stephen> detailing the work being done on topic "foo." Any standard that doesn't have an open URL that anyone can read, is not, in my opinion, a useful standard. So I regard any entity that wants to us review their document, so that they can then sell it to people, is suspect. In particular, since few run-of-the-mill developers out there will ever pay to read that document, it's relevance to the internet is almost nil. (Sure, they might be told, "implement 802.1x" by their boss, but if given the task of "make sure our product has access control on the networking", they won't consider technology in documents that they can not read)=20 =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3r06oqHRg3pndX9AQIafAQAlCpisgWTmITb4g3XZ4diDkly+Q8B+AYo KMQmhEcGGsTvvRmPcXz4qNehp0546JIjAcmB8NcO3/7Xc5NndR4HWOAIn3aJd2uY z0LVynRaqd0LJdiuo52sDysyUaa4yYm29zwcBVgkZTpBzDiryIPiFOkmfcI4uuVF MVuNzE7uaY0= =ao41 -----END PGP SIGNATURE----- --=-=-=-- From simon@josefsson.org Wed Apr 4 05:23:06 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7321F8656 for ; Wed, 4 Apr 2012 05:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.76 X-Spam-Level: X-Spam-Status: No, score=-99.76 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K5GX0VjrN-i for ; Wed, 4 Apr 2012 05:23:05 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id CCF1E21F84DC for ; Wed, 4 Apr 2012 05:23:03 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34CMrb5021649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 14:22:54 +0200 From: Simon Josefsson To: Michael Richardson References: <4F78440A.3000903@cs.tcd.ie> <12498.1333458154@marajade.sandelman.ca> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120404:mcr@sandelman.ca::QUwJE70VGSHU3cUu:4BTv X-Hashcash: 1:22:120404:saag@ietf.org::xh+4nD9dm+H8QSrd:CzRI Date: Wed, 04 Apr 2012 14:22:52 +0200 In-Reply-To: <12498.1333458154@marajade.sandelman.ca> (Michael Richardson's message of "Tue, 03 Apr 2012 09:02:34 -0400") Message-ID: <878vibptyb.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "saag@ietf.org" Subject: Re: [saag] other standards things that are important X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:23:06 -0000 Michael Richardson writes: >>>>>> "Stephen" == Stephen Farrell writes: > Stephen> From time to time we get liaison statements from other > Stephen> standards groups that ask the IETF to do stuff, e.g. to go > Stephen> bother a bunch of IETF folks to produce a response > Stephen> detailing the work being done on topic "foo." > > Any standard that doesn't have an open URL that anyone can read, is not, > in my opinion, a useful standard. +1 Btw, it would make it easier to answer the initial question if we had the names of at least a few organizations that you were thinking of. /Simon From Tina.Tsou.Zouting@huawei.com Wed Apr 4 15:49:54 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974E711E812E for ; Wed, 4 Apr 2012 15:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl9ZXhrbAnwF for ; Wed, 4 Apr 2012 15:49:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1811E812B for ; Wed, 4 Apr 2012 15:49:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEY66086; Wed, 04 Apr 2012 18:49:53 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 15:46:02 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 15:46:07 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 5 Apr 2012 06:45:59 +0800 From: Tina TSOU To: Michael Richardson Thread-Topic: [saag] other standards things that are important Thread-Index: AQHNEAEYMA+4XJazK06e7WNdj3C+2JaIjfMAgAK7cXE= Date: Wed, 4 Apr 2012 22:45:58 +0000 Message-ID: References: <4F78440A.3000903@cs.tcd.ie>, <12498.1333458154@marajade.sandelman.ca> In-Reply-To: <12498.1333458154@marajade.sandelman.ca> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "saag@ietf.org" Subject: Re: [saag] other standards things that are important X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:49:54 -0000 Sent from my iPad On Apr 4, 2012, at 4:17 AM, "Michael Richardson" wr= ote: >=20 >>>>>> "Stephen" =3D=3D Stephen Farrell writes: > Stephen> From time to time we get liaison statements from other > Stephen> standards groups that ask the IETF to do stuff, e.g. to go > Stephen> bother a bunch of IETF folks to produce a response > Stephen> detailing the work being done on topic "foo." >=20 > Any standard that doesn't have an open URL that anyone can read, is not, > in my opinion, a useful standard. So I regard any entity that wants to > us review their document, so that they can then sell it to people, is > suspect. >=20 > In particular, since few run-of-the-mill developers out there will ever > pay to read that document, it's relevance to the internet is almost nil. > (Sure, they might be told, "implement 802.1x" by their boss, but if > given the task of "make sure our product has access control on the > networking", they won't consider technology in documents that they can > not read)=20 I did have to read IEEE standard when I implemented 802.1X in the year 2001= -2002. To make sure our product has access control on the networking, we cr= eated a regional standard version of 802.1X. >=20 >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | firewa= lls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net arch= itect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device d= river[ > Kyoto Plus: watch the video > then sign the petition.=20 >=20 >=20 >=20 >=20 From stephen.farrell@cs.tcd.ie Wed Apr 4 15:53:38 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E89311E8098 for ; Wed, 4 Apr 2012 15:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.058 X-Spam-Level: X-Spam-Status: No, score=-106.058 tagged_above=-999 required=5 tests=[AWL=-3.458, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD2JrqN3BG5Y for ; Wed, 4 Apr 2012 15:53:37 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF7F11E808C for ; Wed, 4 Apr 2012 15:53:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C3863171C54; Wed, 4 Apr 2012 23:53:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333580015; bh=LR6Esk/b4WaLIa hsVQbvhwA8GXC2gxZJYp1zwszixkU=; b=ZJ/Ttx5kWa7Lteew5PLTX4j1jtDN4i ikP3RBNQLFldB+qjYT9dPUbkE5S6OtJVPOREbNJlRbEgISihGWCkVPDIEwImsiz/ BlQISfzU+EIyk4SfWCdwhPYqHnTbXCj54BADUBUvyzDyZAtiIQyhuaL3JiUVk5zn zZcrote/vyPV9lnFkXOC3QwEyylA7tgw9I2Eg8o+bQIb01LJKt5hWyVR/ttck8W1 VbISLV1miT6E7gxPD4EZvclxmuAdYyVgjfpg15fLPNFmpxw9M0LR5OnritjzZiSR fqu+fAq2SUJ96oHr6HnAI+X/Z76kUK3tDH+gDWQnp2kwmOymt1Izhdew== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id NqHlZLJMjpfC; Wed, 4 Apr 2012 23:53:35 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.28.31]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7ED32171C1C; Wed, 4 Apr 2012 23:53:33 +0100 (IST) Message-ID: <4F7CD0ED.5050103@cs.tcd.ie> Date: Wed, 04 Apr 2012 23:53:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Simon Josefsson References: <4F78440A.3000903@cs.tcd.ie> <12498.1333458154@marajade.sandelman.ca> <878vibptyb.fsf@latte.josefsson.org> In-Reply-To: <878vibptyb.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] other standards things that are important X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:53:38 -0000 On 04/04/2012 01:22 PM, Simon Josefsson wrote: > Michael Richardson writes: > >>>>>>> "Stephen" == Stephen Farrell writes: >> Stephen> From time to time we get liaison statements from other >> Stephen> standards groups that ask the IETF to do stuff, e.g. to go >> Stephen> bother a bunch of IETF folks to produce a response >> Stephen> detailing the work being done on topic "foo." >> >> Any standard that doesn't have an open URL that anyone can read, is not, >> in my opinion, a useful standard. > > +1 > > Btw, it would make it easier to answer the initial question if we had > the names of at least a few organizations that you were thinking of. Fair enough. (You're the 2nd to ask) Look at the "From" list on [1] Cheers, S [1] https://datatracker.ietf.org/liaison/ > > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From stephen.farrell@cs.tcd.ie Thu Apr 12 08:29:49 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFC321F8674 for ; Thu, 12 Apr 2012 08:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1avjhIH0+Kk for ; Thu, 12 Apr 2012 08:29:49 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 056D321F8671 for ; Thu, 12 Apr 2012 08:29:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7107317147D for ; Thu, 12 Apr 2012 16:29:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334244588; bh=GyO8JHfiL8mqWp AjcIVqXryAPv17sHQ47Z6Ncw8VbFo=; b=T82RYsvySlAnBkIuoNXu2OCANUDGsd /1EAu7v0GF0GhuLTQXnRerFoxj21XpriFwl7dZ3njWGwAQysnltW3prkWpUUQ64G DW9Vul2uj0i8T/rXCJzexuu6z0tKsMR2l0/n7lQLmTOypS6ZCsABX7d8yS6uJziN mPlJie2OKVVNzBW3brumkuPGFGQuiP2udKDPGdSYE+L8jCmy98QGyWtkFUBiDyfN IUQywddR/EP+hvPHYoMdOteMpYQLOkZgrpDDpLgW/zboHgOKauuhT3GRafpEGsR5 r4UxJ+hF4rrYMNOiGFPzEa4hoHW4WVDPCSqKsXy8Fywa7S54kBdoKgaQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id spNRLtrA9drA for ; Thu, 12 Apr 2012 16:29:48 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.63.74]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 11E1617147C for ; Thu, 12 Apr 2012 16:29:47 +0100 (IST) Message-ID: <4F86F4EB.4050105@cs.tcd.ie> Date: Thu, 12 Apr 2012 16:29:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "saag@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: NIST Request for Comments on Proposed Changes to FIPS 186-3: The Digital Signature Standard X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:29:50 -0000 Not sure if everyone who cares gets this or not so here ya go. If there were any change that impacted on IETF protocols that'd be good to know, Thanks, Stephen. -------- Original Message -------- Subject: NIST Request for Comments on Proposed Changes to FIPS 186-3: The Digital Signature Standard Date: Thu, 12 Apr 2012 11:21:48 -0400 From: Caswell, Sara J. To: stephen.farrell@cs.tcd.ie **************** PLEASE DO NOT REPLY TO THIS EMAIL **************** NIST requests comments on proposed changes to Federal Information Processing Standard 186-3, the Digital Signature Standard. The Federal Register Notice requests that electronic comments be sent by May 25, 2012 to: fips_186-3_change_notice@nist.gov, with 186-3 Change Notice in the subject line. The Federal Register Notice for this proposed change notice for FIPS 186-3 can be accessed by clicking the link "Federal Register Notice". The first link below is the Proposed Change Notice that are proposed for FIPS 186-3. The second link below is the current approved FIPS 186-3. change-notice_fips-186-3.pdf (152 KB) fips_186-3.pdf **************** PLEASE DO NOT REPLY TO THIS EMAIL **************** From bew@cisco.com Thu Apr 12 12:14:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2398121F864A for ; Thu, 12 Apr 2012 12:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MS5I4Pv-iNOI for ; Thu, 12 Apr 2012 12:14:21 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D671521F8643 for ; Thu, 12 Apr 2012 12:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=2307; q=dns/txt; s=iport; t=1334258061; x=1335467661; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sEIp8XdR3Ui5Jo0dxRXZ1Im0JngagoT+iUw0H0uKwsQ=; b=mUm9Y2KuX4wNNVCYp2VujkIpIr7VP0kgZL/7JX65cH0z/WtgC+32kxaG CaIE0Hjmqgo6jaFZggVrTbuTZx5f4FM7n4UHMeik1U6OxOz4KiQzAha0Y w/pQd+egeuQzu4SxPG8hHuqIANAn5fAF7OghDkpkbnJtKSsvYkstXB/vY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGUph0+rRDoJ/2dsb2JhbABCA7l1gQeCCQEBAQMBAQEBDwEnNAsQCxguHAswBhMZCYdnBAyaDZFSjj6OVYJGYwSHCoFQjRKBEYsQgiyBaYMHgTw X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="37731677" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 Apr 2012 19:14:10 +0000 Received: from dhcp-171-69-137-44.cisco.com (dhcp-171-69-137-44.cisco.com [171.69.137.44]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3CJEAvA008552; Thu, 12 Apr 2012 19:14:10 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Thu, 12 Apr 2012 12:14:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F78440A.3000903@cs.tcd.ie>, <12498.1333458154@marajade.sandelman.ca> To: Tina TSOU X-Mailer: Apple Mail (2.1257) Cc: Michael Richardson , "saag@ietf.org" Subject: Re: [saag] other standards things that are important X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:14:23 -0000 As an aside for those who aren't aware, IEEE 802 (and some other IEEE = standards) are available free of charge = six months after they issue. Brian On Apr 4, 2012, at 3:45 PM, Tina TSOU wrote: >=20 >=20 > Sent from my iPad >=20 > On Apr 4, 2012, at 4:17 AM, "Michael Richardson" = wrote: >=20 >>=20 >>>>>>> "Stephen" =3D=3D Stephen Farrell = writes: >> Stephen> =46rom time to time we get liaison statements from other >> Stephen> standards groups that ask the IETF to do stuff, e.g. to go >> Stephen> bother a bunch of IETF folks to produce a response >> Stephen> detailing the work being done on topic "foo." >>=20 >> Any standard that doesn't have an open URL that anyone can read, is = not, >> in my opinion, a useful standard. So I regard any entity that wants = to >> us review their document, so that they can then sell it to people, is >> suspect. >>=20 >> In particular, since few run-of-the-mill developers out there will = ever >> pay to read that document, it's relevance to the internet is almost = nil. >> (Sure, they might be told, "implement 802.1x" by their boss, but if >> given the task of "make sure our product has access control on the >> networking", they won't consider technology in documents that they = can >> not read)=20 > I did have to read IEEE standard when I implemented 802.1X in the year = 2001-2002. To make sure our product has access control on the = networking, we created a regional standard version of 802.1X. >>=20 >>=20 >> --=20 >> ] He who is tired of Weird Al is tired of life! | = firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >> Kyoto Plus: watch the video = >> then sign the petition.=20 >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From mouse@Sparkle.Rodents-Montreal.ORG Thu Apr 12 12:46:25 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D878C21F86E3 for ; Thu, 12 Apr 2012 12:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.129 X-Spam-Level: X-Spam-Status: No, score=-8.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzDLpFKh71uZ for ; Thu, 12 Apr 2012 12:46:25 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id D068B21F86E1 for ; Thu, 12 Apr 2012 12:46:24 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA09546; Thu, 12 Apr 2012 15:46:23 -0400 (EDT) Date: Thu, 12 Apr 2012 15:46:23 -0400 (EDT) From: Mouse Message-Id: <201204121946.PAA09546@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 12 Apr 2012 15:32:57 -0400 (EDT) To: saag@ietf.org In-Reply-To: References: <4F78440A.3000903@cs.tcd.ie> <12498.1333458154@marajade.sandelman.ca> Subject: Re: [saag] other standards things that are important X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:46:26 -0000 > As an aside for those who aren't aware, IEEE 802 (and some other IEEE > standards) are available free of charge > six months after they issue. Even if it's an "aside", I think it's fair to point out here that IEEE's terms are substantially more restrictive than "an open URL that anyone can read". For example, I'm not allowed to put them anywhere my usual backup regimen applies, because that involes a backup copy on-net and a second backup copy offsite. They also are licensed only for personal use (whatever that means; the terms-of-use do not explain). I'm not even sure whether I'd be allowed to convert it to plain text (which is normally the first thing I do with PDFs; plain text is far more useful for most of my purposes for most PDFs). Also, their development process _is_ closed, meaning that the results will be heavily biased towards benefits for their membership rather than benefits for the world at large, for the Internet, or for the state of the art. So I'm with Michael on this one. The IEEE is slightly better than some other (fully pay-to-play) `standards' organizations, but it's got a long way to go before I would consider it acceptable for IETF purposes, and before I would consider reviewing their documents without pay. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From turners@ieca.com Wed Apr 18 13:24:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D480911E80A4 for ; Wed, 18 Apr 2012 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeSQNrRskQXv for ; Wed, 18 Apr 2012 13:24:23 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.242.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28011E8094 for ; Wed, 18 Apr 2012 13:24:21 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 4CB4E3A9EAB50; Wed, 18 Apr 2012 15:24:20 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 426403A9EAB2F for ; Wed, 18 Apr 2012 15:24:20 -0500 (CDT) Received: from [71.191.9.245] (port=43412 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SKbQJ-0005tm-Ue for saag@ietf.org; Wed, 18 Apr 2012 15:24:20 -0500 Message-ID: <4F8F22F3.8080809@ieca.com> Date: Wed, 18 Apr 2012 16:24:19 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-9-245.washdc.east.verizon.net (thunderfish.local) [71.191.9.245]:43412 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 19 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: NIST Request for Comments: 2nd Public Draft, SP 800-130: A Framework for Designing Cryptographic Key Management Systems X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:24:27 -0000 I often get these and somebody on this light might find this of interest. As Stephen once noted on of these: if there were any change that impacted on IETF protocols that'd be good to know. spt -------- Original Message -------- Subject: NIST Request for Comments: 2nd Public Draft, SP 800-130: A Framework for Designing Cryptographic Key Management Systems Date: Wed, 18 Apr 2012 14:24:56 -0400 From: Caswell, Sara J. To: turners@ieca.com *Second Public Draft, Special Publication 800-130, /A Framework for Designing Cryptographic Key Management Systems/* Public Comment Period: April 13, 2012 through July 30, 2012. Email Comments to: ckmsdesignframework@nist.gov Second Public Draft Details: NIST requests comments on SP 800-130, A Framework for Designing Cryptographic Key Management Systems. This is a revision of the document that was provided for public comment in June 2010. Comments are requested by July 30, 2012 and should be sent to ckmsdesignframework@nist.gov, with "Comments on SP 800-130" in the subject line. Another document, SP 800-152, which provides a basic profile of this framework document for the Federal government, will be available for initial comment later this year. Links: Draft SP 800-130 (PDF) on CSRC website: http://csrc.nist.gov/publications/drafts/800-130/second-draft_sp-800-130_april-2012.pdf