From trammell@tik.ee.ethz.ch Wed Feb 1 02:41:10 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745C121F8659 for ; Wed, 1 Feb 2012 02:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Wu4AZPqqFwwA for ; Wed, 1 Feb 2012 02:41:10 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D743421F8655 for ; Wed, 1 Feb 2012 02:41:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7FAE4D9319; Wed, 1 Feb 2012 11:41:03 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b4KpfZv5Jx4M; Wed, 1 Feb 2012 11:41:03 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 52852D9310; Wed, 1 Feb 2012 11:41:03 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Feb 2012 11:41:02 +0100 Message-Id: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> To: Kathleen Moriarty Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: [mile] next up: mile-template X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 10:41:10 -0000 Hi, Kathleen, all, Now that the WG work on 6045-bis and 6046-bis is complete, and (almost) = in accordance with the charter, I believe the present revision of = draft-ietf-mile-template to be ready for WGLC. Many thanks, best regards, Brian Trammell (as author of mile-template)= From kathleen.moriarty@emc.com Wed Feb 1 04:34:40 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3321F86CB for ; Wed, 1 Feb 2012 04:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.802 X-Spam-Level: X-Spam-Status: No, score=-9.802 tagged_above=-999 required=5 tests=[AWL=0.797, BAYES_00=-2.599, 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 7nNIwzKzCQ00 for ; Wed, 1 Feb 2012 04:34:39 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3835C21F86C7 for ; Wed, 1 Feb 2012 04:34:39 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q11CYX70006891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 07:34:35 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 1 Feb 2012 07:34:17 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q11CYHRi009470; Wed, 1 Feb 2012 07:34:17 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub33.corp.emc.com ([::1]) with mapi; Wed, 1 Feb 2012 07:34:17 -0500 From: To: Date: Wed, 1 Feb 2012 07:34:16 -0500 Thread-Topic: Working group last call on Template draft Thread-Index: AczgzifD0S11HUnQQi2otfgXa8gokQADgttQ Message-ID: References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> In-Reply-To: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> 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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 12:34:40 -0000 Hello, We are starting a 2 week review period, the working group last call (WGLC) = for draft-ietf-mile-template. Please review and comment to the MILE list on= the template draft. =20 This is a short one and is used to provide a template for all extensions de= fined in MILE. http://tools.ietf.org/html/draft-ietf-mile-template-00 Last call on comments will end the morning of February 15th. Thank you, Kathleen (as WG chair) -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Wednesday, February 01, 2012 5:41 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: next up: mile-template Hi, Kathleen, all, Now that the WG work on 6045-bis and 6046-bis is complete, and (almost) in = accordance with the charter, I believe the present revision of draft-ietf-m= ile-template to be ready for WGLC. Many thanks, best regards, Brian Trammell (as author of mile-template) From pc@mitre.org Wed Feb 1 07:22:19 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A36721F86DA for ; Wed, 1 Feb 2012 07:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 OMVtsPx8YqAq for ; Wed, 1 Feb 2012 07:22:17 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 687D611E810B for ; Wed, 1 Feb 2012 07:22:17 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AEBBB21B023D; Wed, 1 Feb 2012 10:22:16 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A162321B100C; Wed, 1 Feb 2012 10:22:16 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Wed, 1 Feb 2012 10:22:16 -0500 From: "Chase, Melissa P." To: "Thomas.Millar@us-cert.gov" , "mile@ietf.org" Thread-Topic: MAEC in SCI Thread-Index: AczdG/WfbxSslx+pRm2MmJUNJy7mRgD1jKkA Date: Wed, 1 Feb 2012 15:22:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] MAEC in SCI X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:22:19 -0000 I think this make sense from the MAEC perspective. MAEC behaviors are proba= bly at the right level to express the what falls under the IODEF method (an= d other attributes could be abstracted to the campaign level) and MAEC bund= les capture all the details of individual malware samples. Penny Chase MAEC Project Lead -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Tho= mas.Millar@us-cert.gov Sent: Friday, January 27, 2012 12:49 PM To: mile@ietf.org Subject: [mile] MAEC in SCI I suggest we look at including MAEC in SCI. I believe the appropriate place= for most of what MAEC is intended to express falls under the IODEF Method = class at the top level, but individual instances of malicious code expresse= d using MAEC with full details of network/file observables and such are bet= ter reserved for EventData child classes. Would there be a way to explain how MAEC (or other malware languages) can b= e used in either location depending on the nature of what is being expresse= d? MAEC at the top level Method class would be concerned with common attrib= utes of malware being used in a campaign, perhaps - MAEC in children of Eve= ntData would be concerned with individual malware samples captured and anal= yzed. Making any sense? - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Wed Feb 1 09:10:15 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1C11E8126 for ; Wed, 1 Feb 2012 09:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.606 X-Spam-Level: X-Spam-Status: No, score=-0.606 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 SOyM2+K60c8b for ; Wed, 1 Feb 2012 09:10:14 -0800 (PST) Received: from mow.securemx.jp (mow301.securemx.jp [210.130.202.49]) by ietfa.amsl.com (Postfix) with ESMTP id A6F1311E812A for ; Wed, 1 Feb 2012 09:10:14 -0800 (PST) Received: by mow.securemx.jp (mow301) id q11HADvG017897; Thu, 2 Feb 2012 02:10:13 +0900 X-MXL-Hash: 4f2971f44b47c2b3-93fc5a94766887b7a569e0acba7c2dcbb3ba0e3e Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by relay.securemx.jp (mx-mr303) id q11HAC2T027458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 02:10:12 +0900 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q11HACPY015492 for ; Thu, 2 Feb 2012 02:10:12 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q11HACIF015138 for ; Thu, 2 Feb 2012 02:10:12 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id q11HABiL015135 for ; Thu, 2 Feb 2012 02:10:11 +0900 (JST) From: "Takeshi Takahashi" To: References: In-Reply-To: Date: Thu, 2 Feb 2012 02:10:13 +0900 Message-ID: <00d301cce104$5cabe630$1603b290$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFnyEdDZdS1/Y7UHplF9m1QLQzskgJRqDH9lt/pReA= Content-Language: ja Subject: Re: [mile] MAEC in SCI X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 17:10:15 -0000 Thank you for the kind comments, all. I agree, and the latest version submitted in this morning already includes the MAEC. (See Section 4.1.12) I hope it is ok now. Kind Regards, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Chase, Melissa P. > Sent: Thursday, February 02, 2012 12:22 AM > To: Thomas.Millar@us-cert.gov; mile@ietf.org > Subject: Re: [mile] MAEC in SCI > > I think this make sense from the MAEC perspective. MAEC behaviors are > probably at the right level to express the what falls under the IODEF > method (and other attributes could be abstracted to the campaign level) > and MAEC bundles capture all the details of individual malware samples. > > Penny Chase > MAEC Project Lead > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Thomas.Millar@us-cert.gov > Sent: Friday, January 27, 2012 12:49 PM > To: mile@ietf.org > Subject: [mile] MAEC in SCI > > I suggest we look at including MAEC in SCI. I believe the appropriate > place for most of what MAEC is intended to express falls under the IODEF > Method class at the top level, but individual instances of malicious code > expressed using MAEC with full details of network/file observables and > such are better reserved for EventData child classes. > > Would there be a way to explain how MAEC (or other malware languages) > can be used in either location depending on the nature of what is being > expressed? MAEC at the top level Method class would be concerned with > common attributes of malware being used in a campaign, perhaps - MAEC > in children of EventData would be concerned with individual malware > samples captured and analyzed. > > Making any sense? > > - Tom Millar, US-CERT > > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From paul.cichonski@nist.gov Wed Feb 1 12:48:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274F511E80E9 for ; Wed, 1 Feb 2012 12:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 BMA6+k7IG3rt for ; Wed, 1 Feb 2012 12:48:21 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4C11E80BE for ; Wed, 1 Feb 2012 12:48:21 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Feb 2012 15:48:04 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 1 Feb 2012 15:47:17 -0500 From: "Cichonski, Paul" To: "mile@ietf.org" Date: Wed, 1 Feb 2012 15:48:17 -0500 Thread-Topic: Public Comment Period Open on NIST 800-61 rev.2 - Incident Handling Guide Thread-Index: AczhIroA+4poJeQeSaubYuVa62lt3gAAAavg Message-ID: 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" MIME-Version: 1.0 Subject: [mile] Public Comment Period Open on NIST 800-61 rev.2 - Incident Handling Guide X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 20:48:22 -0000 Hey All, Just wanted to send out a quick heads up: NIST just released the draft version of the NIST SP 800-61 revision 2, Computer Security Incident Handling Guide (available here: http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-61-Rev.%202). The news bulletin at that link provides some of the relevant details and the change-log in Appendix H of the document provides a detailed list of the changes we have made since the last revision. The public comment period on this document is open until March 16. We rely on community comments to ensure the SP accurately reflects the state-of-the-art and best practices of the community, so we appreciate any comments you are able to provide on this (please send comments to: 800-61rev2-comments@nist.gov). Thanks, Paul From kathleen.moriarty@emc.com Mon Feb 6 12:09:27 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7621F8734 for ; Mon, 6 Feb 2012 12:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.835 X-Spam-Level: X-Spam-Status: No, score=-9.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, 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 ANNRxQaOGClL for ; Mon, 6 Feb 2012 12:09:27 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EE84021F8747 for ; Mon, 6 Feb 2012 12:09:26 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q16K9MnB017260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 15:09:25 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 6 Feb 2012 15:09:05 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q16K19WZ011209; Mon, 6 Feb 2012 15:01:10 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Mon, 6 Feb 2012 15:01:09 -0500 From: To: , Date: Mon, 6 Feb 2012 15:00:53 -0500 Thread-Topic: Working group last call on Template draft Thread-Index: AczgzifD0S11HUnQQi2otfgXa8gokQADgttQAEi4RXA= Message-ID: References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> 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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 20:09:27 -0000 Hello! For those of you who have not reviewed/commented on a draft, this would be = an easy one to get your feet wet. Feedback could be on grammar, whether th= e template is sufficient to provide enough information for developers using= specifications for extensions following this specification, or any other n= its or positive comments you have on the draft. Thanks, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Wednesday, February 01, 2012 7:34 AM To: trammell@tik.ee.ethz.ch Cc: mile@ietf.org Subject: [mile] Working group last call on Template draft Hello, We are starting a 2 week review period, the working group last call (WGLC) = for draft-ietf-mile-template. Please review and comment to the MILE list on= the template draft. =20 This is a short one and is used to provide a template for all extensions de= fined in MILE. http://tools.ietf.org/html/draft-ietf-mile-template-00 Last call on comments will end the morning of February 15th. Thank you, Kathleen (as WG chair) -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Wednesday, February 01, 2012 5:41 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: next up: mile-template Hi, Kathleen, all, Now that the WG work on 6045-bis and 6046-bis is complete, and (almost) in = accordance with the charter, I believe the present revision of draft-ietf-m= ile-template to be ready for WGLC. Many thanks, best regards, Brian Trammell (as author of mile-template) _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Tue Feb 7 02:44:45 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D8621F86D8 for ; Tue, 7 Feb 2012 02:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 LfLuAY+89CTm for ; Tue, 7 Feb 2012 02:44:44 -0800 (PST) Received: from mow.securemx.jp (mow300.securemx.jp [210.130.202.48]) by ietfa.amsl.com (Postfix) with ESMTP id A269421F869F for ; Tue, 7 Feb 2012 02:44:44 -0800 (PST) Received: by mow.securemx.jp (mow300) id q17AibsQ022647; Tue, 7 Feb 2012 19:44:37 +0900 X-MXL-Hash: 4f3100942fac36c4-49d15e0430a7c0a56799528362e769649d793480 Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by relay.securemx.jp (mx-mr303) id q17AiZBF027210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 19:44:36 +0900 Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q17AiZdT028342; Tue, 7 Feb 2012 19:44:35 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q17AiZCt017178; Tue, 7 Feb 2012 19:44:35 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q17AiZJR017175; Tue, 7 Feb 2012 19:44:35 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 0259016B2D; Tue, 7 Feb 2012 19:44:35 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail3.nict.go.jp (NICT Mail) with ESMTP id F08FD16AC8; Tue, 7 Feb 2012 19:44:34 +0900 (JST) From: "Takeshi Takahashi" To: , References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> In-Reply-To: Date: Tue, 7 Feb 2012 19:44:35 +0900 Message-ID: <003a01cce585$7be46b00$73ad4100$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUUY1TOXQ6R22bSCLcbwhWlXWyPAI0Fk0TAagV6HCXg4NIgA== Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:44:45 -0000 Hello Brian, The template was very useful for me to prepare an initial version of the SCI draft. Thank you. Let me post one comment on the document template, especially on its Appendix A: Though I do not have any strong opinion, I felt that the "5. Examples" could be put in the appendix II since I think the examples are supplementary information. I mean, appendix I is for schema while appendix II is for example. (RFC 5901 actually puts the examples in the appendix II.) Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > kathleen.moriarty@emc.com > Sent: Tuesday, February 07, 2012 5:01 AM > To: kathleen.moriarty@emc.com; trammell@tik.ee.ethz.ch > Cc: mile@ietf.org > Subject: Re: [mile] Working group last call on Template draft > > Hello! > > For those of you who have not reviewed/commented on a draft, this would > be an easy one to get your feet wet. Feedback could be on grammar, whether > the template is sufficient to provide enough information for developers > using specifications for extensions following this specification, or any > other nits or positive comments you have on the draft. > > Thanks, > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > kathleen.moriarty@emc.com > Sent: Wednesday, February 01, 2012 7:34 AM > To: trammell@tik.ee.ethz.ch > Cc: mile@ietf.org > Subject: [mile] Working group last call on Template draft > > Hello, > > We are starting a 2 week review period, the working group last call (WGLC) > for draft-ietf-mile-template. Please review and comment to the MILE list > on the template draft. > > This is a short one and is used to provide a template for all extensions > defined in MILE. > > http://tools.ietf.org/html/draft-ietf-mile-template-00 > > Last call on comments will end the morning of February 15th. > > Thank you, > Kathleen (as WG chair) > > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, February 01, 2012 5:41 AM > To: Moriarty, Kathleen > Cc: mile@ietf.org > Subject: next up: mile-template > > Hi, Kathleen, all, > > Now that the WG work on 6045-bis and 6046-bis is complete, and (almost) > in accordance with the charter, I believe the present revision of > draft-ietf-mile-template to be ready for WGLC. > > Many thanks, best regards, > > Brian Trammell (as author of mile-template) > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Feb 7 04:27:09 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6EF21F8764 for ; Tue, 7 Feb 2012 04:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 i57Gw1EivMyy for ; Tue, 7 Feb 2012 04:27:08 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1357221F8762 for ; Tue, 7 Feb 2012 04:27:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EC83ED930A; Tue, 7 Feb 2012 13:27:00 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pSx23Py1ne6P; Tue, 7 Feb 2012 13:27:00 +0100 (MET) Received: from [10.152.79.188] (unknown [213.55.184.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 92BF4D9305; Tue, 7 Feb 2012 13:27:00 +0100 (MET) References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> <003a01cce585$7be46b00$73ad4100$@nict.go.jp> In-Reply-To: <003a01cce585$7be46b00$73ad4100$@nict.go.jp> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6DC019E3-EF8E-4607-BA6A-13833DCECD8B@tik.ee.ethz.ch> X-Mailer: iPhone Mail (9A405) From: Brian Trammell Date: Tue, 7 Feb 2012 13:26:55 +0100 To: Takeshi Takahashi Cc: "" Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 12:27:09 -0000 Hi, Take, Thanks for your comment!=20 You're right, the examples belong in an appendix. When the doc template move= d down, I didn't think to move the element examples as well. I'll make this change in an -01 after the last call. Cheers, Brian (as author) Sent from my iPhone On 07.02.2012, at 11:44, "Takeshi Takahashi" w= rote: > Hello Brian, >=20 > The template was very useful for me to prepare an initial version of the S= CI > draft. Thank you. >=20 > Let me post one comment on the document template, especially on its Append= ix > A: >=20 > Though I do not have any strong opinion, I felt that the "5. Examples" cou= ld > be put in the appendix II since I think the examples are supplementary > information. > I mean, appendix I is for schema while appendix II is for example. > (RFC 5901 actually puts the examples in the appendix II.) >=20 > Thank you. > Take >=20 >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >> kathleen.moriarty@emc.com >> Sent: Tuesday, February 07, 2012 5:01 AM >> To: kathleen.moriarty@emc.com; trammell@tik.ee.ethz.ch >> Cc: mile@ietf.org >> Subject: Re: [mile] Working group last call on Template draft >>=20 >> Hello! >>=20 >> For those of you who have not reviewed/commented on a draft, this would >> be an easy one to get your feet wet. Feedback could be on grammar, > whether >> the template is sufficient to provide enough information for developers >> using specifications for extensions following this specification, or any >> other nits or positive comments you have on the draft. >>=20 >> Thanks, >> Kathleen >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >> kathleen.moriarty@emc.com >> Sent: Wednesday, February 01, 2012 7:34 AM >> To: trammell@tik.ee.ethz.ch >> Cc: mile@ietf.org >> Subject: [mile] Working group last call on Template draft >>=20 >> Hello, >>=20 >> We are starting a 2 week review period, the working group last call (WGLC= ) >> for draft-ietf-mile-template. Please review and comment to the MILE list >> on the template draft. >>=20 >> This is a short one and is used to provide a template for all extensions >> defined in MILE. >>=20 >> http://tools.ietf.org/html/draft-ietf-mile-template-00 >>=20 >> Last call on comments will end the morning of February 15th. >>=20 >> Thank you, >> Kathleen (as WG chair) >>=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Wednesday, February 01, 2012 5:41 AM >> To: Moriarty, Kathleen >> Cc: mile@ietf.org >> Subject: next up: mile-template >>=20 >> Hi, Kathleen, all, >>=20 >> Now that the WG work on 6045-bis and 6046-bis is complete, and (almost) >> in accordance with the charter, I believe the present revision of >> draft-ietf-mile-template to be ready for WGLC. >>=20 >> Many thanks, best regards, >>=20 >> Brian Trammell (as author of mile-template) >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Feb 7 05:29:04 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45FB21F8723 for ; Tue, 7 Feb 2012 05:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ys8thR6Kw9ku for ; Tue, 7 Feb 2012 05:29:04 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0C21F870E for ; Tue, 7 Feb 2012 05:29:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 276FED9308; Tue, 7 Feb 2012 14:29:03 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id D476IX1uhaHx; Tue, 7 Feb 2012 14:29:02 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D738CD9307; Tue, 7 Feb 2012 14:29:02 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <6DC019E3-EF8E-4607-BA6A-13833DCECD8B@tik.ee.ethz.ch> Date: Tue, 7 Feb 2012 14:29:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44866635-7A7A-4539-AB90-08B06023170E@tik.ee.ethz.ch> References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> <003a01cce585$7be46b00$73ad4100$@nict.go.jp> <6DC019E3-EF8E-4607-BA6A-13833DCECD8B@tik.ee.ethz.ch> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:29:05 -0000 Hi, Take, all, Actually, on further consideration (and not on a bus), I think the best = way to handle this would be to put _each_ of these in their own = appendix, as follows: Appendix A. Document Template . . . . . . . . . . . . . . . . . . 7 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 A.4. Extension Definition . . . . . . . . . . . . . . . . . . . 8 A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 9 A.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.6. Security Considerations . . . . . . . . . . . . . . . . . 10 A.7. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 A.8. Appendix: XML Schema Definition for Extension . . . . . . 11 Appendix B. Example Enumerated Type Extension Definition: E.164 Address . . . . . . . . . . . . . . . . . . . . 11 Appendix C. Example Element Definition: Test . . . . . . . . . . 11 Cheers, Brian (as author) On Feb 7, 2012, at 1:26 PM, Brian Trammell wrote: > Hi, Take, >=20 > Thanks for your comment!=20 >=20 > You're right, the examples belong in an appendix. When the doc = template moved down, I didn't think to move the element examples as = well. >=20 > I'll make this change in an -01 after the last call. >=20 > Cheers, Brian (as author) >=20 > Sent from my iPhone >=20 > On 07.02.2012, at 11:44, "Takeshi Takahashi" = wrote: >=20 >> Hello Brian, >>=20 >> The template was very useful for me to prepare an initial version of = the SCI >> draft. Thank you. >>=20 >> Let me post one comment on the document template, especially on its = Appendix >> A: >>=20 >> Though I do not have any strong opinion, I felt that the "5. = Examples" could >> be put in the appendix II since I think the examples are = supplementary >> information. >> I mean, appendix I is for schema while appendix II is for example. >> (RFC 5901 actually puts the examples in the appendix II.) >>=20 >> Thank you. >> Take >>=20 >>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >>> kathleen.moriarty@emc.com >>> Sent: Tuesday, February 07, 2012 5:01 AM >>> To: kathleen.moriarty@emc.com; trammell@tik.ee.ethz.ch >>> Cc: mile@ietf.org >>> Subject: Re: [mile] Working group last call on Template draft >>>=20 >>> Hello! >>>=20 >>> For those of you who have not reviewed/commented on a draft, this = would >>> be an easy one to get your feet wet. Feedback could be on grammar, >> whether >>> the template is sufficient to provide enough information for = developers >>> using specifications for extensions following this specification, or = any >>> other nits or positive comments you have on the draft. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >>> kathleen.moriarty@emc.com >>> Sent: Wednesday, February 01, 2012 7:34 AM >>> To: trammell@tik.ee.ethz.ch >>> Cc: mile@ietf.org >>> Subject: [mile] Working group last call on Template draft >>>=20 >>> Hello, >>>=20 >>> We are starting a 2 week review period, the working group last call = (WGLC) >>> for draft-ietf-mile-template. Please review and comment to the MILE = list >>> on the template draft. >>>=20 >>> This is a short one and is used to provide a template for all = extensions >>> defined in MILE. >>>=20 >>> http://tools.ietf.org/html/draft-ietf-mile-template-00 >>>=20 >>> Last call on comments will end the morning of February 15th. >>>=20 >>> Thank you, >>> Kathleen (as WG chair) >>>=20 >>> -----Original Message----- >>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>> Sent: Wednesday, February 01, 2012 5:41 AM >>> To: Moriarty, Kathleen >>> Cc: mile@ietf.org >>> Subject: next up: mile-template >>>=20 >>> Hi, Kathleen, all, >>>=20 >>> Now that the WG work on 6045-bis and 6046-bis is complete, and = (almost) >>> in accordance with the charter, I believe the present revision of >>> draft-ietf-mile-template to be ready for WGLC. >>>=20 >>> Many thanks, best regards, >>>=20 >>> Brian Trammell (as author of mile-template) >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Tue Feb 7 06:28:27 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3E21F85A0 for ; Tue, 7 Feb 2012 06:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 KUzJCjTybTQO for ; Tue, 7 Feb 2012 06:28:26 -0800 (PST) Received: from mow.securemx.jp (mow300.securemx.jp [210.130.202.48]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE421F87C5 for ; Tue, 7 Feb 2012 06:28:25 -0800 (PST) Received: by mow.securemx.jp (mow300) id q17ESODM024441; Tue, 7 Feb 2012 23:28:25 +0900 X-MXL-Hash: 4f313508510c8b3d-5f46900854f987a87edb7a3f1aa305a5f48b2419 Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by relay.securemx.jp (mx-mr300) id q17ESNWu010152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 23:28:24 +0900 Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q17ESNNa011332; Tue, 7 Feb 2012 23:28:23 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q17ESNBD017901; Tue, 7 Feb 2012 23:28:23 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q17ESNMM017898; Tue, 7 Feb 2012 23:28:23 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 258412C168; Tue, 7 Feb 2012 23:28:23 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 1E91116BBE; Tue, 7 Feb 2012 23:28:23 +0900 (JST) From: "Takeshi Takahashi" To: "'Brian Trammell'" References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> <003a01cce585$7be46b00$73ad4100$@nict.go.jp> <6DC019E3-EF8E-4607-BA6A-13833DCECD8B@tik.ee.ethz.ch> <44866635-7A7A-4539-AB90-08B06023170E@tik.ee.ethz.ch> In-Reply-To: <44866635-7A7A-4539-AB90-08B06023170E@tik.ee.ethz.ch> Date: Tue, 7 Feb 2012 23:28:23 +0900 Message-ID: <000601cce5a4$bf7a6ad0$3e6f4070$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUUY1TOXQ6R22bSCLcbwhWlXWyPAI0Fk0TAagV6HACCk5uqQGbnXIhAX3PWUGXWqJHkA== Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:28:27 -0000 Hi Brian, That looks nice to me. I like the revision. On the other hand, I actually wanted to say, "A.5. Examples", which describes IODEF-Document examples, could be moved to Appendix (A.8 Appendiix II). So, the agenda could be as below, but I am also fine with the current one. Appendix A. Document Template . . . . . . . . . . . . . . . . . . 7 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 A.4. Extension Definition . . . . . . . . . . . . . . . . . . . 8 A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 9 A.5. Security Considerations . . . . . . . . . . . . . . . . .xx A.6. IANA Considerations . . . . . . . . . . . . . . . . . . . xx A.7. Appendix I: XML Schema Definition for Extension . . . . . xx A.8. Appendix II: Examples . . . . . . . . . . . . . . . . . . .xx Appendix B. Example Enumerated Type Extension Definition: E.164 Address . . . . . . . . . . . . . . . . . . . . 11 Appendix C. Example Element Definition: Test . . . . . . . . . . 11 I just thought this way could align with the structure of RFC 5901 (phishing extension document), but I am also fine with the current one. Thank you. Take > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Tuesday, February 07, 2012 10:29 PM > To: Takeshi Takahashi > Cc: > Subject: Re: [mile] Working group last call on Template draft > > Hi, Take, all, > > Actually, on further consideration (and not on a bus), I think the best > way to handle this would be to put _each_ of these in their own appendix, > as follows: > > Appendix A. Document Template . . . . . . . . . . . . . . . . . . > 7 > A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . > 7 > A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . > 7 > A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . > 8 > A.4. Extension Definition . . . . . . . . . . . . . . . . . . . > 8 > A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . > 9 > A.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . > 10 > A.6. Security Considerations . . . . . . . . . . . . . . . . . > 10 > A.7. IANA Considerations . . . . . . . . . . . . . . . . . . . > 10 > A.8. Appendix: XML Schema Definition for Extension . . . . . . > 11 > Appendix B. Example Enumerated Type Extension Definition: > E.164 Address . . . . . . . . . . . . . . . . . . . . > 11 > Appendix C. Example Element Definition: Test . . . . . . . . . . > 11 > > Cheers, > > Brian (as author) > > On Feb 7, 2012, at 1:26 PM, Brian Trammell wrote: > > > Hi, Take, > > > > Thanks for your comment! > > > > You're right, the examples belong in an appendix. When the doc template > moved down, I didn't think to move the element examples as well. > > > > I'll make this change in an -01 after the last call. > > > > Cheers, Brian (as author) > > > > Sent from my iPhone > > > > On 07.02.2012, at 11:44, "Takeshi Takahashi" > wrote: > > > >> Hello Brian, > >> > >> The template was very useful for me to prepare an initial version of > >> the SCI draft. Thank you. > >> > >> Let me post one comment on the document template, especially on its > >> Appendix > >> A: > >> > >> Though I do not have any strong opinion, I felt that the "5. > >> Examples" could be put in the appendix II since I think the examples > >> are supplementary information. > >> I mean, appendix I is for schema while appendix II is for example. > >> (RFC 5901 actually puts the examples in the appendix II.) > >> > >> Thank you. > >> Take > >> > >> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > Behalf > >>> Of kathleen.moriarty@emc.com > >>> Sent: Tuesday, February 07, 2012 5:01 AM > >>> To: kathleen.moriarty@emc.com; trammell@tik.ee.ethz.ch > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] Working group last call on Template draft > >>> > >>> Hello! > >>> > >>> For those of you who have not reviewed/commented on a draft, this > >>> would be an easy one to get your feet wet. Feedback could be on > >>> grammar, > >> whether > >>> the template is sufficient to provide enough information for > >>> developers using specifications for extensions following this > >>> specification, or any other nits or positive comments you have on > the draft. > >>> > >>> Thanks, > >>> Kathleen > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > Behalf > >>> Of kathleen.moriarty@emc.com > >>> Sent: Wednesday, February 01, 2012 7:34 AM > >>> To: trammell@tik.ee.ethz.ch > >>> Cc: mile@ietf.org > >>> Subject: [mile] Working group last call on Template draft > >>> > >>> Hello, > >>> > >>> We are starting a 2 week review period, the working group last call > >>> (WGLC) for draft-ietf-mile-template. Please review and comment to > >>> the MILE list on the template draft. > >>> > >>> This is a short one and is used to provide a template for all > >>> extensions defined in MILE. > >>> > >>> http://tools.ietf.org/html/draft-ietf-mile-template-00 > >>> > >>> Last call on comments will end the morning of February 15th. > >>> > >>> Thank you, > >>> Kathleen (as WG chair) > >>> > >>> -----Original Message----- > >>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > >>> Sent: Wednesday, February 01, 2012 5:41 AM > >>> To: Moriarty, Kathleen > >>> Cc: mile@ietf.org > >>> Subject: next up: mile-template > >>> > >>> Hi, Kathleen, all, > >>> > >>> Now that the WG work on 6045-bis and 6046-bis is complete, and > >>> (almost) in accordance with the charter, I believe the present > >>> revision of draft-ietf-mile-template to be ready for WGLC. > >>> > >>> Many thanks, best regards, > >>> > >>> Brian Trammell (as author of mile-template) > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Feb 7 06:36:36 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E026F21F87D5 for ; Tue, 7 Feb 2012 06:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Vc3MInY0MlsX for ; Tue, 7 Feb 2012 06:36:36 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7421F87D3 for ; Tue, 7 Feb 2012 06:36:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9D4B8D9308; Tue, 7 Feb 2012 15:36:28 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id l1xgeFbQboJB; Tue, 7 Feb 2012 15:36:28 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5FAA6D9305; Tue, 7 Feb 2012 15:36:28 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <000601cce5a4$bf7a6ad0$3e6f4070$@nict.go.jp> Date: Tue, 7 Feb 2012 15:36:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> <003a01cce585$7be46b00$73ad4100$@nict.go.jp> <6DC019E3-EF8E-4607-BA6A-13833DCECD8B@tik.ee.ethz.ch> <44866635-7A7A-4539-AB90-08B06023170E@tik.ee.ethz.ch> <000601cce5a4$bf7a6ad0$3e6f4070$@nict.go.jp> To: "Takeshi Takahashi" X-Mailer: Apple Mail (2.1251.1) Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:36:37 -0000 Hi, Take, Ahhh... okay, I understand now, and, yes, that makes sense, too. I'll do = that as well. Cheers, Brian On Feb 7, 2012, at 3:28 PM, Takeshi Takahashi wrote: > Hi Brian, >=20 > That looks nice to me. I like the revision. >=20 > On the other hand, I actually wanted to say, "A.5. Examples", which > describes IODEF-Document examples, could be moved to Appendix (A.8 = Appendiix > II). > So, the agenda could be as below, but I am also fine with the current = one. >=20 > Appendix A. Document Template . . . . . . . . . . . . . . . . . . 7 > A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . = 7 > A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . = 7 > A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . = 8 > A.4. Extension Definition . . . . . . . . . . . . . . . . . . . = 8 > A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . = 9 > A.5. Security Considerations . . . . . . . . . . . . . . . . .xx > A.6. IANA Considerations . . . . . . . . . . . . . . . . . . . = xx > A.7. Appendix I: XML Schema Definition for Extension . . . . . = xx > A.8. Appendix II: Examples . . . . . . . . . . . . . . . . . . = .xx > Appendix B. Example Enumerated Type Extension Definition: > E.164 Address . . . . . . . . . . . . . . . . . . . . = 11 > Appendix C. Example Element Definition: Test . . . . . . . . . . 11 >=20 > I just thought this way could align with the structure of RFC 5901 = (phishing > extension document), but I am also fine with the current one. >=20 > Thank you. > Take >=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Tuesday, February 07, 2012 10:29 PM >> To: Takeshi Takahashi >> Cc: >> Subject: Re: [mile] Working group last call on Template draft >>=20 >> Hi, Take, all, >>=20 >> Actually, on further consideration (and not on a bus), I think the = best >> way to handle this would be to put _each_ of these in their own = appendix, >> as follows: >>=20 >> Appendix A. Document Template . . . . . . . . . . . . . . . . . . >> 7 >> A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . >> 7 >> A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . >> 7 >> A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . >> 8 >> A.4. Extension Definition . . . . . . . . . . . . . . . . . . . >> 8 >> A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . >> 9 >> A.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . >> 10 >> A.6. Security Considerations . . . . . . . . . . . . . . . . . >> 10 >> A.7. IANA Considerations . . . . . . . . . . . . . . . . . . . >> 10 >> A.8. Appendix: XML Schema Definition for Extension . . . . . . >> 11 >> Appendix B. Example Enumerated Type Extension Definition: >> E.164 Address . . . . . . . . . . . . . . . . . . . . >> 11 >> Appendix C. Example Element Definition: Test . . . . . . . . . . >> 11 >>=20 >> Cheers, >>=20 >> Brian (as author) >>=20 >> On Feb 7, 2012, at 1:26 PM, Brian Trammell wrote: >>=20 >>> Hi, Take, >>>=20 >>> Thanks for your comment! >>>=20 >>> You're right, the examples belong in an appendix. When the doc = template >> moved down, I didn't think to move the element examples as well. >>>=20 >>> I'll make this change in an -01 after the last call. >>>=20 >>> Cheers, Brian (as author) >>>=20 >>> Sent from my iPhone >>>=20 >>> On 07.02.2012, at 11:44, "Takeshi Takahashi" >> wrote: >>>=20 >>>> Hello Brian, >>>>=20 >>>> The template was very useful for me to prepare an initial version = of >>>> the SCI draft. Thank you. >>>>=20 >>>> Let me post one comment on the document template, especially on its >>>> Appendix >>>> A: >>>>=20 >>>> Though I do not have any strong opinion, I felt that the "5. >>>> Examples" could be put in the appendix II since I think the = examples >>>> are supplementary information. >>>> I mean, appendix I is for schema while appendix II is for example. >>>> (RFC 5901 actually puts the examples in the appendix II.) >>>>=20 >>>> Thank you. >>>> Take >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >> Behalf >>>>> Of kathleen.moriarty@emc.com >>>>> Sent: Tuesday, February 07, 2012 5:01 AM >>>>> To: kathleen.moriarty@emc.com; trammell@tik.ee.ethz.ch >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] Working group last call on Template draft >>>>>=20 >>>>> Hello! >>>>>=20 >>>>> For those of you who have not reviewed/commented on a draft, this >>>>> would be an easy one to get your feet wet. Feedback could be on >>>>> grammar, >>>> whether >>>>> the template is sufficient to provide enough information for >>>>> developers using specifications for extensions following this >>>>> specification, or any other nits or positive comments you have on >> the draft. >>>>>=20 >>>>> Thanks, >>>>> Kathleen >>>>>=20 >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >> Behalf >>>>> Of kathleen.moriarty@emc.com >>>>> Sent: Wednesday, February 01, 2012 7:34 AM >>>>> To: trammell@tik.ee.ethz.ch >>>>> Cc: mile@ietf.org >>>>> Subject: [mile] Working group last call on Template draft >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> We are starting a 2 week review period, the working group last = call >>>>> (WGLC) for draft-ietf-mile-template. Please review and comment to >>>>> the MILE list on the template draft. >>>>>=20 >>>>> This is a short one and is used to provide a template for all >>>>> extensions defined in MILE. >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-mile-template-00 >>>>>=20 >>>>> Last call on comments will end the morning of February 15th. >>>>>=20 >>>>> Thank you, >>>>> Kathleen (as WG chair) >>>>>=20 >>>>> -----Original Message----- >>>>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>>>> Sent: Wednesday, February 01, 2012 5:41 AM >>>>> To: Moriarty, Kathleen >>>>> Cc: mile@ietf.org >>>>> Subject: next up: mile-template >>>>>=20 >>>>> Hi, Kathleen, all, >>>>>=20 >>>>> Now that the WG work on 6045-bis and 6046-bis is complete, and >>>>> (almost) in accordance with the charter, I believe the present >>>>> revision of draft-ietf-mile-template to be ready for WGLC. >>>>>=20 >>>>> Many thanks, best regards, >>>>>=20 >>>>> Brian Trammell (as author of mile-template) >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>=20 >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile From turners@ieca.com Thu Feb 9 12:40:19 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8D711E808F for ; Thu, 9 Feb 2012 12:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_20=-0.74, 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 5-xjj1dqYFVM for ; Thu, 9 Feb 2012 12:40:18 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.224.20]) by ietfa.amsl.com (Postfix) with ESMTP id 31AB311E8072 for ; Thu, 9 Feb 2012 12:40:18 -0800 (PST) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id CF6CA5B769A57; Thu, 9 Feb 2012 14:40:16 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id B278E5B7699A4 for ; Thu, 9 Feb 2012 14:40:16 -0600 (CST) Received: from [198.180.150.234] (port=63932 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rvamt-0001OL-T8; Thu, 09 Feb 2012 14:40:16 -0600 Message-ID: <4F342F2E.3040607@ieca.com> Date: Thu, 09 Feb 2012 12:40:14 -0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: mile@ietf.org 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: v234.vpn.iad.rg.net (thunderfish.local) [198.180.150.234]:63932 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: sec-ads@tools.ietf.org Subject: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 20:40:19 -0000 Hi all, I realize that the MITRE specifications are now normative references as a result of a question I asked. They are properly marked as normative. NOTE: This issue has nothing to do with the contents of the mile draft or the text in the MITRE references. It only has to do with the TOU (Terms of Use) of the MITRE references. I've reviewed the TOU for the 17 MITRE specifications, which are normative references in draft-ietf-mile-sci. I firmly believe that it will not be possible to achieve IETF consensus with normative references to such documents in a standards-track RFC. The TOU include: You use [insert doc title here] on the condition that you indemnify and hold harmless MITRE, its Board of Trustees, officers, agents, and employees, from any and all liability or damages to yourself or your hardware or software, or third parties, including attorneys' fees, court costs, and other related costs and expenses, arising out of your use of [insert doc title here] irrespective of the cause of said liability. I also don't think that an Expert should accept the TOUs during their review of an IANA registration request - regardless of whether the draft/RFC containing the registry is bound for informational/standards track. In fact, I'd advise them not to accept the registration request if the reference had this type of TOU. This effective stops this draft dead in its tracks until we resolve what types/kinds of Structured Cybersecurity Information it will support. spt From tony@yaanatech.com Thu Feb 9 15:05:11 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D99A11E8095 for ; Thu, 9 Feb 2012 15:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] 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 tY0Q2BqFxkLK for ; Thu, 9 Feb 2012 15:05:10 -0800 (PST) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id BBD4711E808A for ; Thu, 9 Feb 2012 15:05:09 -0800 (PST) Received: from [192.168.0.4] (pool-173-72-136-146.clppva.fios.verizon.net [173.72.136.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 49AD558053; Thu, 9 Feb 2012 23:05:09 +0000 (UTC) Message-ID: <4F345124.5000707@yaanatech.com> Date: Thu, 09 Feb 2012 18:05:08 -0500 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0) Gecko/20110929 Thunderbird/7.0 MIME-Version: 1.0 To: turners@ieca.com References: <4F342F2E.3040607@ieca.com> In-Reply-To: <4F342F2E.3040607@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mile@ietf.org, sec-ads@tools.ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:05:11 -0000 Hi Sean, I fail to understand the reaction here. This is a simple, straightforward indemnification provision that any major contributing organization's counsel would insist upon. It has no apparent collateral adverse effects on anyone. Indeed, as a person who set up some of the protective mechanisms for ISOC and the IETF about 20 years ago, this is consonant with what ISOC and the IETF likely maintain to the outside world themselves. (The current indemnification provisions seem buried somewhere.) What is particularly mystifying is the last sentence of your email that seems rather over-the-top and totally disconnected from the indemnification provisions. Is there something I'm missing? --tony On 2/9/2012 3:40 PM, Sean Turner wrote: > NOTE: This issue has nothing to do with the contents of the mile draft > or the text in the MITRE references. It only has to do with the TOU > (Terms of Use) of the MITRE references. > > I've reviewed the TOU for the 17 MITRE specifications, which are > normative references in draft-ietf-mile-sci. I firmly believe that it > will not be possible to achieve IETF consensus with normative > references to such documents in a standards-track RFC. The TOU include: > > You use [insert doc title here] on the condition that you > indemnify and hold harmless MITRE, its Board of Trustees, > officers, agents, and employees, from any and all liability > or damages to yourself or your hardware or software, or third > parties, including attorneys' fees, court costs, and other > related costs and expenses, arising out of your use of > [insert doc title here] irrespective of the cause of said > liability. > > I also don't think that an Expert should accept the TOUs during their > review of an IANA registration request - regardless of whether the > draft/RFC containing the registry is bound for informational/standards > track. In fact, I'd advise them not to accept the registration > request if the reference had this type of TOU. > > This effective stops this draft dead in its tracks until we resolve > what types/kinds of Structured Cybersecurity Information it will support. From trammell@tik.ee.ethz.ch Fri Feb 10 03:20:43 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD74621F86E8 for ; Fri, 10 Feb 2012 03:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uibk+m+nxlde for ; Fri, 10 Feb 2012 03:20:43 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0B21F85CD for ; Fri, 10 Feb 2012 03:20:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 361CBD9307; Fri, 10 Feb 2012 12:20:39 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RoJFPepruSGK; Fri, 10 Feb 2012 12:20:39 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id EDB85D9300; Fri, 10 Feb 2012 12:20:38 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell In-Reply-To: <4F345124.5000707@yaanatech.com> Date: Fri, 10 Feb 2012 12:20:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> References: <4F342F2E.3040607@ieca.com> <4F345124.5000707@yaanatech.com> To: tony@yaanatech.com X-Mailer: Apple Mail (2.1251.1) Cc: mile@ietf.org, sec-ads@tools.ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 11:20:44 -0000 Hi, Tony, all, IANAL, but all I can find that's current and looks like indemnity is = section 7(a) of the IETF Trust Legal Provisions (rev. 4.0 of 28 December = 2009, http://trustee.ietf.org/license-info/) (sorry for the yelling, = this is a straight copy-paste): ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN = =93AS IS=94 BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF = TRUST, THE INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS = OF ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM = ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY = WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY = RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A = PARTICULAR PURPOSE. The MITRE indemnity clause looks a quite a bit stronger to me than the = no-warranty clause (again, merely as a native speaker of non-lawyer = English), even though I could be convinced that the basic intention is = the same. I could also be convinced that there is enough of a difference = here that they are fundamentally incompatible. The question for this = issue would them seem to be whether a disclaimer of warranty is the same = thing as an indemnification. If it isn't, one class of solutions would be to bring the referenced = MITRE specifications under a licensing regime that's compatible with the = Trust Legal Provisions. Best regards, Brian (as MILE contributor) On Feb 10, 2012, at 12:05 AM, Tony Rutkowski wrote: > Hi Sean, >=20 > I fail to understand the reaction here. This is a simple, > straightforward indemnification provision that any major > contributing organization's counsel would insist upon. > It has no apparent collateral adverse effects on anyone. > Indeed, as a person who set up some of the protective > mechanisms for ISOC and the IETF about 20 years ago, > this is consonant with what ISOC and the IETF likely > maintain to the outside world themselves. (The current > indemnification provisions seem buried somewhere.) >=20 > What is particularly mystifying is the last sentence of > your email that seems rather over-the-top and totally > disconnected from the indemnification provisions. >=20 > Is there something I'm missing? >=20 > --tony >=20 > On 2/9/2012 3:40 PM, Sean Turner wrote: >> NOTE: This issue has nothing to do with the contents of the mile = draft or the text in the MITRE references. It only has to do with the = TOU (Terms of Use) of the MITRE references. >>=20 >> I've reviewed the TOU for the 17 MITRE specifications, which are = normative references in draft-ietf-mile-sci. I firmly believe that it = will not be possible to achieve IETF consensus with normative references = to such documents in a standards-track RFC. The TOU include: >>=20 >> You use [insert doc title here] on the condition that you >> indemnify and hold harmless MITRE, its Board of Trustees, >> officers, agents, and employees, from any and all liability >> or damages to yourself or your hardware or software, or third >> parties, including attorneys' fees, court costs, and other >> related costs and expenses, arising out of your use of >> [insert doc title here] irrespective of the cause of said >> liability. >>=20 >> I also don't think that an Expert should accept the TOUs during their = review of an IANA registration request - regardless of whether the = draft/RFC containing the registry is bound for informational/standards = track. In fact, I'd advise them not to accept the registration request = if the reference had this type of TOU. >>=20 >> This effective stops this draft dead in its tracks until we resolve = what types/kinds of Structured Cybersecurity Information it will = support. >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From tony@yaanatech.com Fri Feb 10 04:39:28 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABA121F86EB for ; Fri, 10 Feb 2012 04:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 h7VsQz+HV1vl for ; Fri, 10 Feb 2012 04:39:28 -0800 (PST) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6FD21F86C2 for ; Fri, 10 Feb 2012 04:39:28 -0800 (PST) Received: from [192.168.0.4] (pool-173-72-136-146.clppva.fios.verizon.net [173.72.136.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id E218A58053; Fri, 10 Feb 2012 12:39:26 +0000 (UTC) Message-ID: <4F350FFD.3020503@yaanatech.com> Date: Fri, 10 Feb 2012 07:39:25 -0500 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0) Gecko/20110929 Thunderbird/7.0 MIME-Version: 1.0 To: trammell@tik.ee.ethz.ch References: <4F342F2E.3040607@ieca.com> <4F345124.5000707@yaanatech.com> <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> In-Reply-To: <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: mile@ietf.org, sec-ads@tools.ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:39:29 -0000 Hi Brian, Good research! At this point, MITRE might respond why its provisions need be stronger than those of the IETF/ISOC. Maybe they would be willing to use the same one. best, tony On 2/10/2012 6:20 AM, Brian Trammell wrote: > Hi, Tony, all, > > IANAL, but all I can find that's current and looks like indemnity is section 7(a) of the IETF Trust Legal Provisions (rev. 4.0 of 28 December 2009, http://trustee.ietf.org/license-info/) (sorry for the yelling, this is a straight copy-paste): > > ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN “AS IS” BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS OF ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > The MITRE indemnity clause looks a quite a bit stronger to me than the no-warranty clause (again, merely as a native speaker of non-lawyer English), even though I could be convinced that the basic intention is the same. I could also be convinced that there is enough of a difference here that they are fundamentally incompatible. The question for this issue would them seem to be whether a disclaimer of warranty is the same thing as an indemnification. > > If it isn't, one class of solutions would be to bring the referenced MITRE specifications under a licensing regime that's compatible with the Trust Legal Provisions. > > From turners@ieca.com Fri Feb 10 07:25:06 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8444221F86F2 for ; Fri, 10 Feb 2012 07:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 G-f8WzE-TAZR for ; Fri, 10 Feb 2012 07:25:06 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.239.22]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9C21F854E for ; Fri, 10 Feb 2012 07:25:05 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 7C56A764EF29C; Fri, 10 Feb 2012 09:25:04 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 709FA764EF274 for ; Fri, 10 Feb 2012 09:25:04 -0600 (CST) Received: from [198.180.150.234] (port=53709 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RvsLP-0000o3-KC; Fri, 10 Feb 2012 09:25:04 -0600 Message-ID: <4F3536CE.3040000@ieca.com> Date: Fri, 10 Feb 2012 07:25:02 -0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: tony@yaanatech.com References: <4F342F2E.3040607@ieca.com> <4F345124.5000707@yaanatech.com> <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> <4F350FFD.3020503@yaanatech.com> In-Reply-To: <4F350FFD.3020503@yaanatech.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: v234.vpn.iad.rg.net (thunderfish.local) [198.180.150.234]:53709 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org, sec-ads@tools.ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:25:06 -0000 Tony, It's the indemnification part that's the problem. The IETF does not ask for indemnification for the use of its standards. As Brian pointed out the IETF's TLP (Trust Legal Provisions) can be found in the Copyright Notice section: http://trustee.ietf.org/license-info/. Also note that this link can be found in the Copyright Notice section of every draft/RFC. I'm just providing some early steering for the WG. The term "dead in its tracks" is a little melodramatic and technically the WG can ignore my early steer. But, nobody should be surprised when there's a process delay between when the draft (with normative references to these documents with these TOU) is passed to me after making it through WG LC and when the IETF LC issued. The WG should consider the TOU now because I will definitely ask later that they be expressly considered. I see my email as tipping my hand early, but I feel I'd be doing a disservice to the WG by not speaking up as soon as I spotted the issue. You are quite correct that MITRE is free to stipulate whatever TOU they want, but the IETF is also free to not reference their specifications. Please don't get me wrong, I'd prefer to be able to reference what's already been developed. spt On 2/10/12 4:39 AM, Tony Rutkowski wrote: > Hi Brian, > > Good research! At this point, MITRE might respond why > its provisions need be stronger than those of the IETF/ISOC. > Maybe they would be willing to use the same one. > > best, > tony > > On 2/10/2012 6:20 AM, Brian Trammell wrote: >> Hi, Tony, all, >> >> IANAL, but all I can find that's current and looks like indemnity is >> section 7(a) of the IETF Trust Legal Provisions (rev. 4.0 of 28 >> December 2009, http://trustee.ietf.org/license-info/) (sorry for the >> yelling, this is a straight copy-paste): >> >> ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN >> “AS IS” BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE >> INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS OF >> ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM >> ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY >> WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY >> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >> PARTICULAR PURPOSE. >> >> The MITRE indemnity clause looks a quite a bit stronger to me than the >> no-warranty clause (again, merely as a native speaker of non-lawyer >> English), even though I could be convinced that the basic intention is >> the same. I could also be convinced that there is enough of a >> difference here that they are fundamentally incompatible. The question >> for this issue would them seem to be whether a disclaimer of warranty >> is the same thing as an indemnification. >> >> If it isn't, one class of solutions would be to bring the referenced >> MITRE specifications under a licensing regime that's compatible with >> the Trust Legal Provisions. >> >> > > From ramartin@mitre.org Fri Feb 10 07:40:23 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1F21F86FE for ; Fri, 10 Feb 2012 07:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 C7fO8R09p-Ij for ; Fri, 10 Feb 2012 07:40:22 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4EE21F86F4 for ; Fri, 10 Feb 2012 07:40:22 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7B63E21B0C61; Fri, 10 Feb 2012 10:40:21 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 608CB21B0C62; Fri, 10 Feb 2012 10:40:21 -0500 (EST) Received: from mm169528-pc.mitre.org (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server id 14.1.339.1; Fri, 10 Feb 2012 10:40:20 -0500 Message-ID: <4F353A64.7010409@mitre.org> Date: Fri, 10 Feb 2012 10:40:20 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: References: <4F342F2E.3040607@ieca.com> <4F345124.5000707@yaanatech.com> <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> <4F350FFD.3020503@yaanatech.com> In-Reply-To: <4F350FFD.3020503@yaanatech.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: mile@ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:40:23 -0000 Sean, We have had the current terms of use since we launched the Common=20 Vulnerabilities and Exposures (CVE) initiative in September of 1999 and=20 this is the first time to my knowledge that anyone has had issue with the= m. I will say that over 200 organizations from 26 countries have found=20 those terms acceptable and incorporated one or more of our=20 standardization efforts into their products or services. IANAL, but maybe the norm of these types of clauses has evolved over the = 12 years that these have been in place on our efforts and its time to=20 review them. Sean, if the terms were along the lines of those used by the IETF as=20 provided by Brian and suggested by Tony would that be in the right=20 direction? MITRE's work in this area is meant to help improve security practices=20 and capabilities and the terms were not meant to impede the uptake or=20 leveraging of this work in any manner, but as I mentioned, this is the=20 first time someone has raised an issue with them. Regards, Bob P.S. Also, so we are communicating clearly, what are the 17 items you=20 are referring to? My count is a bit lower. On 2/10/12 7:39 AM, Tony Rutkowski wrote: > Hi Brian, > > Good research! At this point, MITRE might respond why > its provisions need be stronger than those of the IETF/ISOC. > Maybe they would be willing to use the same one. > > best, > tony > > On 2/10/2012 6:20 AM, Brian Trammell wrote: >> Hi, Tony, all, >> >> IANAL, but all I can find that's current and looks like indemnity is >> section 7(a) of the IETF Trust Legal Provisions (rev. 4.0 of 28 >> December 2009, http://trustee.ietf.org/license-info/) (sorry for the >> yelling, this is a straight copy-paste): >> >> ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN= >> =93AS IS=94 BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESE= NTS >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE= >> INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS OF >> ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM >> ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY >> WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY= >> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >> PARTICULAR PURPOSE. >> >> The MITRE indemnity clause looks a quite a bit stronger to me than the= >> no-warranty clause (again, merely as a native speaker of non-lawyer >> English), even though I could be convinced that the basic intention is= >> the same. I could also be convinced that there is enough of a >> difference here that they are fundamentally incompatible. The question= >> for this issue would them seem to be whether a disclaimer of warranty >> is the same thing as an indemnification. >> >> If it isn't, one class of solutions would be to bring the referenced >> MITRE specifications under a licensing regime that's compatible with >> the Trust Legal Provisions. >> >> > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > From david.black@emc.com Fri Feb 10 12:04:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BFD21F8803 for ; Fri, 10 Feb 2012 12:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.447 X-Spam-Level: X-Spam-Status: No, score=-109.447 tagged_above=-999 required=5 tests=[AWL=1.152, 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 g64uf1Fr47KQ for ; Fri, 10 Feb 2012 12:04:22 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5821F87FA for ; Fri, 10 Feb 2012 12:04:21 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1AK4ERS026852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Feb 2012 15:04:16 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Fri, 10 Feb 2012 15:03:33 -0500 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1AK3Vlx031110 for ; Fri, 10 Feb 2012 15:03:32 -0500 Received: from mx14a.corp.emc.com ([169.254.1.94]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Fri, 10 Feb 2012 15:03:31 -0500 From: To: Date: Fri, 10 Feb 2012 15:03:30 -0500 Thread-Topic: Working group last call on Template draft Thread-Index: AczgzifD0S11HUnQQi2otfgXa8gokQADgttQAdQfGXA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD29CBCD@MX14A.corp.emc.com> References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 20:04:22 -0000 Brian, I have a few WGLC comments, but I should begin by saying that I do like the= result of combining the formerly separate template and iodef-xmlreg drafts= . In addition, the new guidance material that was added (sections 2 and 3)= looks good. Nice work! (1) Process nit: It may be necessary for this draft to be both a standards = track document and a BCP document in order for the registry update to respe= ct previously defined process. Rather than discuss this subtlety further h= ere, I suggest leaving that as a question for the Area Director to consider= during his review (Hi Sean). (2) Security Considerations. Section 4 should say that the security consid= erations for IODEF continue to apply to extensions and cite [RFC5070]. Sec= tion A.6 should advise that IODEF extension specifications do likewise. (3) IANA Considerations for extensions. I suggest adding a sentence or two= to Section A.7 to observe that an IODEF extension may define a new registr= y (or even registries) if that's appropriate, e.g., as the SCI draft is alr= eady doing. I would not cite the SCI draft as part of this, as such a refe= rence should be informative (not normative) and so won't be particularly us= eful if the template draft is published as an RFC fairly quickly - the RFC = Editor replaces filenames in informative references to Internet-Drafts with= "Work in Progress." Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From trammell@tik.ee.ethz.ch Mon Feb 13 03:35:07 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961F521F8599 for ; Mon, 13 Feb 2012 03:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7o7bI9xY-SAK for ; Mon, 13 Feb 2012 03:35:06 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1021F85DA for ; Mon, 13 Feb 2012 03:35:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 345CAD930A; Mon, 13 Feb 2012 12:34:59 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uWuvMNFOzH2o; Mon, 13 Feb 2012 12:34:59 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0B272D9300; Mon, 13 Feb 2012 12:34:59 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD29CBCD@MX14A.corp.emc.com> Date: Mon, 13 Feb 2012 12:34:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <516B100D-91EF-42D5-9179-943FE36DE711@tik.ee.ethz.ch> References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05AD29CBCD@MX14A.corp.emc.com> To: X-Mailer: Apple Mail (2.1251.1) Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 11:35:07 -0000 Hi, David, Thanks for your review and comments; have applied (2) and (3) to the -01 = working copy, and will await Sean's feedback on (1)... Cheers, Brian (as mile-template author) On Feb 10, 2012, at 9:03 PM, = wrote: > Brian, >=20 > I have a few WGLC comments, but I should begin by saying that I do = like the result of combining the formerly separate template and = iodef-xmlreg drafts. In addition, the new guidance material that was = added (sections 2 and 3) looks good. Nice work! >=20 > (1) Process nit: It may be necessary for this draft to be both a = standards track document and a BCP document in order for the registry = update to respect previously defined process. Rather than discuss this = subtlety further here, I suggest leaving that as a question for the Area = Director to consider during his review (Hi Sean). >=20 > (2) Security Considerations. Section 4 should say that the security = considerations for IODEF continue to apply to extensions and cite = [RFC5070]. Section A.6 should advise that IODEF extension = specifications do likewise. >=20 > (3) IANA Considerations for extensions. I suggest adding a sentence = or two to Section A.7 to observe that an IODEF extension may define a = new registry (or even registries) if that's appropriate, e.g., as the = SCI draft is already doing. I would not cite the SCI draft as part of = this, as such a reference should be informative (not normative) and so = won't be particularly useful if the template draft is published as an = RFC fairly quickly - the RFC Editor replaces filenames in informative = references to Internet-Drafts with "Work in Progress." >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From turners@ieca.com Mon Feb 13 06:34:26 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2200A21F8537 for ; Mon, 13 Feb 2012 06:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.132 X-Spam-Level: X-Spam-Status: No, score=-101.132 tagged_above=-999 required=5 tests=[AWL=-1.467, BAYES_50=0.001, 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 pD46YOLEHq+Z for ; Mon, 13 Feb 2012 06:34:25 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.1.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8E59821F8496 for ; Mon, 13 Feb 2012 06:34:25 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id B92CBD8421B40; Mon, 13 Feb 2012 08:34:24 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id AAF0CD8421B1C for ; Mon, 13 Feb 2012 08:34:24 -0600 (CST) Received: from [96.231.120.32] (port=33693 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rwwz2-0005x7-4n; Mon, 13 Feb 2012 08:34:24 -0600 Message-ID: <4F391F6F.50208@ieca.com> Date: Mon, 13 Feb 2012 09:34:23 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Martin, Robert A." References: <4F342F2E.3040607@ieca.com> <4F345124.5000707@yaanatech.com> <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> <4F350FFD.3020503@yaanatech.com> <4F353A64.7010409@mitre.org> In-Reply-To: <4F353A64.7010409@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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-96-231-120-32.washdc.east.verizon.net (thunderfish.local) [96.231.120.32]:33693 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org, sec-ads@tools.ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:34:26 -0000 On 2/10/12 10:40 AM, Martin, Robert A. wrote: > Sean, > > We have had the current terms of use since we launched the Common > Vulnerabilities and Exposures (CVE) initiative in September of 1999 and > this is the first time to my knowledge that anyone has had issue with them. > > I will say that over 200 organizations from 26 countries have found > those terms acceptable and incorporated one or more of our > standardization efforts into their products or services. > > IANAL, but maybe the norm of these types of clauses has evolved over the > 12 years that these have been in place on our efforts and its time to > review them. > > Sean, if the terms were along the lines of those used by the IETF as > provided by Brian and suggested by Tony would that be in the right > direction? It would help. > MITRE's work in this area is meant to help improve security practices > and capabilities and the terms were not meant to impede the uptake or > leveraging of this work in any manner, but as I mentioned, this is the > first time someone has raised an issue with them. > > Regards, > > Bob > > P.S. Also, so we are communicating clearly, what are the 17 items you > are referring to? My count is a bit lower. You're right the number is a bit lower - 7 I think. > On 2/10/12 7:39 AM, Tony Rutkowski wrote: >> Hi Brian, >> >> Good research! At this point, MITRE might respond why >> its provisions need be stronger than those of the IETF/ISOC. >> Maybe they would be willing to use the same one. >> >> best, >> tony >> >> On 2/10/2012 6:20 AM, Brian Trammell wrote: >>> Hi, Tony, all, >>> >>> IANAL, but all I can find that's current and looks like indemnity is >>> section 7(a) of the IETF Trust Legal Provisions (rev. 4.0 of 28 >>> December 2009, http://trustee.ietf.org/license-info/) (sorry for the >>> yelling, this is a straight copy-paste): >>> >>> ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN >>> “AS IS” BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS >>> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE >>> INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS OF >>> ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM >>> ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY >>> WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY >>> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >>> PARTICULAR PURPOSE. >>> >>> The MITRE indemnity clause looks a quite a bit stronger to me than the >>> no-warranty clause (again, merely as a native speaker of non-lawyer >>> English), even though I could be convinced that the basic intention is >>> the same. I could also be convinced that there is enough of a >>> difference here that they are fundamentally incompatible. The question >>> for this issue would them seem to be whether a disclaimer of warranty >>> is the same thing as an indemnification. >>> >>> If it isn't, one class of solutions would be to bring the referenced >>> MITRE specifications under a licensing regime that's compatible with >>> the Trust Legal Provisions. >>> >>> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> . >> > > > From ramartin@mitre.org Mon Feb 13 06:42:33 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38B121F84EA for ; Mon, 13 Feb 2012 06:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 d4m-+yV7gpnJ for ; Mon, 13 Feb 2012 06:42:32 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A8E8021F84E7 for ; Mon, 13 Feb 2012 06:42:32 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DA67621B0394; Mon, 13 Feb 2012 09:42:29 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BBA0E21B03E1; Mon, 13 Feb 2012 09:42:29 -0500 (EST) Received: from mm190558-pc.mitre.org (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server id 14.1.339.1; Mon, 13 Feb 2012 09:42:29 -0500 Message-ID: <4F392155.9000901@mitre.org> Date: Mon, 13 Feb 2012 09:42:29 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Sean Turner References: <4F342F2E.3040607@ieca.com> <4F345124.5000707@yaanatech.com> <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> <4F350FFD.3020503@yaanatech.com> <4F353A64.7010409@mitre.org> <4F391F6F.50208@ieca.com> In-Reply-To: <4F391F6F.50208@ieca.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: mile@ietf.org, sec-ads@tools.ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:42:34 -0000 Sean, While we have had many others agree to our current terms of use and so=20 are still unsure why this is an issue, in the spirit of cooperation and=20 our belief in the goals of structuring cybersecurity information, we=20 will accept the language of the IETF Trust Legal Provisions and revise=20 our terms of use to state the following: ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN=20 "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR = IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES,=20 OFFICERS, AGENTS, AND EMPLOYEES, DISCLAIM ALL WARRANTIES, EXPRESS OR=20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. If you can concur that this should address your concern regarding the=20 terms of use we will proceed to make the changes. Bob On 2/13/12 9:34 AM, Sean Turner wrote: > On 2/10/12 10:40 AM, Martin, Robert A. wrote: >> Sean, >> >> We have had the current terms of use since we launched the Common >> Vulnerabilities and Exposures (CVE) initiative in September of 1999 an= d >> this is the first time to my knowledge that anyone has had issue with >> them. >> >> I will say that over 200 organizations from 26 countries have found >> those terms acceptable and incorporated one or more of our >> standardization efforts into their products or services. >> >> IANAL, but maybe the norm of these types of clauses has evolved over t= he >> 12 years that these have been in place on our efforts and its time to >> review them. >> >> Sean, if the terms were along the lines of those used by the IETF as >> provided by Brian and suggested by Tony would that be in the right >> direction? > > It would help. > >> MITRE's work in this area is meant to help improve security practices >> and capabilities and the terms were not meant to impede the uptake or >> leveraging of this work in any manner, but as I mentioned, this is the= >> first time someone has raised an issue with them. >> >> Regards, >> >> Bob >> >> P.S. Also, so we are communicating clearly, what are the 17 items you >> are referring to? My count is a bit lower. > > You're right the number is a bit lower - 7 I think. > >> On 2/10/12 7:39 AM, Tony Rutkowski wrote: >>> Hi Brian, >>> >>> Good research! At this point, MITRE might respond why >>> its provisions need be stronger than those of the IETF/ISOC. >>> Maybe they would be willing to use the same one. >>> >>> best, >>> tony >>> >>> On 2/10/2012 6:20 AM, Brian Trammell wrote: >>>> Hi, Tony, all, >>>> >>>> IANAL, but all I can find that's current and looks like indemnity is= >>>> section 7(a) of the IETF Trust Legal Provisions (rev. 4.0 of 28 >>>> December 2009, http://trustee.ietf.org/license-info/) (sorry for the= >>>> yelling, this is a straight copy-paste): >>>> >>>> ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON = AN >>>> =93AS IS=94 BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRE= SENTS >>>> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, T= HE >>>> INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS OF >>>> ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM >>>> ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY= >>>> WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE A= NY >>>> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A= >>>> PARTICULAR PURPOSE. >>>> >>>> The MITRE indemnity clause looks a quite a bit stronger to me than t= he >>>> no-warranty clause (again, merely as a native speaker of non-lawyer >>>> English), even though I could be convinced that the basic intention = is >>>> the same. I could also be convinced that there is enough of a >>>> difference here that they are fundamentally incompatible. The questi= on >>>> for this issue would them seem to be whether a disclaimer of warrant= y >>>> is the same thing as an indemnification. >>>> >>>> If it isn't, one class of solutions would be to bring the referenced= >>>> MITRE specifications under a licensing regime that's compatible with= >>>> the Trust Legal Provisions. >>>> >>>> >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> . >>> >> >> >> > . > From david.waltermire@nist.gov Mon Feb 13 13:09:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F35221F8463 for ; Mon, 13 Feb 2012 13:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.978 X-Spam-Level: X-Spam-Status: No, score=-4.978 tagged_above=-999 required=5 tests=[AWL=-1.622, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] 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 duSJuIqlO0qN for ; Mon, 13 Feb 2012 13:09:21 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF6121F8484 for ; Mon, 13 Feb 2012 13:09:20 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 13 Feb 2012 16:09:16 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 13 Feb 2012 16:07:35 -0500 From: "Waltermire, David A." To: "mile@ietf.org" Date: Mon, 13 Feb 2012 16:09:17 -0500 Thread-Topic: Timeslot on the MILE WG Agenda for IETF 83 Thread-Index: Aczqk79fpTp3cLBzT0an1I/3SDNh8w== Message-ID: 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_D7A0423E5E193F40BE6E94126930C493090697ABD9MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [mile] Timeslot on the MILE WG Agenda for IETF 83 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:09:22 -0000 --_000_D7A0423E5E193F40BE6E94126930C493090697ABD9MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Kathleen et al, If possible, I'd like about 30 minutes on the MILE WG agenda at the next IETF meeting to discuss using the GRC Exchange approach as the core specification for orchestrating continuous monitoring solutions across various IT information domains. My presentation would cover use cases and concepts regarding interoperable, inter- and intra-organizational orchestration between various software components and services. Would this be of interest to the WG? Sincerely, Dave Waltermire --_000_D7A0423E5E193F40BE6E94126930C493090697ABD9MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ S2F0aGxlZW4gZXQgYWwsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JZiBwb3NzaWJsZSwgSSYjODIxNztkIGxp a2UgYWJvdXQgMzAgbWludXRlcyBvbiB0aGUgTUlMRSBXRyBhZ2VuZGEgYXQgdGhlIG5leHQgSUVU RiBtZWV0aW5nIHRvIGRpc2N1c3MgdXNpbmcgdGhlIEdSQyBFeGNoYW5nZSBhcHByb2FjaCBhcyB0 aGUgY29yZSBzcGVjaWZpY2F0aW9uIGZvciBvcmNoZXN0cmF0aW5nIGNvbnRpbnVvdXMgbW9uaXRv cmluZyBzb2x1dGlvbnMgYWNyb3NzIHZhcmlvdXMgSVQgaW5mb3JtYXRpb24gZG9tYWlucy4mbmJz cDsgTXkgcHJlc2VudGF0aW9uIHdvdWxkIGNvdmVyIHVzZSBjYXNlcyBhbmQgY29uY2VwdHMgcmVn YXJkaW5nIGludGVyb3BlcmFibGUsIGludGVyLSBhbmQgaW50cmEtb3JnYW5pemF0aW9uYWwgb3Jj aGVzdHJhdGlvbiBiZXR3ZWVuIHZhcmlvdXMgc29mdHdhcmUgY29tcG9uZW50cyBhbmQgc2Vydmlj ZXMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD5Xb3VsZCB0aGlzIGJlIG9mIGludGVyZXN0IHRvIHRoZSBXRz88 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPlNpbmNlcmVseSw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+RGF2ZSBXYWx0ZXJtaXJlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_D7A0423E5E193F40BE6E94126930C493090697ABD9MBCLUSTERxcha_-- From Thomas.Millar@us-cert.gov Mon Feb 13 13:41:50 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E439121E8039 for ; Mon, 13 Feb 2012 13:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, 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 kgmi3S6kzb2d for ; Mon, 13 Feb 2012 13:41:48 -0800 (PST) Received: from shaggy.brass.us-cert.gov (shaggy.brass.us-cert.gov [208.73.184.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD52B21E802A for ; Mon, 13 Feb 2012 13:41:47 -0800 (PST) Received: from shaggy.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id EEC10504C3; Mon, 13 Feb 2012 21:41:45 +0000 (UTC) Received: from dabba.bronze.us-cert.gov (dabba.bronze.us-cert.gov [192.168.16.121]) by shaggy.brass.us-cert.gov (Postfix) with ESMTP id D67F9504C2; Mon, 13 Feb 2012 21:41:45 +0000 (UTC) Received: from rubicon.bronze.us-cert.gov (rubicon.bronze.us-cert.gov [192.168.2.160]) by dabba.bronze.us-cert.gov (Postfix) with ESMTP id 9BC2A6E49D; Mon, 13 Feb 2012 21:41:45 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by rubicon.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 16:41:45 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Feb 2012 15:41:44 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] Working group last call on Template draft Thread-Index: AczgzifD0S11HUnQQi2otfgXa8gokQADgttQAm5d6VA= References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> From: To: X-OriginalArrivalTime: 13 Feb 2012 21:41:45.0290 (UTC) FILETIME=[482032A0:01CCEA98] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18708.001 X-TM-AS-Result: No--16.663-5.0-31-1 X-imss-scan-details: No--16.663-5.0-31-1 X-IMSS-DKIM-White-List: No Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:41:51 -0000 In Section 3, when discussing extension types for enumerated lists, I = think it might be useful to specifically reference section 5.1 of RFC = 5070 as well.=20 Under the "Example Enumerated Type Extension Definition," for the = example given, "content format" applies in the context of = Address@category, but it wouldn't work everywhere. For other extensible = enumerated lists, such as those under Impact@type, the meaning of the = ext-value might better be described by the term "value meaning" which = should be generic enough to cover all the expectation-setting the = various extensible lists can cover. Thank you, - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = kathleen.moriarty@emc.com Sent: Wednesday, February 01, 2012 07:34 To: trammell@tik.ee.ethz.ch Cc: mile@ietf.org Subject: [mile] Working group last call on Template draft Hello, We are starting a 2 week review period, the working group last call = (WGLC) for draft-ietf-mile-template. Please review and comment to the = MILE list on the template draft. =20 This is a short one and is used to provide a template for all extensions = defined in MILE. http://tools.ietf.org/html/draft-ietf-mile-template-00 Last call on comments will end the morning of February 15th. Thank you, Kathleen (as WG chair) -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] Sent: Wednesday, February 01, 2012 5:41 AM To: Moriarty, Kathleen Cc: mile@ietf.org Subject: next up: mile-template Hi, Kathleen, all, Now that the WG work on 6045-bis and 6046-bis is complete, and (almost) = in accordance with the charter, I believe the present revision of = draft-ietf-mile-template to be ready for WGLC. Many thanks, best regards, Brian Trammell (as author of mile-template) = _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Mon Feb 13 13:51:36 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D84F21F864E for ; Mon, 13 Feb 2012 13:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.856 X-Spam-Level: X-Spam-Status: No, score=-9.856 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 voe-C2UosEyc for ; Mon, 13 Feb 2012 13:51:35 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2E47321F8646 for ; Mon, 13 Feb 2012 13:51:35 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1DLpWX2020041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 16:51:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 13 Feb 2012 16:51:12 -0500 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1DLpCFV006804; Mon, 13 Feb 2012 16:51:12 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub34.corp.emc.com ([::1]) with mapi; Mon, 13 Feb 2012 16:51:12 -0500 From: To: , Date: Mon, 13 Feb 2012 16:51:10 -0500 Thread-Topic: Timeslot on the MILE WG Agenda for IETF 83 Thread-Index: Aczqk79fpTp3cLBzT0an1I/3SDNh8wABcJyg Message-ID: 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: multipart/alternative; boundary="_000_AE31510960917D478171C79369B660FA0E2F547A63MX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Timeslot on the MILE WG Agenda for IETF 83 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 21:51:36 -0000 --_000_AE31510960917D478171C79369B660FA0E2F547A63MX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dave, Yes, we will put you on the agenda for the MILE WG meeting and look forward= to the presentation. Thank you! Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Monday, February 13, 2012 4:09 PM To: mile@ietf.org Subject: [mile] Timeslot on the MILE WG Agenda for IETF 83 Kathleen et al, If possible, I'd like about 30 minutes on the MILE WG agenda at the next IE= TF meeting to discuss using the GRC Exchange approach as the core specifica= tion for orchestrating continuous monitoring solutions across various IT in= formation domains. My presentation would cover use cases and concepts rega= rding interoperable, inter- and intra-organizational orchestration between = various software components and services. Would this be of interest to the WG? Sincerely, Dave Waltermire --_000_AE31510960917D478171C79369B660FA0E2F547A63MX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Dave,

 

Yes, we will put you on the agenda for the MILE = WG meeting and look forward to the presentation. 

 

Thank you!

Kathleen

 

From: mile-bounc= es@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Waltermire, = David A.
Sent: Monday, February 13, 2012 4:09 PM
To: mi= le@ietf.org
Subject: [mile] Timeslot on the MILE WG Agenda for IE= TF 83

 

Kathleen et al,

 

If possible, I’d like ab= out 30 minutes on the MILE WG agenda at the next IETF meeting to discuss us= ing the GRC Exchange approach as the core specification for orchestrating c= ontinuous monitoring solutions across various IT information domains. = My presentation would cover use cases and concepts regarding interoperable= , inter- and intra-organizational orchestration between various software co= mponents and services.

 =

Would this be of interest to the WG?

 

Sincerely,<= o:p>

Dave Waltermire

 

= --_000_AE31510960917D478171C79369B660FA0E2F547A63MX06Acorpemcc_-- From turners@ieca.com Mon Feb 13 15:57:20 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19F021F863E for ; Mon, 13 Feb 2012 15:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.887 X-Spam-Level: X-Spam-Status: No, score=-101.887 tagged_above=-999 required=5 tests=[AWL=0.378, 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 jCrfZAoO3OY7 for ; Mon, 13 Feb 2012 15:57:20 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.55.5]) by ietfa.amsl.com (Postfix) with ESMTP id 65E0E21F8639 for ; Mon, 13 Feb 2012 15:57:20 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 4F4E0AFC91D6C; Mon, 13 Feb 2012 17:57:19 -0600 (CST) Received: from ham03.websitewelcome.com (ham.websitewelcome.com [173.192.100.229]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 449D3AFC91D30 for ; Mon, 13 Feb 2012 17:57:19 -0600 (CST) Received: by ham03.websitewelcome.com (Postfix, from userid 666) id 091EB2138B180; Mon, 13 Feb 2012 17:57:19 -0600 (CST) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by ham03.websitewelcome.com (Postfix) with ESMTP id CF92C2138B106 for ; Mon, 13 Feb 2012 17:57:18 -0600 (CST) Received: from [96.231.126.198] (port=48426 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rx5lm-0002Ld-NP for mile@ietf.org; Mon, 13 Feb 2012 17:57:18 -0600 Message-ID: <4F39A35E.7010000@ieca.com> Date: Mon, 13 Feb 2012 18:57:18 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: mile@ietf.org 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-96-231-126-198.washdc.east.verizon.net (thunderfish.local) [96.231.126.198]:48426 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 26 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:57:20 -0000 There's 17 listed SCI (Structured Cybersecurity Information) specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory to implement) choice? In other words, how will you get two interoperability implementations without picking one? spt From kathleen.moriarty@emc.com Mon Feb 13 16:11:48 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CD421F8697 for ; Mon, 13 Feb 2012 16:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.866 X-Spam-Level: X-Spam-Status: No, score=-9.866 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, 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 dtYH9hB-J4hy for ; Mon, 13 Feb 2012 16:11:47 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC1A21F8693 for ; Mon, 13 Feb 2012 16:11:46 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1E0BZt8024276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 19:11:44 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 13 Feb 2012 19:11:23 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1E0BNXN031177; Mon, 13 Feb 2012 19:11:23 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Mon, 13 Feb 2012 19:11:23 -0500 From: To: , Date: Mon, 13 Feb 2012 19:11:21 -0500 Thread-Topic: [mile] MTI SCI? Thread-Index: Aczqq1xe9HbEc94pQZeb1orflcZKSgAAQB8g Message-ID: References: <4F39A35E.7010000@ieca.com> In-Reply-To: <4F39A35E.7010000@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 00:11:48 -0000 Thank you for raising the interoperability testing as we need to plan for a= bake-off that once these questions get answered and the draft is ready. Thanks, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sea= n Turner Sent: Monday, February 13, 2012 6:57 PM To: mile@ietf.org Subject: [mile] MTI SCI? There's 17 listed SCI (Structured Cybersecurity Information)=20 specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory=20 to implement) choice? In other words, how will you get two=20 interoperability implementations without picking one? spt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From turners@ieca.com Mon Feb 13 16:19:31 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535FE21E801A for ; Mon, 13 Feb 2012 16:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=0.283, 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 S02WGoLB+vra for ; Mon, 13 Feb 2012 16:19:31 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.236.22]) by ietfa.amsl.com (Postfix) with ESMTP id EADDB21E8010 for ; Mon, 13 Feb 2012 16:19:30 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 213FED23A02E4; Mon, 13 Feb 2012 18:19:30 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 1702FD23A02C3 for ; Mon, 13 Feb 2012 18:19:30 -0600 (CST) Received: from [96.231.126.198] (port=46810 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rx67F-0007fw-KT; Mon, 13 Feb 2012 18:19:29 -0600 Message-ID: <4F39A891.4060503@ieca.com> Date: Mon, 13 Feb 2012 19:19:29 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <4F39A35E.7010000@ieca.com> In-Reply-To: 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-96-231-126-198.washdc.east.verizon.net (thunderfish.local) [96.231.126.198]:46810 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 00:19:31 -0000 Great - as long as we pick one as the MTI. Note that MTI is not necessarily mandatory to use. spt On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: > Thank you for raising the interoperability testing as we need to plan for a bake-off that once these questions get answered and the draft is ready. > > Thanks, > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > Sent: Monday, February 13, 2012 6:57 PM > To: mile@ietf.org > Subject: [mile] MTI SCI? > > There's 17 listed SCI (Structured Cybersecurity Information) > specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory > to implement) choice? In other words, how will you get two > interoperability implementations without picking one? > > spt > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > From trammell@tik.ee.ethz.ch Tue Feb 14 00:20:46 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C2921E8048 for ; Tue, 14 Feb 2012 00:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ysGg-rYYaugC for ; Tue, 14 Feb 2012 00:20:44 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9226621E804F for ; Tue, 14 Feb 2012 00:20:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7AFF1D9309; Tue, 14 Feb 2012 09:20:42 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lsuQPtB5ATs9; Tue, 14 Feb 2012 09:20:42 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1DB4FD9308; Tue, 14 Feb 2012 09:20:42 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Tue, 14 Feb 2012 09:20:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 08:20:47 -0000 Hi, Tom, Thanks for the comments. Will incorporate in the -01 working copy (to be = submitted after the end of the WGLC, tomorrow).=20 With respect to the meaning of the ext-value, I think we need to = explicitly address that this should describe semantics as well as = representation; so how about "value meaning and encoding"? Best regards, Brian (author hat) On Feb 13, 2012, at 10:41 PM, = wrote: > In Section 3, when discussing extension types for enumerated lists, I = think it might be useful to specifically reference section 5.1 of RFC = 5070 as well.=20 >=20 > Under the "Example Enumerated Type Extension Definition," for the = example given, "content format" applies in the context of = Address@category, but it wouldn't work everywhere. For other extensible = enumerated lists, such as those under Impact@type, the meaning of the = ext-value might better be described by the term "value meaning" which = should be generic enough to cover all the expectation-setting the = various extensible lists can cover. >=20 > Thank you, >=20 > - Tom Millar, US-CERT >=20 > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of kathleen.moriarty@emc.com > Sent: Wednesday, February 01, 2012 07:34 > To: trammell@tik.ee.ethz.ch > Cc: mile@ietf.org > Subject: [mile] Working group last call on Template draft >=20 > Hello, >=20 > We are starting a 2 week review period, the working group last call = (WGLC) for draft-ietf-mile-template. Please review and comment to the = MILE list on the template draft. =20 >=20 > This is a short one and is used to provide a template for all = extensions defined in MILE. >=20 > http://tools.ietf.org/html/draft-ietf-mile-template-00 >=20 > Last call on comments will end the morning of February 15th. >=20 > Thank you, > Kathleen (as WG chair) >=20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, February 01, 2012 5:41 AM > To: Moriarty, Kathleen > Cc: mile@ietf.org > Subject: next up: mile-template >=20 > Hi, Kathleen, all, >=20 > Now that the WG work on 6045-bis and 6046-bis is complete, and = (almost) in accordance with the charter, I believe the present revision = of draft-ietf-mile-template to be ready for WGLC. >=20 > Many thanks, best regards, >=20 > Brian Trammell (as author of mile-template) = _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Feb 14 01:19:57 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AFA21F872A for ; Tue, 14 Feb 2012 01:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jaDXa5wLsuPb for ; Tue, 14 Feb 2012 01:19:56 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AD58C21F8729 for ; Tue, 14 Feb 2012 01:19:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 74AF9D930A; Tue, 14 Feb 2012 10:19:55 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BigkVsDAfS6Q; Tue, 14 Feb 2012 10:19:55 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0A119D9309; Tue, 14 Feb 2012 10:19:55 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4F39A891.4060503@ieca.com> Date: Tue, 14 Feb 2012 10:19:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 09:19:57 -0000 Hi, Sean, all, Looking over the spec, it's not clear to me that one MTI makes sense = here, given that mile-sci's purpose is to reference a set of external = specifications by inclusion in an IODEF document, and that those = external specifications represent fundamentally different things. The specifications are split over their applicability to the IODEF = extension classes. I could envision an mile-sci implementation that was = only interested a subset of these classes (perhaps even only one). If my = implementation has an internal representation of Verification, but not = of any of the other classes, and the MTI is an enumeration that is = applicable to Vulnerability... what do I do? What about selecting an MTI per class, instead? Best regards, Brian (as contributor) On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > Great - as long as we pick one as the MTI. Note that MTI is not = necessarily mandatory to use. >=20 > spt >=20 > On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >> Thank you for raising the interoperability testing as we need to plan = for a bake-off that once these questions get answered and the draft is = ready. >>=20 >> Thanks, >> Kathleen >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Sean Turner >> Sent: Monday, February 13, 2012 6:57 PM >> To: mile@ietf.org >> Subject: [mile] MTI SCI? >>=20 >> There's 17 listed SCI (Structured Cybersecurity Information) >> specifications in draft-ietf-mile-sci. Which one is the MTI = (mandatory >> to implement) choice? In other words, how will you get two >> interoperability implementations without picking one? >>=20 >> spt >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >>=20 >>=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From ramartin@mitre.org Tue Feb 14 05:25:58 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23A221F8717 for ; Tue, 14 Feb 2012 05:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 QLiC+C4oaMWq for ; Tue, 14 Feb 2012 05:25:58 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3F81B21F8709 for ; Tue, 14 Feb 2012 05:25:58 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 956D021B051A; Tue, 14 Feb 2012 08:25:57 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 83E3921B08C7; Tue, 14 Feb 2012 08:25:57 -0500 (EST) Received: from mm169528-pc.mitre.org (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.339.1; Tue, 14 Feb 2012 08:25:57 -0500 Message-ID: <4F3A60E4.7040700@mitre.org> Date: Tue, 14 Feb 2012 08:25:56 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Brian Trammell References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 13:25:59 -0000 Brian, You beat me to this point. Like you, I would be concerned about a MTI selection that ended up requiring someone to implement something to meet the MTI but wasn't germane to anything else they intended to support. Bob On 2/14/12 4:19 AM, Brian Trammell wrote: > Hi, Sean, all, > > Looking over the spec, it's not clear to me that one MTI makes sense here, given that mile-sci's purpose is to reference a set of external specifications by inclusion in an IODEF document, and that those external specifications represent fundamentally different things. > > The specifications are split over their applicability to the IODEF extension classes. I could envision an mile-sci implementation that was only interested a subset of these classes (perhaps even only one). If my implementation has an internal representation of Verification, but not of any of the other classes, and the MTI is an enumeration that is applicable to Vulnerability... what do I do? > > What about selecting an MTI per class, instead? > > Best regards, > > Brian (as contributor) > > On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >> Great - as long as we pick one as the MTI. Note that MTI is not necessarily mandatory to use. >> >> spt >> >> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >>> Thank you for raising the interoperability testing as we need to plan for a bake-off that once these questions get answered and the draft is ready. >>> >>> Thanks, >>> Kathleen >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>> Sent: Monday, February 13, 2012 6:57 PM >>> To: mile@ietf.org >>> Subject: [mile] MTI SCI? >>> >>> There's 17 listed SCI (Structured Cybersecurity Information) >>> specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory >>> to implement) choice? In other words, how will you get two >>> interoperability implementations without picking one? >>> >>> spt >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > From turners@ieca.com Tue Feb 14 05:32:57 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92CA21F85F2 for ; Tue, 14 Feb 2012 05:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=0.189, 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 EnolxvcDJCAN for ; Tue, 14 Feb 2012 05:32:55 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.65.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84C21F85B6 for ; Tue, 14 Feb 2012 05:32:55 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id C4A31D3145BEF; Tue, 14 Feb 2012 07:32:54 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id B7FF2D3145BA8 for ; Tue, 14 Feb 2012 07:32:54 -0600 (CST) Received: from [96.231.116.229] (port=47389 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RxIV4-0005Gg-3F; Tue, 14 Feb 2012 07:32:54 -0600 Message-ID: <4F3A6285.7030501@ieca.com> Date: Tue, 14 Feb 2012 08:32:53 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Martin, Robert A." References: <4F342F2E.3040607@ieca.com> <4F345124.5000707@yaanatech.com> <4ED17FBE-096A-43AC-9436-3F5F124E4FE7@tik.ee.ethz.ch> <4F350FFD.3020503@yaanatech.com> <4F353A64.7010409@mitre.org> <4F391F6F.50208@ieca.com> <4F392155.9000901@mitre.org> In-Reply-To: <4F392155.9000901@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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-96-231-116-229.washdc.east.verizon.net (thunderfish.local) [96.231.116.229]:47389 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org, sec-ads@tools.ietf.org Subject: Re: [mile] Major Issue with draft-ietf-mile-sci X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 13:32:57 -0000 Bob, I think this is much better, but I can't guarantee that others won't have different concerns. spt On 2/13/12 9:42 AM, Martin, Robert A. wrote: > Sean, > > While we have had many others agree to our current terms of use and so > are still unsure why this is an issue, in the spirit of cooperation and > our belief in the goals of structuring cybersecurity information, we > will accept the language of the IETF Trust Legal Provisions and revise > our terms of use to state the following: > > ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN > "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR > IS SPONSORED BY (IF ANY), THE MITRE CORPORATION, ITS BOARD OF TRUSTEES, > OFFICERS, AGENTS, AND EMPLOYEES, DISCLAIM ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > If you can concur that this should address your concern regarding the > terms of use we will proceed to make the changes. > > Bob > > On 2/13/12 9:34 AM, Sean Turner wrote: >> On 2/10/12 10:40 AM, Martin, Robert A. wrote: >>> Sean, >>> >>> We have had the current terms of use since we launched the Common >>> Vulnerabilities and Exposures (CVE) initiative in September of 1999 and >>> this is the first time to my knowledge that anyone has had issue with >>> them. >>> >>> I will say that over 200 organizations from 26 countries have found >>> those terms acceptable and incorporated one or more of our >>> standardization efforts into their products or services. >>> >>> IANAL, but maybe the norm of these types of clauses has evolved over the >>> 12 years that these have been in place on our efforts and its time to >>> review them. >>> >>> Sean, if the terms were along the lines of those used by the IETF as >>> provided by Brian and suggested by Tony would that be in the right >>> direction? >> >> It would help. >> >>> MITRE's work in this area is meant to help improve security practices >>> and capabilities and the terms were not meant to impede the uptake or >>> leveraging of this work in any manner, but as I mentioned, this is the >>> first time someone has raised an issue with them. >>> >>> Regards, >>> >>> Bob >>> >>> P.S. Also, so we are communicating clearly, what are the 17 items you >>> are referring to? My count is a bit lower. >> >> You're right the number is a bit lower - 7 I think. >> >>> On 2/10/12 7:39 AM, Tony Rutkowski wrote: >>>> Hi Brian, >>>> >>>> Good research! At this point, MITRE might respond why >>>> its provisions need be stronger than those of the IETF/ISOC. >>>> Maybe they would be willing to use the same one. >>>> >>>> best, >>>> tony >>>> >>>> On 2/10/2012 6:20 AM, Brian Trammell wrote: >>>>> Hi, Tony, all, >>>>> >>>>> IANAL, but all I can find that's current and looks like indemnity is >>>>> section 7(a) of the IETF Trust Legal Provisions (rev. 4.0 of 28 >>>>> December 2009, http://trustee.ietf.org/license-info/) (sorry for the >>>>> yelling, this is a straight copy-paste): >>>>> >>>>> ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN >>>>> “AS IS” BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS >>>>> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE >>>>> INTERNET ENGINEERING TASK FORCE AND ANY APPLICABLE MANAGERS OF >>>>> ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW, DISCLAIM >>>>> ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY >>>>> WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY >>>>> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A >>>>> PARTICULAR PURPOSE. >>>>> >>>>> The MITRE indemnity clause looks a quite a bit stronger to me than the >>>>> no-warranty clause (again, merely as a native speaker of non-lawyer >>>>> English), even though I could be convinced that the basic intention is >>>>> the same. I could also be convinced that there is enough of a >>>>> difference here that they are fundamentally incompatible. The question >>>>> for this issue would them seem to be whether a disclaimer of warranty >>>>> is the same thing as an indemnification. >>>>> >>>>> If it isn't, one class of solutions would be to bring the referenced >>>>> MITRE specifications under a licensing regime that's compatible with >>>>> the Trust Legal Provisions. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> . >>>> >>> >>> >>> >> . >> > > From turners@ieca.com Tue Feb 14 05:40:37 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC0921F876C for ; Tue, 14 Feb 2012 05:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.803 X-Spam-Level: X-Spam-Status: No, score=-101.803 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_26=0.6, 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 7Q1utIvGCXb5 for ; Tue, 14 Feb 2012 05:40:36 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.31.20]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF421F8766 for ; Tue, 14 Feb 2012 05:40:36 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 980427B445978; Tue, 14 Feb 2012 07:40:35 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 8D9C57B445954 for ; Tue, 14 Feb 2012 07:40:35 -0600 (CST) Received: from [96.231.116.229] (port=46961 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RxIcU-0007L7-Vl; Tue, 14 Feb 2012 07:40:35 -0600 Message-ID: <4F3A6452.6060709@ieca.com> Date: Tue, 14 Feb 2012 08:40:34 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Martin, Robert A." , Brian Trammell References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> <4F3A60E4.7040700@mitre.org> In-Reply-To: <4F3A60E4.7040700@mitre.org> 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-96-231-116-229.washdc.east.verizon.net (thunderfish.local) [96.231.116.229]:46961 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 13:40:37 -0000 Coming from the ol'school world of ASN.1 (all the cool kids are doing JSON now-a-days) when you have optional elements in say a sequence you had to say which one was the MTI to ensure you got interop. In XML-land that doesn't happen as much. There's a bunch of optional things and the implementation gets to pick what it wants to support. That's great for gaining the widest possible adoption of the spec, but not so great for actually getting two implementations to interop. I'll be happy as long as the WG comes up with a way to clearly describe what two implementations need to do to interop. spt On 2/14/12 8:25 AM, Martin, Robert A. wrote: > Brian, > > You beat me to this point. Like you, I would be concerned about a MTI > selection that ended up requiring someone to implement something to meet > the MTI but wasn't germane to anything else they intended to support. > > Bob > > On 2/14/12 4:19 AM, Brian Trammell wrote: >> Hi, Sean, all, >> >> Looking over the spec, it's not clear to me that one MTI makes sense >> here, given that mile-sci's purpose is to reference a set of external >> specifications by inclusion in an IODEF document, and that those >> external specifications represent fundamentally different things. >> >> The specifications are split over their applicability to the IODEF >> extension classes. I could envision an mile-sci implementation that >> was only interested a subset of these classes (perhaps even only one). >> If my implementation has an internal representation of Verification, >> but not of any of the other classes, and the MTI is an enumeration >> that is applicable to Vulnerability... what do I do? >> >> What about selecting an MTI per class, instead? >> >> Best regards, >> >> Brian (as contributor) >> >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >> >>> Great - as long as we pick one as the MTI. Note that MTI is not >>> necessarily mandatory to use. >>> >>> spt >>> >>> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >>>> Thank you for raising the interoperability testing as we need to >>>> plan for a bake-off that once these questions get answered and the >>>> draft is ready. >>>> >>>> Thanks, >>>> Kathleen >>>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>> Of Sean Turner >>>> Sent: Monday, February 13, 2012 6:57 PM >>>> To: mile@ietf.org >>>> Subject: [mile] MTI SCI? >>>> >>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>> specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory >>>> to implement) choice? In other words, how will you get two >>>> interoperability implementations without picking one? >>>> >>>> spt >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> . >> > From kathleen.moriarty@emc.com Tue Feb 14 06:42:37 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BEA21F85D8 for ; Tue, 14 Feb 2012 06:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.876 X-Spam-Level: X-Spam-Status: No, score=-9.876 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, 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 wwJRl0bWW7hh for ; Tue, 14 Feb 2012 06:42:36 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 809C321F8585 for ; Tue, 14 Feb 2012 06:42:36 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EEgMUU029938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 09:42:34 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 14 Feb 2012 09:42:06 -0500 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EEg5Fa001823; Tue, 14 Feb 2012 09:42:05 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Tue, 14 Feb 2012 09:42:05 -0500 From: To: , Date: Tue, 14 Feb 2012 09:42:04 -0500 Thread-Topic: [mile] MTI SCI? Thread-Index: Aczq+f3rMSOT7U8bQXOQtYbBxHInlgALGJww Message-ID: References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:42:37 -0000 Hi Sean, Brian, all, If you think if each included schema as a module, and each module is includ= ed the same way, but in different areas of IODEF, shouldn't one be sufficie= nt for mandatory? For a bake-off, we should do at least two? IODEF specif= ies how to respond when a schema is not recognized, so that should be in th= e bake-off too. =20 Other opinions? Regards, Kathleen -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Tuesday, February 14, 2012 4:20 AM To: Sean Turner Cc: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] MTI SCI? Hi, Sean, all, Looking over the spec, it's not clear to me that one MTI makes sense here, = given that mile-sci's purpose is to reference a set of external specificati= ons by inclusion in an IODEF document, and that those external specificatio= ns represent fundamentally different things. The specifications are split over their applicability to the IODEF extensio= n classes. I could envision an mile-sci implementation that was only intere= sted a subset of these classes (perhaps even only one). If my implementatio= n has an internal representation of Verification, but not of any of the oth= er classes, and the MTI is an enumeration that is applicable to Vulnerabili= ty... what do I do? What about selecting an MTI per class, instead? Best regards, Brian (as contributor) On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > Great - as long as we pick one as the MTI. Note that MTI is not necessar= ily mandatory to use. >=20 > spt >=20 > On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >> Thank you for raising the interoperability testing as we need to plan fo= r a bake-off that once these questions get answered and the draft is ready. >>=20 >> Thanks, >> Kathleen >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Sean Turner >> Sent: Monday, February 13, 2012 6:57 PM >> To: mile@ietf.org >> Subject: [mile] MTI SCI? >>=20 >> There's 17 listed SCI (Structured Cybersecurity Information) >> specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory >> to implement) choice? In other words, how will you get two >> interoperability implementations without picking one? >>=20 >> spt >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >>=20 >>=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Tue Feb 14 07:03:34 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C17721F8764 for ; Tue, 14 Feb 2012 07:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.594 X-Spam-Level: X-Spam-Status: No, score=-9.594 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 SOTJlSCvktJw for ; Tue, 14 Feb 2012 07:03:33 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4ED21F85E0 for ; Tue, 14 Feb 2012 07:03:22 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EF3IUU008918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 10:03:21 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 14 Feb 2012 10:03:06 -0500 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EF35kg013365; Tue, 14 Feb 2012 10:03:05 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Tue, 14 Feb 2012 10:03:04 -0500 From: To: , , Date: Tue, 14 Feb 2012 10:03:03 -0500 Thread-Topic: [mile] MTI SCI? Thread-Index: AczrKFmFSsV3eGuFTR+2PUQoYvDsaAAAKbnQ Message-ID: References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> <4F3A60E4.7040700@mitre.org> <4F3A6452.6060709@ieca.com> In-Reply-To: <4F3A6452.6060709@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 15:03:34 -0000 I agree with Sean here in that there has to be at least one mandatory so we= know if the method used to incorporate schemas within IODE for exchange wo= rks... otherwise, we may need to tweak something in the draft before it mov= es to standard. Brian is arguing for one mandatory in each are of IODEF th= at is extended (valid point and an option we should consider). I think Bob= you feel nothing should be mandatory or are you agreeing with Brian - one = per extended area of IODEF? I think having one fail in the tests would also be good to make sure it hap= pens in a way that works between implementations as well. Other opinions? Or agreement with any of the above opinions? (and my posts to MILE seem to be delayed... apologies) Thanks, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sea= n Turner Sent: Tuesday, February 14, 2012 8:41 AM To: Martin, Robert A.; Brian Trammell Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? Coming from the ol'school world of ASN.1 (all the cool kids are doing=20 JSON now-a-days) when you have optional elements in say a sequence you=20 had to say which one was the MTI to ensure you got interop. In XML-land=20 that doesn't happen as much. There's a bunch of optional things and the=20 implementation gets to pick what it wants to support. That's great for=20 gaining the widest possible adoption of the spec, but not so great for=20 actually getting two implementations to interop. I'll be happy as long=20 as the WG comes up with a way to clearly describe what two=20 implementations need to do to interop. spt On 2/14/12 8:25 AM, Martin, Robert A. wrote: > Brian, > > You beat me to this point. Like you, I would be concerned about a MTI > selection that ended up requiring someone to implement something to meet > the MTI but wasn't germane to anything else they intended to support. > > Bob > > On 2/14/12 4:19 AM, Brian Trammell wrote: >> Hi, Sean, all, >> >> Looking over the spec, it's not clear to me that one MTI makes sense >> here, given that mile-sci's purpose is to reference a set of external >> specifications by inclusion in an IODEF document, and that those >> external specifications represent fundamentally different things. >> >> The specifications are split over their applicability to the IODEF >> extension classes. I could envision an mile-sci implementation that >> was only interested a subset of these classes (perhaps even only one). >> If my implementation has an internal representation of Verification, >> but not of any of the other classes, and the MTI is an enumeration >> that is applicable to Vulnerability... what do I do? >> >> What about selecting an MTI per class, instead? >> >> Best regards, >> >> Brian (as contributor) >> >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >> >>> Great - as long as we pick one as the MTI. Note that MTI is not >>> necessarily mandatory to use. >>> >>> spt >>> >>> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >>>> Thank you for raising the interoperability testing as we need to >>>> plan for a bake-off that once these questions get answered and the >>>> draft is ready. >>>> >>>> Thanks, >>>> Kathleen >>>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>> Of Sean Turner >>>> Sent: Monday, February 13, 2012 6:57 PM >>>> To: mile@ietf.org >>>> Subject: [mile] MTI SCI? >>>> >>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>> specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory >>>> to implement) choice? In other words, how will you get two >>>> interoperability implementations without picking one? >>>> >>>> spt >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> . >> > _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From youki-k@is.aist-nara.ac.jp Tue Feb 14 07:14:45 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7186721F87E1 for ; Tue, 14 Feb 2012 07:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_26=0.6] 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 XDWgeUh+yQHZ for ; Tue, 14 Feb 2012 07:14:44 -0800 (PST) Received: from mailrelay11.naist.jp (mailrelay11.naist.jp [163.221.80.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8662921F877F for ; Tue, 14 Feb 2012 07:14:44 -0800 (PST) Received: from mailpost11.naist.jp (mailscan11.naist.jp [163.221.80.161]) by mailrelay11.naist.jp (Postfix) with ESMTP id E073C39A6; Wed, 15 Feb 2012 00:14:42 +0900 (JST) Received: from air-3.local (121-82-185-209f1.kyt1.eonet.ne.jp [121.82.185.209]) (Authenticated sender: youki-k) by mailpost11.naist.jp (Postfix) with ESMTPSA id 6D85039A5; Wed, 15 Feb 2012 00:14:42 +0900 (JST) Message-ID: <4F3A7A61.1060706@is.aist-nara.ac.jp> Date: Wed, 15 Feb 2012 00:14:41 +0900 From: Youki Kadobayashi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com, mile@ietf.org References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> <4F3A60E4.7040700@mitre.org> <4F3A6452.6060709@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.8105-6.8.0.1017-18710.000 X-TM-AS-Result: No--29.423-5.0-31-1 X-imss-scan-details: No--29.423-5.0-31-1 Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 15:14:45 -0000 I think CAPEC is best candidate of MTI spec, as it is simple, and it nicely extends IODEF vocabulary. I would like to hear other people's opinions. -- Youki Kadobayashi WIDE Project / Nara Institute of Science and Technology (12/02/15 0:03), kathleen.moriarty@emc.com wrote: > I agree with Sean here in that there has to be at least one mandatory so we know if the method used to incorporate schemas within IODE for exchange works... otherwise, we may need to tweak something in the draft before it moves to standard. Brian is arguing for one mandatory in each are of IODEF that is extended (valid point and an option we should consider). I think Bob you feel nothing should be mandatory or are you agreeing with Brian - one per extended area of IODEF? > > I think having one fail in the tests would also be good to make sure it happens in a way that works between implementations as well. > > Other opinions? Or agreement with any of the above opinions? > > (and my posts to MILE seem to be delayed... apologies) > > Thanks, > Kathleen > > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > Sent: Tuesday, February 14, 2012 8:41 AM > To: Martin, Robert A.; Brian Trammell > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? > > Coming from the ol'school world of ASN.1 (all the cool kids are doing > JSON now-a-days) when you have optional elements in say a sequence you > had to say which one was the MTI to ensure you got interop. In XML-land > that doesn't happen as much. There's a bunch of optional things and the > implementation gets to pick what it wants to support. That's great for > gaining the widest possible adoption of the spec, but not so great for > actually getting two implementations to interop. I'll be happy as long > as the WG comes up with a way to clearly describe what two > implementations need to do to interop. > > spt > > On 2/14/12 8:25 AM, Martin, Robert A. wrote: >> Brian, >> >> You beat me to this point. Like you, I would be concerned about a MTI >> selection that ended up requiring someone to implement something to meet >> the MTI but wasn't germane to anything else they intended to support. >> >> Bob >> >> On 2/14/12 4:19 AM, Brian Trammell wrote: >>> Hi, Sean, all, >>> >>> Looking over the spec, it's not clear to me that one MTI makes sense >>> here, given that mile-sci's purpose is to reference a set of external >>> specifications by inclusion in an IODEF document, and that those >>> external specifications represent fundamentally different things. >>> >>> The specifications are split over their applicability to the IODEF >>> extension classes. I could envision an mile-sci implementation that >>> was only interested a subset of these classes (perhaps even only one). >>> If my implementation has an internal representation of Verification, >>> but not of any of the other classes, and the MTI is an enumeration >>> that is applicable to Vulnerability... what do I do? >>> >>> What about selecting an MTI per class, instead? >>> >>> Best regards, >>> >>> Brian (as contributor) >>> >>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>> >>>> Great - as long as we pick one as the MTI. Note that MTI is not >>>> necessarily mandatory to use. >>>> >>>> spt >>>> >>>> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >>>>> Thank you for raising the interoperability testing as we need to >>>>> plan for a bake-off that once these questions get answered and the >>>>> draft is ready. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Sean Turner >>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>> To: mile@ietf.org >>>>> Subject: [mile] MTI SCI? >>>>> >>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>> specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory >>>>> to implement) choice? In other words, how will you get two >>>>> interoperability implementations without picking one? >>>>> >>>>> spt >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> . >>> >> > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > From david.black@emc.com Tue Feb 14 08:14:59 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C38121E8021 for ; Tue, 14 Feb 2012 08:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.47 X-Spam-Level: X-Spam-Status: No, score=-109.47 tagged_above=-999 required=5 tests=[AWL=1.129, 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 9A+k7MYwaYn9 for ; Tue, 14 Feb 2012 08:14:58 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 645A621E8027 for ; Tue, 14 Feb 2012 08:14:52 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EGEm7j030182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 11:14:51 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 14 Feb 2012 11:14:29 -0500 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EGESAc010672; Tue, 14 Feb 2012 11:14:29 -0500 Received: from mx14a.corp.emc.com ([169.254.1.94]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Tue, 14 Feb 2012 11:14:28 -0500 From: To: Date: Tue, 14 Feb 2012 11:14:28 -0500 Thread-Topic: [mile] MTI SCI? Thread-Index: AczrLda5Lfe6JOk2QRCfqjwH7kHJTwAAy6PA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33A6CE@MX14A.corp.emc.com> References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> <4F3A60E4.7040700@mitre.org> In-Reply-To: <4F3A60E4.7040700@mitre.org> 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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:14:59 -0000 Hi Bob, I do appreciate the concern about implementing things that aren't going to = be used. OTOH, it may be useful to have a single simple MTI spec for SCI t= hat can be used to "smoke test" a deployment before trying any serious test= data (and "simple" is important). In addition, a concern that I would have with an MTI SCI spec per class is = that if two SCI implementations don't have at least one class in common, th= ey aren't going to interoperate, and that situation is unlikely to be accep= table to the IESG (i.e., with an MTI SCI spec per class, I suspect that the= re will also have to be an MTI class, which results in an overall MTI SCI s= pec). It may also be useful to include a simple example of the MTI SCI spec in an= appendix to simplify "smoke testing" (e.g., if the MTI SCI spec is CAPEC, = as Youki suggested, the appendix could contain a CAPEC XML document for tes= ting purposes, including enumeration values suitable for testing). What do you (and others) think about this? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of M= artin, Robert A. > Sent: Tuesday, February 14, 2012 8:26 AM > To: Brian Trammell > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? >=20 > Brian, >=20 > You beat me to this point. Like you, I would be concerned about a MTI > selection that ended up requiring someone to implement something to meet > the MTI but wasn't germane to anything else they intended to support. >=20 > Bob >=20 > On 2/14/12 4:19 AM, Brian Trammell wrote: > > Hi, Sean, all, > > > > Looking over the spec, it's not clear to me that one MTI makes sense he= re, given that mile-sci's > purpose is to reference a set of external specifications by inclusion in = an IODEF document, and that > those external specifications represent fundamentally different things. > > > > The specifications are split over their applicability to the IODEF exte= nsion classes. I could > envision an mile-sci implementation that was only interested a subset of = these classes (perhaps even > only one). If my implementation has an internal representation of Verific= ation, but not of any of > the other classes, and the MTI is an enumeration that is applicable to Vu= lnerability... what do I > do? > > > > What about selecting an MTI per class, instead? > > > > Best regards, > > > > Brian (as contributor) > > > > On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > >> Great - as long as we pick one as the MTI. Note that MTI is not neces= sarily mandatory to use. > >> > >> spt > >> > >> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: > >>> Thank you for raising the interoperability testing as we need to plan= for a bake-off that once > these questions get answered and the draft is ready. > >>> > >>> Thanks, > >>> Kathleen > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Sean Turner > >>> Sent: Monday, February 13, 2012 6:57 PM > >>> To: mile@ietf.org > >>> Subject: [mile] MTI SCI? > >>> > >>> There's 17 listed SCI (Structured Cybersecurity Information) > >>> specifications in draft-ietf-mile-sci. Which one is the MTI (mandato= ry > >>> to implement) choice? In other words, how will you get two > >>> interoperability implementations without picking one? > >>> > >>> spt > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > . > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Thomas.Millar@us-cert.gov Tue Feb 14 08:36:59 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B1A21E803C for ; Tue, 14 Feb 2012 08:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, 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 H2sZlvB9G8AS for ; Tue, 14 Feb 2012 08:36:59 -0800 (PST) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [208.73.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0891921E8021 for ; Tue, 14 Feb 2012 08:36:58 -0800 (PST) Received: from daphne.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 258243F3BC; Tue, 14 Feb 2012 16:36:58 +0000 (UTC) Received: from dabba.bronze.us-cert.gov (dabba.bronze.us-cert.gov [192.168.16.121]) by daphne.brass.us-cert.gov (Postfix) with ESMTP id 17C473F3BB; Tue, 14 Feb 2012 16:36:58 +0000 (UTC) Received: from needle.bronze.us-cert.gov (needle.bronze.us-cert.gov [192.168.16.109]) by dabba.bronze.us-cert.gov (Postfix) with ESMTP id 176136E45C; Tue, 14 Feb 2012 16:36:58 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 10:36:57 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Feb 2012 10:36:57 -0600 Message-ID: In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33A6CE@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] MTI SCI? Thread-Index: AczrLda5Lfe6JOk2QRCfqjwH7kHJTwAAy6PAAAENjCA= References: <4F39A35E.7010000@ieca.com><4F39A891.4060503@ieca.com><4F3A60E4.7040700@mitre.org> <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33A6CE@MX14A.corp.emc.com> From: To: , X-OriginalArrivalTime: 14 Feb 2012 16:36:57.0924 (UTC) FILETIME=[DE6B5840:01CCEB36] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18710.000 X-TM-AS-Result: No--44.305-5.0-31-1 X-imss-scan-details: No--44.305-5.0-31-1 X-IMSS-DKIM-White-List: No Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:37:00 -0000 My concern with CAPEC being mandatory is that it could discourage = effective operational uptake of IODEF-SCI as the CAPEC vocabulary = remains "too comprehensive" for many CSIRTs to employ during incident = handling and reporting activity.=20 IODEF by itself has been criticized by CSIRT operators for being more = heavyweight than necessary for day-to-day usage; making CAPEC a = mandatory aspect of "advanced IODEF" seems like it would be adding = ammunition to that argument, especially if the CSIRT is having to fund = implementation out of their own pocket. Personally, I would have a hard = time asking US-CERT's primary constituents to implement IODEF + CAPEC if = they are already balking at the consultant and developer resources = required to implement RFC 5070 by itself. Also keep in mind that CAPEC = references CybOX, so there's wheels within wheels now. =20 I would prefer we take the path of least resistance (from my = perspective) and make CVE the MTI, if we have to pick one additional = spec. CVE is well known, has years of familiarity built in, and I think it's = the simplest schema of the bunch.=20 - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = david.black@emc.com Sent: Tuesday, February 14, 2012 11:14 To: ramartin@mitre.org Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? Hi Bob, I do appreciate the concern about implementing things that aren't going = to be used. OTOH, it may be useful to have a single simple MTI spec for = SCI that can be used to "smoke test" a deployment before trying any = serious test data (and "simple" is important). In addition, a concern that I would have with an MTI SCI spec per class = is that if two SCI implementations don't have at least one class in = common, they aren't going to interoperate, and that situation is = unlikely to be acceptable to the IESG (i.e., with an MTI SCI spec per = class, I suspect that there will also have to be an MTI class, which = results in an overall MTI SCI spec). It may also be useful to include a simple example of the MTI SCI spec in = an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec is = CAPEC, as Youki suggested, the appendix could contain a CAPEC XML = document for testing purposes, including enumeration values suitable for = testing). What do you (and others) think about this? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Martin, Robert A. > Sent: Tuesday, February 14, 2012 8:26 AM > To: Brian Trammell > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? >=20 > Brian, >=20 > You beat me to this point. Like you, I would be concerned about a MTI = > selection that ended up requiring someone to implement something to=20 > meet the MTI but wasn't germane to anything else they intended to = support. >=20 > Bob >=20 > On 2/14/12 4:19 AM, Brian Trammell wrote: > > Hi, Sean, all, > > > > Looking over the spec, it's not clear to me that one MTI makes sense = > > here, given that mile-sci's > purpose is to reference a set of external specifications by inclusion=20 > in an IODEF document, and that those external specifications represent = fundamentally different things. > > > > The specifications are split over their applicability to the IODEF=20 > > extension classes. I could > envision an mile-sci implementation that was only interested a subset=20 > of these classes (perhaps even only one). If my implementation has an=20 > internal representation of Verification, but not of any of the other=20 > classes, and the MTI is an enumeration that is applicable to = Vulnerability... what do I do? > > > > What about selecting an MTI per class, instead? > > > > Best regards, > > > > Brian (as contributor) > > > > On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > >> Great - as long as we pick one as the MTI. Note that MTI is not = necessarily mandatory to use. > >> > >> spt > >> > >> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: > >>> Thank you for raising the interoperability testing as we need to=20 > >>> plan for a bake-off that once > these questions get answered and the draft is ready. > >>> > >>> Thanks, > >>> Kathleen > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On=20 > >>> Behalf Of Sean Turner > >>> Sent: Monday, February 13, 2012 6:57 PM > >>> To: mile@ietf.org > >>> Subject: [mile] MTI SCI? > >>> > >>> There's 17 listed SCI (Structured Cybersecurity Information)=20 > >>> specifications in draft-ietf-mile-sci. Which one is the MTI=20 > >>> (mandatory to implement) choice? In other words, how will you get = > >>> two interoperability implementations without picking one? > >>> > >>> spt > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > . > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From Kent_Landfield@mcafee.com Tue Feb 14 08:45:31 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A7E21F85A4 for ; Tue, 14 Feb 2012 08:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 zuk+92JWDD6h for ; Tue, 14 Feb 2012 08:45:30 -0800 (PST) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id F1B4621F8593 for ; Tue, 14 Feb 2012 08:45:29 -0800 (PST) Received: from (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 023d_ccea_47ea991a_572b_11e1_b9f8_00219b929abd; Tue, 14 Feb 2012 10:45:19 -0600 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Tue, 14 Feb 2012 10:44:50 -0600 From: To: , , Date: Tue, 14 Feb 2012 10:45:24 -0600 Thread-Topic: [mile] MTI SCI? Thread-Index: AczrN/ffLyalN3N3TjqVgejm2jJiHQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB5FEB582C318kentlandfieldmcafeecom_" MIME-Version: 1.0 Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:45:31 -0000 --_000_CB5FEB582C318kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CVE is widely used and understood by all in the the security community. I a= gree with Tom that CVE is the path of least resistance but may be the most = useful for basic interoperability. Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: "Thomas.Millar@us-cert.gov" > Date: Tue, 14 Feb 2012 10:36:57 -0600 To: "david.black@emc.com" >, Bob Martin > Cc: "mile@ietf.org" > Subject: Re: [mile] MTI SCI? My concern with CAPEC being mandatory is that it could discourage effective= operational uptake of IODEF-SCI as the CAPEC vocabulary remains "too compr= ehensive" for many CSIRTs to employ during incident handling and reporting = activity. IODEF by itself has been criticized by CSIRT operators for being more heavy= weight than necessary for day-to-day usage; making CAPEC a mandatory aspect= of "advanced IODEF" seems like it would be adding ammunition to that argum= ent, especially if the CSIRT is having to fund implementation out of their = own pocket. Personally, I would have a hard time asking US-CERT's primary c= onstituents to implement IODEF + CAPEC if they are already balking at the c= onsultant and developer resources required to implement RFC 5070 by itself.= Also keep in mind that CAPEC references CybOX, so there's wheels within wh= eels now. I would prefer we take the path of least resistance (from my perspective) a= nd make CVE the MTI, if we have to pick one additional spec. CVE is well known, has years of familiarity built in, and I think it's the = simplest schema of the bunch. - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of david.black@emc.com Sent: Tuesday, February 14, 2012 11:14 To: ramartin@mitre.org Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? Hi Bob, I do appreciate the concern about implementing things that aren't going to = be used. OTOH, it may be useful to have a single simple MTI spec for SCI t= hat can be used to "smoke test" a deployment before trying any serious test= data (and "simple" is important). In addition, a concern that I would have with an MTI SCI spec per class is = that if two SCI implementations don't have at least one class in common, th= ey aren't going to interoperate, and that situation is unlikely to be accep= table to the IESG (i.e., with an MTI SCI spec per class, I suspect that the= re will also have to be an MTI class, which results in an overall MTI SCI s= pec). It may also be useful to include a simple example of the MTI SCI spec in an= appendix to simplify "smoke testing" (e.g., if the MTI SCI spec is CAPEC, = as Youki suggested, the appendix could contain a CAPEC XML document for tes= ting purposes, including enumeration values suitable for testing). What do you (and others) think about this? Thanks, --David -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Martin, Robert A. Sent: Tuesday, February 14, 2012 8:26 AM To: Brian Trammell Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? Brian, You beat me to this point. Like you, I would be concerned about a MTI selection that ended up requiring someone to implement something to meet the MTI but wasn't germane to anything else they intended to support. Bob On 2/14/12 4:19 AM, Brian Trammell wrote: > Hi, Sean, all, > > Looking over the spec, it's not clear to me that one MTI makes sense > here, given that mile-sci's purpose is to reference a set of external specifications by inclusion in an IODEF document, and that those external specifications represent fund= amentally different things. > > The specifications are split over their applicability to the IODEF > extension classes. I could envision an mile-sci implementation that was only interested a subset of these classes (perhaps even only one). If my implementation has an internal representation of Verification, but not of any of the other classes, and the MTI is an enumeration that is applicable to Vulnerability.= .. what do I do? > > What about selecting an MTI per class, instead? > > Best regards, > > Brian (as contributor) > > On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >> Great - as long as we pick one as the MTI. Note that MTI is not necessa= rily mandatory to use. >> >> spt >> >> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >>> Thank you for raising the interoperability testing as we need to >>> plan for a bake-off that once these questions get answered and the draft is ready. >>> >>> Thanks, >>> Kathleen >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-= bounces@ietf.org] On >>> Behalf Of Sean Turner >>> Sent: Monday, February 13, 2012 6:57 PM >>> To: mile@ietf.org >>> Subject: [mile] MTI SCI? >>> >>> There's 17 listed SCI (Structured Cybersecurity Information) >>> specifications in draft-ietf-mile-sci. Which one is the MTI >>> (mandatory to implement) choice? In other words, how will you get >>> two interoperability implementations without picking one? >>> >>> spt >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_CB5FEB582C318kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CVE = is widely used and understood by all in the the security community. I agree= with Tom that CVE is the path of least resistance but may be the most usef= ul for basic interoperability.

Kent Landfield=
Director Content= Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.= 8026
Web:=  www.mcafee.com

From: "Thomas.Millar@us-cert.gov" <Thomas.Millar@us-cert.gov>
Date: Tue, 14 Feb 2012 10:36:57 -0600
<= span style=3D"font-weight:bold">To: "david.black@emc.com" <david.black@emc.com>, Bob Martin <ramartin@mitre.org>
Cc:= "mile@ietf.org" <mile@ietf.org>
Subject: Re: [mile] MTI SCI?

My concern wi= th CAPEC being mandatory is that it could discourage effective operational = uptake of IODEF-SCI as the CAPEC vocabulary remains "too comprehensive" for= many CSIRTs to employ during incident handling and reporting activity.

IODEF by itself has been criticized by CSIRT operato= rs for being more heavyweight than necessary for day-to-day usage; making C= APEC a mandatory aspect of "advanced IODEF" seems like it would be adding a= mmunition to that argument, especially if the CSIRT is having to fund imple= mentation out of their own pocket. Personally, I would have a hard time ask= ing US-CERT's primary constituents to implement IODEF + CAPEC if they are a= lready balking at the consultant and developer resources required to implem= ent RFC 5070 by itself. Also keep in mind that CAPEC references CybOX, so t= here's wheels within wheels now.

I wou= ld prefer we take the path of least resistance (from my perspective) and ma= ke CVE the MTI, if we have to pick one additional spec.
CVE is we= ll known, has years of familiarity built in, and I think it's the simplest = schema of the bunch.


- Tom Millar= , US-CERT

BB: thomas.millar@dhs.gov / 202-631-1915
24x7: soc@us-cert.gov / 888-282-0870

-----Original Message-----
Sent: Tue= sday, February 14, 2012 11:14
Subject: Re: [mile] MTI SCI?

Hi Bob,

I do appreciate the concern about= implementing things that aren't going to be used.  OTOH, it may = be useful to have a single simple MTI spec for SCI that can be used to "smo= ke test" a deployment before trying any serious test data (and "simple" is = important).

In addition, a concern that I would ha= ve with an MTI SCI spec per class is that if two SCI implementations don't = have at least one class in common, they aren't going to interoperate, and t= hat situation is unlikely to be acceptable to the IESG (i.e., with an MTI S= CI spec per class, I suspect that there will also have to be an MTI class, = which results in an overall MTI SCI spec).

It may = also be useful to include a simple example of the MTI SCI spec in an append= ix to simplify "smoke testing" (e.g., if the MTI SCI spec is CAPEC, as Youk= i suggested, the appendix could contain a CAPEC XML document for testing pu= rposes, including enumeration values suitable for testing).

<= /div>
What do you (and others) think about this?

Thanks,
--David

-----Original Message-----
From:= mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Beh= alf Of Martin, Robert A.
Sent: Tuesday, February 14, 2012 8:26 A= M
To: Brian Trammell
Subject: Re: [mile] MTI SCI?
<= /div>
Brian,
You beat me to this point. &n= bsp;Like you, I would be concerned about a MTI
selection that e= nded up requiring someone to implement something to
meet the MT= I but wasn't germane to anything else they intended to support.
=
Bob
On 2/14/12 4:19 AM, Brian Trammell w= rote:
> Hi, Sean, all,
>
> Lookin= g over the spec, it's not clear to me that one MTI makes sense
= > here, given that mile-sci's
purpose is to reference a set o= f external specifications by inclusion
in an IODEF document, an= d that those external specifications represent fundamentally different thin= gs.
>
> The specifications are split over their= applicability to the IODEF
> extension classes. I could
envision an mile-sci implementation that was only interested a subs= et
of these classes (perhaps even only one). If my implementati= on has an
internal representation of Verification, but not of a= ny of the other
classes, and the MTI is an enumeration that is = applicable to Vulnerability... what do I do?
>
>= ; What about selecting an MTI per class, instead?
>
> Best regards,
>
> Brian (as contributor)=
>
> On Feb 14, 2012, at 1:19 AM, Sean Turner w= rote:
>
>> Great - as long as we pick one as= the MTI.  Note that MTI is not necessarily mandatory to use.
>>
>> spt
>>
>= ;> On 2/13/12 7:11 PM, kath= leen.moriarty@emc.com wrote:
>>> Thank you for rais= ing the interoperability testing as we need to
>>> pla= n for a bake-off that once
these questions get answered and the = draft is ready.
>>>
>>> Thanks,
>>> Kathleen
>>>
>>&g= t; -----Original Message-----
>>= ;> Behalf Of Sean Turner
>>> Sent: Monday, February = 13, 2012 6:57 PM
>>> To: mile@ietf.org
>>> Subject: [mile] MTI SCI?
=
>>>
>>> There's 17 listed SCI (Structure= d Cybersecurity Information)
>>> specifications in dra= ft-ietf-mile-sci.  Which one is the MTI
>>> = (mandatory to implement) choice?  In other words, how will you ge= t
>>> two interoperability implementations without pic= king one?
>>>
>>> spt
&g= t;>> _______________________________________________
>&= gt;> mile mailing list
>
= > _______________________________________________
> mile = mailing list
> .
>
_______________________________________________
mile mailing list

_______________________________________________
mile mail= ing list
=
_________________________________= ______________
mile mailing list

--_000_CB5FEB582C318kentlandfieldmcafeecom_-- From ramartin@mitre.org Tue Feb 14 08:46:08 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C635F21F86E3 for ; Tue, 14 Feb 2012 08:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] 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 PTG4vSQtIsWf for ; Tue, 14 Feb 2012 08:46:08 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C4CB721F8722 for ; Tue, 14 Feb 2012 08:46:07 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 278E021B0615; Tue, 14 Feb 2012 11:46:07 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E60A321B0979; Tue, 14 Feb 2012 11:46:06 -0500 (EST) Received: from mm169528-pc.mitre.org (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.339.1; Tue, 14 Feb 2012 11:46:06 -0500 Message-ID: <4F3A8FCE.80305@mitre.org> Date: Tue, 14 Feb 2012 11:46:06 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: References: <4F39A35E.7010000@ieca.com> <4F39A891.4060503@ieca.com> <4F3A60E4.7040700@mitre.org> <4F3A6452.6060709@ieca.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:46:08 -0000 I agree with Brian - one per extended area. Sorry if I wasn't clear. On 2/14/12 10:03 AM, kathleen.moriarty@emc.com wrote: > I agree with Sean here in that there has to be at least one mandatory so we know if the method used to incorporate schemas within IODE for exchange works... otherwise, we may need to tweak something in the draft before it moves to standard. Brian is arguing for one mandatory in each are of IODEF that is extended (valid point and an option we should consider). I think Bob you feel nothing should be mandatory or are you agreeing with Brian - one per extended area of IODEF? > > I think having one fail in the tests would also be good to make sure it happens in a way that works between implementations as well. > > Other opinions? Or agreement with any of the above opinions? > > (and my posts to MILE seem to be delayed... apologies) > > Thanks, > Kathleen > > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > Sent: Tuesday, February 14, 2012 8:41 AM > To: Martin, Robert A.; Brian Trammell > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? > > Coming from the ol'school world of ASN.1 (all the cool kids are doing > JSON now-a-days) when you have optional elements in say a sequence you > had to say which one was the MTI to ensure you got interop. In XML-land > that doesn't happen as much. There's a bunch of optional things and the > implementation gets to pick what it wants to support. That's great for > gaining the widest possible adoption of the spec, but not so great for > actually getting two implementations to interop. I'll be happy as long > as the WG comes up with a way to clearly describe what two > implementations need to do to interop. > > spt > > On 2/14/12 8:25 AM, Martin, Robert A. wrote: >> Brian, >> >> You beat me to this point. Like you, I would be concerned about a MTI >> selection that ended up requiring someone to implement something to meet >> the MTI but wasn't germane to anything else they intended to support. >> >> Bob >> >> On 2/14/12 4:19 AM, Brian Trammell wrote: >>> Hi, Sean, all, >>> >>> Looking over the spec, it's not clear to me that one MTI makes sense >>> here, given that mile-sci's purpose is to reference a set of external >>> specifications by inclusion in an IODEF document, and that those >>> external specifications represent fundamentally different things. >>> >>> The specifications are split over their applicability to the IODEF >>> extension classes. I could envision an mile-sci implementation that >>> was only interested a subset of these classes (perhaps even only one). >>> If my implementation has an internal representation of Verification, >>> but not of any of the other classes, and the MTI is an enumeration >>> that is applicable to Vulnerability... what do I do? >>> >>> What about selecting an MTI per class, instead? >>> >>> Best regards, >>> >>> Brian (as contributor) >>> >>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>> >>>> Great - as long as we pick one as the MTI. Note that MTI is not >>>> necessarily mandatory to use. >>>> >>>> spt >>>> >>>> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >>>>> Thank you for raising the interoperability testing as we need to >>>>> plan for a bake-off that once these questions get answered and the >>>>> draft is ready. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Sean Turner >>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>> To: mile@ietf.org >>>>> Subject: [mile] MTI SCI? >>>>> >>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>> specifications in draft-ietf-mile-sci. Which one is the MTI (mandatory >>>>> to implement) choice? In other words, how will you get two >>>>> interoperability implementations without picking one? >>>>> >>>>> spt >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> . >>> >> > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > . > From ramartin@mitre.org Tue Feb 14 08:49:39 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0326E21E803C for ; Tue, 14 Feb 2012 08:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 B5YMu+xl+lIS for ; Tue, 14 Feb 2012 08:49:38 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3121F873A for ; Tue, 14 Feb 2012 08:49:38 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A004B21B092D; Tue, 14 Feb 2012 11:49:37 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8470D21B0634; Tue, 14 Feb 2012 11:49:37 -0500 (EST) Received: from mm169528-pc.mitre.org (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.339.1; Tue, 14 Feb 2012 11:49:35 -0500 Message-ID: <4F3A909F.7060502@mitre.org> Date: Tue, 14 Feb 2012 11:49:35 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:49:39 -0000 At the risk of contradicting myself - but then again I have now read the other replies to this issue - I agree that having one area be the smoke test makes sense and I also agree that something simple and commonly used already - like CVE - is the best candidate for what we need. Bob On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > CVE is widely used and understood by all in the the security community. I agree with Tom that CVE is the path of least resistance but may be the most useful for basic interoperability. > > Kent Landfield > Director Content Strategy, Architecture and Standards > > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > > From: "Thomas.Millar@us-cert.gov"> > Date: Tue, 14 Feb 2012 10:36:57 -0600 > To: "david.black@emc.com">, Bob Martin> > Cc: "mile@ietf.org"> > Subject: Re: [mile] MTI SCI? > > My concern with CAPEC being mandatory is that it could discourage effective operational uptake of IODEF-SCI as the CAPEC vocabulary remains "too comprehensive" for many CSIRTs to employ during incident handling and reporting activity. > > IODEF by itself has been criticized by CSIRT operators for being more heavyweight than necessary for day-to-day usage; making CAPEC a mandatory aspect of "advanced IODEF" seems like it would be adding ammunition to that argument, especially if the CSIRT is having to fund implementation out of their own pocket. Personally, I would have a hard time asking US-CERT's primary constituents to implement IODEF + CAPEC if they are already balking at the consultant and developer resources required to implement RFC 5070 by itself. Also keep in mind that CAPEC references CybOX, so there's wheels within wheels now. > > I would prefer we take the path of least resistance (from my perspective) and make CVE the MTI, if we have to pick one additional spec. > CVE is well known, has years of familiarity built in, and I think it's the simplest schema of the bunch. > > > - Tom Millar, US-CERT > > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of david.black@emc.com > Sent: Tuesday, February 14, 2012 11:14 > To: ramartin@mitre.org > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? > > Hi Bob, > > I do appreciate the concern about implementing things that aren't going to be used. OTOH, it may be useful to have a single simple MTI spec for SCI that can be used to "smoke test" a deployment before trying any serious test data (and "simple" is important). > > In addition, a concern that I would have with an MTI SCI spec per class is that if two SCI implementations don't have at least one class in common, they aren't going to interoperate, and that situation is unlikely to be acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect that there will also have to be an MTI class, which results in an overall MTI SCI spec). > > It may also be useful to include a simple example of the MTI SCI spec in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML document for testing purposes, including enumeration values suitable for testing). > > What do you (and others) think about this? > > Thanks, > --David > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > Sent: Tuesday, February 14, 2012 8:26 AM > To: Brian Trammell > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? > Brian, > You beat me to this point. Like you, I would be concerned about a MTI > selection that ended up requiring someone to implement something to > meet the MTI but wasn't germane to anything else they intended to support. > Bob > On 2/14/12 4:19 AM, Brian Trammell wrote: >> Hi, Sean, all, >> >> Looking over the spec, it's not clear to me that one MTI makes sense >> here, given that mile-sci's > purpose is to reference a set of external specifications by inclusion > in an IODEF document, and that those external specifications represent fundamentally different things. >> >> The specifications are split over their applicability to the IODEF >> extension classes. I could > envision an mile-sci implementation that was only interested a subset > of these classes (perhaps even only one). If my implementation has an > internal representation of Verification, but not of any of the other > classes, and the MTI is an enumeration that is applicable to Vulnerability... what do I do? >> >> What about selecting an MTI per class, instead? >> >> Best regards, >> >> Brian (as contributor) >> >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >> >>> Great - as long as we pick one as the MTI. Note that MTI is not necessarily mandatory to use. >>> >>> spt >>> >>> On 2/13/12 7:11 PM, kathleen.moriarty@emc.com wrote: >>>> Thank you for raising the interoperability testing as we need to >>>> plan for a bake-off that once > these questions get answered and the draft is ready. >>>> >>>> Thanks, >>>> Kathleen >>>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>> Behalf Of Sean Turner >>>> Sent: Monday, February 13, 2012 6:57 PM >>>> To: mile@ietf.org >>>> Subject: [mile] MTI SCI? >>>> >>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>> (mandatory to implement) choice? In other words, how will you get >>>> two interoperability implementations without picking one? >>>> >>>> spt >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> . >> > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > From Thomas.Millar@us-cert.gov Tue Feb 14 09:34:15 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E883521E8095 for ; Tue, 14 Feb 2012 09:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.289 X-Spam-Level: X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, 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 LofQfKmQVhSs for ; Tue, 14 Feb 2012 09:34:15 -0800 (PST) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [208.73.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4FF21E8084 for ; Tue, 14 Feb 2012 09:34:15 -0800 (PST) Received: from daphne.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 9A1B63F3BB; Tue, 14 Feb 2012 17:34:14 +0000 (UTC) Received: from yabba.bronze.us-cert.gov (yabba.bronze.us-cert.gov [192.168.2.22]) by daphne.brass.us-cert.gov (Postfix) with ESMTP id 727913F235; Tue, 14 Feb 2012 17:34:14 +0000 (UTC) Received: from needle.bronze.us-cert.gov (unknown [192.168.16.109]) by yabba.bronze.us-cert.gov (Postfix) with ESMTP id 331783006A; Tue, 14 Feb 2012 17:34:14 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 11:34:13 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Feb 2012 11:34:12 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] Working group last call on Template draft Thread-Index: Aczq8Yx36wI5eLS6TxuK5klyENz3EgATTxKA References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> From: To: X-OriginalArrivalTime: 14 Feb 2012 17:34:13.0853 (UTC) FILETIME=[DE6480D0:01CCEB3E] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18710.000 X-TM-AS-Result: No--25.094-5.0-31-1 X-imss-scan-details: No--25.094-5.0-31-1 X-IMSS-DKIM-White-List: No Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:34:16 -0000 Does "encoding" mean more than we think it means? Maybe "Value meaning = and format" - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Tuesday, February 14, 2012 03:21 To: Millar, Thomas R Cc: mile@ietf.org; kathleen.moriarty@emc.com Subject: Re: [mile] Working group last call on Template draft Hi, Tom, Thanks for the comments. Will incorporate in the -01 working copy (to be = submitted after the end of the WGLC, tomorrow).=20 With respect to the meaning of the ext-value, I think we need to = explicitly address that this should describe semantics as well as = representation; so how about "value meaning and encoding"? Best regards, Brian (author hat) On Feb 13, 2012, at 10:41 PM, = wrote: > In Section 3, when discussing extension types for enumerated lists, I = think it might be useful to specifically reference section 5.1 of RFC = 5070 as well.=20 >=20 > Under the "Example Enumerated Type Extension Definition," for the = example given, "content format" applies in the context of = Address@category, but it wouldn't work everywhere. For other extensible = enumerated lists, such as those under Impact@type, the meaning of the = ext-value might better be described by the term "value meaning" which = should be generic enough to cover all the expectation-setting the = various extensible lists can cover. >=20 > Thank you, >=20 > - Tom Millar, US-CERT >=20 > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870=20 >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of kathleen.moriarty@emc.com > Sent: Wednesday, February 01, 2012 07:34 > To: trammell@tik.ee.ethz.ch > Cc: mile@ietf.org > Subject: [mile] Working group last call on Template draft >=20 > Hello, >=20 > We are starting a 2 week review period, the working group last call = (WGLC) for draft-ietf-mile-template. Please review and comment to the = MILE list on the template draft. =20 >=20 > This is a short one and is used to provide a template for all = extensions defined in MILE. >=20 > http://tools.ietf.org/html/draft-ietf-mile-template-00 >=20 > Last call on comments will end the morning of February 15th. >=20 > Thank you, > Kathleen (as WG chair) >=20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, February 01, 2012 5:41 AM > To: Moriarty, Kathleen > Cc: mile@ietf.org > Subject: next up: mile-template >=20 > Hi, Kathleen, all, >=20 > Now that the WG work on 6045-bis and 6046-bis is complete, and = (almost) in accordance with the charter, I believe the present revision = of draft-ietf-mile-template to be ready for WGLC. >=20 > Many thanks, best regards, >=20 > Brian Trammell (as author of mile-template) = _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Feb 14 10:36:54 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235D621F870F for ; Tue, 14 Feb 2012 10:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 xJMcIlN-GUpg for ; Tue, 14 Feb 2012 10:36:53 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE221F86FE for ; Tue, 14 Feb 2012 10:36:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D7CBBD9309; Tue, 14 Feb 2012 19:36:51 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3V+3KmMkrmHy; Tue, 14 Feb 2012 19:36:51 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8649AD9300; Tue, 14 Feb 2012 19:36:51 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Tue, 14 Feb 2012 19:36:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3514A9CE-D18E-4C9F-8FD0-71F35B2B99BD@tik.ee.ethz.ch> To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] Working group last call on Template draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:36:54 -0000 Hi, Thomas, Point. Value meaning and format it is. Cheers, Brian (author hat) On Feb 14, 2012, at 6:34 PM, wrote: > Does "encoding" mean more than we think it means? Maybe "Value meaning = and format" >=20 > - Tom Millar, US-CERT >=20 > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870=20 >=20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 > Sent: Tuesday, February 14, 2012 03:21 > To: Millar, Thomas R > Cc: mile@ietf.org; kathleen.moriarty@emc.com > Subject: Re: [mile] Working group last call on Template draft >=20 > Hi, Tom, >=20 > Thanks for the comments. Will incorporate in the -01 working copy (to = be submitted after the end of the WGLC, tomorrow).=20 >=20 > With respect to the meaning of the ext-value, I think we need to = explicitly address that this should describe semantics as well as = representation; so how about "value meaning and encoding"? >=20 > Best regards, >=20 > Brian (author hat) >=20 > On Feb 13, 2012, at 10:41 PM, = wrote: >=20 >> In Section 3, when discussing extension types for enumerated lists, I = think it might be useful to specifically reference section 5.1 of RFC = 5070 as well.=20 >>=20 >> Under the "Example Enumerated Type Extension Definition," for the = example given, "content format" applies in the context of = Address@category, but it wouldn't work everywhere. For other extensible = enumerated lists, such as those under Impact@type, the meaning of the = ext-value might better be described by the term "value meaning" which = should be generic enough to cover all the expectation-setting the = various extensible lists can cover. >>=20 >> Thank you, >>=20 >> - Tom Millar, US-CERT >>=20 >> thomas.millar@us-cert.gov >> BB: thomas.millar@dhs.gov / 202-631-1915 >> 24x7: soc@us-cert.gov / 888-282-0870=20 >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of kathleen.moriarty@emc.com >> Sent: Wednesday, February 01, 2012 07:34 >> To: trammell@tik.ee.ethz.ch >> Cc: mile@ietf.org >> Subject: [mile] Working group last call on Template draft >>=20 >> Hello, >>=20 >> We are starting a 2 week review period, the working group last call = (WGLC) for draft-ietf-mile-template. Please review and comment to the = MILE list on the template draft. =20 >>=20 >> This is a short one and is used to provide a template for all = extensions defined in MILE. >>=20 >> http://tools.ietf.org/html/draft-ietf-mile-template-00 >>=20 >> Last call on comments will end the morning of February 15th. >>=20 >> Thank you, >> Kathleen (as WG chair) >>=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Wednesday, February 01, 2012 5:41 AM >> To: Moriarty, Kathleen >> Cc: mile@ietf.org >> Subject: next up: mile-template >>=20 >> Hi, Kathleen, all, >>=20 >> Now that the WG work on 6045-bis and 6046-bis is complete, and = (almost) in accordance with the charter, I believe the present revision = of draft-ietf-mile-template to be ready for WGLC. >>=20 >> Many thanks, best regards, >>=20 >> Brian Trammell (as author of mile-template) = _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Wed Feb 15 01:15:48 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4038021F8581 for ; Wed, 15 Feb 2012 01:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_QP_LONG_LINE=1.396] 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 kObxnsWmXQ8N for ; Wed, 15 Feb 2012 01:15:43 -0800 (PST) Received: from mow.securemx.jp (mow301.securemx.jp [210.130.202.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6868F21F864D for ; Wed, 15 Feb 2012 01:15:40 -0800 (PST) Received: by mow.securemx.jp (mow301) id q1F9Fc3C032113; Wed, 15 Feb 2012 18:15:38 +0900 X-MXL-Hash: 4f3b77b85e2d8475-fe4b465178bf234dbede4a1cbdd41929490827ab Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by relay.securemx.jp (mx-mr300) id q1F9Fa7M012298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 18:15:36 +0900 Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q1F9FaWj026699 for ; Wed, 15 Feb 2012 18:15:36 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q1F9FZOR025076 for ; Wed, 15 Feb 2012 18:15:35 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q1F9FZk7025073 for ; Wed, 15 Feb 2012 18:15:35 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id CA2371661F for ; Wed, 15 Feb 2012 18:15:34 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail3.nict.go.jp (NICT Mail) with ESMTP id AD76E16562 for ; Wed, 15 Feb 2012 18:15:34 +0900 (JST) From: "Takeshi Takahashi" To: References: <4F3A909F.7060502@mitre.org> In-Reply-To: <4F3A909F.7060502@mitre.org> Date: Wed, 15 Feb 2012 18:15:38 +0900 Message-ID: <004101ccebc2$61941820$24bc4860$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0042_01CCEC0D.D17CAA80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjelZm9LiA= Content-Language: ja Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 09:15:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01CCEC0D.D17CAA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, Following the discussion, I would like to add a couple of sentences to clarify the MTI issues. (Thank you very much for those of you who kindly provided useful discussion.) I've attached the working version of the draft. I hope it helps to clarify the changes. (added sentences at the end of section 4.1) The SpecID attributes of extended classes (Section 4.3) must allow the values of the specifications' namespace fields, but otherwise, implementations are not required to support all the above specifications. Implementations may choose which specifications to support, though CVE 1.0 (Section 4.1.7) needs to be minimally supported. In case an implementation received a data it does not support, it may expand its functionality by looking up the IANA table or notify the sender of its inability to parse the data by using any means defined outside the scope of this specification. On the other hand, I would like to add "STRING ext-SpecID" to each class, which enables to embed data following private schema. For instance, one security operation center (SOC) may wish to exchange a vulnerability data that is formatted in its own private schema, and that is not formatted in CVE. In this case, the SOC may put the data's schema ID inside ext-SpecID and then embed the data. It could also be used to exchange data using beta version of specifications. The class could be seen as below. +------------------------+ | AttackPattern | +------------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING AttackPatternID |<>--(0..*)-[ Platform ] +------------------------+ SpecID: REQUIRED. ENUM. The identifier of the specification specifying the format of the RawData element. The value should be chosen from the namespaces [XMLNames] listed in Section 4.1 or "private". Note that the lists in Section 4.1 will be developed further by IANA. The value "private" is prepared for conveying RawData based on a format that is not listed in the table. This is usually used for conveying data formatted according to an organization's private schema. When the value "private" is used, ext-SpecID element needs to be used. ext-SpecID: OPTIONAL. STRING. The identifier of the specification specifying the format of the RawData element. When this element is used, the value of SpecID element must be "private." I hope above changes don't cause any complication here. Sincerely, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Martin, Robert A. > Sent: Wednesday, February 15, 2012 1:50 AM > To: Kent_Landfield@McAfee.com > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? > > At the risk of contradicting myself - but then again I have now read the > other replies to this issue - I agree that having one area be the smoke > test makes sense and I also agree that something simple and commonly used > already - like CVE - is the best candidate for what we need. > > Bob > > On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > CVE is widely used and understood by all in the the security community. > I agree with Tom that CVE is the path of least resistance but may be the > most useful for basic interoperability. > > > > Kent Landfield > > Director Content Strategy, Architecture and Standards > > > > McAfee | An Intel Company > > 5000 Headquarters Dr. > > Plano, Texas 75024 > > > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > Web: www.mcafee.com > > > > From: > > > "Thomas.Millar@us-cert.gov" .M > > illar@us-cert.gov> > > Date: Tue, 14 Feb 2012 10:36:57 -0600 > > To: > > > "david.black@emc.com" m< > > mailto:david.black@emc.com>>, Bob > > Martin> > > Cc: > > > "mile@ietf.org" .o > > rg>> > > Subject: Re: [mile] MTI SCI? > > > > My concern with CAPEC being mandatory is that it could discourage > effective operational uptake of IODEF-SCI as the CAPEC vocabulary remains > "too comprehensive" for many CSIRTs to employ during incident handling > and reporting activity. > > > > IODEF by itself has been criticized by CSIRT operators for being more > heavyweight than necessary for day-to-day usage; making CAPEC a mandatory > aspect of "advanced IODEF" seems like it would be adding ammunition to > that argument, especially if the CSIRT is having to fund implementation > out of their own pocket. Personally, I would have a hard time asking > US-CERT's primary constituents to implement IODEF + CAPEC if they are > already balking at the consultant and developer resources required to > implement RFC 5070 by itself. Also keep in mind that CAPEC references > CybOX, so there's wheels within wheels now. > > > > I would prefer we take the path of least resistance (from my perspective) > and make CVE the MTI, if we have to pick one additional spec. > > CVE is well known, has years of familiarity built in, and I think it's > the simplest schema of the bunch. > > > > > > - Tom Millar, US-CERT > > > > thomas.millar@us-cert.gov > > BB: thomas.millar@dhs.gov / > > 202-631-1915 > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > -----Original Message----- > > From: mile-bounces@ietf.org > > [mailto:mile-bounces@ietf.org] On Behalf Of > > david.black@emc.com > > Sent: Tuesday, February 14, 2012 11:14 > > To: ramartin@mitre.org > > Cc: mile@ietf.org > > Subject: Re: [mile] MTI SCI? > > > > Hi Bob, > > > > I do appreciate the concern about implementing things that aren't going > to be used. OTOH, it may be useful to have a single simple MTI spec for > SCI that can be used to "smoke test" a deployment before trying any serious > test data (and "simple" is important). > > > > In addition, a concern that I would have with an MTI SCI spec per class > is that if two SCI implementations don't have at least one class in common, > they aren't going to interoperate, and that situation is unlikely to be > acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect > that there will also have to be an MTI class, which results in an overall > MTI SCI spec). > > > > It may also be useful to include a simple example of the MTI SCI spec > in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec > is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML > document for testing purposes, including enumeration values suitable for > testing). > > > > What do you (and others) think about this? > > > > Thanks, > > --David > > > > -----Original Message----- > > From: mile-bounces@ietf.org > [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > Sent: Tuesday, February 14, 2012 8:26 AM > > To: Brian Trammell > > Cc: mile@ietf.org > > Subject: Re: [mile] MTI SCI? > > Brian, > > You beat me to this point. Like you, I would be concerned about a MTI > > selection that ended up requiring someone to implement something to > > meet the MTI but wasn't germane to anything else they intended to > support. > > Bob > > On 2/14/12 4:19 AM, Brian Trammell wrote: > >> Hi, Sean, all, > >> > >> Looking over the spec, it's not clear to me that one MTI makes sense > >> here, given that mile-sci's > > purpose is to reference a set of external specifications by inclusion > > in an IODEF document, and that those external specifications represent > fundamentally different things. > >> > >> The specifications are split over their applicability to the IODEF > >> extension classes. I could > > envision an mile-sci implementation that was only interested a subset > > of these classes (perhaps even only one). If my implementation has an > > internal representation of Verification, but not of any of the other > > classes, and the MTI is an enumeration that is applicable to > Vulnerability... what do I do? > >> > >> What about selecting an MTI per class, instead? > >> > >> Best regards, > >> > >> Brian (as contributor) > >> > >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >> > >>> Great - as long as we pick one as the MTI. Note that MTI is not > necessarily mandatory to use. > >>> > >>> spt > >>> > >>> On 2/13/12 7:11 PM, > kathleen.moriarty@emc.com wrote: > >>>> Thank you for raising the interoperability testing as we need to > >>>> plan for a bake-off that once > > these questions get answered and the draft is ready. > >>>> > >>>> Thanks, > >>>> Kathleen > >>>> > >>>> -----Original Message----- > >>>> From: mile-bounces@ietf.org > >>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > >>>> Sent: Monday, February 13, 2012 6:57 PM > >>>> To: mile@ietf.org > >>>> Subject: [mile] MTI SCI? > >>>> > >>>> There's 17 listed SCI (Structured Cybersecurity Information) > >>>> specifications in draft-ietf-mile-sci. Which one is the MTI > >>>> (mandatory to implement) choice? In other words, how will you get > >>>> two interoperability implementations without picking one? > >>>> > >>>> spt > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > >> . > >> > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0042_01CCEC0D.D17CAA80 Content-Type: text/plain; name="draft-ietf-mile-sci-03candidate_20120215.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-mile-sci-03candidate_20120215.txt" =0A= =0A= =0A= MILE Working Group T. Takahashi=0A= Internet-Draft NICT=0A= Intended status: Standards Track K. Landfield=0A= Expires: August 18, 2012 McAfee=0A= T. Millar=0A= USCERT=0A= Y. Kadobayashi=0A= NAIST=0A= Feb 15, 2012=0A= =0A= =0A= IODEF-extension to support structured cybersecurity information=0A= draft-ietf-mile-sci-03.txt=0A= =0A= Abstract=0A= =0A= This document extends the Incident Object Description Exchange Format=0A= (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched=0A= cybersecurity information exchange among cybersecurity entities by=0A= embedding structured information formatted by specifications,=0A= including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R)=0A= [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL=0A= [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF].=0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on August 18, 2012.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2012 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 1]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 2]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5=0A= 4.1. List of Supported Structured Cybersecurity Information=0A= Specifictions . . . . . . . . . . . . . . . . . . . . . . 5=0A= 4.1.1. CAPEC 1.6 . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4.1.2. CCE 5.0 . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4.1.3. CCSS 1.0 . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4.1.4. CEE 0.6 . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4.1.5. CPE 2.3 Language . . . . . . . . . . . . . . . . . . . 7=0A= 4.1.6. CPE 2.3 Dictionary . . . . . . . . . . . . . . . . . . 7=0A= 4.1.7. CVE 1.0 . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 4.1.8. CVRF 1.0 . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 4.1.9. CVSS 2.0 . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 4.1.10. CWE 5.0 . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 4.1.11. CWSS 0.8 . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 4.1.12. MAEC 2.0 . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 4.1.13. OCIL 2.0 . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 4.1.14. OVAL 5.10.1 Definitions . . . . . . . . . . . . . . . 8=0A= 4.1.15. OVAL 5.10.1 Results . . . . . . . . . . . . . . . . . 8=0A= 4.1.16. OVAL 5.10.1 Common . . . . . . . . . . . . . . . . . . 8=0A= 4.1.17. XCCDF 1.2 . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.2. Extended Data Types . . . . . . . . . . . . . . . . . . . 9=0A= 4.2.1. XMLDATA . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.3. Extended Classes . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.3.1. AttackPattern . . . . . . . . . . . . . . . . . . . . 10=0A= 4.3.2. Platform . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 4.3.3. Vulnerability . . . . . . . . . . . . . . . . . . . . 13=0A= 4.3.4. Scoring . . . . . . . . . . . . . . . . . . . . . . . 15=0A= 4.3.5. Weakness . . . . . . . . . . . . . . . . . . . . . . . 16=0A= 4.3.6. EventReport . . . . . . . . . . . . . . . . . . . . . 18=0A= 4.3.7. Verifcation . . . . . . . . . . . . . . . . . . . . . 19=0A= 4.3.8. Remediation . . . . . . . . . . . . . . . . . . . . . 20=0A= 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21=0A= 5.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 22=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22=0A= 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 8. Appendix I: XML Schema Definition for Extension . . . . . . . 24=0A= 9. Appendix II: XML Examples . . . . . . . . . . . . . . . . . . 28=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . . 34=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34=0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 3]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= 1. Introduction=0A= =0A= Cyber attacks are getting more sophisticated, and their numbers are=0A= increasing day by day. To cope with such situation, incident=0A= information needs to be reported, exchanged, and shared among=0A= organizations. IODEF is one of the tools enabling such exchange, and=0A= is already in use.=0A= =0A= To efficiently run cybersecurity operations, these exchanged=0A= information needs to be machine-readable. IODEF provides a=0A= structured means to describe the information, but it needs to embed=0A= various non-structured such information in order to convey detailed=0A= information. Further structure within IODEF increases IODEF=0A= documents' machine-readability and thus facilitates streamlining=0A= cybersecurity operations.=0A= =0A= On the other hand, there exist various other activities facilitating=0A= detailed and structured description of cybersecurity information,=0A= major of which includes CAPEC [CAPEC], CEE [CEE], CPE [CPE], CVE=0A= [CVE], CVRF [CVRF], CVSS [CVSS], CWE [CWE], CWSS [CWSS], OCIL [OCIL],=0A= OVAL [OVAL], and XCCDF [XCCDF]. Since such structured description=0A= facilitates cybersecurity operations, it would be beneficial to embed=0A= and convey these information inside IODEF document.=0A= =0A= To enable that, this document extends the IODEF to embed and convey=0A= various structured cybersecurity information, with which=0A= cybersecurity operations can be facilitated. Since IODEF defines a=0A= flexible and extensible format and supports a granular level of=0A= specificity, this document defines an extension to IODEF instead of=0A= defining a new report format. For clarity, and to eliminate=0A= duplication, only the additional structures necessary for describing=0A= the exchange of such structured information are provided.=0A= =0A= =0A= 2. Terminology=0A= =0A= The terminology used in this document follows the one defined in RFC=0A= 5070 [RFC5070].=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= =0A= 3. Applicability=0A= =0A= To maintain cybersecurity, organization needs to exchange=0A= cybersecurity information, which includes the following information:=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 4]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= attack pattern, platform information, vulnerability and weakness,=0A= countermeasure instruction, computer event log, and the severity.=0A= =0A= IODEF provides a scheme to exchange such information among interested=0A= parties. However, the detailed common format to describe such=0A= information is not defined in the IODEF base document.=0A= =0A= On the other hand, to describe those information and to facilitate=0A= exchange, a structured format for that is already available. Major=0A= of them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OCIL, OVAL,=0A= and XCCDF. By embedding them into the IODEF document, the document=0A= can convey more detailed contents to the receivers, and the document=0A= can be easily reused. Note that interactive communication is needed=0A= in some cases, and some of these structured information, e.g., OCIL=0A= information, solicits reply from recipients. These reply could be=0A= also embedded inside the IODEF document.=0A= =0A= These structured cybersecurity information facilitates cybersecurity=0A= operation at the receiver side. Since the information is machine-=0A= readable, the data can be processed by computers. That expedites the=0A= automation of cybersecurity operations=0A= =0A= For instance, an organization wishing to report a security incident=0A= wants to describe what vulnerability was exploited. Then the sender=0A= can simply use IODEF, where an CAPEC record is embedded instead of=0A= describing everything in free format text. Receiver can also=0A= identify the needed details of the attack pattern by looking up some=0A= of the xml [XML1.0] tags defined by CAPEC. Receiver can accumulate=0A= the attack pattern information (CAPEC record) in its database and=0A= could distribute it to the interested parties if needed, without=0A= needing human interventions.=0A= =0A= =0A= 4. Extension Definition=0A= =0A= This draft extends IODEF to embed structured cybersecurity=0A= information by introducing new classes, with which these information=0A= can be embedded inside IODEF document as element contents of=0A= AdditionalData and RecordItem classes.=0A= =0A= 4.1. List of Supported Structured Cybersecurity Information=0A= Specifictions=0A= =0A= This extension embeds structured cybersecurity information from=0A= external specifications. The initial list of supported=0A= specifications is listed below. Each entry has namespace [XMLNames],=0A= specification name, version, specification URI and applicable classes=0A= for each specification. Future assignments are to be managed by IANA=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 5]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= using the Expert Review [RFC5226] and Specification Required=0A= [RFC5226] allocation policies as further specified in Section 6.=0A= =0A= The SpecID attributes of extended classes (Section 4.3) must allow=0A= the values of the specifications' namespace fields, but otherwise,=0A= implementations are not required to support all the above=0A= specifications. Implementations may choose which specifications to=0A= support, though CVE 1.0 (Section 4.1.7) needs to be minimally=0A= supported. In case an implementation received a data it does not=0A= support, it may expand its functionality by looking up the IANA table=0A= or notify the sender of its inability to parse the data by using any=0A= means defined outside the scope of this specification.=0A= =0A= 4.1.1. CAPEC 1.6=0A= =0A= Namespace: http://capec.mitre.org/observables=0A= Specification Name: Common Attack Pattern Enumeration and = Classification=0A= Version: 1.6=0A= Specification URI: http://capec.mitre.org/=0A= Applicable Classes: AttackPattern=0A= =0A= 4.1.2. CCE 5.0=0A= =0A= Namespace: http://cce.mitre.org=0A= Specification Name: Common Configuration Enumeration=0A= Version: 5.0=0A= Specification URI: http://cce.mitre.org/=0A= Applicable Classes: Verification=0A= =0A= 4.1.3. CCSS 1.0=0A= =0A= Namespace: N/A=0A= Specification Name: Common Configuration Scoring System=0A= Version: 1.0=0A= Specification URI: TBD=0A= Applicable Classes: Scoring=0A= =0A= 4.1.4. CEE 0.6=0A= =0A= Namespace: http://cee.mitre.org=0A= Specification Name: Common Event Expression=0A= Version: 0.6=0A= Specification URI: http://cee.mitre.org/=0A= Applicable Classes: EventReport=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 6]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= 4.1.5. CPE 2.3 Language=0A= =0A= Namespace: http://cpe.mitre.org/language/2.0=0A= Specification Name: Common Platform Enumeration Reference=0A= Version: 2.3=0A= Specification URI: http://scap.nist.gov/specifications/cpe/=0A= Applicable Classes: Platform=0A= =0A= 4.1.6. CPE 2.3 Dictionary=0A= =0A= Namespace: http://cpe.mitre.org/dictionary/2.0=0A= Specification Name: Common Platform Enumeration Dictionary=0A= Version: 2.3=0A= Specification URI: http://scap.nist.gov/specifications/cpe/=0A= Applicable Classes: Platform=0A= =0A= 4.1.7. CVE 1.0=0A= =0A= Namespace: http://cve.mitre.org/cve/downloads/1.0=0A= Specification Name: Common Vulnerability and Exposures=0A= Version: 1.0=0A= Specification URI: http://cve.mitre.org/=0A= Applicable Classes: Vulnerability=0A= =0A= 4.1.8. CVRF 1.0=0A= =0A= Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0=0A= Specification Name: Common Vulnerability Reporting Format=0A= Version: 1.0=0A= Specification URI: http://www.icasi.org/cvrf=0A= Applicable Classes: Vulnerability=0A= =0A= 4.1.9. CVSS 2.0=0A= =0A= Namespace: http://scap.nist.gov/schema/cvss-v2/1.0=0A= Specification Name: Common Vulnerability Scoring System=0A= Version: 2=0A= Specification URI: http://www.first.org/cvss=0A= Applicable Classes: Scoring=0A= =0A= 4.1.10. CWE 5.0=0A= =0A= Namespace: N/A=0A= Specification Name: Common Weakness Enumeration=0A= Version: 5.1=0A= Specification URI: http://cwe.mitre.org/=0A= Applicable Classes: Weakness=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 7]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= 4.1.11. CWSS 0.8=0A= =0A= Namespace: N/A=0A= Specification Name: Common Weakness Scoring System=0A= Version: 0.8=0A= Specification URI: http://cwe.mitre.org/cwss/=0A= Applicable Classes: Scoring=0A= =0A= 4.1.12. MAEC 2.0=0A= =0A= Namespace: http://maec.mitre.org/XMLSchema/maec-core-2=0A= Specification Name: Malware Attribute Enumeration and Characterization=0A= Version: 2.0=0A= Specification URI: http://maec.mitre.org/=0A= Applicable Classes: EventReport, AttackPattern=0A= =0A= 4.1.13. OCIL 2.0=0A= =0A= Namespace: http://scap.nist.gov/schema/ocil/2.0=0A= Specification Name: Open Checklist Interactive Language=0A= Version: 2.0=0A= Specification URI: http://scap.nist.gov/specifications/ocil/=0A= Applicable Classes: Verification=0A= =0A= 4.1.14. OVAL 5.10.1 Definitions=0A= =0A= Namespace: = http://oval.mitre.org/XMLSchema/oval-definitions-5=0A= Specification Name: Open Vulnerability and Assessment Language=0A= Version: 5.10.1=0A= Specification URI: http://oval.mitre.org/=0A= Applicable Classes: Verification=0A= =0A= 4.1.15. OVAL 5.10.1 Results=0A= =0A= Namespace: http://oval.mitre.org/XMLSchema/oval-results-5=0A= Specification Name: Open Vulnerability and Assessment Language=0A= Version: 5.10.1=0A= Specification URI: TBD=0A= Applicable Classes: Verification=0A= =0A= 4.1.16. OVAL 5.10.1 Common=0A= =0A= Namespace: http://oval.mitre.org/XMLSchema/oval-common-5=0A= Specification Name: Open Vulnerability and Assessment Language=0A= Version: 5.10.1=0A= Specification URI: TBD=0A= Applicable Classes: Verification=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 8]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= 4.1.17. XCCDF 1.2=0A= =0A= Namespace: http://checklists.nist.gov/xccdf/1.2=0A= Specification Name: Extensible Configuration Checklist Description = Format=0A= Version: 1.2=0A= Specification URI: http://scap.nist.gov/specifications/xccdf/=0A= Applicable Classes: Verification=0A= =0A= 4.2. Extended Data Types=0A= =0A= This extension inherits all of the data types defined in the IODEF=0A= model. One data type is added: XMLDATA.=0A= =0A= 4.2.1. XMLDATA=0A= =0A= An embedded XML data is represented by the XMLDATA data type. This=0A= type is defined as the extension to the iodef:ExtensionType=0A= [RFC5070], whose dtype attribute is set to "xml."=0A= =0A= 4.3. Extended Classes=0A= =0A= The IODEF Incident element [RFC5070] is summarized below. It is=0A= expressed in Unified Modeling Language (UML) syntax as used in the=0A= IODEF specification. The UML representation is for illustrative=0A= purposes only; elements are specified in XML as defined in Appendix=0A= A.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 9]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= +--------------------+=0A= | Incident |=0A= +--------------------+=0A= | ENUM purpose |<>---------[IncidentID]=0A= | STRING ext-purpose |<>--{0..1}-[AlternativeID]=0A= | ENUM lang |<>--{0..1}-[RelatedActivity]=0A= | ENUM restriction |<>--{0..1}-[DetectTime]=0A= | |<>--{0..1}-[StartTime]=0A= | |<>--{0..1}-[EndTime]=0A= | |<>---------[ReportTime]=0A= | |<>--{0..*}-[Description]=0A= | |<>--{1..*}-[Assessment]=0A= | |<>--{0..*}-[Method]=0A= | | |<>--[AdditionalData]=0A= | | |<>--[AttackPattern]=0A= | | |<>--[Vulnerability]=0A= | | |<>--[Weakness]=0A= | |<>--{1..*}-[Contact]=0A= | |<>--{0..*}-[EventData]=0A= | | |<>--[Flow]=0A= | | | |<>--[System]=0A= | | | |<>--[AdditionalData]=0A= | | | |<>--[Platform]=0A= | | |<>--[Expectation]=0A= | | |<>--[Record]=0A= | | |<>--[RecordData]=0A= | | |<>--[RecordItem]=0A= | | |<>--[EventReport]=0A= | |<>--{0..1}-[History]=0A= | |<>--{0..*}-[AdditionalData]=0A= | | |<>--[Verification]=0A= | | |<>--[Remediation]=0A= +--------------------+=0A= =0A= Figure 1: Incident class=0A= =0A= This extension defines the following seven elements.=0A= =0A= 4.3.1. AttackPattern=0A= =0A= An AttackPattern consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". The=0A= extension describes attack patterns of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain one or more of the=0A= extension elements whenever available.=0A= =0A= An AttackPattern class is structured as follows.=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 10]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= +------------------------+=0A= | AttackPattern |=0A= +------------------------+=0A= | ENUM SpecID |<>--(0..*)-[ RawData ]=0A= | STRING ext-SpecID |<>--(0..*)-[ Reference ]=0A= | STRING AttackPatternID |<>--(0..*)-[ Platform ]=0A= +------------------------+=0A= =0A= Figure 2: AttackPattern class=0A= =0A= This class has the following attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1 or=0A= "private". Note that the lists in Section 4.1 will be developed=0A= further by IANA. In case a RawData or Reference element is=0A= provided along with this attribute, writers/senders MUST ensure=0A= that this value is consistent with the one provided by the=0A= element; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer this attribute's value, and SHOULD log the inconsistency so=0A= a human can correct the problem. The value "private" is prepared=0A= for conveying RawData based on a format that is not listed in the=0A= table. This is usually used for conveying data formatted=0A= according to an organization's private schema. When the value=0A= "private" is used, ext-SpecID element needs to be used.=0A= =0A= ext-SpecID: OPTIONAL. STRING. The identifier of the specification=0A= specifying the format of the RawData element. When this element=0A= is used, the value of SpecID element must be "private." In case a=0A= RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this value is=0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer this=0A= attribute's value, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= AttackPatternID: OPTIONAL. STRING. An identifier of an attack=0A= pattern to be reported. This attribute SHOULD be used whenever=0A= such identifier is available, but could be omitted if no such one=0A= is available. In this case, either RawData or Reference elements,=0A= or both of them, MUST be provided. In case a RawData or Reference=0A= element is provided along with this attribute, writers/senders=0A= MUST ensure that this value is consistent with the one provided by=0A= the element; if a reader/receiver detects an inconsistency, it=0A= SHOULD prefer this attribute's value, and SHOULD log the=0A= inconsistency so a human can correct the problem.=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 11]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= The AttackPattern class is composed of the following aggregate=0A= classes.=0A= =0A= RawData: Zero or more. XMLDATA. A complete document that is=0A= formatted according to the specification and its version=0A= identified by the value of the SpecID with the Section 4.1.=0A= =0A= Reference: Zero or more of iodef:Reference [RFC5070]. This element=0A= allows an IODEF document to include a link to a structured=0A= information instead of directly embedding it into a RawData=0A= element.=0A= =0A= Platform: Zero or more. An identifier of software platform involved=0A= in the specific attack pattern, which is elaborated in=0A= Section 4.3.2. Some of the structured information embedded in the=0A= RawData element may include the identifier within it. In this=0A= case, this Platform element SHOULD NOT be used. If a reader/=0A= receiver detects the identifiers in both RawData and Platform=0A= elements and their inconsistency, it SHOULD prefer the identifiers=0A= derived from the Platform element, and SHOULD log the=0A= inconsistency so a human can correct the problem.=0A= =0A= 4.3.2. Platform=0A= =0A= A Platform identifies a software platform. It is recommended that=0A= AttackPattern, Vulnerability, Weakness, and System classes contain=0A= this elements whenever available.=0A= =0A= A Platform element is structured as follows.=0A= =0A= +----------------------+=0A= | Platform |=0A= +----------------------+=0A= | ENUM SpecID |<>--(0..*)-[ RawData ]=0A= | STRING ext-SpecID |<>--(0..*)-[ Reference ]=0A= | STRING PlatformID |=0A= +----------------------+=0A= =0A= Figure 3: Platform class=0A= =0A= This class has the following attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1. Note=0A= that the lists in Section 4.1 will be developed further by IANA.=0A= In case a RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this value is=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 12]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer this=0A= attribute's value, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= PlatformID: OPTIONAL. STRING. An identifier of a platform to be=0A= reported. This attribute SHOULD be used whenever such identifier=0A= is available, but could be omitted if no such one is available.=0A= In this case, either RawData or Reference elements, or both of=0A= them, MUST be provided. In case a RawData or Reference element is=0A= provided along with this attribute, writers/senders MUST ensure=0A= that this value is consistent with the one provided by the=0A= element; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer this attribute's value, and SHOULD log the inconsistency so=0A= a human can correct the problem.=0A= =0A= This class is composed of the following aggregate classes.=0A= =0A= RawData: Zero or more. XMLDATA. A complete document that is=0A= formatted according to the specification and its version=0A= identified by the value of the SpecID with the Section 4.1.=0A= =0A= Reference: Zero or more of iodef:Reference [RFC5070]. This element=0A= allows an IODEF document to include a link to a structured=0A= information instead of directly embedding it into a RawData=0A= element.=0A= =0A= Writers/senders MUST ensure the specification name and version=0A= identified by the SpecID are consistent with the contents of the ID;=0A= if a reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification name and version derived from the content, and SHOULD=0A= log the inconsistency so a human can correct the problem.=0A= =0A= 4.3.3. Vulnerability=0A= =0A= A Vulnerability consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". The=0A= extension describes the (candidate) vulnerabilities of incidents or=0A= events.=0A= =0A= It is recommended that Method class SHOULD contain one or more of the=0A= extension elements whenever available.=0A= =0A= A Vulnerability element is structured as follows.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 13]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= +------------------------+=0A= | Vulnerability |=0A= +------------------------+=0A= | ENUM SpecID |<>--(0..*)-[ RawData ]=0A= | STRING ext-SpecID |<>--(0..*)-[ Reference ]=0A= | STRING VulnerabilityID |<>--(0..*)-[ Platform ]=0A= | |<>--(0..*)-[ Scoring ]=0A= +------------------------+=0A= =0A= Figure 4: Vulnerability class=0A= =0A= This class has the following attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1. Note=0A= that the lists in Section 4.1 will be developed further by IANA.=0A= In case a RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this value is=0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer this=0A= attribute's value, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= VulnerabilityID: OPTIONAL. STRING. An identifier of a=0A= vulnerability to be reported. This attribute SHOULD be used=0A= whenever such identifier is available, but could be omitted if no=0A= such one is available. In this case, either RawData or Reference=0A= elements, or both of them, MUST be provided. In case a RawData or=0A= Reference element is provided along with this attribute, writers/=0A= senders MUST ensure that this value is consistent with the one=0A= provided by the element; if a reader/receiver detects an=0A= inconsistency, it SHOULD prefer this attribute's value, and SHOULD=0A= log the inconsistency so a human can correct the problem.=0A= =0A= This class is composed of the following aggregate classes.=0A= =0A= RawData: Zero or one. XMLDATA. A complete document that is=0A= formatted according to the specification and its version=0A= identified by the value of the SpecID with the Section 4.1.=0A= =0A= Reference: Zero or one of iodef:Reference [RFC5070]. This element=0A= allows an IODEF document to include a link to a structured=0A= information instead of directly embedding it into a RawData=0A= element.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 14]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= Platform: Zero or more. An identifier of software platform affected=0A= by the vulnerability, which is elaborated in Section 4.3.2. Some=0A= of the structured information embedded in the RawData element may=0A= include the identifier within it. In this case, this element=0A= SHOULD NOT be used. If a reader/receiver detects the identifiers=0A= in both RawData and Platform elements and their inconsistency, it=0A= SHOULD prefer the identifiers derived from the Platform element,=0A= and SHOULD log the inconsistency so a human can correct the=0A= problem.=0A= =0A= Scoring: Zero or more. An indicator of the severity of the=0A= vulnerability, such as CVSS and CCSS scores, which is elaborated=0A= in Section 4.3.4. Some of the structured information may include=0A= scores within it. In this case, the Scoring element SHOULD NOT be=0A= used since the RawData element contains the scores. If a reader/=0A= receiver detects scores in both RawData and Scoring elements and=0A= their inconsistency, it SHOULD prefer the scores derived from the=0A= RawData element, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= 4.3.4. Scoring=0A= =0A= A Scoring class describes the scores of the severity in terms of=0A= security. It is recommended that Vulnerability and Weakness classes=0A= contain the elements whenever available.=0A= =0A= A Scoring class is structured as follows.=0A= =0A= +----------------------+=0A= | Scoring |=0A= +----------------------+=0A= | ENUM SpecID |<>---------[ ScoreSet ]=0A= | STRING ext-SpecID |=0A= +----------------------+=0A= =0A= Figure 5: Scoring class=0A= =0A= This class has two attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1. Note=0A= that the lists in Section 4.1 will be developed further by IANA.=0A= In case a RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this namespace is=0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer the value of=0A= this attribute, and SHOULD log the inconsistency so a human can=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 15]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= correct the problem.=0A= =0A= This class is composed of an aggregate class.=0A= =0A= ScoreSet: One. XMLDATA. A complete document that is formatted=0A= according to the specification and its version identified by the=0A= value of the SpecID with the Section 4.1. This element includes a=0A= set of score information.=0A= =0A= Writers/senders MUST ensure the specification name and version=0A= identified by the SpecID are consistent with the contents of the=0A= Score; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer the specification name and version derived from the content,=0A= and SHOULD log the inconsistency so a human can correct the problem.=0A= =0A= 4.3.5. Weakness=0A= =0A= A Weakness consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". The=0A= extension describes the weakness types of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain one or more of the=0A= extension elements whenever available.=0A= =0A= A Weakness element is structured as follows.=0A= =0A= +----------------------+=0A= | Weakness |=0A= +----------------------+=0A= | ENUM SpecID |<>--(0..*)-[ RawData ]=0A= | STRING ext-SpecID |<>--(0..*)-[ Reference ]=0A= | STRING WeaknessID |<>--(0..*)-[ Platform ]=0A= | |<>--(0..*)-[ Scoring ]=0A= +----------------------+=0A= =0A= Figure 6: Weakness class=0A= =0A= This class has the following attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1. Note=0A= that the lists in Section 4.1 will be developed further by IANA.=0A= In case a RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this value is=0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer this=0A= attribute's value, and SHOULD log the inconsistency so a human can=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 16]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= correct the problem.=0A= =0A= WeaknessID: OPTIONAL. STRING. An identifier of a weakness to be=0A= reported. This attribute SHOULD be used whenever such identifier=0A= is available, but could be omitted if no such one is available.=0A= In this case, either RawData or Reference elements, or both of=0A= them, MUST be provided. In case a RawData or Reference element is=0A= provided along with this attribute, writers/senders MUST ensure=0A= that this value is consistent with the one provided by the=0A= element; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer this attribute's value, and SHOULD log the inconsistency so=0A= a human can correct the problem.=0A= =0A= This class is composed of the following aggregate classes.=0A= =0A= RawData: Zero or more. XMLDATA. A complete document that is=0A= formatted according to the specification and its version=0A= identified by the value of the SpecID with the Section 4.1.=0A= =0A= Reference: Zero or one of iodef:Reference [RFC5070]. This element=0A= allows an IODEF document to include a link to a structured=0A= information instead of directly embedding it into a RawData=0A= element.=0A= =0A= Platform: Zero or more. An identifier of software platform affected=0A= by the weakness, which is elaborated in Section 4.3.2. Some of=0A= the structured information embedded in the RawData element may=0A= include the identifier within it. In this case, this element=0A= SHOULD NOT be used. If a reader/receiver detects the identifiers=0A= in both RawData and Platform elements and their inconsistency, it=0A= SHOULD prefer the identifiers derived from the Platform element,=0A= and SHOULD log the inconsistency so a human can correct the=0A= problem.=0A= =0A= Scoring: Zero or more. An indicator of the severity of the=0A= weakness, such as CWSS score, which is elaborated in=0A= Section 4.3.4. Some of the structured information may include=0A= scores within it. In this case, the Scoring element SHOULD NOT be=0A= used since the RawData element contains the scores. If a reader/=0A= receiver detects scores in both RawData and Scoring elements and=0A= their inconsistency, it SHOULD prefer the scores derived from the=0A= RawData element, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 17]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= 4.3.6. EventReport=0A= =0A= An EventReport consists of an extension to the=0A= Incident.EventData.Record.RecordData.RecordItem element with a dtype=0A= of "xml". The extension embeds structured event reports.=0A= =0A= It is recommended that RecordItem class SHOULD contain one or more of=0A= the extension elements whenever available.=0A= =0A= An EventReport element is structured as follows.=0A= =0A= +----------------------+=0A= | EventReport |=0A= +----------------------+=0A= | ENUM SpecID |<>--(0..*)-[ RawData ]=0A= | STRING ext-SpecID |<>--(0..*)-[ Reference ]=0A= | STRING EventID |=0A= +----------------------+=0A= =0A= Figure 7: EventReport class=0A= =0A= This class has the following attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1. Note=0A= that the lists in Section 4.1 will be developed further by IANA.=0A= In case a RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this value is=0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer this=0A= attribute's value, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= EventID: OPTIONAL. STRING. An identifier of an event to be=0A= reported. This attribute SHOULD be used whenever such identifier=0A= is available, but could be omitted if no such one is available.=0A= In this case, either RawData or Reference elements, or both of=0A= them, MUST be provided. In case a RawData or Reference element is=0A= provided along with this attribute, writers/senders MUST ensure=0A= that this value is consistent with the one provided by the=0A= element; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer this attribute's value, and SHOULD log the inconsistency so=0A= a human can correct the problem.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 18]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= RawData: Zero or one. XMLDATA. A complete document that is=0A= formatted according to the specification and its version=0A= identified by the value of the SpecID with the Section 4.1.=0A= =0A= Reference: Zero or one of iodef:Reference [RFC5070]. This element=0A= allows an IODEF document to include a link to a structured=0A= information instead of directly embedding it into a RawData=0A= element.=0A= =0A= This class MUST contain at least one of RawData or Reference=0A= elements. Writers/senders MUST ensure the specification name and=0A= version identified by the SpecID are consistent with the contents of=0A= the RawData; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer the specification name and version derived from the content,=0A= and SHOULD log the inconsistency so a human can correct the problem.=0A= =0A= 4.3.7. Verifcation=0A= =0A= A Verification consists of an extension to the=0A= Incident.AdditionalData element with a dtype of "xml". The extension=0A= elements describes incident on vefifying incidents.=0A= =0A= A Verification class is structured as follows.=0A= =0A= +----------------------+=0A= | Verification |=0A= +----------------------+=0A= | ENUM SpecID |<>--(0..*)-[ RawData ]=0A= | STRING ext-SpecID |<>--(0..*)-[ Reference ]=0A= | STRING VerificationID|=0A= +----------------------+=0A= =0A= Figure 8: Verification class=0A= =0A= This class has the following attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1. Note=0A= that the lists in Section 4.1 will be developed further by IANA.=0A= In case a RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this value is=0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer this=0A= attribute's value, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 19]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= VerificationID: OPTIONAL. STRING. An identifier of an check item=0A= to be reported. This attribute SHOULD be used whenever such=0A= identifier is available, but could be omitted if no such one is=0A= available. In this case, either RawData or Reference elements, or=0A= both of them, MUST be provided. In case a RawData or Reference=0A= element is provided along with this attribute, writers/senders=0A= MUST ensure that this value is consistent with the one provided by=0A= the element; if a reader/receiver detects an inconsistency, it=0A= SHOULD prefer this attribute's value, and SHOULD log the=0A= inconsistency so a human can correct the problem.=0A= =0A= This class is composed of two aggregate classes.=0A= =0A= RawData: Zero or one. XMLDATA. A complete document that is=0A= formatted according to the specification and its version=0A= identified by the value of the SpecID with the Section 4.1.=0A= =0A= Reference: Zero or one of iodef:Reference [RFC5070]. This element=0A= allows an IODEF document to include a link to a structured=0A= information instead of directly embedding it into a RawData=0A= element.=0A= =0A= This class MUST contain at least either of RawData and Reference=0A= elements. Writers/senders MUST ensure the specification name and=0A= version identified by the SpecID are consistent with the contents of=0A= the RawData; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer the specification name and version derived from the content,=0A= and SHOULD log the inconsistency so a human can correct the problem.=0A= =0A= 4.3.8. Remediation=0A= =0A= A Remediation consists of an extension to the Incident.AdditionalData=0A= element with a dtype of "xml". The extension elements describes=0A= incident remediation information including instructions.=0A= =0A= It is recommended that Incident class SHOULD contain one or more of=0A= this extension elements whenever available.=0A= =0A= A Remediation class is structured as follows.=0A= =0A= +----------------------+=0A= | Remediation |=0A= +----------------------+=0A= | ENUM SpecID |<>--(0..*)-[ RawData ]=0A= | STRING ext-SpecID |<>--(0..*)-[ Reference ]=0A= | String RemediationID |=0A= +----------------------+=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 20]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= Figure 9: Remediation class=0A= =0A= This class has the following attributes.=0A= =0A= SpecID: REQUIRED. ENUM. The identifier of the specification=0A= specifying the format of the RawData element. The value should be=0A= chosen from the namespaces [XMLNames] listed in Section 4.1. Note=0A= that the lists in Section 4.1 will be developed further by IANA.=0A= In case a RawData or Reference element is provided along with this=0A= attribute, writers/senders MUST ensure that this value is=0A= consistent with the one provided by the element; if a reader/=0A= receiver detects an inconsistency, it SHOULD prefer this=0A= attribute's value, and SHOULD log the inconsistency so a human can=0A= correct the problem.=0A= =0A= RemediationID: OPTIONAL. STRING. An identifier of a remediation=0A= information to be reported. This attribute SHOULD be used=0A= whenever such identifier is available, but could be omitted if no=0A= such one is available. In this case, either RawData or Reference=0A= elements, or both of them, MUST be provided. In case a RawData or=0A= Reference element is provided along with this attribute, writers/=0A= senders MUST ensure that this value is consistent with the one=0A= provided by the element; if a reader/receiver detects an=0A= inconsistency, it SHOULD prefer this attribute's value, and SHOULD=0A= log the inconsistency so a human can correct the problem.=0A= =0A= This class is composed of two aggregate classes.=0A= =0A= RawData: Zero or one. XMLDATA. A complete document that is=0A= formatted according to the specification and its version=0A= identified by the value of the SpecID with the Section 4.1.=0A= =0A= Reference: Zero or one of iodef:Reference [RFC5070]. This element=0A= allows an IODEF document to include a link to a structured=0A= information instead of directly embedding it into a RawData=0A= element.=0A= =0A= This class MUST contain at least either of RawData and Reference=0A= elements. Writers/senders MUST ensure the specification name and=0A= version identified by the SpecID are consistent with the contents of=0A= the RawData; if a reader/receiver detects an inconsistency, it SHOULD=0A= prefer the specification name and version derived from the content,=0A= and SHOULD log the inconsistency so a human can correct the problem.=0A= =0A= =0A= 5. Security Considerations=0A= =0A= This document specifies a format for encoding a particular class of=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 21]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= security incidents appropriate for exchange across organizations. As=0A= merely a data representation, it does not directly introduce security=0A= issues. However, it is guaranteed that parties exchanging instances=0A= of this specification will have certain concerns. For this reason,=0A= the underlying message format and transport protocol used MUST ensure=0A= the appropriate degree of confidentiality, integrity, and=0A= authenticity for the specific environment.=0A= =0A= Organizations that exchange data using this document are URGED to=0A= develop operating procedures that document the following areas of=0A= concern.=0A= =0A= 5.1. Transport-Specific Concerns=0A= =0A= The underlying messaging format and protocol used to exchange=0A= instances of the IODEF MUST provide appropriate guarantees of=0A= confidentiality, integrity, and authenticity. The use of a=0A= standardized security protocol is encouraged. The Real-time Inter-=0A= network Defense (RID) protocol [RFC6045] and its associated transport=0A= binding [RFC6046] provide such security.=0A= =0A= The critical security concerns are that these structured information=0A= may be falsified or they may become corrupt during transit. In areas=0A= where transmission security or secrecy is questionable, the=0A= application of a digital signature and/or message encryption on each=0A= report will counteract both of these concerns. We expect that each=0A= exchanging organization will determine the need, and mechanism, for=0A= transport protection.=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= This document uses URNs to describe XML namespaces and XML=0A= schemata[XMLschemaPart1][XMLschemaPart2] conforming to a registry=0A= mechanism described in [RFC3688].=0A= =0A= Registration request for the IODEF structured cybersecurity=0A= information extension namespace:=0A= =0A= URI: urn:ietf:params:xml:ns:iodef-sci-1.0=0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: None=0A= =0A= Registration request for the IODEF structured cybersecurity=0A= information extension XML schema:=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 22]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= URI: urn:ietf:params:xml:schema:iodef-sci-1.0=0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: Refer here to the XML Schema in the appendix of the document.=0A= =0A= This memo creates the following registry for IANA to manage:=0A= =0A= Name of the registry: "IODEF Structured Cyber Security Information=0A= Specifications"=0A= =0A= Namespace details: A registry entry for a Structured Cyber=0A= Security Information Specification (SCI specification) consists=0A= of:=0A= =0A= Namespace: A URI [RFC3986] that is the XML namespace name used=0A= by the registered SCI specification.=0A= =0A= Specification Name: A string containing the spelled-out name of=0A= the SCI specification in human-readable form.=0A= =0A= Specification URI: A list of one or more of the URIs [RFC3986]=0A= from which the registered specification can be obtained. The=0A= registered specification MUST be readily and publicly available=0A= from that URI.=0A= =0A= Applicable Classes: A list of one or more of the Extended=0A= Classes specified in Section 4.3 of this document. The=0A= registered SCI specification MUST only be used with the=0A= Extended Classes in the registry entry.=0A= =0A= Information that must be provided to assign a new value: The above=0A= list of information.=0A= =0A= Fields to record in the registry: Namespace/Specification Name/=0A= Version/Applicable Classes.=0A= =0A= Initial registry contents: See sections from Section 4.1.1 through=0A= Section 4.1.17 above.=0A= =0A= Allocation Policy: Expert Review [RFC5226] and Specification=0A= Required [RFC5226].=0A= =0A= The Designated Expert is expected to consult with the mile (Managed=0A= Incident Lightweight Exchange) working group or its successor if any=0A= such WG exists (e.g., via email to the working group's mailing list).=0A= The Designated Expert is expected to retrieve the SCI specification=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 23]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= from the provided URI in order to check the public availability of=0A= the specification and verify the correctness of the URI. An=0A= important responsibility of the Designated Expert is to ensure that=0A= the registered Applicable Classes are appropriate for the registered=0A= SCI specification.=0A= =0A= =0A= 7. Acknowledgment=0A= =0A= We would like to acknowledge Mr. David Black from EMC, who kindly=0A= provided generous support, especially on the IANA registry issues.=0A= We also would like to thank Paul Cichonski from NIST, Robert Martin=0A= from MITRE, Kathleen Moriarty from EMC, Lagadec Philippe from NATO,=0A= Shuhei Yamaguchi from NICT, Anthony Rutkowski from Yaana Technology,=0A= and Brian Trammel from CERT/NetSA for their sincere discussion and=0A= feedback on this document.=0A= =0A= =0A= 8. Appendix I: XML Schema Definition for Extension=0A= =0A= The XML Schema describing the elements defined in the Extension=0A= Definition section is given here. Each of the examples in Section 9=0A= should be verified to validate against this schema by automated=0A= tools.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 24]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 25]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 26]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 27]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 9. Appendix II: XML Examples=0A= =0A= This section provides an example of an incident encoded in the IODEF.=0A= This do not necessarily represent the only way to encode a particular=0A= incident. Below is an example of a CSIRT reporting an attack.=0A= =0A= =0A= =0A= =0A= 189493=0A= 2001-09-13T23:19:24+00:00=0A= Incident report in company xx=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 28]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= =0A= =0A= =0A= Structured information on attack pattern, exploited=0A= vulnerability, and weakness=0A= =0A= =0A= =0A= =0A= .....=0A= =0A= =0A= =0A= Link to Capec-14=0A= http://capec.mitre.org/data/definitions/14.html=0A= =0A= =0A= =0A= =0A= =0A= =0A= ...=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 9.3=0A= NETWORK=0A= MEDIUM=0A= NONE=0A= COMPLETE=0A= COMPLETE=0A= COMPLETE=0A= http://nvd.nist.gov=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 29]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= 2012-01-11T09:55:00.000-05:00=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= .....=0A= =0A= =0A= =0A= =0A= =0A= =0A= Example.com CSIRT=0A= example-com=0A= contact@csirt.example.com=0A= =0A= =0A= =0A= =0A= =0A=
192.0.2.200
=0A= 57=0A= =0A= =0A= =0A= =0A=
192.0.2.16/28
=0A= =0A= =0A= 80=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 30]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= =0A= =0A= =0A= =0A= 2001-09-13T18:11:21+02:00=0A= a Web-server event record=0A= =0A= =0A= =0A= =0A= .....=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 2001-09-14T08:19:01+00:00=0A= Notification sent to=0A= constituency-contact@192.0.2.200=0A= =0A= =0A= =0A= =0A= =0A= =0A= .....=0A= =0A= =0A= =0A= =0A= =0A= =0A= .....=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 10. References=0A= =0A= 10.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform=0A= Resource Identifier (URI): Generic Syntax", STD 66,=0A= RFC 3986, January 2005.=0A= =0A= [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident=0A= Object Description Exchange Format", RFC 5070,=0A= December 2007.=0A= =0A= [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an=0A= IANA Considerations Section in RFCs", BCP 26, RFC 5226,=0A= May 2008.=0A= =0A= [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",=0A= RFC 6045, November 2010.=0A= =0A= [RFC6046] Moriarty, K. and B. Trammell, "Transport of Real-time=0A= Inter-network Defense (RID) Messages", RFC 6046,=0A= November 2010.=0A= =0A= [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and=0A= F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth=0A= Edition)", W3C Recommendation, November 2008.=0A= =0A= [XMLschemaPart1]=0A= Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,=0A= "XML Schema Part 1: Structures Second Edition",=0A= W3C Recommendation, October 2004.=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 32]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= [XMLschemaPart2]=0A= Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes=0A= Second Edition", W3C Recommendation, October 2004.=0A= =0A= [XMLNames]=0A= Bray, T., Hollander, D., Layman, A., Tobin, R., and H.=0A= Thomson, ""Namespaces in XML (Third Edition)",=0A= W3C Recommendation, December 2009.=0A= =0A= [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration=0A= and Classification (CAPEC)".=0A= =0A= [CCE] The MITRE Corporation, "Common Configuration Enumeration=0A= (CCE)".=0A= =0A= [CCSS] Scarfone, K. and P. Mell, "The Common Configuration=0A= Scoring System (CCSS)", NIST Interagency Report 7502,=0A= December 2010.=0A= =0A= [CEE] The MITRE Corporation, "Common Event Expression (CEE)".=0A= =0A= [CPE] National Institute of Standards and Technology, "Common=0A= Platform Enumeration", June 2011.=0A= =0A= [CVE] The MITRE Corporation, "Common Vulnerability and Exposures=0A= (CVE)".=0A= =0A= [CVRF] ICASI, "Common Vulnerability Reporting Framework (CVRF)".=0A= =0A= [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The=0A= Common Vulnerability Scoring System (CVSS) and Its=0A= Applicability to Federal Agency Systems".=0A= =0A= [CWE] The MITRE Corporation, "Common Weakness Enumeration=0A= (CWE)".=0A= =0A= [CWSS] The MITRE Corporation, "Common Weakness Scoring System=0A= (CWSS)".=0A= =0A= [OCIL] David Waltermire and Karen Scarfone and Maria Casipe, "The=0A= Open Checklist Interactive Language (OCIL) Version 2.0",=0A= April 2011.=0A= =0A= [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment=0A= Language (OVAL)".=0A= =0A= [XCCDF] David Waltermire and Charles Schmidt and Karen Scarfone=0A= and Neal Ziring, "Specification for the Extensible=0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 33]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= Configuration Checklist Description Format (XCCDF) version=0A= 1.2 (DRAFT)", July 2011.=0A= =0A= 10.2. Informative References=0A= =0A= [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the=0A= Internet: Timestamps", RFC 3339, July 2002.=0A= =0A= [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC=0A= Text on Security Considerations", BCP 72, RFC 3552,=0A= July 2003.=0A= =0A= [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,=0A= January 2004.=0A= =0A= [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,=0A= October 2008.=0A= =0A= [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to=0A= Uniform Resource Identifiers (URI) Dynamic Delegation=0A= Discovery System (DDDS) Application (ENUM)", RFC 6116,=0A= March 2011.=0A= =0A= [SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A.=0A= Halbardier, "The Technical Specification for the Security=0A= Content Automation Protocol (SCAP): SCAP Version 1.2",=0A= NIST Special Publication 800-126 Revision 2,=0A= September 2011.=0A= =0A= =0A= Authors' Addresses=0A= =0A= Takeshi Takahashi=0A= National Institute of Information and Communications Technology=0A= 4-2-1 Nukui-Kitamachi Koganei=0A= 184-8795 Tokyo=0A= Japan=0A= =0A= Phone: +80 423 27 5862=0A= Email: takeshi_takahashi@nict.go.jp=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 34]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Feb 2012=0A= =0A= =0A= Kent Landfield=0A= McAfee, Inc=0A= 5000 Headquarters Drive=0A= Plano, TX 75024=0A= USA=0A= =0A= Email: Kent_Landfield@McAfee.com=0A= =0A= =0A= Thomas Millar=0A= US Department of Homeland Security, NPPD/CS&C/NCSD/US-CERT=0A= 245 Murray Lane SW, Building 410, MS #732=0A= Washington, DC 20598=0A= USA=0A= =0A= Phone: +1 888 282 0870=0A= Email: thomas.millar@us-cert.gov=0A= =0A= =0A= Youki Kadobayashi=0A= Nara Institute of Science and Technology=0A= 8916-5 Takayama, Ikoma=0A= 630-0192 Nara=0A= Japan=0A= =0A= Email: youki-k@is.aist-nara.ac.jp=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires August 18, 2012 [Page 35]=0A= =0C=0A= ------=_NextPart_000_0042_01CCEC0D.D17CAA80 Content-Type: application/pdf; name="draft-ietf-mile-sci-03candidate_20120215.txt.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-mile-sci-03candidate_20120215.txt.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1WXXPaOhB951fs9KVkJhhIJk3aN+qYDlPScMFt7p2QB1le22r8VUlO4d/f XWEIJO1t5rZmGCShPbs6e3blbzDwhjDgT/sri05/fg6p6QzgA33TzrfO0G2A9kcW8D6kTRcwPIEw 6WzshnByCudntFJ0uleTaQA3lb5XZQofdNXU8OIn9CAU9yITJlNH4dfO8BTCaac7KS3qEm3vUovE vhxu//k08cOj1xusMsYYjBW2Me9gYUUZCx0bCLWQ9/+F8dGDKW1OFOYxYwWrWmkkjFGTNsbC8OIY TgbEzIufKzlKEBnr/51q9xBzVyrPhf4DWPR8XvjBPPw9rH88+CjiKhJrl84/Ehd8Gk0WvxkXwBgj GJ5tckVYp2+dyvifyfVlMO7hijRiVFWCrcA0dV1pS3rRjbSNJunIdYTaoGy0smtQZVLpQljaT2Ct ZH/iOWYB9xTapFeoHHtGqt7g1LMrS6Ynb5zpKCJXQtr2lGGmDMSVbAosLbjQSKs2Q5iUUsW8eB19 RWnhEo3UquZAIFjJTJQpwtjFdhDYsuuOuTyCGBNV0oFUCfOxD2eD8wHc0ogHd3z4REiVK6oUBCy1 khnGbVg/5YBCbF2LoqIWcLiRwlVWoYFo3QJhEWEcc7PYY3gfbzOytBqtwdQoVaKk+8sctxiqlHnj MPzRLPBvw6s7uHXDu2Pwg6BdCAKezrbTmZt+CZbd+fKoRbqluVudj3k8H7vJYsGTxYInN1vzG7fx ZrHYzt3/1/5kusXiMS99GU2dD1qhIa1QE4G/ff+SfLifO+8x/QvXl6BKKMeU+Sssqn0lPOmFtGKa qFCOH0pj0uQ5yGpDXykRviubsVoOFFDr6kGxwJ2f9/4Mzi9cUG74di8arokDjwaEJtS2v2912caL u80QlClJCzXtOnAdCnPPoqTQSIdBSDL0qKwrUpjNhIWKUDSkfG8YKMQaRG4qiBWJQ0WN3fbK5wGI p9wYjylDyMmWwyMFaq6W3a4Wqj0WMUnuM2vrd/1+LCgLfB2g9rhavUqnfVe8pt/i9H/NkjPYC/FB 5CpmPYOgo61U0RQcmFEroFKxmTlgivPBBEQITU0BYXwMGutcSB4RSBWZKse2MDa87dFhCWBbY1YV SGxMnF5UKWoSQK0VlzUVeWPwefiGfCVIB5VbyqkIKZ0iZ9dkJZVLGRata8peyWavODUsRfKR0u1o vFcHRP1Ixd/p6qK+wbcpUMU/uU6Z6K5f1Wut0syyVtQuqMflZVdShbnrl2VFtzljMImsy5p6EMvd NUxqIESaMM/qYtdmRWOzSrOCRhSZc8CEGNQPGHvPz7Mz3NSja8fE0V5lueLYxfXawBRTkR94nz1W 5Rxz6nCkbwJxVpfbxJIFv2iRxe5N6Rio3kTubS+Z9rXkV28ltzNBTXp4R4hB2PmLPv8Cw+HC3mVu ZHN0cmVhbQplbmRvYmoKNiAwIG9iagoxMDcwCmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGggMTMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxtUsFy2jAQvfsr3q0wAwZDM5DemkI6 mWGmNPjW5CDkla3WlhxJDuHvu3LMIbTS2Bqv3r59+7wvmKcZ5nEPp2yS2eMKpU/m+M5PmbwkWQ/A cMgGdzmD1sgWyFXynpdhscRqtUbeJKMHE8gZCtONEyrgaj382Gzvp/QWpl7q68t+3dMRi3m2GOe/ k+Ut8l0y4ujTqAqh/TKbBdf5QJRqCiq1rpzVWpLxNNVG2acxtAEpRTLAGoSKUIhAsGr8KcmWF7a2 O3KaCJoxVjFMexRWdg2ZkAL7moQnOHrVdIok/HG59kwUKaRwpLq6Pk8gfMScUZCXTh8JZ9s5OF1W wUOYgol8cFrGch4nHaoYaVnjwBXsPxK+2YL41bTWxKJgx5yQgQooZ5uPcDRsyUCljaw7Tj3opq21 0pxwd9hg924SAvNEvRepRfTrQL00fE4Ho3pNbF0evcaOSlFj7+yr9n0HsSXuHm0MFcwRW7JdwEk4 J0w4c4WB5UOdSPl/XSnDb9Y3/e/JxR9RCV/pCYi11ullMLZvrWbf8LUro6xsPenn5Hp+fu1FSVg8 M+U2T37y/gtE8N9LZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iago0MzUKZW5kb2JqCjE3IDAgb2Jq Cjw8L0xlbmd0aCAxOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK2XXW/aMBSG 7/MrfNdWKiwf5Wt3WUgnJLoyiGilaRcmMeCRD+o4Hfz7nZMQGsKm4nS2UCKSPDl+ffz65IXobYPo 2A9HP9I+TXtklWo6+Qq/lfaiGfkN5HDwI/LFg5v6xDCJt9SK5wxiWqTX6xMv0q5HsWQiZrI1FHQp Sa2NHofufYvtZCv1ef1i3u7Zgpi6Yd54vzRrQLyxdu3RRchIsiROAvBYpjdXmtnNL8EDRhuwsRRJ kPmSJzFpK3dyB0TDKokm/OMxEfE4CZPVnjQlIsuCc3u7DblPFzzksgHtyLqDc3cHCqQ4zCFb8pgr jph0DiykoXJjnkqUdpZtt4mQLCAzKUDITMCps18wkTI/Exj4KF4mIqL4xiOkaLMt8/mS5/KnagOs BFSEhEE59sR1YGK7iqxujYUT6Tgu6bR1VdnPWFbOms0gLP2jLJxIx3Vh4SmO8C+sDrImLiStRcY0 XmV0xS5l9WqsboU1LKaTin0zVg9ZczeXS3WMdVY/Z03vm2hfZw1yFsyj+XGWobeJ89Qsv85YBrIg Lr3dV2X16yxI/AcbllCDMZ6xIPEfndH4v7Ag8R/n9hgEM3DTebOwd13jnNU5ZU1ZmoXyIvc5Z3VP WU4SRRfa6jkLEv/ZcYaYrKaifw0q5myWZh+AEQ+ppMTbb9nF7lphFTT01eeH8dD2bOVcrcZlVeNy QpqmEFQjVkHDuGwpqb+ZUImlw+XRGXqNhZpNQipxn1IcIxQcpywc5zwLYyaUN27DqrHQ72d+Ini8 UtXe6NRY6PdPjG5ilqronrO6NRb6vfsKFdWU4eavEpvRr7HQ7+dM8KWfVwhKrHpOoN9PWcQCrswy y5xAnWZl6QKFY8oDmEqlCsU0jnF18jz1BI1TVKpVVjxI9iFp32WaZX6h5iP7m90wphMWam77mzj5 HbJgFcFEKlAOrLK47BeFKqxrviOjz+gVkLNrFtFqpQkrq1KC/os1OGEdYO6ORtvwUgczy/zCPXbK lkwwEFo144tuva1ttPc2+VbUsa9MnXzKAsM5VsXqNKvUy87kOhHpFbGDQDBFR62w8BMs/17a0DVN 1/yWMElo2D4sLZiCLQc+vG+VQdlv9G/zTy1Saz8mWENaP4Hoetp36H8AxTi9t2VuZHN0cmVhbQpl bmRvYmoKMTggMCBvYmoKODU0CmVuZG9iagoyMiAwIG9iago8PC9MZW5ndGggMjMgMCBSL0ZpbHRl ciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyFVlFz2jgQfudX7OSl7QzhgFyb9N44Yu4yQ0IKpLmb DA9CFqDGllxJDuF+/e1KFthucwcDlm3507fffrvyd+j3BtCnb3XkeeeX+SVsbacPf+Bv2/neGfgJ UB14Dr8vcdIVDIaw3HTCcwMYXsDl5RUs8877G+WEUcKdXxu2cdD63Myuk8m5eHXnlsv2Tf+ZiDUM +4Phh+W3zsVnWE477wc9fFA5o9OSO6nVh3ed4Sd/B+ePD2thgDnH+LMFZgRshXNSbSHXeGJ1sZPW Sc6cSLvAVApuJ6QBVeb4oH8C8QYXEU8qbgSzBJCyA6wPdEACSw1cFwL20u3Alhz/pCsZ8enSQzIV yiFSwNhok/t7oIRILTgNawFGFNp4HuKV75jaRkp2hzRSYLlW2wpDmy1T8h8PYnuVciAtaCVAbygK RNWZBaHYOiO+nlVE9sCRD4aZYVTpAalBaUWvISGGJjYbySVGkB3AlAo4qWoFL410B8C4TSDSpXWt OPFvaffzuHPGd1KJc6KAXMUxnMLoFxQO6VVMrTOY45LEyAVTHgDvcyMRhkKuLdGFdelAutNSAlMa Y35hRurSgtLqvIbqNarzREG0SdFCjhKsXgQmXDgmsyNSbTYSn5QGeZgTU+8IRKkSFOyDIfnzCiLV vMxRXfuupYXMSN/gSiS7YZyuoFctLSBYjomVR0+8lZVmOmfKK6U9TcxS6pNmKGlYCUdhwn2GFfUi nRS1xcOCp7RGPYJVT1qGxBReRnRkk109URX9nH3Thmbud9JngWclJX88uk/G8OQPqy6MkwRPkoSG 9zS898OvSQXzhEN/YT6h8XziTxYLOlks6OSRnnr0kx799Ud/fTa+mcIT/a8ipdnXEV3C/1WoxL/G 42uE9YcVpnuBLEVV7z+NvAKqZ+7t4kGz7nWZpVQUa6EEFR3L2tYlHpUVQ7U1/WqxYiq3RV/9WM/U E6himKPsYwOIU9EFTiiql11EicvXFm7kPzqmJsDbuQ4N0mf4f1wLnCkS4iRdehS8Cg8FUrXusMnQ whQXEfVxWH8aVg/2LAvqsfgMbA1TZcYMZOJFZOi72GMKwSUp7w5tbY4LqgiPiqM8sbatw6o9Ifnp 1HkZ9qB91d4rNtQq0O0cCfiFfI2j0JnMpcJYI0RZZLQ5eem0ynzKgaWppEvojaPo2MoEF9Yyc6Al Yls8dQd6MPZlqrK2aesuon2yar4pmafaaYe00QmDDHWmt4emq2jDOd2jbYQwWwpudJbpfXAX7VRB UT9xPhk3bPWxf9mHJ7xKg1Xvh8We0f977M0Wzm4fFsuzbjjC3cyP58mXh5t5ck3jxZ+j6fQ4CDMa a+GN2cO0mkujE8p4dnub3F0HoNvR32chV2ez++XN7G40PYtBtnq51zDsb5LeeQojHNWQPW5YMWoY DgaffaQ0WNX0vkC9R4V3QNgK2nWcM8TGX7OIuo23g9r+V2W/Efp/lWqzD1POQv7I07WZvyHgx6EH XLJntmN2J/EdBiXIevG9LXktJJl0VG5L3GUGV13/Gtd+vXu6Z+jOX1eImCw7X/D7L5gXVgtlbmRz dHJlYW0KZW5kb2JqCjIzIDAgb2JqCjExNjkKZW5kb2JqCjI3IDAgb2JqCjw8L0xlbmd0aCAyOCAw IFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1WXXPaRhR951fct9ozmBo7qd1HgqFl xoldQ5PMJH5YVhfYWNIq2hUf/fU9d7UChN2Z4rEE0up+nHvOWf2ky16fLuUvnnXW+fXphpauc0l/ 4H/Z+dnphwUUTzqjDzMsuqX+Fc0Wnfq5Pl1d083NLc2yztkk91zm7C/uSrXwdPKZPNyNxhe89RdO m9Ob4TPmOV1d9q/OZz8617/T7L5zhqvKe6VfqMAZ0btUpMovbJmRyeWkvLG4uq7SnEs1N6nxO1J5 QhtWLzk71z3/pdO/bqJpW0mVGStXlYwYzpeVrmNomxUVbhKvOfeU2mU3RPIrJodrJUL3EO3qtyZa 6ImK0q5Nwo4UOb3ijMlb4q1eqXyJJyu9Oq6VVGbzJa4gEzvPSau+QpXesOsR/Wk3krMb0ifslUk5 kRrxONXRJA/y6tLM6zwIJUGOsxlHufVYtjA5njd5iFcXPlcOoa2uMvTb7uyhXmdxKAmNJN1WMr+y jttdCVCWFkrLCJTnVlsNGl3BKCAO9JOmDZwQEV9QrEpLVglGuEbDap4yoPioftgy9mYXUlhGCtMb Dh5Hwy4NRyMcHuXwORyexnKcTnH8Ihe+yNeH4eQex8+D+24MJSV/HQ7vxkjxYUeczTlJDGYTEmBA 9girBqY4j/grRtIqx2TyNe8os2VrXBhz7h3FWCVrNpiqOzDrjVAAGPw06Q7rK8cJ6vtkPUeMhDgK lF1zYEOVG30YNXMSGFXTgJwFGzXGHBOG3zWEmN/RJFpi4t6yVwP2mlBdxEiNNuip5AIlLkqbSV+m MNIpap2F4PVd6C1N0FADeepsBDokddDNGyC3uTg7LVbv5oCQdSWKbLHwQD/XXtVioy2AYM1a3xoL ST3oYGpyXdd1IqVM6RV0dBHbEaoKRyMplFfN/OAJGuaDYue7vbHU4CAnbwtOjBSJ5xpoKm9jIgyo 3eK+YNcCZgzdiIMpVCvzJVsuVW7+qaNsjFsFNluZhS29aO8AmkargXUHXDYqUnWv841U2/bWjXJS f2pRf1JPO48WmSdcHtHYmUwoAAbX4+0iHDxPCg3KFdhtmQiux5TwABUQxECxFGlE7HDnQ0+g9qJk 3vsgthWU8tSMUbIL1Rr6SqdmsQtl1hKJEnVRDCe7jAwttfZFUlVFUE3LfmibpfTt68f7fu/ymbxa ur3B4snQ3KtyNKhdpbUxSqQ3sh6T7fvZMUbfz6VlEZ2QLPg25NxgHTSWGCjEzMEzrGv85rDLNDsL mUWEAOMw8PGqcR65Kg2vqkzl9ZOyDwrrRI9xR36HxkZbmJqTKu+kayNrThSLmSbhLYBlbeKiwH1U /3+qucXHYzzmwllf2qTSUmTOG9KpcsHZpA9wy2CjrY3t6METWz2xnrbtkFA75fB179x7Jg6wOUhE ld6J0MVOn8JwJh7bRSzmyLne9frA6h5jEdZMq0I0iNTTQ+vDlsonraoPMOAzLWCwC6Nfe0CAmvcD CQ26/2mWcO6TXVpoqFJyMV3tObXIKQwaN9PYkWs6ivi0HxJVy0qRBKd2I7SBeRIwLXd4o8BepTJ2 hYLRipI+ya/n7luxwkq84qGNegNq3fz7aRJmoYoC+5K4cTOLGEveLlhSt55DPeNKEMLQnVnmWRi2 vFWAo2AKNKCWtZ4ng08DxHp/FXCaqReF8lcG+yQYk/aa19fRtjDQGg2qZQWE+rfd8DZ7+pb77RFx 6f0zIo5mnb/w9y9H28NeZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iagoxMjk0CmVuZG9iagozMiAw IG9iago8PC9MZW5ndGggMzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVVFT 4jAQfu+v2Dd1BgsFDzzeEOsNMzeeBz1f1IeQLpCzTWqSgvz727QFW8ZDx3aYTsvut9/37SZ5gY4f QMfd1ZOnXns6gKXxOvCDfkvvxQuKAKgePIWriIIuIehCtPDKvAC6PRgMLiFKvdOJtKgl2vNrzRYW Dq7Jr+vw5hxf7bnh4vDP4rrBOXQ7Qfcs+uv1vkP00zulr7kRcgl2hRC+ZqgtTHEtcAMP05vxt263 /wRMxjDLkIuF4MwKJSnkJRca47MTL+jtgGoJSaKqyEwlggs0wAwsck1lNJgSC2MQEmbIi8C+T2Dd /g4sIj6u5uQamLVazHNLIGoBJBBlTLk8YcbQt8fTHcSF33s8gzQ3tmCwabBzAtcsyUsU92bqkswJ SJaiyRhHIG5JbFpARUE5yhthsEVwDkikWYIpSlvmAdMIUlnQlSdgFZg8y5QuaBSl2FytscpvlvWp cQeAKdsCXyllEDYrwVcHGYS/QyqrtKiEypcrGN+HEPidhiOBPyBPJGLsEmGOkAopUiK2baJg7KhI 4IzqMnkgk9RxFGtSxyBmloGwECvykpQfsqG/nAR8zdzgCOsaLws+LBF2C/MtJEo9u6nLs8Keyeh2 BJbNk51HSjtgsdiWjXIN165tDkxINhcFEOnJmCa6LqhgRdDlODO5k5ciI89iXAhJ7FVujYjLDMNV huUwCNM0uTaLzsKArBmP7sIx2dsvcW93wzJ8W18ra7Nhu80ZQfmpsBp9pZdtNTeo106dqU9kc0U5 vCGMVZrSy8haxp/hjiafFjyEMk9Rl3HO0rGb/H1qyecetaGXYX2978k2S/2ZTob/JVsmjLKMlq2j XBZDM6xIVZya/nSdP+MQvvmdyvXjBnF8q9hYpEddGSu5EMu8MqJmyr7meybUOR3zoc6pvc94zwiq Uje/5kOv8GE2c6vwqBG37dFXdc+40m7CZ1tjMT0qPfhAenR1fVRoVaqp8cJpDEM62fqf6jV+qdfh mnYedyBpNOajFtepHGsxfrrFRfkpuv3Mce5cFKQj9sxWzKxEC9Dt7f6OAPGknd/AKF+6wye4bBXn LBxcD3dsidB/Isgw8n7T/Q+Sy2vJZW5kc3RyZWFtCmVuZG9iagozMyAwIG9iago4MjUKZW5kb2Jq CjM3IDAgb2JqCjw8L0xlbmd0aCAzOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nM2VXW+bMBSG7/kV526t1BhMlo9ylyVkilR1WcLSi2kXDjHEKxhqm6b59zUkIRBNlK29mC2ELJ/z +j0PHHgCC2Gw8nm8+7FhLgYQSsOCr/oKjScDFwFwvPkxfPF00BCwDV5gHPIw2F0YDIbgxcbVjCsq OFWdiSCBgosx+zZxpx36ojrSZ5ebxZjSNdgWtq+930b3Frw74+ozwqiHAMZzF2zUhTvCw4yE9PqT YfeLiCLznsRUpsSnzlltq1TqmKafUhQzJShKRGhGx3zTRpbWwN2zxjKlPguYTxRLeKHowDiJY72Y R0QFiYjB5VlMxSFiQQMqKPdzLweFFRVS7zjVmrTpcr9+wo/FzCldSp+kiDOpUJg8m7IaKPMSzFJk lKaR3llHFMYRkZJKp/R3ppJz61e4TZifaxGxL4VaM9uUuR9A7Q9G/jNsgxzbygVc1Po2q+cqK70y N8mORwnZSBP/Da5VFnFNac0ipvZA+AbclzSRmaCyEVXVZwOqus9GLjUndTjDAs5i2pbObrdDWl6y 4tQ8Uz+zLY2J9iOC9wBa0DQRivEQpvoREvURjOpuc4f/yum24LRcgt2O08WLfEIkZefZfg+lpZ+I nNFyLxWNm1uuLaGACe3zQEjKRkLH4+tssJXDeXCh9wabe3PUvu4HSh45lbL6tWmst4dwq77Zte6b kwUd1O8Vpj3ySLZEbtkNUAUkQqfDdWsz3dgwysJMKsDDm+LPBxfj51z/q2DwSyu6nvFdz1e3viw6 ZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago1NzEKZW5kb2JqCjQyIDAgb2JqCjw8L0xlbmd0aCA0 MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nNWV23KbMBCG73mKvWsyE7DBceL6 jthOxzPOoTZNOtPphayssWoQBAnn8PRdhB27lND0cFMxHkZo99e/nxdxD23HhXZxbe48tlrTUwiV 1YYP9Aute8s1AbC58RjOAgrqgetBsLDKPBe8Dpye9iCIrYOx1JhJ1PYwYwsNlTG+Go7ObXzUtuKi umjGOc7Ba7veYfDN6ryHYGIdHDuu47oOwOB2NiO3vcN3lndilkzKJYtRpYxjfydz2fIpyu3somYp crEQnGmRSJPTh0ESxzS5RbaSqBTMeJIJGcLsSWmMSaBMvcFMUVJ/32dpo07603RMkUut036rxR/Q iYXO0EmykGZKtV7S/DSNKGkeIQwiphSq/tbBrkJTvEfFX/ijAXhOu0yvq3mzZcyQ7+35+WIy40uM mVmwSR9tb59NHZgLFj2wDMHXOhPzXCOMZB5jVsYweQeDJcsYp/9aPJuHpa06Ui+eGzBVPJfxdXxG a5R6immS6aPCHeOra6aLlqsg6xCyq8F4stv+lU7ZOFCcpY4USjthsqaZIZZwEbVKgV+10lWKkqAg X0UkAuY1ID5ijTBhMsxZiI39tG+zAVTF5n6gKu02thft/BJfAXZcALvxJ9B13OJEGOJCSGGEt5IN +JI1i2qbrliw73ZadvdHmK+yvMkjSQjnIhL6ybScX9SgYmqAn5DWES3r2EY0MK1432b8Jr9uhd8U VR5p9Zbea4aXlUJVcP+I3BvQ1bILzoZ/2mknFVLlKfz3oLjR+b85nXSN8YCt2JKppTgC1EBFb3cc PaaCGgL8PMzpmHF7R+ZrCZXx5ZqsQ+8rKY4C6yNd3wF7Pj9RZW5kc3RyZWFtCmVuZG9iago0MyAw IG9iago2MjgKZW5kb2JqCjQ3IDAgb2JqCjw8L0xlbmd0aCA0OCAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nGVU23KbMBB95yt2+tJkJsEGp7VDn1xfOp5xmjYlncwkeZBhATUgCBIJ 7td3JYFvFWPLo9WePefsmlcYuh4M9dPtUeEM7saQSmcI3+iTOq+OZy5At0UFfA3p0gQ8H8LEsXke +CMYjycQFs7ZSiisBarLec0SBSdrdTtfLC+xVZcy4qdBs5a4AX/o+efhH2d0DeHaObtyPdcbuwAP s9l8CZ7rn390/M8mBvCdFSgrFmGwB8mUqoLBIMowesm5VNIV9O2m5dugjaI4GVgMb9Rh/Kow4gmP mOKlMIgBLFqFQvJNjjArRcLTprbhWY8Kc5RRzStzuizrgikCJbjfWEs6Cw512Yr/1bq/WwU7vjJi 1Z6pPLwoO+IWY1pVOQUMt5xJiTLQRXe39/5cuT4ZZ7TEGMOcKQbhtkJpgSDMuAS0UokOFxnBKAks z6FMQGUIsc5ROgdiTLggGC5MxHTz0EcoyhhzKngrDvKASrCYygfwcLOeT8Ope0zQ0721kY7WVAAW G9RJOmKxCKbGqkaJNGMxbLaGRJe4L+daVUe8ehq9ACZN7l64Ks0BJ/5JsOiPtVMdo8e75ezTcDx8 voD3rJQkz2AypWq+aZRBl6g00Ie2yN0PhxJHhz3oOrZrQOcjrETEY5IGmGOh911Jg90UBav5Xy0c 8/KdEFcKTmRiq+2RtkP3guaBft7onnCRwpqJtGEpwtPZ/c366RzkVijWajMauetqx8tyOppB17Kl 3H0f7BQTv6Ssged5I5X+m7z1MFVTV+SWhFLk2y+9NJqHGntwW1l3mR1NGA05GcbbfiT00IxGE6M1 ZC8sYzLjF0CeMz1ydi3aihMzmDYpUQFvcmHeJqdvmccf2ofrZ4JchM5Pev4BA/N8dWVuZHN0cmVh bQplbmRvYmoKNDggMCBvYmoKNjYyCmVuZG9iago1MiAwIG9iago8PC9MZW5ndGggNTMgMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydlltv2jAUx9/zKY76snYtGYFt7aZpEhvQIvU2 SLcHtAeTHMBrYlPb9KJ1333HTtIG6CVghCLAv3P+52IfrqDuB1C3r/wZpd67/j5MtFeHQ3pPvCsv cBsgf0QpfAtp0wEEDQjHXsYF0GjC/v4BhKm33RMGlUBTays2NrC0emftTreGt6amI778o1tdHEGj HjR2wj9e8xOEx942wG7tibW788YLmvmOe+iJiMcoyi7vacdLtOM6pxcnMJurmdRYcF++PuwbFnZ7 7d8FMgj7vdNDsGEUoEP+1n0/+FcbthKbA2b4NZYo5yhhYlISWKb6mDCDcSsijpu7RU6hNorTT1Is c200GJmQp/iAPLEWkIFhaj2iI+JK+4us9XEm13Dx1sWhI8VnNsTXmSBjWlqj1imVp7KbEzRTGb+4 fYUdtuKYW2EsaTPDKsMLJoxh0eU5M7Y3NrLwc54IVGzEk3J7rGPhF7JLQQmrnN/vUpDq6sntXFMp 1kpRJqybyJvqSAkc3GmD6Zpo2fOGlV3dkZk7pzM8lmoNRQ7r3M7oDLNXe3+V7GMkVfV2XkU3aOhV I711ivCcKdc82cVR+V464tpI9fJpKDfopuXODiAqPubRZmVKMeZl8tmp1PiYz7RnVpdP5goh+Pw4 8qKEaZ2ZhXDKtR1NKLQdFjGOOR15MFOEsUzonHGaQBop14AJ2qtT+xZ97zf9wAdYuKdymy2x+DVE kqxro0GOgYmSOyOtp/JkflDpZzevv1iCQgTccDMFBrG5m6E1u3WbJlu+jQdzFeWg7KgYUVjMyYJZ psvp4bk/+qDAxpkF+JjWngFKkaLGTclzjDFJZgYyeVkuYXB0dnHctnEaxgVIgdZaKpXTthzio7Ii pXAzRUHOFbBrxhM2SnBRxGpKnV8SRoN+HhkqcQxM5zVzEXxoODhkl2zK9JTvARpgiV80Bl0inP4n QGs+mWsDwcGe+ye11D7Dczah7qnbNuyE3g96/QeATGVvZW5kc3RyZWFtCmVuZG9iago1MyAwIG9i ago3NDcKZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nL1W33PaRhB+11+x4xfbDciA29hNO52hA0mYsbED8rQzTh4OaYWukXTk7gRx x39896RDvwyYvFSY0Vjcfrvf7vfd6Rv03D70zMfe/cS5mF3BUjk9+EDfpfPN6ecLwN78BP70aNE1 9AfghU4R14fBJVxdXYOXOGeTVKNMUXdHkoUaWtfkbjR+38Xvuqt83v4xv97jAga9/uDc+8e5/BW8 G+eMnr7p7rnenJ86/cvtsmcYas38r/dMmyoq1Gda9ipOgTCePtzCfIX+ZFSv6/n3P7rdz2c91/3p 83n3EWZsM2KawZcycO7NJtMPYMjVw18EYogSUx9fhjaKp/h26H3MdChkUkYepDN4u23Lzj7zZSYR Bu9aLfNjppSF9yKuigcQMQU6QghFHIsNT5dA6yVfZBqVa5cXrN8BzMafHiaz8ciFvJuuQULgAaaa hxwliDAHUxRAD3ymuUgbg6Sr+PHJpCoSy4TpbeS2+xhjQqg2w5rFGaFGIosDWKAtiy4/EgpTCKVI 8vCUJahWzEcFj3/f3kzNv18g5kpjADyFOfqmJPiZnCFkhXOyknzNNJ5QwqnQSGBUk0E0saoduuFx THVAgGuMxQqDCinMJIVJWDzBZDgdEt6Ees8UAivJCVkTi2UKXFUgKynW1NUAWCyoTRuuIyqGZlbO pgMbyWmu6oL4B3SH24e5B5gqGn4FZGlQZNFCM3aRKtMPSmlxEUSKVU6qnJ5VGLbA34CHxEEio3QX En3ka+IZoKbGUGUpNanE9p86wDXMP9493IzqvAztFpVTW1yHMAIbArEo1NHABCUqLAZRljDTW/oK SQUVAyMeC6q4oZxyvKYBVMSKycbMaCCUZo25KLdTWtDQAmoNZbIazbtJCKnQNU01mqUZJXetw+gv UxmL4ye60+JmnsAkKZB1vRrmE50gt4cwbRVyyVL+b+6lU1N+TgWUH2HCKNVfEeZFFFx3aLqoA4NO fQvbyi5FDJTJRHI2i9zGBlMFkPvv7r3J3XR4QzmLfe1/8b+lRxzss4phyatkb2BaBJNMaUNu2w73 pGbJCusVb+61ZG1uR3lzhyVr29lx3txtyQrmR8xZ9+QOLj9kzron66RemrMhstbpuEdpw7QlNMrD 8si2wFb2xCtETW4Xkgy2NWVJbcvGCh82JDTaz2ungsr8qJ7URK8Zj43HO0AYxK04kUAkXOf7QUi7 QxFIg2tItQwtzoRcAkaFZEueHxmHJKg6FRb9vhCkjsIySaeQ16KSyauHzovN/ZDCDwi7wjms8GOE XT+09ij8KF1XOC8Ffpyua1M7IPB9un77Sy5Fj31l9G4VcRqvppa6YK/x9xWX9H4yzJZmZ+pfd/LX Ymhej/dsidDvmxfCsed8os9/kzmZH2VuZHN0cmVhbQplbmRvYmoKNTggMCBvYmoKMTAzNwplbmRv YmoKNjIgMCBvYmoKPDwvTGVuZ3RoIDYzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt CnichVZtbyI3EP7Or5hvTXpAgPSaNKoq0UKuSAnJkU1bNZcPZncW3OzanO2FQ7of3xnv+3LSGSHA 63lm5pnHM3yG0XAMI34Vn2Hau1hdwcb2RvCB3pve597YH4DiI0zh94AOXcN4AkHcy+3GMLmEq6tr CNLe2UI5NArdYGZE7KCzFg+z+e0Av7iBDWX3oV+3uIbJaDw5D/7rXf4CwV3vjHaDLcLUORG+PQrH DiBMhLUgLYQ63WmLEegYHB2LdZLog1QbEJuNwY1weP5Db3xZQnlDtEPanPxcbq7EYSacuAH4F40G bSDVBocA/9zfzabBlL5NvacEHUKkwyxF5cifcBRDC59WrE3KYUYgwlCbiINx2kdndxjKWIbCSa1A qAiks7BHY+k34RQIMiJ4OkcQ66M33IskwzLHJ0JZzOAg3Tb/jaHH+2k47uSFMRpUIXYyYyCpI4xv qhPwsrr94/3oavQ6ZL6JWUyQs+xmJ5hfS7Hn1WywoUGqMMkiBAGJVG+8I8A6k4UuMxg18lM5Rxy0 VNah8PWLpKFMkiNgusbI8yaJYOVxihrVIEV87YwfE+EY+7SUU1XTatib1bE7CCJjV9iQp71O9j7Q VspStYoHwksRdrkW+3DYynALnjKx1kZw6WWjnHV9LocTCuVJp1Uta3parOQM+E0+VmMVNJTZQyqO Fe2M18iR9UHm0pHLBcN4qRY4obDY93sVZxXm058Pz3czWD4EsEbI6HYxQkxFMFQpNBc1DBUMJekX IroZIWm5HYPl+NeadFrGzZovHZ7U0vrHBCENJ6WVlSQOFR77LIQirJ1hzXYd1VgUIEUUQWx06k91 8+t7LwVaojdtglt+SSSU9TZLSe4hv7VhiXrYndFrAmzor6xvJ79pHUEVsOWb0RUgs8wNhVnVKYXK AuAm0xJkqxH24a8sUWjEWibSEU9/o3hTaG2R5JHySMumR+ErJyplusYttyRiVMiVFHshSccJtm/W 9FQnZN6Qr7BF8/XNlU3eDb653rXS+VrjNtfX72Pk1vPl833ZEWvrX38bDD6djYbDHz+dD14q9b1W Zk/BarH8ADyLauMTs6o7nhiWQReG34+2ZvLb61ZuiEa4vKn58GUrkH1LzqfeVtjuqHPOyHXmsKI+ z4m64Gr+8Xmxms9IW8zUMB+m7U54Mpm6DTB/ePSDzDvmNlVadjpS4SEfWHars4SGWON+hVsa16q+ nUqkaHciJHm+0Lhd8s9Xmh8276Kt4Qaw1K6B5Qcwg/Bx2zlN/S9JuIFFJOtE77glZIZOGx6qi+ly OqyRFsp3xHrO8OSoy99QPF37veSLKRJNfBRDuNlaq2rQZDCSbqm9sHyXqRvePz8FgMpypYvgCTLn ykO8n3jaA/EmqMxb2Qd05GlYqmT+ZUdD0sI022TWwfi67/8udbT08ig2SH/SWLXzoPeRXv8DAXH4 PWVuZHN0cmVhbQplbmRvYmoKNjMgMCBvYmoKMTA4MwplbmRvYmoKNjcgMCBvYmoKPDwvTGVuZ3Ro IDY4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicnVbbcts2FHznV5zJS+wZmRYl p3aTJ7WyU87YsWsxbSaXB5A4pNCQgAKAkvX3PQBJkZKdqzgaiRcs9uzuAfgFxmEEY3e0v1kVnN6f Q2GCMbymbxF8CSL/ALQ/WQV/JPTQBUQTSPKgGRfBZArn5xeQVMFRLC1qifZkrllu4eAT384vr07w wZ6YTBze9J8rTGEyjibHyX/B9HdIroOj5kampBHGorSwEXYJdomgJMJKq7XgyCHd+mtYYkUPvQKR AwONjKM+PX4eRNMBmMYMxRo1cLSYWQNMgpC7KbLtCISFxV+3b6/nNAPm9KhdCkM4LQKzVou0tvjc wJqVNY4Ig3dDSlV4MnuYYBQxWtYVTZYx2WNlShMh60dQOSlVENLdyW8d47uS2VzpKp6/BLi9S+Lb N7PrEGCR3MdvXtOfGdHnVLXIBTFVrvJVOwasghQfC7BS2iKnsQnV1ZfTVZAi1IZU3SxRolPK1Nly MEnP3o1eM1Ey4j0CwqB66pI7BFUJS5M4K6RqEJxlwxFhDxRLrzFpYwgIyWSa9p5t5swyUPTX2UBC 7jw2I3c5VZQGlfc4NK4awc3bReI4dPkI/QQOm8T5FioMbd6li5VKFl3yhoKNYKMFZd6cGpSUNdPM jNLUGoekmG1G+rQ4DX4w0T3Gk9H+mSgP69pl+hejPGiFPtPfj7JPW1YyYxoJqpVyMaPIuiG5Kku1 EaQ0KwqNBaNA+ofRdEFpraNGeI9aOQcrpZHcfXdzPZ8lM9cNHrckPYCrrPamev29s3t94DqE+Yyy jLhzNzU1jONiVphR1DNmhZJeEUHqktKGzgfx71pitwI1BrcVLQglnvcGL0gdh3cWRvvC7HJ4UJkD Eopj/rJP6of7qz9fjM/Hn7r2bZNxWB1zavpE+IV3oIZyfpY1d81QCvnZXWFgrK4zS7nlg/pko5Ej LSTZz7xbXDifyy1glSL3ulHMhPQ4rUePkrtf8b9f75snDJCsQu9C70Bf62MTWt0ZYT3VZ3TNXTCd TfH8Vcv2V3urb6muY7/NnzA1YXPItaqGnIbd1yL9yHbyndY7C6d0APxTlxI1S0Up7LaFn+1f7QTz 4hAwbdfkiqPcdMae8rHMvPjhDdql4uGMsuDqZaVfYLs11QvPgNvtyif62UNVPvPp7dTqZ+FoMlqQ 0PhSPh5RcVxwWgo+HsN6QFSgZyhaBnTS7Uq0YdH5ftpi1/5u41dV5QLHmyWhod2uSK2TzggmpF+M B114WHrPuNuP+t1yb3/rSRwq3W85g94DZtqF0JcQjc/88IR9ZktmloL2RkutHXavTJcPK2pGA7O6 qI2F6GLk36AOXqw+3LECIZp+IsjLJPibjv8BiUUlx2VuZHN0cmVhbQplbmRvYmoKNjggMCBvYmoK MTAyMAplbmRvYmoKNzIgMCBvYmoKPDwvTGVuZ3RoIDczIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCniclVZhc9o4EP3Or9hvTa7gYJK7pLmbm+EO0jKTkBSczs2l+SDsNdbVlqgkQ5nJ j+9KtrFxSJsTwxhs7dPue28lf4W+50PffsprmHVOZuew1J0+vKfvsvO147sJUF7CDP4KaNIF+AMI 4k4R58PgFM7PLyDIOkcTYVAJNL2RYrGB1pjcjsZXPfxmejrk7YduXOECBn1/cBz81zl9B8F154ju vu29MN4ev+n4p9W0J/iUpwIVW/CUm22N+kTTfopTIIyn9zcwX2E4GTXzevrjz17v81Hf8375fNx7 gBnbjJhh8LgLnAezyfQ92OKa4c8CMUaFIsTnoXvJU3w79C5lJpYqa0S+MNqR81AqLpa7wB/yMPit 4vOgQHyZK4SzyxbXYcq0LuGDhOviBiRMg0kQYpmmcmNzYMYovsgNaq+cXtB1CTAbf7yfzMYjD5wM nkVC4BEKw2OOCmTswDQF0I2QGS7FngNoFA+3dqliYZUxU0VWsmGKGaGWK6xZmhNqIvM0ggWWadEI E6lRQKxk5sIFy1CvWIgaHv65uZ7av4+Qcm0wAi5gjqFNCc48n6Cn0jSwTEJpWBA7Xbdmw4anKS0N Ea4xlSuCi3NFsxUstjAZTodejTQREDKNwHblSNXwVVkbkAYrJddEXwQslcTHhpuEUuC6xtqp0YWN 4tS7+oQqjugKN/fzAFBoK3eZPEEWXDUhQim0ZYCWLBdAkALrxakCe6/M63fgMaWukNEqJzWMwhD5 mgqO0BAxGpggknbg4bYL3MD8w+399Yiwbbkv1fKmTLNLGFEVksrCEHuYoCXlkuQZs5yKZlGKEioE o0IWlLu31xutZiX33t4Fk9vp8JqULxqafgxFy76sbdf1XhcZaU2gcCUVWcorW2lXWFULzck1RnW6 mwQFWvJ0HibNJW30mvGUUQVdIAyqrHA5yIwb59sYhKyhHILVrxnqOdc5A1jrdQG5M+chA9ZQpeK6 a58vJHmjaMOsW5hrUZvEO2zrGut/+fuQrRsVvsrgL/m6xnmVwQ/YukZ4jb9/bOsa6zX+/rmtG1u3 oyBb0Q4YVdtnYxdfLhUuGVnSTa4381I76od/UUkrPHFG6tJ2ORoGQ9sTDjYlOiCSYe60dPS7Xt5r jmLztiZlIaUeuU1dPj8DHCGcyCWidXEmVAxXrbBTqdC3LKg8qXf6NjfwPV529tsvzOJwGWF8Wfvz YXb196/98/5j1b6lL9rFMcul2+bca1GDDGlFTPPI9kLKxRd7h4E2Kg8NmTVqGqigyObMBWnOnFYR tyqnW8BsgZGjjbzFhcMpFXrWprbgd75LMGBfGJ3cCadGN5SoV53+428rgtYwzJe5NuBfdN3bWusd 4eGOLRH8M/u6MQ46H+nzHdHhGh5lbmRzdHJlYW0KZW5kb2JqCjczIDAgb2JqCjEwMzYKZW5kb2Jq Cjc3IDAgb2JqCjw8L0xlbmd0aCA3OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nJVWXW/bOBB816/Yt7aoo0ROc8n1igN8sdMzkDitpfQODfpASyuLrUS6JGU3QH/8LalPK+41lWHY lrgzu8vZob/CiR/AiX3Vn3HhHS/PYa29E3hL77X31QvcAqg/4gL+imjRBQRjiFKvigtgfArn5xcQ Fd7zuTCoBJqjqWKpgcE1v53Oro7wmznSMR8+dNcVrmB8EoxfRJ+9098huvae0913OTOpVMVrgI+o JEgFhVToA0wE8ASF4SlHBTIFLVOzYwphU8cAS1OMDSYvnnnBaYNI1+oBTIawLXOBiq14zs3DCHYZ jzPgGjBnK6kYBQIXEBIElwJe+af+mHhDWSAB1lDEa6G0UWVsSuVCLDdzMVisMEkqHLtsyXZTZhgx YEGpQ8EeOigu4rxM0C3sVbbjJqNwboh7bmEow5hpHFVfa6gOJvz79u56CovbCFYIpcbEBqbAQCFL UB0rjJFvCTlBQ7XpAaHuZwQrabI2bSaSdkMaYu3uEgRXtgIpNNcGRUwN5Y+z2ihMiXnASJkoyiiB VMnCPRyyjDokS1ej5XJdQfV5SQdUa1YWTFCf6C0VVWzswg5ko+SKkH26M/6tUUZIS7lYH5aaSHjM jFTtjiO1kHRT/x5KbKAtXZK0mIbLD2HoKri8pC+aCFEfVN7eJvQl+KqW4E+UR8pqBNVBVXz/qyhs utBqdE9PHZYVFmiiwIPKpg0xjItKXBXvQIYd1CNB1nkekt8gO6e+DukHMjygvppiKLwOalDQ6Fd1 1yH1BHhAd+2eVoXVYZO20Dhn2uapY8VX2O/nIyVak0FV2Ad7ctQYl3aB3QBjZUbpyIKqss5kMmbg Q1+trtJ/kH0RSMyOHxtTqLfV8bZbsMtQ2ByAbRknBee4P1fDYiiDnmppKlKZ53Kn/Zrk5dHB6+Ve Ud9b0L3r+88xqujZ4u4Gwg3G82kv+s2f7dJ7R4AhGvjURoXRcr54C/Yc62KfwNk14wfXFV9TN+Ds 9X6vauTIjahrXkb9MjuSmjEkiNJg27YqIXKv5ez93Xw5m9J+2yp9G4+Dw9IJhwLoRuwcY2hg1cMH m4ldWzlLEzkYjpphy/KSUDNZ5smeV8SZ1Cg6dxesQL1hMWn4/t+b64X9+QlyO0iDIzcg6IU02B9x Vo2SXa4Hq8na8tweewnpMZcbO9mlotXKnvnzyWLid0hz4VyPhrYph9x9aR0Cras1Tkadp6ndcjss LJfUD+ufzjV7h1KzG2TmNGp0ph1rO190tt3chRGg0HZ76+QJsm0B9GFaOzENCfm8wC6B+p9Lndsf wJ9mqEw8yRSrDXTu0Xabcu0V9+smeDZ2oorYF0bSzfgIaKBY7jfCn33bcGtmk3JdagPBxcj9CxyM x/07tkYIzuwkziLvPb3+A8odRAZlbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2JqCjEwNDcKZW5kb2Jq CjgyIDAgb2JqCjw8L0xlbmd0aCA4MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nJVW227bOBB991cM+tJkayu20yZpd7GAF3a6BhKntRW0QJoHhqIlbiXRJSk7AfrxO0NRN8doUBqG LIlzOJczZ/wDhsEIhvTxV571TpbnEJveED7iN+796I3cBvAXnsE/IW66gNEYwnWvtBvB+BTOzy8g zHpH89wKnQs7mGq2trC35jfT2eVAPNqB4XL/pVuX4gHGw9H4OPyvd/oewqveUfmCK60Ft2ATARut HlKRBceve+Ozak+YSAM8ZcYA/VDZRhkRgVoDy4HFsRYxs6LcQZZks0JUsRL2A8BNLgL4en01nYST AGDiEFKBFpHiRSZyOppZwl4rnTFrRYQoo9OWj4wjXiTzGKxyjpqN4HItObNSoRN5BNIa2Apt6F5G iIqv0cuHJ9rvvcK1ZWkhyHdCWSHKfAo7aZPyHvNA9m+DUeDjFpgOclHmPC0iYYA1WEZYQjIUK24o vUf7bvq+aImVMydG5BFe4fp2FYLITYFGz0PJWSZcPD6WTiaexVVFwBCLq9xIY8nZOiB8Rg+MD7hd nD9BYgFBC4ZenSADhMQjIcLCcDTA0mLIFSR/6mOCYfXvze3V1KNstFijwcshIKZG7AjWWmVtt/oe ifaW0JCq2O3onA1GoadJkaFTnL6/ZOzb4DR4h+X7Itj3XBjjD5nUD6pMGU9h7BosBzlakquT8nnO XdaDa2ETFQWTKJIUJUunzLKaHi7jDCL7tHHsevWYpa8ch6qkN6cgi7iWD8glCmBXeUWmziXpj8Qb DWJLv7qMmrtmwRSoLCNSRWUDlR76TvX5pEwzmYPKBaFlxNSaC02UjXM+IAO7ROSCGMG2TKYMk9x1 opXPukcMGKsLbpHaETDq5zRVu1oU3gwOrjcdV342uO3182WM0nq2uL2u2qKx/uvvweDb0TAI/vh2 PLiDJdu58t3XZqtwOV98pEQMGuNnZsR4ZKR4blg5fdjwU8osyUPL7uDat6NOJdW7fzn6pjKH16WM SXHOPrT6gJjikVsin7CSmWX16HjUZCRsYUWj7y5HqO7L2efb+XI2Ra5T5kvKN0KlK6ntSMS+vJcv n5y+u4NJSCvLqlaeZf6EUsdNoooUxbAl8DzB6ZQ3WkNqZDaMY2/d4RRa0O09pCQtODTyPc1fKNvC cm1FIKmTi+5u7Pk0xaOxn7ciVRsSuELjbk3iPJ8sJkGDNCflMiiLdTjYjQ2dWh2EgraV1NMsVZgP L+XSNFh1Nfqw++Vscc4jZJmrNsShWUESUR/ux4v3qzsrGpjfmRrNvDgYy2vvZv93pwFivRs7LoXs O0PuJrIPOJhZGlTUnz1upMb6T4q4MBZGF333T2ivQe4+sVjA6Ix6bRb2PuPnf/Au67BlbmRzdHJl YW0KZW5kb2JqCjgzIDAgb2JqCjEwMjAKZW5kb2JqCjg3IDAgb2JqCjw8L0xlbmd0aCA4OCAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1WTXPaSBC98yv6lqQKY4Szizd7YoOdpcox XqNUUknlMEgtmLU048yMTPj32z0aoQ+ws6IoQFK/fv36dYsfMB5FMOZX+EyKwfn9FDZ2MIYP9N4M fgwifwOEj6SAv2K66RKiCcTZoIqLYHIB0+klxMXg9UI5NArd2dyIzEHvWCznV9dn+NOd2UT2L/rj GtcwGUeTN/G/g4s/IL4ZvK4uJNoYTBy4LcKj0esci9GbV4PJ7/U9n1E8KLR2MX8HsLyLF8vb2c0I YBXfL24/0JeZApmicjKTaEBnIGAXYsBpWCPBRRetlAYftXGYUmy8lRaEc0auS4ew+nv56WZOIVBa TGG3RYVPBGrLZNtKQoABiqOfhMwF8R4CYVA9ZZ4ygi6koyQgM1C6QtAKOxGjBmihSAG6lghLQChJ DgP3YjcXToCmr5ihQZUgIClEROyQT6+1I9iswaG4YggfP61i5kCCPhFtrpQSMDaJ8xIq0Wuw6mgQ uVYb2BGpiuRBsCHsjCRj2HOLKqXPKjMqWxpskxKuinwSeek1SLSy0jpOGXDRy3PIud7zuQYjEPyT 9RTUQkHpzsk5KLlBKToyETEjL6gDdrIfgnShq+26uOxeKa8CuSFhpLURcr3xzDqYYHWDJWBbFoK1 Vb+2sndbkgsyppegeNRsM7Ish2Q6z/VOktJiszG4EWRIfzPa2iihdTQIX9Fo7mChDVJ3v3y8mc/i GU+Dx81JD0h1Uvqmev19ZztzkGlTCO9RkRD3lFPTwDAX+4gJWT0RTmrlFZGkLilt6XfL/vVI1P0K DQ4VrQhlMW8avCJ1GO/tKOoKc/BhqzJ2A+FInWL2rjHqt/vr97+Np+Pv9fQGY/SLEyymN4RfTi0x NLczL1OehVyqBz4jwDpTJo5sm7bKU5VEzFkq6r7wzUoltznfAxZrTL1s5DKpPE5o0ZFxuwXf5cIx 9nEnj7aZ1ZnbCUOWCjEgsozye6KdkkML6uVHw7mVvLdYI7HWRvh1pFptuBhNeJPqAvtLpKVHR4aq 5AqHb6uXSb0/CrFv61fp7EeoKYr9QOHSjfp7z3UbGmDCMN4u43ozc+BLa6Cb0LYZVSuzps3Orntx 2Kz+LEFIc7xMjlgdlkknIzExxCiFzOjCX+xnGbZ2yK8XznN7prOsjxfOim4le552mUp5vrWpp9Xy o066ffjdd1djK/8sExbef16twFIKfM5qLbVannvbeO4lq5GVagc1OD6dfdFCWJd9MGXHQA2Wf8Zb yVvllJWpA07Q2Fccfd6e7xqoIwcGnqf81mPn7daZvVO+O2G3kKLvtAaqV9D/erK1jdYgPfNki6Kp N0gsHsRW2K2kfy6ONu8IwnH181Eyx1m5Ka2D6HLo/wRC9/h2JzYI0fQ7QV7Fg3/o9R/74Ft5ZW5k c3RyZWFtCmVuZG9iago4OCAwIG9iagoxMDUxCmVuZG9iago5MiAwIG9iago8PC9MZW5ndGggOTMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVl1v2zYUfdevuOhLk9VWbKdosm4Y 4MFuJyBxWlsBBqR9oKQriZtEuiQVJ0B//C6p7yRt01EwBIu8536de6QvMPPnMLNXc49L72R7Bpn2 ZvCefpn3xZu7A9Dc4hL+DOnQOcwXEKZebTeHxSmcnZ1DWHpHgTCoBJrpSrHUwIMVXK3W76Z4Z6Y6 5g833XqHESxm88Vx+I93+iuEF97Ra//Uf+MDrG9RmC3upTLHL73FG7dJJksx3IJYCs210SBTYALI GdIDKcBIMDmS6fy0NQ1EzBMy9R3AihnmbzGWKmlugyeBwRKwwJIOwoGbHBgk5n5vAS0UeXtxVxYv KNAwx4FbLCNMNGijqthUChNA6wyUC1f7o1wCA1zTVixLcpTQYZMzA4MQ4oJpDbu/rq4vVjZXw7gA KRCkglIquqejFM04mDoBDYccBcWhgN0yXrCoQP97RW0T56NEmIZUFoU8uCys2avpk+vVKKSvI+hu ff0xRmO9ub6E3R7jYDWw/v2P6fTT0cz3f/l0PL2BLTvY7sHnzmwXboPNe1uMaW/8yAxTVChifGzo gu5cPiPavppPU51nVEU4ezumr+1vgx3mVO+64TnV2rayrjcXGTBjFI8qg13x66zeAmzXH6+D7Xpl h4Zq1VDSMZ2nnJpOZLVgmgzoQcwMcWPUIlr15r11VTtWJTGxsWyr2/Ci8XDLiopQc1kVCUTtZNCK c6lRQKpk6cwFK1HvWYwabv6+vNjYv5+hoLElVhGfdxjbkOC1PyfojTQDLDcQFqRwUz4+TZNZFOQa EiJ3IfcEl1aKTiuI7iFYbpZ+jxQIiJlGGuQ2HZqhngADzu+VvOV2GlkhqR5u/A01p8fqujGBg+Kk gfpE2wFWGi6vdyHQ/NlmN8ETZF2rIUQjXJ2+2BztYHfOKQM3zXVcvwEngSOtYOTlpIch8UBuJztB Q4XRVgS56MDj+wlw0wrIXtl0v5XLyybMCWEkrUkha0KMMEFLiiWvSmZrKoZJKQqobhglQjpTjoWm mSpi7dWHMLjaLC+o4/XE+U6GxrS1iu7kk9Q8woecrTUVE7+ZnS6TNnhiRqWplJ386SrOBy76wK11 K40TIAxKpaY1yJIbR9QUhKwRbJ+GFmOWuYZbqk0AuSPj9winJ/ZxJIkCTss73mM5qckU9aTwf4LG Pda3+PxMGj8axgGfn0vjHuNJPv8Mi4d5dXT+nyweTEFP5x+zeKDUrgTlXlqaObVUSL3JMoUZIyK6 Q7Vm208mMg/Zv4zkPefEDkMd8dsXxPpuzxVJ5LLKKm1gfj5xn0YPXiM3H1iGtGnfV+vQ+0jXf1pH 9dtlbmRzdHJlYW0KZW5kb2JqCjkzIDAgb2JqCjk5NQplbmRvYmoKOTcgMCBvYmoKPDwvTGVuZ3Ro IDk4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniclVbvb9s2EP2uv+LQL01WW7Gd bk6zYYA3O52AxF0dZRuW5gNNnWyukuiSVBID/eN3pKhfrtGtNAxZEvn47t3doz/BKBzDyH78lefB 2WoKGx2M4C19N8GnYOwmgL/wHH6JadIFjCcQp0G1bgyTc5hOLyDOg5OoMKgKNMO5YqmBgxG9my+u hvhshpqLw5duXOEaJqPx5DT+Jzh/A/F1cEJPV+xpzgy7BPgblQSpQBYYAvx1cz2fxTP6NQMu812G BiGRvMyxMGC2zIDQpy+D8XmNRCOVKmfGYAKMc6kSUWzASJqNoHfIRSo4M0IWwIoEhNHwiErTPeF4 BJEQPM0jiPXeLXxkWYkgU3dzSyjRHJ6E2Vb3yB3e63AcEsjkhyYsTFFhwbEfmMURMsH0spkA96ur X78fTUcPFGu8FRowQxvkYXAsy+STJuqV1h0xJIiCZ2WCwCATxUf7hIE2quSmVJh0wisqiSxnUWiD LLGUEqEokGwPmK8xcbIJ0rdwOD5DLYjn1w/YMecZ0xpu7m5jyllhmCClDWTItKmj92hWj0aCXqQe XZMafypBJafPNBYJXStgLDTFdCSnBcvRJtYT9ak9klGfREYoxFILkoFUbHJqmVsCxNZD2aee948g UtJEkXCozkg1FLQRJFSd3LjkUCpqUL4fWB1vf3t3dz33WDtlo/4K/YY4bUDYCaRK5l1iA49k51bQ kMmNm9HbG7TN3rbMiRS3X6lslt3EnZJr0rmTwtfheTglzf+gXdOKkt9nVj2refodrDw2XOp4yoh9 UTVaL5dRwZ384YyKyq5mmUu+z3GlOYPE7HeuOF4859kL1wbYAnsadV2QLporsUZtw3XwVFukWirS vatc/1T3C/QwDFeqVLNtmwDT5CCuy0K/6avh0fGqF+XnPnI9Pv83RrV6sby7qYuyXf3Tz8Phh5NR GH734XR43/TNQ7PsNl5Fy7dWp2G7+Itljc18sbBLOpr/D7atlkftXWxsX15cHtHZY3c8Ykta20Ks 9LZpI9+mrJYGG/GrqMhAV4v3d9FqMafKsFr5AmkaW9Xu3GuoQ/usXroKqTa2PlivrNWtra3aobJ+ vZVlRuaBrQPyrSRPajvT9q7eMU41eU8H19LePpAVa3sUkQl2jwmApTQdLHeUWZDMdVV/NnVIltHW VPSPmMmdtYNS0WxlzSyaLWdhixTZPtfYWnbPZJumoxxQ+z+SfFTxmSQ9vPUJ3WI12RjA01dd2JEn yEqrLsQxb7WHQLO5t2PPq++sLcy3eGzrrkdjeelpDr7VO7tBHTVR+xeJKi1mHxlV9lYMAA2JG9bN sXje0RGrYVZuSjoLxxcD91fooIXuf2cbhPEb26qLOHhPn38B6zf1emVuZHN0cmVhbQplbmRvYmoK OTggMCBvYmoKMTAyOQplbmRvYmoKMTAyIDAgb2JqCjw8L0xlbmd0aCAxMDMgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJylVl1v20YQfOevWOQldiPRkpzEbloUUCs7EeCP1KLbok4e TuRKupq8U+6Olg3kx3f3ePyQrKBFS8GQTHLn5mZ2lvwCg3gIA/6E77SIjm5OYGmjAbynv2X0JRr6 GyB8pQX8nNBNpzAcQbKIqrohjI7h5OQUkiI6mCqHRqHrT4xYONg5pteTs/M+Prq+TeXuRX+c4xxG g+HoMPkrOv4ekovogM7+hkYuZCqc1Go6eQdw/TGZXl+NL2KAWXIzvXpPP8YKZIbK0Z1oQC9AKEhX mN6DdFgcvoyGxzUeHU7DHMHgWhuHGZUnK2lBOGfkvHQIsw/XtxcTvqe0mMFmhQofCNeW6YqwAkpn Qa5+EDIX8xx7QBiQ6jLPGEEX0tEiIBegtEcArZAqWqCmlJhMFTgmkwpLSCjdiuBvxGYinABNP3GB BlWKgDkWRMD26HSLNdduxfunuqIHl7ezhEmsjX4gulm1AGOD2IvaAgV43lpdDSLXagkbIlWRbBTr wcaQ0MYeWVQZfbc4ngIqWxqkIuGqygeRlywC6aSstI5XCrjo9WnWnD+1WHwx8PqBBRXkoaDljgym KNmhDB2mzrL9UjXY6VOP+qDFCf6uDW97ZysvA7keYWT1nble8uId77vgYDVRWZUFNx3/aUOEnKdL +yBji5hKR2/rFvTtlubC2kqCYq25z9i2DUEtlwaXgvrQ34I2DusGwygCf6LR7BspRZb+cXkxGSdj joEHy0kEyHRaegO96L7dtjKw0KYQvjNFSoQzSc5SLpizXWPaRM7LIElSktfS/3v6n03yhZWrVffB jFCmk9bVGUnCeK/j4bYaTfNtb4xxpM5w8a7t+bub81/eDE4Gn+vMhm7Y3ZzIc73xXeCnTkcMzdbl ZcYByKW65zMCrDNl6qhFs67FlUTMWSpyWniHMsne5k+AxRwzL5skfZXHCQ49S9E37ffpoFZyQpLS DnIU1tWxp9XqjLIJ3ZC2u63HACny+3YGd6K366sSBTJuIBvs3eNqMFIQyr60MnsmQHQDFJ8NxP9D TEPmAlaT0W/Rb4jTAoSdwcLookusF5Cex/n/pPh1fByfxty8BWbSUwrrjLvnasVseCbR448M4Qsh a1OVesXjMfUSV4g8dNAziyvJBWTuae3T8eKxyF/4JGAHuG4IEsSmNNOwHsYyLEVutPy2u5yT4Tta VYmgs3a7d6f+iUDC6KLgNsuq+VJvI7R10LlubJ9mA4U2WHVJuzc/fPeQb5657cNxi8eOyvUsbYMM wtKM83Ognp+v+nuPV1uEvm4BN8fXf8aoqs+ubi/ryLTVP/7U7386GMTxd58O+3dNrD83ZdWbDCvR b4uflTWDsFNIzy1yrEOaav8F27dv/I4TcS9Wwq4kvWw4mptxTfnscU2TzsK4XJY0koanPf9utvPK dvdRLJEuMJ+zJPqVPn8D6UAsdmVuZHN0cmVhbQplbmRvYmoKMTAzIDAgb2JqCjEwODEKZW5kb2Jq CjEwNyAwIG9iago8PC9MZW5ndGggMTA4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt CniclVZdc9o4FH33r7hvbWeIA2SzSbNPbCFdZhLSgjO7s5k8CPkaa2tLVJKh/Pu9kmXsUGhTM4zB ls79OOdI+gr9eAB99wl3Xkbn8ytYmagPH+m7ir5GAz8Awo2X8GdCg65hMIQki+p5AxhewNXVNSRl 9HYqLWqJ9mysWWbh4Jo+jCe3Z/jNnhkuDl/66xaXMOwPhu+S/6KL95DcRW+PjnNDxarSCO9vYI4l poJZoSTwghnz7k00/L2ZnOTC1I8hZwZsjpCpolBbIVfArNViWVk0MU1ywxdr5NPxDcB88vlxOp+M Y4DJ7PE+dkgIIkVpRSZQg8o8mKEJ9ID7+AQyuOikXb/cuVB1YF0y28ycs+2YWQZYUAHShggbVlSE mquqSGGJIS26eK4MSsi0Kv10yUo0a8bRwNM/93cz9/cZCmEspiAkLJD7lvwWDwh6pmwHy+aUhgNx w83BaNiKoqDQkOIGC7UmuKzSNFrDcgfT0WwUt0hT6jkzCGxfjtLESIYaJcemNiAO1lptqH0psEJR P7bC5pSCMC3Wno0ebLUgJZlzqjilO9w/LhJAaRzlIXmCrHvVheBKGtcBChkCICiJbXCqwD0Lef0B IqPUNTKKct7CaOQoNlRwipYaY4BJatIenO96ICws/np4vBsTtiv3VC1vQpo9wkibKYWqBfECE4yi XPKqZK6nsluUpoRqwqiQJeUev9B4xwFeuw+fkunDbHRHvC+S+XT2kX6M5IF4Xdn7aYfCFbLWqpOE VU4MGtdKk7TiYKl9gU1NNKYymLZpb3OU6JpoKp53g7vZGyYKRpX0gDCowlrtoEphvX4zkKqF8giO x+7U2KvPC8FJsAcovEiPCbGFCsybnnu/VKSR2o5lrxbZshVLfFzeLdYv6fyYvDsVvkrop/Td4rxK 6Efk3SK8Ruc/lneL9Rqd/1zenSXct6Bc00qYet62BLVaaVwxEqIf0i7lgTHyw7+olaObOkWc0mI5 HiUj5wkPVlATIFW88gz6pnsnvzBEbQcnTcYp4dQv6er7HcC3QVBLqb2mNlbT18YAe25qVsNuUG88 Lavd5fvA7EF0LwtzOEKlmN20qnya33647F/1nxvTBjUcFsfcfugXOb9Fd5qhHHVFlToHFEJ+cU8Y GKsrbkmiaVc27YohJDHNPEOpcNwWO8ByialvGylKSI8TGPrOnCfp9+4gKVlGWxbxVCAztvE9RWtM 6kjoer+ttrE/deTvH+4xh7y67dbhhmQDvUdYDUQyQjnmVpe9S4DSDVCds8BPbXrSnQFr79FT6e8T pwCEnbbniZBYLyD94m51ysXhFHfptiLkFbV8Bx8cCsX3mR05re3lF0qgEw5rzk50I4648kpisGba Cl4VTAeF+K5eDj1ewr4wOvPlgrYGSyKPm7Pj5NuaZGlgVK0q0s/guudPnQcnzKdPbIUwHDwT4iSJ PtPnfzBPhSRlbmRzdHJlYW0KZW5kb2JqCjEwOCAwIG9iagoxMDkwCmVuZG9iagoxMTIgMCBvYmoK PDwvTGVuZ3RoIDExMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nLVWTXPbNhC9 61fsLfaMpEhy/VHd3NhOPZM4qSJPO+PoAIErCg0J0ABoW/n1fcsvk55Ob5XGI5rELt7ue/vAR5pN 5zSTb/Or89H71TmlYTSjj/hLR4+jebWAmh+d029rLLqg+YLWu1EdN6fFCZ2fX9A6Hx3d2sjecpxc ebWL9OZz++Xq+mbCL3EStHn7sPrc8JYWs/nieP336ORXWn8aHeFuYF16Ew9krDYJ2xhIFYV3hTcq Mu2cJ37Re2VTJqW9C4GcT5U1P1U0zoYp0WU4fjean7QZc/acHUhRoqIiz4XngLzV8jGZSInjQNbh wnjWMZO9o3dJqbmDg4ySy4RQsuzxu3vmJ/ZVvAmUlsor9IMTinsVqVA+GmRtoBqbImeIymoOTSq3 w1KEhoK12Rld4aFnk2W0V09Mmn1UxpJ2CPJVYTcovorxrALAN5ninqm0CfvsIBvlHIJKq1blgKIs MAFcKJwHMO+i0y6jMgDr5/tva2IbSs+9XP1+J5x6ZgELHLuKEKMyNGQsTcLD6hJ7NPGqRAas0ULh rsLLXYnY6sl4Z3OsmCJgcdZy9KVPYd3CjuWKtjJIaVXxidOlZCDlme5XH6+vKLoB4wmoyVxBrmCP lAhEQZoTlNkk73IIvJ3LMvcsy5Q0FsU2xTSt70E9nc7Bw7pt5+RbW9mHhqUmcv1vlMhVj5QhFdF1 FQ9q6WRTC4brwaqZQ4YnUDIgrFPisI7/om5A2rQBHyrSVZNBMCTKJ+YnoHYj2lUAVthqV3roLmky rFhlk2hyIBajmDSZYBjPzv+gK95BeEzfj1a3V9+PX3M9rG4+nM1+Od1U0IzMfwhOS3E9ITfZtsYm 0tYm6GzT9SSUet8hHYpN0Gncxsxlr8W0c1bJqhIJmgKAIfpSR0gHYGxNH0Q6dBh1oC10pLIAMWBh rftD80A7NEE778sCysNuomQpxET06tbWsmsqet6z7C+Pc7iNeEIHEWlxDY86SMcf4UQCRW0zHst+ 7QgWRdbaiVAIW0tNlFJNapVUIp19j2StU4A7fyjqAEus9L5JBbMU06hMCfQKj0pH2rq4b+QYuG9Q fyLXC0YiNiP8mqlnhH27rlMnjMS5sVwJ3MJFa13mLEEm5GOZm9ahBl6GvZBG+G2OkDNp6eXdpUxk gBB87SlvBNC3EUg9wEfugsxgwgHSAJl/ff5EVqFDhZLhEzi4NaA96D1DDeoBD+rrr7D9+Wb4/2JT zZ+TAlPZQs6g1EBW7aHSldntLlKrNH1ydnGxGap3VQfX7fNcqaBz2tocepLVhy373iHWN5ZOzGAn Yhjlqit5OdgUn/vV7ZJKb5eG426JA07lYfmSZ0sblsYlvJODfjKfzpqqelDRZLARIZ0l7u3YUy1y Vx83cB/nwztSSQKDFjZCTesAb3tkcsfc9C1E9H1Jd862k/D/tkoUUtMsvTpdVKvX6ofaq7A3Y2LY fDZt33auXwojx89lmZZAMb8YVy8/b96JHr7KPC4WG2S8Xo/+wPcfJWcoVGVuZHN0cmVhbQplbmRv YmoKMTEzIDAgb2JqCjExMzYKZW5kb2JqCjExNyAwIG9iago8PC9MZW5ndGggMTE4IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicjVbbcts2EH3XV+zkxfaMJevSxA7fVNnOaMZOUklp OxP3AQKXJBoSoAFQsv6+u6QkSiTbFBpbvAC7Z8+e3dUrDAcjGPJn/y2z3s3iFmLXG8In+ot7r71R uQH2XzKDX1e06Q5GY1hFvercCMYTuL29g1XWu5xrj1aj799bEXlorPmX+4fHPr75vpOq+bJcj7iG 8XA0vlr93Zt8hNVT77J68W0xD6CwOlDooyAXVmQueMvSwMkEMxEoE2LEZvujwfDqojf+cHJ4gbFy 3grtYWa0F9IH9CxCCwlaBG/AJwii8Imx7gJEGFp0Dh04lF4ZTfZGkxN7JioPhEYWGWo/aPr78/mp ywE9hmUJF5SuXOY56lC9dVlkW6tEOcgwMyAtCk+IeFdk0tRslY7BVoHt6JGF+fTzlF1lQosYg70J Wp9FhgcPhxMBvCuzAUtvC+kLiyHMdmtCvERZWOV3MNdkNRNdBCxzlCpSsnzp3jXjZ4cuF5ICQi9U 6gKY1lgpvj1i0fLectQB5tw7vFwuZ3Nwp89erkASLnLnahZMFDRxnkJliCQy+L54nE0+3n34i+gS HpQ7pk4fo+IrKByGTbi01rsTnpEDa8Fr6aXJaImKARFfnGbJolWaL9k2GUtTDPum8BUUE3UA4Z0t 1yy8pCCF9ElPoVinrCab/RxRWX9TSCkolpLR5NVCZuxRWbTD1ex1AIqsyWCbKJk0GTqHKIWGNZld c8wYDrgMsM4jrX89+vxtueKzHJxKdyB0CHmxTpXkmw1JkUM+s1WiKlNNAXTxMM1zOl9SNUsFt4Wf EPHw5qmoO8WxN3BATfgpH8uqycAvg0llgjR3bAT/GXw7vSUBRlO060qhsFW+5PvMxgHiEdC+H53X aIuN0yIsKcsKYoE85dZsFNuj9kMGVayptjVuYSPSgpS84l63NhtscnKgUdWWW14fFaahY9MWpbFh E2xQF/FNu4xumi5/R+vo5U07rx3xKq9EWtPChUjUkAKWiIfp4CoN1Wkc0UT1iTVFnHT0s3rTbcVJ y+2U2vs+gq+GMFKED285Wk8zZaOIVa6y9+Mx9SgW+FnMTYcLfC0Ua+V45twdZ+YeOWM0XsKDH1Ig 0pX0VUq5mRapP2oJMkWsvVw+l5PmXOhzLUkJNGmfVJz4LfJ/MisToWOkxrw19gc3spj4ybl0lKd6 KKSkict3EcW024uVHifwxyfCwq2cHOIgHlzDRgmgIarSw2A9s3lBE5Pe8T2r6+WqHqb/I1SL1HJx g93tkyy9H5eRrsQPkQiXqGtADyId1KWVE98OpkXMxTG6uy5/0MD5+v6ViKMfTtwnH1a93+jzD5kg 4dJlbmRzdHJlYW0KZW5kb2JqCjExOCAwIG9iagoxMDAzCmVuZG9iagoxMjIgMCBvYmoKPDwvTGVu Z3RoIDEyMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nKVW227jNhB991dM9dIs 4HvaJmussnAcZ2E0zqaOFu2iKAqaGkusKVIhKV/+vkNdHNtYtAFWhiFYHJ45c86M6BfodwfQ95/6 zrNWb3EFiW314RN9k9ZLa1AGQH3jGdxGFHQNgyFEq1a1bwDDS7i6uoYoa13MlEOj0HXuDFs5OLtm n++m9x3cuY7l4nyxvO5xCcP+YPgu+qd1+R6ih9YFPV0ZnYFLEXKjNyLGGL4sZiAUaBOjAaeBp8jX VUixlIID2zAh2VJI4fagV+9+bA0uGzgfZnPkYiU4c0IrYCqGDRqx2peLXBuD3Cm0lvaWjyhhF2Cs CMhDiCzXxjHlwKDNtbLikKoMv0MrEsUcUZ3ucjQOhPU8UdnCIIUwVyP5aIOJsCQcRY/znOizpUSY SGYtWmC0geVUem4EIcJKm7NdNdTzZHZaV5cWahWvPHu+VnorMU4yVD7/8JdGkt8RtrqQMUixRk+U HWIR5qYLd4yEh1tJzys7pvNJG7aphrVQsdyfCHywKUGFRhcWbJF7wdqAJUEmJUmlyjJm48dxXYvZ k0y2QNutKyJaTFp9xo3UU2t4YoWEieApqb8WFanH2XPUhoVeesXnzDjRGFYuz2fRYtqGX5lLJaKC uSZFDbn2WtEDS1iMHJ5S8jPPscYdR5/bjcppkaKAryxjScHTQ+YJZR4rR3T2sCjcWm8PtL4yphhE yFOlpU72DZRvu1uioCAyLMtQVuGT6SLqPaJ7HjdeCwNWKE5eQywsL6ytu7apDjFeemtKTanVYs0L b/JRB1z7DqCKVCx2MBvBH/MHeKa5yRh160ooUU6CTzjdOepT+nXSIhF5dbQnRssNdb1KShdRos9H mT0WWS8qd4+xXhvkKKGlQfN3Ip2IDZmSUpVEdcp42kwT7liWSxoFAn2u49/Xpdu07I0lVgMsKDW1 yIZJEfthITuFsq5SxVbUl3tghdOZH89mCrWWZdfV9X74uMukR/TUw2DQ7Qc0u1zHVG8YfInuO9fB xxu/+cPOxqMa2DGToHtkGXU54xgGhVEjgW41yhkZbEcEOlJ2JDSp5N+BHQ98pAyt0zIhhkHqXD7q 9bbbbXd72dUm6Q37/UGPHKgMCErm1YYS73+y1ZlOtngKbyd50Zh8r01GDtL8uTB4KUhqL3sAzDnq iMLhSUChXkNujhT2ulWvUVBvVOxMrUr1B1297MKgDPq7etol+KB3nO+HTuc/9n4rbxVzlLvEu+h0 zmDD77xeaYWhH7G7cTT+5un4hqtEu/heRmF4WqT3ims/g7toTy9Fb1gY1FRLVw+zfRw70fR3QLmb esiqNTowqU2qIV4yi7Vvo8ObwmcIDnvqXRZfChpA9M9/Hpa5IrZmKbOpoFPF0TnRbTSgE1dQFhgX SUGjP7hul/8pzpT684nR2Tb86S9CnEat3+jzLyRhwEJlbmRzdHJlYW0KZW5kb2JqCjEyMyAwIG9i agoxMDc0CmVuZG9iagoxMjcgMCBvYmoKPDwvTGVuZ3RoIDEyOCAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nNVWW2/aMBR+z684cx/WSk0hQR0MkUqs0AmpU1nJw6RpD8Y5QNbECbGz pf9+tgklYenWrXTSHCVRzuU7F3/HsIb2mQNtfZVvFlut2y4shdWG9+peWmvLMQZQvlgM73xl1APH BX9hbfwccDvQ7fbAj63jCZeYcZT2KKMLCXtrcjMaX9lYSFuwcF9p1hXOwW077on/1eq8Bf/aOt6q BoUI+pTfA6cxipQy9MjRkRIQSLOEoRCXiYrOpfBIRAsCcchvGMsz9d0mJ68tp1PDg5gWW33O50nO AwxI60JZljaDlg4pcJ0jZ1hVmFSkzMJ5LtEk5JFA3qdIQD89EiYBLvpGZBv5zhlyoQxUyqtwHkoV Er7RKFeiIo7q4Zui6ObVIpkUlQ1fkg1yksow4fQJWDFSbvx+Qvqt6yLJYirD4G98M9SWTGdZb1dF sWnaDmqzFRWDUrORsyROIyzK/TeqmsJXYFpaMmrwyra9Z64dnzwPZizRpcNlRIVo5PUvl0E7fm5G nmfbukj3TUlz03yMMFY9KVtfJkou6uMwaOhVdQcbRuBReJyhrG2rnvX+pw/Xo6E/rI4B1Af00OM4 S5FNRg383J/ETAGGWS1WI3ke2FbWXOn1wQk1lJKyu6mqSZ2mf06rf0eoWqIvRatb+n1EJX0ZVjVH xAVmOjUCGS6259NOevCA04hKfaZW45kSHxT/x+Q8AlmjyZOwG37FGqfy3DV08+kdXVGxCk8BJdDo bNupcZGqFAUM82UuJDi9U/P/Ym9gPk/pEsE9/6IQx771UV0/AInJiONlbmRzdHJlYW0KZW5kb2Jq CjEyOCAwIG9iago1OTcKZW5kb2JqCjEzMiAwIG9iago8PC9MZW5ndGggMTMzIDAgUi9GaWx0ZXIg L0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VZRb5swEH73r7jxslQqDRAtyaJSKRvpFKlTuxZtk6Y9 OOSgXsEktlHpv58xoSU00zal3V56FrLw2d/3Hb47sQbnyAWnGps5ykj/cgSJJA580E9C1sQ1G2Az RRm8C/WmMbgehDGpz7ngDWA0GkOYkd6cKxQclR0IGivo2Pw8mJ3aWCpbRqzrNHaKC/Ac1zsIf5DB WwjPSA/guF/K5QRTzJCrk4PXxBsaz/Er2/b3NI3mDgya78PnIuUo6IKlTN3B+5RKuVPlL8yg9fZV 5Pu23QpSh9+KHjjN0Le2hFonD0FUMsz+KM9WKZbh3Qord69WaFwS1wXyqL2+k+SS3gZUUQuUBvEt li8xri5u8vXjWTANp1b7PGSMn0dRIaRvORZktGzeCr7IC77EpdX/LSPGKCppFgiMN5STh9UnJ7xI qYpzkbX5TIj3jienvIpywXjyiLFZ34ewLpQd92t0UKUEWxQKGyUrjOZBc73mpOpKKKR2CQ3IRJdr F+RWXv4Rdr5SLOc0bWHXUTxO4OdsA9t94AvSG466+P+6BdT27xpBo/SlB7z0gA3d/+4BTUo+e/kP 35h0D+kNvabymh0CKqDpUfPhZuVKK5YwLZJCKnDHh+bXolOr3y5oguANv2vEWUg+6fETlBGAJmVu ZHN0cmVhbQplbmRvYmoKMTMzIDAgb2JqCjQ4OQplbmRvYmoKMTM3IDAgb2JqCjw8L0xlbmd0aCAx MzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdVm1v0zAQ/p5fceQLnbQsLxVr qZpJhXao0tBGiRAS4oObXlJD4qS2M8K/n+MmWgiFTm0FAluRlbvzc8/l7pGyAefCBafa9Rmmhr0Y QCwMB96oJzY2hqsDoD7CFF4FKmgIrgdBZGzvueD1YTAYQpAavTmTyBlKa8pJJKGz5rfT2bWFpbRE SLtOva5xCZ7jemfBF6P/EoIbozd+Zln+sevsueH2NZzvw11CZJTxFF4nRIidPH6zNFjvaEa+ZV0p IO9SswIYl2I1wgRTZBIYSdE3G57m1SP9ioEODbM0T7AMvudYuXtbctolcFMgC9v2nfgL8m1KJDFB KhDfpNkKo6ozo49vb6aTYGK270NK2W0YFlz4pmNCSsrmrWDLrGArXJn23owYIa+omcAxqlOOHq3H JBzbv6hd8yBScrosJNZM3ucYzqdN6fqmCmBxm0IhlIsrQMq7uXZBNu16EmyWS5oxkrRgtwX83Net vf6QrZk5hTB+0MXsXiVYYJ5xeYg0TiSM/bpo8TydNMJ1Rjv2w0RjPwFjjww6OrJ38vvr867b8M8O +wfkNKIhqZgdMO1/bNjbPP/jaX/h6aoC8pWsiVjTc0AJJLlocGdlrqZSwKSICyHBHZ7r/4ROVz7d kRjBG3xWiLPAeKf2A/M3VpllbmRzdHJlYW0KZW5kb2JqCjEzOCAwIG9iago0OTQKZW5kb2JqCjE0 MiAwIG9iago8PC9MZW5ndGggMTQzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic zVVtb9MwEP6eX3HkC0Msrx2sjdpNHd1QJRCwBYSE+OCl19YscTLbodm/55yXNiubQCAhHFVR7u55 7Lt7zr0F3w3AN0/7TjLLuzyGlbJ8eE2/lXVrBXUAtK8kg7OYgoYQhBAvrQYXQDiA4+MhxJl1MBca pUDtzCRbathb83ez8wsHK+2ohO8763WB1xD6Qfgs/mYNRhC/sQ4619ir1CJK1jlP8OTZUysY9NyN U+FtiaJxdw5jZ1pLfl1qBMEynNhXBSbzmQ36rqCvGkkBYmXvcFAqckki5BIXtvcryk8o+ZInTPNc /BZ1XphQlvao2wzzrEixiomg9TR2TDFDoY0tfFmnPn7iOJO/XLtCTiZwSTsseJ0DvEqZUg/26NFV sx387YkmjtPLsS13m3xb7N457T0pjB8u4db1gEQ60FZZB7uUHtqcbWZMs67FPF/g0ug5+vz2zWwa T+9p5TEOXKI0x7BB4rIliXbW+xT7yv9fNN9rwz+TfJNzssaMGXN7R4xcgGlRoFjwCubzCKgXcF4x Q6v6YoJ4zRUoTGqNFzL/zheogAnAJhrypfniIiEH9YtKS71ZkAH0GpsbzL0nuZpxkYPIqbuYoFJM 8vSOGltIVIbDAHNBpg27A523nMCgYFLzpEyZbOvRbUvpnGGab4D/dDZ4dTW/jA17TmCxMn5qDEtu 3F6ZTqsshe8oFaU5sQPXt5tdCTCxP8YXztA+7U3OuLmZZ3lS1irtIwmaMgND0XSUqIWa2KUUEUe9 jCgLlqmIzJFQUTMPZsddcGP8A4iZq1/AKGIfWikCrbUuIs/bbDbuZuDmcuWFvh94JIyrWj0OF0oz M2yd5OZdz4tSFnkzCm2R7Z1gu6j5rJ2CRHGp3bZFLknZPgmGo6PRYOztYnf4y5oz5hmemAM5/sgJ BnE4iIJRFB499/3I98deL2qLnKFKJK9n6GR71uaIRp5miJi4g6oae/3QLX6qFImzG6gXYd35mN2w NVNrfgiogaVud+mcVwXdAgqm5apUGoLhYf3HvHflf3nPVgjh8CsxnsfWB3p+AKDVYP1lbmRzdHJl YW0KZW5kb2JqCjE0MyAwIG9iago3OTMKZW5kb2JqCjE0NyAwIG9iago8PC9MZW5ndGggMTQ4IDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicnVZtb9pIEP7Or1j5y7VS/ErbhAgsccE9 oYOEA5qeVFVoWQ+wF3vteJeX/vubtSkxZtOqNUEOM888s/O2u8/Ec3zi6c/xzdKWO70ma9nyyF/4 XbeeW34JIMcXS8mfcwTdED8g81WrsvNJ0CbX1zdknrbeDIWCQoCyBwVdKdJ4hg+D6KMNB2VLxpvK 8vkISxJ4fvB2/l+r3SHzUetNpegO05wyRViW5gkonometaI8gdgi6lsOPYvGKReWG779o+W3T5Zd ty8lSJmCUFpVCcegNll8+o2SAUhW8FwThzNVbJnaFhATLlZZkVItJvhHlaLsieT4xjCvCBzyJOMK 4hcmstsmAgq65AlX364IFTHZA30SuIiuW3dT896PY65lNBlQRUlcRXRIE6uGQhzPYljp5N32y5VM qoWQWQ5sOOhZd/1JdLfwnQ9W3YycgU842393Tn/mYEr3ei0NgF5rSbY4si3uEJRka3J8L+5pCkcH VtP2BHqEQpYl1Es9SdEfmmL5PdsPbK9zaY8ZEfL2IHnP2iiV37rufr939m0nK9Zu4Hm+++94NGMb SKnNhVRUMHiNJVtKKHZ0mYA8sTGKiXRSrgooKWsYA43ktyLT8UpsTajcjjJWdkvvAv6ajxijdw8y dmm+kCXHYhc4voOiZnnK/D9y2MvQ0U/XrX5c1Mg1F6lZbfdn5e5OYQUFYBYvfZxUOgPhiIsnojKs JUaHndV1z/UX5p+mo/BHGcGFcVEOhXT9d85GpUnX1UbNGMxLrMd21v6vDdRjfWxfBuoxwnHyzot/ Bj2i7LJt2x/e/9ZMsR38ajvVGmoHteRVLaSF+qsXX3aSeQh6Zg5tHGd7kWQ0NjX+70yhqZVx50yJ hGfcBzqdju15XmARUW0gmNKasNoQUWjiwUkwkLua3TAaGNyvz8ELYJJQpc+ElxaZRIvAaTfT9B2n IV8QQ4aDr9XpZOadsazgYl3rvNkMeb3LgBtGMANlSu6SSlikoArOLneIEiG1ddhx2l23+teIoozh 0WXvgKmsCO+j+eeH6d9d91z8I8vqyD7grITjaDD8ND4Z1zRmgq3a4LnNqxkI7x/uI7Q9FxoNWSZW PNYoqmfU5uXlIbx7GE9G0RxJXgEYyTjeadaFkeZCZQ5jhxeV43ZxyWHSmsuVbQvc5Y4jJ3axI7hU zjrbYf0qHdq9D8q7z5w+0Q2VG46XFEVo4nyniQ45L0CS/na9lYr4N1flhavh7MuEroEEna/IGM1b /+Dnf2L4yF1lbmRzdHJlYW0KZW5kb2JqCjE0OCAwIG9iago5NDYKZW5kb2JqCjE1MiAwIG9iago8 PC9MZW5ndGggMTUzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVXvb5s4GP7O X2Hx5TppgCGXNYlIdLuG7iJ1u16C2knTFLnmLfEVMLOdJr2//mxIRoB0+zAjBNjP+/h93h/mG8Ku j7C5Dk+aW97yEqXSwuiDvlPrm+VXAHR40Bz9GWvQCPkBih+t2s5HwQBdXo5QnFsXi0KBKEA5c0Ee FeqMxd/z6NqBvXIkZd3FalzDAwqwH7yJ/7UGYxTfWBddSJhCAYIoSBxeOIl+USyHmbFysO/4fozH k+FwgrGLMXaweXvzm+UPzrN55+m0xUUX+UAkrHNQglHZA4Qe4wk8GmWTFeUCVqA6oC6EFWkLcbp+ t82MWw8sY+qljWpA90CeCpASrUqgi/nUvrqP1kMX2619j6gDQEdobHc9aziXZDcnivT1HWnWV3o5 42kvQvs8K+RkL9nU3ihVTjxvt9u5u4HLReoFGPve5483K7qBnDiskIoUFOwey4F9/YnkMLXvFtE9 ulms4gmqXNcZnaAlSCCCbtAV1xSlkq+z3IGQjBdTO3B9+/usFqi5dcX4Dh47/qBvr1VMCm58kCWh UHt9wylRhq0HPwqmO3BzpgRUmnUxEW8vEzO9lhXF+nno+q6e62agjvEdg52cuWaEXv3Rr7NuIn5Q ZeeSebp+pDoBhN77JGFGJslatqH3EdSGJ82EDr8iVCHBMx1OKoAoLmykXkr9qQNACvZfFbBTsUcr E9tZtCd5mYFLeY6uVotlHHqnyydWS0iZVOLlL1IkGSBx+JzaRLeRPYOayNFEodfGnrJEOWHZjNZb /EElE8qFxofQqwGN5IM3zUz0DIXqxDS8zviuHePVi1SQI10vkHLjpuRbocu9m6tPOhX9FOsMCNPW jTkrn393iJ62Z/44cLEbuLqjqlyJdv6+R3lrjuJDMsB4bc+Gl0ZRtdArmp4noVeL+IkwRUQK6teE FYbgqMt/5wWj15Sd8dM4BeKZUUCsXJeCK055NrXf9VssvOVCzUY6btVLl/pA051v9wNK6pDq0+7M Bk1r3WZEPXKRN2fzbbQO3DNnzRFpQF80Ci3mX22v590rbflKqkKvU5RhtNeOqKofkS7p6lR8yDh9 cjZcKhtVOw6D6i8ZkyeyIXLD3iJQiGTucSdNwnRa0PttupUK+aO31e8atceXW5ICGuCvmjGKrX/0 9T/E/zS/ZW5kc3RyZWFtCmVuZG9iagoxNTMgMCBvYmoKODcyCmVuZG9iagoxNTcgMCBvYmoKPDwv TGVuZ3RoIDE1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1WbU/bMBD+nl9x 6z5saOTF6RhQpWhAy4bExlYihjRNlXGurUcTB8dtyr+fnbY0CWGMCVdtpHt57vz4OTe34DkEPPNZ PVlsuYNdGGeWB5/0d2zdWqQIgNWDxXAU6qA9ID6EI2uZR8Bvw+7uHoSx9fY0USgTVHZP0pGC2jo9 7/VPbFwoO2O87izWCV6D7xF/K/xttfchPLPeLh1Bf5EiU1RxkQBl5tFtCTVB2XIPtt5YpF0OfmXb EAyQCRmdKowPYEIzoAnggqFMFYykiIHCVIzBtk36OnGZU7Lc23pU0Ypde7QNQx7jge95xPb2bdIO yV6HkI5P3nl+x/MC9z6mnosZkzw1Gzmg8AOv7QzlHCXgHBMFsiiq00thNYTN/iBSdyl2W4t42qpF 6TguIhwZxjt9Az3AVEgFF5rO0163ddzvDz3nw8O8SuaA5g0ErMI0BOjSSdZtTZRKO67LEJ2YK4mO kOMmaLMcsxoBXY3Y1I/7dEPlmNJ269y5JXFUDtttPO21+d4UuAV4JSz4zDMl5F05zwjxWCRKKxZy rcFU4pyLWTa9g5hGCDlXE9AqhkzMJEPQo5MLeQMiT7QUqtpcwRcHvp4AtsS2l+l2xhVW6W7Q6PvQ 0xrd73hao97jGq0o9KtQfMTZcvwyI1Almk9VL91UpriaYcLu7FWHH8m+73iO7/hFwUZVB25piyWq 67wGh1HETS6dmgN4RP0l9V6i3HS/Fv755eHZcMchXo2wpzQWiDmdDnUMT4omshoP1UkwwZtRcK++ nF2wCca0cNglFHun1QTU4Ulkwro153/gv9ZQmKL+SVRzrSlPZouXqlaANdcx0f/IEBNxLJLHyFmX fYF+mwvMEv5ihBis5iqLjN/Tkee5k7cLNDOxG0ib66miCcOH92nDTRq4dZnW7rm/ybzsLc/OM6br 6vi4dzIkjv/c6VowFo06R/rumMRU34Q80pNtbENNiYMLGqdTHF6v/cOVhRhmd/ziJSCkN1T/4U/4 NqACfUBrcP0OwSVmcDgbzzIFZG+7eNmA6vr5jY4R2uSXRuyH1nf9+QPmW4HzZW5kc3RyZWFtCmVu ZG9iagoxNTggMCBvYmoKNzk5CmVuZG9iagoxNjIgMCBvYmoKPDwvTGVuZ3RoIDE2MyAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nH2VXXPaOhCG7/kVO745yYwx2CQkMMmZCQFSWkhS cE9Pp+mFIi9YwZaJJAf4910ZJ82HqRk+bEm7z777SjxC0/OhaV/lN09rjekJLHStCVf0XtQea34x AcovnkIvpEmn4AcQzmu7dT4ELTg5OYUwrR2MpEEl0dT7is0NvLtGN/3BsI4bU9dcvB8sriHeQ9D0 g8PwodbqQDiuHbwa3aRJN2Fyce6gdGAUnTsmm4mFdA7/qfmtitlSd2OTnjuxMatuo7Fer711y8vU ouF3Op3GhgYTu/jjsg3n0fxlIY+RLxOhjfYkfXqL7KlRzGj4XlAdgK8wqEeCmz9BVuilwigsAOyQ yCRT20bgNZ1/3wUBz15vH57tcnZ7KHmcMrV8s+isIbII51ba7pSt+8ywV+OvR/9DJeaCM5v/ZcpZ 4yKKRIGUvFp71hhJLiKUpnhAt0UP+xnP0/Jh2Se/6QFMcY6K8FDTQNB+HvBp6DpTKaV8wreTbPKf 0+Fl4PudXwA9xSKJyoWZ54LzBbewzlSkYZ4pyDWCkECTNZgMRjKyRWBl88GyPOZCocWEMT5hoh0X epe34B+5NgjYlC5MmOIxkB9OvD/MJVSrc9q2UNbTStfHiC6EBDYUmERCLigO3TEZwdijQFpY+xP3 NykION1PprNccSQLExz1AhXcHXybju4Ou3CFlEtwmG2lYRtCnoV9aLfd9waBogZL6MJnJnNyEm2d 5vHHKo6bJ02qos/kNhHrHfMExYNF/Vzy//Cgjyn5XC4zKiCMCa5s/L4qbu4fkBtaprkSK+scGGx4 TPsTYVg029npbPNX4PeRY3pPpRN1hfbHQWC1v2bKoLSyF5yfPLhInlAbRXcEepUTYyIk7izyXZGF 5YKm7qMeXVxfwGUmNa1TxRbQMMNiLz6bq7RJ0C7xCaQCf8IKvU8/krebR8dEPsmUIPitC1+sl6fI kroRqRWWXFKnU5KsvSQZ5ijJ2XcH01H/7tBx97qGWGxol7bS07NytLmq8rff5S+063kQKpammCS2 xaSgXmXKQDaHF7i9sv2NmdykNVugLhtuASoU+xv2/5Ox71mX2hNgu9tlE5ZYiw7o5y3LErFz62yF ioIs6hP+NUdrjcudh/ehDz34QfOR5VT1YENu0uI+Qbvxl/kKxmTYnOCpGIKgYoiDfg/F3MQfaxjs zkjbJ/jeuiTheEaKyqiw0pvWfLAGhde0w1J2S23xf+3jDeMsXWkb7BMV1kPksQv9nR6ZRBJnUm7a azp0KDWdbFksKwR3KCPMipRgc4LfhZlROTe5wsL2GUUpS3IqAlRVeMNNVhZ4ZAtsHxc1hGzJYqZj 6hIaYIn3othmJWy2i3yRa0I4dYt/+LeJ4OetbUErsKoMwtpXev0GtnNCM2VuZHN0cmVhbQplbmRv YmoKMTYzIDAgb2JqCjEwNDMKZW5kb2JqCjE2NyAwIG9iago8PC9MZW5ndGggMTY4IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicjVbRkto4EHznK6Z4yW6VlwNzud3cm2O8Fy6wEOyC 1CX7IMyAddiSI4nN8vc3kiHHgqEwRWGM3d3TPSPxA9qtDrTta/eZFo3fJvew0o02/EXvVeNHo+Nu gN1HWsDHhG56gI4PybJRPdcBvwv39w+QFI2bvjCoBJq7nmJLA0dHf9SLHu/w1dzplB//6I5HnIPf 7vi3yb+N7gdIBo0buvrt63Cg0wwLNmbK+M+37xqd7v7Hg+MjV1J4MG4BEwsIWjBkeSaNYh40CQJi hwEWBPw/occMM9sSNeEdIcWYSoKIFtxwKZoezLohTOhiUaBYMHvRg1Fq5BwVCW7/3iIM/49DwU+s QH1eqmJbD5KWB59knpNcVB706OuAbQtG4AGdJ3LO6XRCp7agT61ToUkmC23FNJuOsGQpauACbL3f b5KMq19lfL9teqcIdZX1MMViV9qHo9LCYByFzxU3wrCfTCIIpSql2j3cDAlLCgiMYema3Da2JyAS mwKre86ZYosMc6Y1X/LU3UklOD6SfiwjjJ73FlyUEUqx5KtNdfkaFUQZRnWEcVwxxilTSynQg89V p1HDDTHPidNqqeM9xxWnUnGxgnirDRaOOo5tTvDUjxNw48RWKNItZUS1Gbh/3/ZrUjxIrNM+Vh5d aVX0gsJA9FoqpAwq96O9FRXUeA/15J5lOWnUhpuNQZBLiA35wdRCO18STDMhc7na/uI4Z8Q4Z2Yp VXEYELnw90agLalzXNL0ypKmm1wQ3Jzn3GydKCpP6o1yU38u/2ld/tPJY8XZD4O4f46iislm+qho IH9KtXaIk8c3Pk73zTRGinjXPp+ZQnHQXlZuzHTGYCJpUZB6va167Jz0WkWnPTa1PebQ+6Zm8QvK Mqf52z1uJK3KtDxR1EHViRWQPjFodmUmM2RrQR125TDO6sKY7f27luutC5fo3AAe8Y3C/qDi67EX voAZyym2git0Nr4Nzl0aMsUZhEzzEi+HNirp2TDDdJ1zbXYznxr+grQZiNWG5p90WQUU2hSVm0y/ 1a5bzINS8bxuYEbTYHDZMCfjdFwCrck+2hvMOf2HIonl1LyvYdirRqfWvDBjKkebUFbwhakx9NJ+ 8YTUmP9wmy0VEZeY/r950IIChsqNXg0Kzee5RXrvO6SErVlGs8U9QOLMW3tQWh9ImYZgs9pQHJ0H z/0jecsM38a24m7XbvBR0vhCr/8A3qiIU2VuZHN0cmVhbQplbmRvYmoKMTY4IDAgb2JqCjkxMgpl bmRvYmoKMTcyIDAgb2JqCjw8L0xlbmd0aCAxNzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJx1lV1z2joQhu/9K3Zy0zDHuNjmw8nVIRhyCIFScE47UzIdRQhbwZaoLKfl33dlm7Qk YA8jj1lpn333wz+g5bjQMne90sz6uOhBnFstuMVfbP2w3NIA6oVmcBOhUQCuB9HGqva54PnQ6wUQ ZdblWGimBNPNUJGNhjfX+FM4HDXZL93MKX/7Z3mN2BN4LddrRM+WfwXRvXV5bDCQYsPjQhHNpYBB wug25bmGkOVU8V35diRVRjSsLr8OBuFo1YAXpnL8o/HBcv0TZ7qOh8bhoj+KVo0LG+6KdG8oXAd3 eN1yh9tyPAcjEJvycP7CYME2TDFBWY5m5shvi9HA9/2rR4BJuhfMhlvHhuHaASLWMHBgxn5mRNhw ERLNypcRzxggsk7YObqDpNelca5JtssREn2BcfaK2/L+wj3QdDoe0ixQHKlSgjAVy40DE6lQFmS5 LfiapVywHDA2+KK45iI2558jijCDBnrJaIHWe5OUHA+pkmLgbgZz6Hk1JDLYtUJ/XQdq/wR1NwiQ espIilyxDVOU8SJKGIyH0Qi+Tu8xohizrva1r8CtfeFO+xz2HREFUaXT9nunHd+rpRKcbm2YV6lD x4cEIFCek5jV9VXnwOw76/IT1fKJKeMyeO+y67pddHmjyFqYVCzRG0qp5N6Ge3w2mZo4MCqe+U+i SK3B0HG7bdDynM8HwU2NmkhkoSiKtmZC8w3HJsAyf1iMsSPCvSAZp9g2KYvLtL3PUMixarBG9rDc 55plpkfCcIm7+7tdymnVgqvL4exhWvaNkcPEdCLbU6Jo8ranjAzLQX/+WJp8ISnqnHGFfRNi9J8L LkQlypIStZGmoSa1LH3nXPj/kfSJqDUva9voFTGaYEpJCssdo6hDDW6KHdvutYrfQ2MuNEoH/ULL rNo0V1JLKlMM25CvGtdgVvi/mjBmlFycCH82XkaVe8SYF0+v6gWtVtNFORbshZcHnGqVJduh/FUd VQLWoxHBEqnyD9BfrxUWZzmJ/ogbkS3LE25WkhB8OtJsVhIgz1jkmusCJ5Lc/BlwyFJOLZllhahx 80pMmcr4IFe76TVdmBXbgjcnHIcToehxImMiGK9t3KDdDHpXHYjkdi/rl3dkR8QR7jzBFF/DP0EL 2vhJ8XrQCbreEfMwIzy9Bl0F9l0fAvsXCbUTS+d5Z+w71ZmvcduA3UtS5yDo8NcOyyzHxMYFfjvc wC4/Oseqw7e5aXa//YhHDiPrM96/AUCU4qRlbmRzdHJlYW0KZW5kb2JqCjE3MyAwIG9iago5MzIK ZW5kb2JqCjE3NyAwIG9iago8PC9MZW5ndGggMTc4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnicdZJtb5swEIC/8ytOmrS1GhADIZB+ShrSNWuTZYWom6Zpcs2FuAE7AVM1/36Gkk2J NluWrbvz3XMveyC2A6TZ3c0Ko/cQQFYZBD7pkxl7w2kNoLtYAdeJNgrBcSFZG2//HHA9CIIQksK4 mAmFpUBlRSVdKzhbsy/R9MbCV2VVjJ8r23WDT+ASx71Mng1vCMm9caGldygU3FORrjnm6eUHw/GO qjkbrxFNmAmm5Y3EJ4TALdJ0X9NS01QQlfwFO+0yp0KakHyDwCduv5Ou4rF+uYOj12lBeX7Vxv31 J+7oLZbNZKGN/9IlG1nQCuY8z2l5AreKIcKdpiiaBOQabmWBGiCFGFldcnUwYbFcRr1J/H7SW0zi qLeKrcn0Iem43L4P87os6aFJHyF+NOG65nnKRQZ9h5gwj+Fd4Lmd/SOtNlqlpDAhmuhK+sPwPyku N1LgFXx0IAxDcEMXSBiQE/yuCqrNzy7a/EZ1ZTEslZ3Jl5MqfJf1lsMdTeUTPTQYJ64WtKS6R5Xi qlbYlCJmHAVDaKqRINsImcvs0MGGQ2dg+ZDQrfZVUN3erWbolAOPWMQZuq3TTvaZ7qj4VwsPDZa1 HfHKprxSltB/bMrs511D74WteRNn0zCbgApobh/Hcfq64yVWMK6zulLghGY7nWdD+2NJMwTP/6ld ThPjq96/AWS93mhlbmRzdHJlYW0KZW5kb2JqCjE3OCAwIG9iago1MTcKZW5kb2JqCjQgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDkgMCBSCi9Gb250 IDEwIDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjExIDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNCAwIFIKL0ZvbnQgMTUgMCBSCj4+ Ci9Db250ZW50cyAxMiAwIFIKPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxOSAwIFIKL0ZvbnQgMjAgMCBSCj4+Ci9Db250ZW50 cyAxNyAwIFIKPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0V4dEdTdGF0ZSAyNCAwIFIKL0ZvbnQgMjUgMCBSCj4+Ci9Db250ZW50cyAyMiAwIFIK Pj4KZW5kb2JqCjI2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4 dEdTdGF0ZSAyOSAwIFIKL0ZvbnQgMzAgMCBSCj4+Ci9Db250ZW50cyAyNyAwIFIKPj4KZW5kb2Jq CjMxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAz NCAwIFIKL0ZvbnQgMzUgMCBSCj4+Ci9Db250ZW50cyAzMiAwIFIKPj4KZW5kb2JqCjM2IDAgb2Jq Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzOSAwIFIKL0Zv bnQgNDAgMCBSCj4+Ci9Db250ZW50cyAzNyAwIFIKPj4KZW5kb2JqCjQxIDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0NCAwIFIKL0ZvbnQgNDUgMCBS Cj4+Ci9Db250ZW50cyA0MiAwIFIKPj4KZW5kb2JqCjQ2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0OSAwIFIKL0ZvbnQgNTAgMCBSCj4+Ci9Db250 ZW50cyA0NyAwIFIKPj4KZW5kb2JqCjUxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0V4dEdTdGF0ZSA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250ZW50cyA1MiAw IFIKPj4KZW5kb2JqCjU2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSA1OSAwIFIKL0ZvbnQgNjAgMCBSCj4+Ci9Db250ZW50cyA1NyAwIFIKPj4KZW5k b2JqCjYxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSA2NCAwIFIKL0ZvbnQgNjUgMCBSCj4+Ci9Db250ZW50cyA2MiAwIFIKPj4KZW5kb2JqCjY2IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA2OSAwIFIK L0ZvbnQgNzAgMCBSCj4+Ci9Db250ZW50cyA2NyAwIFIKPj4KZW5kb2JqCjcxIDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA3NCAwIFIKL0ZvbnQgNzUg MCBSCj4+Ci9Db250ZW50cyA3MiAwIFIKPj4KZW5kb2JqCjc2IDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA3OSAwIFIKL0ZvbnQgODAgMCBSCj4+Ci9D b250ZW50cyA3NyAwIFIKPj4KZW5kb2JqCjgxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA4NCAwIFIKL0ZvbnQgODUgMCBSCj4+Ci9Db250ZW50cyA4 MiAwIFIKPj4KZW5kb2JqCjg2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSA4OSAwIFIKL0ZvbnQgOTAgMCBSCj4+Ci9Db250ZW50cyA4NyAwIFIKPj4K ZW5kb2JqCjkxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3Rh dGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdT dGF0ZSA5NCAwIFIKL0ZvbnQgOTUgMCBSCj4+Ci9Db250ZW50cyA5MiAwIFIKPj4KZW5kb2JqCjk2 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA5OSAw IFIKL0ZvbnQgMTAwIDAgUgo+PgovQ29udGVudHMgOTcgMCBSCj4+CmVuZG9iagoxMDEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEwNCAwIFIKL0Zv bnQgMTA1IDAgUgo+PgovQ29udGVudHMgMTAyIDAgUgo+PgplbmRvYmoKMTA2IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMDkgMCBSCi9Gb250IDEx MCAwIFIKPj4KL0NvbnRlbnRzIDEwNyAwIFIKPj4KZW5kb2JqCjExMSAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE0IDAgUgovRm9udCAxMTUgMCBS Cj4+Ci9Db250ZW50cyAxMTIgMCBSCj4+CmVuZG9iagoxMTYgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDExOSAwIFIKL0ZvbnQgMTIwIDAgUgo+Pgov Q29udGVudHMgMTE3IDAgUgo+PgplbmRvYmoKMTIxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMjQgMCBSCi9Gb250IDEyNSAwIFIKPj4KL0NvbnRl bnRzIDEyMiAwIFIKPj4KZW5kb2JqCjEyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAg MCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTI5IDAgUgovRm9udCAxMzAgMCBSCj4+Ci9Db250ZW50cyAx MjcgMCBSCj4+CmVuZG9iagoxMzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDEzNCAwIFIKL0ZvbnQgMTM1IDAgUgo+PgovQ29udGVudHMgMTMyIDAg Ugo+PgplbmRvYmoKMTM2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAxMzkgMCBSCi9Gb250IDE0MCAwIFIKPj4KL0NvbnRlbnRzIDEzNyAwIFIKPj4K ZW5kb2JqCjE0MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgMTQ0IDAgUgovRm9udCAxNDUgMCBSCj4+Ci9Db250ZW50cyAxNDIgMCBSCj4+CmVuZG9i agoxNDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDE0OSAwIFIKL0ZvbnQgMTUwIDAgUgo+PgovQ29udGVudHMgMTQ3IDAgUgo+PgplbmRvYmoKMTUx IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNTQg MCBSCi9Gb250IDE1NSAwIFIKPj4KL0NvbnRlbnRzIDE1MiAwIFIKPj4KZW5kb2JqCjE1NiAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTU5IDAgUgov Rm9udCAxNjAgMCBSCj4+Ci9Db250ZW50cyAxNTcgMCBSCj4+CmVuZG9iagoxNjEgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE2NCAwIFIKL0ZvbnQg MTY1IDAgUgo+PgovQ29udGVudHMgMTYyIDAgUgo+PgplbmRvYmoKMTY2IDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxNjkgMCBSCi9Gb250IDE3MCAw IFIKPj4KL0NvbnRlbnRzIDE2NyAwIFIKPj4KZW5kb2JqCjE3MSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTc0IDAgUgovRm9udCAxNzUgMCBSCj4+ Ci9Db250ZW50cyAxNzIgMCBSCj4+CmVuZG9iagoxNzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE3OSAwIFIKL0ZvbnQgMTgwIDAgUgo+PgovQ29u dGVudHMgMTc3IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0 IDAgUgoxMSAwIFIKMTYgMCBSCjIxIDAgUgoyNiAwIFIKMzEgMCBSCjM2IDAgUgo0MSAwIFIKNDYg MCBSCjUxIDAgUgo1NiAwIFIKNjEgMCBSCjY2IDAgUgo3MSAwIFIKNzYgMCBSCjgxIDAgUgo4NiAw IFIKOTEgMCBSCjk2IDAgUgoxMDEgMCBSCjEwNiAwIFIKMTExIDAgUgoxMTYgMCBSCjEyMSAwIFIK MTI2IDAgUgoxMzEgMCBSCjEzNiAwIFIKMTQxIDAgUgoxNDYgMCBSCjE1MSAwIFIKMTU2IDAgUgox NjEgMCBSCjE2NiAwIFIKMTcxIDAgUgoxNzYgMCBSCl0gL0NvdW50IDM1Cj4+CmVuZG9iagoxIDAg b2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCi9NZXRhZGF0YSAxODEgMCBSCj4+CmVu ZG9iago3IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlCi9PUE0gMT4+ZW5kb2JqCjkgMCBvYmoKPDwv UjcKNyAwIFI+PgplbmRvYmoKMTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTQgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKMTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTkgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMjQg MCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoK MjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMzAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRv YmoKMzQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMzUgMCBvYmoKPDwvUjgKOCAwIFI+Pgpl bmRvYmoKMzkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDAgMCBvYmoKPDwvUjgKOCAwIFI+ PgplbmRvYmoKNDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDUgMCBvYmoKPDwvUjgKOCAw IFI+PgplbmRvYmoKNDkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNTAgMCBvYmoKPDwvUjgK OCAwIFI+PgplbmRvYmoKNTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNTUgMCBvYmoKPDwv UjgKOCAwIFI+PgplbmRvYmoKNTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNjAgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKNjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNjUgMCBv YmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNzAg MCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNzQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK NzUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNzkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKODAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKODQgMCBvYmoKPDwvUjcKNyAwIFI+Pgpl bmRvYmoKODUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKODkgMCBvYmoKPDwvUjcKNyAwIFI+ PgplbmRvYmoKOTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKOTQgMCBvYmoKPDwvUjcKNyAw IFI+PgplbmRvYmoKOTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKOTkgMCBvYmoKPDwvUjcK NyAwIFI+PgplbmRvYmoKMTAwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjEwNCAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iagoxMDUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTA5IDAg b2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjExMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagox MTQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTE1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k b2JqCjExOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMjAgMCBvYmoKPDwvUjgKOCAwIFI+ PgplbmRvYmoKMTI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEyNSAwIG9iago8PC9SOAo4 IDAgUj4+CmVuZG9iagoxMjkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTMwIDAgb2JqCjw8 L1I4CjggMCBSPj4KZW5kb2JqCjEzNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMzUgMCBv YmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTM5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE0 MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKMTQ1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE0OSAwIG9iago8PC9SNwo3IDAgUj4+ CmVuZG9iagoxNTAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTU0IDAgb2JqCjw8L1I3Cjcg MCBSPj4KZW5kb2JqCjE1NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNTkgMCBvYmoKPDwv UjcKNyAwIFI+PgplbmRvYmoKMTYwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjE2NCAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNjUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTY5 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE3MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i agoxNzQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTc1IDAgb2JqCjw8L1I4CjggMCBSPj4K ZW5kb2JqCjE3OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxODAgMCBvYmoKPDwvUjgKOCAw IFI+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9Db3VyaWVyL1R5cGUvRm9udAovU3VidHlw ZS9UeXBlMT4+CmVuZG9iagoxODEgMCBvYmoKPDwvVHlwZS9NZXRhZGF0YQovU3VidHlwZS9YTUwv TGVuZ3RoIDEzNTQ+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlI enJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBt ZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0x MywgZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20v aVgvMS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSc2MTMyYjYyOS04ZmQxLTExZWMt MDAwMC1kNmE0ZjRmNTQ1YicgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMv JyBwZGY6UHJvZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA5LjA0Jy8+CjxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSc2MTMyYjYyOS04ZmQxLTExZWMtMDAwMC1kNmE0ZjRmNTQ1YicgeG1sbnM6eG1w PSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz48eG1wOk1vZGlmeURhdGU+MjAxMi0wMi0x NVQxMDowOTo1NyswMTowMDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6Q3JlYXRlRGF0ZT4yMDEyLTAy LTE1VDEwOjA5OjU3KzAxOjAwPC94bXA6Q3JlYXRlRGF0ZT4KPHhtcDpDcmVhdG9yVG9vbD5HTlUg RW5zY3JpcHQgMS42LjUuOTA8L3htcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNjcmlwdGlvbj4KPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzYxMzJiNjI5LThmZDEtMTFlYy0wMDAwLWQ2YTRmNGY1 NDViJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLycgeGFwTU06 RG9jdW1lbnRJRD0ndXVpZDo2MTMyYjYyOS04ZmQxLTExZWMtMDAwMC1kNmE0ZjRmNTQ1YjIwMTIt MDItMTVUMTA6MDk6NTcrMDE6MDAnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzYxMzJi NjI5LThmZDEtMTFlYy0wMDAwLWQ2YTRmNGY1NDViJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+ PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5FbnNjcmlwdCBPdXRwdXQ8L3Jk ZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8 L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5k PSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3Jp cHQgOS4wNCkKL0NyZWF0aW9uRGF0ZShEOjIwMTIwMjE1MTAwOTU3KzAxJzAwJykKL01vZERhdGUo RDoyMDEyMDIxNTEwMDk1NyswMScwMCcpCi9UaXRsZShFbnNjcmlwdCBPdXRwdXQpCi9DcmVhdG9y KEdOVSBFbnNjcmlwdCAxLjYuNS45MCk+PmVuZG9iagp4cmVmCjAgMTgyCjAwMDAwMDAwMDAgNjU1 MzUgZiAKMDAwMDA0MDY5NCAwMDAwMCBuIAowMDAwMDQ0NDI3IDAwMDAwIG4gCjAwMDAwNDAzODAg MDAwMDAgbiAKMDAwMDAzNDY0OCAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDEx NTUgMDAwMDAgbiAKMDAwMDA0MDc2MCAwMDAwMCBuIAowMDAwMDQyOTMzIDAwMDAwIG4gCjAwMDAw NDA4MDEgMDAwMDAgbiAKMDAwMDA0MDgzMCAwMDAwMCBuIAowMDAwMDM0ODA3IDAwMDAwIG4gCjAw MDAwMDExNzUgMDAwMDAgbiAKMDAwMDAwMTY4MiAwMDAwMCBuIAowMDAwMDQwODYwIDAwMDAwIG4g CjAwMDAwNDA4OTAgMDAwMDAgbiAKMDAwMDAzNDk2OSAwMDAwMCBuIAowMDAwMDAxNzAyIDAwMDAw IG4gCjAwMDAwMDI2MjggMDAwMDAgbiAKMDAwMDA0MDkyMCAwMDAwMCBuIAowMDAwMDQwOTUwIDAw MDAwIG4gCjAwMDAwMzUxMzEgMDAwMDAgbiAKMDAwMDAwMjY0OCAwMDAwMCBuIAowMDAwMDAzODg5 IDAwMDAwIG4gCjAwMDAwNDA5ODAgMDAwMDAgbiAKMDAwMDA0MTAxMCAwMDAwMCBuIAowMDAwMDM1 MjkzIDAwMDAwIG4gCjAwMDAwMDM5MTAgMDAwMDAgbiAKMDAwMDAwNTI3NiAwMDAwMCBuIAowMDAw MDQxMDQwIDAwMDAwIG4gCjAwMDAwNDEwNzAgMDAwMDAgbiAKMDAwMDAzNTQ1NSAwMDAwMCBuIAow MDAwMDA1Mjk3IDAwMDAwIG4gCjAwMDAwMDYxOTQgMDAwMDAgbiAKMDAwMDA0MTEwMCAwMDAwMCBu IAowMDAwMDQxMTMwIDAwMDAwIG4gCjAwMDAwMzU2MTcgMDAwMDAgbiAKMDAwMDAwNjIxNCAwMDAw MCBuIAowMDAwMDA2ODU3IDAwMDAwIG4gCjAwMDAwNDExNjAgMDAwMDAgbiAKMDAwMDA0MTE5MCAw MDAwMCBuIAowMDAwMDM1Nzc5IDAwMDAwIG4gCjAwMDAwMDY4NzcgMDAwMDAgbiAKMDAwMDAwNzU3 NyAwMDAwMCBuIAowMDAwMDQxMjIwIDAwMDAwIG4gCjAwMDAwNDEyNTAgMDAwMDAgbiAKMDAwMDAz NTk0MSAwMDAwMCBuIAowMDAwMDA3NTk3IDAwMDAwIG4gCjAwMDAwMDgzMzEgMDAwMDAgbiAKMDAw MDA0MTI4MCAwMDAwMCBuIAowMDAwMDQxMzEwIDAwMDAwIG4gCjAwMDAwMzYxMDMgMDAwMDAgbiAK MDAwMDAwODM1MSAwMDAwMCBuIAowMDAwMDA5MTcwIDAwMDAwIG4gCjAwMDAwNDEzNDAgMDAwMDAg biAKMDAwMDA0MTM3MCAwMDAwMCBuIAowMDAwMDM2MjY1IDAwMDAwIG4gCjAwMDAwMDkxOTAgMDAw MDAgbiAKMDAwMDAxMDI5OSAwMDAwMCBuIAowMDAwMDQxNDAwIDAwMDAwIG4gCjAwMDAwNDE0MzAg MDAwMDAgbiAKMDAwMDAzNjQyNyAwMDAwMCBuIAowMDAwMDEwMzIwIDAwMDAwIG4gCjAwMDAwMTE0 NzUgMDAwMDAgbiAKMDAwMDA0MTQ2MCAwMDAwMCBuIAowMDAwMDQxNDkwIDAwMDAwIG4gCjAwMDAw MzY1ODkgMDAwMDAgbiAKMDAwMDAxMTQ5NiAwMDAwMCBuIAowMDAwMDEyNTg4IDAwMDAwIG4gCjAw MDAwNDE1MjAgMDAwMDAgbiAKMDAwMDA0MTU1MCAwMDAwMCBuIAowMDAwMDM2NzUxIDAwMDAwIG4g CjAwMDAwMTI2MDkgMDAwMDAgbiAKMDAwMDAxMzcxNyAwMDAwMCBuIAowMDAwMDQxNTgwIDAwMDAw IG4gCjAwMDAwNDE2MTAgMDAwMDAgbiAKMDAwMDAzNjkxMyAwMDAwMCBuIAowMDAwMDEzNzM4IDAw MDAwIG4gCjAwMDAwMTQ4NTcgMDAwMDAgbiAKMDAwMDA0MTY0MCAwMDAwMCBuIAowMDAwMDQxNjcw IDAwMDAwIG4gCjAwMDAwMzcwNzUgMDAwMDAgbiAKMDAwMDAxNDg3OCAwMDAwMCBuIAowMDAwMDE1 OTcwIDAwMDAwIG4gCjAwMDAwNDE3MDAgMDAwMDAgbiAKMDAwMDA0MTczMCAwMDAwMCBuIAowMDAw MDM3MjM3IDAwMDAwIG4gCjAwMDAwMTU5OTEgMDAwMDAgbiAKMDAwMDAxNzExNCAwMDAwMCBuIAow MDAwMDQxNzYwIDAwMDAwIG4gCjAwMDAwNDE3OTAgMDAwMDAgbiAKMDAwMDAzNzM5OSAwMDAwMCBu IAowMDAwMDE3MTM1IDAwMDAwIG4gCjAwMDAwMTgyMDIgMDAwMDAgbiAKMDAwMDA0MTgyMCAwMDAw MCBuIAowMDAwMDQxODUwIDAwMDAwIG4gCjAwMDAwMzc1NjEgMDAwMDAgbiAKMDAwMDAxODIyMiAw MDAwMCBuIAowMDAwMDE5MzIzIDAwMDAwIG4gCjAwMDAwNDE4ODAgMDAwMDAgbiAKMDAwMDA0MTkx MCAwMDAwMCBuIAowMDAwMDM3NzI0IDAwMDAwIG4gCjAwMDAwMTkzNDQgMDAwMDAgbiAKMDAwMDAy MDQ5OSAwMDAwMCBuIAowMDAwMDQxOTQxIDAwMDAwIG4gCjAwMDAwNDE5NzIgMDAwMDAgbiAKMDAw MDAzNzg5MCAwMDAwMCBuIAowMDAwMDIwNTIxIDAwMDAwIG4gCjAwMDAwMjE2ODUgMDAwMDAgbiAK MDAwMDA0MjAwMyAwMDAwMCBuIAowMDAwMDQyMDM0IDAwMDAwIG4gCjAwMDAwMzgwNTYgMDAwMDAg biAKMDAwMDAyMTcwNyAwMDAwMCBuIAowMDAwMDIyOTE3IDAwMDAwIG4gCjAwMDAwNDIwNjUgMDAw MDAgbiAKMDAwMDA0MjA5NiAwMDAwMCBuIAowMDAwMDM4MjIyIDAwMDAwIG4gCjAwMDAwMjI5Mzkg MDAwMDAgbiAKMDAwMDAyNDAxNiAwMDAwMCBuIAowMDAwMDQyMTI3IDAwMDAwIG4gCjAwMDAwNDIx NTggMDAwMDAgbiAKMDAwMDAzODM4OCAwMDAwMCBuIAowMDAwMDI0MDM4IDAwMDAwIG4gCjAwMDAw MjUxODYgMDAwMDAgbiAKMDAwMDA0MjE4OSAwMDAwMCBuIAowMDAwMDQyMjIwIDAwMDAwIG4gCjAw MDAwMzg1NTQgMDAwMDAgbiAKMDAwMDAyNTIwOCAwMDAwMCBuIAowMDAwMDI1ODc5IDAwMDAwIG4g CjAwMDAwNDIyNTEgMDAwMDAgbiAKMDAwMDA0MjI4MiAwMDAwMCBuIAowMDAwMDM4NzIwIDAwMDAw IG4gCjAwMDAwMjU5MDAgMDAwMDAgbiAKMDAwMDAyNjQ2MyAwMDAwMCBuIAowMDAwMDQyMzEzIDAw MDAwIG4gCjAwMDAwNDIzNDQgMDAwMDAgbiAKMDAwMDAzODg4NiAwMDAwMCBuIAowMDAwMDI2NDg0 IDAwMDAwIG4gCjAwMDAwMjcwNTIgMDAwMDAgbiAKMDAwMDA0MjM3NSAwMDAwMCBuIAowMDAwMDQy NDA2IDAwMDAwIG4gCjAwMDAwMzkwNTIgMDAwMDAgbiAKMDAwMDAyNzA3MyAwMDAwMCBuIAowMDAw MDI3OTQwIDAwMDAwIG4gCjAwMDAwNDI0MzcgMDAwMDAgbiAKMDAwMDA0MjQ2OCAwMDAwMCBuIAow MDAwMDM5MjE4IDAwMDAwIG4gCjAwMDAwMjc5NjEgMDAwMDAgbiAKMDAwMDAyODk4MSAwMDAwMCBu IAowMDAwMDQyNDk5IDAwMDAwIG4gCjAwMDAwNDI1MzAgMDAwMDAgbiAKMDAwMDAzOTM4NCAwMDAw MCBuIAowMDAwMDI5MDAyIDAwMDAwIG4gCjAwMDAwMjk5NDggMDAwMDAgbiAKMDAwMDA0MjU2MSAw MDAwMCBuIAowMDAwMDQyNTkyIDAwMDAwIG4gCjAwMDAwMzk1NTAgMDAwMDAgbiAKMDAwMDAyOTk2 OSAwMDAwMCBuIAowMDAwMDMwODQyIDAwMDAwIG4gCjAwMDAwNDI2MjMgMDAwMDAgbiAKMDAwMDA0 MjY1NCAwMDAwMCBuIAowMDAwMDM5NzE2IDAwMDAwIG4gCjAwMDAwMzA4NjMgMDAwMDAgbiAKMDAw MDAzMTk4MCAwMDAwMCBuIAowMDAwMDQyNjg1IDAwMDAwIG4gCjAwMDAwNDI3MTYgMDAwMDAgbiAK MDAwMDAzOTg4MiAwMDAwMCBuIAowMDAwMDMyMDAyIDAwMDAwIG4gCjAwMDAwMzI5ODggMDAwMDAg biAKMDAwMDA0Mjc0NyAwMDAwMCBuIAowMDAwMDQyNzc4IDAwMDAwIG4gCjAwMDAwNDAwNDggMDAw MDAgbiAKMDAwMDAzMzAwOSAwMDAwMCBuIAowMDAwMDM0MDE1IDAwMDAwIG4gCjAwMDAwNDI4MDkg MDAwMDAgbiAKMDAwMDA0Mjg0MCAwMDAwMCBuIAowMDAwMDQwMjE0IDAwMDAwIG4gCjAwMDAwMzQw MzYgMDAwMDAgbiAKMDAwMDAzNDYyNyAwMDAwMCBuIAowMDAwMDQyODcxIDAwMDAwIG4gCjAwMDAw NDI5MDIgMDAwMDAgbiAKMDAwMDA0Mjk5NSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE4MiAv Um9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzxFRTdCNjdFMzA5Qjk5MjY0RTkyQzM4MjM3QjEw MEU0OD48RUU3QjY3RTMwOUI5OTI2NEU5MkMzODIzN0IxMDBFNDg+XQo+PgpzdGFydHhyZWYKNDQ2 MDYKJSVFT0YK ------=_NextPart_000_0042_01CCEC0D.D17CAA80-- From trammell@tik.ee.ethz.ch Wed Feb 15 02:27:40 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF9321F8596 for ; Wed, 15 Feb 2012 02:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4b-5l9C51NOS for ; Wed, 15 Feb 2012 02:27:39 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 73F5721F8597 for ; Wed, 15 Feb 2012 02:27:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4447ED930C; Wed, 15 Feb 2012 11:27:37 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mvWsysZ9givV; Wed, 15 Feb 2012 11:27:37 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1011DD930A; Wed, 15 Feb 2012 11:27:37 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <004101ccebc2$61941820$24bc4860$@nict.go.jp> Date: Wed, 15 Feb 2012 11:27:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1251.1) Cc: mile@ietf.org Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 10:27:41 -0000 Hi, Take, all, Thank you for this edit/clarification. On the first point, it does seem the discussion on the list converged = rather quickly to CVE as MTI. However, as this is a rather important = point, I'd like to make sure we didn't miss anything. So, I'd like to call for consensus on the list. Does the working group = agree on the following two points? 1. mile-sci requires one Mandatory to Implement schema in order to = ensure interoperability. 2. The Mandatory to Implement schema is the Common Vulnerability = Enumeration (CVE) version 1.0, as described in section 4.1.7 of = mile-sci-02. Please note if you agree; if you disagree, please explain why not. Best regards, Brian (as chair) On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > Hello all, >=20 > Following the discussion, I would like to add a couple of sentences to > clarify the MTI issues. > (Thank you very much for those of you who kindly provided useful > discussion.) > I've attached the working version of the draft. I hope it helps to = clarify > the changes. >=20 > (added sentences at the end of section 4.1) >=20 > The SpecID attributes of extended classes (Section 4.3) must allow > the values of the specifications' namespace fields, but otherwise, > implementations are not required to support all the above > specifications. Implementations may choose which specifications to > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > supported. In case an implementation received a data it does not > support, it may expand its functionality by looking up the IANA = table or > notify the sender of its inability to parse the data by using any > means defined outside the scope of this specification. >=20 > On the other hand, I would like to add "STRING ext-SpecID" to each = class, > which enables to embed data following private schema. > For instance, one security operation center (SOC) may wish to exchange = a > vulnerability data that is formatted in its own private schema, and = that is > not formatted in CVE. > In this case, the SOC may put the data's schema ID inside ext-SpecID = and > then embed the data. > It could also be used to exchange data using beta version of = specifications. >=20 > The class could be seen as below. >=20 > +------------------------+ > | AttackPattern | > +------------------------+ > | ENUM SpecID |<>--(0..*)-[ RawData ] > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > +------------------------+ >=20 > SpecID: REQUIRED. ENUM. The identifier of the specification > specifying the format of the RawData element. The value should = be > chosen from the namespaces [XMLNames] listed in Section 4.1 or > "private". Note that the lists in Section 4.1 will be developed > further by IANA. The value "private" is prepared for conveying > RawData based on a format that is not listed in the > table. This is usually used for conveying data formatted > according to an organization's private schema. When the value > "private" is used, ext-SpecID element needs to be used. >=20 > ext-SpecID: OPTIONAL. STRING. The identifier of the specification > specifying the format of the RawData element. When this element > is used, the value of SpecID element must be "private." >=20 > I hope above changes don't cause any complication here. >=20 > Sincerely, > Take >=20 >=20 >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >> Martin, Robert A. >> Sent: Wednesday, February 15, 2012 1:50 AM >> To: Kent_Landfield@McAfee.com >> Cc: mile@ietf.org >> Subject: Re: [mile] MTI SCI? >>=20 >> At the risk of contradicting myself - but then again I have now read = the >> other replies to this issue - I agree that having one area be the = smoke >> test makes sense and I also agree that something simple and commonly = used >> already - like CVE - is the best candidate for what we need. >>=20 >> Bob >>=20 >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>> CVE is widely used and understood by all in the the security = community. >> I agree with Tom that CVE is the path of least resistance but may be = the >> most useful for basic interoperability. >>>=20 >>> Kent Landfield >>> Director Content Strategy, Architecture and Standards >>>=20 >>> McAfee | An Intel Company >>> 5000 Headquarters Dr. >>> Plano, Texas 75024 >>>=20 >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> Web: www.mcafee.com >>>=20 >>> From: >>>=20 >> "Thomas.Millar@us-cert.gov"> .M >>> illar@us-cert.gov> >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>> To: >>>=20 >> "david.black@emc.com"> m< >>> mailto:david.black@emc.com>>, Bob >>> Martin> >>> Cc: >>>=20 >> "mile@ietf.org"> .o >>> rg>> >>> Subject: Re: [mile] MTI SCI? >>>=20 >>> My concern with CAPEC being mandatory is that it could discourage >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary = remains >> "too comprehensive" for many CSIRTs to employ during incident = handling >> and reporting activity. >>>=20 >>> IODEF by itself has been criticized by CSIRT operators for being = more >> heavyweight than necessary for day-to-day usage; making CAPEC a = mandatory >> aspect of "advanced IODEF" seems like it would be adding ammunition = to >> that argument, especially if the CSIRT is having to fund = implementation >> out of their own pocket. Personally, I would have a hard time asking >> US-CERT's primary constituents to implement IODEF + CAPEC if they are >> already balking at the consultant and developer resources required to >> implement RFC 5070 by itself. Also keep in mind that CAPEC references >> CybOX, so there's wheels within wheels now. >>>=20 >>> I would prefer we take the path of least resistance (from my > perspective) >> and make CVE the MTI, if we have to pick one additional spec. >>> CVE is well known, has years of familiarity built in, and I think = it's >> the simplest schema of the bunch. >>>=20 >>>=20 >>> - Tom Millar, US-CERT >>>=20 >>> thomas.millar@us-cert.gov >>> BB: thomas.millar@dhs.gov / >>> 202-631-1915 >>> 24x7: soc@us-cert.gov / 888-282-0870 >>>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org >>> [mailto:mile-bounces@ietf.org] On Behalf Of >>> david.black@emc.com >>> Sent: Tuesday, February 14, 2012 11:14 >>> To: ramartin@mitre.org >>> Cc: mile@ietf.org >>> Subject: Re: [mile] MTI SCI? >>>=20 >>> Hi Bob, >>>=20 >>> I do appreciate the concern about implementing things that aren't = going >> to be used. OTOH, it may be useful to have a single simple MTI spec = for >> SCI that can be used to "smoke test" a deployment before trying any > serious >> test data (and "simple" is important). >>>=20 >>> In addition, a concern that I would have with an MTI SCI spec per = class >> is that if two SCI implementations don't have at least one class in > common, >> they aren't going to interoperate, and that situation is unlikely to = be >> acceptable to the IESG (i.e., with an MTI SCI spec per class, I = suspect >> that there will also have to be an MTI class, which results in an = overall >> MTI SCI spec). >>>=20 >>> It may also be useful to include a simple example of the MTI SCI = spec >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML >> document for testing purposes, including enumeration values suitable = for >> testing). >>>=20 >>> What do you (and others) think about this? >>>=20 >>> Thanks, >>> --David >>>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>> Sent: Tuesday, February 14, 2012 8:26 AM >>> To: Brian Trammell >>> Cc: mile@ietf.org >>> Subject: Re: [mile] MTI SCI? >>> Brian, >>> You beat me to this point. Like you, I would be concerned about a = MTI >>> selection that ended up requiring someone to implement something to >>> meet the MTI but wasn't germane to anything else they intended to >> support. >>> Bob >>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>> Hi, Sean, all, >>>>=20 >>>> Looking over the spec, it's not clear to me that one MTI makes = sense >>>> here, given that mile-sci's >>> purpose is to reference a set of external specifications by = inclusion >>> in an IODEF document, and that those external specifications = represent >> fundamentally different things. >>>>=20 >>>> The specifications are split over their applicability to the IODEF >>>> extension classes. I could >>> envision an mile-sci implementation that was only interested a = subset >>> of these classes (perhaps even only one). If my implementation has = an >>> internal representation of Verification, but not of any of the other >>> classes, and the MTI is an enumeration that is applicable to >> Vulnerability... what do I do? >>>>=20 >>>> What about selecting an MTI per class, instead? >>>>=20 >>>> Best regards, >>>>=20 >>>> Brian (as contributor) >>>>=20 >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>=20 >>>>> Great - as long as we pick one as the MTI. Note that MTI is not >> necessarily mandatory to use. >>>>>=20 >>>>> spt >>>>>=20 >>>>> On 2/13/12 7:11 PM, >> kathleen.moriarty@emc.com wrote: >>>>>> Thank you for raising the interoperability testing as we need to >>>>>> plan for a bake-off that once >>> these questions get answered and the draft is ready. >>>>>>=20 >>>>>> Thanks, >>>>>> Kathleen >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>> To: mile@ietf.org >>>>>> Subject: [mile] MTI SCI? >>>>>>=20 >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>> (mandatory to implement) choice? In other words, how will you = get >>>>>> two interoperability implementations without picking one? >>>>>>=20 >>>>>> spt >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> . >>>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > = _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From bitwatcher@gmail.com Wed Feb 15 04:32:56 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D0421F856F for ; Wed, 15 Feb 2012 04:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 mZETBm8G21Zh for ; Wed, 15 Feb 2012 04:32:52 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E89BA21F84EA for ; Wed, 15 Feb 2012 04:32:51 -0800 (PST) Received: by yhkk25 with SMTP id k25so629801yhk.31 for ; Wed, 15 Feb 2012 04:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=s5kQ1Yjr1PR7ALpRruypBAJ6SX8wWThyYdZkCSMoG5w=; b=KIN/1gYBMYztW1vN4+40OEZZQwgNVSI1lFWMEYHuaM/dx38s7apkkVdIq+3omziWLW zim/p1IVNdeRlDuMlZ04xhFI9TJ2G/IR9U3Cw1kyfzW++IBERPlVoqcHBAr8PInSlhK2 r3Cz4EEd601STHxGK0BHT3ZhS5vzprVF0KOV8= Received: by 10.236.189.5 with SMTP id b5mr32685388yhn.93.1329309171240; Wed, 15 Feb 2012 04:32:51 -0800 (PST) Received: from [192.168.1.74] (76-242-65-38.lightspeed.rcsntx.sbcglobal.net. [76.242.65.38]) by mx.google.com with ESMTPS id j28sm5879115yhe.14.2012.02.15.04.32.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 04:32:49 -0800 (PST) References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8L1) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8L1) From: Kent Landfield Date: Wed, 15 Feb 2012 06:32:43 -0600 To: Brian Trammell Cc: "mile@ietf.org" Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:32:56 -0000 I agree. Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026=20 On Feb 15, 2012, at 4:27 AM, Brian Trammell wrote:= > Hi, Take, all, >=20 > Thank you for this edit/clarification. >=20 > On the first point, it does seem the discussion on the list converged rath= er quickly to CVE as MTI. However, as this is a rather important point, I'd l= ike to make sure we didn't miss anything. >=20 > So, I'd like to call for consensus on the list. Does the working group agr= ee on the following two points? >=20 > 1. mile-sci requires one Mandatory to Implement schema in order to ensure i= nteroperability. >=20 > 2. The Mandatory to Implement schema is the Common Vulnerability Enumerati= on (CVE) version 1.0, as described in section 4.1.7 of mile-sci-02. >=20 > Please note if you agree; if you disagree, please explain why not. >=20 > Best regards, >=20 > Brian (as chair) >=20 > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >=20 >> Hello all, >>=20 >> Following the discussion, I would like to add a couple of sentences to >> clarify the MTI issues. >> (Thank you very much for those of you who kindly provided useful >> discussion.) >> I've attached the working version of the draft. I hope it helps to clarif= y >> the changes. >>=20 >> (added sentences at the end of section 4.1) >>=20 >> The SpecID attributes of extended classes (Section 4.3) must allow >> the values of the specifications' namespace fields, but otherwise, >> implementations are not required to support all the above >> specifications. Implementations may choose which specifications to >> support, though CVE 1.0 (Section 4.1.7) needs to be minimally >> supported. In case an implementation received a data it does not >> support, it may expand its functionality by looking up the IANA table or= >> notify the sender of its inability to parse the data by using any >> means defined outside the scope of this specification. >>=20 >> On the other hand, I would like to add "STRING ext-SpecID" to each class,= >> which enables to embed data following private schema. >> For instance, one security operation center (SOC) may wish to exchange a >> vulnerability data that is formatted in its own private schema, and that i= s >> not formatted in CVE. >> In this case, the SOC may put the data's schema ID inside ext-SpecID and >> then embed the data. >> It could also be used to exchange data using beta version of specificatio= ns. >>=20 >> The class could be seen as below. >>=20 >> +------------------------+ >> | AttackPattern | >> +------------------------+ >> | ENUM SpecID |<>--(0..*)-[ RawData ] >> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >> | STRING AttackPatternID |<>--(0..*)-[ Platform ] >> +------------------------+ >>=20 >> SpecID: REQUIRED. ENUM. The identifier of the specification >> specifying the format of the RawData element. The value should be >> chosen from the namespaces [XMLNames] listed in Section 4.1 or >> "private". Note that the lists in Section 4.1 will be developed >> further by IANA. The value "private" is prepared for conveying >> RawData based on a format that is not listed in the >> table. This is usually used for conveying data formatted >> according to an organization's private schema. When the value >> "private" is used, ext-SpecID element needs to be used. >>=20 >> ext-SpecID: OPTIONAL. STRING. The identifier of the specification >> specifying the format of the RawData element. When this element >> is used, the value of SpecID element must be "private." >>=20 >> I hope above changes don't cause any complication here. >>=20 >> Sincerely, >> Take >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>> Martin, Robert A. >>> Sent: Wednesday, February 15, 2012 1:50 AM >>> To: Kent_Landfield@McAfee.com >>> Cc: mile@ietf.org >>> Subject: Re: [mile] MTI SCI? >>>=20 >>> At the risk of contradicting myself - but then again I have now read the= >>> other replies to this issue - I agree that having one area be the smoke >>> test makes sense and I also agree that something simple and commonly use= d >>> already - like CVE - is the best candidate for what we need. >>>=20 >>> Bob >>>=20 >>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>> CVE is widely used and understood by all in the the security community.= >>> I agree with Tom that CVE is the path of least resistance but may be the= >>> most useful for basic interoperability. >>>>=20 >>>> Kent Landfield >>>> Director Content Strategy, Architecture and Standards >>>>=20 >>>> McAfee | An Intel Company >>>> 5000 Headquarters Dr. >>>> Plano, Texas 75024 >>>>=20 >>>> Direct: +1.972.963.7096 >>>> Mobile: +1.817.637.8026 >>>> Web: www.mcafee.com >>>>=20 >>>> From: >>>>=20 >>> "Thomas.Millar@us-cert.gov">> .M >>>> illar@us-cert.gov> >>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>> To: >>>>=20 >>> "david.black@emc.com">> m< >>>> mailto:david.black@emc.com>>, Bob >>>> Martin> >>>> Cc: >>>>=20 >>> "mile@ietf.org">> .o >>>> rg>> >>>> Subject: Re: [mile] MTI SCI? >>>>=20 >>>> My concern with CAPEC being mandatory is that it could discourage >>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary remain= s >>> "too comprehensive" for many CSIRTs to employ during incident handling >>> and reporting activity. >>>>=20 >>>> IODEF by itself has been criticized by CSIRT operators for being more >>> heavyweight than necessary for day-to-day usage; making CAPEC a mandator= y >>> aspect of "advanced IODEF" seems like it would be adding ammunition to >>> that argument, especially if the CSIRT is having to fund implementation >>> out of their own pocket. Personally, I would have a hard time asking >>> US-CERT's primary constituents to implement IODEF + CAPEC if they are >>> already balking at the consultant and developer resources required to >>> implement RFC 5070 by itself. Also keep in mind that CAPEC references >>> CybOX, so there's wheels within wheels now. >>>>=20 >>>> I would prefer we take the path of least resistance (from my >> perspective) >>> and make CVE the MTI, if we have to pick one additional spec. >>>> CVE is well known, has years of familiarity built in, and I think it's >>> the simplest schema of the bunch. >>>>=20 >>>>=20 >>>> - Tom Millar, US-CERT >>>>=20 >>>> thomas.millar@us-cert.gov >>>> BB: thomas.millar@dhs.gov / >>>> 202-631-1915 >>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>=20 >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org >>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>> david.black@emc.com >>>> Sent: Tuesday, February 14, 2012 11:14 >>>> To: ramartin@mitre.org >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] MTI SCI? >>>>=20 >>>> Hi Bob, >>>>=20 >>>> I do appreciate the concern about implementing things that aren't going= >>> to be used. OTOH, it may be useful to have a single simple MTI spec for= >>> SCI that can be used to "smoke test" a deployment before trying any >> serious >>> test data (and "simple" is important). >>>>=20 >>>> In addition, a concern that I would have with an MTI SCI spec per class= >>> is that if two SCI implementations don't have at least one class in >> common, >>> they aren't going to interoperate, and that situation is unlikely to be >>> acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect >>> that there will also have to be an MTI class, which results in an overal= l >>> MTI SCI spec). >>>>=20 >>>> It may also be useful to include a simple example of the MTI SCI spec >>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec >>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML >>> document for testing purposes, including enumeration values suitable for= >>> testing). >>>>=20 >>>> What do you (and others) think about this? >>>>=20 >>>> Thanks, >>>> --David >>>>=20 >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org >>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>> To: Brian Trammell >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] MTI SCI? >>>> Brian, >>>> You beat me to this point. Like you, I would be concerned about a MTI >>>> selection that ended up requiring someone to implement something to >>>> meet the MTI but wasn't germane to anything else they intended to >>> support. >>>> Bob >>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>> Hi, Sean, all, >>>>>=20 >>>>> Looking over the spec, it's not clear to me that one MTI makes sense >>>>> here, given that mile-sci's >>>> purpose is to reference a set of external specifications by inclusion >>>> in an IODEF document, and that those external specifications represent >>> fundamentally different things. >>>>>=20 >>>>> The specifications are split over their applicability to the IODEF >>>>> extension classes. I could >>>> envision an mile-sci implementation that was only interested a subset >>>> of these classes (perhaps even only one). If my implementation has an >>>> internal representation of Verification, but not of any of the other >>>> classes, and the MTI is an enumeration that is applicable to >>> Vulnerability... what do I do? >>>>>=20 >>>>> What about selecting an MTI per class, instead? >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Brian (as contributor) >>>>>=20 >>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>=20 >>>>>> Great - as long as we pick one as the MTI. Note that MTI is not >>> necessarily mandatory to use. >>>>>>=20 >>>>>> spt >>>>>>=20 >>>>>> On 2/13/12 7:11 PM, >>> kathleen.moriarty@emc.com wrote: >>>>>>> Thank you for raising the interoperability testing as we need to >>>>>>> plan for a bake-off that once >>>> these questions get answered and the draft is ready. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Kathleen >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org >>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>> To: mile@ietf.org >>>>>>> Subject: [mile] MTI SCI? >>>>>>>=20 >>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>>> (mandatory to implement) choice? In other words, how will you get >>>>>>> two interoperability implementations without picking one? >>>>>>>=20 >>>>>>> spt >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>=20 >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> . >>>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From ramartin@mitre.org Wed Feb 15 04:43:27 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB221F8575 for ; Wed, 15 Feb 2012 04:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ia+KspVExWs4 for ; Wed, 15 Feb 2012 04:43:23 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4477B21F8489 for ; Wed, 15 Feb 2012 04:43:23 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D3D1421B07A7; Wed, 15 Feb 2012 07:43:21 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BB97521B07AE; Wed, 15 Feb 2012 07:43:21 -0500 (EST) Received: from MM169528-pc.local (129.83.31.55) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server id 14.1.339.1; Wed, 15 Feb 2012 07:43:21 -0500 Message-ID: <4F3BA869.3010604@mitre.org> Date: Wed, 15 Feb 2012 07:43:21 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Kent Landfield References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "mile@ietf.org" Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:43:28 -0000 Agree On 2/15/12 7:32 AM, Kent Landfield wrote: > I agree. > > Kent Landfield > McAfee Labs > Kent_Landfield@McAfee.com > +1.817.637.8026 > > On Feb 15, 2012, at 4:27 AM, Brian Trammell wrote: > >> Hi, Take, all, >> >> Thank you for this edit/clarification. >> >> On the first point, it does seem the discussion on the list converged rather quickly to CVE as MTI. However, as this is a rather important point, I'd like to make sure we didn't miss anything. >> >> So, I'd like to call for consensus on the list. Does the working group agree on the following two points? >> >> 1. mile-sci requires one Mandatory to Implement schema in order to ensure interoperability. >> >> 2. The Mandatory to Implement schema is the Common Vulnerability Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile-sci-02. >> >> Please note if you agree; if you disagree, please explain why not. >> >> Best regards, >> >> Brian (as chair) >> >> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >> >>> Hello all, >>> >>> Following the discussion, I would like to add a couple of sentences to >>> clarify the MTI issues. >>> (Thank you very much for those of you who kindly provided useful >>> discussion.) >>> I've attached the working version of the draft. I hope it helps to clarify >>> the changes. >>> >>> (added sentences at the end of section 4.1) >>> >>> The SpecID attributes of extended classes (Section 4.3) must allow >>> the values of the specifications' namespace fields, but otherwise, >>> implementations are not required to support all the above >>> specifications. Implementations may choose which specifications to >>> support, though CVE 1.0 (Section 4.1.7) needs to be minimally >>> supported. In case an implementation received a data it does not >>> support, it may expand its functionality by looking up the IANA table or >>> notify the sender of its inability to parse the data by using any >>> means defined outside the scope of this specification. >>> >>> On the other hand, I would like to add "STRING ext-SpecID" to each class, >>> which enables to embed data following private schema. >>> For instance, one security operation center (SOC) may wish to exchange a >>> vulnerability data that is formatted in its own private schema, and that is >>> not formatted in CVE. >>> In this case, the SOC may put the data's schema ID inside ext-SpecID and >>> then embed the data. >>> It could also be used to exchange data using beta version of specifications. >>> >>> The class could be seen as below. >>> >>> +------------------------+ >>> | AttackPattern | >>> +------------------------+ >>> | ENUM SpecID |<>--(0..*)-[ RawData ] >>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] >>> +------------------------+ >>> >>> SpecID: REQUIRED. ENUM. The identifier of the specification >>> specifying the format of the RawData element. The value should be >>> chosen from the namespaces [XMLNames] listed in Section 4.1 or >>> "private". Note that the lists in Section 4.1 will be developed >>> further by IANA. The value "private" is prepared for conveying >>> RawData based on a format that is not listed in the >>> table. This is usually used for conveying data formatted >>> according to an organization's private schema. When the value >>> "private" is used, ext-SpecID element needs to be used. >>> >>> ext-SpecID: OPTIONAL. STRING. The identifier of the specification >>> specifying the format of the RawData element. When this element >>> is used, the value of SpecID element must be "private." >>> >>> I hope above changes don't cause any complication here. >>> >>> Sincerely, >>> Take >>> >>> >>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >>>> Martin, Robert A. >>>> Sent: Wednesday, February 15, 2012 1:50 AM >>>> To: Kent_Landfield@McAfee.com >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] MTI SCI? >>>> >>>> At the risk of contradicting myself - but then again I have now read the >>>> other replies to this issue - I agree that having one area be the smoke >>>> test makes sense and I also agree that something simple and commonly used >>>> already - like CVE - is the best candidate for what we need. >>>> >>>> Bob >>>> >>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>>> CVE is widely used and understood by all in the the security community. >>>> I agree with Tom that CVE is the path of least resistance but may be the >>>> most useful for basic interoperability. >>>>> >>>>> Kent Landfield >>>>> Director Content Strategy, Architecture and Standards >>>>> >>>>> McAfee | An Intel Company >>>>> 5000 Headquarters Dr. >>>>> Plano, Texas 75024 >>>>> >>>>> Direct: +1.972.963.7096 >>>>> Mobile: +1.817.637.8026 >>>>> Web: www.mcafee.com >>>>> >>>>> From: >>>>> >>>> "Thomas.Millar@us-cert.gov">>> .M >>>>> illar@us-cert.gov> >>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>>> To: >>>>> >>>> "david.black@emc.com">>> m< >>>>> mailto:david.black@emc.com>>, Bob >>>>> Martin> >>>>> Cc: >>>>> >>>> "mile@ietf.org">>> .o >>>>> rg>> >>>>> Subject: Re: [mile] MTI SCI? >>>>> >>>>> My concern with CAPEC being mandatory is that it could discourage >>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary remains >>>> "too comprehensive" for many CSIRTs to employ during incident handling >>>> and reporting activity. >>>>> >>>>> IODEF by itself has been criticized by CSIRT operators for being more >>>> heavyweight than necessary for day-to-day usage; making CAPEC a mandatory >>>> aspect of "advanced IODEF" seems like it would be adding ammunition to >>>> that argument, especially if the CSIRT is having to fund implementation >>>> out of their own pocket. Personally, I would have a hard time asking >>>> US-CERT's primary constituents to implement IODEF + CAPEC if they are >>>> already balking at the consultant and developer resources required to >>>> implement RFC 5070 by itself. Also keep in mind that CAPEC references >>>> CybOX, so there's wheels within wheels now. >>>>> >>>>> I would prefer we take the path of least resistance (from my >>> perspective) >>>> and make CVE the MTI, if we have to pick one additional spec. >>>>> CVE is well known, has years of familiarity built in, and I think it's >>>> the simplest schema of the bunch. >>>>> >>>>> >>>>> - Tom Millar, US-CERT >>>>> >>>>> thomas.millar@us-cert.gov >>>>> BB: thomas.millar@dhs.gov / >>>>> 202-631-1915 >>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>> david.black@emc.com >>>>> Sent: Tuesday, February 14, 2012 11:14 >>>>> To: ramartin@mitre.org >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] MTI SCI? >>>>> >>>>> Hi Bob, >>>>> >>>>> I do appreciate the concern about implementing things that aren't going >>>> to be used. OTOH, it may be useful to have a single simple MTI spec for >>>> SCI that can be used to "smoke test" a deployment before trying any >>> serious >>>> test data (and "simple" is important). >>>>> >>>>> In addition, a concern that I would have with an MTI SCI spec per class >>>> is that if two SCI implementations don't have at least one class in >>> common, >>>> they aren't going to interoperate, and that situation is unlikely to be >>>> acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect >>>> that there will also have to be an MTI class, which results in an overall >>>> MTI SCI spec). >>>>> >>>>> It may also be useful to include a simple example of the MTI SCI spec >>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec >>>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML >>>> document for testing purposes, including enumeration values suitable for >>>> testing). >>>>> >>>>> What do you (and others) think about this? >>>>> >>>>> Thanks, >>>>> --David >>>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org >>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>>> To: Brian Trammell >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] MTI SCI? >>>>> Brian, >>>>> You beat me to this point. Like you, I would be concerned about a MTI >>>>> selection that ended up requiring someone to implement something to >>>>> meet the MTI but wasn't germane to anything else they intended to >>>> support. >>>>> Bob >>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>>> Hi, Sean, all, >>>>>> >>>>>> Looking over the spec, it's not clear to me that one MTI makes sense >>>>>> here, given that mile-sci's >>>>> purpose is to reference a set of external specifications by inclusion >>>>> in an IODEF document, and that those external specifications represent >>>> fundamentally different things. >>>>>> >>>>>> The specifications are split over their applicability to the IODEF >>>>>> extension classes. I could >>>>> envision an mile-sci implementation that was only interested a subset >>>>> of these classes (perhaps even only one). If my implementation has an >>>>> internal representation of Verification, but not of any of the other >>>>> classes, and the MTI is an enumeration that is applicable to >>>> Vulnerability... what do I do? >>>>>> >>>>>> What about selecting an MTI per class, instead? >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Brian (as contributor) >>>>>> >>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>> >>>>>>> Great - as long as we pick one as the MTI. Note that MTI is not >>>> necessarily mandatory to use. >>>>>>> >>>>>>> spt >>>>>>> >>>>>>> On 2/13/12 7:11 PM, >>>> kathleen.moriarty@emc.com wrote: >>>>>>>> Thank you for raising the interoperability testing as we need to >>>>>>>> plan for a bake-off that once >>>>> these questions get answered and the draft is ready. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kathleen >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mile-bounces@ietf.org >>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>>> To: mile@ietf.org >>>>>>>> Subject: [mile] MTI SCI? >>>>>>>> >>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>>>> (mandatory to implement) choice? In other words, how will you get >>>>>>>> two interoperability implementations without picking one? >>>>>>>> >>>>>>>> spt >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> . >>>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > From david.black@emc.com Wed Feb 15 06:43:50 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5772A21E8040 for ; Wed, 15 Feb 2012 06:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.492 X-Spam-Level: X-Spam-Status: No, score=-109.492 tagged_above=-999 required=5 tests=[AWL=1.107, 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 IRBZV0zebvru for ; Wed, 15 Feb 2012 06:43:48 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD0121E801C for ; Wed, 15 Feb 2012 06:43:48 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FEhgnf010649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 09:43:44 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 15 Feb 2012 09:43:25 -0500 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FEhPTp004069; Wed, 15 Feb 2012 09:43:25 -0500 Received: from mx14a.corp.emc.com ([169.254.1.94]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Wed, 15 Feb 2012 09:43:24 -0500 From: To: , Date: Wed, 15 Feb 2012 09:43:23 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: Aczr3/jIdZwdgGpYR3aw2BnGulwcGAAD5lAA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33A96E@MX14A.corp.emc.com> References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> <4F3BA869.3010604@mitre.org> In-Reply-To: <4F3BA869.3010604@mitre.org> 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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:43:50 -0000 Agree - I'd also like to see a CVE XML document suitable for testing, or at= least CVE enumeration values recommended for that purpose in an Appendix. = The rationale would be to provide implementers with data for smoke tests t= hat is clearly for testing only, and hence cannot be confused with actual C= VE data if it should escape the smoke test into operational systems. Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of M= artin, Robert A. > Sent: Wednesday, February 15, 2012 7:43 AM > To: Kent Landfield > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= s Re: MTI SCI?) >=20 > Agree >=20 > On 2/15/12 7:32 AM, Kent Landfield wrote: > > I agree. > > > > Kent Landfield > > McAfee Labs > > Kent_Landfield@McAfee.com > > +1.817.637.8026 > > > > On Feb 15, 2012, at 4:27 AM, Brian Trammell w= rote: > > > >> Hi, Take, all, > >> > >> Thank you for this edit/clarification. > >> > >> On the first point, it does seem the discussion on the list converged = rather quickly to CVE as > MTI. However, as this is a rather important point, I'd like to make sure = we didn't miss anything. > >> > >> So, I'd like to call for consensus on the list. Does the working group= agree on the following two > points? > >> > >> 1. mile-sci requires one Mandatory to Implement schema in order to ens= ure interoperability. > >> > >> 2. The Mandatory to Implement schema is the Common Vulnerability Enume= ration (CVE) version 1.0, > as described in section 4.1.7 of mile-sci-02. > >> > >> Please note if you agree; if you disagree, please explain why not. > >> > >> Best regards, > >> > >> Brian (as chair) > >> > >> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > >> > >>> Hello all, > >>> > >>> Following the discussion, I would like to add a couple of sentences t= o > >>> clarify the MTI issues. > >>> (Thank you very much for those of you who kindly provided useful > >>> discussion.) > >>> I've attached the working version of the draft. I hope it helps to cl= arify > >>> the changes. > >>> > >>> (added sentences at the end of section 4.1) > >>> > >>> The SpecID attributes of extended classes (Section 4.3) must allow > >>> the values of the specifications' namespace fields, but otherwise, > >>> implementations are not required to support all the above > >>> specifications. Implementations may choose which specifications to > >>> support, though CVE 1.0 (Section 4.1.7) needs to be minimally > >>> supported. In case an implementation received a data it does not > >>> support, it may expand its functionality by looking up the IANA tab= le or > >>> notify the sender of its inability to parse the data by using any > >>> means defined outside the scope of this specification. > >>> > >>> On the other hand, I would like to add "STRING ext-SpecID" to each cl= ass, > >>> which enables to embed data following private schema. > >>> For instance, one security operation center (SOC) may wish to exchang= e a > >>> vulnerability data that is formatted in its own private schema, and t= hat is > >>> not formatted in CVE. > >>> In this case, the SOC may put the data's schema ID inside ext-SpecID = and > >>> then embed the data. > >>> It could also be used to exchange data using beta version of specific= ations. > >>> > >>> The class could be seen as below. > >>> > >>> +------------------------+ > >>> | AttackPattern | > >>> +------------------------+ > >>> | ENUM SpecID |<>--(0..*)-[ RawData ] > >>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] > >>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] > >>> +------------------------+ > >>> > >>> SpecID: REQUIRED. ENUM. The identifier of the specification > >>> specifying the format of the RawData element. The value should = be > >>> chosen from the namespaces [XMLNames] listed in Section 4.1 or > >>> "private". Note that the lists in Section 4.1 will be developed > >>> further by IANA. The value "private" is prepared for conveying > >>> RawData based on a format that is not listed in the > >>> table. This is usually used for conveying data formatted > >>> according to an organization's private schema. When the value > >>> "private" is used, ext-SpecID element needs to be used. > >>> > >>> ext-SpecID: OPTIONAL. STRING. The identifier of the specificatio= n > >>> specifying the format of the RawData element. When this element > >>> is used, the value of SpecID element must be "private." > >>> > >>> I hope above changes don't cause any complication here. > >>> > >>> Sincerely, > >>> Take > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf= Of > >>>> Martin, Robert A. > >>>> Sent: Wednesday, February 15, 2012 1:50 AM > >>>> To: Kent_Landfield@McAfee.com > >>>> Cc: mile@ietf.org > >>>> Subject: Re: [mile] MTI SCI? > >>>> > >>>> At the risk of contradicting myself - but then again I have now read= the > >>>> other replies to this issue - I agree that having one area be the sm= oke > >>>> test makes sense and I also agree that something simple and commonly= used > >>>> already - like CVE - is the best candidate for what we need. > >>>> > >>>> Bob > >>>> > >>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > >>>>> CVE is widely used and understood by all in the the security commun= ity. > >>>> I agree with Tom that CVE is the path of least resistance but may be= the > >>>> most useful for basic interoperability. > >>>>> > >>>>> Kent Landfield > >>>>> Director Content Strategy, Architecture and Standards > >>>>> > >>>>> McAfee | An Intel Company > >>>>> 5000 Headquarters Dr. > >>>>> Plano, Texas 75024 > >>>>> > >>>>> Direct: +1.972.963.7096 > >>>>> Mobile: +1.817.637.8026 > >>>>> Web: www.mcafee.com > >>>>> > >>>>> From: > >>>>> > >>>> "Thomas.Millar@us-cert.gov" >>>> .M > >>>>> illar@us-cert.gov> > >>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > >>>>> To: > >>>>> > >>>> "david.black@emc.com" >>>> m< > >>>>> mailto:david.black@emc.com>>, Bob > >>>>> Martin> > >>>>> Cc: > >>>>> > >>>> "mile@ietf.org" >>>> .o > >>>>> rg>> > >>>>> Subject: Re: [mile] MTI SCI? > >>>>> > >>>>> My concern with CAPEC being mandatory is that it could discourage > >>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary re= mains > >>>> "too comprehensive" for many CSIRTs to employ during incident handli= ng > >>>> and reporting activity. > >>>>> > >>>>> IODEF by itself has been criticized by CSIRT operators for being mo= re > >>>> heavyweight than necessary for day-to-day usage; making CAPEC a mand= atory > >>>> aspect of "advanced IODEF" seems like it would be adding ammunition = to > >>>> that argument, especially if the CSIRT is having to fund implementat= ion > >>>> out of their own pocket. Personally, I would have a hard time asking > >>>> US-CERT's primary constituents to implement IODEF + CAPEC if they ar= e > >>>> already balking at the consultant and developer resources required t= o > >>>> implement RFC 5070 by itself. Also keep in mind that CAPEC reference= s > >>>> CybOX, so there's wheels within wheels now. > >>>>> > >>>>> I would prefer we take the path of least resistance (from my > >>> perspective) > >>>> and make CVE the MTI, if we have to pick one additional spec. > >>>>> CVE is well known, has years of familiarity built in, and I think i= t's > >>>> the simplest schema of the bunch. > >>>>> > >>>>> > >>>>> - Tom Millar, US-CERT > >>>>> > >>>>> thomas.millar@us-cert.gov > >>>>> BB: thomas.millar@dhs.gov / > >>>>> 202-631-1915 > >>>>> 24x7: soc@us-cert.gov / 888-282-0870 > >>>>> > >>>>> -----Original Message----- > >>>>> From: mile-bounces@ietf.org > >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of > >>>>> david.black@emc.com > >>>>> Sent: Tuesday, February 14, 2012 11:14 > >>>>> To: ramartin@mitre.org > >>>>> Cc: mile@ietf.org > >>>>> Subject: Re: [mile] MTI SCI? > >>>>> > >>>>> Hi Bob, > >>>>> > >>>>> I do appreciate the concern about implementing things that aren't g= oing > >>>> to be used. OTOH, it may be useful to have a single simple MTI spec= for > >>>> SCI that can be used to "smoke test" a deployment before trying any > >>> serious > >>>> test data (and "simple" is important). > >>>>> > >>>>> In addition, a concern that I would have with an MTI SCI spec per c= lass > >>>> is that if two SCI implementations don't have at least one class in > >>> common, > >>>> they aren't going to interoperate, and that situation is unlikely to= be > >>>> acceptable to the IESG (i.e., with an MTI SCI spec per class, I susp= ect > >>>> that there will also have to be an MTI class, which results in an ov= erall > >>>> MTI SCI spec). > >>>>> > >>>>> It may also be useful to include a simple example of the MTI SCI sp= ec > >>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spe= c > >>>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML > >>>> document for testing purposes, including enumeration values suitable= for > >>>> testing). > >>>>> > >>>>> What do you (and others) think about this? > >>>>> > >>>>> Thanks, > >>>>> --David > >>>>> > >>>>> -----Original Message----- > >>>>> From: mile-bounces@ietf.org > >>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > >>>>> Sent: Tuesday, February 14, 2012 8:26 AM > >>>>> To: Brian Trammell > >>>>> Cc: mile@ietf.org > >>>>> Subject: Re: [mile] MTI SCI? > >>>>> Brian, > >>>>> You beat me to this point. Like you, I would be concerned about a = MTI > >>>>> selection that ended up requiring someone to implement something to > >>>>> meet the MTI but wasn't germane to anything else they intended to > >>>> support. > >>>>> Bob > >>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: > >>>>>> Hi, Sean, all, > >>>>>> > >>>>>> Looking over the spec, it's not clear to me that one MTI makes sen= se > >>>>>> here, given that mile-sci's > >>>>> purpose is to reference a set of external specifications by inclusi= on > >>>>> in an IODEF document, and that those external specifications repres= ent > >>>> fundamentally different things. > >>>>>> > >>>>>> The specifications are split over their applicability to the IODEF > >>>>>> extension classes. I could > >>>>> envision an mile-sci implementation that was only interested a subs= et > >>>>> of these classes (perhaps even only one). If my implementation has = an > >>>>> internal representation of Verification, but not of any of the othe= r > >>>>> classes, and the MTI is an enumeration that is applicable to > >>>> Vulnerability... what do I do? > >>>>>> > >>>>>> What about selecting an MTI per class, instead? > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> Brian (as contributor) > >>>>>> > >>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >>>>>> > >>>>>>> Great - as long as we pick one as the MTI. Note that MTI is not > >>>> necessarily mandatory to use. > >>>>>>> > >>>>>>> spt > >>>>>>> > >>>>>>> On 2/13/12 7:11 PM, > >>>> kathleen.moriarty@emc.com wrote: > >>>>>>>> Thank you for raising the interoperability testing as we need to > >>>>>>>> plan for a bake-off that once > >>>>> these questions get answered and the draft is ready. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Kathleen > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: mile-bounces@ietf.org > >>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > >>>>>>>> Sent: Monday, February 13, 2012 6:57 PM > >>>>>>>> To: mile@ietf.org > >>>>>>>> Subject: [mile] MTI SCI? > >>>>>>>> > >>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > >>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > >>>>>>>> (mandatory to implement) choice? In other words, how will you g= et > >>>>>>>> two interoperability implementations without picking one? > >>>>>>>> > >>>>>>>> spt > >>>>>>>> _______________________________________________ > >>>>>>>> mile mailing list > >>>>>>>> mile@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>>>>> > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> mile mailing list > >>>>>>> mile@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mile mailing list > >>>>>> mile@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>>> . > >>>>>> > >>>>> _______________________________________________ > >>>>> mile mailing list > >>>>> mile@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>> > >>>>> _______________________________________________ > >>>>> mile mailing list > >>>>> mile@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>> _______________________________________________ > >>>>> mile mailing list > >>>>> mile@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>> 03candidate_20120215.txt.pdf>____________________________________________= ___ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > . > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From lnunez@c3isecurity.com Wed Feb 15 06:50:04 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2521F8652 for ; Wed, 15 Feb 2012 06:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 unLpmQjJeHfi for ; Wed, 15 Feb 2012 06:50:00 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5343E21F856F for ; Wed, 15 Feb 2012 06:49:56 -0800 (PST) Received: by yhkk25 with SMTP id k25so729376yhk.31 for ; Wed, 15 Feb 2012 06:49:55 -0800 (PST) Received: by 10.101.9.25 with SMTP id m25mr10421612ani.20.1329317395457; Wed, 15 Feb 2012 06:49:55 -0800 (PST) Received: from [172.16.1.103] (cpe-066-057-025-190.nc.res.rr.com. [66.57.25.190]) by mx.google.com with ESMTPS id b4sm4996063and.18.2012.02.15.06.49.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 06:49:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33A96E@MX14A.corp.emc.com> Date: Wed, 15 Feb 2012 09:49:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <399961E1-685C-4D29-988A-B8C0A8AE8B89@c3isecurity.com> References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> <4F3BA869.3010604@mitre.org> <7C4DFCE962635144B8FAE8CA11D0BF1E05AD33A96E@MX14A.corp.emc.com> To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkBMCfmGqFw74Xl/PCD3aVamNbWLQCQOZS1Nxb7XSk1KxYOxyZzNte9sVt2tPT4CmrWirI0 Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:50:04 -0000 Agree - David also make a good point about having samples of what it = looks like. -ln On Feb 15, 2012, at 9:43 AM, = wrote: > Agree - I'd also like to see a CVE XML document suitable for testing, = or at least CVE enumeration values recommended for that purpose in an = Appendix. The rationale would be to provide implementers with data for = smoke tests that is clearly for testing only, and hence cannot be = confused with actual CVE data if it should escape the smoke test into = operational systems. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Martin, Robert A. >> Sent: Wednesday, February 15, 2012 7:43 AM >> To: Kent Landfield >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI = (was Re: MTI SCI?) >>=20 >> Agree >>=20 >> On 2/15/12 7:32 AM, Kent Landfield wrote: >>> I agree. >>>=20 >>> Kent Landfield >>> McAfee Labs >>> Kent_Landfield@McAfee.com >>> +1.817.637.8026 >>>=20 >>> On Feb 15, 2012, at 4:27 AM, Brian Trammell = wrote: >>>=20 >>>> Hi, Take, all, >>>>=20 >>>> Thank you for this edit/clarification. >>>>=20 >>>> On the first point, it does seem the discussion on the list = converged rather quickly to CVE as >> MTI. However, as this is a rather important point, I'd like to make = sure we didn't miss anything. >>>>=20 >>>> So, I'd like to call for consensus on the list. Does the working = group agree on the following two >> points? >>>>=20 >>>> 1. mile-sci requires one Mandatory to Implement schema in order to = ensure interoperability. >>>>=20 >>>> 2. The Mandatory to Implement schema is the Common Vulnerability = Enumeration (CVE) version 1.0, >> as described in section 4.1.7 of mile-sci-02. >>>>=20 >>>> Please note if you agree; if you disagree, please explain why not. >>>>=20 >>>> Best regards, >>>>=20 >>>> Brian (as chair) >>>>=20 >>>> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >>>>=20 >>>>> Hello all, >>>>>=20 >>>>> Following the discussion, I would like to add a couple of = sentences to >>>>> clarify the MTI issues. >>>>> (Thank you very much for those of you who kindly provided useful >>>>> discussion.) >>>>> I've attached the working version of the draft. I hope it helps to = clarify >>>>> the changes. >>>>>=20 >>>>> (added sentences at the end of section 4.1) >>>>>=20 >>>>> The SpecID attributes of extended classes (Section 4.3) must = allow >>>>> the values of the specifications' namespace fields, but = otherwise, >>>>> implementations are not required to support all the above >>>>> specifications. Implementations may choose which specifications = to >>>>> support, though CVE 1.0 (Section 4.1.7) needs to be minimally >>>>> supported. In case an implementation received a data it does not >>>>> support, it may expand its functionality by looking up the IANA = table or >>>>> notify the sender of its inability to parse the data by using any >>>>> means defined outside the scope of this specification. >>>>>=20 >>>>> On the other hand, I would like to add "STRING ext-SpecID" to each = class, >>>>> which enables to embed data following private schema. >>>>> For instance, one security operation center (SOC) may wish to = exchange a >>>>> vulnerability data that is formatted in its own private schema, = and that is >>>>> not formatted in CVE. >>>>> In this case, the SOC may put the data's schema ID inside = ext-SpecID and >>>>> then embed the data. >>>>> It could also be used to exchange data using beta version of = specifications. >>>>>=20 >>>>> The class could be seen as below. >>>>>=20 >>>>> +------------------------+ >>>>> | AttackPattern | >>>>> +------------------------+ >>>>> | ENUM SpecID |<>--(0..*)-[ RawData ] >>>>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >>>>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] >>>>> +------------------------+ >>>>>=20 >>>>> SpecID: REQUIRED. ENUM. The identifier of the specification >>>>> specifying the format of the RawData element. The value = should be >>>>> chosen from the namespaces [XMLNames] listed in Section 4.1 or >>>>> "private". Note that the lists in Section 4.1 will be = developed >>>>> further by IANA. The value "private" is prepared for conveying >>>>> RawData based on a format that is not listed in the >>>>> table. This is usually used for conveying data formatted >>>>> according to an organization's private schema. When the value >>>>> "private" is used, ext-SpecID element needs to be used. >>>>>=20 >>>>> ext-SpecID: OPTIONAL. STRING. The identifier of the = specification >>>>> specifying the format of the RawData element. When this = element >>>>> is used, the value of SpecID element must be "private." >>>>>=20 >>>>> I hope above changes don't cause any complication here. >>>>>=20 >>>>> Sincerely, >>>>> Take >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf Of >>>>>> Martin, Robert A. >>>>>> Sent: Wednesday, February 15, 2012 1:50 AM >>>>>> To: Kent_Landfield@McAfee.com >>>>>> Cc: mile@ietf.org >>>>>> Subject: Re: [mile] MTI SCI? >>>>>>=20 >>>>>> At the risk of contradicting myself - but then again I have now = read the >>>>>> other replies to this issue - I agree that having one area be the = smoke >>>>>> test makes sense and I also agree that something simple and = commonly used >>>>>> already - like CVE - is the best candidate for what we need. >>>>>>=20 >>>>>> Bob >>>>>>=20 >>>>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>>>>> CVE is widely used and understood by all in the the security = community. >>>>>> I agree with Tom that CVE is the path of least resistance but may = be the >>>>>> most useful for basic interoperability. >>>>>>>=20 >>>>>>> Kent Landfield >>>>>>> Director Content Strategy, Architecture and Standards >>>>>>>=20 >>>>>>> McAfee | An Intel Company >>>>>>> 5000 Headquarters Dr. >>>>>>> Plano, Texas 75024 >>>>>>>=20 >>>>>>> Direct: +1.972.963.7096 >>>>>>> Mobile: +1.817.637.8026 >>>>>>> Web: www.mcafee.com >>>>>>>=20 >>>>>>> From: >>>>>>>=20 >>>>>> = "Thomas.Millar@us-cert.gov">>>>> .M >>>>>>> illar@us-cert.gov> >>>>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>>>>> To: >>>>>>>=20 >>>>>> = "david.black@emc.com">>>>> m< >>>>>>> mailto:david.black@emc.com>>, Bob >>>>>>> Martin> >>>>>>> Cc: >>>>>>>=20 >>>>>> = "mile@ietf.org">>>>> .o >>>>>>> rg>> >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>=20 >>>>>>> My concern with CAPEC being mandatory is that it could = discourage >>>>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary = remains >>>>>> "too comprehensive" for many CSIRTs to employ during incident = handling >>>>>> and reporting activity. >>>>>>>=20 >>>>>>> IODEF by itself has been criticized by CSIRT operators for being = more >>>>>> heavyweight than necessary for day-to-day usage; making CAPEC a = mandatory >>>>>> aspect of "advanced IODEF" seems like it would be adding = ammunition to >>>>>> that argument, especially if the CSIRT is having to fund = implementation >>>>>> out of their own pocket. Personally, I would have a hard time = asking >>>>>> US-CERT's primary constituents to implement IODEF + CAPEC if they = are >>>>>> already balking at the consultant and developer resources = required to >>>>>> implement RFC 5070 by itself. Also keep in mind that CAPEC = references >>>>>> CybOX, so there's wheels within wheels now. >>>>>>>=20 >>>>>>> I would prefer we take the path of least resistance (from my >>>>> perspective) >>>>>> and make CVE the MTI, if we have to pick one additional spec. >>>>>>> CVE is well known, has years of familiarity built in, and I = think it's >>>>>> the simplest schema of the bunch. >>>>>>>=20 >>>>>>>=20 >>>>>>> - Tom Millar, US-CERT >>>>>>>=20 >>>>>>> thomas.millar@us-cert.gov >>>>>>> BB: thomas.millar@dhs.gov / >>>>>>> 202-631-1915 >>>>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org >>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>>>> david.black@emc.com >>>>>>> Sent: Tuesday, February 14, 2012 11:14 >>>>>>> To: ramartin@mitre.org >>>>>>> Cc: mile@ietf.org >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>=20 >>>>>>> Hi Bob, >>>>>>>=20 >>>>>>> I do appreciate the concern about implementing things that = aren't going >>>>>> to be used. OTOH, it may be useful to have a single simple MTI = spec for >>>>>> SCI that can be used to "smoke test" a deployment before trying = any >>>>> serious >>>>>> test data (and "simple" is important). >>>>>>>=20 >>>>>>> In addition, a concern that I would have with an MTI SCI spec = per class >>>>>> is that if two SCI implementations don't have at least one class = in >>>>> common, >>>>>> they aren't going to interoperate, and that situation is unlikely = to be >>>>>> acceptable to the IESG (i.e., with an MTI SCI spec per class, I = suspect >>>>>> that there will also have to be an MTI class, which results in an = overall >>>>>> MTI SCI spec). >>>>>>>=20 >>>>>>> It may also be useful to include a simple example of the MTI SCI = spec >>>>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI = spec >>>>>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC = XML >>>>>> document for testing purposes, including enumeration values = suitable for >>>>>> testing). >>>>>>>=20 >>>>>>> What do you (and others) think about this? >>>>>>>=20 >>>>>>> Thanks, >>>>>>> --David >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>>>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>>>>> To: Brian Trammell >>>>>>> Cc: mile@ietf.org >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>> Brian, >>>>>>> You beat me to this point. Like you, I would be concerned about = a MTI >>>>>>> selection that ended up requiring someone to implement something = to >>>>>>> meet the MTI but wasn't germane to anything else they intended = to >>>>>> support. >>>>>>> Bob >>>>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>>>>> Hi, Sean, all, >>>>>>>>=20 >>>>>>>> Looking over the spec, it's not clear to me that one MTI makes = sense >>>>>>>> here, given that mile-sci's >>>>>>> purpose is to reference a set of external specifications by = inclusion >>>>>>> in an IODEF document, and that those external specifications = represent >>>>>> fundamentally different things. >>>>>>>>=20 >>>>>>>> The specifications are split over their applicability to the = IODEF >>>>>>>> extension classes. I could >>>>>>> envision an mile-sci implementation that was only interested a = subset >>>>>>> of these classes (perhaps even only one). If my implementation = has an >>>>>>> internal representation of Verification, but not of any of the = other >>>>>>> classes, and the MTI is an enumeration that is applicable to >>>>>> Vulnerability... what do I do? >>>>>>>>=20 >>>>>>>> What about selecting an MTI per class, instead? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Brian (as contributor) >>>>>>>>=20 >>>>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>>>>=20 >>>>>>>>> Great - as long as we pick one as the MTI. Note that MTI is = not >>>>>> necessarily mandatory to use. >>>>>>>>>=20 >>>>>>>>> spt >>>>>>>>>=20 >>>>>>>>> On 2/13/12 7:11 PM, >>>>>> kathleen.moriarty@emc.com = wrote: >>>>>>>>>> Thank you for raising the interoperability testing as we need = to >>>>>>>>>> plan for a bake-off that once >>>>>>> these questions get answered and the draft is ready. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Kathleen >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mile-bounces@ietf.org >>>>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>>>>> To: mile@ietf.org >>>>>>>>>> Subject: [mile] MTI SCI? >>>>>>>>>>=20 >>>>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>>>>>> (mandatory to implement) choice? In other words, how will = you get >>>>>>>>>> two interoperability implementations without picking one? >>>>>>>>>>=20 >>>>>>>>>> spt >>>>>>>>>> _______________________________________________ >>>>>>>>>> mile mailing list >>>>>>>>>> mile@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> mile mailing list >>>>>>>>> mile@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>> . >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> = > = 03candidate_20120215.txt.pdf>_____________________________________________= __ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> . >>>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Thomas.Millar@us-cert.gov Wed Feb 15 07:34:34 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C121F85D2 for ; Wed, 15 Feb 2012 07:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, 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 YQfKrm-vOB7D for ; Wed, 15 Feb 2012 07:34:30 -0800 (PST) Received: from shaggy.brass.us-cert.gov (shaggy.brass.us-cert.gov [208.73.184.44]) by ietfa.amsl.com (Postfix) with ESMTP id 451EE21F85A7 for ; Wed, 15 Feb 2012 07:34:30 -0800 (PST) Received: from shaggy.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4C1E950636; Wed, 15 Feb 2012 15:34:29 +0000 (UTC) Received: from yabba.bronze.us-cert.gov (yabba.bronze.us-cert.gov [192.168.2.22]) by shaggy.brass.us-cert.gov (Postfix) with ESMTP id 3E2B450634; Wed, 15 Feb 2012 15:34:29 +0000 (UTC) Received: from needle.bronze.us-cert.gov (unknown [192.168.16.109]) by yabba.bronze.us-cert.gov (Postfix) with ESMTP id 06D9F3006A; Wed, 15 Feb 2012 15:34:28 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 09:34:28 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 15 Feb 2012 09:34:26 -0600 Message-ID: In-Reply-To: <399961E1-685C-4D29-988A-B8C0A8AE8B89@c3isecurity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) Thread-Index: Aczr8RzIQNgSFhgbSc6LN2MzQvniSQABdatQ References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp><4F3BA869.3010604@mitre.org><7C4DFCE962635144B8FAE8CA11D0BF1E05AD33A96E@MX14A.corp.emc.com> <399961E1-685C-4D29-988A-B8C0A8AE8B89@c3isecurity.com> From: To: , X-OriginalArrivalTime: 15 Feb 2012 15:34:28.0642 (UTC) FILETIME=[4E161020:01CCEBF7] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18710.007 X-TM-AS-Result: No--60.930-5.0-31-1 X-imss-scan-details: No--60.930-5.0-31-1 X-IMSS-DKIM-White-List: No Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:34:34 -0000 Agree and agree that an "EICAR" for CVE interop testing is reasonable. - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Wednesday, February 15, 2012 09:50 To: Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI = (wasRe: MTI SCI?) Agree - David also make a good point about having samples of what it = looks like. -ln On Feb 15, 2012, at 9:43 AM, = wrote: > Agree - I'd also like to see a CVE XML document suitable for testing, = or at least CVE enumeration values recommended for that purpose in an = Appendix. The rationale would be to provide implementers with data for = smoke tests that is clearly for testing only, and hence cannot be = confused with actual CVE data if it should escape the smoke test into = operational systems. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Martin, Robert A. >> Sent: Wednesday, February 15, 2012 7:43 AM >> To: Kent Landfield >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI = >> (was Re: MTI SCI?) >>=20 >> Agree >>=20 >> On 2/15/12 7:32 AM, Kent Landfield wrote: >>> I agree. >>>=20 >>> Kent Landfield >>> McAfee Labs >>> Kent_Landfield@McAfee.com >>> +1.817.637.8026 >>>=20 >>> On Feb 15, 2012, at 4:27 AM, Brian Trammell = wrote: >>>=20 >>>> Hi, Take, all, >>>>=20 >>>> Thank you for this edit/clarification. >>>>=20 >>>> On the first point, it does seem the discussion on the list=20 >>>> converged rather quickly to CVE as >> MTI. However, as this is a rather important point, I'd like to make = sure we didn't miss anything. >>>>=20 >>>> So, I'd like to call for consensus on the list. Does the working=20 >>>> group agree on the following two >> points? >>>>=20 >>>> 1. mile-sci requires one Mandatory to Implement schema in order to = ensure interoperability. >>>>=20 >>>> 2. The Mandatory to Implement schema is the Common Vulnerability=20 >>>> Enumeration (CVE) version 1.0, >> as described in section 4.1.7 of mile-sci-02. >>>>=20 >>>> Please note if you agree; if you disagree, please explain why not. >>>>=20 >>>> Best regards, >>>>=20 >>>> Brian (as chair) >>>>=20 >>>> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >>>>=20 >>>>> Hello all, >>>>>=20 >>>>> Following the discussion, I would like to add a couple of=20 >>>>> sentences to clarify the MTI issues. >>>>> (Thank you very much for those of you who kindly provided useful >>>>> discussion.) >>>>> I've attached the working version of the draft. I hope it helps to = >>>>> clarify the changes. >>>>>=20 >>>>> (added sentences at the end of section 4.1) >>>>>=20 >>>>> The SpecID attributes of extended classes (Section 4.3) must=20 >>>>> allow the values of the specifications' namespace fields, but=20 >>>>> otherwise, implementations are not required to support all the=20 >>>>> above specifications. Implementations may choose which=20 >>>>> specifications to support, though CVE 1.0 (Section 4.1.7) needs=20 >>>>> to be minimally supported. In case an implementation received a=20 >>>>> data it does not support, it may expand its functionality by=20 >>>>> looking up the IANA table or notify the sender of its inability=20 >>>>> to parse the data by using any means defined outside the scope of = this specification. >>>>>=20 >>>>> On the other hand, I would like to add "STRING ext-SpecID" to each = >>>>> class, which enables to embed data following private schema. >>>>> For instance, one security operation center (SOC) may wish to=20 >>>>> exchange a vulnerability data that is formatted in its own private = >>>>> schema, and that is not formatted in CVE. >>>>> In this case, the SOC may put the data's schema ID inside=20 >>>>> ext-SpecID and then embed the data. >>>>> It could also be used to exchange data using beta version of = specifications. >>>>>=20 >>>>> The class could be seen as below. >>>>>=20 >>>>> +------------------------+ >>>>> | AttackPattern | >>>>> +------------------------+ >>>>> | ENUM SpecID |<>--(0..*)-[ RawData ] >>>>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >>>>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] =20 >>>>> +------------------------+ >>>>>=20 >>>>> SpecID: REQUIRED. ENUM. The identifier of the specification >>>>> specifying the format of the RawData element. The value = should be >>>>> chosen from the namespaces [XMLNames] listed in Section 4.1 or >>>>> "private". Note that the lists in Section 4.1 will be = developed >>>>> further by IANA. The value "private" is prepared for conveying >>>>> RawData based on a format that is not listed in the >>>>> table. This is usually used for conveying data formatted >>>>> according to an organization's private schema. When the value >>>>> "private" is used, ext-SpecID element needs to be used. >>>>>=20 >>>>> ext-SpecID: OPTIONAL. STRING. The identifier of the = specification >>>>> specifying the format of the RawData element. When this = element >>>>> is used, the value of SpecID element must be "private." >>>>>=20 >>>>> I hope above changes don't cause any complication here. >>>>>=20 >>>>> Sincerely, >>>>> Take >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On=20 >>>>>> Behalf Of Martin, Robert A. >>>>>> Sent: Wednesday, February 15, 2012 1:50 AM >>>>>> To: Kent_Landfield@McAfee.com >>>>>> Cc: mile@ietf.org >>>>>> Subject: Re: [mile] MTI SCI? >>>>>>=20 >>>>>> At the risk of contradicting myself - but then again I have now=20 >>>>>> read the other replies to this issue - I agree that having one=20 >>>>>> area be the smoke test makes sense and I also agree that=20 >>>>>> something simple and commonly used already - like CVE - is the = best candidate for what we need. >>>>>>=20 >>>>>> Bob >>>>>>=20 >>>>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>>>>> CVE is widely used and understood by all in the the security = community. >>>>>> I agree with Tom that CVE is the path of least resistance but may = >>>>>> be the most useful for basic interoperability. >>>>>>>=20 >>>>>>> Kent Landfield >>>>>>> Director Content Strategy, Architecture and Standards >>>>>>>=20 >>>>>>> McAfee | An Intel Company >>>>>>> 5000 Headquarters Dr. >>>>>>> Plano, Texas 75024 >>>>>>>=20 >>>>>>> Direct: +1.972.963.7096 >>>>>>> Mobile: +1.817.637.8026 >>>>>>> Web: www.mcafee.com >>>>>>>=20 >>>>>>> From: >>>>>>>=20 >>>>>> "Thomas.Millar@us-cert.gov">>>>> mas >>>>>> .M >>>>>>> illar@us-cert.gov> >>>>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>>>>> To: >>>>>>>=20 >>>>>> "david.black@emc.com">>>>> .co >>>>>> m< >>>>>>> mailto:david.black@emc.com>>, Bob=20 >>>>>>> Martin> >>>>>>> Cc: >>>>>>>=20 >>>>>> "mile@ietf.org">>>>> etf >>>>>> .o >>>>>>> rg>> >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>=20 >>>>>>> My concern with CAPEC being mandatory is that it could=20 >>>>>>> discourage >>>>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary = >>>>>> remains "too comprehensive" for many CSIRTs to employ during=20 >>>>>> incident handling and reporting activity. >>>>>>>=20 >>>>>>> IODEF by itself has been criticized by CSIRT operators for being = >>>>>>> more >>>>>> heavyweight than necessary for day-to-day usage; making CAPEC a=20 >>>>>> mandatory aspect of "advanced IODEF" seems like it would be=20 >>>>>> adding ammunition to that argument, especially if the CSIRT is=20 >>>>>> having to fund implementation out of their own pocket.=20 >>>>>> Personally, I would have a hard time asking US-CERT's primary=20 >>>>>> constituents to implement IODEF + CAPEC if they are already=20 >>>>>> balking at the consultant and developer resources required to=20 >>>>>> implement RFC 5070 by itself. Also keep in mind that CAPEC = references CybOX, so there's wheels within wheels now. >>>>>>>=20 >>>>>>> I would prefer we take the path of least resistance (from my >>>>> perspective) >>>>>> and make CVE the MTI, if we have to pick one additional spec. >>>>>>> CVE is well known, has years of familiarity built in, and I=20 >>>>>>> think it's >>>>>> the simplest schema of the bunch. >>>>>>>=20 >>>>>>>=20 >>>>>>> - Tom Millar, US-CERT >>>>>>>=20 >>>>>>> thomas.millar@us-cert.gov >>>>>>> BB: thomas.millar@dhs.gov / >>>>>>> 202-631-1915 >>>>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org >>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of=20 >>>>>>> david.black@emc.com >>>>>>> Sent: Tuesday, February 14, 2012 11:14 >>>>>>> To: ramartin@mitre.org >>>>>>> Cc: mile@ietf.org >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>=20 >>>>>>> Hi Bob, >>>>>>>=20 >>>>>>> I do appreciate the concern about implementing things that=20 >>>>>>> aren't going >>>>>> to be used. OTOH, it may be useful to have a single simple MTI=20 >>>>>> spec for SCI that can be used to "smoke test" a deployment before = >>>>>> trying any >>>>> serious >>>>>> test data (and "simple" is important). >>>>>>>=20 >>>>>>> In addition, a concern that I would have with an MTI SCI spec=20 >>>>>>> per class >>>>>> is that if two SCI implementations don't have at least one class=20 >>>>>> in >>>>> common, >>>>>> they aren't going to interoperate, and that situation is unlikely = >>>>>> to be acceptable to the IESG (i.e., with an MTI SCI spec per=20 >>>>>> class, I suspect that there will also have to be an MTI class,=20 >>>>>> which results in an overall MTI SCI spec). >>>>>>>=20 >>>>>>> It may also be useful to include a simple example of the MTI SCI = >>>>>>> spec >>>>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI=20 >>>>>> spec is CAPEC, as Youki suggested, the appendix could contain a=20 >>>>>> CAPEC XML document for testing purposes, including enumeration=20 >>>>>> values suitable for testing). >>>>>>>=20 >>>>>>> What do you (and others) think about this? >>>>>>>=20 >>>>>>> Thanks, >>>>>>> --David >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>>>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>>>>> To: Brian Trammell >>>>>>> Cc: mile@ietf.org >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>> Brian, >>>>>>> You beat me to this point. Like you, I would be concerned about = >>>>>>> a MTI selection that ended up requiring someone to implement=20 >>>>>>> something to meet the MTI but wasn't germane to anything else=20 >>>>>>> they intended to >>>>>> support. >>>>>>> Bob >>>>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>>>>> Hi, Sean, all, >>>>>>>>=20 >>>>>>>> Looking over the spec, it's not clear to me that one MTI makes=20 >>>>>>>> sense here, given that mile-sci's >>>>>>> purpose is to reference a set of external specifications by=20 >>>>>>> inclusion in an IODEF document, and that those external=20 >>>>>>> specifications represent >>>>>> fundamentally different things. >>>>>>>>=20 >>>>>>>> The specifications are split over their applicability to the=20 >>>>>>>> IODEF extension classes. I could >>>>>>> envision an mile-sci implementation that was only interested a=20 >>>>>>> subset of these classes (perhaps even only one). If my=20 >>>>>>> implementation has an internal representation of Verification,=20 >>>>>>> but not of any of the other classes, and the MTI is an=20 >>>>>>> enumeration that is applicable to >>>>>> Vulnerability... what do I do? >>>>>>>>=20 >>>>>>>> What about selecting an MTI per class, instead? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Brian (as contributor) >>>>>>>>=20 >>>>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>>>>=20 >>>>>>>>> Great - as long as we pick one as the MTI. Note that MTI is=20 >>>>>>>>> not >>>>>> necessarily mandatory to use. >>>>>>>>>=20 >>>>>>>>> spt >>>>>>>>>=20 >>>>>>>>> On 2/13/12 7:11 PM, >>>>>> kathleen.moriarty@emc.com = wrote: >>>>>>>>>> Thank you for raising the interoperability testing as we need = >>>>>>>>>> to plan for a bake-off that once >>>>>>> these questions get answered and the draft is ready. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Kathleen >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mile-bounces@ietf.org >>>>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>>>>> To: mile@ietf.org >>>>>>>>>> Subject: [mile] MTI SCI? >>>>>>>>>>=20 >>>>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information)=20 >>>>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI=20 >>>>>>>>>> (mandatory to implement) choice? In other words, how will=20 >>>>>>>>>> you get two interoperability implementations without picking = one? >>>>>>>>>>=20 >>>>>>>>>> spt >>>>>>>>>> _______________________________________________ >>>>>>>>>> mile mailing list >>>>>>>>>> mile@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> mile mailing list >>>>>>>>> mile@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>> . >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>> - >> 03candidate_20120215.txt.pdf>________________________________________ >> _______ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> . >>>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From sbarnum@mitre.org Wed Feb 15 09:03:37 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6144421E8040 for ; Wed, 15 Feb 2012 09:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TRDsCCDLF2EG for ; Wed, 15 Feb 2012 09:03:33 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EF51021E807C for ; Wed, 15 Feb 2012 09:03:32 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8BDA021B17C9; Wed, 15 Feb 2012 12:03:27 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2D41021B088A; Wed, 15 Feb 2012 12:03:26 -0500 (EST) Received: from IMCMBX03.MITRE.ORG ([169.254.3.50]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Wed, 15 Feb 2012 12:03:25 -0500 From: "Barnum, Sean D." To: Brian Trammell , Takeshi Takahashi Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AQHM699tRJfO1ZgaoUWvMn69iNQr45Y+L5+A Date: Wed, 15 Feb 2012 17:03:23 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A90D7EAD@IMCMBX03.MITRE.ORG> References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0309_01CCEBD9.D1061890" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 17:03:37 -0000 ------=_NextPart_000_0309_01CCEBD9.D1061890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree. Sean -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] Sent: Wednesday, February 15, 2012 5:28 AM To: Takeshi Takahashi Cc: mile@ietf.org Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Hi, Take, all, Thank you for this edit/clarification. On the first point, it does seem the discussion on the list converged rather quickly to CVE as MTI. However, as this is a rather important point, I'd like to make sure we didn't miss anything. So, I'd like to call for consensus on the list. Does the working group agree on the following two points? 1. mile-sci requires one Mandatory to Implement schema in order to ensure interoperability. 2. The Mandatory to Implement schema is the Common Vulnerability Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile-sci-02. Please note if you agree; if you disagree, please explain why not. Best regards, Brian (as chair) On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > Hello all, > > Following the discussion, I would like to add a couple of sentences to > clarify the MTI issues. > (Thank you very much for those of you who kindly provided useful > discussion.) > I've attached the working version of the draft. I hope it helps to clarify > the changes. > > (added sentences at the end of section 4.1) > > The SpecID attributes of extended classes (Section 4.3) must allow > the values of the specifications' namespace fields, but otherwise, > implementations are not required to support all the above > specifications. Implementations may choose which specifications to > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > supported. In case an implementation received a data it does not > support, it may expand its functionality by looking up the IANA table or > notify the sender of its inability to parse the data by using any > means defined outside the scope of this specification. > > On the other hand, I would like to add "STRING ext-SpecID" to each class, > which enables to embed data following private schema. > For instance, one security operation center (SOC) may wish to exchange a > vulnerability data that is formatted in its own private schema, and that is > not formatted in CVE. > In this case, the SOC may put the data's schema ID inside ext-SpecID and > then embed the data. > It could also be used to exchange data using beta version of specifications. > > The class could be seen as below. > > +------------------------+ > | AttackPattern | > +------------------------+ > | ENUM SpecID |<>--(0..*)-[ RawData ] > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > +------------------------+ > > SpecID: REQUIRED. ENUM. The identifier of the specification > specifying the format of the RawData element. The value should be > chosen from the namespaces [XMLNames] listed in Section 4.1 or > "private". Note that the lists in Section 4.1 will be developed > further by IANA. The value "private" is prepared for conveying > RawData based on a format that is not listed in the > table. This is usually used for conveying data formatted > according to an organization's private schema. When the value > "private" is used, ext-SpecID element needs to be used. > > ext-SpecID: OPTIONAL. STRING. The identifier of the specification > specifying the format of the RawData element. When this element > is used, the value of SpecID element must be "private." > > I hope above changes don't cause any complication here. > > Sincerely, > Take > > > >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >> Martin, Robert A. >> Sent: Wednesday, February 15, 2012 1:50 AM >> To: Kent_Landfield@McAfee.com >> Cc: mile@ietf.org >> Subject: Re: [mile] MTI SCI? >> >> At the risk of contradicting myself - but then again I have now read the >> other replies to this issue - I agree that having one area be the smoke >> test makes sense and I also agree that something simple and commonly used >> already - like CVE - is the best candidate for what we need. >> >> Bob >> >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>> CVE is widely used and understood by all in the the security community. >> I agree with Tom that CVE is the path of least resistance but may be the >> most useful for basic interoperability. >>> >>> Kent Landfield >>> Director Content Strategy, Architecture and Standards >>> >>> McAfee | An Intel Company >>> 5000 Headquarters Dr. >>> Plano, Texas 75024 >>> >>> Direct: +1.972.963.7096 >>> Mobile: +1.817.637.8026 >>> Web: www.mcafee.com >>> >>> From: >>> >> "Thomas.Millar@us-cert.gov"> .M >>> illar@us-cert.gov> >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>> To: >>> >> "david.black@emc.com"> m< >>> mailto:david.black@emc.com>>, Bob >>> Martin> >>> Cc: >>> >> "mile@ietf.org"> .o >>> rg>> >>> Subject: Re: [mile] MTI SCI? >>> >>> My concern with CAPEC being mandatory is that it could discourage >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary remains >> "too comprehensive" for many CSIRTs to employ during incident handling >> and reporting activity. >>> >>> IODEF by itself has been criticized by CSIRT operators for being more >> heavyweight than necessary for day-to-day usage; making CAPEC a mandatory >> aspect of "advanced IODEF" seems like it would be adding ammunition to >> that argument, especially if the CSIRT is having to fund implementation >> out of their own pocket. Personally, I would have a hard time asking >> US-CERT's primary constituents to implement IODEF + CAPEC if they are >> already balking at the consultant and developer resources required to >> implement RFC 5070 by itself. Also keep in mind that CAPEC references >> CybOX, so there's wheels within wheels now. >>> >>> I would prefer we take the path of least resistance (from my > perspective) >> and make CVE the MTI, if we have to pick one additional spec. >>> CVE is well known, has years of familiarity built in, and I think it's >> the simplest schema of the bunch. >>> >>> >>> - Tom Millar, US-CERT >>> >>> thomas.millar@us-cert.gov >>> BB: thomas.millar@dhs.gov / >>> 202-631-1915 >>> 24x7: soc@us-cert.gov / 888-282-0870 >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org >>> [mailto:mile-bounces@ietf.org] On Behalf Of >>> david.black@emc.com >>> Sent: Tuesday, February 14, 2012 11:14 >>> To: ramartin@mitre.org >>> Cc: mile@ietf.org >>> Subject: Re: [mile] MTI SCI? >>> >>> Hi Bob, >>> >>> I do appreciate the concern about implementing things that aren't going >> to be used. OTOH, it may be useful to have a single simple MTI spec for >> SCI that can be used to "smoke test" a deployment before trying any > serious >> test data (and "simple" is important). >>> >>> In addition, a concern that I would have with an MTI SCI spec per class >> is that if two SCI implementations don't have at least one class in > common, >> they aren't going to interoperate, and that situation is unlikely to be >> acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect >> that there will also have to be an MTI class, which results in an overall >> MTI SCI spec). >>> >>> It may also be useful to include a simple example of the MTI SCI spec >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML >> document for testing purposes, including enumeration values suitable for >> testing). >>> >>> What do you (and others) think about this? >>> >>> Thanks, >>> --David >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>> Sent: Tuesday, February 14, 2012 8:26 AM >>> To: Brian Trammell >>> Cc: mile@ietf.org >>> Subject: Re: [mile] MTI SCI? >>> Brian, >>> You beat me to this point. Like you, I would be concerned about a MTI >>> selection that ended up requiring someone to implement something to >>> meet the MTI but wasn't germane to anything else they intended to >> support. >>> Bob >>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>> Hi, Sean, all, >>>> >>>> Looking over the spec, it's not clear to me that one MTI makes sense >>>> here, given that mile-sci's >>> purpose is to reference a set of external specifications by inclusion >>> in an IODEF document, and that those external specifications represent >> fundamentally different things. >>>> >>>> The specifications are split over their applicability to the IODEF >>>> extension classes. I could >>> envision an mile-sci implementation that was only interested a subset >>> of these classes (perhaps even only one). If my implementation has an >>> internal representation of Verification, but not of any of the other >>> classes, and the MTI is an enumeration that is applicable to >> Vulnerability... what do I do? >>>> >>>> What about selecting an MTI per class, instead? >>>> >>>> Best regards, >>>> >>>> Brian (as contributor) >>>> >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>> >>>>> Great - as long as we pick one as the MTI. Note that MTI is not >> necessarily mandatory to use. >>>>> >>>>> spt >>>>> >>>>> On 2/13/12 7:11 PM, >> kathleen.moriarty@emc.com wrote: >>>>>> Thank you for raising the interoperability testing as we need to >>>>>> plan for a bake-off that once >>> these questions get answered and the draft is ready. >>>>>> >>>>>> Thanks, >>>>>> Kathleen >>>>>> >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>> To: mile@ietf.org >>>>>> Subject: [mile] MTI SCI? >>>>>> >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>> (mandatory to implement) choice? In other words, how will you get >>>>>> two interoperability implementations without picking one? >>>>>> >>>>>> spt >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> . >>>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0309_01CCEBD9.D1061890 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKuDCCA2Qw ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8 A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB nQYdEpyz5tgh7Y2qMIIDZDCCAkygAwIBAgICWUowDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0xMTA3MTkxOTEzMjRaFw0xMjA2MDMxNzEzMjJa MFcxEjAQBgNVBAoMCW1pdHJlLm9yZzEPMA0GA1UECwwGUGVvcGxlMRcwFQYKCZImiZPyLGQBAQwH c2Jhcm51bTEXMBUGA1UEAwwOQmFybnVtIFNlYW4gRC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMAJwqoYzabLPa0hB6LMzgIVmgfXp/ZvEs1tXnlyiWI/Ac/pZqVfYLRZCB1ZtJ88sobfdBDs boIuJ/yxeBFKqGU5i7rgLFfJiCiu3pF2qmaZhsgL7JEpEllaFMSeEx+L3vCndY8nezzmFHWHz44j NMRxwbBoJ+bHNxuwlJXz0BtPAgMBAAGjgbcwgbQwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBR+ A4pJJ/uF9W8PON/fN9A7YJ0UzjAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNV HR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJl X29yZy5jcmwwHAYDVR0RBBUwE4ERc2Jhcm51bUBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEB AEFYXm77AcEZq93S4h64rNXmzos/Qhs3yVswkOqlwmqCKBcScFGdDKBrTedHU+A7dcQ+Dc3cguuu 03p+lsznLHqDT8HNo5vxQWQ3Db0At7plvK7MJhRXvWJbDTrNzy32vJbLKpAQZqMTe0JxRxBDCN6w eMhkid2Ag88Mw7pFIMGpFowKBExlliKfF2Z0Rs5+k1vD9PhnKvIlRHrlvSdpLAJaKcNNzBtORBKe EVRTMDeEBjrCYnc4zyhjxkxJzOzTcIh/RwZ4QMBN3XDzkbvkW9bO2tqPS1LDICnOk2MI3+RQhNTQ DZ1r7tKEpPtBhuBuYZ48Mn5AaxtqjAFhIzO5FkMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEB BQUAMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFPMXGG +iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2ING1 9aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhICfgmi O/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzztC+ww OTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBqmQID AQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSH tA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNV HR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9t aXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/p w3IAe7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoib qP/8WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82Ziy U680ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHc xWXtp3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh 7NqgMYIDAjCCAv4CAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgJZ SjAJBgUrDgMCGgUAoIIB9TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjAyMTUxNzAzMjNaMCMGCSqGSIb3DQEJBDEWBBSmPnGbYsbDd28MdO6a2YeFuKK4qzByBgkr BgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUg QXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAllKMHQG CyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgJZ SjCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcN AwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDAN BggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASBgHYy/EFSxDhbH/9YxoZBhhEFQHMFSPW/avvRFgspqxznZRCu L5OMy0BwP6UBW6Z8AAbcSMyP/9JgQJRgQ5ko30U+PDHLu/i/MZcZ8uNrvD+DbIISY4CWSIwUrDcQ mqGCJftuYc0oNisSKuw6k1LdHbRh7cM1HsXwTbVdWf8ACgipAAAAAAAA ------=_NextPart_000_0309_01CCEBD9.D1061890-- From kathleen.moriarty@emc.com Wed Feb 15 14:08:28 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828121E80A2 for ; Wed, 15 Feb 2012 14:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.908 X-Spam-Level: X-Spam-Status: No, score=-9.908 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, 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 Ur6tV52gssZe for ; Wed, 15 Feb 2012 14:08:27 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A859121E8032 for ; Wed, 15 Feb 2012 14:08:27 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FM8QPt018257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 17:08:26 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 15 Feb 2012 17:08:07 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FM877t024248; Wed, 15 Feb 2012 17:08:07 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Wed, 15 Feb 2012 17:08:06 -0500 From: To: , Date: Wed, 15 Feb 2012 17:08:05 -0500 Thread-Topic: review of draft-ietf-mile-template-00 Thread-Index: AczsLkrbHu06b9CdSiKQM20cr7yBCg== Message-ID: 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-EMM-MHVC: 1 Subject: [mile] review of draft-ietf-mile-template-00 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:08:28 -0000 Hi Brian, The document looks like it is close, I have some editorial recommendations: Title: Since the extensions can apply to IODEF or a lightweight IODEF yet-= to-be defined, the title and abstract should reflect that capability. The = title and abstract read as if IODEF is lightweight and the extensions will = be lightweight, which is not necessarily the case. The WG has not begun work on the charter objective to provide IODEF guidanc= e for making IODEF lightweight or deciding what that means. The template e= xtension should apply to both use cases as IODEF could be big complex docum= ents right now (and later where appropriate) or lightweight with the curren= t model or through the guidance or a reduced schema. As such, removing ref= erences to MILE would be helpful as the WG name will go away at some point = in time and we will be left with draft and specification names. Introduction: Can you reword the first sentence? It is very long and a lit= tle tough to follow. Is it accurate? I think we are defining IODEF guidan= ce somewhere else? 2nd paragraph, recommend rewording the first sentence from: "Additionally, IODEF extensions via class extension through AdditionalData and RecordItem elements, a" TO: "Additionally, IODEF extensions through the AdditionalData and RecordItem elements nested in the extensible IODEF cl= asses, a" Section 2, #2, last line: Recommend changing from: "then extension is not necessary." T: "then the extension is not necessary." The next line, the word includes should be include (refers to a single list= ). "A non-exhaustive list of good candidate extensions to IODEF includes:" #1 in the list, can you reword this and possibly make it two sentences? I = think it would be easier to read. Security considerations: I don't think you need MILE in this description. The extensions are to IOD= EF and then to a lightweight version of IODEF that may be another specifica= tion or a guidance document, but we have not done that yet. A.4: References MILE extension documents, this should reference IODEF exten= sion documents. A.6: I think this should match IODEF's security considerations as these co= ncerns described are addressed in the transport documents. IODEF also poin= ts out that the formats are for exchanges and not storage. Storage securit= y considerations about the data inside the formats should be out-of-scope. = If extension authors try to cover that content, they won't be able to get = right as the tools used for storage will be different and implementers shou= ld refer to the appropriate specifications. Thank you! Kathleen From kathleen.moriarty@emc.com Wed Feb 15 14:36:06 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E822A21E80C3 for ; Wed, 15 Feb 2012 14:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, 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 TCMY-8kJCX1w for ; Wed, 15 Feb 2012 14:36:05 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 30D9621E8084 for ; Wed, 15 Feb 2012 14:36:04 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FMa43J010074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Feb 2012 17:36:04 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Wed, 15 Feb 2012 17:35:51 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FMZp99022954 for ; Wed, 15 Feb 2012 17:35:51 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Wed, 15 Feb 2012 17:35:02 -0500 From: To: Date: Wed, 15 Feb 2012 17:35:50 -0500 Thread-Topic: WGLC for draft-ietf-mile-template-00 is closed Thread-Index: AczsMisZONqCG66qQnuaKx6yyi168g== Message-ID: 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-EMM-MHVC: 1 Subject: [mile] WGLC for draft-ietf-mile-template-00 is closed X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:36:06 -0000 Hello, Thank you to all WG participants who took the time to review draft-ietf-mil= e-template-00. The Working Group Last Call (WGLC) for this document is now= closed. Brian, when you are ready, please post a revision of the draft. Thank you, Kathleen (WG Chair) Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-58= 07 | Kathleen.Moriarty@emc.com | EMC Corporation From trammell@tik.ee.ethz.ch Thu Feb 16 00:59:35 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BF521F86F5 for ; Thu, 16 Feb 2012 00:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JPBgY+I-P7zn for ; Thu, 16 Feb 2012 00:59:34 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CFBA721F86F4 for ; Thu, 16 Feb 2012 00:59:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5C9FCD930A; Thu, 16 Feb 2012 09:59:31 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xtt2EXh38-gY; Thu, 16 Feb 2012 09:59:31 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 19719D9300; Thu, 16 Feb 2012 09:59:31 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Thu, 16 Feb 2012 09:59:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] review of draft-ietf-mile-template-00 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:59:35 -0000 Hi, Kathleen, Thanks for the review. I've incorporated all of these into -01; specific = comments thereon inline. As WGLC is closed, I will post the -01 revision shortly. On Feb 15, 2012, at 11:08 PM, = wrote: > Hi Brian, >=20 > The document looks like it is close, I have some editorial = recommendations: >=20 > Title: Since the extensions can apply to IODEF or a lightweight IODEF = yet-to-be defined, the title and abstract should reflect that = capability. The title and abstract read as if IODEF is lightweight and = the extensions will be lightweight, which is not necessarily the case. >=20 > The WG has not begun work on the charter objective to provide IODEF = guidance for making IODEF lightweight or deciding what that means. The = template extension should apply to both use cases as IODEF could be big = complex documents right now (and later where appropriate) or lightweight = with the current model or through the guidance or a reduced schema. As = such, removing references to MILE would be helpful as the WG name will = go away at some point in time and we will be left with draft and = specification names. >=20 > Introduction: Can you reword the first sentence? It is very long and = a little tough to follow. Is it accurate? I think we are defining = IODEF guidance somewhere else? Split in three; now: In the five years since the specification of IODEF=20 [RFC5070], the threat environment has evolved, as has the practice of cooperative network defense. These trends, along = with experience gained through implementation and deployment, have = indicated the need to extend IODEF. This document provides guidelines for = defining these=20 extensions... > #1 in the list, can you reword this and possibly make it two = sentences? I think it would be easier to read. These are aspects of the same concept. I've shuffled it a bit, though: 1. Leveraging existing work in describing aspects of incidents=20 to make IODEF more expressive, by standardized reference to=20 external information bases about incidents and incident-related information > Security considerations: > I don't think you need MILE in this description. The extensions are = to IODEF and then to a lightweight version of IODEF that may be another = specification or a guidance document, but we have not done that yet. >=20 > A.4: References MILE extension documents, this should reference IODEF = extension documents. Good point. Indeed, I've also changed the footer title to "IODEF = extension guidelines". > A.6: I think this should match IODEF's security considerations as = these concerns described are addressed in the transport documents. = IODEF also points out that the formats are for exchanges and not = storage. Storage security considerations about the data inside the = formats should be out-of-scope. If extension authors try to cover that = content, they won't be able to get right as the tools used for storage = will be different and implementers should refer to the appropriate = specifications. I've referenced security considerations on 5070 already on a previous = comment; I'll also remove the reference to storage. Best regards, Brian (author hat) From internet-drafts@ietf.org Thu Feb 16 01:38:29 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C31721F8585; Thu, 16 Feb 2012 01:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 RTqJ04ic+wxF; Thu, 16 Feb 2012 01:38:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9021F8593; Thu, 16 Feb 2012 01:38:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120216093824.11585.56658.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2012 01:38:24 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-template-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:38:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange= Working Group of the IETF. Title : Guidelines for Extensions to IODEF for Managed Incident = Lightweight Exchange Author(s) : Brian Trammell Filename : draft-ietf-mile-template-01.txt Pages : 13 Date : 2012-02-16 This document provides guidelines for extensions to IODEF [RFC5070] for exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. It also specifies additional Expert Review of XML Schemas used to describe these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-template-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-template-01.txt From trammell@tik.ee.ethz.ch Thu Feb 16 01:54:41 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A7721F85C9 for ; Thu, 16 Feb 2012 01:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DFh8MGDQzZXd for ; Thu, 16 Feb 2012 01:54:40 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE921F85C5 for ; Thu, 16 Feb 2012 01:54:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1022CD930A for ; Thu, 16 Feb 2012 10:54:40 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vD1Pv+mlHphB for ; Thu, 16 Feb 2012 10:54:39 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CB270D9308 for ; Thu, 16 Feb 2012 10:54:39 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2012 10:54:39 +0100 References: <20120216093825.11585.93023.idtracker@ietfa.amsl.com> To: mile@ietf.org Message-Id: <4A345B53-9D07-4BF2-B794-FF187A107002@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mile] Fwd: New Version Notification for draft-ietf-mile-template-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:54:41 -0000 Greetings, all, I've submitted mile-template-01, which addresses all WGLC comments = received. Thanks again, all, for your reviews. The document is (IMO) = ready to send up to the IESG. Best regards,=20 Brian (as author of mile-template) Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 16, 2012 10:38:25 AM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: trammell@tik.ee.ethz.ch > Subject: New Version Notification for draft-ietf-mile-template-01.txt >=20 > A new version of I-D, draft-ietf-mile-template-01.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-ietf-mile-template > Revision: 01 > Title: Guidelines for Extensions to IODEF for Managed = Incident Lightweight Exchange > Creation date: 2012-02-16 > WG ID: mile > Number of pages: 13 >=20 > Abstract: > This document provides guidelines for extensions to IODEF [RFC5070] > for exchange of incident management data, and contains a template = for > Internet-Drafts describing those extensions, in order to ease the > work and improve the quality of extension descriptions. It also > specifies additional Expert Review of XML Schemas used to describe > these extensions. >=20 >=20 >=20 >=20 > The IETF Secretariat From kathleen.moriarty@emc.com Thu Feb 16 07:34:38 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C6621F8657 for ; Thu, 16 Feb 2012 07:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.933 X-Spam-Level: X-Spam-Status: No, score=-9.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, 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 7nSD8YLgWPEt for ; Thu, 16 Feb 2012 07:34:34 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 52F3321F860B for ; Thu, 16 Feb 2012 07:34:33 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1GFYWvS007699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 10:34:33 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 16 Feb 2012 10:34:06 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1GFY5Tn030910; Thu, 16 Feb 2012 10:34:05 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 16 Feb 2012 10:34:05 -0500 From: To: , Date: Thu, 16 Feb 2012 10:34:03 -0500 Thread-Topic: [mile] Fwd: New Version Notification for draft-ietf-mile-template-01.txt Thread-Index: Aczsk8OmRAMmTXzqRoi7akcNcN37JAAKjkFg Message-ID: References: <20120216093825.11585.93023.idtracker@ietfa.amsl.com> <4A345B53-9D07-4BF2-B794-FF187A107002@tik.ee.ethz.ch> In-Reply-To: <4A345B53-9D07-4BF2-B794-FF187A107002@tik.ee.ethz.ch> 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-EMM-MHVC: 1 Subject: Re: [mile] Fwd: New Version Notification for draft-ietf-mile-template-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:34:38 -0000 Hello, The updated document addresses all questions raised during WGLC, with the e= xception of the title, and is ready for the next step in the process (IESG)= . =20 The document title is the only remaining item and it will be changed in the= next revision to drop the last 5 words (the Managed Incident Lightweight E= xchange), leaving the title as "Guidelines for Extensions to IODEF". Thank you, Kathleen (WG Chair) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Thursday, February 16, 2012 4:55 AM To: mile@ietf.org Subject: [mile] Fwd: New Version Notification for draft-ietf-mile-template-= 01.txt Greetings, all, I've submitted mile-template-01, which addresses all WGLC comments received= . Thanks again, all, for your reviews. The document is (IMO) ready to send = up to the IESG. Best regards,=20 Brian (as author of mile-template) Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 16, 2012 10:38:25 AM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: trammell@tik.ee.ethz.ch > Subject: New Version Notification for draft-ietf-mile-template-01.txt >=20 > A new version of I-D, draft-ietf-mile-template-01.txt has been successful= ly submitted by Brian Trammell and posted to the IETF repository. >=20 > Filename: draft-ietf-mile-template > Revision: 01 > Title: Guidelines for Extensions to IODEF for Managed Incident Lightwei= ght Exchange > Creation date: 2012-02-16 > WG ID: mile > Number of pages: 13 >=20 > Abstract: > This document provides guidelines for extensions to IODEF [RFC5070] > for exchange of incident management data, and contains a template for > Internet-Drafts describing those extensions, in order to ease the > work and improve the quality of extension descriptions. It also > specifies additional Expert Review of XML Schemas used to describe > these extensions. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Thu Feb 16 11:25:03 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0A21F87DE for ; Thu, 16 Feb 2012 11:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.941 X-Spam-Level: X-Spam-Status: No, score=-9.941 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, 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 C+MWe0x+EaTs for ; Thu, 16 Feb 2012 11:24:54 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47E21F87A1 for ; Thu, 16 Feb 2012 11:24:54 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1GJOfcp010049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 14:24:47 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 16 Feb 2012 14:24:24 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1GJOOhE004141; Thu, 16 Feb 2012 14:24:24 -0500 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub30.corp.emc.com (128.222.70.170) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 14:23:31 -0500 Received: from mx06a.corp.emc.com ([169.254.1.250]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Thu, 16 Feb 2012 14:24:23 -0500 From: To: , , Date: Thu, 16 Feb 2012 14:24:22 -0500 Thread-Topic: [mile] Fwd: New Version Notification for draft-ietf-mile-template-01.txt Thread-Index: Aczsk8OmRAMmTXzqRoi7akcNcN37JAAKjkFgAAiOKTA= Message-ID: References: <20120216093825.11585.93023.idtracker@ietfa.amsl.com> <4A345B53-9D07-4BF2-B794-FF187A107002@tik.ee.ethz.ch> 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-EMM-MHVC: 1 Subject: Re: [mile] Fwd: New Version Notification for draft-ietf-mile-template-01.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:25:03 -0000 Brian, In going through the document shepherd write-up, I noticed a few things tha= t should get addressed before we pass the document to the IESG. Can you fi= x the outdated informational references and include the RFC2119 boilerplate= text? There are some RFC2119 terms used in section 3 of the main part of = the document, so the terminology section should be included. Once you have that ready with the title change, we can wrap this up. Sorry= I didn't catch this earlier. Thank you, Kathleen (WG Chair) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Thursday, February 16, 2012 10:34 AM To: trammell@tik.ee.ethz.ch; mile@ietf.org Subject: Re: [mile] Fwd: New Version Notification for draft-ietf-mile-templ= ate-01.txt Hello, The updated document addresses all questions raised during WGLC, with the e= xception of the title, and is ready for the next step in the process (IESG)= . =20 The document title is the only remaining item and it will be changed in the= next revision to drop the last 5 words (the Managed Incident Lightweight E= xchange), leaving the title as "Guidelines for Extensions to IODEF". Thank you, Kathleen (WG Chair) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Thursday, February 16, 2012 4:55 AM To: mile@ietf.org Subject: [mile] Fwd: New Version Notification for draft-ietf-mile-template-= 01.txt Greetings, all, I've submitted mile-template-01, which addresses all WGLC comments received= . Thanks again, all, for your reviews. The document is (IMO) ready to send = up to the IESG. Best regards,=20 Brian (as author of mile-template) Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 16, 2012 10:38:25 AM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: trammell@tik.ee.ethz.ch > Subject: New Version Notification for draft-ietf-mile-template-01.txt >=20 > A new version of I-D, draft-ietf-mile-template-01.txt has been successful= ly submitted by Brian Trammell and posted to the IETF repository. >=20 > Filename: draft-ietf-mile-template > Revision: 01 > Title: Guidelines for Extensions to IODEF for Managed Incident Lightwei= ght Exchange > Creation date: 2012-02-16 > WG ID: mile > Number of pages: 13 >=20 > Abstract: > This document provides guidelines for extensions to IODEF [RFC5070] > for exchange of incident management data, and contains a template for > Internet-Drafts describing those extensions, in order to ease the > work and improve the quality of extension descriptions. It also > specifies additional Expert Review of XML Schemas used to describe > these extensions. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.waltermire@nist.gov Thu Feb 16 14:26:23 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA7F21E80A9 for ; Thu, 16 Feb 2012 14:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tUG2eA6GugoU for ; Thu, 16 Feb 2012 14:26:13 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2521E80A7 for ; Thu, 16 Feb 2012 14:26:12 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 17:25:53 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 16 Feb 2012 17:26:11 -0500 From: "Waltermire, David A." To: Brian Trammell , Takeshi Takahashi Date: Thu, 16 Feb 2012 17:26:10 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AczrzDOx+UzUfup8TqGaleJkelzyYgBKnXqQ Message-ID: References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> 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" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:26:24 -0000 I have not been following this thread as closely as I probably should. Relative to MTI, is the question what schema should be MTI for the vulerability class? In general I think we should have one or more MTI for each class. Relative to CVE specifically, are we talking about the schema currently located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd? This seems to match the namespace defined in section 4.1.7 of mile-sci-02. Looking at the implementation of this schema, it looks like the targetNamespace is incorrectly assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be fixed. Also, the specification URI points to the CVE website, which is not really a specification. It's not clear where to find guidance on how to properly use the model indicated by the namespace. Without having clear guidance on its use I don't see how we can make it MTI, even if it is considered a de facto approach. It might make sense to produce a specification for the model before making it MTI for the vulnerability class. Sincerely, David Waltermire > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Wednesday, February 15, 2012 5:28 AM > To: Takeshi Takahashi > Cc: mile@ietf.org > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was > Re: MTI SCI?) > > Hi, Take, all, > > Thank you for this edit/clarification. > > On the first point, it does seem the discussion on the list converged > rather quickly to CVE as MTI. However, as this is a rather important > point, I'd like to make sure we didn't miss anything. > > So, I'd like to call for consensus on the list. Does the working group > agree on the following two points? > > 1. mile-sci requires one Mandatory to Implement schema in order to > ensure interoperability. > > 2. The Mandatory to Implement schema is the Common Vulnerability > Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- > sci-02. > > Please note if you agree; if you disagree, please explain why not. > > Best regards, > > Brian (as chair) > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > Hello all, > > > > Following the discussion, I would like to add a couple of sentences > to > > clarify the MTI issues. > > (Thank you very much for those of you who kindly provided useful > > discussion.) > > I've attached the working version of the draft. I hope it helps to > > clarify the changes. > > > > (added sentences at the end of section 4.1) > > > > The SpecID attributes of extended classes (Section 4.3) must allow > > the values of the specifications' namespace fields, but otherwise, > > implementations are not required to support all the above > > specifications. Implementations may choose which specifications to > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > supported. In case an implementation received a data it does not > > support, it may expand its functionality by looking up the IANA > table or > > notify the sender of its inability to parse the data by using any > > means defined outside the scope of this specification. > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > class, which enables to embed data following private schema. > > For instance, one security operation center (SOC) may wish to > exchange > > a vulnerability data that is formatted in its own private schema, and > > that is not formatted in CVE. > > In this case, the SOC may put the data's schema ID inside ext-SpecID > > and then embed the data. > > It could also be used to exchange data using beta version of > specifications. > > > > The class could be seen as below. > > > > +------------------------+ > > | AttackPattern | > > +------------------------+ > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > +------------------------+ > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > specifying the format of the RawData element. The value should > be > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > "private". Note that the lists in Section 4.1 will be developed > > further by IANA. The value "private" is prepared for conveying > > RawData based on a format that is not listed in the > > table. This is usually used for conveying data formatted > > according to an organization's private schema. When the value > > "private" is used, ext-SpecID element needs to be used. > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > specification > > specifying the format of the RawData element. When this element > > is used, the value of SpecID element must be "private." > > > > I hope above changes don't cause any complication here. > > > > Sincerely, > > Take > > > > > > > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > >> Of Martin, Robert A. > >> Sent: Wednesday, February 15, 2012 1:50 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] MTI SCI? > >> > >> At the risk of contradicting myself - but then again I have now read > >> the other replies to this issue - I agree that having one area be > the > >> smoke test makes sense and I also agree that something simple and > >> commonly used already - like CVE - is the best candidate for what we > need. > >> > >> Bob > >> > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > >>> CVE is widely used and understood by all in the the security > community. > >> I agree with Tom that CVE is the path of least resistance but may be > >> the most useful for basic interoperability. > >>> > >>> Kent Landfield > >>> Director Content Strategy, Architecture and Standards > >>> > >>> McAfee | An Intel Company > >>> 5000 Headquarters Dr. > >>> Plano, Texas 75024 > >>> > >>> Direct: +1.972.963.7096 > >>> Mobile: +1.817.637.8026 > >>> Web: www.mcafee.com > >>> > >>> From: > >>> > >> "Thomas.Millar@us-cert.gov" >> .M > >>> illar@us-cert.gov> > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > >>> To: > >>> > >> "david.black@emc.com" >> m< > >>> mailto:david.black@emc.com>>, Bob > >>> Martin> > >>> Cc: > >>> > >> "mile@ietf.org" >> .o > >>> rg>> > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> My concern with CAPEC being mandatory is that it could discourage > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > >> remains "too comprehensive" for many CSIRTs to employ during > incident > >> handling and reporting activity. > >>> > >>> IODEF by itself has been criticized by CSIRT operators for being > >>> more > >> heavyweight than necessary for day-to-day usage; making CAPEC a > >> mandatory aspect of "advanced IODEF" seems like it would be adding > >> ammunition to that argument, especially if the CSIRT is having to > >> fund implementation out of their own pocket. Personally, I would > have > >> a hard time asking US-CERT's primary constituents to implement IODEF > >> + CAPEC if they are already balking at the consultant and developer > >> resources required to implement RFC 5070 by itself. Also keep in > mind > >> that CAPEC references CybOX, so there's wheels within wheels now. > >>> > >>> I would prefer we take the path of least resistance (from my > > perspective) > >> and make CVE the MTI, if we have to pick one additional spec. > >>> CVE is well known, has years of familiarity built in, and I think > >>> it's > >> the simplest schema of the bunch. > >>> > >>> > >>> - Tom Millar, US-CERT > >>> > >>> thomas.millar@us-cert.gov > >>> BB: thomas.millar@dhs.gov / > >>> 202-631-1915 > >>> 24x7: soc@us-cert.gov / 888-282-0870 > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > >>> david.black@emc.com > >>> Sent: Tuesday, February 14, 2012 11:14 > >>> To: ramartin@mitre.org > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> Hi Bob, > >>> > >>> I do appreciate the concern about implementing things that aren't > >>> going > >> to be used. OTOH, it may be useful to have a single simple MTI spec > >> for SCI that can be used to "smoke test" a deployment before trying > >> any > > serious > >> test data (and "simple" is important). > >>> > >>> In addition, a concern that I would have with an MTI SCI spec per > >>> class > >> is that if two SCI implementations don't have at least one class in > > common, > >> they aren't going to interoperate, and that situation is unlikely to > >> be acceptable to the IESG (i.e., with an MTI SCI spec per class, I > >> suspect that there will also have to be an MTI class, which results > >> in an overall MTI SCI spec). > >>> > >>> It may also be useful to include a simple example of the MTI SCI > >>> spec > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > spec > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML > >> document for testing purposes, including enumeration values suitable > >> for testing). > >>> > >>> What do you (and others) think about this? > >>> > >>> Thanks, > >>> --David > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > >>> Sent: Tuesday, February 14, 2012 8:26 AM > >>> To: Brian Trammell > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> Brian, > >>> You beat me to this point. Like you, I would be concerned about a > >>> MTI selection that ended up requiring someone to implement > something > >>> to meet the MTI but wasn't germane to anything else they intended > to > >> support. > >>> Bob > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > >>>> Hi, Sean, all, > >>>> > >>>> Looking over the spec, it's not clear to me that one MTI makes > >>>> sense here, given that mile-sci's > >>> purpose is to reference a set of external specifications by > >>> inclusion in an IODEF document, and that those external > >>> specifications represent > >> fundamentally different things. > >>>> > >>>> The specifications are split over their applicability to the IODEF > >>>> extension classes. I could > >>> envision an mile-sci implementation that was only interested a > >>> subset of these classes (perhaps even only one). If my > >>> implementation has an internal representation of Verification, but > >>> not of any of the other classes, and the MTI is an enumeration that > >>> is applicable to > >> Vulnerability... what do I do? > >>>> > >>>> What about selecting an MTI per class, instead? > >>>> > >>>> Best regards, > >>>> > >>>> Brian (as contributor) > >>>> > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >>>> > >>>>> Great - as long as we pick one as the MTI. Note that MTI is not > >> necessarily mandatory to use. > >>>>> > >>>>> spt > >>>>> > >>>>> On 2/13/12 7:11 PM, > >> kathleen.moriarty@emc.com wrote: > >>>>>> Thank you for raising the interoperability testing as we need to > >>>>>> plan for a bake-off that once > >>> these questions get answered and the draft is ready. > >>>>>> > >>>>>> Thanks, > >>>>>> Kathleen > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: mile-bounces@ietf.org > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > >>>>>> To: mile@ietf.org > >>>>>> Subject: [mile] MTI SCI? > >>>>>> > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > >>>>>> (mandatory to implement) choice? In other words, how will you > >>>>>> get two interoperability implementations without picking one? > >>>>>> > >>>>>> spt > >>>>>> _______________________________________________ > >>>>>> mile mailing list > >>>>>> mile@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> mile mailing list > >>>>> mile@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>>> . > >>>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > 03c > > > andidate_20120215.txt.pdf>____________________________________________ > > ___ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From internet-drafts@ietf.org Fri Feb 17 03:39:16 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6517621F87B7; Fri, 17 Feb 2012 03:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 nhYHMkZUObII; Fri, 17 Feb 2012 03:39:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8674E21F87AF; Fri, 17 Feb 2012 03:39:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120217113913.32118.21860.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2012 03:39:13 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-template-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:39:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange= Working Group of the IETF. Title : Guidelines for Defining Extensions to IODEF Author(s) : Brian Trammell Filename : draft-ietf-mile-template-02.txt Pages : 13 Date : 2012-02-17 This document provides guidelines for extensions to IODEF [RFC5070] for exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. It also specifies additional Expert Review of XML Schemas used to describe these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-template-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-template-02.txt From trammell@tik.ee.ethz.ch Fri Feb 17 03:42:33 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311BB21F87AF for ; Fri, 17 Feb 2012 03:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ivnJnUtmJygL for ; Fri, 17 Feb 2012 03:42:32 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1921F87EA for ; Fri, 17 Feb 2012 03:42:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B0368D930B for ; Fri, 17 Feb 2012 12:42:17 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TkfxsIL2Fxee for ; Fri, 17 Feb 2012 12:42:17 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 72099D9300 for ; Fri, 17 Feb 2012 12:42:17 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2012 12:42:17 +0100 References: <20120217113916.32118.99748.idtracker@ietfa.amsl.com> To: "" Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [mile] Fwd: New Version Notification for draft-ietf-mile-template-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:42:33 -0000 Greetings, all, I've submitted a -02 revision of this document to address issues = discovered during the shepherd review (missing 2119 reference, outdated = informative references taken from 5070) and to change the title to make = it more descriptive. Best regards, Brian (as mile-template author) Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-mile-template-02.txt > Date: February 17, 2012 12:39:16 PM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: trammell@tik.ee.ethz.ch >=20 > A new version of I-D, draft-ietf-mile-template-02.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-ietf-mile-template > Revision: 02 > Title: Guidelines for Defining Extensions to IODEF > Creation date: 2012-02-17 > WG ID: mile > Number of pages: 13 >=20 > Abstract: > This document provides guidelines for extensions to IODEF [RFC5070] > for exchange of incident management data, and contains a template = for > Internet-Drafts describing those extensions, in order to ease the > work and improve the quality of extension descriptions. It also > specifies additional Expert Review of XML Schemas used to describe > these extensions. >=20 >=20 >=20 >=20 > The IETF Secretariat From kathleen.moriarty@emc.com Mon Feb 20 03:08:34 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FDC21F8767 for ; Mon, 20 Feb 2012 03:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.964 X-Spam-Level: X-Spam-Status: No, score=-9.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, 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 WkfjfPM04ACs for ; Mon, 20 Feb 2012 03:08:30 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D7F1F21F873E for ; Mon, 20 Feb 2012 03:08:29 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1KB8R7L006149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 06:08:28 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 20 Feb 2012 06:08:06 -0500 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1KB80al026980; Mon, 20 Feb 2012 06:08:03 -0500 Received: from mx06a.corp.emc.com ([169.254.1.82]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Mon, 20 Feb 2012 06:08:00 -0500 From: To: , , Date: Mon, 20 Feb 2012 06:08:00 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AczrzDOx+UzUfup8TqGaleJkelzyYgBKnXqQALGDu2U= Message-ID: References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> , 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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:08:34 -0000 Thank you, Dave. Dave raises a few very important points as we consider MTI for SCI. We wil= l need to resolve these issues if CVE is to be the (or an) MTI specificatio= n for the SCI draft. If CVE is mandatory to implement, what guidance would be followed on how to= use the model or will MTI only mean that the document can be received and = parsed? The CVE website is listed as the specification URI, but from Dave= 's message, the specification URI does not exist to provide the guidance (I= get to broken link pages for both - the existing and suggested replacement= link). This is the closest I could find and may be the answer for guidance: http:/= /cve.mitre.org/compatible/requirements.html It looks like the reference to the target namespace needs to be fixed as we= ll. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Waltermire= , David A. [david.waltermire@nist.gov] Sent: Thursday, February 16, 2012 5:26 PM To: Brian Trammell; Takeshi Takahashi Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was = Re: MTI SCI?) I have not been following this thread as closely as I probably should. Rel= ative to MTI, is the question what schema should be MTI for the vulerabilit= y class? In general I think we should have one or more MTI for each class. Relative to CVE specifically, are we talking about the schema currently loc= ated at: http://cve.mitre.org/schema/cve/cve_1.0.xsd? This seems to match the namespace defined in section 4.1.7 of mile-sci-02. = Looking at the implementation of this schema, it looks like the targetName= space is incorrectly assigned to "http://cve.mitre.org/cve/downloads/xml_sc= hema_info.html" when it should be "http://cve.mitre.org/cve/downloads/1.0".= This will likely need to be fixed. Also, the specification URI points to the CVE website, which is not really = a specification. It's not clear where to find guidance on how to properly = use the model indicated by the namespace. Without having clear guidance on= its use I don't see how we can make it MTI, even if it is considered a de = facto approach. It might make sense to produce a specification for the mod= el before making it MTI for the vulnerability class. Sincerely, David Waltermire > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Wednesday, February 15, 2012 5:28 AM > To: Takeshi Takahashi > Cc: mile@ietf.org > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was > Re: MTI SCI?) > > Hi, Take, all, > > Thank you for this edit/clarification. > > On the first point, it does seem the discussion on the list converged > rather quickly to CVE as MTI. However, as this is a rather important > point, I'd like to make sure we didn't miss anything. > > So, I'd like to call for consensus on the list. Does the working group > agree on the following two points? > > 1. mile-sci requires one Mandatory to Implement schema in order to > ensure interoperability. > > 2. The Mandatory to Implement schema is the Common Vulnerability > Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- > sci-02. > > Please note if you agree; if you disagree, please explain why not. > > Best regards, > > Brian (as chair) > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > Hello all, > > > > Following the discussion, I would like to add a couple of sentences > to > > clarify the MTI issues. > > (Thank you very much for those of you who kindly provided useful > > discussion.) > > I've attached the working version of the draft. I hope it helps to > > clarify the changes. > > > > (added sentences at the end of section 4.1) > > > > The SpecID attributes of extended classes (Section 4.3) must allow > > the values of the specifications' namespace fields, but otherwise, > > implementations are not required to support all the above > > specifications. Implementations may choose which specifications to > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > supported. In case an implementation received a data it does not > > support, it may expand its functionality by looking up the IANA > table or > > notify the sender of its inability to parse the data by using any > > means defined outside the scope of this specification. > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > class, which enables to embed data following private schema. > > For instance, one security operation center (SOC) may wish to > exchange > > a vulnerability data that is formatted in its own private schema, and > > that is not formatted in CVE. > > In this case, the SOC may put the data's schema ID inside ext-SpecID > > and then embed the data. > > It could also be used to exchange data using beta version of > specifications. > > > > The class could be seen as below. > > > > +------------------------+ > > | AttackPattern | > > +------------------------+ > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > +------------------------+ > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > specifying the format of the RawData element. The value should > be > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > "private". Note that the lists in Section 4.1 will be developed > > further by IANA. The value "private" is prepared for conveying > > RawData based on a format that is not listed in the > > table. This is usually used for conveying data formatted > > according to an organization's private schema. When the value > > "private" is used, ext-SpecID element needs to be used. > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > specification > > specifying the format of the RawData element. When this element > > is used, the value of SpecID element must be "private." > > > > I hope above changes don't cause any complication here. > > > > Sincerely, > > Take > > > > > > > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > >> Of Martin, Robert A. > >> Sent: Wednesday, February 15, 2012 1:50 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] MTI SCI? > >> > >> At the risk of contradicting myself - but then again I have now read > >> the other replies to this issue - I agree that having one area be > the > >> smoke test makes sense and I also agree that something simple and > >> commonly used already - like CVE - is the best candidate for what we > need. > >> > >> Bob > >> > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > >>> CVE is widely used and understood by all in the the security > community. > >> I agree with Tom that CVE is the path of least resistance but may be > >> the most useful for basic interoperability. > >>> > >>> Kent Landfield > >>> Director Content Strategy, Architecture and Standards > >>> > >>> McAfee | An Intel Company > >>> 5000 Headquarters Dr. > >>> Plano, Texas 75024 > >>> > >>> Direct: +1.972.963.7096 > >>> Mobile: +1.817.637.8026 > >>> Web: www.mcafee.com > >>> > >>> From: > >>> > >> "Thomas.Millar@us-cert.gov" >> .M > >>> illar@us-cert.gov> > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > >>> To: > >>> > >> "david.black@emc.com" >> m< > >>> mailto:david.black@emc.com>>, Bob > >>> Martin> > >>> Cc: > >>> > >> "mile@ietf.org" >> .o > >>> rg>> > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> My concern with CAPEC being mandatory is that it could discourage > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > >> remains "too comprehensive" for many CSIRTs to employ during > incident > >> handling and reporting activity. > >>> > >>> IODEF by itself has been criticized by CSIRT operators for being > >>> more > >> heavyweight than necessary for day-to-day usage; making CAPEC a > >> mandatory aspect of "advanced IODEF" seems like it would be adding > >> ammunition to that argument, especially if the CSIRT is having to > >> fund implementation out of their own pocket. Personally, I would > have > >> a hard time asking US-CERT's primary constituents to implement IODEF > >> + CAPEC if they are already balking at the consultant and developer > >> resources required to implement RFC 5070 by itself. Also keep in > mind > >> that CAPEC references CybOX, so there's wheels within wheels now. > >>> > >>> I would prefer we take the path of least resistance (from my > > perspective) > >> and make CVE the MTI, if we have to pick one additional spec. > >>> CVE is well known, has years of familiarity built in, and I think > >>> it's > >> the simplest schema of the bunch. > >>> > >>> > >>> - Tom Millar, US-CERT > >>> > >>> thomas.millar@us-cert.gov > >>> BB: thomas.millar@dhs.gov / > >>> 202-631-1915 > >>> 24x7: soc@us-cert.gov / 888-282-0870 > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > >>> david.black@emc.com > >>> Sent: Tuesday, February 14, 2012 11:14 > >>> To: ramartin@mitre.org > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> Hi Bob, > >>> > >>> I do appreciate the concern about implementing things that aren't > >>> going > >> to be used. OTOH, it may be useful to have a single simple MTI spec > >> for SCI that can be used to "smoke test" a deployment before trying > >> any > > serious > >> test data (and "simple" is important). > >>> > >>> In addition, a concern that I would have with an MTI SCI spec per > >>> class > >> is that if two SCI implementations don't have at least one class in > > common, > >> they aren't going to interoperate, and that situation is unlikely to > >> be acceptable to the IESG (i.e., with an MTI SCI spec per class, I > >> suspect that there will also have to be an MTI class, which results > >> in an overall MTI SCI spec). > >>> > >>> It may also be useful to include a simple example of the MTI SCI > >>> spec > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > spec > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML > >> document for testing purposes, including enumeration values suitable > >> for testing). > >>> > >>> What do you (and others) think about this? > >>> > >>> Thanks, > >>> --David > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > >>> Sent: Tuesday, February 14, 2012 8:26 AM > >>> To: Brian Trammell > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> Brian, > >>> You beat me to this point. Like you, I would be concerned about a > >>> MTI selection that ended up requiring someone to implement > something > >>> to meet the MTI but wasn't germane to anything else they intended > to > >> support. > >>> Bob > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > >>>> Hi, Sean, all, > >>>> > >>>> Looking over the spec, it's not clear to me that one MTI makes > >>>> sense here, given that mile-sci's > >>> purpose is to reference a set of external specifications by > >>> inclusion in an IODEF document, and that those external > >>> specifications represent > >> fundamentally different things. > >>>> > >>>> The specifications are split over their applicability to the IODEF > >>>> extension classes. I could > >>> envision an mile-sci implementation that was only interested a > >>> subset of these classes (perhaps even only one). If my > >>> implementation has an internal representation of Verification, but > >>> not of any of the other classes, and the MTI is an enumeration that > >>> is applicable to > >> Vulnerability... what do I do? > >>>> > >>>> What about selecting an MTI per class, instead? > >>>> > >>>> Best regards, > >>>> > >>>> Brian (as contributor) > >>>> > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >>>> > >>>>> Great - as long as we pick one as the MTI. Note that MTI is not > >> necessarily mandatory to use. > >>>>> > >>>>> spt > >>>>> > >>>>> On 2/13/12 7:11 PM, > >> kathleen.moriarty@emc.com wrote: > >>>>>> Thank you for raising the interoperability testing as we need to > >>>>>> plan for a bake-off that once > >>> these questions get answered and the draft is ready. > >>>>>> > >>>>>> Thanks, > >>>>>> Kathleen > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: mile-bounces@ietf.org > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > >>>>>> To: mile@ietf.org > >>>>>> Subject: [mile] MTI SCI? > >>>>>> > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > >>>>>> (mandatory to implement) choice? In other words, how will you > >>>>>> get two interoperability implementations without picking one? > >>>>>> > >>>>>> spt > >>>>>> _______________________________________________ > >>>>>> mile mailing list > >>>>>> mile@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> mile mailing list > >>>>> mile@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>>> . > >>>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > 03c > > > andidate_20120215.txt.pdf>____________________________________________ > > ___ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From jeff360@gmail.com Mon Feb 20 18:27:37 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB55A21F8597 for ; Mon, 20 Feb 2012 18:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NRtrIeTPH0nK for ; Mon, 20 Feb 2012 18:27:36 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 473BB21F8593 for ; Mon, 20 Feb 2012 18:27:35 -0800 (PST) Received: by bkuw12 with SMTP id w12so5714640bku.31 for ; Mon, 20 Feb 2012 18:27:34 -0800 (PST) Received-SPF: pass (google.com: domain of jeff360@gmail.com designates 10.204.156.5 as permitted sender) client-ip=10.204.156.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jeff360@gmail.com designates 10.204.156.5 as permitted sender) smtp.mail=jeff360@gmail.com; dkim=pass header.i=jeff360@gmail.com Received: from mr.google.com ([10.204.156.5]) by 10.204.156.5 with SMTP id u5mr12709405bkw.84.1329791254353 (num_hops = 1); Mon, 20 Feb 2012 18:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ypoM9sH5mSCTFz8DgVm11pznxJaOvMGsyjXs7i1U2jk=; b=FegCkjyDNpbcyFT/xoObpygrZOP7UbY0LKPWDjyMfrKdr1AVmId1K0AiQ47w7ayLmi osI2MCwIlgehXmzlwQWM/2PfxBKRgm/0pyCHi683M/V1l2yIu60DWG0T/XdTYFGRgsEZ xz2IA9IFTsYSaFjJOWHMP3f1X09HlksDqnU8o= Received: by 10.204.156.5 with SMTP id u5mr10237482bkw.84.1329791254214; Mon, 20 Feb 2012 18:27:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.83.73 with HTTP; Mon, 20 Feb 2012 18:27:14 -0800 (PST) In-Reply-To: <004101ccebc2$61941820$24bc4860$@nict.go.jp> References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> From: Jeff Reed Date: Mon, 20 Feb 2012 18:27:14 -0800 Message-ID: To: Takeshi Takahashi Content-Type: multipart/alternative; boundary=0015175cd2fa55371404b970277a Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:27:37 -0000 --0015175cd2fa55371404b970277a Content-Type: text/plain; charset=ISO-8859-1 Take, Should your suggested text: Implementations may choose which specifications to support, though CVE 1.0 (Section 4.1.7) needs to be minimally supported. ...be changes to: Implementations may choose which specifications to support, though CVE 1.0 (Section 4.1.7) MUST be minimally supported. ...in the context of this discussion? Kind regards, Jeff Reed On Wed, Feb 15, 2012 at 1:15 AM, Takeshi Takahashi < takeshi_takahashi@nict.go.jp> wrote: > Hello all, > > Following the discussion, I would like to add a couple of sentences to > clarify the MTI issues. > (Thank you very much for those of you who kindly provided useful > discussion.) > I've attached the working version of the draft. I hope it helps to clarify > the changes. > > (added sentences at the end of section 4.1) > > The SpecID attributes of extended classes (Section 4.3) must allow > the values of the specifications' namespace fields, but otherwise, > implementations are not required to support all the above > specifications. Implementations may choose which specifications to > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > supported. In case an implementation received a data it does not > support, it may expand its functionality by looking up the IANA table or > notify the sender of its inability to parse the data by using any > means defined outside the scope of this specification. > > On the other hand, I would like to add "STRING ext-SpecID" to each class, > which enables to embed data following private schema. > For instance, one security operation center (SOC) may wish to exchange a > vulnerability data that is formatted in its own private schema, and that is > not formatted in CVE. > In this case, the SOC may put the data's schema ID inside ext-SpecID and > then embed the data. > It could also be used to exchange data using beta version of > specifications. > > The class could be seen as below. > > +------------------------+ > | AttackPattern | > +------------------------+ > | ENUM SpecID |<>--(0..*)-[ RawData ] > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > +------------------------+ > > SpecID: REQUIRED. ENUM. The identifier of the specification > specifying the format of the RawData element. The value should be > chosen from the namespaces [XMLNames] listed in Section 4.1 or > "private". Note that the lists in Section 4.1 will be developed > further by IANA. The value "private" is prepared for conveying > RawData based on a format that is not listed in the > table. This is usually used for conveying data formatted > according to an organization's private schema. When the value > "private" is used, ext-SpecID element needs to be used. > > ext-SpecID: OPTIONAL. STRING. The identifier of the specification > specifying the format of the RawData element. When this element > is used, the value of SpecID element must be "private." > > I hope above changes don't cause any complication here. > > Sincerely, > Take > > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > > Martin, Robert A. > > Sent: Wednesday, February 15, 2012 1:50 AM > > To: Kent_Landfield@McAfee.com > > Cc: mile@ietf.org > > Subject: Re: [mile] MTI SCI? > > > > At the risk of contradicting myself - but then again I have now read the > > other replies to this issue - I agree that having one area be the smoke > > test makes sense and I also agree that something simple and commonly used > > already - like CVE - is the best candidate for what we need. > > > > Bob > > > > On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > > CVE is widely used and understood by all in the the security community. > > I agree with Tom that CVE is the path of least resistance but may be the > > most useful for basic interoperability. > > > > > > Kent Landfield > > > Director Content Strategy, Architecture and Standards > > > > > > McAfee | An Intel Company > > > 5000 Headquarters Dr. > > > Plano, Texas 75024 > > > > > > Direct: +1.972.963.7096 > > > Mobile: +1.817.637.8026 > > > Web: www.mcafee.com > > > > > > From: > > > > > "Thomas.Millar@us-cert.gov" > .M > > > illar@us-cert.gov> > > > Date: Tue, 14 Feb 2012 10:36:57 -0600 > > > To: > > > > > "david.black@emc.com" > m< > > > mailto:david.black@emc.com>>, Bob > > > Martin> > > > Cc: > > > > > "mile@ietf.org" > .o > > > rg>> > > > Subject: Re: [mile] MTI SCI? > > > > > > My concern with CAPEC being mandatory is that it could discourage > > effective operational uptake of IODEF-SCI as the CAPEC vocabulary remains > > "too comprehensive" for many CSIRTs to employ during incident handling > > and reporting activity. > > > > > > IODEF by itself has been criticized by CSIRT operators for being more > > heavyweight than necessary for day-to-day usage; making CAPEC a mandatory > > aspect of "advanced IODEF" seems like it would be adding ammunition to > > that argument, especially if the CSIRT is having to fund implementation > > out of their own pocket. Personally, I would have a hard time asking > > US-CERT's primary constituents to implement IODEF + CAPEC if they are > > already balking at the consultant and developer resources required to > > implement RFC 5070 by itself. Also keep in mind that CAPEC references > > CybOX, so there's wheels within wheels now. > > > > > > I would prefer we take the path of least resistance (from my > perspective) > > and make CVE the MTI, if we have to pick one additional spec. > > > CVE is well known, has years of familiarity built in, and I think it's > > the simplest schema of the bunch. > > > > > > > > > - Tom Millar, US-CERT > > > > > > thomas.millar@us-cert.gov > > > BB: thomas.millar@dhs.gov / > > > 202-631-1915 > > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org > > > [mailto:mile-bounces@ietf.org] On Behalf Of > > > david.black@emc.com > > > Sent: Tuesday, February 14, 2012 11:14 > > > To: ramartin@mitre.org > > > Cc: mile@ietf.org > > > Subject: Re: [mile] MTI SCI? > > > > > > Hi Bob, > > > > > > I do appreciate the concern about implementing things that aren't going > > to be used. OTOH, it may be useful to have a single simple MTI spec for > > SCI that can be used to "smoke test" a deployment before trying any > serious > > test data (and "simple" is important). > > > > > > In addition, a concern that I would have with an MTI SCI spec per class > > is that if two SCI implementations don't have at least one class in > common, > > they aren't going to interoperate, and that situation is unlikely to be > > acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect > > that there will also have to be an MTI class, which results in an overall > > MTI SCI spec). > > > > > > It may also be useful to include a simple example of the MTI SCI spec > > in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec > > is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML > > document for testing purposes, including enumeration values suitable for > > testing). > > > > > > What do you (and others) think about this? > > > > > > Thanks, > > > --David > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org > > [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > > Sent: Tuesday, February 14, 2012 8:26 AM > > > To: Brian Trammell > > > Cc: mile@ietf.org > > > Subject: Re: [mile] MTI SCI? > > > Brian, > > > You beat me to this point. Like you, I would be concerned about a MTI > > > selection that ended up requiring someone to implement something to > > > meet the MTI but wasn't germane to anything else they intended to > > support. > > > Bob > > > On 2/14/12 4:19 AM, Brian Trammell wrote: > > >> Hi, Sean, all, > > >> > > >> Looking over the spec, it's not clear to me that one MTI makes sense > > >> here, given that mile-sci's > > > purpose is to reference a set of external specifications by inclusion > > > in an IODEF document, and that those external specifications represent > > fundamentally different things. > > >> > > >> The specifications are split over their applicability to the IODEF > > >> extension classes. I could > > > envision an mile-sci implementation that was only interested a subset > > > of these classes (perhaps even only one). If my implementation has an > > > internal representation of Verification, but not of any of the other > > > classes, and the MTI is an enumeration that is applicable to > > Vulnerability... what do I do? > > >> > > >> What about selecting an MTI per class, instead? > > >> > > >> Best regards, > > >> > > >> Brian (as contributor) > > >> > > >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > >> > > >>> Great - as long as we pick one as the MTI. Note that MTI is not > > necessarily mandatory to use. > > >>> > > >>> spt > > >>> > > >>> On 2/13/12 7:11 PM, > > kathleen.moriarty@emc.com wrote: > > >>>> Thank you for raising the interoperability testing as we need to > > >>>> plan for a bake-off that once > > > these questions get answered and the draft is ready. > > >>>> > > >>>> Thanks, > > >>>> Kathleen > > >>>> > > >>>> -----Original Message----- > > >>>> From: mile-bounces@ietf.org > > >>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > >>>> Sent: Monday, February 13, 2012 6:57 PM > > >>>> To: mile@ietf.org > > >>>> Subject: [mile] MTI SCI? > > >>>> > > >>>> There's 17 listed SCI (Structured Cybersecurity Information) > > >>>> specifications in draft-ietf-mile-sci. Which one is the MTI > > >>>> (mandatory to implement) choice? In other words, how will you get > > >>>> two interoperability implementations without picking one? > > >>>> > > >>>> spt > > >>>> _______________________________________________ > > >>>> mile mailing list > > >>>> mile@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >> > > >> _______________________________________________ > > >> mile mailing list > > >> mile@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mile > > >> . > > >> > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > --0015175cd2fa55371404b970277a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Take,

=A0=A0 Should your suggested text:

=A0Implementations m= ay choose which specifications to
=A0 support, though CVE 1.0 (Section 4.1.7) needs to be minimally
=A0 supported.

=A0=A0 ...be changes to:

=A0Implementations = may choose which specifications to
=A0 support, though CVE 1.0 (Section 4.1.7) MUST be minimally
=A0 supported.

=A0=A0 ...in the context of this discussion?
=A0=A0 Kind regards,

=A0=A0 Jeff Reed
=A0=A0


On Wed, Feb 15, 2012 at 1:15 AM, Takeshi Takahashi <takeshi_t= akahashi@nict.go.jp> wrote:
Hello all,

Following the discussion, I would like to add a couple of sentences to
clarify the MTI issues.
(Thank you very much for those of you who kindly provided useful
discussion.)
I've attached the working version of the draft. I hope it helps to clar= ify
the changes.

(added sentences at the end of section 4.1)

=A0 The SpecID attributes of extended classes (Section 4.3) must allow
=A0 the values of the specifications' namespace fields, but otherwise,=
=A0 implementations are not required to support all the above
=A0 specifications. =A0Implementations may choose which specifications to<= br> =A0 support, though CVE 1.0 (Section 4.1.7) needs to be minimally
=A0 supported. =A0In case an implementation received a data it does not =A0 support, it may expand its functionality by looking up the IANA table = or
=A0 notify the sender of its inability to parse the data by using any
=A0 means defined outside the scope of this specification.

On the other hand, I would like to add "STRING ext-SpecID" to eac= h class,
which enables to embed data following private schema.
For instance, one security operation center (SOC) may wish to exchange a vulnerability data that is formatted in its own private schema, and that is=
not formatted in CVE.
In this case, the SOC may put the data's schema ID inside ext-SpecID an= d
then embed the data.
It could also be used to exchange data using beta version of specifications= .

The class could be seen as below.

=A0 +------------------------+
=A0 | AttackPattern =A0 =A0 =A0 =A0 =A0|
=A0 +------------------------+
=A0 | ENUM SpecID =A0 =A0 =A0 =A0 =A0 =A0|<>--(0..*)-[ RawData ]
=A0 | STRING ext-SpecID =A0 =A0 =A0|<>--(0..*)-[ Reference ]
=A0 | STRING AttackPatternID |<>--(0..*)-[ Platform ]
=A0 +------------------------+

=A0 SpecID: =A0REQUIRED. =A0ENUM. =A0The identifier of the specification =A0 =A0 =A0specifying the format of the RawData element. =A0The value shou= ld be
=A0 =A0 =A0chosen from the namespaces [XMLNames] listed in Section 4.1 or<= br> =A0 =A0 =A0"private". =A0Note that the lists in Section 4.1 will= be developed
=A0 =A0 =A0further by IANA. The value "private" is prepared for = conveying
=A0 =A0 =A0RawData based on a format that is not listed in the
=A0 =A0 =A0table. =A0This is usually used for conveying data formatted
=A0 =A0 =A0according to an organization's private schema. =A0When the = value
=A0 =A0 =A0"private" is used, ext-SpecID element needs to be use= d.

=A0 ext-SpecID: =A0OPTIONAL. =A0STRING. =A0The identifier of the specifica= tion
=A0 =A0 =A0specifying the format of the RawData element. =A0When this elem= ent
=A0 =A0 =A0is used, the value of SpecID element must be "private.&quo= t;

I hope above changes don't cause any complication here.

Sincerely,
Take



> -----Original Message-----
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
> Martin, Robert A.
> Sent: Wednesday, February 15, 2012 1:50= AM
> To: Kent_Landfield@McAfee.com
> Cc: mile@ietf.org
> Subject: Re: [mile] MTI SCI?
>
> At the risk of contradic= ting myself - but then again I have now read the
> other replies to this issue - I agree that having one area be the smok= e
> test makes sense and I also agree that something simple and commonly u= sed
> already - like CVE - is the best candidate for what we need.
>
> Bob
>
> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote:
> > CVE is widely used and understood by all in the the security comm= unity.
> I agree with Tom that CVE is the path of least resistance but may be t= he
> most useful for basic interoperability.
> >
> > Kent Landfield
> > Director Content Strategy, Architecture and Standards
> >
> > McAfee | An Intel Company
> > 5000 Headquarters Dr.
> > Plano, Texas 75024
> >
> > Direct: = +1.972.963.7096
> > Mobile: = +1.817.637.8026
> > Web: www.mcaf= ee.com<http://w= ww.mcafee.com/>
> >
> > From:
> >
> "Thomas.Millar@us-ce= rt.gov<mailto:Thomas.Mi= llar@us-cert.gov>"<Thomas
> .M
> > illar@us-cert.gov<mai= lto:Thomas.Millar@us-cert.gov<= /a>>>
> > Date: Tue, 14 Feb 2012 10:36:57 -0600
> > To:
> >
> "david.black@emc.com&l= t;mailto:david.black@emc.com>= "<david.black@emc.co
> m<
> > mailto:david.black@emc.com= >>, Bob
> > Martin<ramartin@mitre.or= g<mailto:ramartin@mitre.org>>
> > Cc:
> >
> "mile@ietf.org<mailto:mile@ietf.org>"<mile@ietf.org<mailto:mile@ietf
> .o
> > rg>>
> > Subject: Re: [mile] MTI SCI?
> >
> > My concern with CAPEC being mandatory is that it could discourage=
> effective operational uptake of IODEF-SCI as the CAPEC vocabulary rema= ins
> "too comprehensive" for many CSIRTs to employ during inciden= t handling
> and reporting activity.
> >
> > IODEF by itself has been criticized by CSIRT operators for being = more
> heavyweight than necessary for day-to-day usage; making CAPEC a mandat= ory
> aspect of "advanced IODEF" seems like it would be adding amm= unition to
> that argument, especially if the CSIRT is having to fund implementatio= n
> out of their own pocket. Personally, I would have a hard time asking > US-CERT's primary constituents to implement IODEF + CAPEC if they = are
> already balking at the consultant and developer resources required to<= br> > implement RFC 5070 by itself. Also keep in mind that CAPEC references<= br> > CybOX, so there's wheels within wheels now.
> >
> > I would prefer we take the path of least resistance (from my
perspective)
> and make CVE the MTI, if we have to pick one additional spec.
> > CVE is well known, has years of familiarity built in, and I think= it's
> the simplest schema of the bunch.
> >
> >
> > - Tom Millar, US-CERT
> >
> > thomas.millar@us-cer= t.gov<mailto:thomas.mil= lar@us-cert.gov>
> > BB: thomas.millar@dhs.go= v<mailto:thomas.millar@dhs.= gov> =A0/
> > 202-631-1915<= /a>
> > 24x7: soc@us-cert.gov<m= ailto:soc@us-cert.gov> =A0/ 888-282-0870
> >
> > -----Original Message-----
> > From: mile-bounces@ietf.= org<mailto:mile-bounces@iet= f.org>
> > [mailto:mile-bounces@iet= f.org] On Behalf Of
> > david.black@emc.com<= ;mailto:david.black@emc.com><= br> > > Sent: Tuesday, February 14, 2012 11:14
> > To: ramartin@mitre.org&= lt;mailto:ramartin@mitre.org><= br> > > Cc: mile@ietf.org<mailto:= mile@ietf.org>
> > Subject: Re: [mile] MTI SCI?
> >
> > Hi Bob,
> >
> > I do appreciate the concern about implementing things that aren&#= 39;t going
> to be used. =A0OTOH, it may be useful to have a single simple MTI spec= for
> SCI that can be used to "smoke test" a deployment before try= ing any
serious
> test data (and "simple" is important).
> >
> > In addition, a concern that I would have with an MTI SCI spec per= class
> is that if two SCI implementations don't have at least one class i= n
common,
> they aren't going to interoperate, and that situation is unlikely = to be
> acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspec= t
> that there will also have to be an MTI class, which results in an over= all
> MTI SCI spec).
> >
> > It may also be useful to include a simple example of the MTI SCI = spec
> in an appendix to simplify "smoke testing" (e.g., if the MTI= SCI spec
> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML > document for testing purposes, including enumeration values suitable f= or
> testing).
> >
> > What do you (and others) think about this?
> >
> > Thanks,
> > --David
> >
> > -----Original Message-----
> > From: mile-bounces@ietf.= org<mailto:mile-bounces@iet= f.org>
> [mailto:mile-bounces@ietf.org= ] On Behalf Of Martin, Robert A.
> > Sent: Tuesday, February 14, 2012 8:26 AM
> > To: Brian Trammell
> > Cc: mile@ietf.org<mailto:= mile@ietf.org>
> > Subject: Re: [mile] MTI SCI?
> > Brian,
> > You beat me to this point. =A0Like you, I would be concerned abou= t a MTI
> > selection that ended up requiring someone to implement something = to
> > meet the MTI but wasn't germane to anything else they intende= d to
> support.
> > Bob
> > On 2/14/12 4:19 AM, Brian Trammell wrote:
> >> Hi, Sean, all,
> >>
> >> Looking over the spec, it's not clear to me that one MTI = makes sense
> >> here, given that mile-sci's
> > purpose is to reference a set of external specifications by inclu= sion
> > in an IODEF document, and that those external specifications repr= esent
> fundamentally different things.
> >>
> >> The specifications are split over their applicability to the = IODEF
> >> extension classes. I could
> > envision an mile-sci implementation that was only interested a su= bset
> > of these classes (perhaps even only one). If my implementation ha= s an
> > internal representation of Verification, but not of any of the ot= her
> > classes, and the MTI is an enumeration that is applicable to
> Vulnerability... what do I do?
> >>
> >> What about selecting an MTI per class, instead?
> >>
> >> Best regards,
> >>
> >> Brian (as contributor)
> >>
> >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote:
> >>
> >>> Great - as long as we pick one as the MTI. =A0Note that M= TI is not
> necessarily mandatory to use.
> >>>
> >>> spt
> >>>
> >>> On 2/13/12 7:11 PM,
> kathleen.moriarty@emc.com= <mailto:kathleen.moriar= ty@emc.com> =A0wrote:
> >>>> Thank you for raising the interoperability testing as= we need to
> >>>> plan for a bake-off that once
> > these questions get answered and the draft is ready.
> >>>>
> >>>> Thanks,
> >>>> Kathleen
> >>>>
> >>>> -----Original Message-----
> >>>> From: mile-b= ounces@ietf.org<mailto:mile= -bounces@ietf.org>
> >>>> [mailto:mile= -bounces@ietf.org] On Behalf Of Sean Turner
> >>>> Sent: Monday, February 13, 2012 6:57 PM
> >>>> To: mile@ietf.org<mailto:mile@ietf.org>
> >>>> Subject: [mile] MTI SCI?
> >>>>
> >>>> There's 17 listed SCI (Structured Cybersecurity I= nformation)
> >>>> specifications in draft-ietf-mile-sci. =A0Which one i= s the MTI
> >>>> (mandatory to implement) choice? =A0In other words, h= ow will you get
> >>>> two interoperability implementations without picking = one?
> >>>>
> >>>> spt
> >>>> _______________________________________________
> >>>> mile mailing list
> >>>> mile@ietf.org<= ;mailto:mile@ietf.org>
> >>>> https://www.ietf.org/mailman/listinfo/mile
> >>>>
> >>>>
> >>> _______________________________________________
> >>> mile mailing list
> >>> mile@ietf.org<mai= lto:mile@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/mile
> >>
> >> _______________________________________________
> >> mile mailing list
> >> mile@ietf.org<mailto:= mile@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/mile
> >> .
> >>
> > _______________________________________________
> > mile mailing list
> > mile@ietf.org<mailto:mile@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mile
> >
> > _______________________________________________
> > mile mailing list
> > mile@ietf.org<mailto:mile@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mile
> > _______________________________________________
> > mile mailing list
> > mile@ietf.org<mailto:mile@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mile
> >
> >
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
mile@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mile


--0015175cd2fa55371404b970277a-- From ariestake@googlemail.com Mon Feb 20 17:40:44 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CF321E8010 for ; Mon, 20 Feb 2012 17:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wMJHtX9X3+eY for ; Mon, 20 Feb 2012 17:40:42 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7752521E8016 for ; Mon, 20 Feb 2012 17:40:42 -0800 (PST) Received: by dakl33 with SMTP id l33so6597076dak.31 for ; Mon, 20 Feb 2012 17:40:42 -0800 (PST) Received-SPF: pass (google.com: domain of ariestake@googlemail.com designates 10.68.129.162 as permitted sender) client-ip=10.68.129.162; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ariestake@googlemail.com designates 10.68.129.162 as permitted sender) smtp.mail=ariestake@googlemail.com; dkim=pass header.i=ariestake@googlemail.com Received: from mr.google.com ([10.68.129.162]) by 10.68.129.162 with SMTP id nx2mr13951028pbb.94.1329788442383 (num_hops = 1); Mon, 20 Feb 2012 17:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=O/ftC2XiT2V9hxDZJSmXzr+SUGtrWRiXoE9iK1gxJVo=; b=tE0VPmw4S8uveXGV2gIK3MVGV9h5HXL9v8Twyh6L5zqfDRDm56npexeVLHG3jDfDXt k3wkvkxRWWEw7Yv53P/UCzpREs8+5ZD0PoDd+tlSlANlXPCSaBBAwC0efxFg9vBr+3oM i1t59q62dibutfasMxk9mRgJm9ajJ9Mu5EW7g= Received: by 10.68.129.162 with SMTP id nx2mr11313536pbb.94.1329788442201; Mon, 20 Feb 2012 17:40:42 -0800 (PST) Received: from takeVAIO2 ([210.229.158.128]) by mx.google.com with ESMTPS id b1sm14605958pbr.64.2012.02.20.17.40.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 17:40:41 -0800 (PST) From: "Takeshi Takahashi" To: , , , References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> , In-Reply-To: Date: Tue, 21 Feb 2012 10:40:27 +0900 Message-ID: <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtSVXlOfYA== Content-Language: ja X-Mailman-Approved-At: Tue, 21 Feb 2012 02:36:21 -0800 Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 01:40:44 -0000 Hello all, Thank you for your kind comments, which are really useful for me. On the other hand, I have some difficulties to understand what people specifically mean by "support" or "mandatory". I would appreciate if you could kindly give me some comments on below. Below are my views on the MTI issues. 1. All the specification namespaces listed in the table MUST be "supported" as values for the SpecID field. These namespaces are the allowed ENUM values. So, in a way, all the specification listed in the table are supported. (implementations must allow these namespaces of all the specifications listed in the table as values for SpecID field) Since all the specification listed in the table are supported, we need to have expert review before registration (as we discussed in Quebec City) In this way, receivers can correctly understand the data. That will give us the same level of interoperability as the RFC 5070 (IODEF) does between sender and receiver, I think. 2. Implementers have freedom to define how to parse, how to understand, and how to respond the IODEF extension message I might be wrong, but I do not think we would like to define how to parse the IODEF extension message at the receiver side. And I do not think we would like to define how to parse, for instance, CAPEC data, at the receiver side. I think the SCI draft is a container that conveys these structured information, and it can see such information as a blackbox with a tag (namespace information). If above understanding is correct, I have some difficulty to understand the meaning of "mandatory to support CVE". As described in issue 1 above, if CVE or CAPEC data is attached, the implementation needs to recognize that the data is in CVE/CAPEC format, and that is the requirement for the implementation. What else do we want to mandate here, specifically? Do we need to manipulate the embedded xml data itself? I rather prefer to handle the data as a blackbox. I appreciate your kind comments. Regarding the other point Dave kindly pointed out, let me have another thread. (sorry I need to get on board now...) Thank you. Take -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] Sent: Monday, February 20, 2012 8:08 PM To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp Cc: mile@ietf.org Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thank you, Dave. Dave raises a few very important points as we consider MTI for SCI. We will need to resolve these issues if CVE is to be the (or an) MTI specification for the SCI draft. If CVE is mandatory to implement, what guidance would be followed on how to use the model or will MTI only mean that the document can be received and parsed? The CVE website is listed as the specification URI, but from Dave's message, the specification URI does not exist to provide the guidance (I get to broken link pages for both - the existing and suggested replacement link). This is the closest I could find and may be the answer for guidance: http://cve.mitre.org/compatible/requirements.html It looks like the reference to the target namespace needs to be fixed as well. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Waltermire, David A. [david.waltermire@nist.gov] Sent: Thursday, February 16, 2012 5:26 PM To: Brian Trammell; Takeshi Takahashi Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) I have not been following this thread as closely as I probably should. Relative to MTI, is the question what schema should be MTI for the vulerability class? In general I think we should have one or more MTI for each class. Relative to CVE specifically, are we talking about the schema currently located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd? This seems to match the namespace defined in section 4.1.7 of mile-sci-02. Looking at the implementation of this schema, it looks like the targetNamespace is incorrectly assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be fixed. Also, the specification URI points to the CVE website, which is not really a specification. It's not clear where to find guidance on how to properly use the model indicated by the namespace. Without having clear guidance on its use I don't see how we can make it MTI, even if it is considered a de facto approach. It might make sense to produce a specification for the model before making it MTI for the vulnerability class. Sincerely, David Waltermire > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of Brian Trammell > Sent: Wednesday, February 15, 2012 5:28 AM > To: Takeshi Takahashi > Cc: mile@ietf.org > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was > Re: MTI SCI?) > > Hi, Take, all, > > Thank you for this edit/clarification. > > On the first point, it does seem the discussion on the list converged > rather quickly to CVE as MTI. However, as this is a rather important > point, I'd like to make sure we didn't miss anything. > > So, I'd like to call for consensus on the list. Does the working group > agree on the following two points? > > 1. mile-sci requires one Mandatory to Implement schema in order to > ensure interoperability. > > 2. The Mandatory to Implement schema is the Common Vulnerability > Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- > sci-02. > > Please note if you agree; if you disagree, please explain why not. > > Best regards, > > Brian (as chair) > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > Hello all, > > > > Following the discussion, I would like to add a couple of sentences > to > > clarify the MTI issues. > > (Thank you very much for those of you who kindly provided useful > > discussion.) > > I've attached the working version of the draft. I hope it helps to > > clarify the changes. > > > > (added sentences at the end of section 4.1) > > > > The SpecID attributes of extended classes (Section 4.3) must allow > > the values of the specifications' namespace fields, but otherwise, > > implementations are not required to support all the above > > specifications. Implementations may choose which specifications to > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > supported. In case an implementation received a data it does not > > support, it may expand its functionality by looking up the IANA > table or > > notify the sender of its inability to parse the data by using any > > means defined outside the scope of this specification. > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > class, which enables to embed data following private schema. > > For instance, one security operation center (SOC) may wish to > exchange > > a vulnerability data that is formatted in its own private schema, > > and that is not formatted in CVE. > > In this case, the SOC may put the data's schema ID inside ext-SpecID > > and then embed the data. > > It could also be used to exchange data using beta version of > specifications. > > > > The class could be seen as below. > > > > +------------------------+ > > | AttackPattern | > > +------------------------+ > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > +------------------------+ > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > specifying the format of the RawData element. The value should > be > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > "private". Note that the lists in Section 4.1 will be developed > > further by IANA. The value "private" is prepared for conveying > > RawData based on a format that is not listed in the > > table. This is usually used for conveying data formatted > > according to an organization's private schema. When the value > > "private" is used, ext-SpecID element needs to be used. > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > specification > > specifying the format of the RawData element. When this element > > is used, the value of SpecID element must be "private." > > > > I hope above changes don't cause any complication here. > > > > Sincerely, > > Take > > > > > > > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > >> Behalf Of Martin, Robert A. > >> Sent: Wednesday, February 15, 2012 1:50 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] MTI SCI? > >> > >> At the risk of contradicting myself - but then again I have now > >> read the other replies to this issue - I agree that having one area > >> be > the > >> smoke test makes sense and I also agree that something simple and > >> commonly used already - like CVE - is the best candidate for what > >> we > need. > >> > >> Bob > >> > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > >>> CVE is widely used and understood by all in the the security > community. > >> I agree with Tom that CVE is the path of least resistance but may > >> be the most useful for basic interoperability. > >>> > >>> Kent Landfield > >>> Director Content Strategy, Architecture and Standards > >>> > >>> McAfee | An Intel Company > >>> 5000 Headquarters Dr. > >>> Plano, Texas 75024 > >>> > >>> Direct: +1.972.963.7096 > >>> Mobile: +1.817.637.8026 > >>> Web: www.mcafee.com > >>> > >>> From: > >>> > >> "Thomas.Millar@us-cert.gov" >> s > >> .M > >>> illar@us-cert.gov> > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > >>> To: > >>> > >> "david.black@emc.com" >> o > >> m< > >>> mailto:david.black@emc.com>>, Bob > >>> Martin> > >>> Cc: > >>> > >> "mile@ietf.org" >> f > >> .o > >>> rg>> > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> My concern with CAPEC being mandatory is that it could discourage > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > >> remains "too comprehensive" for many CSIRTs to employ during > incident > >> handling and reporting activity. > >>> > >>> IODEF by itself has been criticized by CSIRT operators for being > >>> more > >> heavyweight than necessary for day-to-day usage; making CAPEC a > >> mandatory aspect of "advanced IODEF" seems like it would be adding > >> ammunition to that argument, especially if the CSIRT is having to > >> fund implementation out of their own pocket. Personally, I would > have > >> a hard time asking US-CERT's primary constituents to implement > >> IODEF > >> + CAPEC if they are already balking at the consultant and developer > >> resources required to implement RFC 5070 by itself. Also keep in > mind > >> that CAPEC references CybOX, so there's wheels within wheels now. > >>> > >>> I would prefer we take the path of least resistance (from my > > perspective) > >> and make CVE the MTI, if we have to pick one additional spec. > >>> CVE is well known, has years of familiarity built in, and I think > >>> it's > >> the simplest schema of the bunch. > >>> > >>> > >>> - Tom Millar, US-CERT > >>> > >>> thomas.millar@us-cert.gov > >>> BB: thomas.millar@dhs.gov / > >>> 202-631-1915 > >>> 24x7: soc@us-cert.gov / 888-282-0870 > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > >>> david.black@emc.com > >>> Sent: Tuesday, February 14, 2012 11:14 > >>> To: ramartin@mitre.org > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> Hi Bob, > >>> > >>> I do appreciate the concern about implementing things that aren't > >>> going > >> to be used. OTOH, it may be useful to have a single simple MTI > >> spec for SCI that can be used to "smoke test" a deployment before > >> trying any > > serious > >> test data (and "simple" is important). > >>> > >>> In addition, a concern that I would have with an MTI SCI spec per > >>> class > >> is that if two SCI implementations don't have at least one class in > > common, > >> they aren't going to interoperate, and that situation is unlikely > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per class, > >> I suspect that there will also have to be an MTI class, which > >> results in an overall MTI SCI spec). > >>> > >>> It may also be useful to include a simple example of the MTI SCI > >>> spec > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > spec > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC > >> XML document for testing purposes, including enumeration values > >> suitable for testing). > >>> > >>> What do you (and others) think about this? > >>> > >>> Thanks, > >>> --David > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > >>> Sent: Tuesday, February 14, 2012 8:26 AM > >>> To: Brian Trammell > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> Brian, > >>> You beat me to this point. Like you, I would be concerned about a > >>> MTI selection that ended up requiring someone to implement > something > >>> to meet the MTI but wasn't germane to anything else they intended > to > >> support. > >>> Bob > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > >>>> Hi, Sean, all, > >>>> > >>>> Looking over the spec, it's not clear to me that one MTI makes > >>>> sense here, given that mile-sci's > >>> purpose is to reference a set of external specifications by > >>> inclusion in an IODEF document, and that those external > >>> specifications represent > >> fundamentally different things. > >>>> > >>>> The specifications are split over their applicability to the > >>>> IODEF extension classes. I could > >>> envision an mile-sci implementation that was only interested a > >>> subset of these classes (perhaps even only one). If my > >>> implementation has an internal representation of Verification, but > >>> not of any of the other classes, and the MTI is an enumeration > >>> that is applicable to > >> Vulnerability... what do I do? > >>>> > >>>> What about selecting an MTI per class, instead? > >>>> > >>>> Best regards, > >>>> > >>>> Brian (as contributor) > >>>> > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >>>> > >>>>> Great - as long as we pick one as the MTI. Note that MTI is not > >> necessarily mandatory to use. > >>>>> > >>>>> spt > >>>>> > >>>>> On 2/13/12 7:11 PM, > >> kathleen.moriarty@emc.com wrote: > >>>>>> Thank you for raising the interoperability testing as we need > >>>>>> to plan for a bake-off that once > >>> these questions get answered and the draft is ready. > >>>>>> > >>>>>> Thanks, > >>>>>> Kathleen > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: mile-bounces@ietf.org > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > >>>>>> To: mile@ietf.org > >>>>>> Subject: [mile] MTI SCI? > >>>>>> > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > >>>>>> (mandatory to implement) choice? In other words, how will you > >>>>>> get two interoperability implementations without picking one? > >>>>>> > >>>>>> spt > >>>>>> _______________________________________________ > >>>>>> mile mailing list > >>>>>> mile@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> mile mailing list > >>>>> mile@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>>> . > >>>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > 03c > > > andidate_20120215.txt.pdf>____________________________________________ > > ___ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From Thomas.Millar@us-cert.gov Tue Feb 21 09:00:28 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFF821F870A for ; Tue, 21 Feb 2012 09:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, 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 UKG2SB7FPtPY for ; Tue, 21 Feb 2012 09:00:24 -0800 (PST) Received: from shaggy.brass.us-cert.gov (shaggy.brass.us-cert.gov [208.73.184.44]) by ietfa.amsl.com (Postfix) with ESMTP id A20A521F8758 for ; Tue, 21 Feb 2012 09:00:22 -0800 (PST) Received: from shaggy.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 0FB2050AFF; Tue, 21 Feb 2012 17:00:21 +0000 (UTC) Received: from dabba.bronze.us-cert.gov (dabba.bronze.us-cert.gov [192.168.16.121]) by shaggy.brass.us-cert.gov (Postfix) with ESMTP id CB8A350AFE; Tue, 21 Feb 2012 17:00:20 +0000 (UTC) Received: from needle.bronze.us-cert.gov (needle.bronze.us-cert.gov [192.168.16.109]) by dabba.bronze.us-cert.gov (Postfix) with ESMTP id 8166F6E45D; Tue, 21 Feb 2012 17:00:20 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 11:00:20 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Feb 2012 11:00:19 -0600 Message-ID: In-Reply-To: <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtSVXlOfYIAA940A References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> From: To: , , , , X-OriginalArrivalTime: 21 Feb 2012 17:00:20.0385 (UTC) FILETIME=[4B3E2910:01CCF0BA] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18724.000 X-TM-AS-Result: No--65.519-5.0-31-1 X-imss-scan-details: No--65.519-5.0-31-1 X-IMSS-DKIM-White-List: No Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 17:00:29 -0000 Take, I think you've done a very good job of explaining the two different = interpretations around this call for consensus. My interpretation of MTI was closer to #2 - that to support this draft, = an implementer would have to support not only recognition of the = namespace in the appropriate IODEF parent class context, but also be = able to parse the content of the referenced namespace. Hence my = preference for a relatively simple and familiar spec as the MTI. If we can concur that we all really mean the interpretation you describe = under #1, then I'm okay with having an MTI for each class. What that = says to me is that each implementer would need to conform to the SCI = draft's class placement of each namespace, but not necessarily have to = be able to interpret the contents of said namespace(s). So all I have to = do, minimally, is recognize the class under which any of the referenced = namespaces exist; I don't have to have any means to parse or handle that = class content other than bucket it and move on to the next. Is that = right? I would recommend that we be very clear in regards to what "support" or = "minimally support" mean so that technical requirements handed down = based on this draft do not bar achievement by operational implementers = and their engineering teams. Thanks again, - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Takeshi Takahashi Sent: Monday, February 20, 2012 20:40 To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; = trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI = (wasRe: MTI SCI?) Hello all, Thank you for your kind comments, which are really useful for me. On the other hand, I have some difficulties to understand what people = specifically mean by "support" or "mandatory". I would appreciate if you could kindly give me some comments on below. Below are my views on the MTI issues. 1. All the specification namespaces listed in the table MUST be "supported" as values for the SpecID field. These namespaces are the allowed ENUM values. So, in a way, all the specification listed in the table are supported. (implementations must allow these namespaces of all the specifications = listed in the table as values for SpecID field) Since all the = specification listed in the table are supported, we need to have expert = review before registration (as we discussed in Quebec City) In this way, receivers can correctly understand the data. That will give us the same level of interoperability as the RFC 5070 = (IODEF) does between sender and receiver, I think. 2. Implementers have freedom to define how to parse, how to understand, and how to respond the IODEF extension message I might be wrong, but I do not think we would like to define how to = parse the IODEF extension message at the receiver side. And I do not think we would like to define how to parse, for instance, = CAPEC data, at the receiver side. I think the SCI draft is a container that conveys these structured = information, and it can see such information as a blackbox with a tag = (namespace information). If above understanding is correct, I have some difficulty to understand = the meaning of "mandatory to support CVE". As described in issue 1 above, if CVE or CAPEC data is attached, the = implementation needs to recognize that the data is in CVE/CAPEC format, = and that is the requirement for the implementation. What else do we want to mandate here, specifically? Do we need to manipulate the embedded xml data itself? I rather prefer = to handle the data as a blackbox. I appreciate your kind comments. Regarding the other point Dave kindly pointed out, let me have another = thread. (sorry I need to get on board now...) Thank you. Take -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] Sent: Monday, February 20, 2012 8:08 PM To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; = takeshi_takahashi@nict.go.jp Cc: mile@ietf.org Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI = (was Re: MTI SCI?) Thank you, Dave. Dave raises a few very important points as we consider MTI for SCI. We = will need to resolve these issues if CVE is to be the (or an) MTI = specification for the SCI draft. If CVE is mandatory to implement, what guidance would be followed on how = to use the model or will MTI only mean that the document can be received = and parsed? The CVE website is listed as the specification URI, but from Dave's message, the specification URI does not exist to provide the = guidance (I get to broken link pages for both - the existing and = suggested replacement link). This is the closest I could find and may be the answer for guidance: http://cve.mitre.org/compatible/requirements.html It looks like the reference to the target namespace needs to be fixed as = well. Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Waltermire, David A. [david.waltermire@nist.gov] Sent: Thursday, February 16, 2012 5:26 PM To: Brian Trammell; Takeshi Takahashi Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI = (was Re: MTI SCI?) I have not been following this thread as closely as I probably should. Relative to MTI, is the question what schema should be MTI for the = vulerability class? In general I think we should have one or more MTI = for each class. Relative to CVE specifically, are we talking about the schema currently = located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd? This seems to match the namespace defined in section 4.1.7 of = mile-sci-02. Looking at the implementation of this schema, it looks like the = targetNamespace is incorrectly assigned to = "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should = be "http://cve.mitre.org/cve/downloads/1.0". This will likely need to = be fixed. Also, the specification URI points to the CVE website, which is not = really a specification. It's not clear where to find guidance on how to = properly use the model indicated by the namespace. Without having clear = guidance on its use I don't see how we can make it MTI, even if it is = considered a de facto approach. It might make sense to produce a = specification for the model before making it MTI for the vulnerability = class. Sincerely, David Waltermire > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Brian Trammell > Sent: Wednesday, February 15, 2012 5:28 AM > To: Takeshi Takahashi > Cc: mile@ietf.org > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was > Re: MTI SCI?) > > Hi, Take, all, > > Thank you for this edit/clarification. > > On the first point, it does seem the discussion on the list converged=20 > rather quickly to CVE as MTI. However, as this is a rather important=20 > point, I'd like to make sure we didn't miss anything. > > So, I'd like to call for consensus on the list. Does the working group = > agree on the following two points? > > 1. mile-sci requires one Mandatory to Implement schema in order to=20 > ensure interoperability. > > 2. The Mandatory to Implement schema is the Common Vulnerability=20 > Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile-=20 > sci-02. > > Please note if you agree; if you disagree, please explain why not. > > Best regards, > > Brian (as chair) > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > Hello all, > > > > Following the discussion, I would like to add a couple of sentences > to > > clarify the MTI issues. > > (Thank you very much for those of you who kindly provided useful > > discussion.) > > I've attached the working version of the draft. I hope it helps to=20 > > clarify the changes. > > > > (added sentences at the end of section 4.1) > > > > The SpecID attributes of extended classes (Section 4.3) must allow > > the values of the specifications' namespace fields, but otherwise, > > implementations are not required to support all the above > > specifications. Implementations may choose which specifications = to > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > supported. In case an implementation received a data it does not > > support, it may expand its functionality by looking up the IANA > table or > > notify the sender of its inability to parse the data by using any > > means defined outside the scope of this specification. > > > > On the other hand, I would like to add "STRING ext-SpecID" to each=20 > > class, which enables to embed data following private schema. > > For instance, one security operation center (SOC) may wish to > exchange > > a vulnerability data that is formatted in its own private schema,=20 > > and that is not formatted in CVE. > > In this case, the SOC may put the data's schema ID inside ext-SpecID = > > and then embed the data. > > It could also be used to exchange data using beta version of > specifications. > > > > The class could be seen as below. > > > > +------------------------+ > > | AttackPattern | > > +------------------------+ > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > +------------------------+ > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > specifying the format of the RawData element. The value should > be > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > "private". Note that the lists in Section 4.1 will be = developed > > further by IANA. The value "private" is prepared for conveying > > RawData based on a format that is not listed in the > > table. This is usually used for conveying data formatted > > according to an organization's private schema. When the value > > "private" is used, ext-SpecID element needs to be used. > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > specification > > specifying the format of the RawData element. When this = element > > is used, the value of SpecID element must be "private." > > > > I hope above changes don't cause any complication here. > > > > Sincerely, > > Take > > > > > > > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On=20 > >> Behalf Of Martin, Robert A. > >> Sent: Wednesday, February 15, 2012 1:50 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] MTI SCI? > >> > >> At the risk of contradicting myself - but then again I have now=20 > >> read the other replies to this issue - I agree that having one area = > >> be > the > >> smoke test makes sense and I also agree that something simple and=20 > >> commonly used already - like CVE - is the best candidate for what=20 > >> we > need. > >> > >> Bob > >> > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > >>> CVE is widely used and understood by all in the the security > community. > >> I agree with Tom that CVE is the path of least resistance but may=20 > >> be the most useful for basic interoperability. > >>> > >>> Kent Landfield > >>> Director Content Strategy, Architecture and Standards > >>> > >>> McAfee | An Intel Company > >>> 5000 Headquarters Dr. > >>> Plano, Texas 75024 > >>> > >>> Direct: +1.972.963.7096 > >>> Mobile: +1.817.637.8026 > >>> Web: www.mcafee.com > >>> > >>> From: > >>> > >> "Thomas.Millar@us-cert.gov" >> s > >> .M > >>> illar@us-cert.gov> > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > >>> To: > >>> > >> "david.black@emc.com" >> o > >> m< > >>> mailto:david.black@emc.com>>, Bob > >>> Martin> > >>> Cc: > >>> > >> "mile@ietf.org" >> f > >> .o > >>> rg>> > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> My concern with CAPEC being mandatory is that it could discourage > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary=20 > >> remains "too comprehensive" for many CSIRTs to employ during > incident > >> handling and reporting activity. > >>> > >>> IODEF by itself has been criticized by CSIRT operators for being=20 > >>> more > >> heavyweight than necessary for day-to-day usage; making CAPEC a=20 > >> mandatory aspect of "advanced IODEF" seems like it would be adding=20 > >> ammunition to that argument, especially if the CSIRT is having to=20 > >> fund implementation out of their own pocket. Personally, I would > have > >> a hard time asking US-CERT's primary constituents to implement=20 > >> IODEF > >> + CAPEC if they are already balking at the consultant and developer > >> resources required to implement RFC 5070 by itself. Also keep in > mind > >> that CAPEC references CybOX, so there's wheels within wheels now. > >>> > >>> I would prefer we take the path of least resistance (from my > > perspective) > >> and make CVE the MTI, if we have to pick one additional spec. > >>> CVE is well known, has years of familiarity built in, and I think=20 > >>> it's > >> the simplest schema of the bunch. > >>> > >>> > >>> - Tom Millar, US-CERT > >>> > >>> thomas.millar@us-cert.gov > >>> BB: thomas.millar@dhs.gov / > >>> 202-631-1915 > >>> 24x7: soc@us-cert.gov / 888-282-0870 > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >>> [mailto:mile-bounces@ietf.org] On Behalf Of=20 > >>> david.black@emc.com > >>> Sent: Tuesday, February 14, 2012 11:14 > >>> To: ramartin@mitre.org > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> > >>> Hi Bob, > >>> > >>> I do appreciate the concern about implementing things that aren't=20 > >>> going > >> to be used. OTOH, it may be useful to have a single simple MTI=20 > >> spec for SCI that can be used to "smoke test" a deployment before=20 > >> trying any > > serious > >> test data (and "simple" is important). > >>> > >>> In addition, a concern that I would have with an MTI SCI spec per=20 > >>> class > >> is that if two SCI implementations don't have at least one class in > > common, > >> they aren't going to interoperate, and that situation is unlikely=20 > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per class, = > >> I suspect that there will also have to be an MTI class, which=20 > >> results in an overall MTI SCI spec). > >>> > >>> It may also be useful to include a simple example of the MTI SCI=20 > >>> spec > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > spec > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC=20 > >> XML document for testing purposes, including enumeration values=20 > >> suitable for testing). > >>> > >>> What do you (and others) think about this? > >>> > >>> Thanks, > >>> --David > >>> > >>> -----Original Message----- > >>> From: mile-bounces@ietf.org > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > >>> Sent: Tuesday, February 14, 2012 8:26 AM > >>> To: Brian Trammell > >>> Cc: mile@ietf.org > >>> Subject: Re: [mile] MTI SCI? > >>> Brian, > >>> You beat me to this point. Like you, I would be concerned about a = > >>> MTI selection that ended up requiring someone to implement > something > >>> to meet the MTI but wasn't germane to anything else they intended > to > >> support. > >>> Bob > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > >>>> Hi, Sean, all, > >>>> > >>>> Looking over the spec, it's not clear to me that one MTI makes=20 > >>>> sense here, given that mile-sci's > >>> purpose is to reference a set of external specifications by=20 > >>> inclusion in an IODEF document, and that those external=20 > >>> specifications represent > >> fundamentally different things. > >>>> > >>>> The specifications are split over their applicability to the=20 > >>>> IODEF extension classes. I could > >>> envision an mile-sci implementation that was only interested a=20 > >>> subset of these classes (perhaps even only one). If my=20 > >>> implementation has an internal representation of Verification, but = > >>> not of any of the other classes, and the MTI is an enumeration=20 > >>> that is applicable to > >> Vulnerability... what do I do? > >>>> > >>>> What about selecting an MTI per class, instead? > >>>> > >>>> Best regards, > >>>> > >>>> Brian (as contributor) > >>>> > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >>>> > >>>>> Great - as long as we pick one as the MTI. Note that MTI is not > >> necessarily mandatory to use. > >>>>> > >>>>> spt > >>>>> > >>>>> On 2/13/12 7:11 PM, > >> kathleen.moriarty@emc.com wrote: > >>>>>> Thank you for raising the interoperability testing as we need=20 > >>>>>> to plan for a bake-off that once > >>> these questions get answered and the draft is ready. > >>>>>> > >>>>>> Thanks, > >>>>>> Kathleen > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: mile-bounces@ietf.org > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > >>>>>> To: mile@ietf.org > >>>>>> Subject: [mile] MTI SCI? > >>>>>> > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information)=20 > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI=20 > >>>>>> (mandatory to implement) choice? In other words, how will you=20 > >>>>>> get two interoperability implementations without picking one? > >>>>>> > >>>>>> spt > >>>>>> _______________________________________________ > >>>>>> mile mailing list > >>>>>> mile@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> mile mailing list > >>>>> mile@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>>> . > >>>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >>> > >>> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > 03c > > > andidate_20120215.txt.pdf>____________________________________________ > > ___ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Tue Feb 21 09:49:13 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA92621F85D7 for ; Tue, 21 Feb 2012 09:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.61 X-Spam-Level: X-Spam-Status: No, score=-109.61 tagged_above=-999 required=5 tests=[AWL=0.989, 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 n-Tkam5xxw1c for ; Tue, 21 Feb 2012 09:49:08 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A908221F85AE for ; Tue, 21 Feb 2012 09:49:08 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LHn3hL028677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 12:49:06 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 21 Feb 2012 12:48:37 -0500 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LHma4T023420; Tue, 21 Feb 2012 12:48:37 -0500 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Tue, 21 Feb 2012 12:48:36 -0500 From: To: , Date: Tue, 21 Feb 2012 12:48:35 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtSVXlOfYIAA940AgAAPhFA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 17:49:13 -0000 Hi Tom, I believe I agree with you, although I'd like to add some precision on what= is meant by "parse". I don't think it's sufficient to support the value in the SpecID field (e.g= ., a CVE version) and accept an XML blob that is not a well-formed CVE XML document. Hence, I think the minimum requirement is to validate the received SCI XML = document against the appropriate XML schema and detect any errors. Beyond that, Take's reference to RFC 5070 is a useful source of insight, as= I think it rules out most additional requirements. IODEF is a format, not a protocol, = so: A) Error reporting is specific to whatever transport protocol is be= ing used. For example, if RID is used, the rfc6046-bis draft specifie= s how to report errors, but there's no RFC 5070 requirement that IOD= EF use RID. Beyond error detection, it's not possible to specify a requ= ired error reporting mechanism. B) RFC 5070 has nothing to say about replies or responses to IODEF,= so the same should be true of extensions like SCI. C) I'm not sure I understand what Take had in mind by "how to under= stand" in #2. I see no need to understand CVE semantics or meaning b= eyond the CVE syntax check obtained by validating the received document a= gainst the CVE XML schema. > I would recommend that we be very clear in regards to what "support" or "= minimally support" mean so > that technical requirements handed down based on this draft do not bar ac= hievement by operational > implementers and their engineering teams. I agree and would suggest: - The CVE SpecID value and related values (e.g., namespace) MUST be supported (not cause errors if used). - Recipient MUST validate received CVE XML document against the CVE XML schema to detect invalid CVE documents. I assume that this is all about CVE 1.0. Does all of this make sense? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of T= homas.Millar@us-cert.gov > Sent: Tuesday, February 21, 2012 12:00 PM > To: ariestake@googlemail.com; Moriarty, Kathleen; david.waltermire@nist.g= ov; trammell@tik.ee.ethz.ch; > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= s Re: MTI SCI?) > > Take, > > I think you've done a very good job of explaining the two different inter= pretations around this call > for consensus. > > My interpretation of MTI was closer to #2 - that to support this draft, a= n implementer would have to > support not only recognition of the namespace in the appropriate IODEF pa= rent class context, but also > be able to parse the content of the referenced namespace. Hence my prefer= ence for a relatively simple > and familiar spec as the MTI. > > If we can concur that we all really mean the interpretation you describe = under #1, then I'm okay with > having an MTI for each class. What that says to me is that each implement= er would need to conform to > the SCI draft's class placement of each namespace, but not necessarily ha= ve to be able to interpret > the contents of said namespace(s). So all I have to do, minimally, is rec= ognize the class under which > any of the referenced namespaces exist; I don't have to have any means to= parse or handle that class > content other than bucket it and move on to the next. Is that right? > > I would recommend that we be very clear in regards to what "support" or "= minimally support" mean so > that technical requirements handed down based on this draft do not bar ac= hievement by operational > implementers and their engineering teams. > > Thanks again, > > - Tom Millar, US-CERT > > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of T= akeshi Takahashi > Sent: Monday, February 20, 2012 20:40 > To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; trammell@tik.ee= .ethz.ch; > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= sRe: MTI SCI?) > > Hello all, > > Thank you for your kind comments, which are really useful for me. > On the other hand, I have some difficulties to understand what people spe= cifically mean by "support" > or "mandatory". > I would appreciate if you could kindly give me some comments on below. > > Below are my views on the MTI issues. > > 1. All the specification namespaces listed in the table MUST be > "supported" as values for the SpecID field. > > These namespaces are the allowed ENUM values. > So, in a way, all the specification listed in the table are supported. > (implementations must allow these namespaces of all the specifications li= sted in the table as values > for SpecID field) Since all the specification listed in the table are sup= ported, we need to have > expert review before registration (as we discussed in Quebec City) > > In this way, receivers can correctly understand the data. > That will give us the same level of interoperability as the RFC 5070 (IOD= EF) does between sender and > receiver, I think. > > > 2. Implementers have freedom to define how to parse, how to understand= , > and how to respond the IODEF extension message > > I might be wrong, but I do not think we would like to define how to parse= the IODEF extension message > at the receiver side. > And I do not think we would like to define how to parse, for instance, CA= PEC data, at the receiver > side. > I think the SCI draft is a container that conveys these structured inform= ation, and it can see such > information as a blackbox with a tag (namespace information). > > If above understanding is correct, I have some difficulty to understand t= he meaning of "mandatory to > support CVE". > As described in issue 1 above, if CVE or CAPEC data is attached, the impl= ementation needs to recognize > that the data is in CVE/CAPEC format, and that is the requirement for the= implementation. > What else do we want to mandate here, specifically? > Do we need to manipulate the embedded xml data itself? I rather prefer to= handle the data as a > blackbox. > > I appreciate your kind comments. > Regarding the other point Dave kindly pointed out, let me have another th= read. (sorry I need to get on > board now...) > > Thank you. > > Take > > > > > -----Original Message----- > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > Sent: Monday, February 20, 2012 8:08 PM > To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; takeshi_takahashi= @nict.go.jp > Cc: mile@ietf.org > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= s > Re: MTI SCI?) > > Thank you, Dave. > > Dave raises a few very important points as we consider MTI for SCI. We w= ill need to resolve these > issues if CVE is to be the (or an) MTI specification for the SCI draft. > > If CVE is mandatory to implement, what guidance would be followed on how = to use the model or will MTI > only mean that the document can be received and > parsed? The CVE website is listed as the specification URI, but from > Dave's message, the specification URI does not exist to provide the guida= nce (I get to broken link > pages for both - the existing and suggested replacement link). > > This is the closest I could find and may be the answer for guidance: > http://cve.mitre.org/compatible/requirements.html > > It looks like the reference to the target namespace needs to be fixed as = well. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Waltermi= re, David A. > [david.waltermire@nist.gov] > Sent: Thursday, February 16, 2012 5:26 PM > To: Brian Trammell; Takeshi Takahashi > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= s > Re: MTI SCI?) > > I have not been following this thread as closely as I probably should. > Relative to MTI, is the question what schema should be MTI for the vulera= bility class? In general I > think we should have one or more MTI for each class. > > Relative to CVE specifically, are we talking about the schema currently l= ocated at: > http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > This seems to match the namespace defined in section 4.1.7 of mile-sci-02= . > Looking at the implementation of this schema, it looks like the targetNam= espace is incorrectly > assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" whe= n it should be > "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be fi= xed. > > Also, the specification URI points to the CVE website, which is not reall= y a specification. It's not > clear where to find guidance on how to properly use the model indicated b= y the namespace. Without > having clear guidance on its use I don't see how we can make it MTI, even= if it is considered a de > facto approach. It might make sense to produce a specification for the m= odel before making it MTI for > the vulnerability class. > > Sincerely, > David Waltermire > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Brian Trammell > > Sent: Wednesday, February 15, 2012 5:28 AM > > To: Takeshi Takahashi > > Cc: mile@ietf.org > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was > > Re: MTI SCI?) > > > > Hi, Take, all, > > > > Thank you for this edit/clarification. > > > > On the first point, it does seem the discussion on the list converged > > rather quickly to CVE as MTI. However, as this is a rather important > > point, I'd like to make sure we didn't miss anything. > > > > So, I'd like to call for consensus on the list. Does the working group > > agree on the following two points? > > > > 1. mile-sci requires one Mandatory to Implement schema in order to > > ensure interoperability. > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- > > sci-02. > > > > Please note if you agree; if you disagree, please explain why not. > > > > Best regards, > > > > Brian (as chair) > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > Hello all, > > > > > > Following the discussion, I would like to add a couple of sentences > > to > > > clarify the MTI issues. > > > (Thank you very much for those of you who kindly provided useful > > > discussion.) > > > I've attached the working version of the draft. I hope it helps to > > > clarify the changes. > > > > > > (added sentences at the end of section 4.1) > > > > > > The SpecID attributes of extended classes (Section 4.3) must allow > > > the values of the specifications' namespace fields, but otherwise, > > > implementations are not required to support all the above > > > specifications. Implementations may choose which specifications to > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > supported. In case an implementation received a data it does not > > > support, it may expand its functionality by looking up the IANA > > table or > > > notify the sender of its inability to parse the data by using any > > > means defined outside the scope of this specification. > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > > class, which enables to embed data following private schema. > > > For instance, one security operation center (SOC) may wish to > > exchange > > > a vulnerability data that is formatted in its own private schema, > > > and that is not formatted in CVE. > > > In this case, the SOC may put the data's schema ID inside ext-SpecID > > > and then embed the data. > > > It could also be used to exchange data using beta version of > > specifications. > > > > > > The class could be seen as below. > > > > > > +------------------------+ > > > | AttackPattern | > > > +------------------------+ > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > +------------------------+ > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > specifying the format of the RawData element. The value should > > be > > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > > "private". Note that the lists in Section 4.1 will be developed > > > further by IANA. The value "private" is prepared for conveying > > > RawData based on a format that is not listed in the > > > table. This is usually used for conveying data formatted > > > according to an organization's private schema. When the value > > > "private" is used, ext-SpecID element needs to be used. > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > specification > > > specifying the format of the RawData element. When this element > > > is used, the value of SpecID element must be "private." > > > > > > I hope above changes don't cause any complication here. > > > > > > Sincerely, > > > Take > > > > > > > > > > > >> -----Original Message----- > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > >> Behalf Of Martin, Robert A. > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > >> To: Kent_Landfield@McAfee.com > > >> Cc: mile@ietf.org > > >> Subject: Re: [mile] MTI SCI? > > >> > > >> At the risk of contradicting myself - but then again I have now > > >> read the other replies to this issue - I agree that having one area > > >> be > > the > > >> smoke test makes sense and I also agree that something simple and > > >> commonly used already - like CVE - is the best candidate for what > > >> we > > need. > > >> > > >> Bob > > >> > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > >>> CVE is widely used and understood by all in the the security > > community. > > >> I agree with Tom that CVE is the path of least resistance but may > > >> be the most useful for basic interoperability. > > >>> > > >>> Kent Landfield > > >>> Director Content Strategy, Architecture and Standards > > >>> > > >>> McAfee | An Intel Company > > >>> 5000 Headquarters Dr. > > >>> Plano, Texas 75024 > > >>> > > >>> Direct: +1.972.963.7096 > > >>> Mobile: +1.817.637.8026 > > >>> Web: www.mcafee.com > > >>> > > >>> From: > > >>> > > >> "Thomas.Millar@us-cert.gov" > >> s > > >> .M > > >>> illar@us-cert.gov> > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > >>> To: > > >>> > > >> "david.black@emc.com" > >> o > > >> m< > > >>> mailto:david.black@emc.com>>, Bob > > >>> Martin> > > >>> Cc: > > >>> > > >> "mile@ietf.org" > >> f > > >> .o > > >>> rg>> > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> My concern with CAPEC being mandatory is that it could discourage > > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > > >> remains "too comprehensive" for many CSIRTs to employ during > > incident > > >> handling and reporting activity. > > >>> > > >>> IODEF by itself has been criticized by CSIRT operators for being > > >>> more > > >> heavyweight than necessary for day-to-day usage; making CAPEC a > > >> mandatory aspect of "advanced IODEF" seems like it would be adding > > >> ammunition to that argument, especially if the CSIRT is having to > > >> fund implementation out of their own pocket. Personally, I would > > have > > >> a hard time asking US-CERT's primary constituents to implement > > >> IODEF > > >> + CAPEC if they are already balking at the consultant and developer > > >> resources required to implement RFC 5070 by itself. Also keep in > > mind > > >> that CAPEC references CybOX, so there's wheels within wheels now. > > >>> > > >>> I would prefer we take the path of least resistance (from my > > > perspective) > > >> and make CVE the MTI, if we have to pick one additional spec. > > >>> CVE is well known, has years of familiarity built in, and I think > > >>> it's > > >> the simplest schema of the bunch. > > >>> > > >>> > > >>> - Tom Millar, US-CERT > > >>> > > >>> thomas.millar@us-cert.gov > > >>> BB: thomas.millar@dhs.gov / > > >>> 202-631-1915 > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > >>> david.black@emc.com > > >>> Sent: Tuesday, February 14, 2012 11:14 > > >>> To: ramartin@mitre.org > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> Hi Bob, > > >>> > > >>> I do appreciate the concern about implementing things that aren't > > >>> going > > >> to be used. OTOH, it may be useful to have a single simple MTI > > >> spec for SCI that can be used to "smoke test" a deployment before > > >> trying any > > > serious > > >> test data (and "simple" is important). > > >>> > > >>> In addition, a concern that I would have with an MTI SCI spec per > > >>> class > > >> is that if two SCI implementations don't have at least one class in > > > common, > > >> they aren't going to interoperate, and that situation is unlikely > > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per class, > > >> I suspect that there will also have to be an MTI class, which > > >> results in an overall MTI SCI spec). > > >>> > > >>> It may also be useful to include a simple example of the MTI SCI > > >>> spec > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > > spec > > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC > > >> XML document for testing purposes, including enumeration values > > >> suitable for testing). > > >>> > > >>> What do you (and others) think about this? > > >>> > > >>> Thanks, > > >>> --David > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > >>> To: Brian Trammell > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> Brian, > > >>> You beat me to this point. Like you, I would be concerned about a > > >>> MTI selection that ended up requiring someone to implement > > something > > >>> to meet the MTI but wasn't germane to anything else they intended > > to > > >> support. > > >>> Bob > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > >>>> Hi, Sean, all, > > >>>> > > >>>> Looking over the spec, it's not clear to me that one MTI makes > > >>>> sense here, given that mile-sci's > > >>> purpose is to reference a set of external specifications by > > >>> inclusion in an IODEF document, and that those external > > >>> specifications represent > > >> fundamentally different things. > > >>>> > > >>>> The specifications are split over their applicability to the > > >>>> IODEF extension classes. I could > > >>> envision an mile-sci implementation that was only interested a > > >>> subset of these classes (perhaps even only one). If my > > >>> implementation has an internal representation of Verification, but > > >>> not of any of the other classes, and the MTI is an enumeration > > >>> that is applicable to > > >> Vulnerability... what do I do? > > >>>> > > >>>> What about selecting an MTI per class, instead? > > >>>> > > >>>> Best regards, > > >>>> > > >>>> Brian (as contributor) > > >>>> > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > >>>> > > >>>>> Great - as long as we pick one as the MTI. Note that MTI is not > > >> necessarily mandatory to use. > > >>>>> > > >>>>> spt > > >>>>> > > >>>>> On 2/13/12 7:11 PM, > > >> kathleen.moriarty@emc.com wrote: > > >>>>>> Thank you for raising the interoperability testing as we need > > >>>>>> to plan for a bake-off that once > > >>> these questions get answered and the draft is ready. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Kathleen > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: mile-bounces@ietf.org > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > >>>>>> To: mile@ietf.org > > >>>>>> Subject: [mile] MTI SCI? > > >>>>>> > > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > > >>>>>> (mandatory to implement) choice? In other words, how will you > > >>>>>> get two interoperability implementations without picking one? > > >>>>>> > > >>>>>> spt > > >>>>>> _______________________________________________ > > >>>>>> mile mailing list > > >>>>>> mile@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> mile mailing list > > >>>>> mile@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>> _______________________________________________ > > >>>> mile mailing list > > >>>> mile@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> . > > >>>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> > > >> _______________________________________________ > > >> mile mailing list > > >> mile@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mile > > > > 03c > > > > > andidate_20120215.txt.pdf>____________________________________________ > > > ___ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.waltermire@nist.gov Tue Feb 21 12:57:10 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C4911E80A5 for ; Tue, 21 Feb 2012 12:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XBWJ1TCz2ZnU for ; Tue, 21 Feb 2012 12:57:05 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9F10411E80AC for ; Tue, 21 Feb 2012 12:57:04 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 15:57:20 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 21 Feb 2012 15:54:49 -0500 From: "Waltermire, David A." To: "kathleen.moriarty@emc.com" , "trammell@tik.ee.ethz.ch" , "takeshi_takahashi@nict.go.jp" Date: Tue, 21 Feb 2012 15:56:59 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AczrzDOx+UzUfup8TqGaleJkelzyYgBKnXqQALGDu2UARtezUA== Message-ID: References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> , 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" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 20:57:10 -0000 For all referenced models, a larger concern is referencing a website for guidance. A website can be inherantly unstable, as it can be changed at any time, and does not necessarily represent a consensous opinion. One possibility might be to reference a standards track document that specified the use of the model. In addition the referenced document could possibly provide some parsing instructions for the model addressing some of the concerns from the other discussion thread. This would require new work to be completed before completing the SCI document, but would provide a more concrete foundation for interoperable information exchange. Any thoughts on this approach? Sincerely, David Waltermire > -----Original Message----- > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > Sent: Monday, February 20, 2012 6:08 AM > To: Waltermire, David A.; trammell@tik.ee.ethz.ch; > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > (was Re: MTI SCI?) > > Thank you, Dave. > > Dave raises a few very important points as we consider MTI for SCI. We > will need to resolve these issues if CVE is to be the (or an) MTI > specification for the SCI draft. > > If CVE is mandatory to implement, what guidance would be followed on > how to use the model or will MTI only mean that the document can be > received and parsed? The CVE website is listed as the specification > URI, but from Dave's message, the specification URI does not exist to > provide the guidance (I get to broken link pages for both - the > existing and suggested replacement link). > > This is the closest I could find and may be the answer for guidance: > http://cve.mitre.org/compatible/requirements.html > > It looks like the reference to the target namespace needs to be fixed > as well. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > Waltermire, David A. [david.waltermire@nist.gov] > Sent: Thursday, February 16, 2012 5:26 PM > To: Brian Trammell; Takeshi Takahashi > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > (was Re: MTI SCI?) > > I have not been following this thread as closely as I probably should. > Relative to MTI, is the question what schema should be MTI for the > vulerability class? In general I think we should have one or more MTI > for each class. > > Relative to CVE specifically, are we talking about the schema currently > located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > This seems to match the namespace defined in section 4.1.7 of mile-sci- > 02. Looking at the implementation of this schema, it looks like the > targetNamespace is incorrectly assigned to > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it > should be "http://cve.mitre.org/cve/downloads/1.0". This will likely > need to be fixed. > > Also, the specification URI points to the CVE website, which is not > really a specification. It's not clear where to find guidance on how > to properly use the model indicated by the namespace. Without having > clear guidance on its use I don't see how we can make it MTI, even if > it is considered a de facto approach. It might make sense to produce a > specification for the model before making it MTI for the vulnerability > class. > > Sincerely, > David Waltermire > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Brian Trammell > > Sent: Wednesday, February 15, 2012 5:28 AM > > To: Takeshi Takahashi > > Cc: mile@ietf.org > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI > (was > > Re: MTI SCI?) > > > > Hi, Take, all, > > > > Thank you for this edit/clarification. > > > > On the first point, it does seem the discussion on the list converged > > rather quickly to CVE as MTI. However, as this is a rather important > > point, I'd like to make sure we didn't miss anything. > > > > So, I'd like to call for consensus on the list. Does the working > group > > agree on the following two points? > > > > 1. mile-sci requires one Mandatory to Implement schema in order to > > ensure interoperability. > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- > > sci-02. > > > > Please note if you agree; if you disagree, please explain why not. > > > > Best regards, > > > > Brian (as chair) > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > Hello all, > > > > > > Following the discussion, I would like to add a couple of sentences > > to > > > clarify the MTI issues. > > > (Thank you very much for those of you who kindly provided useful > > > discussion.) > > > I've attached the working version of the draft. I hope it helps to > > > clarify the changes. > > > > > > (added sentences at the end of section 4.1) > > > > > > The SpecID attributes of extended classes (Section 4.3) must > allow > > > the values of the specifications' namespace fields, but > otherwise, > > > implementations are not required to support all the above > > > specifications. Implementations may choose which specifications > to > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > supported. In case an implementation received a data it does not > > > support, it may expand its functionality by looking up the IANA > > table or > > > notify the sender of its inability to parse the data by using any > > > means defined outside the scope of this specification. > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > > class, which enables to embed data following private schema. > > > For instance, one security operation center (SOC) may wish to > > exchange > > > a vulnerability data that is formatted in its own private schema, > > > and that is not formatted in CVE. > > > In this case, the SOC may put the data's schema ID inside ext- > SpecID > > > and then embed the data. > > > It could also be used to exchange data using beta version of > > specifications. > > > > > > The class could be seen as below. > > > > > > +------------------------+ > > > | AttackPattern | > > > +------------------------+ > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > +------------------------+ > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > specifying the format of the RawData element. The value > should > > be > > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > > "private". Note that the lists in Section 4.1 will be > developed > > > further by IANA. The value "private" is prepared for conveying > > > RawData based on a format that is not listed in the > > > table. This is usually used for conveying data formatted > > > according to an organization's private schema. When the value > > > "private" is used, ext-SpecID element needs to be used. > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > specification > > > specifying the format of the RawData element. When this > element > > > is used, the value of SpecID element must be "private." > > > > > > I hope above changes don't cause any complication here. > > > > > > Sincerely, > > > Take > > > > > > > > > > > >> -----Original Message----- > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > >> Behalf Of Martin, Robert A. > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > >> To: Kent_Landfield@McAfee.com > > >> Cc: mile@ietf.org > > >> Subject: Re: [mile] MTI SCI? > > >> > > >> At the risk of contradicting myself - but then again I have now > > >> read the other replies to this issue - I agree that having one > area > > >> be > > the > > >> smoke test makes sense and I also agree that something simple and > > >> commonly used already - like CVE - is the best candidate for what > > >> we > > need. > > >> > > >> Bob > > >> > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > >>> CVE is widely used and understood by all in the the security > > community. > > >> I agree with Tom that CVE is the path of least resistance but may > > >> be the most useful for basic interoperability. > > >>> > > >>> Kent Landfield > > >>> Director Content Strategy, Architecture and Standards > > >>> > > >>> McAfee | An Intel Company > > >>> 5000 Headquarters Dr. > > >>> Plano, Texas 75024 > > >>> > > >>> Direct: +1.972.963.7096 > > >>> Mobile: +1.817.637.8026 > > >>> Web: www.mcafee.com > > >>> > > >>> From: > > >>> > > >> "Thomas.Millar@us-cert.gov cert.gov>" > >> s > > >> .M > > >>> illar@us-cert.gov> > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > >>> To: > > >>> > > >> > "david.black@emc.com" > >> o > > >> m< > > >>> mailto:david.black@emc.com>>, Bob > > >>> Martin> > > >>> Cc: > > >>> > > >> > "mile@ietf.org" > >> f > > >> .o > > >>> rg>> > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> My concern with CAPEC being mandatory is that it could discourage > > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > > >> remains "too comprehensive" for many CSIRTs to employ during > > incident > > >> handling and reporting activity. > > >>> > > >>> IODEF by itself has been criticized by CSIRT operators for being > > >>> more > > >> heavyweight than necessary for day-to-day usage; making CAPEC a > > >> mandatory aspect of "advanced IODEF" seems like it would be adding > > >> ammunition to that argument, especially if the CSIRT is having to > > >> fund implementation out of their own pocket. Personally, I would > > have > > >> a hard time asking US-CERT's primary constituents to implement > > >> IODEF > > >> + CAPEC if they are already balking at the consultant and > developer > > >> resources required to implement RFC 5070 by itself. Also keep in > > mind > > >> that CAPEC references CybOX, so there's wheels within wheels now. > > >>> > > >>> I would prefer we take the path of least resistance (from my > > > perspective) > > >> and make CVE the MTI, if we have to pick one additional spec. > > >>> CVE is well known, has years of familiarity built in, and I think > > >>> it's > > >> the simplest schema of the bunch. > > >>> > > >>> > > >>> - Tom Millar, US-CERT > > >>> > > >>> thomas.millar@us-cert.gov > > >>> BB: thomas.millar@dhs.gov / > > >>> 202-631-1915 > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > >>> david.black@emc.com > > >>> Sent: Tuesday, February 14, 2012 11:14 > > >>> To: ramartin@mitre.org > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> Hi Bob, > > >>> > > >>> I do appreciate the concern about implementing things that aren't > > >>> going > > >> to be used. OTOH, it may be useful to have a single simple MTI > > >> spec for SCI that can be used to "smoke test" a deployment before > > >> trying any > > > serious > > >> test data (and "simple" is important). > > >>> > > >>> In addition, a concern that I would have with an MTI SCI spec per > > >>> class > > >> is that if two SCI implementations don't have at least one class > in > > > common, > > >> they aren't going to interoperate, and that situation is unlikely > > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per > class, > > >> I suspect that there will also have to be an MTI class, which > > >> results in an overall MTI SCI spec). > > >>> > > >>> It may also be useful to include a simple example of the MTI SCI > > >>> spec > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > > spec > > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC > > >> XML document for testing purposes, including enumeration values > > >> suitable for testing). > > >>> > > >>> What do you (and others) think about this? > > >>> > > >>> Thanks, > > >>> --David > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > >>> To: Brian Trammell > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> Brian, > > >>> You beat me to this point. Like you, I would be concerned about > a > > >>> MTI selection that ended up requiring someone to implement > > something > > >>> to meet the MTI but wasn't germane to anything else they intended > > to > > >> support. > > >>> Bob > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > >>>> Hi, Sean, all, > > >>>> > > >>>> Looking over the spec, it's not clear to me that one MTI makes > > >>>> sense here, given that mile-sci's > > >>> purpose is to reference a set of external specifications by > > >>> inclusion in an IODEF document, and that those external > > >>> specifications represent > > >> fundamentally different things. > > >>>> > > >>>> The specifications are split over their applicability to the > > >>>> IODEF extension classes. I could > > >>> envision an mile-sci implementation that was only interested a > > >>> subset of these classes (perhaps even only one). If my > > >>> implementation has an internal representation of Verification, > but > > >>> not of any of the other classes, and the MTI is an enumeration > > >>> that is applicable to > > >> Vulnerability... what do I do? > > >>>> > > >>>> What about selecting an MTI per class, instead? > > >>>> > > >>>> Best regards, > > >>>> > > >>>> Brian (as contributor) > > >>>> > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > >>>> > > >>>>> Great - as long as we pick one as the MTI. Note that MTI is > not > > >> necessarily mandatory to use. > > >>>>> > > >>>>> spt > > >>>>> > > >>>>> On 2/13/12 7:11 PM, > > >> kathleen.moriarty@emc.com > wrote: > > >>>>>> Thank you for raising the interoperability testing as we need > > >>>>>> to plan for a bake-off that once > > >>> these questions get answered and the draft is ready. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Kathleen > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: mile-bounces@ietf.org > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > >>>>>> To: mile@ietf.org > > >>>>>> Subject: [mile] MTI SCI? > > >>>>>> > > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > > >>>>>> (mandatory to implement) choice? In other words, how will you > > >>>>>> get two interoperability implementations without picking one? > > >>>>>> > > >>>>>> spt > > >>>>>> _______________________________________________ > > >>>>>> mile mailing list > > >>>>>> mile@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> mile mailing list > > >>>>> mile@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>> _______________________________________________ > > >>>> mile mailing list > > >>>> mile@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> . > > >>>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> > > >> _______________________________________________ > > >> mile mailing list > > >> mile@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mile > > > > 03c > > > > > > andidate_20120215.txt.pdf>____________________________________________ > > > ___ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Thomas.Millar@us-cert.gov Tue Feb 21 13:17:37 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A229E21F888B for ; Tue, 21 Feb 2012 13:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, 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 gaXo5ii7O7W5 for ; Tue, 21 Feb 2012 13:17:33 -0800 (PST) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [208.73.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id 542EA21F8888 for ; Tue, 21 Feb 2012 13:17:33 -0800 (PST) Received: from daphne.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 875193F964; Tue, 21 Feb 2012 21:17:32 +0000 (UTC) Received: from yabba.bronze.us-cert.gov (yabba.bronze.us-cert.gov [192.168.2.22]) by daphne.brass.us-cert.gov (Postfix) with ESMTP id 4FCC53F963; Tue, 21 Feb 2012 21:17:32 +0000 (UTC) Received: from needle.bronze.us-cert.gov (unknown [192.168.16.109]) by yabba.bronze.us-cert.gov (Postfix) with ESMTP id DFE9B3006A; Tue, 21 Feb 2012 21:17:31 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 15:17:31 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Feb 2012 15:17:31 -0600 Message-ID: In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtSVXlOfYIAA940AgAAPhFCAAETQYA== References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> From: To: , X-OriginalArrivalTime: 21 Feb 2012 21:17:31.0599 (UTC) FILETIME=[38F68DF0:01CCF0DE] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18724.001 X-TM-AS-Result: No--49.961-5.0-31-1 X-imss-scan-details: No--49.961-5.0-31-1 X-IMSS-DKIM-White-List: No Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:17:37 -0000 Should a recipient be required to validate a referenced schema even if = they don't intend to interpret the content? - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: david.black@emc.com [mailto:david.black@emc.com]=20 Sent: Tuesday, February 21, 2012 12:49 To: mile@ietf.org; Millar, Thomas R Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI = (wasRe: MTI SCI?) Hi Tom, I believe I agree with you, although I'd like to add some precision on = what is meant by "parse". I don't think it's sufficient to support the value in the SpecID field = (e.g., a CVE version) and accept an XML blob that is not a well-formed CVE XML = document. Hence, I think the minimum requirement is to validate the received SCI = XML document against the appropriate XML schema and detect any errors. Beyond that, Take's reference to RFC 5070 is a useful source of insight, = as I think it rules out most additional requirements. IODEF is a format, = not a protocol, so: A) Error reporting is specific to whatever transport protocol is = being used. For example, if RID is used, the rfc6046-bis draft = specifies how to report errors, but there's no RFC 5070 requirement that = IODEF use RID. Beyond error detection, it's not possible to specify a = required error reporting mechanism. B) RFC 5070 has nothing to say about replies or responses to = IODEF, so the same should be true of extensions like SCI. C) I'm not sure I understand what Take had in mind by "how to = understand" in #2. I see no need to understand CVE semantics or = meaning beyond the CVE syntax check obtained by validating the received = document against the CVE XML schema. > I would recommend that we be very clear in regards to what "support"=20 > or "minimally support" mean so that technical requirements handed down = > based on this draft do not bar achievement by operational implementers = and their engineering teams. I agree and would suggest: - The CVE SpecID value and related values (e.g., namespace) MUST be supported (not cause errors if used). - Recipient MUST validate received CVE XML document against the = CVE XML schema to detect invalid CVE documents. I assume that this is all about CVE 1.0. Does all of this make sense? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Thomas.Millar@us-cert.gov > Sent: Tuesday, February 21, 2012 12:00 PM > To: ariestake@googlemail.com; Moriarty, Kathleen;=20 > david.waltermire@nist.gov; trammell@tik.ee.ethz.ch;=20 > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI=20 > (was Re: MTI SCI?) > > Take, > > I think you've done a very good job of explaining the two different=20 > interpretations around this call for consensus. > > My interpretation of MTI was closer to #2 - that to support this=20 > draft, an implementer would have to support not only recognition of=20 > the namespace in the appropriate IODEF parent class context, but also=20 > be able to parse the content of the referenced namespace. Hence my = preference for a relatively simple and familiar spec as the MTI. > > If we can concur that we all really mean the interpretation you=20 > describe under #1, then I'm okay with having an MTI for each class.=20 > What that says to me is that each implementer would need to conform to = > the SCI draft's class placement of each namespace, but not necessarily = > have to be able to interpret the contents of said namespace(s). So all = > I have to do, minimally, is recognize the class under which any of the = referenced namespaces exist; I don't have to have any means to parse or = handle that class content other than bucket it and move on to the next. = Is that right? > > I would recommend that we be very clear in regards to what "support"=20 > or "minimally support" mean so that technical requirements handed down = > based on this draft do not bar achievement by operational implementers = and their engineering teams. > > Thanks again, > > - Tom Millar, US-CERT > > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20 > Of Takeshi Takahashi > Sent: Monday, February 20, 2012 20:40 > To: kathleen.moriarty@emc.com; david.waltermire@nist.gov;=20 > trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI=20 > (wasRe: MTI SCI?) > > Hello all, > > Thank you for your kind comments, which are really useful for me. > On the other hand, I have some difficulties to understand what people = specifically mean by "support" > or "mandatory". > I would appreciate if you could kindly give me some comments on below. > > Below are my views on the MTI issues. > > 1. All the specification namespaces listed in the table MUST be > "supported" as values for the SpecID field. > > These namespaces are the allowed ENUM values. > So, in a way, all the specification listed in the table are supported. > (implementations must allow these namespaces of all the specifications = > listed in the table as values for SpecID field) Since all the=20 > specification listed in the table are supported, we need to have=20 > expert review before registration (as we discussed in Quebec City) > > In this way, receivers can correctly understand the data. > That will give us the same level of interoperability as the RFC 5070=20 > (IODEF) does between sender and receiver, I think. > > > 2. Implementers have freedom to define how to parse, how to = understand, > and how to respond the IODEF extension message > > I might be wrong, but I do not think we would like to define how to=20 > parse the IODEF extension message at the receiver side. > And I do not think we would like to define how to parse, for instance, = > CAPEC data, at the receiver side. > I think the SCI draft is a container that conveys these structured=20 > information, and it can see such information as a blackbox with a tag = (namespace information). > > If above understanding is correct, I have some difficulty to=20 > understand the meaning of "mandatory to support CVE". > As described in issue 1 above, if CVE or CAPEC data is attached, the=20 > implementation needs to recognize that the data is in CVE/CAPEC = format, and that is the requirement for the implementation. > What else do we want to mandate here, specifically? > Do we need to manipulate the embedded xml data itself? I rather prefer = > to handle the data as a blackbox. > > I appreciate your kind comments. > Regarding the other point Dave kindly pointed out, let me have another = > thread. (sorry I need to get on board now...) > > Thank you. > > Take > > > > > -----Original Message----- > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > Sent: Monday, February 20, 2012 8:08 PM > To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch;=20 > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI=20 > (was > Re: MTI SCI?) > > Thank you, Dave. > > Dave raises a few very important points as we consider MTI for SCI. =20 > We will need to resolve these issues if CVE is to be the (or an) MTI = specification for the SCI draft. > > If CVE is mandatory to implement, what guidance would be followed on=20 > how to use the model or will MTI only mean that the document can be = received and > parsed? The CVE website is listed as the specification URI, but from > Dave's message, the specification URI does not exist to provide the=20 > guidance (I get to broken link pages for both - the existing and = suggested replacement link). > > This is the closest I could find and may be the answer for guidance: > http://cve.mitre.org/compatible/requirements.html > > It looks like the reference to the target namespace needs to be fixed = as well. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Waltermire, David A. > [david.waltermire@nist.gov] > Sent: Thursday, February 16, 2012 5:26 PM > To: Brian Trammell; Takeshi Takahashi > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI=20 > (was > Re: MTI SCI?) > > I have not been following this thread as closely as I probably should. > Relative to MTI, is the question what schema should be MTI for the=20 > vulerability class? In general I think we should have one or more MTI = for each class. > > Relative to CVE specifically, are we talking about the schema = currently located at: > http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > This seems to match the namespace defined in section 4.1.7 of = mile-sci-02. > Looking at the implementation of this schema, it looks like the=20 > targetNamespace is incorrectly assigned to=20 > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it = should be "http://cve.mitre.org/cve/downloads/1.0". This will likely = need to be fixed. > > Also, the specification URI points to the CVE website, which is not=20 > really a specification. It's not clear where to find guidance on how=20 > to properly use the model indicated by the namespace. Without having=20 > clear guidance on its use I don't see how we can make it MTI, even if=20 > it is considered a de facto approach. It might make sense to produce = a specification for the model before making it MTI for the vulnerability = class. > > Sincerely, > David Waltermire > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = > > Of Brian Trammell > > Sent: Wednesday, February 15, 2012 5:28 AM > > To: Takeshi Takahashi > > Cc: mile@ietf.org > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI=20 > > (was > > Re: MTI SCI?) > > > > Hi, Take, all, > > > > Thank you for this edit/clarification. > > > > On the first point, it does seem the discussion on the list=20 > > converged rather quickly to CVE as MTI. However, as this is a rather = > > important point, I'd like to make sure we didn't miss anything. > > > > So, I'd like to call for consensus on the list. Does the working=20 > > group agree on the following two points? > > > > 1. mile-sci requires one Mandatory to Implement schema in order to=20 > > ensure interoperability. > > > > 2. The Mandatory to Implement schema is the Common Vulnerability=20 > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of=20 > > mile- sci-02. > > > > Please note if you agree; if you disagree, please explain why not. > > > > Best regards, > > > > Brian (as chair) > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > Hello all, > > > > > > Following the discussion, I would like to add a couple of=20 > > > sentences > > to > > > clarify the MTI issues. > > > (Thank you very much for those of you who kindly provided useful > > > discussion.) > > > I've attached the working version of the draft. I hope it helps to = > > > clarify the changes. > > > > > > (added sentences at the end of section 4.1) > > > > > > The SpecID attributes of extended classes (Section 4.3) must = allow > > > the values of the specifications' namespace fields, but = otherwise, > > > implementations are not required to support all the above > > > specifications. Implementations may choose which specifications = to > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > supported. In case an implementation received a data it does = not > > > support, it may expand its functionality by looking up the IANA > > table or > > > notify the sender of its inability to parse the data by using = any > > > means defined outside the scope of this specification. > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to each = > > > class, which enables to embed data following private schema. > > > For instance, one security operation center (SOC) may wish to > > exchange > > > a vulnerability data that is formatted in its own private schema,=20 > > > and that is not formatted in CVE. > > > In this case, the SOC may put the data's schema ID inside=20 > > > ext-SpecID and then embed the data. > > > It could also be used to exchange data using beta version of > > specifications. > > > > > > The class could be seen as below. > > > > > > +------------------------+ > > > | AttackPattern | > > > +------------------------+ > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > +------------------------+ > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > specifying the format of the RawData element. The value=20 > > > should > > be > > > chosen from the namespaces [XMLNames] listed in Section 4.1 = or > > > "private". Note that the lists in Section 4.1 will be = developed > > > further by IANA. The value "private" is prepared for = conveying > > > RawData based on a format that is not listed in the > > > table. This is usually used for conveying data formatted > > > according to an organization's private schema. When the = value > > > "private" is used, ext-SpecID element needs to be used. > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > specification > > > specifying the format of the RawData element. When this = element > > > is used, the value of SpecID element must be "private." > > > > > > I hope above changes don't cause any complication here. > > > > > > Sincerely, > > > Take > > > > > > > > > > > >> -----Original Message----- > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On=20 > > >> Behalf Of Martin, Robert A. > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > >> To: Kent_Landfield@McAfee.com > > >> Cc: mile@ietf.org > > >> Subject: Re: [mile] MTI SCI? > > >> > > >> At the risk of contradicting myself - but then again I have now=20 > > >> read the other replies to this issue - I agree that having one=20 > > >> area be > > the > > >> smoke test makes sense and I also agree that something simple and = > > >> commonly used already - like CVE - is the best candidate for what = > > >> we > > need. > > >> > > >> Bob > > >> > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > >>> CVE is widely used and understood by all in the the security > > community. > > >> I agree with Tom that CVE is the path of least resistance but may = > > >> be the most useful for basic interoperability. > > >>> > > >>> Kent Landfield > > >>> Director Content Strategy, Architecture and Standards > > >>> > > >>> McAfee | An Intel Company > > >>> 5000 Headquarters Dr. > > >>> Plano, Texas 75024 > > >>> > > >>> Direct: +1.972.963.7096 > > >>> Mobile: +1.817.637.8026 > > >>> Web: www.mcafee.com > > >>> > > >>> From: > > >>> > > >> "Thomas.Millar@us-cert.gov" > >> ma > > >> s > > >> .M > > >>> illar@us-cert.gov> > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > >>> To: > > >>> > > >> "david.black@emc.com" > >> .c > > >> o > > >> m< > > >>> mailto:david.black@emc.com>>, Bob=20 > > >>> Martin> > > >>> Cc: > > >>> > > >> "mile@ietf.org" > >> et > > >> f > > >> .o > > >>> rg>> > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> My concern with CAPEC being mandatory is that it could=20 > > >>> discourage > > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary = > > >> remains "too comprehensive" for many CSIRTs to employ during > > incident > > >> handling and reporting activity. > > >>> > > >>> IODEF by itself has been criticized by CSIRT operators for being = > > >>> more > > >> heavyweight than necessary for day-to-day usage; making CAPEC a=20 > > >> mandatory aspect of "advanced IODEF" seems like it would be=20 > > >> adding ammunition to that argument, especially if the CSIRT is=20 > > >> having to fund implementation out of their own pocket.=20 > > >> Personally, I would > > have > > >> a hard time asking US-CERT's primary constituents to implement=20 > > >> IODEF > > >> + CAPEC if they are already balking at the consultant and=20 > > >> + developer > > >> resources required to implement RFC 5070 by itself. Also keep in > > mind > > >> that CAPEC references CybOX, so there's wheels within wheels now. > > >>> > > >>> I would prefer we take the path of least resistance (from my > > > perspective) > > >> and make CVE the MTI, if we have to pick one additional spec. > > >>> CVE is well known, has years of familiarity built in, and I=20 > > >>> think it's > > >> the simplest schema of the bunch. > > >>> > > >>> > > >>> - Tom Millar, US-CERT > > >>> > > >>> thomas.millar@us-cert.gov > > >>> BB: thomas.millar@dhs.gov / > > >>> 202-631-1915 > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of=20 > > >>> david.black@emc.com > > >>> Sent: Tuesday, February 14, 2012 11:14 > > >>> To: ramartin@mitre.org > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> Hi Bob, > > >>> > > >>> I do appreciate the concern about implementing things that=20 > > >>> aren't going > > >> to be used. OTOH, it may be useful to have a single simple MTI=20 > > >> spec for SCI that can be used to "smoke test" a deployment before = > > >> trying any > > > serious > > >> test data (and "simple" is important). > > >>> > > >>> In addition, a concern that I would have with an MTI SCI spec=20 > > >>> per class > > >> is that if two SCI implementations don't have at least one class=20 > > >> in > > > common, > > >> they aren't going to interoperate, and that situation is unlikely = > > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per=20 > > >> class, I suspect that there will also have to be an MTI class,=20 > > >> which results in an overall MTI SCI spec). > > >>> > > >>> It may also be useful to include a simple example of the MTI SCI = > > >>> spec > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > > spec > > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC=20 > > >> XML document for testing purposes, including enumeration values=20 > > >> suitable for testing). > > >>> > > >>> What do you (and others) think about this? > > >>> > > >>> Thanks, > > >>> --David > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > >>> To: Brian Trammell > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> Brian, > > >>> You beat me to this point. Like you, I would be concerned about = > > >>> a MTI selection that ended up requiring someone to implement > > something > > >>> to meet the MTI but wasn't germane to anything else they=20 > > >>> intended > > to > > >> support. > > >>> Bob > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > >>>> Hi, Sean, all, > > >>>> > > >>>> Looking over the spec, it's not clear to me that one MTI makes=20 > > >>>> sense here, given that mile-sci's > > >>> purpose is to reference a set of external specifications by=20 > > >>> inclusion in an IODEF document, and that those external=20 > > >>> specifications represent > > >> fundamentally different things. > > >>>> > > >>>> The specifications are split over their applicability to the=20 > > >>>> IODEF extension classes. I could > > >>> envision an mile-sci implementation that was only interested a=20 > > >>> subset of these classes (perhaps even only one). If my=20 > > >>> implementation has an internal representation of Verification,=20 > > >>> but not of any of the other classes, and the MTI is an=20 > > >>> enumeration that is applicable to > > >> Vulnerability... what do I do? > > >>>> > > >>>> What about selecting an MTI per class, instead? > > >>>> > > >>>> Best regards, > > >>>> > > >>>> Brian (as contributor) > > >>>> > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > >>>> > > >>>>> Great - as long as we pick one as the MTI. Note that MTI is=20 > > >>>>> not > > >> necessarily mandatory to use. > > >>>>> > > >>>>> spt > > >>>>> > > >>>>> On 2/13/12 7:11 PM, > > >> kathleen.moriarty@emc.com = wrote: > > >>>>>> Thank you for raising the interoperability testing as we need = > > >>>>>> to plan for a bake-off that once > > >>> these questions get answered and the draft is ready. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Kathleen > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: mile-bounces@ietf.org > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > >>>>>> To: mile@ietf.org > > >>>>>> Subject: [mile] MTI SCI? > > >>>>>> > > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information)=20 > > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI=20 > > >>>>>> (mandatory to implement) choice? In other words, how will=20 > > >>>>>> you get two interoperability implementations without picking = one? > > >>>>>> > > >>>>>> spt > > >>>>>> _______________________________________________ > > >>>>>> mile mailing list > > >>>>>> mile@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> mile mailing list > > >>>>> mile@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>> _______________________________________________ > > >>>> mile mailing list > > >>>> mile@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> . > > >>>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> > > >> _______________________________________________ > > >> mile mailing list > > >> mile@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > - > > 03c > > > > > andidate_20120215.txt.pdf>__________________________________________ > > __ > > > ___ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From ramartin@mitre.org Tue Feb 21 13:20:25 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6D321F8893 for ; Tue, 21 Feb 2012 13:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ke2GI4IDBgE0 for ; Tue, 21 Feb 2012 13:20:20 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECC721F8866 for ; Tue, 21 Feb 2012 13:20:20 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF76521B1817; Tue, 21 Feb 2012 16:20:19 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4DB3521B180C; Tue, 21 Feb 2012 16:20:19 -0500 (EST) Received: from bvb-172-31-33-177.mitre.org (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server id 14.1.339.1; Tue, 21 Feb 2012 16:20:16 -0500 Message-ID: <4F440A82.5070904@mitre.org> Date: Tue, 21 Feb 2012 16:20:02 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:20:25 -0000 I would like to offer that for some of the "ID" like things (i.e. CVE ID, CWE ID, and CAPEC ID) there may not be a need for an xml document and we may want to simplify those construct in SCI. Most people who send a CVE ID send a ascii text string 'CVE-xxx-xxxx' and assume that the reciever knows that there is a well established cgi url 'http://cve.mitre.org/cgi-bin/cvename.cgi?name=xxxx-xxxx' where the recipient can look up the details about CVE-xxxx-xxxx. CWE and CAPEC IDs have a similar well known address to resolve their IDs at. Bob On 2/21/12 12:48 PM, david.black@emc.com wrote: > Hi Tom, > > I believe I agree with you, although I'd like to add some precision on what is meant > by "parse". > > I don't think it's sufficient to support the value in the SpecID field (e.g., a CVE > version) and accept an XML blob that is not a well-formed CVE XML document. > > Hence, I think the minimum requirement is to validate the received SCI XML document > against the appropriate XML schema and detect any errors. > > Beyond that, Take's reference to RFC 5070 is a useful source of insight, as I think it > rules out most additional requirements. IODEF is a format, not a protocol, so: > > A) Error reporting is specific to whatever transport protocol is being used. > For example, if RID is used, the rfc6046-bis draft specifies how to > report errors, but there's no RFC 5070 requirement that IODEF use RID. > Beyond error detection, it's not possible to specify a required error > reporting mechanism. > > B) RFC 5070 has nothing to say about replies or responses to IODEF, so the > same should be true of extensions like SCI. > > C) I'm not sure I understand what Take had in mind by "how to understand" in > #2. I see no need to understand CVE semantics or meaning beyond the CVE > syntax check obtained by validating the received document against the > CVE XML schema. > >> I would recommend that we be very clear in regards to what "support" or "minimally support" mean so >> that technical requirements handed down based on this draft do not bar achievement by operational >> implementers and their engineering teams. > > I agree and would suggest: > > - The CVE SpecID value and related values (e.g., namespace) MUST > be supported (not cause errors if used). > - Recipient MUST validate received CVE XML document against the CVE > XML schema to detect invalid CVE documents. > > I assume that this is all about CVE 1.0. > > Does all of this make sense? > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Thomas.Millar@us-cert.gov >> Sent: Tuesday, February 21, 2012 12:00 PM >> To: ariestake@googlemail.com; Moriarty, Kathleen; david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >> takeshi_takahashi@nict.go.jp >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) >> >> Take, >> >> I think you've done a very good job of explaining the two different interpretations around this call >> for consensus. >> >> My interpretation of MTI was closer to #2 - that to support this draft, an implementer would have to >> support not only recognition of the namespace in the appropriate IODEF parent class context, but also >> be able to parse the content of the referenced namespace. Hence my preference for a relatively simple >> and familiar spec as the MTI. >> >> If we can concur that we all really mean the interpretation you describe under #1, then I'm okay with >> having an MTI for each class. What that says to me is that each implementer would need to conform to >> the SCI draft's class placement of each namespace, but not necessarily have to be able to interpret >> the contents of said namespace(s). So all I have to do, minimally, is recognize the class under which >> any of the referenced namespaces exist; I don't have to have any means to parse or handle that class >> content other than bucket it and move on to the next. Is that right? >> >> I would recommend that we be very clear in regards to what "support" or "minimally support" mean so >> that technical requirements handed down based on this draft do not bar achievement by operational >> implementers and their engineering teams. >> >> Thanks again, >> >> - Tom Millar, US-CERT >> >> thomas.millar@us-cert.gov >> BB: thomas.millar@dhs.gov / 202-631-1915 >> 24x7: soc@us-cert.gov / 888-282-0870 >> >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Takeshi Takahashi >> Sent: Monday, February 20, 2012 20:40 >> To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >> takeshi_takahashi@nict.go.jp >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) >> >> Hello all, >> >> Thank you for your kind comments, which are really useful for me. >> On the other hand, I have some difficulties to understand what people specifically mean by "support" >> or "mandatory". >> I would appreciate if you could kindly give me some comments on below. >> >> Below are my views on the MTI issues. >> >> 1. All the specification namespaces listed in the table MUST be >> "supported" as values for the SpecID field. >> >> These namespaces are the allowed ENUM values. >> So, in a way, all the specification listed in the table are supported. >> (implementations must allow these namespaces of all the specifications listed in the table as values >> for SpecID field) Since all the specification listed in the table are supported, we need to have >> expert review before registration (as we discussed in Quebec City) >> >> In this way, receivers can correctly understand the data. >> That will give us the same level of interoperability as the RFC 5070 (IODEF) does between sender and >> receiver, I think. >> >> >> 2. Implementers have freedom to define how to parse, how to understand, >> and how to respond the IODEF extension message >> >> I might be wrong, but I do not think we would like to define how to parse the IODEF extension message >> at the receiver side. >> And I do not think we would like to define how to parse, for instance, CAPEC data, at the receiver >> side. >> I think the SCI draft is a container that conveys these structured information, and it can see such >> information as a blackbox with a tag (namespace information). >> >> If above understanding is correct, I have some difficulty to understand the meaning of "mandatory to >> support CVE". >> As described in issue 1 above, if CVE or CAPEC data is attached, the implementation needs to recognize >> that the data is in CVE/CAPEC format, and that is the requirement for the implementation. >> What else do we want to mandate here, specifically? >> Do we need to manipulate the embedded xml data itself? I rather prefer to handle the data as a >> blackbox. >> >> I appreciate your kind comments. >> Regarding the other point Dave kindly pointed out, let me have another thread. (sorry I need to get on >> board now...) >> >> Thank you. >> >> Take >> >> >> >> >> -----Original Message----- >> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] >> Sent: Monday, February 20, 2012 8:08 PM >> To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp >> Cc: mile@ietf.org >> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (was >> Re: MTI SCI?) >> >> Thank you, Dave. >> >> Dave raises a few very important points as we consider MTI for SCI. We will need to resolve these >> issues if CVE is to be the (or an) MTI specification for the SCI draft. >> >> If CVE is mandatory to implement, what guidance would be followed on how to use the model or will MTI >> only mean that the document can be received and >> parsed? The CVE website is listed as the specification URI, but from >> Dave's message, the specification URI does not exist to provide the guidance (I get to broken link >> pages for both - the existing and suggested replacement link). >> >> This is the closest I could find and may be the answer for guidance: >> http://cve.mitre.org/compatible/requirements.html >> >> It looks like the reference to the target namespace needs to be fixed as well. >> >> Thank you, >> Kathleen >> ________________________________________ >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Waltermire, David A. >> [david.waltermire@nist.gov] >> Sent: Thursday, February 16, 2012 5:26 PM >> To: Brian Trammell; Takeshi Takahashi >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was >> Re: MTI SCI?) >> >> I have not been following this thread as closely as I probably should. >> Relative to MTI, is the question what schema should be MTI for the vulerability class? In general I >> think we should have one or more MTI for each class. >> >> Relative to CVE specifically, are we talking about the schema currently located at: >> http://cve.mitre.org/schema/cve/cve_1.0.xsd? >> >> This seems to match the namespace defined in section 4.1.7 of mile-sci-02. >> Looking at the implementation of this schema, it looks like the targetNamespace is incorrectly >> assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be >> "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be fixed. >> >> Also, the specification URI points to the CVE website, which is not really a specification. It's not >> clear where to find guidance on how to properly use the model indicated by the namespace. Without >> having clear guidance on its use I don't see how we can make it MTI, even if it is considered a de >> facto approach. It might make sense to produce a specification for the model before making it MTI for >> the vulnerability class. >> >> Sincerely, >> David Waltermire >> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Brian Trammell >>> Sent: Wednesday, February 15, 2012 5:28 AM >>> To: Takeshi Takahashi >>> Cc: mile@ietf.org >>> Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was >>> Re: MTI SCI?) >>> >>> Hi, Take, all, >>> >>> Thank you for this edit/clarification. >>> >>> On the first point, it does seem the discussion on the list converged >>> rather quickly to CVE as MTI. However, as this is a rather important >>> point, I'd like to make sure we didn't miss anything. >>> >>> So, I'd like to call for consensus on the list. Does the working group >>> agree on the following two points? >>> >>> 1. mile-sci requires one Mandatory to Implement schema in order to >>> ensure interoperability. >>> >>> 2. The Mandatory to Implement schema is the Common Vulnerability >>> Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- >>> sci-02. >>> >>> Please note if you agree; if you disagree, please explain why not. >>> >>> Best regards, >>> >>> Brian (as chair) >>> >>> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >>> >>>> Hello all, >>>> >>>> Following the discussion, I would like to add a couple of sentences >>> to >>>> clarify the MTI issues. >>>> (Thank you very much for those of you who kindly provided useful >>>> discussion.) >>>> I've attached the working version of the draft. I hope it helps to >>>> clarify the changes. >>>> >>>> (added sentences at the end of section 4.1) >>>> >>>> The SpecID attributes of extended classes (Section 4.3) must allow >>>> the values of the specifications' namespace fields, but otherwise, >>>> implementations are not required to support all the above >>>> specifications. Implementations may choose which specifications to >>>> support, though CVE 1.0 (Section 4.1.7) needs to be minimally >>>> supported. In case an implementation received a data it does not >>>> support, it may expand its functionality by looking up the IANA >>> table or >>>> notify the sender of its inability to parse the data by using any >>>> means defined outside the scope of this specification. >>>> >>>> On the other hand, I would like to add "STRING ext-SpecID" to each >>>> class, which enables to embed data following private schema. >>>> For instance, one security operation center (SOC) may wish to >>> exchange >>>> a vulnerability data that is formatted in its own private schema, >>>> and that is not formatted in CVE. >>>> In this case, the SOC may put the data's schema ID inside ext-SpecID >>>> and then embed the data. >>>> It could also be used to exchange data using beta version of >>> specifications. >>>> >>>> The class could be seen as below. >>>> >>>> +------------------------+ >>>> | AttackPattern | >>>> +------------------------+ >>>> | ENUM SpecID |<>--(0..*)-[ RawData ] >>>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >>>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] >>>> +------------------------+ >>>> >>>> SpecID: REQUIRED. ENUM. The identifier of the specification >>>> specifying the format of the RawData element. The value should >>> be >>>> chosen from the namespaces [XMLNames] listed in Section 4.1 or >>>> "private". Note that the lists in Section 4.1 will be developed >>>> further by IANA. The value "private" is prepared for conveying >>>> RawData based on a format that is not listed in the >>>> table. This is usually used for conveying data formatted >>>> according to an organization's private schema. When the value >>>> "private" is used, ext-SpecID element needs to be used. >>>> >>>> ext-SpecID: OPTIONAL. STRING. The identifier of the >>> specification >>>> specifying the format of the RawData element. When this element >>>> is used, the value of SpecID element must be "private." >>>> >>>> I hope above changes don't cause any complication here. >>>> >>>> Sincerely, >>>> Take >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>> Behalf Of Martin, Robert A. >>>>> Sent: Wednesday, February 15, 2012 1:50 AM >>>>> To: Kent_Landfield@McAfee.com >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] MTI SCI? >>>>> >>>>> At the risk of contradicting myself - but then again I have now >>>>> read the other replies to this issue - I agree that having one area >>>>> be >>> the >>>>> smoke test makes sense and I also agree that something simple and >>>>> commonly used already - like CVE - is the best candidate for what >>>>> we >>> need. >>>>> >>>>> Bob >>>>> >>>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>>>> CVE is widely used and understood by all in the the security >>> community. >>>>> I agree with Tom that CVE is the path of least resistance but may >>>>> be the most useful for basic interoperability. >>>>>> >>>>>> Kent Landfield >>>>>> Director Content Strategy, Architecture and Standards >>>>>> >>>>>> McAfee | An Intel Company >>>>>> 5000 Headquarters Dr. >>>>>> Plano, Texas 75024 >>>>>> >>>>>> Direct: +1.972.963.7096 >>>>>> Mobile: +1.817.637.8026 >>>>>> Web: www.mcafee.com >>>>>> >>>>>> From: >>>>>> >>>>> "Thomas.Millar@us-cert.gov">>>> s >>>>> .M >>>>>> illar@us-cert.gov> >>>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>>>> To: >>>>>> >>>>> "david.black@emc.com">>>> o >>>>> m< >>>>>> mailto:david.black@emc.com>>, Bob >>>>>> Martin> >>>>>> Cc: >>>>>> >>>>> "mile@ietf.org">>>> f >>>>> .o >>>>>> rg>> >>>>>> Subject: Re: [mile] MTI SCI? >>>>>> >>>>>> My concern with CAPEC being mandatory is that it could discourage >>>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary >>>>> remains "too comprehensive" for many CSIRTs to employ during >>> incident >>>>> handling and reporting activity. >>>>>> >>>>>> IODEF by itself has been criticized by CSIRT operators for being >>>>>> more >>>>> heavyweight than necessary for day-to-day usage; making CAPEC a >>>>> mandatory aspect of "advanced IODEF" seems like it would be adding >>>>> ammunition to that argument, especially if the CSIRT is having to >>>>> fund implementation out of their own pocket. Personally, I would >>> have >>>>> a hard time asking US-CERT's primary constituents to implement >>>>> IODEF >>>>> + CAPEC if they are already balking at the consultant and developer >>>>> resources required to implement RFC 5070 by itself. Also keep in >>> mind >>>>> that CAPEC references CybOX, so there's wheels within wheels now. >>>>>> >>>>>> I would prefer we take the path of least resistance (from my >>>> perspective) >>>>> and make CVE the MTI, if we have to pick one additional spec. >>>>>> CVE is well known, has years of familiarity built in, and I think >>>>>> it's >>>>> the simplest schema of the bunch. >>>>>> >>>>>> >>>>>> - Tom Millar, US-CERT >>>>>> >>>>>> thomas.millar@us-cert.gov >>>>>> BB: thomas.millar@dhs.gov / >>>>>> 202-631-1915 >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>>> >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>>> david.black@emc.com >>>>>> Sent: Tuesday, February 14, 2012 11:14 >>>>>> To: ramartin@mitre.org >>>>>> Cc: mile@ietf.org >>>>>> Subject: Re: [mile] MTI SCI? >>>>>> >>>>>> Hi Bob, >>>>>> >>>>>> I do appreciate the concern about implementing things that aren't >>>>>> going >>>>> to be used. OTOH, it may be useful to have a single simple MTI >>>>> spec for SCI that can be used to "smoke test" a deployment before >>>>> trying any >>>> serious >>>>> test data (and "simple" is important). >>>>>> >>>>>> In addition, a concern that I would have with an MTI SCI spec per >>>>>> class >>>>> is that if two SCI implementations don't have at least one class in >>>> common, >>>>> they aren't going to interoperate, and that situation is unlikely >>>>> to be acceptable to the IESG (i.e., with an MTI SCI spec per class, >>>>> I suspect that there will also have to be an MTI class, which >>>>> results in an overall MTI SCI spec). >>>>>> >>>>>> It may also be useful to include a simple example of the MTI SCI >>>>>> spec >>>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI >>> spec >>>>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC >>>>> XML document for testing purposes, including enumeration values >>>>> suitable for testing). >>>>>> >>>>>> What do you (and others) think about this? >>>>>> >>>>>> Thanks, >>>>>> --David >>>>>> >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>>>> To: Brian Trammell >>>>>> Cc: mile@ietf.org >>>>>> Subject: Re: [mile] MTI SCI? >>>>>> Brian, >>>>>> You beat me to this point. Like you, I would be concerned about a >>>>>> MTI selection that ended up requiring someone to implement >>> something >>>>>> to meet the MTI but wasn't germane to anything else they intended >>> to >>>>> support. >>>>>> Bob >>>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>>>> Hi, Sean, all, >>>>>>> >>>>>>> Looking over the spec, it's not clear to me that one MTI makes >>>>>>> sense here, given that mile-sci's >>>>>> purpose is to reference a set of external specifications by >>>>>> inclusion in an IODEF document, and that those external >>>>>> specifications represent >>>>> fundamentally different things. >>>>>>> >>>>>>> The specifications are split over their applicability to the >>>>>>> IODEF extension classes. I could >>>>>> envision an mile-sci implementation that was only interested a >>>>>> subset of these classes (perhaps even only one). If my >>>>>> implementation has an internal representation of Verification, but >>>>>> not of any of the other classes, and the MTI is an enumeration >>>>>> that is applicable to >>>>> Vulnerability... what do I do? >>>>>>> >>>>>>> What about selecting an MTI per class, instead? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Brian (as contributor) >>>>>>> >>>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>>> >>>>>>>> Great - as long as we pick one as the MTI. Note that MTI is not >>>>> necessarily mandatory to use. >>>>>>>> >>>>>>>> spt >>>>>>>> >>>>>>>> On 2/13/12 7:11 PM, >>>>> kathleen.moriarty@emc.com wrote: >>>>>>>>> Thank you for raising the interoperability testing as we need >>>>>>>>> to plan for a bake-off that once >>>>>> these questions get answered and the draft is ready. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Kathleen >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mile-bounces@ietf.org >>>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>>>> To: mile@ietf.org >>>>>>>>> Subject: [mile] MTI SCI? >>>>>>>>> >>>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>>>>> (mandatory to implement) choice? In other words, how will you >>>>>>>>> get two interoperability implementations without picking one? >>>>>>>>> >>>>>>>>> spt >>>>>>>>> _______________________________________________ >>>>>>>>> mile mailing list >>>>>>>>> mile@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>> . >>>>>>> >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >> 03c >>>> >>> andidate_20120215.txt.pdf>____________________________________________ >>>> ___ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> >> >> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > From kathleen.moriarty@emc.com Tue Feb 21 13:37:09 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24AE21E80B4 for ; Tue, 21 Feb 2012 13:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.971 X-Spam-Level: X-Spam-Status: No, score=-9.971 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, 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 i6f3XYsooUAf for ; Tue, 21 Feb 2012 13:37:07 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6821E80AE for ; Tue, 21 Feb 2012 13:37:07 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LLb5v2030337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 16:37:05 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 21 Feb 2012 16:36:56 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LLauN8021490; Tue, 21 Feb 2012 16:36:56 -0500 Received: from mx06a.corp.emc.com ([169.254.1.82]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Tue, 21 Feb 2012 16:36:55 -0500 From: To: , , Date: Tue, 21 Feb 2012 16:36:55 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtSVXlOfYIAA940AgAAPhFCAAETQYIAAAMvN Message-ID: References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:37:10 -0000 Hi all, I think we have 2 possible issues to help break down this question. 1) If you think about what we actually use CVE for, do we want to pass the= content of CVE around or for this case, just provide a CVE number and perh= aps a reference URL? Or do we want to set options and guidance for handlin= g both use cases (just an enumerated value and reference URL and the use of= another schema to extend the possible set of data elements). For the CVE enumeration use case, we may want to consider creating tight gu= idance on how the Reference class of IODEF is used. We could set the strin= g value to be CVE and the number, roving strict guidance on how that would = be represented. Then also using the Reference URL. There are other schemas in SCI where we clearly want to have the ability to= include a document created by another schema. 2) When you extend to use a schema, for the most part, we might think abou= t this as a black box. IODEF already has guidance to handle the use case o= f what to do when there its a schema that is included that cannot be parsed= (already provided on list). We are taking another step with the SCI draft= - I am in agreement with David on this for the meaning of MTI. I *think* = the MTI use case is not to take away from the black box concept, but to tes= t one instance of where the module can be parsed by the receiving node. Th= is helps us understand that this capability would work for any other module= that uses the same approach. Only one specification would be MTI, so the = others may not be implemented and may respond via the guidance in IODEF. The result of this conversation will help us understand what it means to be= compliant with SCI. If we are compliant with IODEF, then we have guidance= to follow the use case where we can't parse something. Then we need to figure out if CVE is the right schema for this and what we = need to have appropriate guidance for that to really work - specification a= nd schema (David Waltermire's points)? Thanks, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Thomas.Mil= lar@us-cert.gov [Thomas.Millar@us-cert.gov] Sent: Tuesday, February 21, 2012 4:17 PM To: Black, David; mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= sRe: MTI SCI?) Should a recipient be required to validate a referenced schema even if they= don't intend to interpret the content? - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870 -----Original Message----- From: david.black@emc.com [mailto:david.black@emc.com] Sent: Tuesday, February 21, 2012 12:49 To: mile@ietf.org; Millar, Thomas R Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wasR= e: MTI SCI?) Hi Tom, I believe I agree with you, although I'd like to add some precision on what= is meant by "parse". I don't think it's sufficient to support the value in the SpecID field (e.g= ., a CVE version) and accept an XML blob that is not a well-formed CVE XML document. Hence, I think the minimum requirement is to validate the received SCI XML = document against the appropriate XML schema and detect any errors. Beyond that, Take's reference to RFC 5070 is a useful source of insight, as= I think it rules out most additional requirements. IODEF is a format, not = a protocol, so: A) Error reporting is specific to whatever transport protocol is be= ing used. For example, if RID is used, the rfc6046-bis draft specifie= s how to report errors, but there's no RFC 5070 requirement that IOD= EF use RID. Beyond error detection, it's not possible to specify a requ= ired error reporting mechanism. B) RFC 5070 has nothing to say about replies or responses to IODEF,= so the same should be true of extensions like SCI. C) I'm not sure I understand what Take had in mind by "how to under= stand" in #2. I see no need to understand CVE semantics or meaning b= eyond the CVE syntax check obtained by validating the received document a= gainst the CVE XML schema. > I would recommend that we be very clear in regards to what "support" > or "minimally support" mean so that technical requirements handed down > based on this draft do not bar achievement by operational implementers an= d their engineering teams. I agree and would suggest: - The CVE SpecID value and related values (e.g., namespace) MUST be supported (not cause errors if used). - Recipient MUST validate received CVE XML document against the CVE XML schema to detect invalid CVE documents. I assume that this is all about CVE 1.0. Does all of this make sense? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of Thomas.Millar@us-cert.gov > Sent: Tuesday, February 21, 2012 12:00 PM > To: ariestake@googlemail.com; Moriarty, Kathleen; > david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > (was Re: MTI SCI?) > > Take, > > I think you've done a very good job of explaining the two different > interpretations around this call for consensus. > > My interpretation of MTI was closer to #2 - that to support this > draft, an implementer would have to support not only recognition of > the namespace in the appropriate IODEF parent class context, but also > be able to parse the content of the referenced namespace. Hence my prefer= ence for a relatively simple and familiar spec as the MTI. > > If we can concur that we all really mean the interpretation you > describe under #1, then I'm okay with having an MTI for each class. > What that says to me is that each implementer would need to conform to > the SCI draft's class placement of each namespace, but not necessarily > have to be able to interpret the contents of said namespace(s). So all > I have to do, minimally, is recognize the class under which any of the re= ferenced namespaces exist; I don't have to have any means to parse or handl= e that class content other than bucket it and move on to the next. Is that = right? > > I would recommend that we be very clear in regards to what "support" > or "minimally support" mean so that technical requirements handed down > based on this draft do not bar achievement by operational implementers an= d their engineering teams. > > Thanks again, > > - Tom Millar, US-CERT > > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of Takeshi Takahashi > Sent: Monday, February 20, 2012 20:40 > To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; > trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > (wasRe: MTI SCI?) > > Hello all, > > Thank you for your kind comments, which are really useful for me. > On the other hand, I have some difficulties to understand what people spe= cifically mean by "support" > or "mandatory". > I would appreciate if you could kindly give me some comments on below. > > Below are my views on the MTI issues. > > 1. All the specification namespaces listed in the table MUST be > "supported" as values for the SpecID field. > > These namespaces are the allowed ENUM values. > So, in a way, all the specification listed in the table are supported. > (implementations must allow these namespaces of all the specifications > listed in the table as values for SpecID field) Since all the > specification listed in the table are supported, we need to have > expert review before registration (as we discussed in Quebec City) > > In this way, receivers can correctly understand the data. > That will give us the same level of interoperability as the RFC 5070 > (IODEF) does between sender and receiver, I think. > > > 2. Implementers have freedom to define how to parse, how to understand= , > and how to respond the IODEF extension message > > I might be wrong, but I do not think we would like to define how to > parse the IODEF extension message at the receiver side. > And I do not think we would like to define how to parse, for instance, > CAPEC data, at the receiver side. > I think the SCI draft is a container that conveys these structured > information, and it can see such information as a blackbox with a tag (na= mespace information). > > If above understanding is correct, I have some difficulty to > understand the meaning of "mandatory to support CVE". > As described in issue 1 above, if CVE or CAPEC data is attached, the > implementation needs to recognize that the data is in CVE/CAPEC format, a= nd that is the requirement for the implementation. > What else do we want to mandate here, specifically? > Do we need to manipulate the embedded xml data itself? I rather prefer > to handle the data as a blackbox. > > I appreciate your kind comments. > Regarding the other point Dave kindly pointed out, let me have another > thread. (sorry I need to get on board now...) > > Thank you. > > Take > > > > > -----Original Message----- > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > Sent: Monday, February 20, 2012 8:08 PM > To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > (was > Re: MTI SCI?) > > Thank you, Dave. > > Dave raises a few very important points as we consider MTI for SCI. > We will need to resolve these issues if CVE is to be the (or an) MTI spec= ification for the SCI draft. > > If CVE is mandatory to implement, what guidance would be followed on > how to use the model or will MTI only mean that the document can be recei= ved and > parsed? The CVE website is listed as the specification URI, but from > Dave's message, the specification URI does not exist to provide the > guidance (I get to broken link pages for both - the existing and suggeste= d replacement link). > > This is the closest I could find and may be the answer for guidance: > http://cve.mitre.org/compatible/requirements.html > > It looks like the reference to the target namespace needs to be fixed as = well. > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Waltermi= re, David A. > [david.waltermire@nist.gov] > Sent: Thursday, February 16, 2012 5:26 PM > To: Brian Trammell; Takeshi Takahashi > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > (was > Re: MTI SCI?) > > I have not been following this thread as closely as I probably should. > Relative to MTI, is the question what schema should be MTI for the > vulerability class? In general I think we should have one or more MTI fo= r each class. > > Relative to CVE specifically, are we talking about the schema currently l= ocated at: > http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > This seems to match the namespace defined in section 4.1.7 of mile-sci-02= . > Looking at the implementation of this schema, it looks like the > targetNamespace is incorrectly assigned to > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should = be "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be f= ixed. > > Also, the specification URI points to the CVE website, which is not > really a specification. It's not clear where to find guidance on how > to properly use the model indicated by the namespace. Without having > clear guidance on its use I don't see how we can make it MTI, even if > it is considered a de facto approach. It might make sense to produce a s= pecification for the model before making it MTI for the vulnerability class= . > > Sincerely, > David Waltermire > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Brian Trammell > > Sent: Wednesday, February 15, 2012 5:28 AM > > To: Takeshi Takahashi > > Cc: mile@ietf.org > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was > > Re: MTI SCI?) > > > > Hi, Take, all, > > > > Thank you for this edit/clarification. > > > > On the first point, it does seem the discussion on the list > > converged rather quickly to CVE as MTI. However, as this is a rather > > important point, I'd like to make sure we didn't miss anything. > > > > So, I'd like to call for consensus on the list. Does the working > > group agree on the following two points? > > > > 1. mile-sci requires one Mandatory to Implement schema in order to > > ensure interoperability. > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of > > mile- sci-02. > > > > Please note if you agree; if you disagree, please explain why not. > > > > Best regards, > > > > Brian (as chair) > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > Hello all, > > > > > > Following the discussion, I would like to add a couple of > > > sentences > > to > > > clarify the MTI issues. > > > (Thank you very much for those of you who kindly provided useful > > > discussion.) > > > I've attached the working version of the draft. I hope it helps to > > > clarify the changes. > > > > > > (added sentences at the end of section 4.1) > > > > > > The SpecID attributes of extended classes (Section 4.3) must allow > > > the values of the specifications' namespace fields, but otherwise, > > > implementations are not required to support all the above > > > specifications. Implementations may choose which specifications to > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > supported. In case an implementation received a data it does not > > > support, it may expand its functionality by looking up the IANA > > table or > > > notify the sender of its inability to parse the data by using any > > > means defined outside the scope of this specification. > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > > class, which enables to embed data following private schema. > > > For instance, one security operation center (SOC) may wish to > > exchange > > > a vulnerability data that is formatted in its own private schema, > > > and that is not formatted in CVE. > > > In this case, the SOC may put the data's schema ID inside > > > ext-SpecID and then embed the data. > > > It could also be used to exchange data using beta version of > > specifications. > > > > > > The class could be seen as below. > > > > > > +------------------------+ > > > | AttackPattern | > > > +------------------------+ > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > +------------------------+ > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > specifying the format of the RawData element. The value > > > should > > be > > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > > "private". Note that the lists in Section 4.1 will be developed > > > further by IANA. The value "private" is prepared for conveying > > > RawData based on a format that is not listed in the > > > table. This is usually used for conveying data formatted > > > according to an organization's private schema. When the value > > > "private" is used, ext-SpecID element needs to be used. > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > specification > > > specifying the format of the RawData element. When this element > > > is used, the value of SpecID element must be "private." > > > > > > I hope above changes don't cause any complication here. > > > > > > Sincerely, > > > Take > > > > > > > > > > > >> -----Original Message----- > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > >> Behalf Of Martin, Robert A. > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > >> To: Kent_Landfield@McAfee.com > > >> Cc: mile@ietf.org > > >> Subject: Re: [mile] MTI SCI? > > >> > > >> At the risk of contradicting myself - but then again I have now > > >> read the other replies to this issue - I agree that having one > > >> area be > > the > > >> smoke test makes sense and I also agree that something simple and > > >> commonly used already - like CVE - is the best candidate for what > > >> we > > need. > > >> > > >> Bob > > >> > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > >>> CVE is widely used and understood by all in the the security > > community. > > >> I agree with Tom that CVE is the path of least resistance but may > > >> be the most useful for basic interoperability. > > >>> > > >>> Kent Landfield > > >>> Director Content Strategy, Architecture and Standards > > >>> > > >>> McAfee | An Intel Company > > >>> 5000 Headquarters Dr. > > >>> Plano, Texas 75024 > > >>> > > >>> Direct: +1.972.963.7096 > > >>> Mobile: +1.817.637.8026 > > >>> Web: www.mcafee.com > > >>> > > >>> From: > > >>> > > >> "Thomas.Millar@us-cert.gov" > >> ma > > >> s > > >> .M > > >>> illar@us-cert.gov> > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > >>> To: > > >>> > > >> "david.black@emc.com" > >> .c > > >> o > > >> m< > > >>> mailto:david.black@emc.com>>, Bob > > >>> Martin> > > >>> Cc: > > >>> > > >> "mile@ietf.org" > >> et > > >> f > > >> .o > > >>> rg>> > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> My concern with CAPEC being mandatory is that it could > > >>> discourage > > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > > >> remains "too comprehensive" for many CSIRTs to employ during > > incident > > >> handling and reporting activity. > > >>> > > >>> IODEF by itself has been criticized by CSIRT operators for being > > >>> more > > >> heavyweight than necessary for day-to-day usage; making CAPEC a > > >> mandatory aspect of "advanced IODEF" seems like it would be > > >> adding ammunition to that argument, especially if the CSIRT is > > >> having to fund implementation out of their own pocket. > > >> Personally, I would > > have > > >> a hard time asking US-CERT's primary constituents to implement > > >> IODEF > > >> + CAPEC if they are already balking at the consultant and > > >> + developer > > >> resources required to implement RFC 5070 by itself. Also keep in > > mind > > >> that CAPEC references CybOX, so there's wheels within wheels now. > > >>> > > >>> I would prefer we take the path of least resistance (from my > > > perspective) > > >> and make CVE the MTI, if we have to pick one additional spec. > > >>> CVE is well known, has years of familiarity built in, and I > > >>> think it's > > >> the simplest schema of the bunch. > > >>> > > >>> > > >>> - Tom Millar, US-CERT > > >>> > > >>> thomas.millar@us-cert.gov > > >>> BB: thomas.millar@dhs.gov / > > >>> 202-631-1915 > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > >>> david.black@emc.com > > >>> Sent: Tuesday, February 14, 2012 11:14 > > >>> To: ramartin@mitre.org > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> > > >>> Hi Bob, > > >>> > > >>> I do appreciate the concern about implementing things that > > >>> aren't going > > >> to be used. OTOH, it may be useful to have a single simple MTI > > >> spec for SCI that can be used to "smoke test" a deployment before > > >> trying any > > > serious > > >> test data (and "simple" is important). > > >>> > > >>> In addition, a concern that I would have with an MTI SCI spec > > >>> per class > > >> is that if two SCI implementations don't have at least one class > > >> in > > > common, > > >> they aren't going to interoperate, and that situation is unlikely > > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per > > >> class, I suspect that there will also have to be an MTI class, > > >> which results in an overall MTI SCI spec). > > >>> > > >>> It may also be useful to include a simple example of the MTI SCI > > >>> spec > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > > spec > > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC > > >> XML document for testing purposes, including enumeration values > > >> suitable for testing). > > >>> > > >>> What do you (and others) think about this? > > >>> > > >>> Thanks, > > >>> --David > > >>> > > >>> -----Original Message----- > > >>> From: mile-bounces@ietf.org > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > >>> To: Brian Trammell > > >>> Cc: mile@ietf.org > > >>> Subject: Re: [mile] MTI SCI? > > >>> Brian, > > >>> You beat me to this point. Like you, I would be concerned about > > >>> a MTI selection that ended up requiring someone to implement > > something > > >>> to meet the MTI but wasn't germane to anything else they > > >>> intended > > to > > >> support. > > >>> Bob > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > >>>> Hi, Sean, all, > > >>>> > > >>>> Looking over the spec, it's not clear to me that one MTI makes > > >>>> sense here, given that mile-sci's > > >>> purpose is to reference a set of external specifications by > > >>> inclusion in an IODEF document, and that those external > > >>> specifications represent > > >> fundamentally different things. > > >>>> > > >>>> The specifications are split over their applicability to the > > >>>> IODEF extension classes. I could > > >>> envision an mile-sci implementation that was only interested a > > >>> subset of these classes (perhaps even only one). If my > > >>> implementation has an internal representation of Verification, > > >>> but not of any of the other classes, and the MTI is an > > >>> enumeration that is applicable to > > >> Vulnerability... what do I do? > > >>>> > > >>>> What about selecting an MTI per class, instead? > > >>>> > > >>>> Best regards, > > >>>> > > >>>> Brian (as contributor) > > >>>> > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > >>>> > > >>>>> Great - as long as we pick one as the MTI. Note that MTI is > > >>>>> not > > >> necessarily mandatory to use. > > >>>>> > > >>>>> spt > > >>>>> > > >>>>> On 2/13/12 7:11 PM, > > >> kathleen.moriarty@emc.com wrote: > > >>>>>> Thank you for raising the interoperability testing as we need > > >>>>>> to plan for a bake-off that once > > >>> these questions get answered and the draft is ready. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Kathleen > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: mile-bounces@ietf.org > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > >>>>>> To: mile@ietf.org > > >>>>>> Subject: [mile] MTI SCI? > > >>>>>> > > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > > >>>>>> (mandatory to implement) choice? In other words, how will > > >>>>>> you get two interoperability implementations without picking one= ? > > >>>>>> > > >>>>>> spt > > >>>>>> _______________________________________________ > > >>>>>> mile mailing list > > >>>>>> mile@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>>>> > > >>>>>> > > >>>>> _______________________________________________ > > >>>>> mile mailing list > > >>>>> mile@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>> _______________________________________________ > > >>>> mile mailing list > > >>>> mile@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> . > > >>>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> _______________________________________________ > > >>> mile mailing list > > >>> mile@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mile > > >>> > > >>> > > >> _______________________________________________ > > >> mile mailing list > > >> mile@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > - > > 03c > > > > > andidate_20120215.txt.pdf>__________________________________________ > > __ > > > ___ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Tue Feb 21 13:39:11 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156C621E807D for ; Tue, 21 Feb 2012 13:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.978 X-Spam-Level: X-Spam-Status: No, score=-9.978 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, 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 FLBAMOrvRMtz for ; Tue, 21 Feb 2012 13:39:09 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B145F21E80B0 for ; Tue, 21 Feb 2012 13:39:08 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LLd6qs032699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 16:39:07 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 21 Feb 2012 16:38:41 -0500 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LLce8f003215; Tue, 21 Feb 2012 16:38:41 -0500 Received: from mx06a.corp.emc.com ([169.254.1.82]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Tue, 21 Feb 2012 16:38:40 -0500 From: To: , Date: Tue, 21 Feb 2012 16:37:18 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: Aczw3rtHfWj9FqE/S1ucoxDElZdHIQAAkEk0 Message-ID: References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com>, <4F440A82.5070904@mitre.org> In-Reply-To: <4F440A82.5070904@mitre.org> 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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:39:11 -0000 I agree, however, why don't we have the SCI draft provide guidance on what = would be expected when the enumerations were included in IODEF using the Re= ference class for each of these rather than creating an extension for this = use case? Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Martin, Ro= bert A. [ramartin@mitre.org] Sent: Tuesday, February 21, 2012 4:20 PM To: Black, David Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was = Re: MTI SCI?) I would like to offer that for some of the "ID" like things (i.e. CVE ID, CWE ID, and CAPEC ID) there may not be a need for an xml document and we may want to simplify those construct in SCI. Most people who send a CVE ID send a ascii text string 'CVE-xxx-xxxx' and assume that the reciever knows that there is a well established cgi url 'http://cve.mitre.org/cgi-bin/cvename.cgi?name=3Dxxxx-xxxx' where the recipient can look up the details about CVE-xxxx-xxxx. CWE and CAPEC IDs have a similar well known address to resolve their IDs at= . Bob On 2/21/12 12:48 PM, david.black@emc.com wrote: > Hi Tom, > > I believe I agree with you, although I'd like to add some precision on wh= at is meant > by "parse". > > I don't think it's sufficient to support the value in the SpecID field (e= .g., a CVE > version) and accept an XML blob that is not a well-formed CVE XML documen= t. > > Hence, I think the minimum requirement is to validate the received SCI XM= L document > against the appropriate XML schema and detect any errors. > > Beyond that, Take's reference to RFC 5070 is a useful source of insight, = as I think it > rules out most additional requirements. IODEF is a format, not a protocol= , so: > > A) Error reporting is specific to whatever transport protocol is= being used. > For example, if RID is used, the rfc6046-bis draft speci= fies how to > report errors, but there's no RFC 5070 requirement that = IODEF use RID. > Beyond error detection, it's not possible to specify a r= equired error > reporting mechanism. > > B) RFC 5070 has nothing to say about replies or responses to IOD= EF, so the > same should be true of extensions like SCI. > > C) I'm not sure I understand what Take had in mind by "how to un= derstand" in > #2. I see no need to understand CVE semantics or meanin= g beyond the CVE > syntax check obtained by validating the received documen= t against the > CVE XML schema. > >> I would recommend that we be very clear in regards to what "support" or = "minimally support" mean so >> that technical requirements handed down based on this draft do not bar a= chievement by operational >> implementers and their engineering teams. > > I agree and would suggest: > > - The CVE SpecID value and related values (e.g., namespace) MUST > be supported (not cause errors if used). > - Recipient MUST validate received CVE XML document against the = CVE > XML schema to detect invalid CVE documents. > > I assume that this is all about CVE 1.0. > > Does all of this make sense? > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Thomas.Millar@us-cert.gov >> Sent: Tuesday, February 21, 2012 12:00 PM >> To: ariestake@googlemail.com; Moriarty, Kathleen; david.waltermire@nist.= gov; trammell@tik.ee.ethz.ch; >> takeshi_takahashi@nict.go.jp >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (w= as Re: MTI SCI?) >> >> Take, >> >> I think you've done a very good job of explaining the two different inte= rpretations around this call >> for consensus. >> >> My interpretation of MTI was closer to #2 - that to support this draft, = an implementer would have to >> support not only recognition of the namespace in the appropriate IODEF p= arent class context, but also >> be able to parse the content of the referenced namespace. Hence my prefe= rence for a relatively simple >> and familiar spec as the MTI. >> >> If we can concur that we all really mean the interpretation you describe= under #1, then I'm okay with >> having an MTI for each class. What that says to me is that each implemen= ter would need to conform to >> the SCI draft's class placement of each namespace, but not necessarily h= ave to be able to interpret >> the contents of said namespace(s). So all I have to do, minimally, is re= cognize the class under which >> any of the referenced namespaces exist; I don't have to have any means t= o parse or handle that class >> content other than bucket it and move on to the next. Is that right? >> >> I would recommend that we be very clear in regards to what "support" or = "minimally support" mean so >> that technical requirements handed down based on this draft do not bar a= chievement by operational >> implementers and their engineering teams. >> >> Thanks again, >> >> - Tom Millar, US-CERT >> >> thomas.millar@us-cert.gov >> BB: thomas.millar@dhs.gov / 202-631-1915 >> 24x7: soc@us-cert.gov / 888-282-0870 >> >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Takeshi Takahashi >> Sent: Monday, February 20, 2012 20:40 >> To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; trammell@tik.e= e.ethz.ch; >> takeshi_takahashi@nict.go.jp >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (w= asRe: MTI SCI?) >> >> Hello all, >> >> Thank you for your kind comments, which are really useful for me. >> On the other hand, I have some difficulties to understand what people sp= ecifically mean by "support" >> or "mandatory". >> I would appreciate if you could kindly give me some comments on below. >> >> Below are my views on the MTI issues. >> >> 1. All the specification namespaces listed in the table MUST be >> "supported" as values for the SpecID field. >> >> These namespaces are the allowed ENUM values. >> So, in a way, all the specification listed in the table are supported. >> (implementations must allow these namespaces of all the specifications l= isted in the table as values >> for SpecID field) Since all the specification listed in the table are su= pported, we need to have >> expert review before registration (as we discussed in Quebec City) >> >> In this way, receivers can correctly understand the data. >> That will give us the same level of interoperability as the RFC 5070 (IO= DEF) does between sender and >> receiver, I think. >> >> >> 2. Implementers have freedom to define how to parse, how to understan= d, >> and how to respond the IODEF extension message >> >> I might be wrong, but I do not think we would like to define how to pars= e the IODEF extension message >> at the receiver side. >> And I do not think we would like to define how to parse, for instance, C= APEC data, at the receiver >> side. >> I think the SCI draft is a container that conveys these structured infor= mation, and it can see such >> information as a blackbox with a tag (namespace information). >> >> If above understanding is correct, I have some difficulty to understand = the meaning of "mandatory to >> support CVE". >> As described in issue 1 above, if CVE or CAPEC data is attached, the imp= lementation needs to recognize >> that the data is in CVE/CAPEC format, and that is the requirement for th= e implementation. >> What else do we want to mandate here, specifically? >> Do we need to manipulate the embedded xml data itself? I rather prefer t= o handle the data as a >> blackbox. >> >> I appreciate your kind comments. >> Regarding the other point Dave kindly pointed out, let me have another t= hread. (sorry I need to get on >> board now...) >> >> Thank you. >> >> Take >> >> >> >> >> -----Original Message----- >> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] >> Sent: Monday, February 20, 2012 8:08 PM >> To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; takeshi_takahash= i@nict.go.jp >> Cc: mile@ietf.org >> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (w= as >> Re: MTI SCI?) >> >> Thank you, Dave. >> >> Dave raises a few very important points as we consider MTI for SCI. We = will need to resolve these >> issues if CVE is to be the (or an) MTI specification for the SCI draft. >> >> If CVE is mandatory to implement, what guidance would be followed on how= to use the model or will MTI >> only mean that the document can be received and >> parsed? The CVE website is listed as the specification URI, but from >> Dave's message, the specification URI does not exist to provide the guid= ance (I get to broken link >> pages for both - the existing and suggested replacement link). >> >> This is the closest I could find and may be the answer for guidance: >> http://cve.mitre.org/compatible/requirements.html >> >> It looks like the reference to the target namespace needs to be fixed as= well. >> >> Thank you, >> Kathleen >> ________________________________________ >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Walterm= ire, David A. >> [david.waltermire@nist.gov] >> Sent: Thursday, February 16, 2012 5:26 PM >> To: Brian Trammell; Takeshi Takahashi >> Cc: mile@ietf.org >> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (w= as >> Re: MTI SCI?) >> >> I have not been following this thread as closely as I probably should. >> Relative to MTI, is the question what schema should be MTI for the vuler= ability class? In general I >> think we should have one or more MTI for each class. >> >> Relative to CVE specifically, are we talking about the schema currently = located at: >> http://cve.mitre.org/schema/cve/cve_1.0.xsd? >> >> This seems to match the namespace defined in section 4.1.7 of mile-sci-0= 2. >> Looking at the implementation of this schema, it looks like the targetNa= mespace is incorrectly >> assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" wh= en it should be >> "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be f= ixed. >> >> Also, the specification URI points to the CVE website, which is not real= ly a specification. It's not >> clear where to find guidance on how to properly use the model indicated = by the namespace. Without >> having clear guidance on its use I don't see how we can make it MTI, eve= n if it is considered a de >> facto approach. It might make sense to produce a specification for the = model before making it MTI for >> the vulnerability class. >> >> Sincerely, >> David Waltermire >> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Brian Trammell >>> Sent: Wednesday, February 15, 2012 5:28 AM >>> To: Takeshi Takahashi >>> Cc: mile@ietf.org >>> Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was >>> Re: MTI SCI?) >>> >>> Hi, Take, all, >>> >>> Thank you for this edit/clarification. >>> >>> On the first point, it does seem the discussion on the list converged >>> rather quickly to CVE as MTI. However, as this is a rather important >>> point, I'd like to make sure we didn't miss anything. >>> >>> So, I'd like to call for consensus on the list. Does the working group >>> agree on the following two points? >>> >>> 1. mile-sci requires one Mandatory to Implement schema in order to >>> ensure interoperability. >>> >>> 2. The Mandatory to Implement schema is the Common Vulnerability >>> Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- >>> sci-02. >>> >>> Please note if you agree; if you disagree, please explain why not. >>> >>> Best regards, >>> >>> Brian (as chair) >>> >>> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >>> >>>> Hello all, >>>> >>>> Following the discussion, I would like to add a couple of sentences >>> to >>>> clarify the MTI issues. >>>> (Thank you very much for those of you who kindly provided useful >>>> discussion.) >>>> I've attached the working version of the draft. I hope it helps to >>>> clarify the changes. >>>> >>>> (added sentences at the end of section 4.1) >>>> >>>> The SpecID attributes of extended classes (Section 4.3) must allow >>>> the values of the specifications' namespace fields, but otherwise, >>>> implementations are not required to support all the above >>>> specifications. Implementations may choose which specifications to >>>> support, though CVE 1.0 (Section 4.1.7) needs to be minimally >>>> supported. In case an implementation received a data it does not >>>> support, it may expand its functionality by looking up the IANA >>> table or >>>> notify the sender of its inability to parse the data by using any >>>> means defined outside the scope of this specification. >>>> >>>> On the other hand, I would like to add "STRING ext-SpecID" to each >>>> class, which enables to embed data following private schema. >>>> For instance, one security operation center (SOC) may wish to >>> exchange >>>> a vulnerability data that is formatted in its own private schema, >>>> and that is not formatted in CVE. >>>> In this case, the SOC may put the data's schema ID inside ext-SpecID >>>> and then embed the data. >>>> It could also be used to exchange data using beta version of >>> specifications. >>>> >>>> The class could be seen as below. >>>> >>>> +------------------------+ >>>> | AttackPattern | >>>> +------------------------+ >>>> | ENUM SpecID |<>--(0..*)-[ RawData ] >>>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >>>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] >>>> +------------------------+ >>>> >>>> SpecID: REQUIRED. ENUM. The identifier of the specification >>>> specifying the format of the RawData element. The value should >>> be >>>> chosen from the namespaces [XMLNames] listed in Section 4.1 or >>>> "private". Note that the lists in Section 4.1 will be developed >>>> further by IANA. The value "private" is prepared for conveying >>>> RawData based on a format that is not listed in the >>>> table. This is usually used for conveying data formatted >>>> according to an organization's private schema. When the value >>>> "private" is used, ext-SpecID element needs to be used. >>>> >>>> ext-SpecID: OPTIONAL. STRING. The identifier of the >>> specification >>>> specifying the format of the RawData element. When this element >>>> is used, the value of SpecID element must be "private." >>>> >>>> I hope above changes don't cause any complication here. >>>> >>>> Sincerely, >>>> Take >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>> Behalf Of Martin, Robert A. >>>>> Sent: Wednesday, February 15, 2012 1:50 AM >>>>> To: Kent_Landfield@McAfee.com >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] MTI SCI? >>>>> >>>>> At the risk of contradicting myself - but then again I have now >>>>> read the other replies to this issue - I agree that having one area >>>>> be >>> the >>>>> smoke test makes sense and I also agree that something simple and >>>>> commonly used already - like CVE - is the best candidate for what >>>>> we >>> need. >>>>> >>>>> Bob >>>>> >>>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>>>> CVE is widely used and understood by all in the the security >>> community. >>>>> I agree with Tom that CVE is the path of least resistance but may >>>>> be the most useful for basic interoperability. >>>>>> >>>>>> Kent Landfield >>>>>> Director Content Strategy, Architecture and Standards >>>>>> >>>>>> McAfee | An Intel Company >>>>>> 5000 Headquarters Dr. >>>>>> Plano, Texas 75024 >>>>>> >>>>>> Direct: +1.972.963.7096 >>>>>> Mobile: +1.817.637.8026 >>>>>> Web: www.mcafee.com >>>>>> >>>>>> From: >>>>>> >>>>> "Thomas.Millar@us-cert.gov">>>> s >>>>> .M >>>>>> illar@us-cert.gov> >>>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>>>> To: >>>>>> >>>>> "david.black@emc.com">>>> o >>>>> m< >>>>>> mailto:david.black@emc.com>>, Bob >>>>>> Martin> >>>>>> Cc: >>>>>> >>>>> "mile@ietf.org">>>> f >>>>> .o >>>>>> rg>> >>>>>> Subject: Re: [mile] MTI SCI? >>>>>> >>>>>> My concern with CAPEC being mandatory is that it could discourage >>>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary >>>>> remains "too comprehensive" for many CSIRTs to employ during >>> incident >>>>> handling and reporting activity. >>>>>> >>>>>> IODEF by itself has been criticized by CSIRT operators for being >>>>>> more >>>>> heavyweight than necessary for day-to-day usage; making CAPEC a >>>>> mandatory aspect of "advanced IODEF" seems like it would be adding >>>>> ammunition to that argument, especially if the CSIRT is having to >>>>> fund implementation out of their own pocket. Personally, I would >>> have >>>>> a hard time asking US-CERT's primary constituents to implement >>>>> IODEF >>>>> + CAPEC if they are already balking at the consultant and developer >>>>> resources required to implement RFC 5070 by itself. Also keep in >>> mind >>>>> that CAPEC references CybOX, so there's wheels within wheels now. >>>>>> >>>>>> I would prefer we take the path of least resistance (from my >>>> perspective) >>>>> and make CVE the MTI, if we have to pick one additional spec. >>>>>> CVE is well known, has years of familiarity built in, and I think >>>>>> it's >>>>> the simplest schema of the bunch. >>>>>> >>>>>> >>>>>> - Tom Millar, US-CERT >>>>>> >>>>>> thomas.millar@us-cert.gov >>>>>> BB: thomas.millar@dhs.gov / >>>>>> 202-631-1915 >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>>> >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>>> david.black@emc.com >>>>>> Sent: Tuesday, February 14, 2012 11:14 >>>>>> To: ramartin@mitre.org >>>>>> Cc: mile@ietf.org >>>>>> Subject: Re: [mile] MTI SCI? >>>>>> >>>>>> Hi Bob, >>>>>> >>>>>> I do appreciate the concern about implementing things that aren't >>>>>> going >>>>> to be used. OTOH, it may be useful to have a single simple MTI >>>>> spec for SCI that can be used to "smoke test" a deployment before >>>>> trying any >>>> serious >>>>> test data (and "simple" is important). >>>>>> >>>>>> In addition, a concern that I would have with an MTI SCI spec per >>>>>> class >>>>> is that if two SCI implementations don't have at least one class in >>>> common, >>>>> they aren't going to interoperate, and that situation is unlikely >>>>> to be acceptable to the IESG (i.e., with an MTI SCI spec per class, >>>>> I suspect that there will also have to be an MTI class, which >>>>> results in an overall MTI SCI spec). >>>>>> >>>>>> It may also be useful to include a simple example of the MTI SCI >>>>>> spec >>>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI >>> spec >>>>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC >>>>> XML document for testing purposes, including enumeration values >>>>> suitable for testing). >>>>>> >>>>>> What do you (and others) think about this? >>>>>> >>>>>> Thanks, >>>>>> --David >>>>>> >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>>>> To: Brian Trammell >>>>>> Cc: mile@ietf.org >>>>>> Subject: Re: [mile] MTI SCI? >>>>>> Brian, >>>>>> You beat me to this point. Like you, I would be concerned about a >>>>>> MTI selection that ended up requiring someone to implement >>> something >>>>>> to meet the MTI but wasn't germane to anything else they intended >>> to >>>>> support. >>>>>> Bob >>>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>>>> Hi, Sean, all, >>>>>>> >>>>>>> Looking over the spec, it's not clear to me that one MTI makes >>>>>>> sense here, given that mile-sci's >>>>>> purpose is to reference a set of external specifications by >>>>>> inclusion in an IODEF document, and that those external >>>>>> specifications represent >>>>> fundamentally different things. >>>>>>> >>>>>>> The specifications are split over their applicability to the >>>>>>> IODEF extension classes. I could >>>>>> envision an mile-sci implementation that was only interested a >>>>>> subset of these classes (perhaps even only one). If my >>>>>> implementation has an internal representation of Verification, but >>>>>> not of any of the other classes, and the MTI is an enumeration >>>>>> that is applicable to >>>>> Vulnerability... what do I do? >>>>>>> >>>>>>> What about selecting an MTI per class, instead? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Brian (as contributor) >>>>>>> >>>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>>> >>>>>>>> Great - as long as we pick one as the MTI. Note that MTI is not >>>>> necessarily mandatory to use. >>>>>>>> >>>>>>>> spt >>>>>>>> >>>>>>>> On 2/13/12 7:11 PM, >>>>> kathleen.moriarty@emc.com wrote: >>>>>>>>> Thank you for raising the interoperability testing as we need >>>>>>>>> to plan for a bake-off that once >>>>>> these questions get answered and the draft is ready. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Kathleen >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mile-bounces@ietf.org >>>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>>>> To: mile@ietf.org >>>>>>>>> Subject: [mile] MTI SCI? >>>>>>>>> >>>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>>>>> (mandatory to implement) choice? In other words, how will you >>>>>>>>> get two interoperability implementations without picking one? >>>>>>>>> >>>>>>>>> spt >>>>>>>>> _______________________________________________ >>>>>>>>> mile mailing list >>>>>>>>> mile@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>> . >>>>>>> >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> >> 03c >>>> >>> andidate_20120215.txt.pdf>____________________________________________ >>>> ___ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> >> >> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Tue Feb 21 15:47:57 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD9721E8033 for ; Tue, 21 Feb 2012 15:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.627 X-Spam-Level: X-Spam-Status: No, score=-109.627 tagged_above=-999 required=5 tests=[AWL=0.972, 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 PwJETgwL83nA for ; Tue, 21 Feb 2012 15:47:52 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8182E21E8059 for ; Tue, 21 Feb 2012 15:47:52 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LNlo78006184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 18:47:51 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 21 Feb 2012 18:47:32 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LNlUOX002695; Tue, 21 Feb 2012 18:47:31 -0500 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Tue, 21 Feb 2012 18:47:30 -0500 From: To: , Date: Tue, 21 Feb 2012 18:47:28 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtSVXlOfYIAA940AgAAPhFCAAETQYIAAJ1+A Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 23:47:57 -0000 A "smoke test" is one of the motivations for this MTI requirement - for tha= t, validation of the received content (e.g., against an XML schema for XML con= tent) should be required, as one usually wants to know that the "smoke" made it through ok (the "smoke" that arrived matches what was sent). So, even if the content will only be used as "smoke test" evidence, and not otherwise interpreted, it's still a good idea to require format validation. Thanks, --David > -----Original Message----- > From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] > Sent: Tuesday, February 21, 2012 4:18 PM > To: Black, David; mile@ietf.org > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= sRe: MTI SCI?) > > Should a recipient be required to validate a referenced schema even if th= ey don't intend to interpret > the content? > > - Tom Millar, US-CERT > > thomas.millar@us-cert.gov > BB: thomas.millar@dhs.gov / 202-631-1915 > 24x7: soc@us-cert.gov / 888-282-0870 > > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Tuesday, February 21, 2012 12:49 > To: mile@ietf.org; Millar, Thomas R > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= sRe: MTI SCI?) > > Hi Tom, > > I believe I agree with you, although I'd like to add some precision on wh= at is meant by "parse". > > I don't think it's sufficient to support the value in the SpecID field (e= .g., a CVE > version) and accept an XML blob that is not a well-formed CVE XML documen= t. > > Hence, I think the minimum requirement is to validate the received SCI XM= L document against the > appropriate XML schema and detect any errors. > > Beyond that, Take's reference to RFC 5070 is a useful source of insight, = as I think it rules out most > additional requirements. IODEF is a format, not a protocol, so: > > A) Error reporting is specific to whatever transport protocol is = being used. > For example, if RID is used, the rfc6046-bis draft specif= ies how to > report errors, but there's no RFC 5070 requirement that I= ODEF use RID. > Beyond error detection, it's not possible to specify a re= quired error > reporting mechanism. > > B) RFC 5070 has nothing to say about replies or responses to IODE= F, so the > same should be true of extensions like SCI. > > C) I'm not sure I understand what Take had in mind by "how to und= erstand" in > #2. I see no need to understand CVE semantics or meaning= beyond the CVE > syntax check obtained by validating the received document= against the > CVE XML schema. > > > I would recommend that we be very clear in regards to what "support" > > or "minimally support" mean so that technical requirements handed down > > based on this draft do not bar achievement by operational implementers = and their engineering teams. > > I agree and would suggest: > > - The CVE SpecID value and related values (e.g., namespace) MUST > be supported (not cause errors if used). > - Recipient MUST validate received CVE XML document against the C= VE > XML schema to detect invalid CVE documents. > > I assume that this is all about CVE 1.0. > > Does all of this make sense? > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Thomas.Millar@us-cert.gov > > Sent: Tuesday, February 21, 2012 12:00 PM > > To: ariestake@googlemail.com; Moriarty, Kathleen; > > david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > takeshi_takahashi@nict.go.jp > > Cc: mile@ietf.org > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was Re: MTI SCI?) > > > > Take, > > > > I think you've done a very good job of explaining the two different > > interpretations around this call for consensus. > > > > My interpretation of MTI was closer to #2 - that to support this > > draft, an implementer would have to support not only recognition of > > the namespace in the appropriate IODEF parent class context, but also > > be able to parse the content of the referenced namespace. Hence my pref= erence for a relatively > simple and familiar spec as the MTI. > > > > If we can concur that we all really mean the interpretation you > > describe under #1, then I'm okay with having an MTI for each class. > > What that says to me is that each implementer would need to conform to > > the SCI draft's class placement of each namespace, but not necessarily > > have to be able to interpret the contents of said namespace(s). So all > > I have to do, minimally, is recognize the class under which any of the = referenced namespaces exist; > I don't have to have any means to parse or handle that class content othe= r than bucket it and move on > to the next. Is that right? > > > > I would recommend that we be very clear in regards to what "support" > > or "minimally support" mean so that technical requirements handed down > > based on this draft do not bar achievement by operational implementers = and their engineering teams. > > > > Thanks again, > > > > - Tom Millar, US-CERT > > > > thomas.millar@us-cert.gov > > BB: thomas.millar@dhs.gov / 202-631-1915 > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Takeshi Takahashi > > Sent: Monday, February 20, 2012 20:40 > > To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; > > trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > > Cc: mile@ietf.org > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > > (wasRe: MTI SCI?) > > > > Hello all, > > > > Thank you for your kind comments, which are really useful for me. > > On the other hand, I have some difficulties to understand what people s= pecifically mean by "support" > > or "mandatory". > > I would appreciate if you could kindly give me some comments on below. > > > > Below are my views on the MTI issues. > > > > 1. All the specification namespaces listed in the table MUST be > > "supported" as values for the SpecID field. > > > > These namespaces are the allowed ENUM values. > > So, in a way, all the specification listed in the table are supported. > > (implementations must allow these namespaces of all the specifications > > listed in the table as values for SpecID field) Since all the > > specification listed in the table are supported, we need to have > > expert review before registration (as we discussed in Quebec City) > > > > In this way, receivers can correctly understand the data. > > That will give us the same level of interoperability as the RFC 5070 > > (IODEF) does between sender and receiver, I think. > > > > > > 2. Implementers have freedom to define how to parse, how to understa= nd, > > and how to respond the IODEF extension message > > > > I might be wrong, but I do not think we would like to define how to > > parse the IODEF extension message at the receiver side. > > And I do not think we would like to define how to parse, for instance, > > CAPEC data, at the receiver side. > > I think the SCI draft is a container that conveys these structured > > information, and it can see such information as a blackbox with a tag (= namespace information). > > > > If above understanding is correct, I have some difficulty to > > understand the meaning of "mandatory to support CVE". > > As described in issue 1 above, if CVE or CAPEC data is attached, the > > implementation needs to recognize that the data is in CVE/CAPEC format,= and that is the requirement > for the implementation. > > What else do we want to mandate here, specifically? > > Do we need to manipulate the embedded xml data itself? I rather prefer > > to handle the data as a blackbox. > > > > I appreciate your kind comments. > > Regarding the other point Dave kindly pointed out, let me have another > > thread. (sorry I need to get on board now...) > > > > Thank you. > > > > Take > > > > > > > > > > -----Original Message----- > > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > > Sent: Monday, February 20, 2012 8:08 PM > > To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > takeshi_takahashi@nict.go.jp > > Cc: mile@ietf.org > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was > > Re: MTI SCI?) > > > > Thank you, Dave. > > > > Dave raises a few very important points as we consider MTI for SCI. > > We will need to resolve these issues if CVE is to be the (or an) MTI sp= ecification for the SCI > draft. > > > > If CVE is mandatory to implement, what guidance would be followed on > > how to use the model or will MTI only mean that the document can be rec= eived and > > parsed? The CVE website is listed as the specification URI, but from > > Dave's message, the specification URI does not exist to provide the > > guidance (I get to broken link pages for both - the existing and sugges= ted replacement link). > > > > This is the closest I could find and may be the answer for guidance: > > http://cve.mitre.org/compatible/requirements.html > > > > It looks like the reference to the target namespace needs to be fixed a= s well. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Walter= mire, David A. > > [david.waltermire@nist.gov] > > Sent: Thursday, February 16, 2012 5:26 PM > > To: Brian Trammell; Takeshi Takahashi > > Cc: mile@ietf.org > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was > > Re: MTI SCI?) > > > > I have not been following this thread as closely as I probably should. > > Relative to MTI, is the question what schema should be MTI for the > > vulerability class? In general I think we should have one or more MTI = for each class. > > > > Relative to CVE specifically, are we talking about the schema currently= located at: > > http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > > > This seems to match the namespace defined in section 4.1.7 of mile-sci-= 02. > > Looking at the implementation of this schema, it looks like the > > targetNamespace is incorrectly assigned to > > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it shoul= d be > "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be fi= xed. > > > > Also, the specification URI points to the CVE website, which is not > > really a specification. It's not clear where to find guidance on how > > to properly use the model indicated by the namespace. Without having > > clear guidance on its use I don't see how we can make it MTI, even if > > it is considered a de facto approach. It might make sense to produce a= specification for the model > before making it MTI for the vulnerability class. > > > > Sincerely, > > David Waltermire > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > > Of Brian Trammell > > > Sent: Wednesday, February 15, 2012 5:28 AM > > > To: Takeshi Takahashi > > > Cc: mile@ietf.org > > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI > > > (was > > > Re: MTI SCI?) > > > > > > Hi, Take, all, > > > > > > Thank you for this edit/clarification. > > > > > > On the first point, it does seem the discussion on the list > > > converged rather quickly to CVE as MTI. However, as this is a rather > > > important point, I'd like to make sure we didn't miss anything. > > > > > > So, I'd like to call for consensus on the list. Does the working > > > group agree on the following two points? > > > > > > 1. mile-sci requires one Mandatory to Implement schema in order to > > > ensure interoperability. > > > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of > > > mile- sci-02. > > > > > > Please note if you agree; if you disagree, please explain why not. > > > > > > Best regards, > > > > > > Brian (as chair) > > > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > > > Hello all, > > > > > > > > Following the discussion, I would like to add a couple of > > > > sentences > > > to > > > > clarify the MTI issues. > > > > (Thank you very much for those of you who kindly provided useful > > > > discussion.) > > > > I've attached the working version of the draft. I hope it helps to > > > > clarify the changes. > > > > > > > > (added sentences at the end of section 4.1) > > > > > > > > The SpecID attributes of extended classes (Section 4.3) must allo= w > > > > the values of the specifications' namespace fields, but otherwise= , > > > > implementations are not required to support all the above > > > > specifications. Implementations may choose which specifications = to > > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > > supported. In case an implementation received a data it does not > > > > support, it may expand its functionality by looking up the IANA > > > table or > > > > notify the sender of its inability to parse the data by using any > > > > means defined outside the scope of this specification. > > > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > > > class, which enables to embed data following private schema. > > > > For instance, one security operation center (SOC) may wish to > > > exchange > > > > a vulnerability data that is formatted in its own private schema, > > > > and that is not formatted in CVE. > > > > In this case, the SOC may put the data's schema ID inside > > > > ext-SpecID and then embed the data. > > > > It could also be used to exchange data using beta version of > > > specifications. > > > > > > > > The class could be seen as below. > > > > > > > > +------------------------+ > > > > | AttackPattern | > > > > +------------------------+ > > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > > +------------------------+ > > > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > > specifying the format of the RawData element. The value > > > > should > > > be > > > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > > > "private". Note that the lists in Section 4.1 will be develop= ed > > > > further by IANA. The value "private" is prepared for conveying > > > > RawData based on a format that is not listed in the > > > > table. This is usually used for conveying data formatted > > > > according to an organization's private schema. When the value > > > > "private" is used, ext-SpecID element needs to be used. > > > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > > specification > > > > specifying the format of the RawData element. When this eleme= nt > > > > is used, the value of SpecID element must be "private." > > > > > > > > I hope above changes don't cause any complication here. > > > > > > > > Sincerely, > > > > Take > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > >> Behalf Of Martin, Robert A. > > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > > >> To: Kent_Landfield@McAfee.com > > > >> Cc: mile@ietf.org > > > >> Subject: Re: [mile] MTI SCI? > > > >> > > > >> At the risk of contradicting myself - but then again I have now > > > >> read the other replies to this issue - I agree that having one > > > >> area be > > > the > > > >> smoke test makes sense and I also agree that something simple and > > > >> commonly used already - like CVE - is the best candidate for what > > > >> we > > > need. > > > >> > > > >> Bob > > > >> > > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > > >>> CVE is widely used and understood by all in the the security > > > community. > > > >> I agree with Tom that CVE is the path of least resistance but may > > > >> be the most useful for basic interoperability. > > > >>> > > > >>> Kent Landfield > > > >>> Director Content Strategy, Architecture and Standards > > > >>> > > > >>> McAfee | An Intel Company > > > >>> 5000 Headquarters Dr. > > > >>> Plano, Texas 75024 > > > >>> > > > >>> Direct: +1.972.963.7096 > > > >>> Mobile: +1.817.637.8026 > > > >>> Web: www.mcafee.com > > > >>> > > > >>> From: > > > >>> > > > >> "Thomas.Millar@us-cert.gov" > > >> ma > > > >> s > > > >> .M > > > >>> illar@us-cert.gov> > > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > > >>> To: > > > >>> > > > >> "david.black@emc.com" > > >> .c > > > >> o > > > >> m< > > > >>> mailto:david.black@emc.com>>, Bob > > > >>> Martin> > > > >>> Cc: > > > >>> > > > >> "mile@ietf.org" > > >> et > > > >> f > > > >> .o > > > >>> rg>> > > > >>> Subject: Re: [mile] MTI SCI? > > > >>> > > > >>> My concern with CAPEC being mandatory is that it could > > > >>> discourage > > > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > > > >> remains "too comprehensive" for many CSIRTs to employ during > > > incident > > > >> handling and reporting activity. > > > >>> > > > >>> IODEF by itself has been criticized by CSIRT operators for being > > > >>> more > > > >> heavyweight than necessary for day-to-day usage; making CAPEC a > > > >> mandatory aspect of "advanced IODEF" seems like it would be > > > >> adding ammunition to that argument, especially if the CSIRT is > > > >> having to fund implementation out of their own pocket. > > > >> Personally, I would > > > have > > > >> a hard time asking US-CERT's primary constituents to implement > > > >> IODEF > > > >> + CAPEC if they are already balking at the consultant and > > > >> + developer > > > >> resources required to implement RFC 5070 by itself. Also keep in > > > mind > > > >> that CAPEC references CybOX, so there's wheels within wheels now. > > > >>> > > > >>> I would prefer we take the path of least resistance (from my > > > > perspective) > > > >> and make CVE the MTI, if we have to pick one additional spec. > > > >>> CVE is well known, has years of familiarity built in, and I > > > >>> think it's > > > >> the simplest schema of the bunch. > > > >>> > > > >>> > > > >>> - Tom Millar, US-CERT > > > >>> > > > >>> thomas.millar@us-cert.gov > > > >>> BB: thomas.millar@dhs.gov / > > > >>> 202-631-1915 > > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > > >>> > > > >>> -----Original Message----- > > > >>> From: mile-bounces@ietf.org > > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > > >>> david.black@emc.com > > > >>> Sent: Tuesday, February 14, 2012 11:14 > > > >>> To: ramartin@mitre.org > > > >>> Cc: mile@ietf.org > > > >>> Subject: Re: [mile] MTI SCI? > > > >>> > > > >>> Hi Bob, > > > >>> > > > >>> I do appreciate the concern about implementing things that > > > >>> aren't going > > > >> to be used. OTOH, it may be useful to have a single simple MTI > > > >> spec for SCI that can be used to "smoke test" a deployment before > > > >> trying any > > > > serious > > > >> test data (and "simple" is important). > > > >>> > > > >>> In addition, a concern that I would have with an MTI SCI spec > > > >>> per class > > > >> is that if two SCI implementations don't have at least one class > > > >> in > > > > common, > > > >> they aren't going to interoperate, and that situation is unlikely > > > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per > > > >> class, I suspect that there will also have to be an MTI class, > > > >> which results in an overall MTI SCI spec). > > > >>> > > > >>> It may also be useful to include a simple example of the MTI SCI > > > >>> spec > > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > > > spec > > > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC > > > >> XML document for testing purposes, including enumeration values > > > >> suitable for testing). > > > >>> > > > >>> What do you (and others) think about this? > > > >>> > > > >>> Thanks, > > > >>> --David > > > >>> > > > >>> -----Original Message----- > > > >>> From: mile-bounces@ietf.org > > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > > >>> To: Brian Trammell > > > >>> Cc: mile@ietf.org > > > >>> Subject: Re: [mile] MTI SCI? > > > >>> Brian, > > > >>> You beat me to this point. Like you, I would be concerned about > > > >>> a MTI selection that ended up requiring someone to implement > > > something > > > >>> to meet the MTI but wasn't germane to anything else they > > > >>> intended > > > to > > > >> support. > > > >>> Bob > > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > > >>>> Hi, Sean, all, > > > >>>> > > > >>>> Looking over the spec, it's not clear to me that one MTI makes > > > >>>> sense here, given that mile-sci's > > > >>> purpose is to reference a set of external specifications by > > > >>> inclusion in an IODEF document, and that those external > > > >>> specifications represent > > > >> fundamentally different things. > > > >>>> > > > >>>> The specifications are split over their applicability to the > > > >>>> IODEF extension classes. I could > > > >>> envision an mile-sci implementation that was only interested a > > > >>> subset of these classes (perhaps even only one). If my > > > >>> implementation has an internal representation of Verification, > > > >>> but not of any of the other classes, and the MTI is an > > > >>> enumeration that is applicable to > > > >> Vulnerability... what do I do? > > > >>>> > > > >>>> What about selecting an MTI per class, instead? > > > >>>> > > > >>>> Best regards, > > > >>>> > > > >>>> Brian (as contributor) > > > >>>> > > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > >>>> > > > >>>>> Great - as long as we pick one as the MTI. Note that MTI is > > > >>>>> not > > > >> necessarily mandatory to use. > > > >>>>> > > > >>>>> spt > > > >>>>> > > > >>>>> On 2/13/12 7:11 PM, > > > >> kathleen.moriarty@emc.com wrote= : > > > >>>>>> Thank you for raising the interoperability testing as we need > > > >>>>>> to plan for a bake-off that once > > > >>> these questions get answered and the draft is ready. > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Kathleen > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: mile-bounces@ietf.org > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > > >>>>>> To: mile@ietf.org > > > >>>>>> Subject: [mile] MTI SCI? > > > >>>>>> > > > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > > > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > > > >>>>>> (mandatory to implement) choice? In other words, how will > > > >>>>>> you get two interoperability implementations without picking o= ne? > > > >>>>>> > > > >>>>>> spt > > > >>>>>> _______________________________________________ > > > >>>>>> mile mailing list > > > >>>>>> mile@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>>>> > > > >>>>>> > > > >>>>> _______________________________________________ > > > >>>>> mile mailing list > > > >>>>> mile@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mile mailing list > > > >>>> mile@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> . > > > >>>> > > > >>> _______________________________________________ > > > >>> mile mailing list > > > >>> mile@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > >>> > > > >>> _______________________________________________ > > > >>> mile mailing list > > > >>> mile@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > >>> _______________________________________________ > > > >>> mile mailing list > > > >>> mile@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > >>> > > > >>> > > > >> _______________________________________________ > > > >> mile mailing list > > > >> mile@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > - > > > 03c > > > > > > > andidate_20120215.txt.pdf>__________________________________________ > > > __ > > > > ___ > > > > mile mailing list > > > > mile@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > From david.black@emc.com Tue Feb 21 16:00:26 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E306821E805F for ; Tue, 21 Feb 2012 16:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.635 X-Spam-Level: X-Spam-Status: No, score=-109.635 tagged_above=-999 required=5 tests=[AWL=0.964, 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 DOKXlreiGlJm for ; Tue, 21 Feb 2012 16:00:22 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B27C721E806A for ; Tue, 21 Feb 2012 16:00:21 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1M00Ken027152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 19:00:21 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 21 Feb 2012 18:59:58 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1LNxwmO008526; Tue, 21 Feb 2012 18:59:58 -0500 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Tue, 21 Feb 2012 18:59:57 -0500 From: To: Date: Tue, 21 Feb 2012 18:59:56 -0500 Thread-Topic: Guidance on SCI usage Thread-Index: AczrzDOx+UzUfup8TqGaleJkelzyYgBKnXqQALGDu2UARtezUAAG0dFQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FF@MX14A.corp.emc.com> References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> , 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-EMM-MHVC: 1 Cc: mile@ietf.org Subject: [mile] Guidance on SCI usage X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 00:00:27 -0000 > For all referenced models, a larger concern is referencing a website for = guidance. A website can be > inherently unstable, as it can be changed at any time, and does not neces= sarily represent a consensus > opinion. I concur with the need for a stable reference for guidance on SCI spec usag= e, as the guidance could be quite important (e.g., prior discussion on how to use= MAEC in two different ways as an SCI). FWIW, I recently discovered independentl= y that IETF doesn't consider Wikipedia to be a stable reference ;-). Putting the guidance for usage of the initial specs into the SCI draft soun= ds like a good idea, especially as the IANA registry entries for all of those initi= al specs will point back to that draft (as an RFC), which should make the guidance e= asy to find for implementers. Beyond that I'm going to split a hair :-). An RFC is a good stable guidanc= e reference, but an informational RFC (as opposed to standards track) may suffice. I'd = suggest deferring that decision in favor of figuring out what the guidance needs to= cover. How does that sound? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of W= altermire, David A. > Sent: Tuesday, February 21, 2012 3:57 PM > To: Moriarty, Kathleen; trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.g= o.jp > Cc: mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= s Re: MTI SCI?) > > For all referenced models, a larger concern is referencing a website for = guidance. A website can be > inherantly unstable, as it can be changed at any time, and does not neces= sarily represent a consensous > opinion. One possibility might be to reference a standards track documen= t that specified the use of > the model. In addition the referenced document could possibly provide so= me parsing instructions for > the model addressing some of the concerns from the other discussion threa= d. This would require new > work to be completed before completing the SCI document, but would provid= e a more concrete foundation > for interoperable information exchange. > > Any thoughts on this approach? > > Sincerely, > David Waltermire > > > -----Original Message----- > > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > > Sent: Monday, February 20, 2012 6:08 AM > > To: Waltermire, David A.; trammell@tik.ee.ethz.ch; > > takeshi_takahashi@nict.go.jp > > Cc: mile@ietf.org > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was Re: MTI SCI?) > > > > Thank you, Dave. > > > > Dave raises a few very important points as we consider MTI for SCI. We > > will need to resolve these issues if CVE is to be the (or an) MTI > > specification for the SCI draft. > > > > If CVE is mandatory to implement, what guidance would be followed on > > how to use the model or will MTI only mean that the document can be > > received and parsed? The CVE website is listed as the specification > > URI, but from Dave's message, the specification URI does not exist to > > provide the guidance (I get to broken link pages for both - the > > existing and suggested replacement link). > > > > This is the closest I could find and may be the answer for guidance: > > http://cve.mitre.org/compatible/requirements.html > > > > It looks like the reference to the target namespace needs to be fixed > > as well. > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > > Waltermire, David A. [david.waltermire@nist.gov] > > Sent: Thursday, February 16, 2012 5:26 PM > > To: Brian Trammell; Takeshi Takahashi > > Cc: mile@ietf.org > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was Re: MTI SCI?) > > > > I have not been following this thread as closely as I probably should. > > Relative to MTI, is the question what schema should be MTI for the > > vulerability class? In general I think we should have one or more MTI > > for each class. > > > > Relative to CVE specifically, are we talking about the schema currently > > located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > > > This seems to match the namespace defined in section 4.1.7 of mile-sci- > > 02. Looking at the implementation of this schema, it looks like the > > targetNamespace is incorrectly assigned to > > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it > > should be "http://cve.mitre.org/cve/downloads/1.0". This will likely > > need to be fixed. > > > > Also, the specification URI points to the CVE website, which is not > > really a specification. It's not clear where to find guidance on how > > to properly use the model indicated by the namespace. Without having > > clear guidance on its use I don't see how we can make it MTI, even if > > it is considered a de facto approach. It might make sense to produce a > > specification for the model before making it MTI for the vulnerability > > class. > > > > Sincerely, > > David Waltermire > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > > Of Brian Trammell > > > Sent: Wednesday, February 15, 2012 5:28 AM > > > To: Takeshi Takahashi > > > Cc: mile@ietf.org > > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was > > > Re: MTI SCI?) > > > > > > Hi, Take, all, > > > > > > Thank you for this edit/clarification. > > > > > > On the first point, it does seem the discussion on the list converged > > > rather quickly to CVE as MTI. However, as this is a rather important > > > point, I'd like to make sure we didn't miss anything. > > > > > > So, I'd like to call for consensus on the list. Does the working > > group > > > agree on the following two points? > > > > > > 1. mile-sci requires one Mandatory to Implement schema in order to > > > ensure interoperability. > > > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- > > > sci-02. > > > > > > Please note if you agree; if you disagree, please explain why not. > > > > > > Best regards, > > > > > > Brian (as chair) > > > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > > > Hello all, > > > > > > > > Following the discussion, I would like to add a couple of sentences > > > to > > > > clarify the MTI issues. > > > > (Thank you very much for those of you who kindly provided useful > > > > discussion.) > > > > I've attached the working version of the draft. I hope it helps to > > > > clarify the changes. > > > > > > > > (added sentences at the end of section 4.1) > > > > > > > > The SpecID attributes of extended classes (Section 4.3) must > > allow > > > > the values of the specifications' namespace fields, but > > otherwise, > > > > implementations are not required to support all the above > > > > specifications. Implementations may choose which specifications > > to > > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > > supported. In case an implementation received a data it does not > > > > support, it may expand its functionality by looking up the IANA > > > table or > > > > notify the sender of its inability to parse the data by using any > > > > means defined outside the scope of this specification. > > > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to each > > > > class, which enables to embed data following private schema. > > > > For instance, one security operation center (SOC) may wish to > > > exchange > > > > a vulnerability data that is formatted in its own private schema, > > > > and that is not formatted in CVE. > > > > In this case, the SOC may put the data's schema ID inside ext- > > SpecID > > > > and then embed the data. > > > > It could also be used to exchange data using beta version of > > > specifications. > > > > > > > > The class could be seen as below. > > > > > > > > +------------------------+ > > > > | AttackPattern | > > > > +------------------------+ > > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > > +------------------------+ > > > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > > specifying the format of the RawData element. The value > > should > > > be > > > > chosen from the namespaces [XMLNames] listed in Section 4.1 or > > > > "private". Note that the lists in Section 4.1 will be > > developed > > > > further by IANA. The value "private" is prepared for conveying > > > > RawData based on a format that is not listed in the > > > > table. This is usually used for conveying data formatted > > > > according to an organization's private schema. When the value > > > > "private" is used, ext-SpecID element needs to be used. > > > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > > specification > > > > specifying the format of the RawData element. When this > > element > > > > is used, the value of SpecID element must be "private." > > > > > > > > I hope above changes don't cause any complication here. > > > > > > > > Sincerely, > > > > Take > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > >> Behalf Of Martin, Robert A. > > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > > >> To: Kent_Landfield@McAfee.com > > > >> Cc: mile@ietf.org > > > >> Subject: Re: [mile] MTI SCI? > > > >> > > > >> At the risk of contradicting myself - but then again I have now > > > >> read the other replies to this issue - I agree that having one > > area > > > >> be > > > the > > > >> smoke test makes sense and I also agree that something simple and > > > >> commonly used already - like CVE - is the best candidate for what > > > >> we > > > need. > > > >> > > > >> Bob > > > >> > > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > > >>> CVE is widely used and understood by all in the the security > > > community. > > > >> I agree with Tom that CVE is the path of least resistance but may > > > >> be the most useful for basic interoperability. > > > >>> > > > >>> Kent Landfield > > > >>> Director Content Strategy, Architecture and Standards > > > >>> > > > >>> McAfee | An Intel Company > > > >>> 5000 Headquarters Dr. > > > >>> Plano, Texas 75024 > > > >>> > > > >>> Direct: +1.972.963.7096 > > > >>> Mobile: +1.817.637.8026 > > > >>> Web: www.mcafee.com > > > >>> > > > >>> From: > > > >>> > > > >> "Thomas.Millar@us-cert.gov > cert.gov>" > > >> s > > > >> .M > > > >>> illar@us-cert.gov> > > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > > >>> To: > > > >>> > > > >> > > "david.black@emc.com" > > >> o > > > >> m< > > > >>> mailto:david.black@emc.com>>, Bob > > > >>> Martin> > > > >>> Cc: > > > >>> > > > >> > > "mile@ietf.org" > > >> f > > > >> .o > > > >>> rg>> > > > >>> Subject: Re: [mile] MTI SCI? > > > >>> > > > >>> My concern with CAPEC being mandatory is that it could discourage > > > >> effective operational uptake of IODEF-SCI as the CAPEC vocabulary > > > >> remains "too comprehensive" for many CSIRTs to employ during > > > incident > > > >> handling and reporting activity. > > > >>> > > > >>> IODEF by itself has been criticized by CSIRT operators for being > > > >>> more > > > >> heavyweight than necessary for day-to-day usage; making CAPEC a > > > >> mandatory aspect of "advanced IODEF" seems like it would be adding > > > >> ammunition to that argument, especially if the CSIRT is having to > > > >> fund implementation out of their own pocket. Personally, I would > > > have > > > >> a hard time asking US-CERT's primary constituents to implement > > > >> IODEF > > > >> + CAPEC if they are already balking at the consultant and > > developer > > > >> resources required to implement RFC 5070 by itself. Also keep in > > > mind > > > >> that CAPEC references CybOX, so there's wheels within wheels now. > > > >>> > > > >>> I would prefer we take the path of least resistance (from my > > > > perspective) > > > >> and make CVE the MTI, if we have to pick one additional spec. > > > >>> CVE is well known, has years of familiarity built in, and I think > > > >>> it's > > > >> the simplest schema of the bunch. > > > >>> > > > >>> > > > >>> - Tom Millar, US-CERT > > > >>> > > > >>> thomas.millar@us-cert.gov > > > >>> BB: thomas.millar@dhs.gov / > > > >>> 202-631-1915 > > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > > >>> > > > >>> -----Original Message----- > > > >>> From: mile-bounces@ietf.org > > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > > >>> david.black@emc.com > > > >>> Sent: Tuesday, February 14, 2012 11:14 > > > >>> To: ramartin@mitre.org > > > >>> Cc: mile@ietf.org > > > >>> Subject: Re: [mile] MTI SCI? > > > >>> > > > >>> Hi Bob, > > > >>> > > > >>> I do appreciate the concern about implementing things that aren't > > > >>> going > > > >> to be used. OTOH, it may be useful to have a single simple MTI > > > >> spec for SCI that can be used to "smoke test" a deployment before > > > >> trying any > > > > serious > > > >> test data (and "simple" is important). > > > >>> > > > >>> In addition, a concern that I would have with an MTI SCI spec per > > > >>> class > > > >> is that if two SCI implementations don't have at least one class > > in > > > > common, > > > >> they aren't going to interoperate, and that situation is unlikely > > > >> to be acceptable to the IESG (i.e., with an MTI SCI spec per > > class, > > > >> I suspect that there will also have to be an MTI class, which > > > >> results in an overall MTI SCI spec). > > > >>> > > > >>> It may also be useful to include a simple example of the MTI SCI > > > >>> spec > > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI > > > spec > > > >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC > > > >> XML document for testing purposes, including enumeration values > > > >> suitable for testing). > > > >>> > > > >>> What do you (and others) think about this? > > > >>> > > > >>> Thanks, > > > >>> --David > > > >>> > > > >>> -----Original Message----- > > > >>> From: mile-bounces@ietf.org > > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > > >>> To: Brian Trammell > > > >>> Cc: mile@ietf.org > > > >>> Subject: Re: [mile] MTI SCI? > > > >>> Brian, > > > >>> You beat me to this point. Like you, I would be concerned about > > a > > > >>> MTI selection that ended up requiring someone to implement > > > something > > > >>> to meet the MTI but wasn't germane to anything else they intended > > > to > > > >> support. > > > >>> Bob > > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > > >>>> Hi, Sean, all, > > > >>>> > > > >>>> Looking over the spec, it's not clear to me that one MTI makes > > > >>>> sense here, given that mile-sci's > > > >>> purpose is to reference a set of external specifications by > > > >>> inclusion in an IODEF document, and that those external > > > >>> specifications represent > > > >> fundamentally different things. > > > >>>> > > > >>>> The specifications are split over their applicability to the > > > >>>> IODEF extension classes. I could > > > >>> envision an mile-sci implementation that was only interested a > > > >>> subset of these classes (perhaps even only one). If my > > > >>> implementation has an internal representation of Verification, > > but > > > >>> not of any of the other classes, and the MTI is an enumeration > > > >>> that is applicable to > > > >> Vulnerability... what do I do? > > > >>>> > > > >>>> What about selecting an MTI per class, instead? > > > >>>> > > > >>>> Best regards, > > > >>>> > > > >>>> Brian (as contributor) > > > >>>> > > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > >>>> > > > >>>>> Great - as long as we pick one as the MTI. Note that MTI is > > not > > > >> necessarily mandatory to use. > > > >>>>> > > > >>>>> spt > > > >>>>> > > > >>>>> On 2/13/12 7:11 PM, > > > >> kathleen.moriarty@emc.com > > wrote: > > > >>>>>> Thank you for raising the interoperability testing as we need > > > >>>>>> to plan for a bake-off that once > > > >>> these questions get answered and the draft is ready. > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Kathleen > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: mile-bounces@ietf.org > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > > >>>>>> To: mile@ietf.org > > > >>>>>> Subject: [mile] MTI SCI? > > > >>>>>> > > > >>>>>> There's 17 listed SCI (Structured Cybersecurity Information) > > > >>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI > > > >>>>>> (mandatory to implement) choice? In other words, how will you > > > >>>>>> get two interoperability implementations without picking one? > > > >>>>>> > > > >>>>>> spt > > > >>>>>> _______________________________________________ > > > >>>>>> mile mailing list > > > >>>>>> mile@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>>>> > > > >>>>>> > > > >>>>> _______________________________________________ > > > >>>>> mile mailing list > > > >>>>> mile@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mile mailing list > > > >>>> mile@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> . > > > >>>> > > > >>> _______________________________________________ > > > >>> mile mailing list > > > >>> mile@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > >>> > > > >>> _______________________________________________ > > > >>> mile mailing list > > > >>> mile@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > >>> _______________________________________________ > > > >>> mile mailing list > > > >>> mile@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > >>> > > > >>> > > > >> _______________________________________________ > > > >> mile mailing list > > > >> mile@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > 03c > > > > > > > > > andidate_20120215.txt.pdf>____________________________________________ > > > > ___ > > > > mile mailing list > > > > mile@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Wed Feb 22 01:32:43 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E6B21F8996 for ; Wed, 22 Feb 2012 01:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 x-+LiYzHkwDm for ; Wed, 22 Feb 2012 01:32:42 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3521F8993 for ; Wed, 22 Feb 2012 01:32:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1EA6FD9312 for ; Wed, 22 Feb 2012 10:32:41 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DDS0LutoJdmx for ; Wed, 22 Feb 2012 10:32:40 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CAE4FD930A for ; Wed, 22 Feb 2012 10:32:40 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Brian Trammell In-Reply-To: Date: Wed, 22 Feb 2012 10:32:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com>, To: mile@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:32:43 -0000 Greetings, all, First, I'm very happy to see this productive discussion. Thank you all! = As chair, it's clear to me there's not consensus on these points yet = (from the original call): 1. mile-sci requires one Mandatory to Implement schema in order to ensure interoperability. 2. The Mandatory to Implement schema is the Common Vulnerability Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile- sci-02. and that the discussion should continue; I'll call for consensus again = once the working group has explored and understood the issues, and = converges on a solution. I may have misunderstood the intent of -sci as it stands, and I = apologize for the consensus call being based on my unstated assumption = that the content of a "CVE object" in an IODEF document would be a = _reference_ (as in Kathleen's point 1, below); indeed, I didn't even = consider the possibility that someone might want to move the _content_ = around via IODEF, and this assumption clearly colored my reading of the = document. Best regards, Brian (as co-chair) On Feb 21, 2012, at 10:36 PM, = wrote: > Hi all, >=20 > I think we have 2 possible issues to help break down this question. >=20 > 1) If you think about what we actually use CVE for, do we want to = pass the content of CVE around or for this case, just provide a CVE = number and perhaps a reference URL? Or do we want to set options and = guidance for handling both use cases (just an enumerated value and = reference URL and the use of another schema to extend the possible set = of data elements). >=20 > For the CVE enumeration use case, we may want to consider creating = tight guidance on how the Reference class of IODEF is used. We could = set the string value to be CVE and the number, roving strict guidance on = how that would be represented. Then also using the Reference URL. >=20 > There are other schemas in SCI where we clearly want to have the = ability to include a document created by another schema. >=20 > 2) When you extend to use a schema, for the most part, we might think = about this as a black box. IODEF already has guidance to handle the use = case of what to do when there its a schema that is included that cannot = be parsed (already provided on list). We are taking another step with = the SCI draft - I am in agreement with David on this for the meaning of = MTI. I *think* the MTI use case is not to take away from the black box = concept, but to test one instance of where the module can be parsed by = the receiving node. This helps us understand that this capability would = work for any other module that uses the same approach. Only one = specification would be MTI, so the others may not be implemented and may = respond via the guidance in IODEF. >=20 > The result of this conversation will help us understand what it means = to be compliant with SCI. If we are compliant with IODEF, then we have = guidance to follow the use case where we can't parse something. >=20 > Then we need to figure out if CVE is the right schema for this and = what we need to have appropriate guidance for that to really work - = specification and schema (David Waltermire's points)? >=20 > Thanks, > Kathleen From trammell@tik.ee.ethz.ch Wed Feb 22 01:34:40 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625AE21F893E for ; Wed, 22 Feb 2012 01:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 e2Kqxju2XWA0 for ; Wed, 22 Feb 2012 01:34:37 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 67D7221F893B for ; Wed, 22 Feb 2012 01:34:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BF381D9305; Wed, 22 Feb 2012 10:34:36 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oVS7me0gUqBk; Wed, 22 Feb 2012 10:34:36 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1CA55D9304; Wed, 22 Feb 2012 10:34:36 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> Date: Wed, 22 Feb 2012 10:34:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> To: X-Mailer: Apple Mail (2.1257) Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:34:40 -0000 Greetings, all, Taking my chair hat off, putting my contributor hat on now: I like Kathleen's suggestion, and would extend it: do we want to = consider explicitly considering the question from the standpoint of = "reference" separately from "containment". For things like CVE, a CVE = identifier is de facto operationally assumed to be a stable reference to = a static resource. (The stability of a CVE reference is probably _not_ = such that it could be used as a normative reference within the IETF; = however, it is as far as I know still common practice to treat it as = such in incident handling.) Interoperability for a reference then is tested by the following two = conditions: 1. an IODEF + SCI producer can take its internal representation of an = SCI object and convert it to a reference in a standard representation = which can be dereferenced by the consumer, perhaps relying on a = connection to an external resource. 2. an IODEF + SCI consumer can take a reference in a standard = representation from the IODEF document and deference it into its = internal representation of a substantially identical SCI object, perhaps = relying on a connection to an external resource. Considering the question from the content angle, interoperability looks = a bit more straightforward to test: 1. an IODEF + SCI producer can take its internal representation of an = SCI object and convert it into an XML element embedded in an IODEF = document. 2. an IODEF + SCI consumer can convert an XML element embedded in an = IODEF Document and convert it into its internal representation of a = substantially identical SCI object. This raises another issue, though. Let's say I send content about an = incident involving an exploit of CVE-2011-4692, a remote root = vulnerability in OpenBSD exploitable by sending a specific sequence of = unsolicited UDP packets. The receiver parses this and now knows that one = of my OpenBSD boxes got rooted by a magic packet attack exploiting = CVE-2011-4692. So the implementations are interoperable. Right?=20 Well, no. According to = http://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCVE-2011-4692, this is = a WebKit browser cache information leak vulnerability. So you can't = sensibly define interoperability in terms of content without reference = to the static resource. What do I do as a receiver when I get = information in content that conflicts with information in the referenced = resource? I suspect this is the case with most if not all of the enumerations = covered by SCI. I don't have deep familiarity with all the enumerations: = how many of these are commonly exchanged as references, and how many as = content? For those which are generally exchanged by reference, it would = seem to make sense to test "implementation" based on handling = references, and not content. Thoughts? Brian (as contributor) On Feb 22, 2012, at 12:47 AM, = wrote: > A "smoke test" is one of the motivations for this MTI requirement - = for that, > validation of the received content (e.g., against an XML schema for = XML content) > should be required, as one usually wants to know that the "smoke" made = it > through ok (the "smoke" that arrived matches what was sent). >=20 > So, even if the content will only be used as "smoke test" evidence, = and not > otherwise interpreted, it's still a good idea to require format = validation. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] >> Sent: Tuesday, February 21, 2012 4:18 PM >> To: Black, David; mile@ietf.org >> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI = (wasRe: MTI SCI?) >>=20 >> Should a recipient be required to validate a referenced schema even = if they don't intend to interpret >> the content? >>=20 >> - Tom Millar, US-CERT >>=20 >> thomas.millar@us-cert.gov >> BB: thomas.millar@dhs.gov / 202-631-1915 >> 24x7: soc@us-cert.gov / 888-282-0870 >>=20 >> -----Original Message----- >> From: david.black@emc.com [mailto:david.black@emc.com] >> Sent: Tuesday, February 21, 2012 12:49 >> To: mile@ietf.org; Millar, Thomas R >> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI = (wasRe: MTI SCI?) >>=20 >> Hi Tom, >>=20 >> I believe I agree with you, although I'd like to add some precision = on what is meant by "parse". >>=20 >> I don't think it's sufficient to support the value in the SpecID = field (e.g., a CVE >> version) and accept an XML blob that is not a well-formed CVE XML = document. >>=20 >> Hence, I think the minimum requirement is to validate the received = SCI XML document against the >> appropriate XML schema and detect any errors. >>=20 >> Beyond that, Take's reference to RFC 5070 is a useful source of = insight, as I think it rules out most >> additional requirements. IODEF is a format, not a protocol, so: >>=20 >> A) Error reporting is specific to whatever transport protocol = is being used. >> For example, if RID is used, the rfc6046-bis draft = specifies how to >> report errors, but there's no RFC 5070 requirement = that IODEF use RID. >> Beyond error detection, it's not possible to specify a = required error >> reporting mechanism. >>=20 >> B) RFC 5070 has nothing to say about replies or responses to = IODEF, so the >> same should be true of extensions like SCI. >>=20 >> C) I'm not sure I understand what Take had in mind by "how to = understand" in >> #2. I see no need to understand CVE semantics or = meaning beyond the CVE >> syntax check obtained by validating the received = document against the >> CVE XML schema. >>=20 >>> I would recommend that we be very clear in regards to what "support" >>> or "minimally support" mean so that technical requirements handed = down >>> based on this draft do not bar achievement by operational = implementers and their engineering teams. >>=20 >> I agree and would suggest: >>=20 >> - The CVE SpecID value and related values (e.g., namespace) = MUST >> be supported (not cause errors if used). >> - Recipient MUST validate received CVE XML document against = the CVE >> XML schema to detect invalid CVE documents. >>=20 >> I assume that this is all about CVE 1.0. >>=20 >> Does all of this make sense? >>=20 >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Thomas.Millar@us-cert.gov >>> Sent: Tuesday, February 21, 2012 12:00 PM >>> To: ariestake@googlemail.com; Moriarty, Kathleen; >>> david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >>> takeshi_takahashi@nict.go.jp >>> Cc: mile@ietf.org >>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for = SCI >>> (was Re: MTI SCI?) >>>=20 >>> Take, >>>=20 >>> I think you've done a very good job of explaining the two different >>> interpretations around this call for consensus. >>>=20 >>> My interpretation of MTI was closer to #2 - that to support this >>> draft, an implementer would have to support not only recognition of >>> the namespace in the appropriate IODEF parent class context, but = also >>> be able to parse the content of the referenced namespace. Hence my = preference for a relatively >> simple and familiar spec as the MTI. >>>=20 >>> If we can concur that we all really mean the interpretation you >>> describe under #1, then I'm okay with having an MTI for each class. >>> What that says to me is that each implementer would need to conform = to >>> the SCI draft's class placement of each namespace, but not = necessarily >>> have to be able to interpret the contents of said namespace(s). So = all >>> I have to do, minimally, is recognize the class under which any of = the referenced namespaces exist; >> I don't have to have any means to parse or handle that class content = other than bucket it and move on >> to the next. Is that right? >>>=20 >>> I would recommend that we be very clear in regards to what "support" >>> or "minimally support" mean so that technical requirements handed = down >>> based on this draft do not bar achievement by operational = implementers and their engineering teams. >>>=20 >>> Thanks again, >>>=20 >>> - Tom Millar, US-CERT >>>=20 >>> thomas.millar@us-cert.gov >>> BB: thomas.millar@dhs.gov / 202-631-1915 >>> 24x7: soc@us-cert.gov / 888-282-0870 >>>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of Takeshi Takahashi >>> Sent: Monday, February 20, 2012 20:40 >>> To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; >>> trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp >>> Cc: mile@ietf.org >>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for = SCI >>> (wasRe: MTI SCI?) >>>=20 >>> Hello all, >>>=20 >>> Thank you for your kind comments, which are really useful for me. >>> On the other hand, I have some difficulties to understand what = people specifically mean by "support" >>> or "mandatory". >>> I would appreciate if you could kindly give me some comments on = below. >>>=20 >>> Below are my views on the MTI issues. >>>=20 >>> 1. All the specification namespaces listed in the table MUST be >>> "supported" as values for the SpecID field. >>>=20 >>> These namespaces are the allowed ENUM values. >>> So, in a way, all the specification listed in the table are = supported. >>> (implementations must allow these namespaces of all the = specifications >>> listed in the table as values for SpecID field) Since all the >>> specification listed in the table are supported, we need to have >>> expert review before registration (as we discussed in Quebec City) >>>=20 >>> In this way, receivers can correctly understand the data. >>> That will give us the same level of interoperability as the RFC 5070 >>> (IODEF) does between sender and receiver, I think. >>>=20 >>>=20 >>> 2. Implementers have freedom to define how to parse, how to = understand, >>> and how to respond the IODEF extension message >>>=20 >>> I might be wrong, but I do not think we would like to define how to >>> parse the IODEF extension message at the receiver side. >>> And I do not think we would like to define how to parse, for = instance, >>> CAPEC data, at the receiver side. >>> I think the SCI draft is a container that conveys these structured >>> information, and it can see such information as a blackbox with a = tag (namespace information). >>>=20 >>> If above understanding is correct, I have some difficulty to >>> understand the meaning of "mandatory to support CVE". >>> As described in issue 1 above, if CVE or CAPEC data is attached, the >>> implementation needs to recognize that the data is in CVE/CAPEC = format, and that is the requirement >> for the implementation. >>> What else do we want to mandate here, specifically? >>> Do we need to manipulate the embedded xml data itself? I rather = prefer >>> to handle the data as a blackbox. >>>=20 >>> I appreciate your kind comments. >>> Regarding the other point Dave kindly pointed out, let me have = another >>> thread. (sorry I need to get on board now...) >>>=20 >>> Thank you. >>>=20 >>> Take >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] >>> Sent: Monday, February 20, 2012 8:08 PM >>> To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >>> takeshi_takahashi@nict.go.jp >>> Cc: mile@ietf.org >>> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for = SCI >>> (was >>> Re: MTI SCI?) >>>=20 >>> Thank you, Dave. >>>=20 >>> Dave raises a few very important points as we consider MTI for SCI. >>> We will need to resolve these issues if CVE is to be the (or an) MTI = specification for the SCI >> draft. >>>=20 >>> If CVE is mandatory to implement, what guidance would be followed on >>> how to use the model or will MTI only mean that the document can be = received and >>> parsed? The CVE website is listed as the specification URI, but = from >>> Dave's message, the specification URI does not exist to provide the >>> guidance (I get to broken link pages for both - the existing and = suggested replacement link). >>>=20 >>> This is the closest I could find and may be the answer for guidance: >>> http://cve.mitre.org/compatible/requirements.html >>>=20 >>> It looks like the reference to the target namespace needs to be = fixed as well. >>>=20 >>> Thank you, >>> Kathleen >>> ________________________________________ >>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Waltermire, David A. >>> [david.waltermire@nist.gov] >>> Sent: Thursday, February 16, 2012 5:26 PM >>> To: Brian Trammell; Takeshi Takahashi >>> Cc: mile@ietf.org >>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for = SCI >>> (was >>> Re: MTI SCI?) >>>=20 >>> I have not been following this thread as closely as I probably = should. >>> Relative to MTI, is the question what schema should be MTI for the >>> vulerability class? In general I think we should have one or more = MTI for each class. >>>=20 >>> Relative to CVE specifically, are we talking about the schema = currently located at: >>> http://cve.mitre.org/schema/cve/cve_1.0.xsd? >>>=20 >>> This seems to match the namespace defined in section 4.1.7 of = mile-sci-02. >>> Looking at the implementation of this schema, it looks like the >>> targetNamespace is incorrectly assigned to >>> "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it = should be >> "http://cve.mitre.org/cve/downloads/1.0". This will likely need to = be fixed. >>>=20 >>> Also, the specification URI points to the CVE website, which is not >>> really a specification. It's not clear where to find guidance on = how >>> to properly use the model indicated by the namespace. Without = having >>> clear guidance on its use I don't see how we can make it MTI, even = if >>> it is considered a de facto approach. It might make sense to = produce a specification for the model >> before making it MTI for the vulnerability class. >>>=20 >>> Sincerely, >>> David Waltermire >>>=20 >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf >>>> Of Brian Trammell >>>> Sent: Wednesday, February 15, 2012 5:28 AM >>>> To: Takeshi Takahashi >>>> Cc: mile@ietf.org >>>> Subject: [mile] Discussion / consensus call on CVE as MTI for SCI >>>> (was >>>> Re: MTI SCI?) >>>>=20 >>>> Hi, Take, all, >>>>=20 >>>> Thank you for this edit/clarification. >>>>=20 >>>> On the first point, it does seem the discussion on the list >>>> converged rather quickly to CVE as MTI. However, as this is a = rather >>>> important point, I'd like to make sure we didn't miss anything. >>>>=20 >>>> So, I'd like to call for consensus on the list. Does the working >>>> group agree on the following two points? >>>>=20 >>>> 1. mile-sci requires one Mandatory to Implement schema in order to >>>> ensure interoperability. >>>>=20 >>>> 2. The Mandatory to Implement schema is the Common Vulnerability >>>> Enumeration (CVE) version 1.0, as described in section 4.1.7 of >>>> mile- sci-02. >>>>=20 >>>> Please note if you agree; if you disagree, please explain why not. >>>>=20 >>>> Best regards, >>>>=20 >>>> Brian (as chair) >>>>=20 >>>> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >>>>=20 >>>>> Hello all, >>>>>=20 >>>>> Following the discussion, I would like to add a couple of >>>>> sentences >>>> to >>>>> clarify the MTI issues. >>>>> (Thank you very much for those of you who kindly provided useful >>>>> discussion.) >>>>> I've attached the working version of the draft. I hope it helps to >>>>> clarify the changes. >>>>>=20 >>>>> (added sentences at the end of section 4.1) >>>>>=20 >>>>> The SpecID attributes of extended classes (Section 4.3) must = allow >>>>> the values of the specifications' namespace fields, but = otherwise, >>>>> implementations are not required to support all the above >>>>> specifications. Implementations may choose which specifications = to >>>>> support, though CVE 1.0 (Section 4.1.7) needs to be minimally >>>>> supported. In case an implementation received a data it does not >>>>> support, it may expand its functionality by looking up the IANA >>>> table or >>>>> notify the sender of its inability to parse the data by using any >>>>> means defined outside the scope of this specification. >>>>>=20 >>>>> On the other hand, I would like to add "STRING ext-SpecID" to each >>>>> class, which enables to embed data following private schema. >>>>> For instance, one security operation center (SOC) may wish to >>>> exchange >>>>> a vulnerability data that is formatted in its own private schema, >>>>> and that is not formatted in CVE. >>>>> In this case, the SOC may put the data's schema ID inside >>>>> ext-SpecID and then embed the data. >>>>> It could also be used to exchange data using beta version of >>>> specifications. >>>>>=20 >>>>> The class could be seen as below. >>>>>=20 >>>>> +------------------------+ >>>>> | AttackPattern | >>>>> +------------------------+ >>>>> | ENUM SpecID |<>--(0..*)-[ RawData ] >>>>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >>>>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] >>>>> +------------------------+ >>>>>=20 >>>>> SpecID: REQUIRED. ENUM. The identifier of the specification >>>>> specifying the format of the RawData element. The value >>>>> should >>>> be >>>>> chosen from the namespaces [XMLNames] listed in Section 4.1 or >>>>> "private". Note that the lists in Section 4.1 will be = developed >>>>> further by IANA. The value "private" is prepared for conveying >>>>> RawData based on a format that is not listed in the >>>>> table. This is usually used for conveying data formatted >>>>> according to an organization's private schema. When the value >>>>> "private" is used, ext-SpecID element needs to be used. >>>>>=20 >>>>> ext-SpecID: OPTIONAL. STRING. The identifier of the >>>> specification >>>>> specifying the format of the RawData element. When this = element >>>>> is used, the value of SpecID element must be "private." >>>>>=20 >>>>> I hope above changes don't cause any complication here. >>>>>=20 >>>>> Sincerely, >>>>> Take >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>>> Behalf Of Martin, Robert A. >>>>>> Sent: Wednesday, February 15, 2012 1:50 AM >>>>>> To: Kent_Landfield@McAfee.com >>>>>> Cc: mile@ietf.org >>>>>> Subject: Re: [mile] MTI SCI? >>>>>>=20 >>>>>> At the risk of contradicting myself - but then again I have now >>>>>> read the other replies to this issue - I agree that having one >>>>>> area be >>>> the >>>>>> smoke test makes sense and I also agree that something simple and >>>>>> commonly used already - like CVE - is the best candidate for what >>>>>> we >>>> need. >>>>>>=20 >>>>>> Bob >>>>>>=20 >>>>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>>>>> CVE is widely used and understood by all in the the security >>>> community. >>>>>> I agree with Tom that CVE is the path of least resistance but may >>>>>> be the most useful for basic interoperability. >>>>>>>=20 >>>>>>> Kent Landfield >>>>>>> Director Content Strategy, Architecture and Standards >>>>>>>=20 >>>>>>> McAfee | An Intel Company >>>>>>> 5000 Headquarters Dr. >>>>>>> Plano, Texas 75024 >>>>>>>=20 >>>>>>> Direct: +1.972.963.7096 >>>>>>> Mobile: +1.817.637.8026 >>>>>>> Web: www.mcafee.com >>>>>>>=20 >>>>>>> From: >>>>>>>=20 >>>>>> "Thomas.Millar@us-cert.gov">>>>> ma >>>>>> s >>>>>> .M >>>>>>> illar@us-cert.gov> >>>>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>>>>> To: >>>>>>>=20 >>>>>> "david.black@emc.com">>>>> .c >>>>>> o >>>>>> m< >>>>>>> mailto:david.black@emc.com>>, Bob >>>>>>> Martin> >>>>>>> Cc: >>>>>>>=20 >>>>>> "mile@ietf.org">>>>> et >>>>>> f >>>>>> .o >>>>>>> rg>> >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>=20 >>>>>>> My concern with CAPEC being mandatory is that it could >>>>>>> discourage >>>>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary >>>>>> remains "too comprehensive" for many CSIRTs to employ during >>>> incident >>>>>> handling and reporting activity. >>>>>>>=20 >>>>>>> IODEF by itself has been criticized by CSIRT operators for being >>>>>>> more >>>>>> heavyweight than necessary for day-to-day usage; making CAPEC a >>>>>> mandatory aspect of "advanced IODEF" seems like it would be >>>>>> adding ammunition to that argument, especially if the CSIRT is >>>>>> having to fund implementation out of their own pocket. >>>>>> Personally, I would >>>> have >>>>>> a hard time asking US-CERT's primary constituents to implement >>>>>> IODEF >>>>>> + CAPEC if they are already balking at the consultant and >>>>>> + developer >>>>>> resources required to implement RFC 5070 by itself. Also keep in >>>> mind >>>>>> that CAPEC references CybOX, so there's wheels within wheels now. >>>>>>>=20 >>>>>>> I would prefer we take the path of least resistance (from my >>>>> perspective) >>>>>> and make CVE the MTI, if we have to pick one additional spec. >>>>>>> CVE is well known, has years of familiarity built in, and I >>>>>>> think it's >>>>>> the simplest schema of the bunch. >>>>>>>=20 >>>>>>>=20 >>>>>>> - Tom Millar, US-CERT >>>>>>>=20 >>>>>>> thomas.millar@us-cert.gov >>>>>>> BB: thomas.millar@dhs.gov / >>>>>>> 202-631-1915 >>>>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org >>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>>>> david.black@emc.com >>>>>>> Sent: Tuesday, February 14, 2012 11:14 >>>>>>> To: ramartin@mitre.org >>>>>>> Cc: mile@ietf.org >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>=20 >>>>>>> Hi Bob, >>>>>>>=20 >>>>>>> I do appreciate the concern about implementing things that >>>>>>> aren't going >>>>>> to be used. OTOH, it may be useful to have a single simple MTI >>>>>> spec for SCI that can be used to "smoke test" a deployment before >>>>>> trying any >>>>> serious >>>>>> test data (and "simple" is important). >>>>>>>=20 >>>>>>> In addition, a concern that I would have with an MTI SCI spec >>>>>>> per class >>>>>> is that if two SCI implementations don't have at least one class >>>>>> in >>>>> common, >>>>>> they aren't going to interoperate, and that situation is unlikely >>>>>> to be acceptable to the IESG (i.e., with an MTI SCI spec per >>>>>> class, I suspect that there will also have to be an MTI class, >>>>>> which results in an overall MTI SCI spec). >>>>>>>=20 >>>>>>> It may also be useful to include a simple example of the MTI SCI >>>>>>> spec >>>>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI >>>> spec >>>>>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC >>>>>> XML document for testing purposes, including enumeration values >>>>>> suitable for testing). >>>>>>>=20 >>>>>>> What do you (and others) think about this? >>>>>>>=20 >>>>>>> Thanks, >>>>>>> --David >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>>>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>>>>> To: Brian Trammell >>>>>>> Cc: mile@ietf.org >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>> Brian, >>>>>>> You beat me to this point. Like you, I would be concerned about >>>>>>> a MTI selection that ended up requiring someone to implement >>>> something >>>>>>> to meet the MTI but wasn't germane to anything else they >>>>>>> intended >>>> to >>>>>> support. >>>>>>> Bob >>>>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>>>>> Hi, Sean, all, >>>>>>>>=20 >>>>>>>> Looking over the spec, it's not clear to me that one MTI makes >>>>>>>> sense here, given that mile-sci's >>>>>>> purpose is to reference a set of external specifications by >>>>>>> inclusion in an IODEF document, and that those external >>>>>>> specifications represent >>>>>> fundamentally different things. >>>>>>>>=20 >>>>>>>> The specifications are split over their applicability to the >>>>>>>> IODEF extension classes. I could >>>>>>> envision an mile-sci implementation that was only interested a >>>>>>> subset of these classes (perhaps even only one). If my >>>>>>> implementation has an internal representation of Verification, >>>>>>> but not of any of the other classes, and the MTI is an >>>>>>> enumeration that is applicable to >>>>>> Vulnerability... what do I do? >>>>>>>>=20 >>>>>>>> What about selecting an MTI per class, instead? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Brian (as contributor) >>>>>>>>=20 >>>>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>>>>=20 >>>>>>>>> Great - as long as we pick one as the MTI. Note that MTI is >>>>>>>>> not >>>>>> necessarily mandatory to use. >>>>>>>>>=20 >>>>>>>>> spt >>>>>>>>>=20 >>>>>>>>> On 2/13/12 7:11 PM, >>>>>> kathleen.moriarty@emc.com = wrote: >>>>>>>>>> Thank you for raising the interoperability testing as we need >>>>>>>>>> to plan for a bake-off that once >>>>>>> these questions get answered and the draft is ready. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Kathleen >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mile-bounces@ietf.org >>>>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>>>>> To: mile@ietf.org >>>>>>>>>> Subject: [mile] MTI SCI? >>>>>>>>>>=20 >>>>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>>>>>> (mandatory to implement) choice? In other words, how will >>>>>>>>>> you get two interoperability implementations without picking = one? >>>>>>>>>>=20 >>>>>>>>>> spt >>>>>>>>>> _______________________________________________ >>>>>>>>>> mile mailing list >>>>>>>>>> mile@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> mile mailing list >>>>>>>>> mile@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>> . >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>=20 >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>> - >>>> 03c >>>>>=20 >>>> = andidate_20120215.txt.pdf>__________________________________________ >>>> __ >>>>> ___ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From ramartin@mitre.org Wed Feb 22 04:04:04 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F5721F8717 for ; Wed, 22 Feb 2012 04:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vB4MKcOk0xFp for ; Wed, 22 Feb 2012 04:04:01 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2628521F8715 for ; Wed, 22 Feb 2012 04:04:01 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 53FC521B1877; Wed, 22 Feb 2012 07:04:00 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 331E121B1862; Wed, 22 Feb 2012 07:04:00 -0500 (EST) Received: from bvb-172-31-36-48.mitre.org (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.339.1; Wed, 22 Feb 2012 07:03:59 -0500 Message-ID: <4F44D9A0.1010707@mitre.org> Date: Wed, 22 Feb 2012 07:03:44 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian Trammell References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: mile@ietf.org Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 12:04:04 -0000 Brian, I am confused. Unlike the two texts you quoted I found the exact same text from that CVE at the CVE site and the NVD site. Bob http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4692 WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 and earlier, does not prevent capture of data about the time required for image loading, which makes it easier for remote attackers to determine whether an image exists in the browser cache via crafted JavaScript code, as demonstrated by visipisi. http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4692 WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 and earlier, does not prevent capture of data about the time required for image loading, which makes it easier for remote attackers to determine whether an image exists in the browser cache via crafted JavaScript code, as demonstrated by visipisi. On 2/22/12 4:34 AM, Brian Trammell wrote: > Greetings, all, > > Taking my chair hat off, putting my contributor hat on now: > > I like Kathleen's suggestion, and would extend it: do we want to consider explicitly considering the question from the standpoint of "reference" separately from "containment". For things like CVE, a CVE identifier is de facto operationally assumed to be a stable reference to a static resource. (The stability of a CVE reference is probably _not_ such that it could be used as a normative reference within the IETF; however, it is as far as I know still common practice to treat it as such in incident handling.) > > Interoperability for a reference then is tested by the following two conditions: > > 1. an IODEF + SCI producer can take its internal representation of an SCI object and convert it to a reference in a standard representation which can be dereferenced by the consumer, perhaps relying on a connection to an external resource. > > 2. an IODEF + SCI consumer can take a reference in a standard representation from the IODEF document and deference it into its internal representation of a substantially identical SCI object, perhaps relying on a connection to an external resource. > > Considering the question from the content angle, interoperability looks a bit more straightforward to test: > > 1. an IODEF + SCI producer can take its internal representation of an SCI object and convert it into an XML element embedded in an IODEF document. > > 2. an IODEF + SCI consumer can convert an XML element embedded in an IODEF Document and convert it into its internal representation of a substantially identical SCI object. > > This raises another issue, though. Let's say I send content about an incident involving an exploit of CVE-2011-4692, a remote root vulnerability in OpenBSD exploitable by sending a specific sequence of unsolicited UDP packets. The receiver parses this and now knows that one of my OpenBSD boxes got rooted by a magic packet attack exploiting CVE-2011-4692. So the implementations are interoperable. Right? > > Well, no. According to http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4692, this is a WebKit browser cache information leak vulnerability. So you can't sensibly define interoperability in terms of content without reference to the static resource. What do I do as a receiver when I get information in content that conflicts with information in the referenced resource? > > I suspect this is the case with most if not all of the enumerations covered by SCI. I don't have deep familiarity with all the enumerations: how many of these are commonly exchanged as references, and how many as content? For those which are generally exchanged by reference, it would seem to make sense to test "implementation" based on handling references, and not content. > > Thoughts? > > Brian (as contributor) > > On Feb 22, 2012, at 12:47 AM, wrote: > >> A "smoke test" is one of the motivations for this MTI requirement - for that, >> validation of the received content (e.g., against an XML schema for XML content) >> should be required, as one usually wants to know that the "smoke" made it >> through ok (the "smoke" that arrived matches what was sent). >> >> So, even if the content will only be used as "smoke test" evidence, and not >> otherwise interpreted, it's still a good idea to require format validation. >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] >>> Sent: Tuesday, February 21, 2012 4:18 PM >>> To: Black, David; mile@ietf.org >>> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) >>> >>> Should a recipient be required to validate a referenced schema even if they don't intend to interpret >>> the content? >>> >>> - Tom Millar, US-CERT >>> >>> thomas.millar@us-cert.gov >>> BB: thomas.millar@dhs.gov / 202-631-1915 >>> 24x7: soc@us-cert.gov / 888-282-0870 >>> >>> -----Original Message----- >>> From: david.black@emc.com [mailto:david.black@emc.com] >>> Sent: Tuesday, February 21, 2012 12:49 >>> To: mile@ietf.org; Millar, Thomas R >>> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?) >>> >>> Hi Tom, >>> >>> I believe I agree with you, although I'd like to add some precision on what is meant by "parse". >>> >>> I don't think it's sufficient to support the value in the SpecID field (e.g., a CVE >>> version) and accept an XML blob that is not a well-formed CVE XML document. >>> >>> Hence, I think the minimum requirement is to validate the received SCI XML document against the >>> appropriate XML schema and detect any errors. >>> >>> Beyond that, Take's reference to RFC 5070 is a useful source of insight, as I think it rules out most >>> additional requirements. IODEF is a format, not a protocol, so: >>> >>> A) Error reporting is specific to whatever transport protocol is being used. >>> For example, if RID is used, the rfc6046-bis draft specifies how to >>> report errors, but there's no RFC 5070 requirement that IODEF use RID. >>> Beyond error detection, it's not possible to specify a required error >>> reporting mechanism. >>> >>> B) RFC 5070 has nothing to say about replies or responses to IODEF, so the >>> same should be true of extensions like SCI. >>> >>> C) I'm not sure I understand what Take had in mind by "how to understand" in >>> #2. I see no need to understand CVE semantics or meaning beyond the CVE >>> syntax check obtained by validating the received document against the >>> CVE XML schema. >>> >>>> I would recommend that we be very clear in regards to what "support" >>>> or "minimally support" mean so that technical requirements handed down >>>> based on this draft do not bar achievement by operational implementers and their engineering teams. >>> >>> I agree and would suggest: >>> >>> - The CVE SpecID value and related values (e.g., namespace) MUST >>> be supported (not cause errors if used). >>> - Recipient MUST validate received CVE XML document against the CVE >>> XML schema to detect invalid CVE documents. >>> >>> I assume that this is all about CVE 1.0. >>> >>> Does all of this make sense? >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>> Of Thomas.Millar@us-cert.gov >>>> Sent: Tuesday, February 21, 2012 12:00 PM >>>> To: ariestake@googlemail.com; Moriarty, Kathleen; >>>> david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >>>> takeshi_takahashi@nict.go.jp >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI >>>> (was Re: MTI SCI?) >>>> >>>> Take, >>>> >>>> I think you've done a very good job of explaining the two different >>>> interpretations around this call for consensus. >>>> >>>> My interpretation of MTI was closer to #2 - that to support this >>>> draft, an implementer would have to support not only recognition of >>>> the namespace in the appropriate IODEF parent class context, but also >>>> be able to parse the content of the referenced namespace. Hence my preference for a relatively >>> simple and familiar spec as the MTI. >>>> >>>> If we can concur that we all really mean the interpretation you >>>> describe under #1, then I'm okay with having an MTI for each class. >>>> What that says to me is that each implementer would need to conform to >>>> the SCI draft's class placement of each namespace, but not necessarily >>>> have to be able to interpret the contents of said namespace(s). So all >>>> I have to do, minimally, is recognize the class under which any of the referenced namespaces exist; >>> I don't have to have any means to parse or handle that class content other than bucket it and move on >>> to the next. Is that right? >>>> >>>> I would recommend that we be very clear in regards to what "support" >>>> or "minimally support" mean so that technical requirements handed down >>>> based on this draft do not bar achievement by operational implementers and their engineering teams. >>>> >>>> Thanks again, >>>> >>>> - Tom Millar, US-CERT >>>> >>>> thomas.millar@us-cert.gov >>>> BB: thomas.millar@dhs.gov / 202-631-1915 >>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>> Of Takeshi Takahashi >>>> Sent: Monday, February 20, 2012 20:40 >>>> To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; >>>> trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI >>>> (wasRe: MTI SCI?) >>>> >>>> Hello all, >>>> >>>> Thank you for your kind comments, which are really useful for me. >>>> On the other hand, I have some difficulties to understand what people specifically mean by "support" >>>> or "mandatory". >>>> I would appreciate if you could kindly give me some comments on below. >>>> >>>> Below are my views on the MTI issues. >>>> >>>> 1. All the specification namespaces listed in the table MUST be >>>> "supported" as values for the SpecID field. >>>> >>>> These namespaces are the allowed ENUM values. >>>> So, in a way, all the specification listed in the table are supported. >>>> (implementations must allow these namespaces of all the specifications >>>> listed in the table as values for SpecID field) Since all the >>>> specification listed in the table are supported, we need to have >>>> expert review before registration (as we discussed in Quebec City) >>>> >>>> In this way, receivers can correctly understand the data. >>>> That will give us the same level of interoperability as the RFC 5070 >>>> (IODEF) does between sender and receiver, I think. >>>> >>>> >>>> 2. Implementers have freedom to define how to parse, how to understand, >>>> and how to respond the IODEF extension message >>>> >>>> I might be wrong, but I do not think we would like to define how to >>>> parse the IODEF extension message at the receiver side. >>>> And I do not think we would like to define how to parse, for instance, >>>> CAPEC data, at the receiver side. >>>> I think the SCI draft is a container that conveys these structured >>>> information, and it can see such information as a blackbox with a tag (namespace information). >>>> >>>> If above understanding is correct, I have some difficulty to >>>> understand the meaning of "mandatory to support CVE". >>>> As described in issue 1 above, if CVE or CAPEC data is attached, the >>>> implementation needs to recognize that the data is in CVE/CAPEC format, and that is the requirement >>> for the implementation. >>>> What else do we want to mandate here, specifically? >>>> Do we need to manipulate the embedded xml data itself? I rather prefer >>>> to handle the data as a blackbox. >>>> >>>> I appreciate your kind comments. >>>> Regarding the other point Dave kindly pointed out, let me have another >>>> thread. (sorry I need to get on board now...) >>>> >>>> Thank you. >>>> >>>> Take >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] >>>> Sent: Monday, February 20, 2012 8:08 PM >>>> To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >>>> takeshi_takahashi@nict.go.jp >>>> Cc: mile@ietf.org >>>> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI >>>> (was >>>> Re: MTI SCI?) >>>> >>>> Thank you, Dave. >>>> >>>> Dave raises a few very important points as we consider MTI for SCI. >>>> We will need to resolve these issues if CVE is to be the (or an) MTI specification for the SCI >>> draft. >>>> >>>> If CVE is mandatory to implement, what guidance would be followed on >>>> how to use the model or will MTI only mean that the document can be received and >>>> parsed? The CVE website is listed as the specification URI, but from >>>> Dave's message, the specification URI does not exist to provide the >>>> guidance (I get to broken link pages for both - the existing and suggested replacement link). >>>> >>>> This is the closest I could find and may be the answer for guidance: >>>> http://cve.mitre.org/compatible/requirements.html >>>> >>>> It looks like the reference to the target namespace needs to be fixed as well. >>>> >>>> Thank you, >>>> Kathleen >>>> ________________________________________ >>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Waltermire, David A. >>>> [david.waltermire@nist.gov] >>>> Sent: Thursday, February 16, 2012 5:26 PM >>>> To: Brian Trammell; Takeshi Takahashi >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI >>>> (was >>>> Re: MTI SCI?) >>>> >>>> I have not been following this thread as closely as I probably should. >>>> Relative to MTI, is the question what schema should be MTI for the >>>> vulerability class? In general I think we should have one or more MTI for each class. >>>> >>>> Relative to CVE specifically, are we talking about the schema currently located at: >>>> http://cve.mitre.org/schema/cve/cve_1.0.xsd? >>>> >>>> This seems to match the namespace defined in section 4.1.7 of mile-sci-02. >>>> Looking at the implementation of this schema, it looks like the >>>> targetNamespace is incorrectly assigned to >>>> "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be >>> "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be fixed. >>>> >>>> Also, the specification URI points to the CVE website, which is not >>>> really a specification. It's not clear where to find guidance on how >>>> to properly use the model indicated by the namespace. Without having >>>> clear guidance on its use I don't see how we can make it MTI, even if >>>> it is considered a de facto approach. It might make sense to produce a specification for the model >>> before making it MTI for the vulnerability class. >>>> >>>> Sincerely, >>>> David Waltermire >>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Brian Trammell >>>>> Sent: Wednesday, February 15, 2012 5:28 AM >>>>> To: Takeshi Takahashi >>>>> Cc: mile@ietf.org >>>>> Subject: [mile] Discussion / consensus call on CVE as MTI for SCI >>>>> (was >>>>> Re: MTI SCI?) >>>>> >>>>> Hi, Take, all, >>>>> >>>>> Thank you for this edit/clarification. >>>>> >>>>> On the first point, it does seem the discussion on the list >>>>> converged rather quickly to CVE as MTI. However, as this is a rather >>>>> important point, I'd like to make sure we didn't miss anything. >>>>> >>>>> So, I'd like to call for consensus on the list. Does the working >>>>> group agree on the following two points? >>>>> >>>>> 1. mile-sci requires one Mandatory to Implement schema in order to >>>>> ensure interoperability. >>>>> >>>>> 2. The Mandatory to Implement schema is the Common Vulnerability >>>>> Enumeration (CVE) version 1.0, as described in section 4.1.7 of >>>>> mile- sci-02. >>>>> >>>>> Please note if you agree; if you disagree, please explain why not. >>>>> >>>>> Best regards, >>>>> >>>>> Brian (as chair) >>>>> >>>>> On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> Following the discussion, I would like to add a couple of >>>>>> sentences >>>>> to >>>>>> clarify the MTI issues. >>>>>> (Thank you very much for those of you who kindly provided useful >>>>>> discussion.) >>>>>> I've attached the working version of the draft. I hope it helps to >>>>>> clarify the changes. >>>>>> >>>>>> (added sentences at the end of section 4.1) >>>>>> >>>>>> The SpecID attributes of extended classes (Section 4.3) must allow >>>>>> the values of the specifications' namespace fields, but otherwise, >>>>>> implementations are not required to support all the above >>>>>> specifications. Implementations may choose which specifications to >>>>>> support, though CVE 1.0 (Section 4.1.7) needs to be minimally >>>>>> supported. In case an implementation received a data it does not >>>>>> support, it may expand its functionality by looking up the IANA >>>>> table or >>>>>> notify the sender of its inability to parse the data by using any >>>>>> means defined outside the scope of this specification. >>>>>> >>>>>> On the other hand, I would like to add "STRING ext-SpecID" to each >>>>>> class, which enables to embed data following private schema. >>>>>> For instance, one security operation center (SOC) may wish to >>>>> exchange >>>>>> a vulnerability data that is formatted in its own private schema, >>>>>> and that is not formatted in CVE. >>>>>> In this case, the SOC may put the data's schema ID inside >>>>>> ext-SpecID and then embed the data. >>>>>> It could also be used to exchange data using beta version of >>>>> specifications. >>>>>> >>>>>> The class could be seen as below. >>>>>> >>>>>> +------------------------+ >>>>>> | AttackPattern | >>>>>> +------------------------+ >>>>>> | ENUM SpecID |<>--(0..*)-[ RawData ] >>>>>> | STRING ext-SpecID |<>--(0..*)-[ Reference ] >>>>>> | STRING AttackPatternID |<>--(0..*)-[ Platform ] >>>>>> +------------------------+ >>>>>> >>>>>> SpecID: REQUIRED. ENUM. The identifier of the specification >>>>>> specifying the format of the RawData element. The value >>>>>> should >>>>> be >>>>>> chosen from the namespaces [XMLNames] listed in Section 4.1 or >>>>>> "private". Note that the lists in Section 4.1 will be developed >>>>>> further by IANA. The value "private" is prepared for conveying >>>>>> RawData based on a format that is not listed in the >>>>>> table. This is usually used for conveying data formatted >>>>>> according to an organization's private schema. When the value >>>>>> "private" is used, ext-SpecID element needs to be used. >>>>>> >>>>>> ext-SpecID: OPTIONAL. STRING. The identifier of the >>>>> specification >>>>>> specifying the format of the RawData element. When this element >>>>>> is used, the value of SpecID element must be "private." >>>>>> >>>>>> I hope above changes don't cause any complication here. >>>>>> >>>>>> Sincerely, >>>>>> Take >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>>>> Behalf Of Martin, Robert A. >>>>>>> Sent: Wednesday, February 15, 2012 1:50 AM >>>>>>> To: Kent_Landfield@McAfee.com >>>>>>> Cc: mile@ietf.org >>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>> >>>>>>> At the risk of contradicting myself - but then again I have now >>>>>>> read the other replies to this issue - I agree that having one >>>>>>> area be >>>>> the >>>>>>> smoke test makes sense and I also agree that something simple and >>>>>>> commonly used already - like CVE - is the best candidate for what >>>>>>> we >>>>> need. >>>>>>> >>>>>>> Bob >>>>>>> >>>>>>> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: >>>>>>>> CVE is widely used and understood by all in the the security >>>>> community. >>>>>>> I agree with Tom that CVE is the path of least resistance but may >>>>>>> be the most useful for basic interoperability. >>>>>>>> >>>>>>>> Kent Landfield >>>>>>>> Director Content Strategy, Architecture and Standards >>>>>>>> >>>>>>>> McAfee | An Intel Company >>>>>>>> 5000 Headquarters Dr. >>>>>>>> Plano, Texas 75024 >>>>>>>> >>>>>>>> Direct: +1.972.963.7096 >>>>>>>> Mobile: +1.817.637.8026 >>>>>>>> Web: www.mcafee.com >>>>>>>> >>>>>>>> From: >>>>>>>> >>>>>>> "Thomas.Millar@us-cert.gov">>>>>> ma >>>>>>> s >>>>>>> .M >>>>>>>> illar@us-cert.gov> >>>>>>>> Date: Tue, 14 Feb 2012 10:36:57 -0600 >>>>>>>> To: >>>>>>>> >>>>>>> "david.black@emc.com">>>>>> .c >>>>>>> o >>>>>>> m< >>>>>>>> mailto:david.black@emc.com>>, Bob >>>>>>>> Martin> >>>>>>>> Cc: >>>>>>>> >>>>>>> "mile@ietf.org">>>>>> et >>>>>>> f >>>>>>> .o >>>>>>>> rg>> >>>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>> >>>>>>>> My concern with CAPEC being mandatory is that it could >>>>>>>> discourage >>>>>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary >>>>>>> remains "too comprehensive" for many CSIRTs to employ during >>>>> incident >>>>>>> handling and reporting activity. >>>>>>>> >>>>>>>> IODEF by itself has been criticized by CSIRT operators for being >>>>>>>> more >>>>>>> heavyweight than necessary for day-to-day usage; making CAPEC a >>>>>>> mandatory aspect of "advanced IODEF" seems like it would be >>>>>>> adding ammunition to that argument, especially if the CSIRT is >>>>>>> having to fund implementation out of their own pocket. >>>>>>> Personally, I would >>>>> have >>>>>>> a hard time asking US-CERT's primary constituents to implement >>>>>>> IODEF >>>>>>> + CAPEC if they are already balking at the consultant and >>>>>>> + developer >>>>>>> resources required to implement RFC 5070 by itself. Also keep in >>>>> mind >>>>>>> that CAPEC references CybOX, so there's wheels within wheels now. >>>>>>>> >>>>>>>> I would prefer we take the path of least resistance (from my >>>>>> perspective) >>>>>>> and make CVE the MTI, if we have to pick one additional spec. >>>>>>>> CVE is well known, has years of familiarity built in, and I >>>>>>>> think it's >>>>>>> the simplest schema of the bunch. >>>>>>>> >>>>>>>> >>>>>>>> - Tom Millar, US-CERT >>>>>>>> >>>>>>>> thomas.millar@us-cert.gov >>>>>>>> BB: thomas.millar@dhs.gov / >>>>>>>> 202-631-1915 >>>>>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mile-bounces@ietf.org >>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>>>>> david.black@emc.com >>>>>>>> Sent: Tuesday, February 14, 2012 11:14 >>>>>>>> To: ramartin@mitre.org >>>>>>>> Cc: mile@ietf.org >>>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>> >>>>>>>> Hi Bob, >>>>>>>> >>>>>>>> I do appreciate the concern about implementing things that >>>>>>>> aren't going >>>>>>> to be used. OTOH, it may be useful to have a single simple MTI >>>>>>> spec for SCI that can be used to "smoke test" a deployment before >>>>>>> trying any >>>>>> serious >>>>>>> test data (and "simple" is important). >>>>>>>> >>>>>>>> In addition, a concern that I would have with an MTI SCI spec >>>>>>>> per class >>>>>>> is that if two SCI implementations don't have at least one class >>>>>>> in >>>>>> common, >>>>>>> they aren't going to interoperate, and that situation is unlikely >>>>>>> to be acceptable to the IESG (i.e., with an MTI SCI spec per >>>>>>> class, I suspect that there will also have to be an MTI class, >>>>>>> which results in an overall MTI SCI spec). >>>>>>>> >>>>>>>> It may also be useful to include a simple example of the MTI SCI >>>>>>>> spec >>>>>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI >>>>> spec >>>>>>> is CAPEC, as Youki suggested, the appendix could contain a CAPEC >>>>>>> XML document for testing purposes, including enumeration values >>>>>>> suitable for testing). >>>>>>>> >>>>>>>> What do you (and others) think about this? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> --David >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mile-bounces@ietf.org >>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. >>>>>>>> Sent: Tuesday, February 14, 2012 8:26 AM >>>>>>>> To: Brian Trammell >>>>>>>> Cc: mile@ietf.org >>>>>>>> Subject: Re: [mile] MTI SCI? >>>>>>>> Brian, >>>>>>>> You beat me to this point. Like you, I would be concerned about >>>>>>>> a MTI selection that ended up requiring someone to implement >>>>> something >>>>>>>> to meet the MTI but wasn't germane to anything else they >>>>>>>> intended >>>>> to >>>>>>> support. >>>>>>>> Bob >>>>>>>> On 2/14/12 4:19 AM, Brian Trammell wrote: >>>>>>>>> Hi, Sean, all, >>>>>>>>> >>>>>>>>> Looking over the spec, it's not clear to me that one MTI makes >>>>>>>>> sense here, given that mile-sci's >>>>>>>> purpose is to reference a set of external specifications by >>>>>>>> inclusion in an IODEF document, and that those external >>>>>>>> specifications represent >>>>>>> fundamentally different things. >>>>>>>>> >>>>>>>>> The specifications are split over their applicability to the >>>>>>>>> IODEF extension classes. I could >>>>>>>> envision an mile-sci implementation that was only interested a >>>>>>>> subset of these classes (perhaps even only one). If my >>>>>>>> implementation has an internal representation of Verification, >>>>>>>> but not of any of the other classes, and the MTI is an >>>>>>>> enumeration that is applicable to >>>>>>> Vulnerability... what do I do? >>>>>>>>> >>>>>>>>> What about selecting an MTI per class, instead? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Brian (as contributor) >>>>>>>>> >>>>>>>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: >>>>>>>>> >>>>>>>>>> Great - as long as we pick one as the MTI. Note that MTI is >>>>>>>>>> not >>>>>>> necessarily mandatory to use. >>>>>>>>>> >>>>>>>>>> spt >>>>>>>>>> >>>>>>>>>> On 2/13/12 7:11 PM, >>>>>>> kathleen.moriarty@emc.com wrote: >>>>>>>>>>> Thank you for raising the interoperability testing as we need >>>>>>>>>>> to plan for a bake-off that once >>>>>>>> these questions get answered and the draft is ready. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Kathleen >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mile-bounces@ietf.org >>>>>>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >>>>>>>>>>> Sent: Monday, February 13, 2012 6:57 PM >>>>>>>>>>> To: mile@ietf.org >>>>>>>>>>> Subject: [mile] MTI SCI? >>>>>>>>>>> >>>>>>>>>>> There's 17 listed SCI (Structured Cybersecurity Information) >>>>>>>>>>> specifications in draft-ietf-mile-sci. Which one is the MTI >>>>>>>>>>> (mandatory to implement) choice? In other words, how will >>>>>>>>>>> you get two interoperability implementations without picking one? >>>>>>>>>>> >>>>>>>>>>> spt >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mile mailing list >>>>>>>>>>> mile@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mile mailing list >>>>>>>>>> mile@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mile mailing list >>>>>>>>> mile@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>>> . >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>> _______________________________________________ >>>>>>>> mile mailing list >>>>>>>> mile@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mile mailing list >>>>>>> mile@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>>> >>>>> - >>>>> 03c >>>>>> >>>>> andidate_20120215.txt.pdf>__________________________________________ >>>>> __ >>>>>> ___ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > From trammell@tik.ee.ethz.ch Wed Feb 22 04:21:39 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8921F871D for ; Wed, 22 Feb 2012 04:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 h0Q1Zhpu-YiW for ; Wed, 22 Feb 2012 04:21:34 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9821F869C for ; Wed, 22 Feb 2012 04:21:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 63C3BD9314; Wed, 22 Feb 2012 13:21:21 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 43PvMA5-CF20; Wed, 22 Feb 2012 13:21:05 +0100 (MET) Received: from [10.156.84.164] (unknown [213.55.184.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 97C7FD9304; Wed, 22 Feb 2012 13:21:05 +0100 (MET) References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> <4F44D9A0.1010707@mitre.org> In-Reply-To: <4F44D9A0.1010707@mitre.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <724270F5-EDD8-4632-BCD3-939FA924BADF@tik.ee.ethz.ch> X-Mailer: iPhone Mail (9A405) From: Brian Trammell Date: Wed, 22 Feb 2012 13:21:00 +0100 To: "Martin, Robert A." Cc: "" Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 12:21:39 -0000 hi, Bob, sorry if the example wasn't clear: the point is, yes, it's a (real) WebKit v= uln, not a (hypothetical) openbsd kernel vuln, but a test for interop at the= content level without reference to the canonical enumeration would lead to s= yntactically accurate nonsense... regards, Brian Sent from my iPhone On 22.02.2012, at 13:03, "Martin, Robert A." wrote: > Brian, >=20 > I am confused. >=20 > Unlike the two texts you quoted I found the exact same text from that CVE a= t the CVE site and the NVD site. >=20 > Bob >=20 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2011-4692 >=20 > WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 and= earlier, does not prevent capture of data about the time required for image= loading, which makes it easier for remote attackers to determine whether an= image exists in the browser cache via crafted JavaScript code, as demonstra= ted by visipisi. >=20 > http://nvd.nist.gov/nvd.cfm?cvename=3DCVE-2011-4692 >=20 > WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 and= earlier, does not prevent capture of data about the time required for image= loading, which makes it easier for remote attackers to determine whether an= image exists in the browser cache via crafted JavaScript code, as demonstra= ted by visipisi. >=20 > On 2/22/12 4:34 AM, Brian Trammell wrote: >> Greetings, all, >>=20 >> Taking my chair hat off, putting my contributor hat on now: >>=20 >> I like Kathleen's suggestion, and would extend it: do we want to consider= explicitly considering the question from the standpoint of "reference" sepa= rately from "containment". For things like CVE, a CVE identifier is de facto= operationally assumed to be a stable reference to a static resource. (The s= tability of a CVE reference is probably _not_ such that it could be used as a= normative reference within the IETF; however, it is as far as I know still c= ommon practice to treat it as such in incident handling.) >>=20 >> Interoperability for a reference then is tested by the following two cond= itions: >>=20 >> 1. an IODEF + SCI producer can take its internal representation of an SCI= object and convert it to a reference in a standard representation which can= be dereferenced by the consumer, perhaps relying on a connection to an exte= rnal resource. >>=20 >> 2. an IODEF + SCI consumer can take a reference in a standard representat= ion from the IODEF document and deference it into its internal representatio= n of a substantially identical SCI object, perhaps relying on a connection t= o an external resource. >>=20 >> Considering the question from the content angle, interoperability looks a= bit more straightforward to test: >>=20 >> 1. an IODEF + SCI producer can take its internal representation of an SCI= object and convert it into an XML element embedded in an IODEF document. >>=20 >> 2. an IODEF + SCI consumer can convert an XML element embedded in an IODE= F Document and convert it into its internal representation of a substantiall= y identical SCI object. >>=20 >> This raises another issue, though. Let's say I send content about an inci= dent involving an exploit of CVE-2011-4692, a remote root vulnerability in O= penBSD exploitable by sending a specific sequence of unsolicited UDP packets= . The receiver parses this and now knows that one of my OpenBSD boxes got ro= oted by a magic packet attack exploiting CVE-2011-4692. So the implementatio= ns are interoperable. Right? >>=20 >> Well, no. According to http://web.nvd.nist.gov/view/vuln/detail?vulnId=3D= CVE-2011-4692, this is a WebKit browser cache information leak vulnerability= . So you can't sensibly define interoperability in terms of content without r= eference to the static resource. What do I do as a receiver when I get infor= mation in content that conflicts with information in the referenced resource= ? >>=20 >> I suspect this is the case with most if not all of the enumerations cover= ed by SCI. I don't have deep familiarity with all the enumerations: how many= of these are commonly exchanged as references, and how many as content? For= those which are generally exchanged by reference, it would seem to make sen= se to test "implementation" based on handling references, and not content. >>=20 >> Thoughts? >>=20 >> Brian (as contributor) >>=20 >> On Feb 22, 2012, at 12:47 AM, = wrote: >>=20 >>> A "smoke test" is one of the motivations for this MTI requirement - for t= hat, >>> validation of the received content (e.g., against an XML schema for XML c= ontent) >>> should be required, as one usually wants to know that the "smoke" made i= t >>> through ok (the "smoke" that arrived matches what was sent). >>>=20 >>> So, even if the content will only be used as "smoke test" evidence, and n= ot >>> otherwise interpreted, it's still a good idea to require format validati= on. >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] >>>> Sent: Tuesday, February 21, 2012 4:18 PM >>>> To: Black, David; mile@ietf.org >>>> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (= wasRe: MTI SCI?) >>>>=20 >>>> Should a recipient be required to validate a referenced schema even if t= hey don't intend to interpret >>>> the content? >>>>=20 >>>> - Tom Millar, US-CERT >>>>=20 >>>> thomas.millar@us-cert.gov >>>> BB: thomas.millar@dhs.gov / 202-631-1915 >>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>=20 >>>> -----Original Message----- >>>> From: david.black@emc.com [mailto:david.black@emc.com] >>>> Sent: Tuesday, February 21, 2012 12:49 >>>> To: mile@ietf.org; Millar, Thomas R >>>> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (= wasRe: MTI SCI?) >>>>=20 >>>> Hi Tom, >>>>=20 >>>> I believe I agree with you, although I'd like to add some precision on w= hat is meant by "parse". >>>>=20 >>>> I don't think it's sufficient to support the value in the SpecID field (= e.g., a CVE >>>> version) and accept an XML blob that is not a well-formed CVE XML docum= ent. >>>>=20 >>>> Hence, I think the minimum requirement is to validate the received SCI X= ML document against the >>>> appropriate XML schema and detect any errors. >>>>=20 >>>> Beyond that, Take's reference to RFC 5070 is a useful source of insight= , as I think it rules out most >>>> additional requirements. IODEF is a format, not a protocol, so: >>>>=20 >>>> A) Error reporting is specific to whatever transport protocol is= being used. >>>> For example, if RID is used, the rfc6046-bis draft speci= fies how to >>>> report errors, but there's no RFC 5070 requirement that I= ODEF use RID. >>>> Beyond error detection, it's not possible to specify a r= equired error >>>> reporting mechanism. >>>>=20 >>>> B) RFC 5070 has nothing to say about replies or responses to IOD= EF, so the >>>> same should be true of extensions like SCI. >>>>=20 >>>> C) I'm not sure I understand what Take had in mind by "how to un= derstand" in >>>> #2. I see no need to understand CVE semantics or meanin= g beyond the CVE >>>> syntax check obtained by validating the received documen= t against the >>>> CVE XML schema. >>>>=20 >>>>> I would recommend that we be very clear in regards to what "support" >>>>> or "minimally support" mean so that technical requirements handed down= >>>>> based on this draft do not bar achievement by operational implementers= and their engineering teams. >>>>=20 >>>> I agree and would suggest: >>>>=20 >>>> - The CVE SpecID value and related values (e.g., namespace) MUST= >>>> be supported (not cause errors if used). >>>> - Recipient MUST validate received CVE XML document against the C= VE >>>> XML schema to detect invalid CVE documents. >>>>=20 >>>> I assume that this is all about CVE 1.0. >>>>=20 >>>> Does all of this make sense? >>>>=20 >>>> Thanks, >>>> --David >>>> ---------------------------------------------------- >>>> David L. Black, Distinguished Engineer >>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>> ---------------------------------------------------- >>>>=20 >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Thomas.Millar@us-cert.gov >>>>> Sent: Tuesday, February 21, 2012 12:00 PM >>>>> To: ariestake@googlemail.com; Moriarty, Kathleen; >>>>> david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >>>>> takeshi_takahashi@nict.go.jp >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI >>>>> (was Re: MTI SCI?) >>>>>=20 >>>>> Take, >>>>>=20 >>>>> I think you've done a very good job of explaining the two different >>>>> interpretations around this call for consensus. >>>>>=20 >>>>> My interpretation of MTI was closer to #2 - that to support this >>>>> draft, an implementer would have to support not only recognition of >>>>> the namespace in the appropriate IODEF parent class context, but also >>>>> be able to parse the content of the referenced namespace. Hence my pre= ference for a relatively >>>> simple and familiar spec as the MTI. >>>>>=20 >>>>> If we can concur that we all really mean the interpretation you >>>>> describe under #1, then I'm okay with having an MTI for each class. >>>>> What that says to me is that each implementer would need to conform to= >>>>> the SCI draft's class placement of each namespace, but not necessarily= >>>>> have to be able to interpret the contents of said namespace(s). So all= >>>>> I have to do, minimally, is recognize the class under which any of the= referenced namespaces exist; >>>> I don't have to have any means to parse or handle that class content ot= her than bucket it and move on >>>> to the next. Is that right? >>>>>=20 >>>>> I would recommend that we be very clear in regards to what "support" >>>>> or "minimally support" mean so that technical requirements handed down= >>>>> based on this draft do not bar achievement by operational implementers= and their engineering teams. >>>>>=20 >>>>> Thanks again, >>>>>=20 >>>>> - Tom Millar, US-CERT >>>>>=20 >>>>> thomas.millar@us-cert.gov >>>>> BB: thomas.millar@dhs.gov / 202-631-1915 >>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>>=20 >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>> Of Takeshi Takahashi >>>>> Sent: Monday, February 20, 2012 20:40 >>>>> To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; >>>>> trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI >>>>> (wasRe: MTI SCI?) >>>>>=20 >>>>> Hello all, >>>>>=20 >>>>> Thank you for your kind comments, which are really useful for me. >>>>> On the other hand, I have some difficulties to understand what people s= pecifically mean by "support" >>>>> or "mandatory". >>>>> I would appreciate if you could kindly give me some comments on below.= >>>>>=20 >>>>> Below are my views on the MTI issues. >>>>>=20 >>>>> 1. All the specification namespaces listed in the table MUST be >>>>> "supported" as values for the SpecID field. >>>>>=20 >>>>> These namespaces are the allowed ENUM values. >>>>> So, in a way, all the specification listed in the table are supported.= >>>>> (implementations must allow these namespaces of all the specifications= >>>>> listed in the table as values for SpecID field) Since all the >>>>> specification listed in the table are supported, we need to have >>>>> expert review before registration (as we discussed in Quebec City) >>>>>=20 >>>>> In this way, receivers can correctly understand the data. >>>>> That will give us the same level of interoperability as the RFC 5070 >>>>> (IODEF) does between sender and receiver, I think. >>>>>=20 >>>>>=20 >>>>> 2. Implementers have freedom to define how to parse, how to underst= and, >>>>> and how to respond the IODEF extension message >>>>>=20 >>>>> I might be wrong, but I do not think we would like to define how to >>>>> parse the IODEF extension message at the receiver side. >>>>> And I do not think we would like to define how to parse, for instance,= >>>>> CAPEC data, at the receiver side. >>>>> I think the SCI draft is a container that conveys these structured >>>>> information, and it can see such information as a blackbox with a tag (= namespace information). >>>>>=20 >>>>> If above understanding is correct, I have some difficulty to >>>>> understand the meaning of "mandatory to support CVE". >>>>> As described in issue 1 above, if CVE or CAPEC data is attached, the >>>>> implementation needs to recognize that the data is in CVE/CAPEC format= , and that is the requirement >>>> for the implementation. >>>>> What else do we want to mandate here, specifically? >>>>> Do we need to manipulate the embedded xml data itself? I rather prefer= >>>>> to handle the data as a blackbox. >>>>>=20 >>>>> I appreciate your kind comments. >>>>> Regarding the other point Dave kindly pointed out, let me have another= >>>>> thread. (sorry I need to get on board now...) >>>>>=20 >>>>> Thank you. >>>>>=20 >>>>> Take >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] >>>>> Sent: Monday, February 20, 2012 8:08 PM >>>>> To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; >>>>> takeshi_takahashi@nict.go.jp >>>>> Cc: mile@ietf.org >>>>> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI >>>>> (was >>>>> Re: MTI SCI?) >>>>>=20 >>>>> Thank you, Dave. >>>>>=20 >>>>> Dave raises a few very important points as we consider MTI for SCI. >>>>> We will need to resolve these issues if CVE is to be the (or an) MTI s= pecification for the SCI >>>> draft. >>>>>=20 >>>>> If CVE is mandatory to implement, what guidance would be followed on >>>>> how to use the model or will MTI only mean that the document can be re= ceived and >>>>> parsed? The CVE website is listed as the specification URI, but from= >>>>> Dave's message, the specification URI does not exist to provide the >>>>> guidance (I get to broken link pages for both - the existing and sugge= sted replacement link). >>>>>=20 >>>>> This is the closest I could find and may be the answer for guidance: >>>>> http://cve.mitre.org/compatible/requirements.html >>>>>=20 >>>>> It looks like the reference to the target namespace needs to be fixed a= s well. >>>>>=20 >>>>> Thank you, >>>>> Kathleen >>>>> ________________________________________ >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Walte= rmire, David A. >>>>> [david.waltermire@nist.gov] >>>>> Sent: Thursday, February 16, 2012 5:26 PM >>>>> To: Brian Trammell; Takeshi Takahashi >>>>> Cc: mile@ietf.org >>>>> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI >>>>> (was >>>>> Re: MTI SCI?) >>>>>=20 >>>>> I have not been following this thread as closely as I probably should.= >>>>> Relative to MTI, is the question what schema should be MTI for the >>>>> vulerability class? In general I think we should have one or more MTI= for each class. >>>>>=20 >>>>> Relative to CVE specifically, are we talking about the schema currentl= y located at: >>>>> http://cve.mitre.org/schema/cve/cve_1.0.xsd? >>>>>=20 >>>>> This seems to match the namespace defined in section 4.1.7 of mile-sci= -02. >>>>> Looking at the implementation of this schema, it looks like the >>>>> targetNamespace is incorrectly assigned to >>>>> "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it shou= ld be >>>> "http://cve.mitre.org/cve/downloads/1.0". This will likely need to be f= ixed. >>>>>=20 >>>>> Also, the specification URI points to the CVE website, which is not >>>>> really a specification. It's not clear where to find guidance on how >>>>> to properly use the model indicated by the namespace. Without having >>>>> clear guidance on its use I don't see how we can make it MTI, even if >>>>> it is considered a de facto approach. It might make sense to produce a= specification for the model >>>> before making it MTI for the vulnerability class. >>>>>=20 >>>>> Sincerely, >>>>> David Waltermire >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>>>>> Of Brian Trammell >>>>>> Sent: Wednesday, February 15, 2012 5:28 AM >>>>>> To: Takeshi Takahashi >>>>>> Cc: mile@ietf.org >>>>>> Subject: [mile] Discussion / consensus call on CVE as MTI for SCI >>>>>> (was >>>>>> Re: MTI SCI?) >>>>>>=20 >>>>>> Hi, Take, all, >>>>>>=20 >>>>>> Thank you for this edit/clarification. >>>>>>=20 >>>>>> On the first point, it does seem the discussion on the list >>>>>> converged rather quickly to CVE as MTI. However, as this is a rather >>>>>> important point, I'd like to make sure we di From takeshi_takahashi@nict.go.jp Wed Feb 22 10:06:06 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0E21F882F for ; Wed, 22 Feb 2012 10:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 rTFUdub1jS2H for ; Wed, 22 Feb 2012 10:06:02 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3DD21F86B4 for ; Wed, 22 Feb 2012 10:05:59 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q1MI5qc8025339; Thu, 23 Feb 2012 03:05:52 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q1MI5qF9024273; Thu, 23 Feb 2012 03:05:52 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id q1MI5mb6024252; Thu, 23 Feb 2012 03:05:49 +0900 (JST) From: "Takeshi Takahashi" To: , , References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> Date: Thu, 23 Feb 2012 03:05:36 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtQCXe3+vgHTO+ibAQ/JkYkBN9mkQwEgvGD1lSQq87A= Content-Language: ja Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:06:06 -0000 I'm generally in favor of the kind opinions from Tom and David. IMHO, the sentence David kindly provided could be changed as below: In order to be compliant with SCI draft, the implementations need to suffice below: 1. The CVE SpecID value and related values (e.g., namespace) MUST be supported (not cause errors if used). 2. Recipient MUST "be capable of" validating received CVE 1.0 XML document against the CVE 1.0 XML schema to detect invalid CVE documents. I think the receiver needs to be capable of validating received CVE XML for the smoke test purpose, but I am not sure whether we should mandate the validation process to the receiver. When operation processes are automated, validation process could be implemented elsewhere (for instance, data generation unit could do the validation). So, I think the SCI draft could mandates the capability, instead of the process. Does it make sense? Thank you. Take > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Wednesday, February 22, 2012 8:47 AM > To: Thomas.Millar@us-cert.gov; mile@ietf.org > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > (was Re: MTI SCI?) > > A "smoke test" is one of the motivations for this MTI requirement - for > that, validation of the received content (e.g., against an XML schema > for XML content) should be required, as one usually wants to know that > the "smoke" made it through ok (the "smoke" that arrived matches what > was sent). > > So, even if the content will only be used as "smoke test" evidence, and > not otherwise interpreted, it's still a good idea to require format > validation. > > Thanks, > --David > > > -----Original Message----- > > From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] > > Sent: Tuesday, February 21, 2012 4:18 PM > > To: Black, David; mile@ietf.org > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > > (wasRe: MTI SCI?) > > > > Should a recipient be required to validate a referenced schema even > if > > they don't intend to interpret the content? > > > > - Tom Millar, US-CERT > > > > thomas.millar@us-cert.gov > > BB: thomas.millar@dhs.gov / 202-631-1915 > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > -----Original Message----- > > From: david.black@emc.com [mailto:david.black@emc.com] > > Sent: Tuesday, February 21, 2012 12:49 > > To: mile@ietf.org; Millar, Thomas R > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > > (wasRe: MTI SCI?) > > > > Hi Tom, > > > > I believe I agree with you, although I'd like to add some precision > on what is meant by "parse". > > > > I don't think it's sufficient to support the value in the SpecID field > > (e.g., a CVE > > version) and accept an XML blob that is not a well-formed CVE XML > document. > > > > Hence, I think the minimum requirement is to validate the received SCI > > XML document against the appropriate XML schema and detect any errors. > > > > Beyond that, Take's reference to RFC 5070 is a useful source of > > insight, as I think it rules out most additional requirements. IODEF > is a format, not a protocol, so: > > > > A) Error reporting is specific to whatever transport protocol > is being used. > > For example, if RID is used, the rfc6046-bis draft > specifies how to > > report errors, but there's no RFC 5070 requirement that > IODEF use RID. > > Beyond error detection, it's not possible to specify > a required error > > reporting mechanism. > > > > B) RFC 5070 has nothing to say about replies or responses to > IODEF, so the > > same should be true of extensions like SCI. > > > > C) I'm not sure I understand what Take had in mind by "how to > understand" in > > #2. I see no need to understand CVE semantics or > meaning beyond the CVE > > syntax check obtained by validating the received > document against the > > CVE XML schema. > > > > > I would recommend that we be very clear in regards to what "support" > > > or "minimally support" mean so that technical requirements handed > > > down based on this draft do not bar achievement by operational > implementers and their engineering teams. > > > > I agree and would suggest: > > > > - The CVE SpecID value and related values (e.g., namespace) > MUST > > be supported (not cause errors if used). > > - Recipient MUST validate received CVE XML document against > the CVE > > XML schema to detect invalid CVE documents. > > > > I assume that this is all about CVE 1.0. > > > > Does all of this make sense? > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer EMC Corporation, 176 South St., > > Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > david.black@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > Behalf > > > Of Thomas.Millar@us-cert.gov > > > Sent: Tuesday, February 21, 2012 12:00 PM > > > To: ariestake@googlemail.com; Moriarty, Kathleen; > > > david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > > takeshi_takahashi@nict.go.jp > > > Cc: mile@ietf.org > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > SCI (was Re: MTI SCI?) > > > > > > Take, > > > > > > I think you've done a very good job of explaining the two different > > > interpretations around this call for consensus. > > > > > > My interpretation of MTI was closer to #2 - that to support this > > > draft, an implementer would have to support not only recognition of > > > the namespace in the appropriate IODEF parent class context, but > > > also be able to parse the content of the referenced namespace. Hence > > > my preference for a relatively > > simple and familiar spec as the MTI. > > > > > > If we can concur that we all really mean the interpretation you > > > describe under #1, then I'm okay with having an MTI for each class. > > > What that says to me is that each implementer would need to conform > > > to the SCI draft's class placement of each namespace, but not > > > necessarily have to be able to interpret the contents of said > > > namespace(s). So all I have to do, minimally, is recognize the class > > > under which any of the referenced namespaces exist; > > I don't have to have any means to parse or handle that class content > > other than bucket it and move on to the next. Is that right? > > > > > > I would recommend that we be very clear in regards to what "support" > > > or "minimally support" mean so that technical requirements handed > > > down based on this draft do not bar achievement by operational > implementers and their engineering teams. > > > > > > Thanks again, > > > > > > - Tom Millar, US-CERT > > > > > > thomas.millar@us-cert.gov > > > BB: thomas.millar@dhs.gov / 202-631-1915 > > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > Behalf > > > Of Takeshi Takahashi > > > Sent: Monday, February 20, 2012 20:40 > > > To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; > > > trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > > > Cc: mile@ietf.org > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > SCI > > > (wasRe: MTI SCI?) > > > > > > Hello all, > > > > > > Thank you for your kind comments, which are really useful for me. > > > On the other hand, I have some difficulties to understand what people > specifically mean by "support" > > > or "mandatory". > > > I would appreciate if you could kindly give me some comments on below. > > > > > > Below are my views on the MTI issues. > > > > > > 1. All the specification namespaces listed in the table MUST be > > > "supported" as values for the SpecID field. > > > > > > These namespaces are the allowed ENUM values. > > > So, in a way, all the specification listed in the table are supported. > > > (implementations must allow these namespaces of all the > > > specifications listed in the table as values for SpecID field) Since > > > all the specification listed in the table are supported, we need to > > > have expert review before registration (as we discussed in Quebec > > > City) > > > > > > In this way, receivers can correctly understand the data. > > > That will give us the same level of interoperability as the RFC 5070 > > > (IODEF) does between sender and receiver, I think. > > > > > > > > > 2. Implementers have freedom to define how to parse, how to > understand, > > > and how to respond the IODEF extension message > > > > > > I might be wrong, but I do not think we would like to define how to > > > parse the IODEF extension message at the receiver side. > > > And I do not think we would like to define how to parse, for > > > instance, CAPEC data, at the receiver side. > > > I think the SCI draft is a container that conveys these structured > > > information, and it can see such information as a blackbox with a > tag (namespace information). > > > > > > If above understanding is correct, I have some difficulty to > > > understand the meaning of "mandatory to support CVE". > > > As described in issue 1 above, if CVE or CAPEC data is attached, the > > > implementation needs to recognize that the data is in CVE/CAPEC > > > format, and that is the requirement > > for the implementation. > > > What else do we want to mandate here, specifically? > > > Do we need to manipulate the embedded xml data itself? I rather > > > prefer to handle the data as a blackbox. > > > > > > I appreciate your kind comments. > > > Regarding the other point Dave kindly pointed out, let me have > > > another thread. (sorry I need to get on board now...) > > > > > > Thank you. > > > > > > Take > > > > > > > > > > > > > > > -----Original Message----- > > > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > > > Sent: Monday, February 20, 2012 8:08 PM > > > To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > > takeshi_takahashi@nict.go.jp > > > Cc: mile@ietf.org > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for > > > SCI (was > > > Re: MTI SCI?) > > > > > > Thank you, Dave. > > > > > > Dave raises a few very important points as we consider MTI for SCI. > > > We will need to resolve these issues if CVE is to be the (or an) MTI > > > specification for the SCI > > draft. > > > > > > If CVE is mandatory to implement, what guidance would be followed > on > > > how to use the model or will MTI only mean that the document can be > received and > > > parsed? The CVE website is listed as the specification URI, but > from > > > Dave's message, the specification URI does not exist to provide the > > > guidance (I get to broken link pages for both - the existing and > suggested replacement link). > > > > > > This is the closest I could find and may be the answer for guidance: > > > http://cve.mitre.org/compatible/requirements.html > > > > > > It looks like the reference to the target namespace needs to be fixed > as well. > > > > > > Thank you, > > > Kathleen > > > ________________________________________ > > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > Waltermire, David A. > > > [david.waltermire@nist.gov] > > > Sent: Thursday, February 16, 2012 5:26 PM > > > To: Brian Trammell; Takeshi Takahashi > > > Cc: mile@ietf.org > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > SCI (was > > > Re: MTI SCI?) > > > > > > I have not been following this thread as closely as I probably should. > > > Relative to MTI, is the question what schema should be MTI for the > > > vulerability class? In general I think we should have one or more > MTI for each class. > > > > > > Relative to CVE specifically, are we talking about the schema currently > located at: > > > http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > > > > > This seems to match the namespace defined in section 4.1.7 of > mile-sci-02. > > > Looking at the implementation of this schema, it looks like the > > > targetNamespace is incorrectly assigned to > > > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it > > > should be > > "http://cve.mitre.org/cve/downloads/1.0". This will likely need to > be fixed. > > > > > > Also, the specification URI points to the CVE website, which is not > > > really a specification. It's not clear where to find guidance on > > > how to properly use the model indicated by the namespace. Without > > > having clear guidance on its use I don't see how we can make it MTI, > > > even if it is considered a de facto approach. It might make sense > > > to produce a specification for the model > > before making it MTI for the vulnerability class. > > > > > > Sincerely, > > > David Waltermire > > > > > > > -----Original Message----- > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > Behalf Of Brian Trammell > > > > Sent: Wednesday, February 15, 2012 5:28 AM > > > > To: Takeshi Takahashi > > > > Cc: mile@ietf.org > > > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI > > > > (was > > > > Re: MTI SCI?) > > > > > > > > Hi, Take, all, > > > > > > > > Thank you for this edit/clarification. > > > > > > > > On the first point, it does seem the discussion on the list > > > > converged rather quickly to CVE as MTI. However, as this is a > > > > rather important point, I'd like to make sure we didn't miss anything. > > > > > > > > So, I'd like to call for consensus on the list. Does the working > > > > group agree on the following two points? > > > > > > > > 1. mile-sci requires one Mandatory to Implement schema in order > to > > > > ensure interoperability. > > > > > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of > > > > mile- sci-02. > > > > > > > > Please note if you agree; if you disagree, please explain why not. > > > > > > > > Best regards, > > > > > > > > Brian (as chair) > > > > > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > > > > > Hello all, > > > > > > > > > > Following the discussion, I would like to add a couple of > > > > > sentences > > > > to > > > > > clarify the MTI issues. > > > > > (Thank you very much for those of you who kindly provided useful > > > > > discussion.) > > > > > I've attached the working version of the draft. I hope it helps > > > > > to clarify the changes. > > > > > > > > > > (added sentences at the end of section 4.1) > > > > > > > > > > The SpecID attributes of extended classes (Section 4.3) must > allow > > > > > the values of the specifications' namespace fields, but > otherwise, > > > > > implementations are not required to support all the above > > > > > specifications. Implementations may choose which > specifications to > > > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > > > supported. In case an implementation received a data it does > not > > > > > support, it may expand its functionality by looking up the > > > > > IANA > > > > table or > > > > > notify the sender of its inability to parse the data by using > any > > > > > means defined outside the scope of this specification. > > > > > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to > > > > > each class, which enables to embed data following private schema. > > > > > For instance, one security operation center (SOC) may wish to > > > > exchange > > > > > a vulnerability data that is formatted in its own private > > > > > schema, and that is not formatted in CVE. > > > > > In this case, the SOC may put the data's schema ID inside > > > > > ext-SpecID and then embed the data. > > > > > It could also be used to exchange data using beta version of > > > > specifications. > > > > > > > > > > The class could be seen as below. > > > > > > > > > > +------------------------+ > > > > > | AttackPattern | > > > > > +------------------------+ > > > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > > > +------------------------+ > > > > > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > > > specifying the format of the RawData element. The value > > > > > should > > > > be > > > > > chosen from the namespaces [XMLNames] listed in Section 4.1 > or > > > > > "private". Note that the lists in Section 4.1 will be > developed > > > > > further by IANA. The value "private" is prepared for conveying > > > > > RawData based on a format that is not listed in the > > > > > table. This is usually used for conveying data formatted > > > > > according to an organization's private schema. When the > value > > > > > "private" is used, ext-SpecID element needs to be used. > > > > > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > > > specification > > > > > specifying the format of the RawData element. When this > element > > > > > is used, the value of SpecID element must be "private." > > > > > > > > > > I hope above changes don't cause any complication here. > > > > > > > > > > Sincerely, > > > > > Take > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > >> Behalf Of Martin, Robert A. > > > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > > > >> To: Kent_Landfield@McAfee.com > > > > >> Cc: mile@ietf.org > > > > >> Subject: Re: [mile] MTI SCI? > > > > >> > > > > >> At the risk of contradicting myself - but then again I have now > > > > >> read the other replies to this issue - I agree that having one > > > > >> area be > > > > the > > > > >> smoke test makes sense and I also agree that something simple > > > > >> and commonly used already - like CVE - is the best candidate > > > > >> for what we > > > > need. > > > > >> > > > > >> Bob > > > > >> > > > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > > > >>> CVE is widely used and understood by all in the the security > > > > community. > > > > >> I agree with Tom that CVE is the path of least resistance but > > > > >> may be the most useful for basic interoperability. > > > > >>> > > > > >>> Kent Landfield > > > > >>> Director Content Strategy, Architecture and Standards > > > > >>> > > > > >>> McAfee | An Intel Company > > > > >>> 5000 Headquarters Dr. > > > > >>> Plano, Texas 75024 > > > > >>> > > > > >>> Direct: +1.972.963.7096 > > > > >>> Mobile: +1.817.637.8026 > > > > >>> Web: www.mcafee.com > > > > >>> > > > > >>> From: > > > > >>> > > > > >> > "Thomas.Millar@us-cert.gov" > > > >> ho > > > > >> ma > > > > >> s > > > > >> .M > > > > >>> illar@us-cert.gov> > > > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > > > >>> To: > > > > >>> > > > > >> > "david.black@emc.com" > > > >> mc > > > > >> .c > > > > >> o > > > > >> m< > > > > >>> mailto:david.black@emc.com>>, Bob > > > > >>> Martin> > > > > >>> Cc: > > > > >>> > > > > >> > "mile@ietf.org" > > > >> @i > > > > >> et > > > > >> f > > > > >> .o > > > > >>> rg>> > > > > >>> Subject: Re: [mile] MTI SCI? > > > > >>> > > > > >>> My concern with CAPEC being mandatory is that it could > > > > >>> discourage > > > > >> effective operational uptake of IODEF-SCI as the CAPEC > > > > >> vocabulary remains "too comprehensive" for many CSIRTs to > > > > >> employ during > > > > incident > > > > >> handling and reporting activity. > > > > >>> > > > > >>> IODEF by itself has been criticized by CSIRT operators for > > > > >>> being more > > > > >> heavyweight than necessary for day-to-day usage; making CAPEC > a > > > > >> mandatory aspect of "advanced IODEF" seems like it would be > > > > >> adding ammunition to that argument, especially if the CSIRT is > > > > >> having to fund implementation out of their own pocket. > > > > >> Personally, I would > > > > have > > > > >> a hard time asking US-CERT's primary constituents to implement > > > > >> IODEF > > > > >> + CAPEC if they are already balking at the consultant and > > > > >> + developer > > > > >> resources required to implement RFC 5070 by itself. Also keep > > > > >> in > > > > mind > > > > >> that CAPEC references CybOX, so there's wheels within wheels > now. > > > > >>> > > > > >>> I would prefer we take the path of least resistance (from my > > > > > perspective) > > > > >> and make CVE the MTI, if we have to pick one additional spec. > > > > >>> CVE is well known, has years of familiarity built in, and I > > > > >>> think it's > > > > >> the simplest schema of the bunch. > > > > >>> > > > > >>> > > > > >>> - Tom Millar, US-CERT > > > > >>> > > > > >>> thomas.millar@us-cert.gov > > > > >>> BB: thomas.millar@dhs.gov / > > > > >>> 202-631-1915 > > > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > > > >>> > > > > >>> -----Original Message----- > > > > >>> From: mile-bounces@ietf.org > > > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > > > >>> david.black@emc.com > > > > >>> Sent: Tuesday, February 14, 2012 11:14 > > > > >>> To: ramartin@mitre.org > > > > >>> Cc: mile@ietf.org > > > > >>> Subject: Re: [mile] MTI SCI? > > > > >>> > > > > >>> Hi Bob, > > > > >>> > > > > >>> I do appreciate the concern about implementing things that > > > > >>> aren't going > > > > >> to be used. OTOH, it may be useful to have a single simple MTI > > > > >> spec for SCI that can be used to "smoke test" a deployment > > > > >> before trying any > > > > > serious > > > > >> test data (and "simple" is important). > > > > >>> > > > > >>> In addition, a concern that I would have with an MTI SCI spec > > > > >>> per class > > > > >> is that if two SCI implementations don't have at least one > > > > >> class in > > > > > common, > > > > >> they aren't going to interoperate, and that situation is > > > > >> unlikely to be acceptable to the IESG (i.e., with an MTI SCI > > > > >> spec per class, I suspect that there will also have to be an > > > > >> MTI class, which results in an overall MTI SCI spec). > > > > >>> > > > > >>> It may also be useful to include a simple example of the MTI > > > > >>> SCI spec > > > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI > > > > >> SCI > > > > spec > > > > >> is CAPEC, as Youki suggested, the appendix could contain a > > > > >> CAPEC XML document for testing purposes, including enumeration > > > > >> values suitable for testing). > > > > >>> > > > > >>> What do you (and others) think about this? > > > > >>> > > > > >>> Thanks, > > > > >>> --David > > > > >>> > > > > >>> -----Original Message----- > > > > >>> From: mile-bounces@ietf.org > > > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > > > >>> To: Brian Trammell > > > > >>> Cc: mile@ietf.org > > > > >>> Subject: Re: [mile] MTI SCI? > > > > >>> Brian, > > > > >>> You beat me to this point. Like you, I would be concerned > > > > >>> about a MTI selection that ended up requiring someone to > > > > >>> implement > > > > something > > > > >>> to meet the MTI but wasn't germane to anything else they > > > > >>> intended > > > > to > > > > >> support. > > > > >>> Bob > > > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > > > >>>> Hi, Sean, all, > > > > >>>> > > > > >>>> Looking over the spec, it's not clear to me that one MTI > > > > >>>> makes sense here, given that mile-sci's > > > > >>> purpose is to reference a set of external specifications by > > > > >>> inclusion in an IODEF document, and that those external > > > > >>> specifications represent > > > > >> fundamentally different things. > > > > >>>> > > > > >>>> The specifications are split over their applicability to the > > > > >>>> IODEF extension classes. I could > > > > >>> envision an mile-sci implementation that was only interested > a > > > > >>> subset of these classes (perhaps even only one). If my > > > > >>> implementation has an internal representation of Verification, > > > > >>> but not of any of the other classes, and the MTI is an > > > > >>> enumeration that is applicable to > > > > >> Vulnerability... what do I do? > > > > >>>> > > > > >>>> What about selecting an MTI per class, instead? > > > > >>>> > > > > >>>> Best regards, > > > > >>>> > > > > >>>> Brian (as contributor) > > > > >>>> > > > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > > >>>> > > > > >>>>> Great - as long as we pick one as the MTI. Note that MTI > is > > > > >>>>> not > > > > >> necessarily mandatory to use. > > > > >>>>> > > > > >>>>> spt > > > > >>>>> > > > > >>>>> On 2/13/12 7:11 PM, > > > > >> kathleen.moriarty@emc.com > wrote: > > > > >>>>>> Thank you for raising the interoperability testing as we > > > > >>>>>> need to plan for a bake-off that once > > > > >>> these questions get answered and the draft is ready. > > > > >>>>>> > > > > >>>>>> Thanks, > > > > >>>>>> Kathleen > > > > >>>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: mile-bounces@ietf.org > > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > > > >>>>>> To: mile@ietf.org > > > > >>>>>> Subject: [mile] MTI SCI? > > > > >>>>>> > > > > >>>>>> There's 17 listed SCI (Structured Cybersecurity > > > > >>>>>> Information) specifications in draft-ietf-mile-sci. Which > > > > >>>>>> one is the MTI (mandatory to implement) choice? In other > > > > >>>>>> words, how will you get two interoperability implementations > without picking one? > > > > >>>>>> > > > > >>>>>> spt > > > > >>>>>> _______________________________________________ > > > > >>>>>> mile mailing list > > > > >>>>>> mile@ietf.org > > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > > >>>>>> > > > > >>>>>> > > > > >>>>> _______________________________________________ > > > > >>>>> mile mailing list > > > > >>>>> mile@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> mile mailing list > > > > >>>> mile@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/mile > > > > >>>> . > > > > >>>> > > > > >>> _______________________________________________ > > > > >>> mile mailing list > > > > >>> mile@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > >>> > > > > >>> _______________________________________________ > > > > >>> mile mailing list > > > > >>> mile@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > >>> _______________________________________________ > > > > >>> mile mailing list > > > > >>> mile@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > >>> > > > > >>> > > > > >> _______________________________________________ > > > > >> mile mailing list > > > > >> mile@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > ci > > > > > - > > > > 03c > > > > > > > > > > andidate_20120215.txt.pdf>________________________________________ > > > > __ > > > > __ > > > > > ___ > > > > > mile mailing list > > > > > mile@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > _______________________________________________ > > > > mile mailing list > > > > mile@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mile > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > From takeshi_takahashi@nict.go.jp Wed Feb 22 10:06:07 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097A521F8831 for ; Wed, 22 Feb 2012 10:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_JP=1.244, 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 0PLGkqLAdOw9 for ; Wed, 22 Feb 2012 10:06:02 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A321F8798 for ; Wed, 22 Feb 2012 10:05:59 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q1MI5uPv025345; Thu, 23 Feb 2012 03:05:56 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q1MI5uHt024284; Thu, 23 Feb 2012 03:05:56 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id q1MI5mb7024252; Thu, 23 Feb 2012 03:05:52 +0900 (JST) From: "Takeshi Takahashi" To: "'Jeff Reed'" References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> In-Reply-To: Date: Thu, 23 Feb 2012 03:05:36 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_EDBD_01CCF1D8.06AC8020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakB887HTpV/9JEA Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:06:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_EDBD_01CCF1D8.06AC8020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jeff, Thank you for your kind correction. I appreciate feedbacks. Kind Regards, Take From: Jeff Reed [mailto:jeff360@gmail.com] Sent: Tuesday, February 21, 2012 11:27 AM To: Takeshi Takahashi Cc: mile@ietf.org Subject: Re: [mile] MTI SCI? Take, Should your suggested text: Implementations may choose which specifications to support, though CVE 1.0 (Section 4.1.7) needs to be minimally supported. ...be changes to: Implementations may choose which specifications to support, though CVE 1.0 (Section 4.1.7) MUST be minimally supported. ...in the context of this discussion? Kind regards, Jeff Reed On Wed, Feb 15, 2012 at 1:15 AM, Takeshi Takahashi wrote: Hello all, Following the discussion, I would like to add a couple of sentences to clarify the MTI issues. (Thank you very much for those of you who kindly provided useful discussion.) I've attached the working version of the draft. I hope it helps to clarify the changes. (added sentences at the end of section 4.1) The SpecID attributes of extended classes (Section 4.3) must allow the values of the specifications' namespace fields, but otherwise, implementations are not required to support all the above specifications. Implementations may choose which specifications to support, though CVE 1.0 (Section 4.1.7) needs to be minimally supported. In case an implementation received a data it does not support, it may expand its functionality by looking up the IANA table or notify the sender of its inability to parse the data by using any means defined outside the scope of this specification. On the other hand, I would like to add "STRING ext-SpecID" to each class, which enables to embed data following private schema. For instance, one security operation center (SOC) may wish to exchange a vulnerability data that is formatted in its own private schema, and that is not formatted in CVE. In this case, the SOC may put the data's schema ID inside ext-SpecID and then embed the data. It could also be used to exchange data using beta version of specifications. The class could be seen as below. +------------------------+ | AttackPattern | +------------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING AttackPatternID |<>--(0..*)-[ Platform ] +------------------------+ SpecID: REQUIRED. ENUM. The identifier of the specification specifying the format of the RawData element. The value should be chosen from the namespaces [XMLNames] listed in Section 4.1 or "private". Note that the lists in Section 4.1 will be developed further by IANA. The value "private" is prepared for conveying RawData based on a format that is not listed in the table. This is usually used for conveying data formatted according to an organization's private schema. When the value "private" is used, ext-SpecID element needs to be used. ext-SpecID: OPTIONAL. STRING. The identifier of the specification specifying the format of the RawData element. When this element is used, the value of SpecID element must be "private." I hope above changes don't cause any complication here. Sincerely, Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Martin, Robert A. > Sent: Wednesday, February 15, 2012 1:50 AM > To: Kent_Landfield@McAfee.com > Cc: mile@ietf.org > Subject: Re: [mile] MTI SCI? > > At the risk of contradicting myself - but then again I have now read the > other replies to this issue - I agree that having one area be the smoke > test makes sense and I also agree that something simple and commonly used > already - like CVE - is the best candidate for what we need. > > Bob > > On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > CVE is widely used and understood by all in the the security community. > I agree with Tom that CVE is the path of least resistance but may be the > most useful for basic interoperability. > > > > Kent Landfield > > Director Content Strategy, Architecture and Standards > > > > McAfee | An Intel Company > > 5000 Headquarters Dr. > > Plano, Texas 75024 > > > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > Web: www.mcafee.com > > > > From: > > > "Thomas.Millar@us-cert.gov" .M > > illar@us-cert.gov> > > Date: Tue, 14 Feb 2012 10:36:57 -0600 > > To: > > > "david.black@emc.com" m< > > mailto:david.black@emc.com>>, Bob > > Martin> > > Cc: > > > "mile@ietf.org" .o > > rg>> > > Subject: Re: [mile] MTI SCI? > > > > My concern with CAPEC being mandatory is that it could discourage > effective operational uptake of IODEF-SCI as the CAPEC vocabulary remains > "too comprehensive" for many CSIRTs to employ during incident handling > and reporting activity. > > > > IODEF by itself has been criticized by CSIRT operators for being more > heavyweight than necessary for day-to-day usage; making CAPEC a mandatory > aspect of "advanced IODEF" seems like it would be adding ammunition to > that argument, especially if the CSIRT is having to fund implementation > out of their own pocket. Personally, I would have a hard time asking > US-CERT's primary constituents to implement IODEF + CAPEC if they are > already balking at the consultant and developer resources required to > implement RFC 5070 by itself. Also keep in mind that CAPEC references > CybOX, so there's wheels within wheels now. > > > > I would prefer we take the path of least resistance (from my perspective) > and make CVE the MTI, if we have to pick one additional spec. > > CVE is well known, has years of familiarity built in, and I think it's > the simplest schema of the bunch. > > > > > > - Tom Millar, US-CERT > > > > thomas.millar@us-cert.gov > > BB: thomas.millar@dhs.gov / > > 202-631-1915 > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > -----Original Message----- > > From: mile-bounces@ietf.org > > [mailto:mile-bounces@ietf.org] On Behalf Of > > david.black@emc.com > > Sent: Tuesday, February 14, 2012 11:14 > > To: ramartin@mitre.org > > Cc: mile@ietf.org > > Subject: Re: [mile] MTI SCI? > > > > Hi Bob, > > > > I do appreciate the concern about implementing things that aren't going > to be used. OTOH, it may be useful to have a single simple MTI spec for > SCI that can be used to "smoke test" a deployment before trying any serious > test data (and "simple" is important). > > > > In addition, a concern that I would have with an MTI SCI spec per class > is that if two SCI implementations don't have at least one class in common, > they aren't going to interoperate, and that situation is unlikely to be > acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect > that there will also have to be an MTI class, which results in an overall > MTI SCI spec). > > > > It may also be useful to include a simple example of the MTI SCI spec > in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec > is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML > document for testing purposes, including enumeration values suitable for > testing). > > > > What do you (and others) think about this? > > > > Thanks, > > --David > > > > -----Original Message----- > > From: mile-bounces@ietf.org > [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > Sent: Tuesday, February 14, 2012 8:26 AM > > To: Brian Trammell > > Cc: mile@ietf.org > > Subject: Re: [mile] MTI SCI? > > Brian, > > You beat me to this point. Like you, I would be concerned about a MTI > > selection that ended up requiring someone to implement something to > > meet the MTI but wasn't germane to anything else they intended to > support. > > Bob > > On 2/14/12 4:19 AM, Brian Trammell wrote: > >> Hi, Sean, all, > >> > >> Looking over the spec, it's not clear to me that one MTI makes sense > >> here, given that mile-sci's > > purpose is to reference a set of external specifications by inclusion > > in an IODEF document, and that those external specifications represent > fundamentally different things. > >> > >> The specifications are split over their applicability to the IODEF > >> extension classes. I could > > envision an mile-sci implementation that was only interested a subset > > of these classes (perhaps even only one). If my implementation has an > > internal representation of Verification, but not of any of the other > > classes, and the MTI is an enumeration that is applicable to > Vulnerability... what do I do? > >> > >> What about selecting an MTI per class, instead? > >> > >> Best regards, > >> > >> Brian (as contributor) > >> > >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > >> > >>> Great - as long as we pick one as the MTI. Note that MTI is not > necessarily mandatory to use. > >>> > >>> spt > >>> > >>> On 2/13/12 7:11 PM, > kathleen.moriarty@emc.com wrote: > >>>> Thank you for raising the interoperability testing as we need to > >>>> plan for a bake-off that once > > these questions get answered and the draft is ready. > >>>> > >>>> Thanks, > >>>> Kathleen > >>>> > >>>> -----Original Message----- > >>>> From: mile-bounces@ietf.org > >>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > >>>> Sent: Monday, February 13, 2012 6:57 PM > >>>> To: mile@ietf.org > >>>> Subject: [mile] MTI SCI? > >>>> > >>>> There's 17 listed SCI (Structured Cybersecurity Information) > >>>> specifications in draft-ietf-mile-sci. Which one is the MTI > >>>> (mandatory to implement) choice? In other words, how will you get > >>>> two interoperability implementations without picking one? > >>>> > >>>> spt > >>>> _______________________________________________ > >>>> mile mailing list > >>>> mile@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> > >>> _______________________________________________ > >>> mile mailing list > >>> mile@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mile > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > >> . > >> > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_EDBD_01CCF1D8.06AC8020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mile] MTI SCI?

Hi Jeff,

Thank you for your kind correction.

I appreciate feedbacks.

Kind Regards,

Take

From: Jeff Reed [mailto:jeff360@gmail.com]
Sent: Tuesday, February 21, = 2012 11:27 AM
To: Takeshi Takahashi
Cc: mile@ietf.org
Subject: Re: [mile] MTI SCI?

Take,

   Should your suggested = text:

 Implementations may choose which specifications to
  support, though CVE 1.0 (Section 4.1.7) needs to be minimally
  supported.

   ...be changes to:

 Implementations may choose which specifications to
  support, though CVE 1.0 (Section 4.1.7) MUST be minimally
  supported.

   ...in the context of this discussion?

   Kind regards,

   Jeff Reed
  

On Wed, = Feb 15, 2012 at 1:15 AM, Takeshi Takahashi <takeshi_takahashi@nict.go.jp> wrote:

Hello = all,

Following the discussion, I would like to add a couple of sentences = to
clarify the MTI issues.
(Thank you very much for those of you who kindly provided useful
discussion.)
I've attached the working version = of the draft. I hope it helps to clarify
the changes.

(added sentences at the end of section 4.1)

  The SpecID attributes of extended classes (Section 4.3) must = allow
  the values of the specifications' namespace fields, but = otherwise,
  implementations are not required to support all the = above
  specifications.  Implementations may choose which = specifications to
  support, though CVE 1.0 (Section 4.1.7) needs to be minimally
  supported.  In case an implementation received a data it = does not
  support, it may expand its functionality by = looking up the IANA table or
  notify the sender of its inability to parse the data by using = any
  means defined outside the scope of this specification.

On the other hand, I would like to add "STRING = ext-SpecID" to each class,
which enables to embed data following private schema.
For instance, one security operation center (SOC) may wish to exchange = a
vulnerability data that is formatted in its own private schema, and that = is
not formatted in CVE.
In this case, the SOC may put the data's schema ID inside = ext-SpecID and
then embed the data.
It could also be used to exchange data using beta version of = specifications.

The class could be seen as below.

  +------------------------+
  | AttackPattern          |
  +------------------------+
  | ENUM SpecID           =  |<>--(0..*)-[ RawData ]
  | STRING ext-SpecID      |<>--(0..*)-[ = Reference ]
  | STRING AttackPatternID |<>--(0..*)-[ Platform ]
  +------------------------+

  SpecID:  REQUIRED.  ENUM.  The identifier = of the specification
     specifying the format of the RawData element. =  The value should be
     chosen from the namespaces [XMLNames] listed in = Section 4.1 or
     "private".  Note that the lists in = Section 4.1 will be developed
     further by IANA. The value "private" = is prepared for conveying
     RawData based on a format that is not listed in = the
     table.  This is usually used for conveying data = formatted
     according to an organization's private schema. =  When the value
     "private" is used, ext-SpecID = element needs to be used.

  ext-SpecID:  OPTIONAL.  STRING.  The identifier of = the specification
     specifying the format of the RawData element. =  When this element
     is used, the value of SpecID element must be = "private."

I hope above changes don't cause any complication here.

Sincerely,
Take




> -----Original Message-----
> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of
> Martin, Robert = A.

> = Sent: Wednesday, February 15, 2012 1:50 AM
> To: Kent_Landfield@McAfee.com
> Cc: mile@ietf.org
> Subject: Re: [mile] MTI SCI?
>

> At = the risk of contradicting myself - but then again I have now = read the
> other replies to this issue - I agree that having one area be the = smoke
> test makes sense and I also agree that something simple and = commonly used
> already - like CVE - is the best candidate for what we need.
>
> Bob
>
> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote:
> > CVE is widely used and understood by all in the the security = community.
> I agree with Tom that CVE is the path of least resistance but may = be the
> most useful for basic interoperability.
> >
> > Kent Landfield
> > Director Content = Strategy, Architecture and Standards
> >
> > McAfee | An Intel Company
> > 5000 Headquarters Dr.
> > Plano, Texas 75024
> >
> > Direct: +1.972.963.7096
> > Mobile: +1.817.637.8026
> > Web: www.mcafee.com<http://www.mcafee.com/>
> >
> > From:
> >
> "Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>"<Thomas
> .M
> > illar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>>
> > Date: Tue, 14 Feb 2012 = 10:36:57 -0600
> > To:
> >
> "david.black@emc.com<mailto:david.black@emc.com>"<david.black@emc.co
> m<
> > mailto:david.black@emc.com>>, Bob
> > Martin<ramartin@mitre.org<mailto:ramartin@mitre.org>>
> > Cc:
> >
> "mile@ietf.org<mailto:mile@ietf.org>"<mile@ietf.org<mailto:mile@ietf
> .o
> > rg>>
> > Subject: Re: [mile] MTI SCI?
> >
> > My concern with CAPEC = being mandatory is that it could discourage
> effective operational uptake of IODEF-SCI as the CAPEC vocabulary = remains
> "too comprehensive" for many CSIRTs to employ during = incident handling
> and reporting activity.
> >
> > IODEF by itself has been criticized by CSIRT = operators for being more
> heavyweight than necessary for day-to-day usage; making CAPEC a = mandatory
> aspect of "advanced IODEF" seems like it would be adding = ammunition to
> that argument, especially if the CSIRT is having to fund = implementation
> out of their own pocket. Personally, I would have a hard time = asking
> US-CERT's primary constituents to implement IODEF + CAPEC if they = are
> already balking at the consultant and developer resources required = to
> implement RFC 5070 by itself. Also keep in mind that = CAPEC references
> CybOX, so there's wheels within wheels now.
> >
> > I would prefer we take the path of least resistance (from = my
perspective)
> and make CVE the MTI, if we have to pick one additional spec.
> > CVE is well known, has = years of familiarity built in, and I think it's
> the simplest schema of the bunch.
> >
> >
> > - Tom Millar, US-CERT
> >
> > thomas.millar@us-cert.gov<mailto:thomas.millar@us-cert.gov>
> > BB: thomas.millar@dhs.gov<mailto:thomas.millar@dhs.gov>  /
> > 202-631-1915
> > 24x7: soc@us-cert.gov<mailto:soc@us-cert.gov>  / 888-282-0870
> >
> > -----Original Message-----
> > From: mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>
> > [mailto:mile-bounces@ietf.org] On Behalf Of
> > david.black@emc.com<mailto:david.black@emc.com>
> > Sent: Tuesday, February 14, 2012 11:14
> > To: ramartin@mitre.org<mailto:ramartin@mitre.org>
> > Cc: mile@ietf.org<mailto:mile@ietf.org>
> > Subject: Re: [mile] MTI SCI?
> >
> > Hi Bob,
> >
> > I do appreciate the concern about implementing things that aren't going
> to be used.  OTOH, it may be useful to have a single simple = MTI spec for
> SCI that can be used to "smoke test" a deployment before = trying any
serious
> test data (and "simple" is important).
> >
> > In addition, a concern that I would have with an MTI SCI = spec per class
> is that if two SCI implementations don't have at least one class = in
common,
> they aren't going to interoperate, and that situation is unlikely = to be
> acceptable to the IESG (i.e., with an MTI SCI spec per = class, I suspect
> that there will also have to be an MTI class, which results in an = overall
> MTI SCI spec).
> >
> > It may also be useful to include a simple example of the MTI = SCI spec
> in an appendix to simplify "smoke testing" (e.g., if the = MTI SCI spec
> is CAPEC, as Youki suggested, the appendix could contain a = CAPEC XML
> document for testing purposes, including enumeration values = suitable for
> testing).
> >
> > What do you (and others) think about this?
> >
> > Thanks,
> > --David
> >
> > -----Original = Message-----
> > From: mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>
> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A.
> > Sent: Tuesday, February 14, 2012 8:26 AM
> > To: Brian Trammell
> > Cc: mile@ietf.org<mailto:mile@ietf.org>
> > Subject: Re: [mile] MTI SCI?
> > Brian,
> > You beat me to this point.  Like you, I would be = concerned about a MTI
> > selection that ended up requiring someone to implement = something to
> > meet the MTI but wasn't germane to anything else they intended = to
> support.
> > Bob
> > On 2/14/12 4:19 AM, Brian Trammell wrote:
> >> Hi, Sean, all,
> >>
> >> Looking over the spec, it's not clear to me that one MTI = makes sense
> >> here, given that mile-sci's
> > purpose is to reference a set of external specifications by = inclusion
> > in an IODEF document, and that those = external specifications represent
> fundamentally different things.
> >>
> >> The specifications are split over their applicability to = the IODEF
> >> extension classes. I could
> > envision an mile-sci implementation that was only interested a subset
> > of these classes (perhaps even only one). If my implementation = has an
> > internal representation of Verification, but not of any of the = other
> > classes, and the MTI is an enumeration that is applicable = to
> Vulnerability... what do I do?
> >>
> >> What about selecting an MTI per class, instead?
> >>
> >> Best regards,
> >>
> >> Brian (as contributor)
> >>
> >> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote:
> >>
> >>> Great - as long as we pick one as the MTI.  Note = that MTI is not
> necessarily mandatory to = use.
> >>>
> >>> spt
> >>>
> >>> On 2/13/12 7:11 PM,
> kathleen.moriarty@emc.com<mailto:kathleen.moriarty@emc.com>  wrote:
> >>>> Thank you = for raising the interoperability testing as we need to
> >>>> plan for a bake-off that once
> > these questions get answered and the draft is ready.
> >>>>
> >>>> Thanks,
> >>>> Kathleen
> >>>>
> >>>> -----Original Message-----
> >>>> From: mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>
> >>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner
> >>>> Sent: = Monday, February 13, 2012 6:57 PM
> >>>> To: mile@ietf.org<mailto:mile@ietf.org>
> >>>> Subject: [mile] MTI SCI?
> >>>>
> >>>> There's 17 listed SCI (Structured Cybersecurity = Information)
> >>>> specifications in draft-ietf-mile-sci.  Which = one is the MTI
> >>>> (mandatory to implement) choice?  In other = words, how will you get
> >>>> two interoperability implementations without = picking one?
> >>>>
> >>>> spt
> >>>> _______________________________________________
> >>>> mile mailing list
> >>>> mile@ietf.org<mailto:mile@ietf.org>
> >>>> https://www.ietf.org/mailman/listinfo/mile
> >>>>
> >>>>
> >>> _______________________________________________
> >>> mile mailing list
> >>> mile@ietf.org<mailto:mile@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/mile
> >>
> >> _______________________________________________
> >> mile mailing list
> >> mile@ietf.org<mailto:mile@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/mile
> >> .
> >>
> > _______________________________________________
> > mile mailing list
> > mile@ietf.org<mailto:mile@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mile
> >
> > _______________________________________________
> > mile mailing list
> > mile@ietf.org<mailto:mile@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mile
> > = _______________________________________________
> > mile mailing list
> > mile@ietf.org<mailto:mile@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mile
> >
> >
> _______________________________________________
> mile mailing list
> mile@ietf.org
> = https://www.ietf.org/mailman/listinfo/mile


_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile

------=_NextPart_000_EDBD_01CCF1D8.06AC8020-- From takeshi_takahashi@nict.go.jp Wed Feb 22 10:36:03 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0460321F8731 for ; Wed, 22 Feb 2012 10:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 YWLNJYnJIIIA for ; Wed, 22 Feb 2012 10:35:58 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F6B21F86F8 for ; Wed, 22 Feb 2012 10:35:58 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q1MIZrTF013285; Thu, 23 Feb 2012 03:35:53 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q1MIZr5C000391; Thu, 23 Feb 2012 03:35:53 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id q1MIZo9Q000378; Thu, 23 Feb 2012 03:35:51 +0900 (JST) From: "Takeshi Takahashi" To: , References: <4F3A909F.7060502@mitre.org> <004101ccebc2$61941820$24bc4860$@nict.go.jp> , <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FF@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FF@MX14A.corp.emc.com> Date: Thu, 23 Feb 2012 03:35:37 +0900 Message-ID: <10c6f01ccf190$c6dd5380$5497fa80$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtQCUmL+XgJqFvltlTseSwA= Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] Guidance on SCI usage X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:36:03 -0000 I understand and agree on the concern Dave kindly provided. By the way, in Sci02 draft, multiple URI could be described in the "Specification URI" field of the IANA table. (See section 6) (Sci01 draft allowed only one URI for the field, but I changed when publishing Sci02 draft.) Specification URI: A list of one or more of the URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI. (Section 6) So, informational RFC that describes the usage of the specifications, as well as the original specification, could be described in the field. Thank you. Take > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Wednesday, February 22, 2012 9:00 AM > To: david.waltermire@nist.gov > Cc: mile@ietf.org > Subject: [mile] Guidance on SCI usage > > > For all referenced models, a larger concern is referencing a website > > for guidance. A website can be inherently unstable, as it can be > > changed at any time, and does not necessarily represent a consensus > opinion. > > I concur with the need for a stable reference for guidance on SCI spec > usage, as the guidance could be quite important (e.g., prior discussion > on how to use MAEC in two different ways as an SCI). FWIW, I recently > discovered independently that IETF doesn't consider Wikipedia to be a > stable reference ;-). > > Putting the guidance for usage of the initial specs into the SCI draft > sounds like a good idea, especially as the IANA registry entries for all > of those initial specs will point back to that draft (as an RFC), which > should make the guidance easy to find for implementers. > > Beyond that I'm going to split a hair :-). An RFC is a good stable guidance > reference, but an informational RFC (as opposed to standards track) may > suffice. I'd suggest deferring that decision in favor of figuring out > what the guidance needs to cover. > > How does that sound? > > Thanks, > --David > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of Waltermire, David A. > > Sent: Tuesday, February 21, 2012 3:57 PM > > To: Moriarty, Kathleen; trammell@tik.ee.ethz.ch; > > takeshi_takahashi@nict.go.jp > > Cc: mile@ietf.org > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was Re: MTI SCI?) > > > > For all referenced models, a larger concern is referencing a website > > for guidance. A website can be inherantly unstable, as it can be > > changed at any time, and does not necessarily represent a consensous > > opinion. One possibility might be to reference a standards track > > document that specified the use of the model. In addition the > > referenced document could possibly provide some parsing instructions > > for the model addressing some of the concerns from the other discussion > thread. This would require new work to be completed before completing > the SCI document, but would provide a more concrete foundation for > interoperable information exchange. > > > > Any thoughts on this approach? > > > > Sincerely, > > David Waltermire > > > > > -----Original Message----- > > > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > > > Sent: Monday, February 20, 2012 6:08 AM > > > To: Waltermire, David A.; trammell@tik.ee.ethz.ch; > > > takeshi_takahashi@nict.go.jp > > > Cc: mile@ietf.org > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for > > > SCI (was Re: MTI SCI?) > > > > > > Thank you, Dave. > > > > > > Dave raises a few very important points as we consider MTI for SCI. > > > We will need to resolve these issues if CVE is to be the (or an) MTI > > > specification for the SCI draft. > > > > > > If CVE is mandatory to implement, what guidance would be followed > on > > > how to use the model or will MTI only mean that the document can be > > > received and parsed? The CVE website is listed as the specification > > > URI, but from Dave's message, the specification URI does not exist > > > to provide the guidance (I get to broken link pages for both - the > > > existing and suggested replacement link). > > > > > > This is the closest I could find and may be the answer for guidance: > > > http://cve.mitre.org/compatible/requirements.html > > > > > > It looks like the reference to the target namespace needs to be > > > fixed as well. > > > > > > Thank you, > > > Kathleen > > > ________________________________________ > > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > > > Waltermire, David A. [david.waltermire@nist.gov] > > > Sent: Thursday, February 16, 2012 5:26 PM > > > To: Brian Trammell; Takeshi Takahashi > > > Cc: mile@ietf.org > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > SCI (was Re: MTI SCI?) > > > > > > I have not been following this thread as closely as I probably should. > > > Relative to MTI, is the question what schema should be MTI for the > > > vulerability class? In general I think we should have one or more > > > MTI for each class. > > > > > > Relative to CVE specifically, are we talking about the schema > > > currently located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > > > > > This seems to match the namespace defined in section 4.1.7 of > > > mile-sci- 02. Looking at the implementation of this schema, it > > > looks like the targetNamespace is incorrectly assigned to > > > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it > > > should be "http://cve.mitre.org/cve/downloads/1.0". This will > > > likely need to be fixed. > > > > > > Also, the specification URI points to the CVE website, which is not > > > really a specification. It's not clear where to find guidance on > > > how to properly use the model indicated by the namespace. Without > > > having clear guidance on its use I don't see how we can make it MTI, > > > even if it is considered a de facto approach. It might make sense > > > to produce a specification for the model before making it MTI for > > > the vulnerability class. > > > > > > Sincerely, > > > David Waltermire > > > > > > > -----Original Message----- > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > Behalf Of Brian Trammell > > > > Sent: Wednesday, February 15, 2012 5:28 AM > > > > To: Takeshi Takahashi > > > > Cc: mile@ietf.org > > > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI > > > (was > > > > Re: MTI SCI?) > > > > > > > > Hi, Take, all, > > > > > > > > Thank you for this edit/clarification. > > > > > > > > On the first point, it does seem the discussion on the list > > > > converged rather quickly to CVE as MTI. However, as this is a > > > > rather important point, I'd like to make sure we didn't miss anything. > > > > > > > > So, I'd like to call for consensus on the list. Does the working > > > group > > > > agree on the following two points? > > > > > > > > 1. mile-sci requires one Mandatory to Implement schema in order > to > > > > ensure interoperability. > > > > > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of > > > > mile- sci-02. > > > > > > > > Please note if you agree; if you disagree, please explain why not. > > > > > > > > Best regards, > > > > > > > > Brian (as chair) > > > > > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > > > > > Hello all, > > > > > > > > > > Following the discussion, I would like to add a couple of > > > > > sentences > > > > to > > > > > clarify the MTI issues. > > > > > (Thank you very much for those of you who kindly provided useful > > > > > discussion.) > > > > > I've attached the working version of the draft. I hope it helps > > > > > to clarify the changes. > > > > > > > > > > (added sentences at the end of section 4.1) > > > > > > > > > > The SpecID attributes of extended classes (Section 4.3) must > > > allow > > > > > the values of the specifications' namespace fields, but > > > otherwise, > > > > > implementations are not required to support all the above > > > > > specifications. Implementations may choose which > > > > > specifications > > > to > > > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > > > supported. In case an implementation received a data it does > not > > > > > support, it may expand its functionality by looking up the > > > > > IANA > > > > table or > > > > > notify the sender of its inability to parse the data by using > any > > > > > means defined outside the scope of this specification. > > > > > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to > > > > > each class, which enables to embed data following private schema. > > > > > For instance, one security operation center (SOC) may wish to > > > > exchange > > > > > a vulnerability data that is formatted in its own private > > > > > schema, and that is not formatted in CVE. > > > > > In this case, the SOC may put the data's schema ID inside ext- > > > SpecID > > > > > and then embed the data. > > > > > It could also be used to exchange data using beta version of > > > > specifications. > > > > > > > > > > The class could be seen as below. > > > > > > > > > > +------------------------+ > > > > > | AttackPattern | > > > > > +------------------------+ > > > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > > > +------------------------+ > > > > > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specification > > > > > specifying the format of the RawData element. The value > > > should > > > > be > > > > > chosen from the namespaces [XMLNames] listed in Section 4.1 > or > > > > > "private". Note that the lists in Section 4.1 will be > > > developed > > > > > further by IANA. The value "private" is prepared for conveying > > > > > RawData based on a format that is not listed in the > > > > > table. This is usually used for conveying data formatted > > > > > according to an organization's private schema. When the > value > > > > > "private" is used, ext-SpecID element needs to be used. > > > > > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > > > specification > > > > > specifying the format of the RawData element. When this > > > element > > > > > is used, the value of SpecID element must be "private." > > > > > > > > > > I hope above changes don't cause any complication here. > > > > > > > > > > Sincerely, > > > > > Take > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > >> Behalf Of Martin, Robert A. > > > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > > > >> To: Kent_Landfield@McAfee.com > > > > >> Cc: mile@ietf.org > > > > >> Subject: Re: [mile] MTI SCI? > > > > >> > > > > >> At the risk of contradicting myself - but then again I have now > > > > >> read the other replies to this issue - I agree that having one > > > area > > > > >> be > > > > the > > > > >> smoke test makes sense and I also agree that something simple > > > > >> and commonly used already - like CVE - is the best candidate > > > > >> for what we > > > > need. > > > > >> > > > > >> Bob > > > > >> > > > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > > > >>> CVE is widely used and understood by all in the the security > > > > community. > > > > >> I agree with Tom that CVE is the path of least resistance but > > > > >> may be the most useful for basic interoperability. > > > > >>> > > > > >>> Kent Landfield > > > > >>> Director Content Strategy, Architecture and Standards > > > > >>> > > > > >>> McAfee | An Intel Company > > > > >>> 5000 Headquarters Dr. > > > > >>> Plano, Texas 75024 > > > > >>> > > > > >>> Direct: +1.972.963.7096 > > > > >>> Mobile: +1.817.637.8026 > > > > >>> Web: www.mcafee.com > > > > >>> > > > > >>> From: > > > > >>> > > > > >> "Thomas.Millar@us-cert.gov > > cert.gov>" > > > >> s > > > > >> .M > > > > >>> illar@us-cert.gov> > > > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > > > >>> To: > > > > >>> > > > > >> > > > > "david.black@emc.com" > > > >> o > > > > >> m< > > > > >>> mailto:david.black@emc.com>>, Bob > > > > >>> Martin> > > > > >>> Cc: > > > > >>> > > > > >> > > > > "mile@ietf.org" > > > >> f > > > > >> .o > > > > >>> rg>> > > > > >>> Subject: Re: [mile] MTI SCI? > > > > >>> > > > > >>> My concern with CAPEC being mandatory is that it could > > > > >>> discourage > > > > >> effective operational uptake of IODEF-SCI as the CAPEC > > > > >> vocabulary remains "too comprehensive" for many CSIRTs to > > > > >> employ during > > > > incident > > > > >> handling and reporting activity. > > > > >>> > > > > >>> IODEF by itself has been criticized by CSIRT operators for > > > > >>> being more > > > > >> heavyweight than necessary for day-to-day usage; making CAPEC > a > > > > >> mandatory aspect of "advanced IODEF" seems like it would be > > > > >> adding ammunition to that argument, especially if the CSIRT is > > > > >> having to fund implementation out of their own pocket. > > > > >> Personally, I would > > > > have > > > > >> a hard time asking US-CERT's primary constituents to implement > > > > >> IODEF > > > > >> + CAPEC if they are already balking at the consultant and > > > developer > > > > >> resources required to implement RFC 5070 by itself. Also keep > > > > >> in > > > > mind > > > > >> that CAPEC references CybOX, so there's wheels within wheels > now. > > > > >>> > > > > >>> I would prefer we take the path of least resistance (from my > > > > > perspective) > > > > >> and make CVE the MTI, if we have to pick one additional spec. > > > > >>> CVE is well known, has years of familiarity built in, and I > > > > >>> think it's > > > > >> the simplest schema of the bunch. > > > > >>> > > > > >>> > > > > >>> - Tom Millar, US-CERT > > > > >>> > > > > >>> thomas.millar@us-cert.gov > > > > >>> BB: thomas.millar@dhs.gov / > > > > >>> 202-631-1915 > > > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > > > >>> > > > > >>> -----Original Message----- > > > > >>> From: mile-bounces@ietf.org > > > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > > > >>> david.black@emc.com > > > > >>> Sent: Tuesday, February 14, 2012 11:14 > > > > >>> To: ramartin@mitre.org > > > > >>> Cc: mile@ietf.org > > > > >>> Subject: Re: [mile] MTI SCI? > > > > >>> > > > > >>> Hi Bob, > > > > >>> > > > > >>> I do appreciate the concern about implementing things that > > > > >>> aren't going > > > > >> to be used. OTOH, it may be useful to have a single simple MTI > > > > >> spec for SCI that can be used to "smoke test" a deployment > > > > >> before trying any > > > > > serious > > > > >> test data (and "simple" is important). > > > > >>> > > > > >>> In addition, a concern that I would have with an MTI SCI spec > > > > >>> per class > > > > >> is that if two SCI implementations don't have at least one > > > > >> class > > > in > > > > > common, > > > > >> they aren't going to interoperate, and that situation is > > > > >> unlikely to be acceptable to the IESG (i.e., with an MTI SCI > > > > >> spec per > > > class, > > > > >> I suspect that there will also have to be an MTI class, which > > > > >> results in an overall MTI SCI spec). > > > > >>> > > > > >>> It may also be useful to include a simple example of the MTI > > > > >>> SCI spec > > > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI > > > > >> SCI > > > > spec > > > > >> is CAPEC, as Youki suggested, the appendix could contain a > > > > >> CAPEC XML document for testing purposes, including enumeration > > > > >> values suitable for testing). > > > > >>> > > > > >>> What do you (and others) think about this? > > > > >>> > > > > >>> Thanks, > > > > >>> --David > > > > >>> > > > > >>> -----Original Message----- > > > > >>> From: mile-bounces@ietf.org > > > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > > > >>> To: Brian Trammell > > > > >>> Cc: mile@ietf.org > > > > >>> Subject: Re: [mile] MTI SCI? > > > > >>> Brian, > > > > >>> You beat me to this point. Like you, I would be concerned > > > > >>> about > > > a > > > > >>> MTI selection that ended up requiring someone to implement > > > > something > > > > >>> to meet the MTI but wasn't germane to anything else they > > > > >>> intended > > > > to > > > > >> support. > > > > >>> Bob > > > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > > > >>>> Hi, Sean, all, > > > > >>>> > > > > >>>> Looking over the spec, it's not clear to me that one MTI > > > > >>>> makes sense here, given that mile-sci's > > > > >>> purpose is to reference a set of external specifications by > > > > >>> inclusion in an IODEF document, and that those external > > > > >>> specifications represent > > > > >> fundamentally different things. > > > > >>>> > > > > >>>> The specifications are split over their applicability to the > > > > >>>> IODEF extension classes. I could > > > > >>> envision an mile-sci implementation that was only interested > a > > > > >>> subset of these classes (perhaps even only one). If my > > > > >>> implementation has an internal representation of Verification, > > > but > > > > >>> not of any of the other classes, and the MTI is an enumeration > > > > >>> that is applicable to > > > > >> Vulnerability... what do I do? > > > > >>>> > > > > >>>> What about selecting an MTI per class, instead? > > > > >>>> > > > > >>>> Best regards, > > > > >>>> > > > > >>>> Brian (as contributor) > > > > >>>> > > > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > > >>>> > > > > >>>>> Great - as long as we pick one as the MTI. Note that MTI > is > > > not > > > > >> necessarily mandatory to use. > > > > >>>>> > > > > >>>>> spt > > > > >>>>> > > > > >>>>> On 2/13/12 7:11 PM, > > > > >> kathleen.moriarty@emc.com > > > wrote: > > > > >>>>>> Thank you for raising the interoperability testing as we > > > > >>>>>> need to plan for a bake-off that once > > > > >>> these questions get answered and the draft is ready. > > > > >>>>>> > > > > >>>>>> Thanks, > > > > >>>>>> Kathleen > > > > >>>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: mile-bounces@ietf.org > > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > > > >>>>>> To: mile@ietf.org > > > > >>>>>> Subject: [mile] MTI SCI? > > > > >>>>>> > > > > >>>>>> There's 17 listed SCI (Structured Cybersecurity > > > > >>>>>> Information) specifications in draft-ietf-mile-sci. Which > > > > >>>>>> one is the MTI (mandatory to implement) choice? In other > > > > >>>>>> words, how will you get two interoperability implementations > without picking one? > > > > >>>>>> > > > > >>>>>> spt > > > > >>>>>> _______________________________________________ > > > > >>>>>> mile mailing list > > > > >>>>>> mile@ietf.org > > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > > >>>>>> > > > > >>>>>> > > > > >>>>> _______________________________________________ > > > > >>>>> mile mailing list > > > > >>>>> mile@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> mile mailing list > > > > >>>> mile@ietf.org > > > > >>>> https://www.ietf.org/mailman/listinfo/mile > > > > >>>> . > > > > >>>> > > > > >>> _______________________________________________ > > > > >>> mile mailing list > > > > >>> mile@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > >>> > > > > >>> _______________________________________________ > > > > >>> mile mailing list > > > > >>> mile@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > >>> _______________________________________________ > > > > >>> mile mailing list > > > > >>> mile@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > >>> > > > > >>> > > > > >> _______________________________________________ > > > > >> mile mailing list > > > > >> mile@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > ci- > > > > 03c > > > > > > > > > > > > > andidate_20120215.txt.pdf>__________________________________________ > > > __ > > > > > ___ > > > > > mile mailing list > > > > > mile@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > _______________________________________________ > > > > mile mailing list > > > > mile@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mile > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > From david.black@emc.com Wed Feb 22 11:39:05 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF1621F850F for ; Wed, 22 Feb 2012 11:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.643 X-Spam-Level: X-Spam-Status: No, score=-109.643 tagged_above=-999 required=5 tests=[AWL=0.956, 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 oVDQOPL0IayB for ; Wed, 22 Feb 2012 11:39:03 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 50C7521F86B7 for ; Wed, 22 Feb 2012 11:39:00 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1MJcsmD023731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 14:38:58 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 22 Feb 2012 14:38:39 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1MJcdo9008024; Wed, 22 Feb 2012 14:38:39 -0500 Received: from mx14a.corp.emc.com ([169.254.1.157]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Wed, 22 Feb 2012 14:38:38 -0500 From: To: , Date: Wed, 22 Feb 2012 14:38:38 -0500 Thread-Topic: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtQCXe3+vgHTO+ibAQ/JkYkBN9mkQwEgvGD1lSQq87CAABloYA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEFC68@MX14A.corp.emc.com> References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:39:05 -0000 Hi Take, > I think the receiver needs to be capable of validating received CVE XML f= or > the smoke test purpose, but I am not sure whether we should mandate the > validation process to the receiver. I think you have a point. In more detail, while discussing mandatory-to-im= plement requirements, we have gotten into discussing whether schema validation shou= ld not only be mandatory-to-implement, but also whether it should be mandatory-to-use (a different, but related, concept) when the SpecID is use= d. I suggest that validation that XML content is well-formed with respect to its schema is a good idea, so I think something stronger than "be capable o= f" is appropriate. OTOH, I can conceive of reasons to bypass validation (e.g.= , the schema validation is always failing, so as a step towards finding the probl= em, turn off validation in order to take a look at the actual XML that arrived, which should indicate whether the problem is at the sender vs. the receiver= ). In light of that, here's a possible rewrite of my two sentences (they are n= ow three sentences in order to separate implementation and usage requirements)= : 1. The CVE SpecID value and related values (e.g., namespace) MUST be implemented (implementation is capable of sending and receiving well-formed CVE 1.0 XML documents without error). 2. The receiver MUST implement validation of received CVE 1.0 XML documents against the CVE 1.0 XML schema in order to detect invalid CVE documents. 3. The receiver SHOULD validate all received CVE 1.0 XML documents as described in item #2. What do you think of this? Thanks, --David > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Wednesday, February 22, 2012 1:06 PM > To: Black, David; Thomas.Millar@us-cert.gov; mile@ietf.org > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wa= s Re: MTI SCI?) > > I'm generally in favor of the kind opinions from Tom and David. > IMHO, the sentence David kindly provided could be changed as below: > > In order to be compliant with SCI draft, the implementations need to suff= ice > below: > > 1. The CVE SpecID value and related values (e.g., namespace) MUST be > supported (not cause errors if used). > 2. Recipient MUST "be capable of" validating received CVE 1.0 XML documen= t > against the CVE 1.0 XML schema to detect invalid CVE documents. > > I think the receiver needs to be capable of validating received CVE XML f= or > the smoke test purpose, but I am not sure whether we should mandate the > validation process to the receiver. > When operation processes are automated, validation process could be > implemented elsewhere (for instance, data generation unit could do the > validation). > So, I think the SCI draft could mandates the capability, instead of the > process. > > Does it make sense? > > Thank you. > Take > > > -----Original Message----- > > From: david.black@emc.com [mailto:david.black@emc.com] > > Sent: Wednesday, February 22, 2012 8:47 AM > > To: Thomas.Millar@us-cert.gov; mile@ietf.org > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was Re: MTI SCI?) > > > > A "smoke test" is one of the motivations for this MTI requirement - for > > that, validation of the received content (e.g., against an XML schema > > for XML content) should be required, as one usually wants to know that > > the "smoke" made it through ok (the "smoke" that arrived matches what > > was sent). > > > > So, even if the content will only be used as "smoke test" evidence, and > > not otherwise interpreted, it's still a good idea to require format > > validation. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Thomas.Millar@us-cert.gov [mailto:Thomas.Millar@us-cert.gov] > > > Sent: Tuesday, February 21, 2012 4:18 PM > > > To: Black, David; mile@ietf.org > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > > > (wasRe: MTI SCI?) > > > > > > Should a recipient be required to validate a referenced schema even > > if > > > they don't intend to interpret the content? > > > > > > - Tom Millar, US-CERT > > > > > > thomas.millar@us-cert.gov > > > BB: thomas.millar@dhs.gov / 202-631-1915 > > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > > > -----Original Message----- > > > From: david.black@emc.com [mailto:david.black@emc.com] > > > Sent: Tuesday, February 21, 2012 12:49 > > > To: mile@ietf.org; Millar, Thomas R > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > > > (wasRe: MTI SCI?) > > > > > > Hi Tom, > > > > > > I believe I agree with you, although I'd like to add some precision > > on what is meant by "parse". > > > > > > I don't think it's sufficient to support the value in the SpecID fiel= d > > > (e.g., a CVE > > > version) and accept an XML blob that is not a well-formed CVE XML > > document. > > > > > > Hence, I think the minimum requirement is to validate the received SC= I > > > XML document against the appropriate XML schema and detect any errors= . > > > > > > Beyond that, Take's reference to RFC 5070 is a useful source of > > > insight, as I think it rules out most additional requirements. IODEF > > is a format, not a protocol, so: > > > > > > A) Error reporting is specific to whatever transport protocol > > is being used. > > > For example, if RID is used, the rfc6046-bis draft > > specifies how to > > > report errors, but there's no RFC 5070 requirement th= at > > IODEF use RID. > > > Beyond error detection, it's not possible to specify > > a required error > > > reporting mechanism. > > > > > > B) RFC 5070 has nothing to say about replies or responses to > > IODEF, so the > > > same should be true of extensions like SCI. > > > > > > C) I'm not sure I understand what Take had in mind by "how to > > understand" in > > > #2. I see no need to understand CVE semantics or > > meaning beyond the CVE > > > syntax check obtained by validating the received > > document against the > > > CVE XML schema. > > > > > > > I would recommend that we be very clear in regards to what "support= " > > > > or "minimally support" mean so that technical requirements handed > > > > down based on this draft do not bar achievement by operational > > implementers and their engineering teams. > > > > > > I agree and would suggest: > > > > > > - The CVE SpecID value and related values (e.g., namespace) > > MUST > > > be supported (not cause errors if used). > > > - Recipient MUST validate received CVE XML document against > > the CVE > > > XML schema to detect invalid CVE documents. > > > > > > I assume that this is all about CVE 1.0. > > > > > > Does all of this make sense? > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.= , > > > Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > david.black@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > > -----Original Message----- > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > Behalf > > > > Of Thomas.Millar@us-cert.gov > > > > Sent: Tuesday, February 21, 2012 12:00 PM > > > > To: ariestake@googlemail.com; Moriarty, Kathleen; > > > > david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > > > takeshi_takahashi@nict.go.jp > > > > Cc: mile@ietf.org > > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > > SCI (was Re: MTI SCI?) > > > > > > > > Take, > > > > > > > > I think you've done a very good job of explaining the two different > > > > interpretations around this call for consensus. > > > > > > > > My interpretation of MTI was closer to #2 - that to support this > > > > draft, an implementer would have to support not only recognition of > > > > the namespace in the appropriate IODEF parent class context, but > > > > also be able to parse the content of the referenced namespace. Henc= e > > > > my preference for a relatively > > > simple and familiar spec as the MTI. > > > > > > > > If we can concur that we all really mean the interpretation you > > > > describe under #1, then I'm okay with having an MTI for each class. > > > > What that says to me is that each implementer would need to conform > > > > to the SCI draft's class placement of each namespace, but not > > > > necessarily have to be able to interpret the contents of said > > > > namespace(s). So all I have to do, minimally, is recognize the clas= s > > > > under which any of the referenced namespaces exist; > > > I don't have to have any means to parse or handle that class content > > > other than bucket it and move on to the next. Is that right? > > > > > > > > I would recommend that we be very clear in regards to what "support= " > > > > or "minimally support" mean so that technical requirements handed > > > > down based on this draft do not bar achievement by operational > > implementers and their engineering teams. > > > > > > > > Thanks again, > > > > > > > > - Tom Millar, US-CERT > > > > > > > > thomas.millar@us-cert.gov > > > > BB: thomas.millar@dhs.gov / 202-631-1915 > > > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > > > > > -----Original Message----- > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > Behalf > > > > Of Takeshi Takahashi > > > > Sent: Monday, February 20, 2012 20:40 > > > > To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; > > > > trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > > > > Cc: mile@ietf.org > > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > > SCI > > > > (wasRe: MTI SCI?) > > > > > > > > Hello all, > > > > > > > > Thank you for your kind comments, which are really useful for me. > > > > On the other hand, I have some difficulties to understand what peop= le > > specifically mean by "support" > > > > or "mandatory". > > > > I would appreciate if you could kindly give me some comments on bel= ow. > > > > > > > > Below are my views on the MTI issues. > > > > > > > > 1. All the specification namespaces listed in the table MUST be > > > > "supported" as values for the SpecID field. > > > > > > > > These namespaces are the allowed ENUM values. > > > > So, in a way, all the specification listed in the table are support= ed. > > > > (implementations must allow these namespaces of all the > > > > specifications listed in the table as values for SpecID field) Sinc= e > > > > all the specification listed in the table are supported, we need to > > > > have expert review before registration (as we discussed in Quebec > > > > City) > > > > > > > > In this way, receivers can correctly understand the data. > > > > That will give us the same level of interoperability as the RFC 507= 0 > > > > (IODEF) does between sender and receiver, I think. > > > > > > > > > > > > 2. Implementers have freedom to define how to parse, how to > > understand, > > > > and how to respond the IODEF extension message > > > > > > > > I might be wrong, but I do not think we would like to define how to > > > > parse the IODEF extension message at the receiver side. > > > > And I do not think we would like to define how to parse, for > > > > instance, CAPEC data, at the receiver side. > > > > I think the SCI draft is a container that conveys these structured > > > > information, and it can see such information as a blackbox with a > > tag (namespace information). > > > > > > > > If above understanding is correct, I have some difficulty to > > > > understand the meaning of "mandatory to support CVE". > > > > As described in issue 1 above, if CVE or CAPEC data is attached, th= e > > > > implementation needs to recognize that the data is in CVE/CAPEC > > > > format, and that is the requirement > > > for the implementation. > > > > What else do we want to mandate here, specifically? > > > > Do we need to manipulate the embedded xml data itself? I rather > > > > prefer to handle the data as a blackbox. > > > > > > > > I appreciate your kind comments. > > > > Regarding the other point Dave kindly pointed out, let me have > > > > another thread. (sorry I need to get on board now...) > > > > > > > > Thank you. > > > > > > > > Take > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > > > > Sent: Monday, February 20, 2012 8:08 PM > > > > To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > > > takeshi_takahashi@nict.go.jp > > > > Cc: mile@ietf.org > > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for > > > > SCI (was > > > > Re: MTI SCI?) > > > > > > > > Thank you, Dave. > > > > > > > > Dave raises a few very important points as we consider MTI for SCI. > > > > We will need to resolve these issues if CVE is to be the (or an) MT= I > > > > specification for the SCI > > > draft. > > > > > > > > If CVE is mandatory to implement, what guidance would be followed > > on > > > > how to use the model or will MTI only mean that the document can be > > received and > > > > parsed? The CVE website is listed as the specification URI, but > > from > > > > Dave's message, the specification URI does not exist to provide the > > > > guidance (I get to broken link pages for both - the existing and > > suggested replacement link). > > > > > > > > This is the closest I could find and may be the answer for guidance= : > > > > http://cve.mitre.org/compatible/requirements.html > > > > > > > > It looks like the reference to the target namespace needs to be fix= ed > > as well. > > > > > > > > Thank you, > > > > Kathleen > > > > ________________________________________ > > > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > > Waltermire, David A. > > > > [david.waltermire@nist.gov] > > > > Sent: Thursday, February 16, 2012 5:26 PM > > > > To: Brian Trammell; Takeshi Takahashi > > > > Cc: mile@ietf.org > > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > > SCI (was > > > > Re: MTI SCI?) > > > > > > > > I have not been following this thread as closely as I probably shou= ld. > > > > Relative to MTI, is the question what schema should be MTI for the > > > > vulerability class? In general I think we should have one or more > > MTI for each class. > > > > > > > > Relative to CVE specifically, are we talking about the schema > currently > > located at: > > > > http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > > > > > > > This seems to match the namespace defined in section 4.1.7 of > > mile-sci-02. > > > > Looking at the implementation of this schema, it looks like the > > > > targetNamespace is incorrectly assigned to > > > > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it > > > > should be > > > "http://cve.mitre.org/cve/downloads/1.0". This will likely need to > > be fixed. > > > > > > > > Also, the specification URI points to the CVE website, which is not > > > > really a specification. It's not clear where to find guidance on > > > > how to properly use the model indicated by the namespace. Without > > > > having clear guidance on its use I don't see how we can make it MTI= , > > > > even if it is considered a de facto approach. It might make sense > > > > to produce a specification for the model > > > before making it MTI for the vulnerability class. > > > > > > > > Sincerely, > > > > David Waltermire > > > > > > > > > -----Original Message----- > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > > Behalf Of Brian Trammell > > > > > Sent: Wednesday, February 15, 2012 5:28 AM > > > > > To: Takeshi Takahashi > > > > > Cc: mile@ietf.org > > > > > Subject: [mile] Discussion / consensus call on CVE as MTI for SCI > > > > > (was > > > > > Re: MTI SCI?) > > > > > > > > > > Hi, Take, all, > > > > > > > > > > Thank you for this edit/clarification. > > > > > > > > > > On the first point, it does seem the discussion on the list > > > > > converged rather quickly to CVE as MTI. However, as this is a > > > > > rather important point, I'd like to make sure we didn't miss > anything. > > > > > > > > > > So, I'd like to call for consensus on the list. Does the working > > > > > group agree on the following two points? > > > > > > > > > > 1. mile-sci requires one Mandatory to Implement schema in order > > to > > > > > ensure interoperability. > > > > > > > > > > 2. The Mandatory to Implement schema is the Common Vulnerability > > > > > Enumeration (CVE) version 1.0, as described in section 4.1.7 of > > > > > mile- sci-02. > > > > > > > > > > Please note if you agree; if you disagree, please explain why not= . > > > > > > > > > > Best regards, > > > > > > > > > > Brian (as chair) > > > > > > > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > > > > > > > Hello all, > > > > > > > > > > > > Following the discussion, I would like to add a couple of > > > > > > sentences > > > > > to > > > > > > clarify the MTI issues. > > > > > > (Thank you very much for those of you who kindly provided usefu= l > > > > > > discussion.) > > > > > > I've attached the working version of the draft. I hope it helps > > > > > > to clarify the changes. > > > > > > > > > > > > (added sentences at the end of section 4.1) > > > > > > > > > > > > The SpecID attributes of extended classes (Section 4.3) must > > allow > > > > > > the values of the specifications' namespace fields, but > > otherwise, > > > > > > implementations are not required to support all the above > > > > > > specifications. Implementations may choose which > > specifications to > > > > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > > > > supported. In case an implementation received a data it does > > not > > > > > > support, it may expand its functionality by looking up the > > > > > > IANA > > > > > table or > > > > > > notify the sender of its inability to parse the data by using > > any > > > > > > means defined outside the scope of this specification. > > > > > > > > > > > > On the other hand, I would like to add "STRING ext-SpecID" to > > > > > > each class, which enables to embed data following private schem= a. > > > > > > For instance, one security operation center (SOC) may wish to > > > > > exchange > > > > > > a vulnerability data that is formatted in its own private > > > > > > schema, and that is not formatted in CVE. > > > > > > In this case, the SOC may put the data's schema ID inside > > > > > > ext-SpecID and then embed the data. > > > > > > It could also be used to exchange data using beta version of > > > > > specifications. > > > > > > > > > > > > The class could be seen as below. > > > > > > > > > > > > +------------------------+ > > > > > > | AttackPattern | > > > > > > +------------------------+ > > > > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > > > > +------------------------+ > > > > > > > > > > > > SpecID: REQUIRED. ENUM. The identifier of the specificatio= n > > > > > > specifying the format of the RawData element. The value > > > > > > should > > > > > be > > > > > > chosen from the namespaces [XMLNames] listed in Section 4.= 1 > > or > > > > > > "private". Note that the lists in Section 4.1 will be > > developed > > > > > > further by IANA. The value "private" is prepared for > conveying > > > > > > RawData based on a format that is not listed in the > > > > > > table. This is usually used for conveying data formatted > > > > > > according to an organization's private schema. When the > > value > > > > > > "private" is used, ext-SpecID element needs to be used. > > > > > > > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > > > > specification > > > > > > specifying the format of the RawData element. When this > > element > > > > > > is used, the value of SpecID element must be "private." > > > > > > > > > > > > I hope above changes don't cause any complication here. > > > > > > > > > > > > Sincerely, > > > > > > Take > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > > >> Behalf Of Martin, Robert A. > > > > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > > > > >> To: Kent_Landfield@McAfee.com > > > > > >> Cc: mile@ietf.org > > > > > >> Subject: Re: [mile] MTI SCI? > > > > > >> > > > > > >> At the risk of contradicting myself - but then again I have no= w > > > > > >> read the other replies to this issue - I agree that having one > > > > > >> area be > > > > > the > > > > > >> smoke test makes sense and I also agree that something simple > > > > > >> and commonly used already - like CVE - is the best candidate > > > > > >> for what we > > > > > need. > > > > > >> > > > > > >> Bob > > > > > >> > > > > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > > > > >>> CVE is widely used and understood by all in the the security > > > > > community. > > > > > >> I agree with Tom that CVE is the path of least resistance but > > > > > >> may be the most useful for basic interoperability. > > > > > >>> > > > > > >>> Kent Landfield > > > > > >>> Director Content Strategy, Architecture and Standards > > > > > >>> > > > > > >>> McAfee | An Intel Company > > > > > >>> 5000 Headquarters Dr. > > > > > >>> Plano, Texas 75024 > > > > > >>> > > > > > >>> Direct: +1.972.963.7096 > > > > > >>> Mobile: +1.817.637.8026 > > > > > >>> Web: www.mcafee.com > > > > > >>> > > > > > >>> From: > > > > > >>> > > > > > >> > > "Thomas.Millar@us-cert.gov" > > > > >> ho > > > > > >> ma > > > > > >> s > > > > > >> .M > > > > > >>> illar@us-cert.gov> > > > > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > > > > >>> To: > > > > > >>> > > > > > >> > > "david.black@emc.com" > > > > >> mc > > > > > >> .c > > > > > >> o > > > > > >> m< > > > > > >>> mailto:david.black@emc.com>>, Bob > > > > > >>> Martin> > > > > > >>> Cc: > > > > > >>> > > > > > >> > > "mile@ietf.org" > > > > >> @i > > > > > >> et > > > > > >> f > > > > > >> .o > > > > > >>> rg>> > > > > > >>> Subject: Re: [mile] MTI SCI? > > > > > >>> > > > > > >>> My concern with CAPEC being mandatory is that it could > > > > > >>> discourage > > > > > >> effective operational uptake of IODEF-SCI as the CAPEC > > > > > >> vocabulary remains "too comprehensive" for many CSIRTs to > > > > > >> employ during > > > > > incident > > > > > >> handling and reporting activity. > > > > > >>> > > > > > >>> IODEF by itself has been criticized by CSIRT operators for > > > > > >>> being more > > > > > >> heavyweight than necessary for day-to-day usage; making CAPEC > > a > > > > > >> mandatory aspect of "advanced IODEF" seems like it would be > > > > > >> adding ammunition to that argument, especially if the CSIRT is > > > > > >> having to fund implementation out of their own pocket. > > > > > >> Personally, I would > > > > > have > > > > > >> a hard time asking US-CERT's primary constituents to implement > > > > > >> IODEF > > > > > >> + CAPEC if they are already balking at the consultant and > > > > > >> + developer > > > > > >> resources required to implement RFC 5070 by itself. Also keep > > > > > >> in > > > > > mind > > > > > >> that CAPEC references CybOX, so there's wheels within wheels > > now. > > > > > >>> > > > > > >>> I would prefer we take the path of least resistance (from my > > > > > > perspective) > > > > > >> and make CVE the MTI, if we have to pick one additional spec. > > > > > >>> CVE is well known, has years of familiarity built in, and I > > > > > >>> think it's > > > > > >> the simplest schema of the bunch. > > > > > >>> > > > > > >>> > > > > > >>> - Tom Millar, US-CERT > > > > > >>> > > > > > >>> thomas.millar@us-cert.gov > > > > > >>> BB: thomas.millar@dhs.gov / > > > > > >>> 202-631-1915 > > > > > >>> 24x7: soc@us-cert.gov / 888-282-0870 > > > > > >>> > > > > > >>> -----Original Message----- > > > > > >>> From: mile-bounces@ietf.org > > > > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > > > > >>> david.black@emc.com > > > > > >>> Sent: Tuesday, February 14, 2012 11:14 > > > > > >>> To: ramartin@mitre.org > > > > > >>> Cc: mile@ietf.org > > > > > >>> Subject: Re: [mile] MTI SCI? > > > > > >>> > > > > > >>> Hi Bob, > > > > > >>> > > > > > >>> I do appreciate the concern about implementing things that > > > > > >>> aren't going > > > > > >> to be used. OTOH, it may be useful to have a single simple MT= I > > > > > >> spec for SCI that can be used to "smoke test" a deployment > > > > > >> before trying any > > > > > > serious > > > > > >> test data (and "simple" is important). > > > > > >>> > > > > > >>> In addition, a concern that I would have with an MTI SCI spec > > > > > >>> per class > > > > > >> is that if two SCI implementations don't have at least one > > > > > >> class in > > > > > > common, > > > > > >> they aren't going to interoperate, and that situation is > > > > > >> unlikely to be acceptable to the IESG (i.e., with an MTI SCI > > > > > >> spec per class, I suspect that there will also have to be an > > > > > >> MTI class, which results in an overall MTI SCI spec). > > > > > >>> > > > > > >>> It may also be useful to include a simple example of the MTI > > > > > >>> SCI spec > > > > > >> in an appendix to simplify "smoke testing" (e.g., if the MTI > > > > > >> SCI > > > > > spec > > > > > >> is CAPEC, as Youki suggested, the appendix could contain a > > > > > >> CAPEC XML document for testing purposes, including enumeration > > > > > >> values suitable for testing). > > > > > >>> > > > > > >>> What do you (and others) think about this? > > > > > >>> > > > > > >>> Thanks, > > > > > >>> --David > > > > > >>> > > > > > >>> -----Original Message----- > > > > > >>> From: mile-bounces@ietf.org > > > > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert A. > > > > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > > > > >>> To: Brian Trammell > > > > > >>> Cc: mile@ietf.org > > > > > >>> Subject: Re: [mile] MTI SCI? > > > > > >>> Brian, > > > > > >>> You beat me to this point. Like you, I would be concerned > > > > > >>> about a MTI selection that ended up requiring someone to > > > > > >>> implement > > > > > something > > > > > >>> to meet the MTI but wasn't germane to anything else they > > > > > >>> intended > > > > > to > > > > > >> support. > > > > > >>> Bob > > > > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > > > > >>>> Hi, Sean, all, > > > > > >>>> > > > > > >>>> Looking over the spec, it's not clear to me that one MTI > > > > > >>>> makes sense here, given that mile-sci's > > > > > >>> purpose is to reference a set of external specifications by > > > > > >>> inclusion in an IODEF document, and that those external > > > > > >>> specifications represent > > > > > >> fundamentally different things. > > > > > >>>> > > > > > >>>> The specifications are split over their applicability to the > > > > > >>>> IODEF extension classes. I could > > > > > >>> envision an mile-sci implementation that was only interested > > a > > > > > >>> subset of these classes (perhaps even only one). If my > > > > > >>> implementation has an internal representation of Verification= , > > > > > >>> but not of any of the other classes, and the MTI is an > > > > > >>> enumeration that is applicable to > > > > > >> Vulnerability... what do I do? > > > > > >>>> > > > > > >>>> What about selecting an MTI per class, instead? > > > > > >>>> > > > > > >>>> Best regards, > > > > > >>>> > > > > > >>>> Brian (as contributor) > > > > > >>>> > > > > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > > > >>>> > > > > > >>>>> Great - as long as we pick one as the MTI. Note that MTI > > is > > > > > >>>>> not > > > > > >> necessarily mandatory to use. > > > > > >>>>> > > > > > >>>>> spt > > > > > >>>>> > > > > > >>>>> On 2/13/12 7:11 PM, > > > > > >> kathleen.moriarty@emc.com > > wrote: > > > > > >>>>>> Thank you for raising the interoperability testing as we > > > > > >>>>>> need to plan for a bake-off that once > > > > > >>> these questions get answered and the draft is ready. > > > > > >>>>>> > > > > > >>>>>> Thanks, > > > > > >>>>>> Kathleen > > > > > >>>>>> > > > > > >>>>>> -----Original Message----- > > > > > >>>>>> From: mile-bounces@ietf.org > > > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > > > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > > > > >>>>>> To: mile@ietf.org > > > > > >>>>>> Subject: [mile] MTI SCI? > > > > > >>>>>> > > > > > >>>>>> There's 17 listed SCI (Structured Cybersecurity > > > > > >>>>>> Information) specifications in draft-ietf-mile-sci. Which > > > > > >>>>>> one is the MTI (mandatory to implement) choice? In other > > > > > >>>>>> words, how will you get two interoperability implementatio= ns > > without picking one? > > > > > >>>>>> > > > > > >>>>>> spt > > > > > >>>>>> _______________________________________________ > > > > > >>>>>> mile mailing list > > > > > >>>>>> mile@ietf.org > > > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>> _______________________________________________ > > > > > >>>>> mile mailing list > > > > > >>>>> mile@ietf.org > > > > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > > > > >>>> > > > > > >>>> _______________________________________________ > > > > > >>>> mile mailing list > > > > > >>>> mile@ietf.org > > > > > >>>> https://www.ietf.org/mailman/listinfo/mile > > > > > >>>> . > > > > > >>>> > > > > > >>> _______________________________________________ > > > > > >>> mile mailing list > > > > > >>> mile@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> mile mailing list > > > > > >>> mile@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > > >>> _______________________________________________ > > > > > >>> mile mailing list > > > > > >>> mile@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > > >>> > > > > > >>> > > > > > >> _______________________________________________ > > > > > >> mile mailing list > > > > > >> mile@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > ci > > > > > > - > > > > > 03c > > > > > > > > > > > > > andidate_20120215.txt.pdf>________________________________________ > > > > > __ > > > > > __ > > > > > > ___ > > > > > > mile mailing list > > > > > > mile@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > _______________________________________________ > > > > > mile mailing list > > > > > mile@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > > > mile mailing list > > > > mile@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mile mailing list > > > > mile@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > > > mile mailing list > > > > mile@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > > > From bakerj@mitre.org Thu Feb 23 07:25:06 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A853A21F85C4 for ; Thu, 23 Feb 2012 07:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] 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 Z1WF-pu223XF for ; Thu, 23 Feb 2012 07:25:05 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6F04821F87F8 for ; Thu, 23 Feb 2012 07:25:05 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A736F21B13F0 for ; Thu, 23 Feb 2012 10:25:04 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8165F21B036E for ; Thu, 23 Feb 2012 10:25:04 -0500 (EST) Received: from IMCMBX03.MITRE.ORG ([169.254.3.50]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Thu, 23 Feb 2012 10:25:04 -0500 From: "Baker, Jon" To: "mile@ietf.org" Thread-Topic: corrections to the SCI XML Schema Thread-Index: AczyP09M08u1Cr3sSHmfDkVzrb2YFw== Date: Thu, 23 Feb 2012 15:25:03 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D386513499120@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/mixed; boundary="_002_6C1C15D8B5510B4B8FF132B10D386513499120IMCMBX03MITREORG_" MIME-Version: 1.0 Subject: [mile] corrections to the SCI XML Schema X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:25:06 -0000 --_002_6C1C15D8B5510B4B8FF132B10D386513499120IMCMBX03MITREORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Earlier this week I was working with the SCI XML Schema and noticed a few e= rrors.=20 First, in numerous places xsd:elements are declared using an element refere= nce and also specifying an element name as follows: When declaring an xsd:element by a reference to another previously defined = element, a @name cannot be specified. The correct definition should look li= ke: Second, in the definition of the "XMLDATA" complex type the "dtype" attribu= te was improperly declared as follows: I believe that the intent was to set the value of the attribute to always b= e "xml" the proper way to do this is to use the @fixed attribute. A @value = attribute is not defined on the xsd:attribute element. This type is defined= as being a restriction on the iodef:ExtensionType and therefore it cannot = have a @use attribute value other than "required". The attribute is defined= and required in the base type. The correct declaration follows: The attached .xsd has been revised to address these issues.=20 Thanks, Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org --_002_6C1C15D8B5510B4B8FF132B10D386513499120IMCMBX03MITREORG_ Content-Type: text/xml; name="iodef-sci.xsd" Content-Description: iodef-sci.xsd Content-Disposition: attachment; filename="iodef-sci.xsd"; size=7761; creation-date="Fri, 17 Feb 2012 14:54:00 GMT"; modification-date="Tue, 21 Feb 2012 17:19:23 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCg0KPHhzZDpzY2hlbWEgdGFy Z2V0TmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXNjaS0xLjAiIHhtbG5z OnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOmlvZGVmPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCIgeG1sbnM6aW9kZWYtc2NpPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOmlvZGVmLXNjaS0xLjAiIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVk IiBhdHRyaWJ1dGVGb3JtRGVmYXVsdD0idW5xdWFsaWZpZWQiPg0KDQogIDx4c2Q6aW1wb3J0IG5h bWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiIHNjaGVtYUxvY2F0aW9u PSJpb2RlZl9zY2hlbWEueHNkIi8+DQoNCiAgPCEtLQ0KIHNjaGVtYUxvY2F0aW9uPSJ1cm46aWV0 ZjpwYXJhbXM6eG1sOnNjaGVtYTppb2RlZi0xLjAiLz4NCi0tPg0KDQogIDwhLS09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo9 PSBYTUxEQVRBICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA9PQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09LS0+DQoNCiAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJYTUxE QVRBIj4NCiAgICA8eHNkOmNvbXBsZXhDb250ZW50Pg0KICAgICAgPHhzZDpyZXN0cmljdGlvbiBi YXNlPSJpb2RlZjpFeHRlbnNpb25UeXBlIj4NCiAgICAgICAgPHhzZDpzZXF1ZW5jZT4NCiAgICAg ICAgICA8eHNkOmFueSBuYW1lc3BhY2U9IiMjYW55IiBwcm9jZXNzQ29udGVudHM9ImxheCIgbWlu T2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgICA8L3hzZDpzZXF1ZW5j ZT4NCiAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZHR5cGUiIHR5cGU9ImlvZGVmOmR0eXBl LXR5cGUiIHVzZT0icmVxdWlyZWQiIGZpeGVkPSJ4bWwiLz4NCiAgICAgICAgPHhzZDphdHRyaWJ1 dGUgbmFtZT0iZXh0LWR0eXBlIiB0eXBlPSJ4c2Q6c3RyaW5nIiB1c2U9Im9wdGlvbmFsIi8+DQog ICAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9Im1lYW5pbmciIHR5cGU9InhzZDpzdHJpbmciLz4N CiAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZm9ybWF0aWQiIHR5cGU9InhzZDpzdHJpbmci Lz4NCiAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0icmVzdHJpY3Rpb24iIHR5cGU9ImlvZGVm OnJlc3RyaWN0aW9uLXR5cGUiLz4NCiAgICAgIDwveHNkOnJlc3RyaWN0aW9uPg0KICAgIDwveHNk OmNvbXBsZXhDb250ZW50Pg0KICA8L3hzZDpjb21wbGV4VHlwZT4NCg0KDQogIDwhLS09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo9PSBTY29yaW5nIENsYXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA9PQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09LS0+DQoNCiAgPHhzZDplbGVtZW50IG5hbWU9IlNjb3Jp bmciPg0KICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgICA8eHNkOnNlcXVlbmNlPg0KICAgICAg ICA8eHNkOmVsZW1lbnQgbmFtZT0iU2NvcmVTZXQiIHR5cGU9ImlvZGVmLXNjaTpYTUxEQVRBIiBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICA8L3hzZDpzZXF1ZW5j ZT4NCiAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9IlNwZWNJRCIgdHlwZT0ieHNkOnN0cmluZyIg dXNlPSJyZXF1aXJlZCIvPg0KICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZXh0LVNwZWNJRCIg dHlwZT0ieHNkOnN0cmluZyIgdXNlPSJvcHRpb25hbCIvPg0KICAgIDwveHNkOmNvbXBsZXhUeXBl Pg0KICA8L3hzZDplbGVtZW50Pg0KDQogIDwhLS09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo9PSBBdHRhY2tQYXR0ZXJuIENs YXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9PQ0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09LS0+DQoNCiAgPHhzZDplbGVtZW50IG5hbWU9IkF0dGFja1BhdHRlcm4iPg0KICAgIDx4c2Q6 Y29tcGxleFR5cGU+DQogICAgICA8eHNkOnNlcXVlbmNlPg0KICAgICAgICA8eHNkOmVsZW1lbnQg bmFtZT0iUmF3RGF0YSIgdHlwZT0iaW9kZWYtc2NpOlhNTERBVEEiIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iaW9kZWY6UmVm ZXJlbmNlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICAgIDx4 c2Q6ZWxlbWVudCByZWY9ImlvZGVmLXNjaTpQbGF0Zm9ybSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9InVuYm91bmRlZCIvPg0KICAgICAgPC94c2Q6c2VxdWVuY2U+DQogICAgICA8eHNkOmF0dHJp YnV0ZSBuYW1lPSJTcGVjSUQiIHR5cGU9InhzZDpzdHJpbmciIHVzZT0icmVxdWlyZWQiLz4NCiAg ICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9ImV4dC1TcGVjSUQiIHR5cGU9InhzZDpzdHJpbmciIHVz ZT0ib3B0aW9uYWwiLz4NCiAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9IkF0dGFja1BhdHRlcm5J RCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJvcHRpb25hbCIvPg0KICAgIDwveHNkOmNvbXBsZXhU eXBlPg0KICA8L3hzZDplbGVtZW50Pg0KDQogIDwhLS09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo9PSBWdWxuZXJhYmlsaXR5 IENsYXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9PQ0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09LS0+DQoNCiAgPHhzZDplbGVtZW50IG5hbWU9IlZ1bG5lcmFiaWxpdHkiPg0KICAgIDx4 c2Q6Y29tcGxleFR5cGU+DQogICAgICA8eHNkOnNlcXVlbmNlPg0KICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0iUmF3RGF0YSIgdHlwZT0iaW9kZWYtc2NpOlhNTERBVEEiIG1pbk9jY3Vycz0iMCIg bWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iaW9kZWY6 UmVmZXJlbmNlIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICAg IDx4c2Q6ZWxlbWVudCByZWY9ImlvZGVmLXNjaTpQbGF0Zm9ybSIgbWluT2NjdXJzPSIwIiBtYXhP Y2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJpb2RlZi1zY2k6 U2NvcmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPC94 c2Q6c2VxdWVuY2U+DQogICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJTcGVjSUQiIHR5cGU9Inhz ZDpzdHJpbmciIHVzZT0icmVxdWlyZWQiLz4NCiAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9ImV4 dC1TcGVjSUQiIHR5cGU9InhzZDpzdHJpbmciIHVzZT0ib3B0aW9uYWwiLz4NCiAgICAgIDx4c2Q6 YXR0cmlidXRlIG5hbWU9IlZ1bG5lcmFiaWxpdHlJRCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJv cHRpb25hbCIvPg0KICAgIDwveHNkOmNvbXBsZXhUeXBlPg0KICA8L3hzZDplbGVtZW50Pg0KDQog IDwhLS09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KPT0gV2Vha25lc3MgQ2xhc3MgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgID09DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0tLT4NCg0KICA8eHNkOmVsZW1l bnQgbmFtZT0iV2Vha25lc3MiPg0KICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgICA8eHNkOnNl cXVlbmNlPg0KICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iUmF3RGF0YSIgdHlwZT0iaW9kZWYt c2NpOlhNTERBVEEiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAg ICAgPHhzZDplbGVtZW50IHJlZj0iaW9kZWY6UmVmZXJlbmNlIiBtaW5PY2N1cnM9IjAiIG1heE9j Y3Vycz0idW5ib3VuZGVkIi8+DQogICAgICAgIDx4c2Q6ZWxlbWVudCByZWY9ImlvZGVmLXNjaTpQ bGF0Zm9ybSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgICA8 eHNkOmVsZW1lbnQgcmVmPSJpb2RlZi1zY2k6U2NvcmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9InVuYm91bmRlZCIvPg0KICAgICAgPC94c2Q6c2VxdWVuY2U+DQogICAgICA8eHNkOmF0dHJp YnV0ZSBuYW1lPSJTcGVjSUQiIHR5cGU9InhzZDpzdHJpbmciIHVzZT0icmVxdWlyZWQiLz4NCiAg ICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9ImV4dC1TcGVjSUQiIHR5cGU9InhzZDpzdHJpbmciIHVz ZT0ib3B0aW9uYWwiLz4NCiAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9IldlYWtuZXNzSUQiIHR5 cGU9InhzZDpzdHJpbmciIHVzZT0ib3B0aW9uYWwiLz4NCiAgICA8L3hzZDpjb21wbGV4VHlwZT4N CiAgPC94c2Q6ZWxlbWVudD4NCg0KICA8IS0tPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj09IFBsYXRmb3JtIENsYXNzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT0NCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PS0tPg0KDQogIDx4c2Q6ZWxlbWVudCBuYW1lPSJQbGF0Zm9ybSI+DQogICAgPHhzZDpjb21wbGV4 VHlwZT4NCiAgICAgIDx4c2Q6c2VxdWVuY2U+DQogICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJS YXdEYXRhIiB0eXBlPSJpb2RlZi1zY2k6WE1MREFUQSIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9 InVuYm91bmRlZCIvPg0KICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJpb2RlZjpSZWZlcmVuY2Ui IG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgIDwveHNkOnNlcXVl bmNlPg0KICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iU3BlY0lEIiB0eXBlPSJ4c2Q6c3RyaW5n IiB1c2U9InJlcXVpcmVkIi8+DQogICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJleHQtU3BlY0lE IiB0eXBlPSJ4c2Q6c3RyaW5nIiB1c2U9Im9wdGlvbmFsIi8+DQogICAgICA8eHNkOmF0dHJpYnV0 ZSBuYW1lPSJQbGF0Zm9ybUlEIiB0eXBlPSJ4c2Q6c3RyaW5nIiB1c2U9Im9wdGlvbmFsIi8+DQog ICAgPC94c2Q6Y29tcGxleFR5cGU+DQogIDwveHNkOmVsZW1lbnQ+DQoNCiAgPCEtLT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cj09IEV2ZW50UmVwb3J0IENsYXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID09DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PS0tPg0KDQogIDx4c2Q6ZWxlbWVudCBuYW1lPSJFdmVudFJl cG9ydCI+DQogICAgPHhzZDpjb21wbGV4VHlwZT4NCiAgICAgIDx4c2Q6c2VxdWVuY2U+DQogICAg ICAgIDx4c2Q6Y2hvaWNlPg0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJSYXdEYXRhIiB0 eXBlPSJpb2RlZi1zY2k6WE1MREFUQSIvPg0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCByZWY9Imlv ZGVmOlJlZmVyZW5jZSIvPg0KICAgICAgICA8L3hzZDpjaG9pY2U+DQogICAgICA8L3hzZDpzZXF1 ZW5jZT4NCiAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9IlNwZWNJRCIgdHlwZT0ieHNkOnN0cmlu ZyIgdXNlPSJyZXF1aXJlZCIvPg0KICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZXh0LVNwZWNJ RCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJvcHRpb25hbCIvPg0KICAgICAgPHhzZDphdHRyaWJ1 dGUgbmFtZT0iRXZlbnRJRCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJvcHRpb25hbCIvPg0KICAg IDwveHNkOmNvbXBsZXhUeXBlPg0KICA8L3hzZDplbGVtZW50Pg0KDQogIDwhLS09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo9 PSBWZXJpZmljYXRpb24gQ2xhc3MgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA9PQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0tLT4NCg0KICA8eHNkOmVsZW1lbnQgbmFtZT0iVmVyaWZpY2F0 aW9uIj4NCiAgICA8eHNkOmNvbXBsZXhUeXBlPg0KICAgICAgPHhzZDpzZXF1ZW5jZT4NCiAgICAg ICAgPHhzZDpjaG9pY2U+DQogICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IlJhd0RhdGEiIHR5 cGU9ImlvZGVmLXNjaTpYTUxEQVRBIi8+DQogICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iaW9k ZWY6UmVmZXJlbmNlIi8+DQogICAgICAgIDwveHNkOmNob2ljZT4NCiAgICAgIDwveHNkOnNlcXVl bmNlPg0KICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iU3BlY0lEIiB0eXBlPSJ4c2Q6c3RyaW5n IiB1c2U9InJlcXVpcmVkIi8+DQogICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJleHQtU3BlY0lE IiB0eXBlPSJ4c2Q6c3RyaW5nIiB1c2U9Im9wdGlvbmFsIi8+DQogICAgICA8eHNkOmF0dHJpYnV0 ZSBuYW1lPSJWZXJpZmljYXRpb25JRCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJvcHRpb25hbCIv Pg0KICAgIDwveHNkOmNvbXBsZXhUeXBlPg0KICA8L3hzZDplbGVtZW50Pg0KDQogIDwhLS09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQo9PSBSZW1lZGlhdGlvbiBDbGFzcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA9PQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0tLT4NCg0KICA8eHNkOmVsZW1lbnQgbmFtZT0iUmVt ZWRpYXRpb24iPg0KICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgICA8eHNkOnNlcXVlbmNlPg0K ICAgICAgICA8eHNkOmNob2ljZT4NCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iUmF3RGF0 YSIgdHlwZT0iaW9kZWYtc2NpOlhNTERBVEEiLz4NCiAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVm PSJpb2RlZjpSZWZlcmVuY2UiLz4NCiAgICAgICAgPC94c2Q6Y2hvaWNlPg0KICAgICAgPC94c2Q6 c2VxdWVuY2U+DQogICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJTcGVjSUQiIHR5cGU9InhzZDpz dHJpbmciIHVzZT0icmVxdWlyZWQiLz4NCiAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9ImV4dC1T cGVjSUQiIHR5cGU9InhzZDpzdHJpbmciIHVzZT0ib3B0aW9uYWwiLz4NCiAgICAgIDx4c2Q6YXR0 cmlidXRlIG5hbWU9IlJlbWVkaWF0aW9uSUQiIHR5cGU9InhzZDpzdHJpbmciIHVzZT0ib3B0aW9u YWwiLz4NCiAgICA8L3hzZDpjb21wbGV4VHlwZT4NCiAgPC94c2Q6ZWxlbWVudD4NCg0KPC94c2Q6 c2NoZW1hPg0K --_002_6C1C15D8B5510B4B8FF132B10D386513499120IMCMBX03MITREORG_-- From takeshi_takahashi@nict.go.jp Thu Feb 23 08:03:45 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7107021F87F7 for ; Thu, 23 Feb 2012 08:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_39=0.6] 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 fM1ZWft6PdZ9 for ; Thu, 23 Feb 2012 08:03:44 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 403CC21F87E0 for ; Thu, 23 Feb 2012 08:03:44 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q1NG3grA006710; Fri, 24 Feb 2012 01:03:42 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q1NG3gW4000111; Fri, 24 Feb 2012 01:03:42 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id q1NG3ec5000108; Fri, 24 Feb 2012 01:03:41 +0900 (JST) From: "Takeshi Takahashi" To: "'Baker, Jon'" , References: <6C1C15D8B5510B4B8FF132B10D386513499120@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D386513499120@IMCMBX03.MITRE.ORG> Date: Fri, 24 Feb 2012 01:03:27 +0900 Message-ID: <3d9c01ccf244$af1245d0$0d36d170$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJAyTqG7O+zDgAnDppxvdLf4MlsZZVi8DWg Content-Language: ja Subject: Re: [mile] corrections to the SCI XML Schema X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:03:45 -0000 Hi Jon, I really appreciate your kind assistance onlne and offline. Thank you very much. I will reflect these changes to the next version of the SCI draft. Thank you. Take > -----Original Message----- > From: Baker, Jon [mailto:bakerj@mitre.org] > Sent: Friday, February 24, 2012 12:25 AM > To: mile@ietf.org > Subject: [mile] corrections to the SCI XML Schema > > Earlier this week I was working with the SCI XML Schema and noticed a > few errors. > > First, in numerous places xsd:elements are declared using an element > reference and also specifying an element name as follows: > maxOccurs="unbounded"/> > > When declaring an xsd:element by a reference to another previously defined > element, a @name cannot be specified. The correct definition should look > like: > maxOccurs="unbounded"/> > > Second, in the definition of the "XMLDATA" complex type the "dtype" > attribute was improperly declared as follows: > value="xml"/> > > I believe that the intent was to set the value of the attribute to always > be "xml" the proper way to do this is to use the @fixed attribute. A @value > attribute is not defined on the xsd:attribute element. This type is > defined as being a restriction on the iodef:ExtensionType and therefore > it cannot have a @use attribute value other than "required". The attribute > is defined and required in the base type. The correct declaration follows: > fixed="xml"/> > > The attached .xsd has been revised to address these issues. > > Thanks, > > Jon > > ============================================ > Jonathan O. Baker > G022 - IA Industry Collaboration > The MITRE Corporation > Email: bakerj@mitre.org > From takeshi_takahashi@nict.go.jp Thu Feb 23 08:06:15 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6937521F87E3 for ; Thu, 23 Feb 2012 08:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 WNnlf2SR59mx for ; Thu, 23 Feb 2012 08:06:11 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E9821F87A1 for ; Thu, 23 Feb 2012 08:06:10 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q1NG66xj006919; Fri, 24 Feb 2012 01:06:06 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q1NG65D0000561; Fri, 24 Feb 2012 01:06:05 +0900 (JST) Received: from takeVAIO2 (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id q1NG61Ri000558; Fri, 24 Feb 2012 01:06:02 +0900 (JST) From: "Takeshi Takahashi" To: , References: <4F3A909F.7060502@mitre.org><004101ccebc2$61941820$24bc4860$@nict.go.jp>, <04dc01ccf039$cb51ce80$61f56b80$@googlemail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF8C4@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEF9FE@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEFC68@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEAEFC68@MX14A.corp.emc.com> Date: Fri, 24 Feb 2012 01:05:48 +0900 Message-ID: <3d9d01ccf245$037fe3c0$0a7fab40$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVcL45eZgWLqp/l4iy6Arf2hRFJQJbsSjeAri4SakBVRcBygLXQOLuAaalRtQCXe3+vgHTO+ibAQ/JkYkBN9mkQwEgvGD1ANzP73oBYAd0QZUTudBA Content-Language: ja Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:06:15 -0000 Hi David and all, I agree with the one you kindly proposed. I appreciate that. Thank you. Take > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Thursday, February 23, 2012 4:39 AM > To: takeshi_takahashi@nict.go.jp; mile@ietf.org > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > (was Re: MTI SCI?) > > Hi Take, > > > I think the receiver needs to be capable of validating received CVE > > XML for the smoke test purpose, but I am not sure whether we should > > mandate the validation process to the receiver. > > I think you have a point. In more detail, while discussing > mandatory-to-implement requirements, we have gotten into discussing > whether schema validation should not only be mandatory-to-implement, but > also whether it should be mandatory-to-use (a different, but related, > concept) when the SpecID is used. > > I suggest that validation that XML content is well-formed with respect > to its schema is a good idea, so I think something stronger than "be capable > of" > is appropriate. OTOH, I can conceive of reasons to bypass validation > (e.g., the schema validation is always failing, so as a step towards > finding the problem, turn off validation in order to take a look at the > actual XML that arrived, which should indicate whether the problem is > at the sender vs. the receiver). > > In light of that, here's a possible rewrite of my two sentences (they > are now three sentences in order to separate implementation and usage > requirements): > > 1. The CVE SpecID value and related values (e.g., namespace) MUST be > implemented (implementation is capable of sending and receiving > well-formed CVE 1.0 XML documents without error). > 2. The receiver MUST implement validation of received CVE 1.0 XML > documents against the CVE 1.0 XML schema in order to detect > invalid CVE documents. > 3. The receiver SHOULD validate all received CVE 1.0 XML documents > as described in item #2. > > What do you think of this? > > Thanks, > --David > > > -----Original Message----- > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > Sent: Wednesday, February 22, 2012 1:06 PM > > To: Black, David; Thomas.Millar@us-cert.gov; mile@ietf.org > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI > > (was Re: MTI SCI?) > > > > I'm generally in favor of the kind opinions from Tom and David. > > IMHO, the sentence David kindly provided could be changed as below: > > > > In order to be compliant with SCI draft, the implementations need to > > suffice > > below: > > > > 1. The CVE SpecID value and related values (e.g., namespace) MUST be > > supported (not cause errors if used). > > 2. Recipient MUST "be capable of" validating received CVE 1.0 XML > > document against the CVE 1.0 XML schema to detect invalid CVE documents. > > > > I think the receiver needs to be capable of validating received CVE > > XML for the smoke test purpose, but I am not sure whether we should > > mandate the validation process to the receiver. > > When operation processes are automated, validation process could be > > implemented elsewhere (for instance, data generation unit could do the > > validation). > > So, I think the SCI draft could mandates the capability, instead of > > the process. > > > > Does it make sense? > > > > Thank you. > > Take > > > > > -----Original Message----- > > > From: david.black@emc.com [mailto:david.black@emc.com] > > > Sent: Wednesday, February 22, 2012 8:47 AM > > > To: Thomas.Millar@us-cert.gov; mile@ietf.org > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for > > > SCI (was Re: MTI SCI?) > > > > > > A "smoke test" is one of the motivations for this MTI requirement > - > > > for that, validation of the received content (e.g., against an XML > > > schema for XML content) should be required, as one usually wants to > > > know that the "smoke" made it through ok (the "smoke" that arrived > > > matches what was sent). > > > > > > So, even if the content will only be used as "smoke test" evidence, > > > and not otherwise interpreted, it's still a good idea to require > > > format validation. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Thomas.Millar@us-cert.gov > [mailto:Thomas.Millar@us-cert.gov] > > > > Sent: Tuesday, February 21, 2012 4:18 PM > > > > To: Black, David; mile@ietf.org > > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for > > > > SCI > > > > (wasRe: MTI SCI?) > > > > > > > > Should a recipient be required to validate a referenced schema > > > > even > > > if > > > > they don't intend to interpret the content? > > > > > > > > - Tom Millar, US-CERT > > > > > > > > thomas.millar@us-cert.gov > > > > BB: thomas.millar@dhs.gov / 202-631-1915 > > > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > > > > > -----Original Message----- > > > > From: david.black@emc.com [mailto:david.black@emc.com] > > > > Sent: Tuesday, February 21, 2012 12:49 > > > > To: mile@ietf.org; Millar, Thomas R > > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for > > > > SCI > > > > (wasRe: MTI SCI?) > > > > > > > > Hi Tom, > > > > > > > > I believe I agree with you, although I'd like to add some > > > > precision > > > on what is meant by "parse". > > > > > > > > I don't think it's sufficient to support the value in the SpecID > > > > field (e.g., a CVE > > > > version) and accept an XML blob that is not a well-formed CVE XML > > > document. > > > > > > > > Hence, I think the minimum requirement is to validate the received > > > > SCI XML document against the appropriate XML schema and detect any > errors. > > > > > > > > Beyond that, Take's reference to RFC 5070 is a useful source of > > > > insight, as I think it rules out most additional requirements. > > > > IODEF > > > is a format, not a protocol, so: > > > > > > > > A) Error reporting is specific to whatever transport > > > > protocol > > > is being used. > > > > For example, if RID is used, the rfc6046-bis draft > > > specifies how to > > > > report errors, but there's no RFC 5070 requirement > > > > that > > > IODEF use RID. > > > > Beyond error detection, it's not possible to > > > > specify > > > a required error > > > > reporting mechanism. > > > > > > > > B) RFC 5070 has nothing to say about replies or responses > > > > to > > > IODEF, so the > > > > same should be true of extensions like SCI. > > > > > > > > C) I'm not sure I understand what Take had in mind by "how > > > > to > > > understand" in > > > > #2. I see no need to understand CVE semantics or > > > meaning beyond the CVE > > > > syntax check obtained by validating the received > > > document against the > > > > CVE XML schema. > > > > > > > > > I would recommend that we be very clear in regards to what "support" > > > > > or "minimally support" mean so that technical requirements > > > > > handed down based on this draft do not bar achievement by > > > > > operational > > > implementers and their engineering teams. > > > > > > > > I agree and would suggest: > > > > > > > > - The CVE SpecID value and related values (e.g., > > > > namespace) > > > MUST > > > > be supported (not cause errors if used). > > > > - Recipient MUST validate received CVE XML document > > > > against > > > the CVE > > > > XML schema to detect invalid CVE documents. > > > > > > > > I assume that this is all about CVE 1.0. > > > > > > > > Does all of this make sense? > > > > > > > > Thanks, > > > > --David > > > > ---------------------------------------------------- > > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South > > > > St., Hopkinton, MA 01748 > > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > david.black@emc.com Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > > > > > > > -----Original Message----- > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > Behalf > > > > > Of Thomas.Millar@us-cert.gov > > > > > Sent: Tuesday, February 21, 2012 12:00 PM > > > > > To: ariestake@googlemail.com; Moriarty, Kathleen; > > > > > david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > > > > takeshi_takahashi@nict.go.jp > > > > > Cc: mile@ietf.org > > > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI > > > > > for SCI (was Re: MTI SCI?) > > > > > > > > > > Take, > > > > > > > > > > I think you've done a very good job of explaining the two > > > > > different interpretations around this call for consensus. > > > > > > > > > > My interpretation of MTI was closer to #2 - that to support this > > > > > draft, an implementer would have to support not only recognition > > > > > of the namespace in the appropriate IODEF parent class context, > > > > > but also be able to parse the content of the referenced > > > > > namespace. Hence my preference for a relatively > > > > simple and familiar spec as the MTI. > > > > > > > > > > If we can concur that we all really mean the interpretation you > > > > > describe under #1, then I'm okay with having an MTI for each class. > > > > > What that says to me is that each implementer would need to > > > > > conform to the SCI draft's class placement of each namespace, > > > > > but not necessarily have to be able to interpret the contents > of > > > > > said namespace(s). So all I have to do, minimally, is recognize > > > > > the class under which any of the referenced namespaces exist; > > > > I don't have to have any means to parse or handle that class > > > > content other than bucket it and move on to the next. Is that right? > > > > > > > > > > I would recommend that we be very clear in regards to what "support" > > > > > or "minimally support" mean so that technical requirements > > > > > handed down based on this draft do not bar achievement by > > > > > operational > > > implementers and their engineering teams. > > > > > > > > > > Thanks again, > > > > > > > > > > - Tom Millar, US-CERT > > > > > > > > > > thomas.millar@us-cert.gov > > > > > BB: thomas.millar@dhs.gov / 202-631-1915 > > > > > 24x7: soc@us-cert.gov / 888-282-0870 > > > > > > > > > > -----Original Message----- > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > Behalf > > > > > Of Takeshi Takahashi > > > > > Sent: Monday, February 20, 2012 20:40 > > > > > To: kathleen.moriarty@emc.com; david.waltermire@nist.gov; > > > > > trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > > > > > Cc: mile@ietf.org > > > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI > > > > > for SCI > > > > > (wasRe: MTI SCI?) > > > > > > > > > > Hello all, > > > > > > > > > > Thank you for your kind comments, which are really useful for > me. > > > > > On the other hand, I have some difficulties to understand what > > > > > people > > > specifically mean by "support" > > > > > or "mandatory". > > > > > I would appreciate if you could kindly give me some comments on > below. > > > > > > > > > > Below are my views on the MTI issues. > > > > > > > > > > 1. All the specification namespaces listed in the table MUST > be > > > > > "supported" as values for the SpecID field. > > > > > > > > > > These namespaces are the allowed ENUM values. > > > > > So, in a way, all the specification listed in the table are > supported. > > > > > (implementations must allow these namespaces of all the > > > > > specifications listed in the table as values for SpecID field) > > > > > Since all the specification listed in the table are supported, > > > > > we need to have expert review before registration (as we > > > > > discussed in Quebec > > > > > City) > > > > > > > > > > In this way, receivers can correctly understand the data. > > > > > That will give us the same level of interoperability as the RFC > > > > > 5070 > > > > > (IODEF) does between sender and receiver, I think. > > > > > > > > > > > > > > > 2. Implementers have freedom to define how to parse, how to > > > understand, > > > > > and how to respond the IODEF extension message > > > > > > > > > > I might be wrong, but I do not think we would like to define how > > > > > to parse the IODEF extension message at the receiver side. > > > > > And I do not think we would like to define how to parse, for > > > > > instance, CAPEC data, at the receiver side. > > > > > I think the SCI draft is a container that conveys these > > > > > structured information, and it can see such information as a > > > > > blackbox with a > > > tag (namespace information). > > > > > > > > > > If above understanding is correct, I have some difficulty to > > > > > understand the meaning of "mandatory to support CVE". > > > > > As described in issue 1 above, if CVE or CAPEC data is attached, > > > > > the implementation needs to recognize that the data is in > > > > > CVE/CAPEC format, and that is the requirement > > > > for the implementation. > > > > > What else do we want to mandate here, specifically? > > > > > Do we need to manipulate the embedded xml data itself? I rather > > > > > prefer to handle the data as a blackbox. > > > > > > > > > > I appreciate your kind comments. > > > > > Regarding the other point Dave kindly pointed out, let me have > > > > > another thread. (sorry I need to get on board now...) > > > > > > > > > > Thank you. > > > > > > > > > > Take > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: kathleen.moriarty@emc.com > > > > > [mailto:kathleen.moriarty@emc.com] > > > > > Sent: Monday, February 20, 2012 8:08 PM > > > > > To: david.waltermire@nist.gov; trammell@tik.ee.ethz.ch; > > > > > takeshi_takahashi@nict.go.jp > > > > > Cc: mile@ietf.org > > > > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI > > > > > for SCI (was > > > > > Re: MTI SCI?) > > > > > > > > > > Thank you, Dave. > > > > > > > > > > Dave raises a few very important points as we consider MTI for > SCI. > > > > > We will need to resolve these issues if CVE is to be the (or an) > > > > > MTI specification for the SCI > > > > draft. > > > > > > > > > > If CVE is mandatory to implement, what guidance would be > > > > > followed > > > on > > > > > how to use the model or will MTI only mean that the document can > > > > > be > > > received and > > > > > parsed? The CVE website is listed as the specification URI, > but > > > from > > > > > Dave's message, the specification URI does not exist to provide > > > > > the guidance (I get to broken link pages for both - the existing > > > > > and > > > suggested replacement link). > > > > > > > > > > This is the closest I could find and may be the answer for guidance: > > > > > http://cve.mitre.org/compatible/requirements.html > > > > > > > > > > It looks like the reference to the target namespace needs to be > > > > > fixed > > > as well. > > > > > > > > > > Thank you, > > > > > Kathleen > > > > > ________________________________________ > > > > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf > Of > > > Waltermire, David A. > > > > > [david.waltermire@nist.gov] > > > > > Sent: Thursday, February 16, 2012 5:26 PM > > > > > To: Brian Trammell; Takeshi Takahashi > > > > > Cc: mile@ietf.org > > > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI > > > > > for SCI (was > > > > > Re: MTI SCI?) > > > > > > > > > > I have not been following this thread as closely as I probably > should. > > > > > Relative to MTI, is the question what schema should be MTI for > > > > > the vulerability class? In general I think we should have one > > > > > or more > > > MTI for each class. > > > > > > > > > > Relative to CVE specifically, are we talking about the schema > > currently > > > located at: > > > > > http://cve.mitre.org/schema/cve/cve_1.0.xsd? > > > > > > > > > > This seems to match the namespace defined in section 4.1.7 of > > > mile-sci-02. > > > > > Looking at the implementation of this schema, it looks like the > > > > > targetNamespace is incorrectly assigned to > > > > > "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when > > > > > it should be > > > > "http://cve.mitre.org/cve/downloads/1.0". This will likely need > > > > to > > > be fixed. > > > > > > > > > > Also, the specification URI points to the CVE website, which is > > > > > not really a specification. It's not clear where to find > > > > > guidance on how to properly use the model indicated by the > > > > > namespace. Without having clear guidance on its use I don't see > > > > > how we can make it MTI, even if it is considered a de facto > > > > > approach. It might make sense to produce a specification for > > > > > the model > > > > before making it MTI for the vulnerability class. > > > > > > > > > > Sincerely, > > > > > David Waltermire > > > > > > > > > > > -----Original Message----- > > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > > > Behalf Of Brian Trammell > > > > > > Sent: Wednesday, February 15, 2012 5:28 AM > > > > > > To: Takeshi Takahashi > > > > > > Cc: mile@ietf.org > > > > > > Subject: [mile] Discussion / consensus call on CVE as MTI for > > > > > > SCI (was > > > > > > Re: MTI SCI?) > > > > > > > > > > > > Hi, Take, all, > > > > > > > > > > > > Thank you for this edit/clarification. > > > > > > > > > > > > On the first point, it does seem the discussion on the list > > > > > > converged rather quickly to CVE as MTI. However, as this is > a > > > > > > rather important point, I'd like to make sure we didn't miss > > anything. > > > > > > > > > > > > So, I'd like to call for consensus on the list. Does the > > > > > > working group agree on the following two points? > > > > > > > > > > > > 1. mile-sci requires one Mandatory to Implement schema in > > > > > > order > > > to > > > > > > ensure interoperability. > > > > > > > > > > > > 2. The Mandatory to Implement schema is the Common > > > > > > Vulnerability Enumeration (CVE) version 1.0, as described in > > > > > > section 4.1.7 of > > > > > > mile- sci-02. > > > > > > > > > > > > Please note if you agree; if you disagree, please explain why > not. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Brian (as chair) > > > > > > > > > > > > On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote: > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > Following the discussion, I would like to add a couple of > > > > > > > sentences > > > > > > to > > > > > > > clarify the MTI issues. > > > > > > > (Thank you very much for those of you who kindly provided > > > > > > > useful > > > > > > > discussion.) > > > > > > > I've attached the working version of the draft. I hope it > > > > > > > helps to clarify the changes. > > > > > > > > > > > > > > (added sentences at the end of section 4.1) > > > > > > > > > > > > > > The SpecID attributes of extended classes (Section 4.3) > > > > > > > must > > > allow > > > > > > > the values of the specifications' namespace fields, but > > > otherwise, > > > > > > > implementations are not required to support all the above > > > > > > > specifications. Implementations may choose which > > > specifications to > > > > > > > support, though CVE 1.0 (Section 4.1.7) needs to be minimally > > > > > > > supported. In case an implementation received a data it > > > > > > > does > > > not > > > > > > > support, it may expand its functionality by looking up the > > > > > > > IANA > > > > > > table or > > > > > > > notify the sender of its inability to parse the data by > > > > > > > using > > > any > > > > > > > means defined outside the scope of this specification. > > > > > > > > > > > > > > On the other hand, I would like to add "STRING ext-SpecID" > > > > > > > to each class, which enables to embed data following private > schema. > > > > > > > For instance, one security operation center (SOC) may wish > > > > > > > to > > > > > > exchange > > > > > > > a vulnerability data that is formatted in its own private > > > > > > > schema, and that is not formatted in CVE. > > > > > > > In this case, the SOC may put the data's schema ID inside > > > > > > > ext-SpecID and then embed the data. > > > > > > > It could also be used to exchange data using beta version > of > > > > > > specifications. > > > > > > > > > > > > > > The class could be seen as below. > > > > > > > > > > > > > > +------------------------+ > > > > > > > | AttackPattern | > > > > > > > +------------------------+ > > > > > > > | ENUM SpecID |<>--(0..*)-[ RawData ] > > > > > > > | STRING ext-SpecID |<>--(0..*)-[ Reference ] > > > > > > > | STRING AttackPatternID |<>--(0..*)-[ Platform ] > > > > > > > +------------------------+ > > > > > > > > > > > > > > SpecID: REQUIRED. ENUM. The identifier of the > specification > > > > > > > specifying the format of the RawData element. The > > > > > > > value should > > > > > > be > > > > > > > chosen from the namespaces [XMLNames] listed in Section > > > > > > > 4.1 > > > or > > > > > > > "private". Note that the lists in Section 4.1 will be > > > developed > > > > > > > further by IANA. The value "private" is prepared for > > conveying > > > > > > > RawData based on a format that is not listed in the > > > > > > > table. This is usually used for conveying data formatted > > > > > > > according to an organization's private schema. When > > > > > > > the > > > value > > > > > > > "private" is used, ext-SpecID element needs to be used. > > > > > > > > > > > > > > ext-SpecID: OPTIONAL. STRING. The identifier of the > > > > > > specification > > > > > > > specifying the format of the RawData element. When > > > > > > > this > > > element > > > > > > > is used, the value of SpecID element must be "private." > > > > > > > > > > > > > > I hope above changes don't cause any complication here. > > > > > > > > > > > > > > Sincerely, > > > > > > > Take > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] > > > > > > >> On Behalf Of Martin, Robert A. > > > > > > >> Sent: Wednesday, February 15, 2012 1:50 AM > > > > > > >> To: Kent_Landfield@McAfee.com > > > > > > >> Cc: mile@ietf.org > > > > > > >> Subject: Re: [mile] MTI SCI? > > > > > > >> > > > > > > >> At the risk of contradicting myself - but then again I have > > > > > > >> now read the other replies to this issue - I agree that > > > > > > >> having one area be > > > > > > the > > > > > > >> smoke test makes sense and I also agree that something > > > > > > >> simple and commonly used already - like CVE - is the best > > > > > > >> candidate for what we > > > > > > need. > > > > > > >> > > > > > > >> Bob > > > > > > >> > > > > > > >> On 2/14/12 11:45 AM, Kent_Landfield@McAfee.com wrote: > > > > > > >>> CVE is widely used and understood by all in the the > > > > > > >>> security > > > > > > community. > > > > > > >> I agree with Tom that CVE is the path of least resistance > > > > > > >> but may be the most useful for basic interoperability. > > > > > > >>> > > > > > > >>> Kent Landfield > > > > > > >>> Director Content Strategy, Architecture and Standards > > > > > > >>> > > > > > > >>> McAfee | An Intel Company > > > > > > >>> 5000 Headquarters Dr. > > > > > > >>> Plano, Texas 75024 > > > > > > >>> > > > > > > >>> Direct: +1.972.963.7096 > > > > > > >>> Mobile: +1.817.637.8026 > > > > > > >>> Web: www.mcafee.com > > > > > > >>> > > > > > > >>> From: > > > > > > >>> > > > > > > >> > > > "Thomas.Millar@us-cert.gov" > > > > > >> ho > > > > > > >> ma > > > > > > >> s > > > > > > >> .M > > > > > > >>> illar@us-cert.gov> > > > > > > >>> Date: Tue, 14 Feb 2012 10:36:57 -0600 > > > > > > >>> To: > > > > > > >>> > > > > > > >> > > > "david.black@emc.com" > > > > > >> mc > > > > > > >> .c > > > > > > >> o > > > > > > >> m< > > > > > > >>> mailto:david.black@emc.com>>, Bob > > > > > > >>> Martin> > > > > > > >>> Cc: > > > > > > >>> > > > > > > >> > > > "mile@ietf.org" > > > > > >> @i > > > > > > >> et > > > > > > >> f > > > > > > >> .o > > > > > > >>> rg>> > > > > > > >>> Subject: Re: [mile] MTI SCI? > > > > > > >>> > > > > > > >>> My concern with CAPEC being mandatory is that it could > > > > > > >>> discourage > > > > > > >> effective operational uptake of IODEF-SCI as the CAPEC > > > > > > >> vocabulary remains "too comprehensive" for many CSIRTs to > > > > > > >> employ during > > > > > > incident > > > > > > >> handling and reporting activity. > > > > > > >>> > > > > > > >>> IODEF by itself has been criticized by CSIRT operators for > > > > > > >>> being more > > > > > > >> heavyweight than necessary for day-to-day usage; making > > > > > > >> CAPEC > > > a > > > > > > >> mandatory aspect of "advanced IODEF" seems like it would > be > > > > > > >> adding ammunition to that argument, especially if the CSIRT > > > > > > >> is having to fund implementation out of their own pocket. > > > > > > >> Personally, I would > > > > > > have > > > > > > >> a hard time asking US-CERT's primary constituents to > > > > > > >> implement IODEF > > > > > > >> + CAPEC if they are already balking at the consultant and > > > > > > >> + developer > > > > > > >> resources required to implement RFC 5070 by itself. Also > > > > > > >> keep in > > > > > > mind > > > > > > >> that CAPEC references CybOX, so there's wheels within > > > > > > >> wheels > > > now. > > > > > > >>> > > > > > > >>> I would prefer we take the path of least resistance (from > > > > > > >>> my > > > > > > > perspective) > > > > > > >> and make CVE the MTI, if we have to pick one additional spec. > > > > > > >>> CVE is well known, has years of familiarity built in, and > > > > > > >>> I think it's > > > > > > >> the simplest schema of the bunch. > > > > > > >>> > > > > > > >>> > > > > > > >>> - Tom Millar, US-CERT > > > > > > >>> > > > > > > >>> > thomas.millar@us-cert.gov > > > > > >>> > > > > > > > >>> BB: thomas.millar@dhs.gov > / > > > > > > >>> 202-631-1915 > > > > > > >>> 24x7: soc@us-cert.gov / > > > > > > >>> 888-282-0870 > > > > > > >>> > > > > > > >>> -----Original Message----- > > > > > > >>> From: mile-bounces@ietf.org > > > > > > >>> [mailto:mile-bounces@ietf.org] On Behalf Of > > > > > > >>> david.black@emc.com > > > > > > >>> Sent: Tuesday, February 14, 2012 11:14 > > > > > > >>> To: ramartin@mitre.org > > > > > > >>> Cc: mile@ietf.org > > > > > > >>> Subject: Re: [mile] MTI SCI? > > > > > > >>> > > > > > > >>> Hi Bob, > > > > > > >>> > > > > > > >>> I do appreciate the concern about implementing things that > > > > > > >>> aren't going > > > > > > >> to be used. OTOH, it may be useful to have a single simple > > > > > > >> MTI spec for SCI that can be used to "smoke test" a > > > > > > >> deployment before trying any > > > > > > > serious > > > > > > >> test data (and "simple" is important). > > > > > > >>> > > > > > > >>> In addition, a concern that I would have with an MTI SCI > > > > > > >>> spec per class > > > > > > >> is that if two SCI implementations don't have at least one > > > > > > >> class in > > > > > > > common, > > > > > > >> they aren't going to interoperate, and that situation is > > > > > > >> unlikely to be acceptable to the IESG (i.e., with an MTI > > > > > > >> SCI spec per class, I suspect that there will also have to > > > > > > >> be an MTI class, which results in an overall MTI SCI spec). > > > > > > >>> > > > > > > >>> It may also be useful to include a simple example of the > > > > > > >>> MTI SCI spec > > > > > > >> in an appendix to simplify "smoke testing" (e.g., if the > > > > > > >> MTI SCI > > > > > > spec > > > > > > >> is CAPEC, as Youki suggested, the appendix could contain > a > > > > > > >> CAPEC XML document for testing purposes, including > > > > > > >> enumeration values suitable for testing). > > > > > > >>> > > > > > > >>> What do you (and others) think about this? > > > > > > >>> > > > > > > >>> Thanks, > > > > > > >>> --David > > > > > > >>> > > > > > > >>> -----Original Message----- > > > > > > >>> From: mile-bounces@ietf.org > > > > > > >> [mailto:mile-bounces@ietf.org] On Behalf Of Martin, Robert > A. > > > > > > >>> Sent: Tuesday, February 14, 2012 8:26 AM > > > > > > >>> To: Brian Trammell > > > > > > >>> Cc: mile@ietf.org > > > > > > >>> Subject: Re: [mile] MTI SCI? > > > > > > >>> Brian, > > > > > > >>> You beat me to this point. Like you, I would be concerned > > > > > > >>> about a MTI selection that ended up requiring someone to > > > > > > >>> implement > > > > > > something > > > > > > >>> to meet the MTI but wasn't germane to anything else they > > > > > > >>> intended > > > > > > to > > > > > > >> support. > > > > > > >>> Bob > > > > > > >>> On 2/14/12 4:19 AM, Brian Trammell wrote: > > > > > > >>>> Hi, Sean, all, > > > > > > >>>> > > > > > > >>>> Looking over the spec, it's not clear to me that one MTI > > > > > > >>>> makes sense here, given that mile-sci's > > > > > > >>> purpose is to reference a set of external specifications > > > > > > >>> by inclusion in an IODEF document, and that those external > > > > > > >>> specifications represent > > > > > > >> fundamentally different things. > > > > > > >>>> > > > > > > >>>> The specifications are split over their applicability to > > > > > > >>>> the IODEF extension classes. I could > > > > > > >>> envision an mile-sci implementation that was only > > > > > > >>> interested > > > a > > > > > > >>> subset of these classes (perhaps even only one). If my > > > > > > >>> implementation has an internal representation of > > > > > > >>> Verification, but not of any of the other classes, and the > > > > > > >>> MTI is an enumeration that is applicable to > > > > > > >> Vulnerability... what do I do? > > > > > > >>>> > > > > > > >>>> What about selecting an MTI per class, instead? > > > > > > >>>> > > > > > > >>>> Best regards, > > > > > > >>>> > > > > > > >>>> Brian (as contributor) > > > > > > >>>> > > > > > > >>>> On Feb 14, 2012, at 1:19 AM, Sean Turner wrote: > > > > > > >>>> > > > > > > >>>>> Great - as long as we pick one as the MTI. Note that > > > > > > >>>>> MTI > > > is > > > > > > >>>>> not > > > > > > >> necessarily mandatory to use. > > > > > > >>>>> > > > > > > >>>>> spt > > > > > > >>>>> > > > > > > >>>>> On 2/13/12 7:11 PM, > > > > > > >> > kathleen.moriarty@emc.com > > > wrote: > > > > > > >>>>>> Thank you for raising the interoperability testing as > > > > > > >>>>>> we need to plan for a bake-off that once > > > > > > >>> these questions get answered and the draft is ready. > > > > > > >>>>>> > > > > > > >>>>>> Thanks, > > > > > > >>>>>> Kathleen > > > > > > >>>>>> > > > > > > >>>>>> -----Original Message----- > > > > > > >>>>>> From: > > > > > > >>>>>> mile-bounces@ietf.org > > > > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner > > > > > > >>>>>> Sent: Monday, February 13, 2012 6:57 PM > > > > > > >>>>>> To: mile@ietf.org > > > > > > >>>>>> Subject: [mile] MTI SCI? > > > > > > >>>>>> > > > > > > >>>>>> There's 17 listed SCI (Structured Cybersecurity > > > > > > >>>>>> Information) specifications in draft-ietf-mile-sci. > > > > > > >>>>>> Which one is the MTI (mandatory to implement) choice? > > > > > > >>>>>> In other words, how will you get two interoperability > > > > > > >>>>>> implementations > > > without picking one? > > > > > > >>>>>> > > > > > > >>>>>> spt > > > > > > >>>>>> _______________________________________________ > > > > > > >>>>>> mile mailing list > > > > > > >>>>>> mile@ietf.org > > > > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>> _______________________________________________ > > > > > > >>>>> mile mailing list > > > > > > >>>>> mile@ietf.org > > > > > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > > > > > >>>> > > > > > > >>>> _______________________________________________ > > > > > > >>>> mile mailing list > > > > > > >>>> mile@ietf.org > > > > > > >>>> https://www.ietf.org/mailman/listinfo/mile > > > > > > >>>> . > > > > > > >>>> > > > > > > >>> _______________________________________________ > > > > > > >>> mile mailing list > > > > > > >>> mile@ietf.org > > > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> mile mailing list > > > > > > >>> mile@ietf.org > > > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > > > >>> _______________________________________________ > > > > > > >>> mile mailing list > > > > > > >>> mile@ietf.org > > > > > > >>> https://www.ietf.org/mailman/listinfo/mile > > > > > > >>> > > > > > > >>> > > > > > > >> _______________________________________________ > > > > > > >> mile mailing list > > > > > > >> mile@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > > > > ci > > > > > > > - > > > > > > 03c > > > > > > > > > > > > > > > > > andidate_20120215.txt.pdf>________________________________________ > > > > > > __ > > > > > > __ > > > > > > > ___ > > > > > > > mile mailing list > > > > > > > mile@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > _______________________________________________ > > > > > > mile mailing list > > > > > > mile@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > _______________________________________________ > > > > > mile mailing list > > > > > mile@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mile mailing list > > > > > mile@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > _______________________________________________ > > > > > mile mailing list > > > > > mile@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > From trammell@tik.ee.ethz.ch Fri Feb 24 01:21:16 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256C921F88CD for ; Fri, 24 Feb 2012 01:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SNqh4Um7AIFw for ; Fri, 24 Feb 2012 01:21:15 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B678A21F8593 for ; Fri, 24 Feb 2012 01:21:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5E6DCD930A for ; Fri, 24 Feb 2012 10:21:10 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3GaOeU61Syqy for ; Fri, 24 Feb 2012 10:21:10 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 33EB5D9308 for ; Fri, 24 Feb 2012 10:21:10 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 10:21:09 +0100 References: <20120223202318.5156.93875.idtracker@ietfa.amsl.com> To: "" Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [mile] Fwd: mile - Requested session has been scheduled for IETF 83 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:21:16 -0000 Greetings, all, Per the draft IETF agenda = (https://datatracker.ietf.org/meeting/83/agenda.html), the MILE meeting = will take place on Tuesday afternoon, 17:10 local time, in Room 235 of = the Palais de Congres de Paris.=20 Best regards, Brian Begin forwarded message: > From: "\"IETF Secretariat\"" > Subject: mile - Requested session has been scheduled for IETF 83 > Date: February 23, 2012 9:23:18 PM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: mile-ads@tools.ietf.org, mile-chairs@tools.ietf.org, wlo@amsl.com >=20 > Dear Brian Trammell, >=20 > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > mile Session 1 (1 hour) > Tuesday, Afternoon Session III 1710-1810 > Room Name: 253 > --------------------------------------------- From jeff360@gmail.com Sat Feb 25 15:26:15 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA43A21F8512 for ; Sat, 25 Feb 2012 15:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WHfyvVzaUjCS for ; Sat, 25 Feb 2012 15:26:15 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 359EA21F853B for ; Sat, 25 Feb 2012 15:26:07 -0800 (PST) Received: by bkwj4 with SMTP id j4so1482368bkw.31 for ; Sat, 25 Feb 2012 15:26:06 -0800 (PST) Received-SPF: pass (google.com: domain of jeff360@gmail.com designates 10.204.153.26 as permitted sender) client-ip=10.204.153.26; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jeff360@gmail.com designates 10.204.153.26 as permitted sender) smtp.mail=jeff360@gmail.com; dkim=pass header.i=jeff360@gmail.com Received: from mr.google.com ([10.204.153.26]) by 10.204.153.26 with SMTP id i26mr3872440bkw.66.1330212366298 (num_hops = 1); Sat, 25 Feb 2012 15:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=7DalggbKkbiIWRKULVR6Te9ZY+MKa8d8f10iPcguqMI=; b=frPbxo/PqLpgu/7sTcsWVuxAAyuwQL+w5ssFJ3mdAuE0YMCfWq9oiHGDirbin8OuBJ er0KgVCT1G0rBTUf5v7qW8qUiGJCorh3Mwy8hy1N9tpZBvrLwjDkA5lQduTZ50Fqx5g5 VwpvrQiSfwUFSsIPEFVdG1YnEV2SFR3HDxW5Q= Received: by 10.204.153.26 with SMTP id i26mr3180696bkw.66.1330212366211; Sat, 25 Feb 2012 15:26:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.83.73 with HTTP; Sat, 25 Feb 2012 15:25:45 -0800 (PST) From: Jeff Reed Date: Sat, 25 Feb 2012 15:25:45 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=000e0cd1fc1a905a9c04b9d2331d Subject: [mile] Forensics Extension X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 23:26:16 -0000 --000e0cd1fc1a905a9c04b9d2331d Content-Type: text/plain; charset=ISO-8859-1 Has anyone begun work on the Forensics Extension draft? Has anyone collected any base references for inclusion in this draft? I would like to begin focusing on that effort with whoever else may have already started, or begin work on it if no one has. Jeff Reed Information Security Office Cambia Health Solutions (o) +1-503-450-1725 (m) +1-360-823-3975 jeffrey.reed@cambiahealth.com jeff360@gmail.com --000e0cd1fc1a905a9c04b9d2331d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0=A0 Has anyone begun work on the Forensics Extension draft?=A0 Has a= nyone collected any base references for inclusion in this draft?=A0 I would= like to begin focusing on that effort with whoever else may have already s= tarted, or begin work on it if no one has.

=A0=A0 Jeff Reed
=A0=A0 Information Security Office
=A0=A0 Cambia= Health Solutions
=A0=A0 (o) +1-503-450-1725
=A0=A0 (m) +1-360-823-39= 75
=A0=A0 jeffrey.reed@= cambiahealth.com
=A0=A0 jeff360@gmail.com
--000e0cd1fc1a905a9c04b9d2331d-- From inacio@cert.org Tue Feb 28 13:00:43 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9AB21F8547 for ; Tue, 28 Feb 2012 13:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] 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 ZXLk-hQ3siTg for ; Tue, 28 Feb 2012 13:00:42 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66BFF21F853D for ; Tue, 28 Feb 2012 13:00:41 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1405) with ESMTP id q1SL0b7f024102; Tue, 28 Feb 2012 16:00:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1330462837; bh=n7c96sEgdHv1BAz5D5jm28ITfwfOxLiaClaTx6mpwVQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=cyZe+EHKUvG3HLHTCoKDLtoIzxKfwGrYEfP5paCsCLeSysrE4zn1yP5l7NahDajDc WPnTiRAstgfGN6V9Qu6Qv7IcAsQSDMct4x+HHVKKnDCm13SBohpGkzXfbREU7mNE2R bvKDaL0Aarg0Z0nyFPcH6hmkGlWJuqTDCmOPu+NI= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by timber.sei.cmu.edu (8.14.4/8.14.4/1405) with ESMTP id q1SL0bvS026121; Tue, 28 Feb 2012 16:00:37 -0500 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.12]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Tue, 28 Feb 2012 16:00:37 -0500 From: Chris Inacio To: Jeff Reed Date: Tue, 28 Feb 2012 16:00:42 -0500 Thread-Topic: [mile] Forensics Extension Thread-Index: Acz2XATdfJdmqpSbTSCvJpA0TxBbug== Message-ID: <65E2E0B1-101A-4157-8C14-9B1FA5F1D0FA@cert.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_65E2E0B1101A41578C149B1FA5F1D0FAcertorg_" MIME-Version: 1.0 Cc: "" Subject: Re: [mile] Forensics Extension X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 21:00:44 -0000 --_003_65E2E0B1101A41578C149B1FA5F1D0FAcertorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I submitted the beginnings of a draft. It's in pretty rough shape at this = point - so there is still A LONG way to go on it. It borrows (heavily) from work submitted to ITU & DFXML. Chris Inacio Development Team Lead Systems Team Lead CERT / Software Engineering Institute Carnegie Mellon University On Feb 25, 2012, at 6:25 PM, Jeff Reed wrote: >=20 > Has anyone begun work on the Forensics Extension draft? Has anyone co= llected any base references for inclusion in this draft? I would like to b= egin focusing on that effort with whoever else may have already started, or= begin work on it if no one has. >=20 > Jeff Reed > Information Security Office > Cambia Health Solutions > (o) +1-503-450-1725 > (m) +1-360-823-3975 > jeffrey.reed@cambiahealth.com > jeff360@gmail.com > --_003_65E2E0B1101A41578C149B1FA5F1D0FAcertorg_ Content-Type: application/octet-stream; name="draft-ietf-mile-digitalForensics-00.nroff" Content-Description: draft-ietf-mile-digitalForensics-00.nroff Content-Disposition: attachment; filename="draft-ietf-mile-digitalForensics-00.nroff"; size=18195; creation-date="Tue, 28 Feb 2012 21:00:36 GMT"; modification-date="Tue, 28 Feb 2012 21:00:36 GMT" Content-Transfer-Encoding: base64 LnBsIDEwLjBpDQoucG8gMA0KLmxsIDcuMmkNCi5sdCA3LjJpDQoubnIgTEwgNy4yaQ0KLm5yIExU IDcuMmkNCi5kcyBMRiBDaHJpc3RvcGhlciBJbmFjaW8gDQouZHMgUkYgRk9STUZFRURbUGFnZSAl XQ0KLmRzIExIIElOVEVSTkVUIERSQUZUDQouZHMgUkggRmVicnVhcnkgMTksIDIwMTINCi5kcyBD SCBEaWdpdGFsIEZvcmVuc2ljcyBFeHRlbnNpb24gZm9yIElPREVGDQouZHMgQ0YgRXhwaXJlcyBB dWd1c3QgMjIsIDIwMTINCi5oeSAwDQoubmgNCi5hZCBsDQouaW4gMA0KDQoubmYNCi50bCAnSU5U RVJORVQtRFJBRlQnJ0NocmlzdG9waGVyIEluYWNpbycNCi50bCAnSW50ZW5kZWQgU3RhdHVzOiBQ cm9wb3NlZCBTdGFuZGFyZCcnQ2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHknDQoudGwgJ0V4cGly ZXM6IDxFeHBpcnkgRGF0ZT4nJzxJc3N1ZSBEYXRlPicNCi5maQ0KDQouXCIgTm90ZS4gVGhlICIu dGwiIGRpcmVjdGl2ZSBpcyB1c2VkIHRvIGdlbmVyYXRlIHRoZSBsZWFkaW5nIGhlYWRlciANCi5c IiBpbiBJbnRlcm5ldCBkcmFmdHMuIFRoZSBpbmZvcm1hdGlvbiBzcGVjaWZpZWQgYWZ0ZXIgIi50 bCIgcHJvdmlkZXMNCi5cIiBsZWZ0LCBjZW50ZXIgYW5kIHJpZ2h0IGNvbXBvbmVudHMgb2YgYSBs aW5lIHNlcGFyYXRlZCBieSB0aGUgJyBjaGFyYWN0ZXINCi5cIiBpbiB0aGUgZm9sbG93aW5nIG1h bm5lcjoNCi5cIiANCi5cIiAgLnRsICc8bGVmdCBjb21wb25lbnQ+JzxjZW50ZXIgY29tcG9uZW50 Pic8cmlnaHQgY29tcG9uZW50PicNCi5cIg0KLlwiIE9ubHkgdGhlIGxlZnQgYW5kIHJpZ2h0IGNv bXBvbmVudHMgYXJlIHVzZWQgaW4gSW50ZXJuZXQtZHJhZnQgaGVhZGVycw0KLlwiIFRoaXMgYW5k IG90aGVyIGNvbW1lbnRzIGluIHRoaXMgdGVtcGxhdGUgY2FuIHNhZmVseSBiZSBkZWxldGVkLg0K DQouY2UgMg0KRGlnaXRhbCBGb3JlbnNpY3MgRXh0ZW5zaW9uIGZvciBJT0RFRiANCmRyYWZ0LWll dGYtbWlsZS1kaWdpdGFsRm9yZW5zaWNzLTAwDQouZmkNCi5pbiAzDQoNCg0KLnRpIDANCkFic3Ry YWN0DQoNClRoaXMgZXh0ZW5zaW9uIHRvIElPREVGIChSRkMgNTA3MCkgaXMgZGVzaWduZWQgdG8g YWlkIGluIHRoZSBzaGFyaW5nIGFuZCBkaXNzZW1pbmF0aW9uIG9mIGRpZ2l0YWwgZm9yZW5zaWNz IGluZm9ybWF0aW9uLiAgVGhlIGdvYWwgaXMgdG8gYWxsb3cgYSB0b29sIGluZGVwZW5kZW50IGZv cm1hdCB0byBzaGFyZSBpbmZvcm1hdGlvbiBiZXR3ZWVuIG9yZ2FuaXphdGlvbnMgZm9jdXNlZCBv biBkaWdpdGFsIGZvcmVuc2ljczogZHJpdmUgaW1hZ2VzLCBmaWxlIGNhcnZpbmcsIG1ldGFkYXRh LCBhbmQgcmVsYXRlZCBoYXNoZXMuICBBcyB3aXRoIElPREVGIGFuZCBpdHMgZXh0ZW5zaW9ucywg aXQgaXMgZGVmaW5lZCB1c2luZyBYTUwuDQoNCg0KLnRpIDANClN0YXR1cyBvZiB0aGlzIE1lbW8N Cg0KVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZv cm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQXDA3OCBhbmQgQkNQXDA3OS4NCg0KSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw cy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv Y3VtZW50cyBhcyBcJUludGVybmV0LURyYWZ0cy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUg dXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55 IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHBy b2dyZXNzLiINCg0KVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0IFwlaHR0cDovL3d3dy5pZXRmLm9yZy8xaWQtYWJzdHJhY3RzLmh0bWwNCg0KVGhl IGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3Nl ZCBhdCBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQoNCg0KLnRpIDANCkNvcHlyaWdo dCBhbmQgTGljZW5zZSBOb3RpY2VcIiBCb2lsZXJwbGF0ZSBmcm9tIERlY2VtYmVyIDIwMDkNCg0K LlwiIE5PVEU6IEluc2VydCBjdXJyZW50IDx5ZWFyPiBpbiB0aGUgZm9sbG93aW5nIHBhcmFncmFw aA0KQ29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlIGRvY3VtZW50IGF1dGhvcnMuIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNClRoaXMg ZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1BcMDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2Fs IFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMgXCUoaHR0cDovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YgcHVibGljYXRp b24gb2YgdGhpcyBkb2N1bWVudC4gUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1 bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCBy ZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0 aGlzIGRvY3VtZW50IG11c3QgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb25cMDQuZSBvZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBh bmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMgZGVzY3JpYmVkIGluIHRoZSBTaW1w bGlmaWVkIEJTRCBMaWNlbnNlLg0KDQoNCg0KLlwiIFwjIFRENCAgLS0gU2V0IFRPQyBkZXB0aCBi eSBhbHRlcmluZyB0aGlzIHZhbHVlIChURDUgPSBkZXB0aCA1KQ0KLlwiIFwjIFRPQyAgLS0gQmVn aW5uaW5nIG9mIGF1dG8gdXBkYXRlZCBUYWJsZSBvZiBDb250ZW50cw0KLmluIDANClRhYmxlIG9m IENvbnRlbnRzDQoNCi5uZg0KICAgMSAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDEuMSAgVGVybWlub2xvZ3kg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIu IEZvcmVuc2ljIEV4dGVuc2lvbiB0byBJT0RFRiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMw0KICAgMy4gRm9yZW5zaWNzIERhdGEgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDMuMSBGb3JlbnNpY3MgVHlwZSBEZXNj cmlwdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgICAgICAzLjEu MSBIZWFkZXIgSW5mb3JtYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNA0KICAgICAgIDMuMS4yIERldmljZS9Tb3VyY2UgSW5mb3JtYXRpb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAgICAgMy4xLjMgSGFzaCBJbmZvcm1hdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgICAzLjEuNCBCeXRl IFJ1biBJbmZvcm1hdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0K ICAgICAgIDMuMS41IEZpbGUgT2JqZWN0IEluZm9ybWF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA1DQogICAyLiAgVGl0bGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgIDMgIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgNCAg SUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA3DQogICA1ICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgNS4xICBOb3JtYXRpdmUgUmVmZXJlbmNl cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICA1LjIgIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA3DQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIEFwcGVuZGl4IEE6IERpZ2l0YWwgRm9yZW5zaWNzIFhN TCBTY2hlbWEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KLmZpDQouaW4gMw0KDQouXCIg XCMgRVRDIC0tIEVuZCBvZiBhdXRvIHVwZGF0ZWQgVGFibGUgb2YgQ29udGVudHMNCg0KLmJwDQou dGkgMA0KMSAgSW50cm9kdWN0aW9uDQoNClRoaXMgZXh0ZW5zaW9uIHRvIElPREVGIGlzIGRlc2ln bmVkIHRvIGNhcnJ5IGRpZ2l0YWwgZm9yZW5zaWNzIGluZm9ybWF0aW9uIGluIGEgd2F5IGFjY2Vw dGFibGUgZm9yIGNoYWluIG9mIGV2aWRlbmNlIGhhbmRsaW5nIGFuZCBnZW5lcmFsIGZvcmVuc2lj cyBleGFtaW5hdGlvbi4gIFRoZXJlIGFyZSB2YXJpb3VzIHByb2dyYW1zIHRoYXQgZ2VuZXJhdGUg Zm9yZW5zaWNzIGluZm9ybWF0aW9uLCBidXQgZmV3IHRoYXQgZ2VuZXJhdGUgdGhhdCBpbmZvcm1h dGlvbiBpbiBhIHdheSB0aGF0IGlzIGV4Y2hhbmdlYWJsZSBpbiBhIHVuaXZlcnNhbCB3YXkuDQoN ClRoZXJlIGhhdmUgYmVlbiBzb21lIGVmZm9ydHMgdG8gY3JlYXRlIGluZGVwZW5kZW50IHN0YW5k YXJkcywgb2Z0ZW4gWE1MIGJhc2VkLCB0byBleGNoYW5nZSBkaWdpdGFsIGZvcmVuc2ljcyBpbmZv cm1hdGlvbi4gIEluZGVlZCwgdGhpcyBzdGFuZGFyZCBpcyBkZXNpZ25lZCB0byBpbmNvcnBvcmF0 ZSBmZWF0dXJlcyBmcm9tIHRob3NlIGVmZm9ydHMsIERGWE1MLCBERVhGLCBJT0MsIGFuZCBERlJX Uy4gIEJ5IGV4dGVuZGluZyBJT0RFRiwgaG93ZXZlciwgdGhlIGdvYWwgb2YgdGhpcyBzdGFuZGFy ZCBpcyB0byBidWlsZCB1cG9uIGEgd2lkZWx5IHVzZWQgSUVURiBzdGFuZGFyZCwgdGFrZSBhZHZh bnRhZ2Ugb2YgdGhlIG90aGVyIGZlYXR1cmVzIHdpdGhpbiB0aGUgSU9ERUYgZmFtaWx5IG9mIHN0 YW5kYXJkcy4NCg0KVGhlIG1haW4gcGllY2VzIG9mIGluZm9ybWF0aW9uIHRoaXMgZXh0ZW5zaW9u IHNlZWtzIHRvIGJlIGFibGUgdG8gY29udmV5IGFyZSBpbmZvcm1hdGlvbiBhYm91dCBmaWxlIHN5 c3RlbXMgYW5kIHRoZSByZXN1bHRpbmcgcHJvZHVjdHMgZnJvbSBhbmFseXppbmcgZmlsZSBzeXN0 ZW1zLiAgVGhpcyBpbmNsdWRlcyBpbmZvcm1hdGlvbiBhYm91dCBmaWxlIGNhcnZpbmcsIHN5c3Rl bSBtZXRhZGF0YSBpbmNsdWRpbmcgZGlzayBtZXRhZGF0YS4NCg0KLnRpIDANCjEuMSAgVGVybWlu b2xvZ3kNCg0KVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJT SEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQi LCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KLnRpIDANCjIuIEZv cmVuc2ljIEV4dGVuc2lvbiB0byBJT0RFRg0KDQpUaGUgRm9yZW5zaWNzIERhdGEgaXMgY2FwdHVy ZWQgd2l0aGluIGEgbmV3IGNsYXNzIHdpdGhpbiBJT0RFRidzIEV2ZW50IERhdGEgY2xhc3MsIHdp dGhpbiBpdHMgQWRkaXRpb25hbCBEYXRhIGNsYXNzLiAgVGhlIEZvcmVuc2ljcyBEYXRhIGlzIG5v dCByZXF1aXJlZCB0byBiZSBwcmVzZW50LCBhbmQgbWF5IG9jY3VyIGFuIHVubGltaXRlZCBudW1i ZXIgb2YgdGltZXMgYXMgbmVlZGVkLg0KDQoubmYNCistLS0tLS0tLS0tLS0tKw0KfCAgIEluY2lk ZW50ICB8DQorLS0tLS0tLS0tLS0tLSsNCnwgICAgICAuICAgICAgfA0KfCAgICAgIC4gICAgICB8 DQp8ICAgICAgLiAgICAgIHwNCnwgRXZlbnQgRGF0YSAgfDw+LXswLi4qfS1bIEV2ZW50IERhdGEg XQ0KfCAgICAgICAgICAgICB8ICAgICAgICAgICAgfDw+LXswLi4qfS1bIEFkZGl0aW9uYWwgRGF0 YSBdDQp8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHw8Pi17MC4uKn0t WyBGb3JlbnNpY3MgRGF0YV0NCnwgICAgICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0rDQoNCg0K DQoudGkgMA0KMy4gRm9yZW5zaWNzIERhdGENCg0KLm5mDQorLS0tLS0tLS0tLS0tLS0tLSsNCnwg Rm9yZW5zaWNzIERhdGEgfA0KKy0tLS0tLS0tLS0tLS0tLS0rDQp8ICAgICAgICAgICAgICAgIHw8 Pi1bVmVyc2lvbl0NCnwgICAgICAgICAgICAgICAgfCAgICB8PD4tW01ham9yXQ0KfCAgICAgICAg ICAgICAgICB8ICAgIHw8Pi1bTWlub3JdDQp8ICAgICAgICAgICAgICAgIHw8Pi1bU2l0ZSBOYW1l XQ0KfCAgICAgICAgICAgICAgICB8PD4tW0V4YW1pbmVyIE5hbWVdDQp8ICAgICAgICAgICAgICAg IHw8Pi1bRXZpZGVuY2UgSURdDQp8ICAgICAgICAgICAgICAgIHw8Pi1bQ3JlYXRpb24gVGltZV0N CnwgICAgICAgICAgICAgICAgfDw+LVtUb29sIE5hbWVdDQp8ICAgICAgICAgICAgICAgIHw8Pi1b VG9vbCBWZXJzaW9uXQ0KfCAgICAgICAgICAgICAgICB8PD4tW0hvc3QgT3BlcmF0aW5nIFN5c3Rl bV0NCnwgICAgICAgICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICB8PD4tW0RldmljZV0NCnwg ICAgICAgICAgICAgICAgfCAgICAgICB8PD4tW0RldmljZSBUeXBlXQ0KfCAgICAgICAgICAgICAg ICB8ICAgICAgIHw8Pi1bRGV2aWNlIE1vZGVsXQ0KfCAgICAgICAgICAgICAgICB8ICAgICAgIHw8 Pi1bRGV2aWNlIFNlcmlhbF0NCnwgICAgICAgICAgICAgICAgfCAgICAgICB8PD4tezAuLjF9LVtT ZWN0b3IgU2l6ZV0NCnwgICAgICAgICAgICAgICAgfCAgICAgICB8PD4tezAuLjF9LVtEZXZpY2Ug U2VjdG9yc10NCnwgICAgICAgICAgICAgICAgfCAgICAgICB8PD4tezAuLip9LVtIYXNoXQ0KfCAg ICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICB8PD4tW0hhc2ggVHlwZV0NCnwgICAg ICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgfDw+LVtIYXNoIFNpemVdDQp8ICAgICAg ICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgIHw8Pi1bSGFzaCBWYWx1ZV0NCnwgICAgICAg ICAgICAgICAgfCAgICAgICB8PD4tezAuLip9LVtGaWxlIE9iamVjdF0NCnwgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICB8PD4tW05hbWVdDQp8ICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgfDw+LVtJRF0NCnwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICB8PD4tW1NpemVdDQp8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfDw+ LVtQYXJ0aXRpb25dDQp8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfDw+LVtN b2RlXQ0KfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHw8Pi1bQUNMXQ0KfCAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHw8Pi1bbXRpbWVdDQp8ICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgfDw+LVthdGltZV0NCnwgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICB8PD4tW2N0aW1lXQ0KfCAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgIHw8Pi17MC4uKn0tW0J5dGUgUnVuXQ0KfCAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8Pi17MS4uKn0tW0hhc2hdDQp8ICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDw+LVtI YXNoIFR5cGVdDQp8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfDw+LVtIYXNoIFNpemVdDQp8ICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDw+LVtIYXNoIFZhbHVlXQ0KfCAg ICAgICAgICAgICAgICB8PD4tW0RpZ2l0YWwgU2lnbmF0dXJlXQ0KKy0tLS0tLS0tLS0tLS0tLS0r DQoNCg0KLnRpIDANCjMuMSBGb3JlbnNpY3MgVHlwZSBEZXNjcmlwdGlvbnMNCg0KQWxsIGRhdGUt dGltZSBzdGFtcHMgYXJlIGNvbXBhdGlibGUgd2l0aCB0aGUgZGF0ZS10aW1lIHN0cmluZ3MgYXMg ZGVmaW5lZCBpbiBJT0RFRiBbSU9ERUZdIHdoaWNoIGFyZSBjb21wYXRpYmxlIHdpdGggUkZDIDMz MzkgW1JGQzMzMzldLCBhIHJlc3RyaWN0ZWQgc3Vic2V0IG9mIElTTyA4NjAxOjIwMDAgW0lTTzg2 MDFdLg0KDQoudGkgMA0KMy4xLjEgSGVhZGVyIEluZm9ybWF0aW9uDQoNCi5pbiA5DQoudGkgNg0K TyBWZXJzaW9uIHtNYWpvcixNaW5vcn0gLSBUaGUgdmVyc2lvbiBudW1iZXIgb2YgdGhlIERpZ2l0 YWwgRm9yZW5zaWNzIGV4dGVuc2lvbiBzY2hlbWEgZGVmaW5pdGlvbi4gIFRoZXNlIHdpbGwgYmUg ZGVmaW5lZCB3aXRoaW4gdGhlIHN0YW5kYXJkIHNjaGVtYSwgYXZhaWxhYmxlIGZyb20gSUFOQS4N Cg0KLnRpIDYNCm8gU2l0ZSBOYW1lIC0gQSB0ZXh0IHN0cmluZyB3aGljaCBpcyBhIGh1bWFuIHJl YWRhYmxlIGRlZmluaXRpb24gb2YgdGhlIHNpdGUgdGhhdCBhbmFseXplZCB0aGUgY29udGFpbmVk IGZvcmVuc2ljcyBkYXRhLg0KDQoudGkgNg0KbyBDcmVhdG9yIE5hbWUgLSBUaGUgbmFtZSBvZiB0 aGUgZXhhbWluZXIgdGhhdCBhbmFseXplZCBvciBwcm92aWRlZCB0aGUgcmF3IGRhdGEgcHJlc2Vu dGVkIHdpdGhpbiB0aGUgc2lnbmVkIGZvcmVuc2ljcyBleHRlbnNpb24uDQoNCi50aSA2DQpvIEV2 aWRlbmNlIElEIC0gQSBzaXRlIHNwZWNpZmljIElEIHVzZWQgZm9yIHRyYWNraW5nIHRoZSBmb3Jl bnNpY3MgaW5mb3JtYXRpb24uICBGb3IgZXhhbXBsZSwgYSBjYXNlIG51bWJlciBmb3IgY2hhaW4g b2YgZXZpZGVuY2UgbWFpbnRlbmFuY2UuDQoNCi50aSA2DQpvIENyZWF0aW9uIFRpbWUgLSBUaGUg dGltZSB0aGlzIHJlY29yZCB3YXMgY3JlYXRlZC4NCg0KLnRpIDYNCm8gRGV2aWNlIFRpbWUgLSBB IHJlY29yZCBvZiB0aGUgY3JlYXRpb24gZnJvbSB0aGUgZm9yZW5zaWMgZGF0YSBzb3VyY2UuDQoN Ci50aSA2DQpvIFRvb2wgTmFtZSAtIEEgc3RyaW5nIGRlZmluaW5nIHRoZSB0b29sIHVzZWQgdG8g cHJvY2VzcyB0aGUgZm9yZW5zaWNzIGRhdGEuDQoNCi50aSA2DQpvIFRvb2wgVmVyc2lvbiAtIEEg dmVyc2lvbiBzdHJpbmcgY29udGFpbmluZyBhbGwgcmVsZXZhbnQgcmVsZWFzZSBpbmZvcm1hdGlv biBmb3IgdGhlIGdlbmVyYXRpbmcgZm9yZW5zaWNzIGRhdGEgdG9vbC4NCg0KLnRpIDYNCm8gSG9z dCBPcGVyYXRpbmcgU3lzdGVtIC0gVGhlIGhvc3Qgb3BlcmF0aW5nIHN5c3RlbSBvbiB3aGljaCB0 aGUgZm9yZW5zaWNzIHRvb2wgd2FzIHJ1bjsgZGVmaW5lZCBpbiBDUEUgW0NQRV0gZm9ybWF0Lg0K DQoNCi50aSAwDQozLjEuMiBEZXZpY2UvU291cmNlIEluZm9ybWF0aW9uDQoNCi5pbiA5DQoudGkg Ng0KbyBEZXZpY2UgVHlwZSAoZW51bT8/KQ0KLnRpIDYNCm8gRGV2aWNlIE1vZGVsDQoudGkgNg0K byBEZXZpY2UgU2VyaWFsDQoudGkgNg0KbyBTZWN0b3IgU2l6ZQ0KLnRpIDYNCm8gRGV2aWNlIFNl Y3RvcnMNCg0KDQoudGkgMA0KMy4xLjMgSGFzaCBJbmZvcm1hdGlvbg0KDQouaW4gOQ0KLnRpIDYN Cm8gSGFzaCBUeXBlIChlbnVtIE1ENSwgU0hBLTEsIFNIQS0yNTYpDQoNCi50aSA2DQpvIEhhc2gg U2l6ZSAob2N0ZXQgY291bnQgb2YgaGFzaCB2YWx1ZSkNCg0KLnRpIDYNCm8gSGFzaCBWYWx1ZQ0K DQoNCi50aSAwDQozLjEuNCBCeXRlIFJ1biBJbmZvcm1hdGlvbg0KDQouaW4gOQ0KLnRpIDYNCm8g Qnl0ZSBSdW4NCg0KLnRpIDANCjMuMS41IEZpbGUgT2JqZWN0IEluZm9ybWF0aW9uDQoNCi5pbiA5 DQoudGkgNg0KbyBGaWxlIE9iamVjdCAtIEEgY29sbGVjdGlvbiBvZiB2YWx1ZXMsIGNhcHR1cmlu ZyB0aGUgcmVsZXZhbnQgZmlsZSBzeXN0ZW0gbWV0YWRhdGEgYWxvbmcgd2l0aCByZWxldmFudCBm b3JlbnNpYyBkYXRhIChieXRlIHJ1bnMgYW5kIGhhc2hlcykgZm9yIGEgZmlsZSBvZiBpbnRlcmVz dC4NCg0KLnRpIDYNCm8gTmFtZSAtIFRoZSBuYW1lIG9mIHRoZSBmaWxlIGFzIGNhcHR1cmVkIGZy b20gdGhlIGZpbGUgc3lzdGVtIG1ldGFkYXRhLg0KDQoudGkgNg0KbyBJRCAtIEEgc2l0ZSBnZW5l cmF0ZWQgdW5pcXVlIG51bWJlci4NCg0KLnRpIDYNCm8gU2l6ZSAtIFRoZSBzaXplIG9mIHRoZSBm aWxlLCBhcyBjYXB0dXJlZCBmcm9tIHRoZSBmaWxlIHN5c3RlbSBtZXRhZGF0YS4NCg0KLnRpIDYN Cm8gUGFydGl0aW9uIC0gVGhlIHBhcnRpdGlvbiB0aGF0IHRoZSBmaWxlIHN5c3RlbSB0aGF0IGZp bGUgY2FtZSBmcm9tIHJlc2lkZXMgd2l0aGluLg0KDQoudGkgNg0KbyBNb2RlIC0gRmlsZSBwZXJt aXNzaW9uIG1vZGUgYXMgY2FwdHVyZWQgZnJvbSB0aGUgZmlsZSBzeXN0ZW0uDQoNCi50aSA2DQpv IEFDTCAtIFRoZSBhY2Nlc3MgY29udHJvbCBsaXN0IGFzIGNhcHR1cmVkIGZyb20gdGhlIGZpbGUg c3lzdGVtLg0KDQoudGkgNg0KbyBtdGltZSAtIEZpbGUgbW9kaWZpY2F0aW9uIHRpbWUgYXMgY2Fw dHVyZWQgZnJvbSB0aGUgbWV0YWRhdGEgZnJvbSB0aGUgZmlsZXN5c3RlbS4NCg0KLnRpIDYNCm8g YXRpbWUgLSBMYXN0IGZpbGUgYWNjZXNzIHRpbWUgYXMgY2FwdHVyZWQgZnJvbSB0aGUgbWV0YWRh dGEgZnJvbSB0aGUgZmlsZXN5c3RlbS4NCg0KLnRpIDYNCm8gY3RpbWUgLSBDcmVhdGlvbiB0aW1l IGFzIGNhcHR1cmVkIGZyb20gdGhlIG1ldGFkYXRhIGZyb20gdGhlIGZpbGVzeXN0ZW0uDQoNCg0K DQoudGkgMA0KMi4gIFRpdGxlDQoNCi5cIiBDb21tZW50IGxpbmUgcHJvdmlkaW5nIGluZm8gZm9y IHRoZSBBdXRob3JzIG9yIHRoZSBSRkMgRWRpdG9yDQo8RG9jdW1lbnQgdGV4dD4NCg0KLmluIDYN Ci5uZg0KRGVmaW5pdGlvbnMgYW5kIGNvZGUgew0KICBsaW5lIDENCiAgbGluZSAyDQp9DQouZmkN Ci5pbiAzDQoNCi5cIiBEaXJlY3RpdmVzIChlLmcgLnRpIGFuZCAuaW4pIGFuZCBlc2NhcGUgc2Vx dWVuY2VzIChcLCBcJiwgXCUsIFwiIGFuZCBcMCkgYXJlIHVzZWQgdG8gY29udHJvbA0KLlwiIEZv cm1hdHRpbmcgYW5kIGFyZSBub3QgZGlzcGxheWVkIGluIHRoZSB0ZXh0IGRvY3VtZW50Lg0KDQpT cGVjaWFsIGNoYXJhY3RlcnMgZXhhbXBsZXM6DQogDQpUaGUgY2hhcmFjdGVycyBcMCwgXCYsIFwl LCBcIiBhcmUgbm90IHNob3duIGluIHRleHQuDQouXCINCi5cIiBZb3UgY2FuIGRpc3BsYXkgdGhl c2UgY2hhcmFjdGVyIHNlcXVlbmNlcyBpbiB0aGUgdGV4dCBkb2N1bWVudCBieQ0KLlwiIGluc2Vy dGluZyB0aGUgZXNjYXBlIGNoYXJhY3RlciAnXCcuDQpIb3dldmVyLCB0aGUgY2hhcmFjdGVycyBc XDAsIFxcJiwgXFwlLCBcXCIgYXJlIGRpc3BsYXllZC4NCg0KXCYudGkgMCAgaXMgZGlzcGxheWVk IGluIHRleHQgaW5zdGVhZCBvZiB1c2VkIGFzIGEgZGlyZWN0aXZlLiANCi5icg0KXCYuXFwiICBp cyBkaXNwbGF5ZWQgaW4gZG9jdW1lbnQgaW5zdGVhZCBvZiBiZWluZyB0cmVhdGVkIGFzIGEgY29t bWVudA0KDQpDOlxcZGlyXFxzdWJkaXJcXGZpbGUuZXh0ICBTaG93cyBpbmNsdXNpb24gb2YgYmFj a3NsYXNoICJcXCIuDQoNCg0KLmJwDQoudGkgMA0KMyAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN Cg0KVGhpcyBzdGFuZGFyZCBpcyBhbiBleHRlbnNpb24gdG8gSU9ERUYgW0lPREVGXSBhbmQgYXMg c3VjaCwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRoYXQgYXBwbHkgdG8gSU9ERUYgYXBw bHkgdG8gdGhpcyBleHRlbnNpb24uDQoNCkluIGFkZGl0aW9uLCB0aGUgc2VjdXJpdHkgcHJvdmlk ZWQgYnkgdGhlIHJlbGF0ZWQgUklEIFtSSURdIGVuaGFuY2VtZW50cyBhcHBseSBlcXVhbGx5IHRv IHRoaXMgZXh0ZW5zaW9ucyBhcyB0byBJT0RFRiBbSU9ERUZdLg0KDQoudGkgMA0KNCAgSUFOQSBD b25zaWRlcmF0aW9ucw0KDQoNClJlZ2lzdHJhdGlvbiByZXF1ZXN0IGZvciB0aGUgSU9ERUYgRGln aXRhbCBGb3JlbnNpY3MgRXh0ZW5zaW9uIG5hbWVzcGFjZToNCg0KVVJJOiB1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOmlvZGVmLWRpZ2l0YWxmb3JlbnNpY3MtMS4wDQoNClJlZ2lzdHJhbnQgQ29udGFj dDoNCg0KQ2hyaXN0b3BoZXIgSW5hY2lvDQpDYXJuZWdpZSBNZWxsb24gVW5pdmVyc2l0eQ0KNDUw MCA1dGggQXZlDQpQaXR0c2J1cmdoLCBQQSAxNTIxMw0KVVNBDQppbmFjaW9AY2VydC5vcmcNCg0K WE1MOiBzY2hlbWEgaW4gQXBwZW5kaXggTi4NCg0KLnRpIDANCjUgIFJlZmVyZW5jZXMNCg0KLnRp IDAgDQo1LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCi5pbiAxNA0KLlwiIFwjIFJFRiAgLS0g TWFuYWdlZCByZWZlcmVuY2UgbGlzdC4gU3ludGF4OiBbUkZDXW5ubm5bO0xhYmVsXSwgLi4uICxb UkZDXW5ubm5bO0xhYmVsXQ0KLlwiIFwjIDIxMTk7S0VZV09SRFMsIDUwNzA7SU9ERUYsIDYwNDU7 UklELCAzMzM5DQoudGkgMw0KW0tFWVdPUkRTXSBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3Ig dXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQXDAxNCwgUkZD XDAyMTE5LCBNYXJjaCAxOTk3Lg0KDQoudGkgMw0KW0lPREVGXSAgICBEYW55bGl3LCBSLiwgTWVp amVyLCBKLiwgYW5kIFkuIERlbWNoZW5rbywgIlRoZSBJbmNpZGVudCBPYmplY3QgRGVzY3JpcHRp b24gRXhjaGFuZ2UgRm9ybWF0IiwgUkZDXDA1MDcwLCBEZWNlbWJlciAyMDA3Lg0KDQoudGkgMw0K W1JJRF0gICAgICBNb3JpYXJ0eSwgSy4sICJSZWFsLXRpbWUgSW50ZXItbmV0d29yayBEZWZlbnNl IChSSUQpIiwgUkZDXDA2MDQ1LCBOb3ZlbWJlciAyMDEwLg0KDQoudGkgMw0KW1JGQzMzMzldICBL bHluZSwgRy4gYW5kIEMuIE5ld21hbiwgIkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0OiBU aW1lc3RhbXBzIiwgUkZDXDAzMzM5LCBKdWx5IDIwMDIuDQoNCi5cIiBcIyBFUkYgLS0gRW5kIG9m IG1hbmFnZWQgcmVmZXJlbmNlIGxpc3QNCi5cIiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQouXCIgVGhlIHJlZmVyZW5jZSBsaXN0IGNhbiBiZSBjaGFuZ2VkIGF0IGFu eSB0aW1lIGJ5IGFsdGVyaW5nIHRoZSBSRkMgbGlzdCBpbiB0aGUgbGluZSBiZWxvdyB0aGUgLlwi IFwjIFJFRiBkaXJlY3RpdmUNCi5cIiBJbiBvcmRlciB0byBleGVjdXRlIGFueSBjaGFuZ2UsIGNs aWNrIG9uIHRoZSAnVXBkYXRlIEFsbCcgYnV0dG9uIG9yIHNlbGVjdCAiVXBkYXRlICdUYWJsZSBv ZiBDb250ZW50cycgYW5kIFJlZmVyZW5jZXMiDQouXCIgZnJvbSB0aGUgIkVkaXQiIG1lbnUgb3Ig cHJlc3MgPEYzPi4NCi5cIiBOT1RFOiBNYW5hZ2VkIHJlZmVyZW5jZSBsaXN0IHJlcXVpcmVzIE5y b2ZmRWRpdCB2ZXJzaW9uIDEuNDAgb3IgbGF0ZXIuDQoNCi50aSAwDQo1LjIgIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMNCg0KLmluIDE0DQouXCIgXCMgUkVGICAtLSBNYW5hZ2VkIHJlZmVyZW5jZSBs aXN0LiBTeW50YXg6IFtSRkNdbm5ubls7TGFiZWxdLCAuLi4gLFtSRkNdbm5ubls7TGFiZWxdDQou XCIgXCMNCi5cIiBcIyBFUkYgLS0gRW5kIG9mIG1hbmFnZWQgcmVmZXJlbmNlIGxpc3QNCg0KLnRp IDMNCltERlhNTF0JR2FyZmlua2VsLCBTLiwgIkRpZ2l0YWwgZm9yZW5zaWNzIFhNTCBhbmQgdGhl IERGWE1MIHRvb2xzZXQiLCBEaWdpdGFsIEludmVzdGlnYXRpb24sIDIwMTIuDQoNCi50aSAzDQpb REVYRl0JR2lsLCBZLiBILiwgSG9uZywgRC4sIFJ1dGtvd3NraSwgQS4gTS4sICJSZXZpc2VkIGRy YWZ0IG9uIFJlY29tbWVuZGF0aW9uIElUVS1UIFguZGVmOiBkaWdpdGFsIGZvcmVuc2ljcyBleGNo YW5nZSBmb3JtYXQiLCBJVFUgU3R1ZHkgR3JvdXAgMTcsIFNlcHRlbWJlciAyLCAyMDExLg0KDQou dGkgMw0KW05JSjE5OTQwOF0JIk5JSiBTcGVjaWFsIFJlcG9ydCAxOTk0MDg6IEZvcmVuc2ljIEV4 YW1pbmF0aW9uIG9mIERpZ2l0YWwgRXZpZGVuY2U6IEEgR3VpZGUgZm9yIExhdyBFbmZvcmNlbWVu dCIgDQoNCi50aSAzDQpbSVNPODYwMV0JSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0 YW5kYXJkaXphdGlvbiwgIkludGVybmF0aW9uYWwNCiAgICAgICAgIFN0YW5kYXJkOiBEYXRhIGVs ZW1lbnRzIGFuZCBpbnRlcmNoYW5nZSBmb3JtYXRzIC0gSW5mb3JtYXRpb24NCiAgICAgICAgIGlu dGVyY2hhbmdlIC0gUmVwcmVzZW50YXRpb24gb2YgZGF0ZXMgYW5kIHRpbWVzIiwgSVNPIDg2MDEs DQogICAgICAgICBTZWNvbmQgRWRpdGlvbiwgRGVjZW1iZXIgMjAwMC4NCi5pbiAzDQoNCg0KLnRp IDANCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQouc3ANCi5uZg0KQ2hyaXN0b3BoZXIgSW5hY2lvDQo0 NTAwIDV0aCBBdmUuDQpQaXR0c2J1cmdoLCBQQSAxNTE0Mw0KVVNBDQoNCkVNYWlsOiBpbmFjaW9A Y2VydC5vcmcNCi5zcA0KLmZpDQoNCi50aSAwDQpBcHBlbmRpeCBBOiBEaWdpdGFsIEZvcmVuc2lj cyBYTUwgU2NoZW1hDQoNCltbcHJlbGltaW5hcnkgc2NoZW1hIGhlcmVdXQ0KDQouXCIgSG93IGRv IHlvdSBibG9jayBxdW90ZSBpbiBucm9mZj8NCi5uZiA4MA0KPD94bWwgdmVyc2lvbj0iMS4wIiBl bmNvZGluZz0iVVRGLTgiPz4NCjx4c2Q6c2NoZW1hIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5v cmcvMjAwMS9YTUxTY2hlbWEiIA0KICAgICAgICAgICAgeG1sbnM6ZGlnaXRhbGZvcmVuc2ljcz0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi1kaWdpdGFsZm9yZW5zaWNzLTEuMCINCiAgICAg ICAgICAgIHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi1kaWdp dGFsZm9yZW5zaWNzLTEuMCIgDQogICAgICAgICAgICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxp ZmllZCINCiAgICAgICAgICAgIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCI+DQog ICAgDQogICAgDQogICAgPHhzZDplbGVtZW50IG5hbWU9ImRpZ2l0YWxmb3JlbnNpY3MiIHR5cGU9 ImRpZ2l0YWxmb3JlbnNpY3NUeXBlIi8+DQogICAgDQogICAgPHhzZDplbGVtZW50IG5hbWU9ImRp Z2l0YWxmb3JlbnNpY3NUeXBlIi8+DQogICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJkaWdpdGFs Zm9yZW5zaWNzVHlwZSI+DQogICAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9Ik1ham9yVmVyc2lv biJ0eXBlPSJ4c2Q6aW50ZWdlciIgdXNlPSJyZXF1aXJlZCIvPg0KICAgICAgICA8eHNkOmF0dHJp YnV0ZSBuYW1lPSJNaW5vclZlcnNpb24idHlwZT0ieHNkOmludGVnZXIiIHVzZT0icmVxdWlyZWQi Lz4NCiAgICA8L3hzZDpjb21wbGV4VHlwZT4NCg0KDQogICAgPCEtLSBIQVNIIHR5cGUgZGVmaW5p dGlvbiAtLT4NCiAgICA8eHNkOnNpbXBsZVR5cGUgbmFtZT0iaGFzaFR5cGUiPg0KICAgICAgICA8 eHNkOnJlc3RyaWN0aW9uIGJhc2U9InhzZDpzdHJpbmciPg0KICAgICAgICAgICAgPHhzZDplbnVt ZXJhdGlvbiB2YWx1ZT0iTUQ1Ii8+DQogICAgICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVl PSJTSEEtMSIvPg0KICAgICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iU0hBLTI1NiIv Pg0KICAgICAgICA8L3hzZDpyZXN0cmljdGlvbj4NCiAgICA8L3hzZDpzaW1wbGVUeXBlPg0KICAg IDx4c2Q6c2ltcGxlVHlwZSBuYW1lPSJoYXNoU2l6ZSIgdHlwZT0ieHNkOmludGVnZXIiLz4NCiAg ICA8eHNkOnNpbXBsZVR5cGUgbmFtZT0iaGFzaFZhbHVlIiB0eXBlPSJ4c2Q6c3RyaW5nIj4NCiAg ICAgICAgPHhzZDpyZXN0cmljdGlvbj4NCiAgICAgICAgICAgIDxwYXR0ZXJuIHZhbHVlPSdbYS1m QS1GMC05XSsnPg0KICAgICAgICA8L3hzZDpyZXN0cmljdGlvbj4NCiAgICA8L3hzZDpzaW1wbGVU eXBlPg0KICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0iaGFzaCI+DQogICAgICAgIDx4c2Q6c2Vx dWVuY2U+DQogICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJoYXNoVHlwZSIvPg0KICAgICAg ICAgICAgPHhzZDplbGVtZW50IHJlZj0iaGFzaFNpemUiLz4NCiAgICAgICAgICAgIDx4c2Q6ZWxl bWVudCByZWY9Imhhc2hWYWx1ZSIvPg0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4NCiAgICA8L3hz ZDpjb21wbGV4VHlwZT4NCiAgICANCiAgICA8IS0tIGJ5dGUgcnVucyAtLT4NCiAgICA8eHNkOmVs ZW1lbnQgbmFtZT0icnVuIj4NCiAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4NCiAgICAgICAgICAg IDx4c2Q6YXR0cmlidXRlIG5hbWU9ImZpbGVzeXN0ZW1fb2Zmc2V0IiB0eXBlPSJ4c2Q6bm9uTmVn YXRpdmVJbnRlZ2VyIi8+DQogICAgICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJmaWxlX29m ZnNldCIgdHlwZT0ieHNkOm5vbk5lZ2F0aXZlSW50ZWdlciIvPg0KICAgICAgICAgICAgPHhzZDph dHRyaWJ1dGUgbmFtZT0iaW1hZ2Vfb2Zmc2V0IiB0eXBlPSJ4c2Q6bm9uTmVnYXRpdmVJbnRlZ2Vy Ii8+DQogICAgICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJsZW4iIHR5cGU9InhzZDpub25O ZWdhdGl2ZUludGVnZXIiLz4NCiAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+DQogICAgICAgIDx4 c2Q6ZWxlbWVudCByZWY9Imhhc2giLz4NCiAgICA8L3hzZDplbGVtZW50Pg0KICAgIDx4c2Q6ZWxl bWVudCBuYW1lPSJieXRlX3J1biI+DQogICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+DQogICAgICAg ICAgICA8eHNkOnNlcXVlbmNlPg0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCByZWY9InJ1 biIgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgICAgICAgPC94 c2Q6c2VxdWVuY2U+DQogICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPg0KICAgIDwveHNkOmVsZW1l bnQ+DQoNCiAgICA8IS0tIEZpbGUgT2JqZWN0IERlZmluaXRpb24gLS0+DQogICAgPCEtLSBuYW1l LCBJRCwgU2l6ZSwgUGFydGl0aW9uLCBNb2RlLCBBQ0wsIG10aW1lLCBhdGltZSwgY3RpbWUgLS0+ DQogICAgPHhzZDplbGVtZW50IG5hbWU9ImZpbGVfb2JqZWN0Ij4NCiAgICAgICAgPHhzZDpjb21w bGV4VHlwZT4NCiAgICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+DQogICAgICAgICAgICAgICAgPCEt LSA8eHNkOmVsZW1lbnQgbmFtZT0iIiB0eXBlPSIiIG1pbk9jY3Vycz0iIi8+IC0tPg0KICAgICAg ICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJmaWxlbmFtZSIgdHlwZT0ieHNkOnN0cmluZyIg bWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4NCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0iaWQiIHR5cGU9InhzZDpzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICAg ICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJmaWxlc2l6ZSIgdHlwZT0ieHNkOnBvc2l0aXZlSW50 ZWdlciIgbWluT2NjdXJzPSIwIi8+DQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9 InBhcnRpdGlvbiIgdHlwZT0ieHNkOm5vbk5lZ2F0aXZlSW50ZWdlciIgbWluT2NjdXJzPSIwIi8+ DQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Im1vZGUiIHR5cGU9InhzZDpub25O ZWdhdGl2ZUludGVnZXIiIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxl bWVudCBuYW1lPSJhY2wiIHR5cGU9InhzZDpzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAgICAg ICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJtdGltZSIgdHlwZT0iIiBtaW5PY2N1cnM9IjAi Lz4NCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iYXRpbWUiIHR5cGU9IiIgbWlu T2NjdXJzPSIwIi8+DQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9ImN0aW1lIiB0 eXBlPSIiIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCByZWY9 ImJ5dGVfcnVuIiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQg cmVmPSJoYXNoIiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPg0K ICAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4NCiAgICA8L3hzZDplbGVtZW50Pg0KDQo8L3hzZDpz Y2hlbWE+DQoNCg0K --_003_65E2E0B1101A41578C149B1FA5F1D0FAcertorg_ Content-Type: text/plain; name="draft-ietf-mile-digitalForensics-00.txt" Content-Description: draft-ietf-mile-digitalForensics-00.txt Content-Disposition: attachment; filename="draft-ietf-mile-digitalForensics-00.txt"; size=19342; creation-date="Tue, 28 Feb 2012 21:00:36 GMT"; modification-date="Tue, 28 Feb 2012 21:00:36 GMT" Content-Transfer-Encoding: base64 IA0NDQoNDQ0KDQ0NCg0NDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDaHJpc3RvcGhlciBJbmFjaW8NDQ0KSW50ZW5kZWQgU3RhdHVzOiBQcm9w b3NlZCBTdGFuZGFyZCAgICAgICAgICAgIENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5DQ0NCkV4 cGlyZXM6IDxFeHBpcnkgRGF0ZT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxJc3N1ZSBEYXRlPg0NDQoNDQ0KDQ0NCiAgICAgICAgICAgICAgICAgRGlnaXRhbCBGb3JlbnNp Y3MgRXh0ZW5zaW9uIGZvciBJT0RFRiANDQ0KICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1t aWxlLWRpZ2l0YWxGb3JlbnNpY3MtMDANDQ0KDQ0NCg0NDQpBYnN0cmFjdA0NDQoNDQ0KICAgVGhp cyBleHRlbnNpb24gdG8gSU9ERUYgKFJGQyA1MDcwKSBpcyBkZXNpZ25lZCB0byBhaWQgaW4gdGhl IHNoYXJpbmcNDQ0KICAgYW5kIGRpc3NlbWluYXRpb24gb2YgZGlnaXRhbCBmb3JlbnNpY3MgaW5m b3JtYXRpb24uICBUaGUgZ29hbCBpcyB0bw0NDQogICBhbGxvdyBhIHRvb2wgaW5kZXBlbmRlbnQg Zm9ybWF0IHRvIHNoYXJlIGluZm9ybWF0aW9uIGJldHdlZW4NDQ0KICAgb3JnYW5pemF0aW9ucyBm b2N1c2VkIG9uIGRpZ2l0YWwgZm9yZW5zaWNzOiBkcml2ZSBpbWFnZXMsIGZpbGUNDQ0KICAgY2Fy dmluZywgbWV0YWRhdGEsIGFuZCByZWxhdGVkIGhhc2hlcy4gIEFzIHdpdGggSU9ERUYgYW5kIGl0 cw0NDQogICBleHRlbnNpb25zLCBpdCBpcyBkZWZpbmVkIHVzaW5nIFhNTC4NDQ0KDQ0NCg0NDQpT dGF0dXMgb2YgdGhpcyBNZW1vDQ0NCg0NDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1p dHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNDQ0KICAgcHJvdmlzaW9u cyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NDQ0KDQ0NCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQ0NCiAgIFRhc2sgRm9y Y2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQN DQ0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMg YXMNDQ0KICAgSW50ZXJuZXQtRHJhZnRzLg0NDQoNDQ0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQ0NCiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55DQ0NCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlDQ0NCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINDQ0KDQ0NCiAgIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0NDQogICBodHRwOi8vd3d3Lmll dGYub3JnLzFpZC1hYnN0cmFjdHMuaHRtbA0NDQoNDQ0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0NDQogICBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQ0NCg0NDQoNDQ0KQ29weXJpZ2h0IGFuZCBMaWNlbnNl IE5vdGljZQ0NDQoNDQ0KICAgQ29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQ0NCiAgIGRvY3VtZW50IGF1dGhvcnMuIEFsbCByaWdo dHMgcmVzZXJ2ZWQuDQ0NCg0NDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4 IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQ0NCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8g SUVURiBEb2N1bWVudHMNDQ0KIA0NDQoNDQ0KDQ0NCkNocmlzdG9waGVyIEluYWNpbyAgICAgIEV4 cGlyZXMgQXVndXN0IDIyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0NDQoMDQ0NCklO VEVSTkVUIERSQUZUICAgRGlnaXRhbCBGb3JlbnNpY3MgRXh0ZW5zaW9uIGZvciBJT0RFRiBGZWJy dWFyeSAxOSwgMjAxMg0NDQoNDQ0KDQ0NCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZg0NDQogICBwdWJsaWNhdGlvbiBvZiB0 aGlzIGRvY3VtZW50LiBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cw0NDQogICBjYXJlZnVs bHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QNDQ0KICAgdG8gdGhpcyBkb2N1bWVudC4gQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBm cm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0NDQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNDQ0KICAgdGhlIFRydXN0IExl Z2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQ0NCiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NDQ0KDQ0NCg0NDQoNDQ0K VGFibGUgb2YgQ29udGVudHMNDQ0KDQ0NCiAgIDEgIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0NDQogICAgIDEuMSAgVGVy bWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDMNDQ0KICAgMi4gRm9yZW5zaWMgRXh0ZW5zaW9uIHRvIElPREVGIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAzDQ0NCiAgIDMuIEZvcmVuc2ljcyBEYXRhICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0NDQogICAgIDMuMSBGb3Jl bnNpY3MgVHlwZSBEZXNjcmlwdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQNDQ0KICAgICAgIDMuMS4xIEhlYWRlciBJbmZvcm1hdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0DQ0NCiAgICAgICAzLjEuMiBEZXZpY2UvU291cmNlIEluZm9y bWF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0NDQogICAgICAgMy4xLjMg SGFzaCBJbmZvcm1hdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDUNDQ0KICAgICAgIDMuMS40IEJ5dGUgUnVuIEluZm9ybWF0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA1DQ0NCiAgICAgICAzLjEuNSBGaWxlIE9iamVjdCBJbmZvcm1h dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0NDQogICAyLiAgVGl0bGUg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDYNDQ0KICAgMyAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA3DQ0NCiAgIDQgIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0NDQogICA1ICBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDcNDQ0KICAgICA1LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA3DQ0NCiAgICAgNS4yICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0NDQogICBBdXRob3JzJyBB ZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDgNDQ0KICAgQXBwZW5kaXggQTogRGlnaXRhbCBGb3JlbnNpY3MgWE1MIFNjaGVtYSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA4DQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0K DQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCiANDQ0KDQ0NCg0NDQpDaHJp c3RvcGhlciBJbmFjaW8gICAgICBFeHBpcmVzIEF1Z3VzdCAyMiwgMjAxMiAgICAgICAgICAgICAg ICAgW1BhZ2UgMl0NDQ0KDA0NDQpJTlRFUk5FVCBEUkFGVCAgIERpZ2l0YWwgRm9yZW5zaWNzIEV4 dGVuc2lvbiBmb3IgSU9ERUYgRmVicnVhcnkgMTksIDIwMTINDQ0KDQ0NCg0NDQoxICBJbnRyb2R1 Y3Rpb24NDQ0KDQ0NCiAgIFRoaXMgZXh0ZW5zaW9uIHRvIElPREVGIGlzIGRlc2lnbmVkIHRvIGNh cnJ5IGRpZ2l0YWwgZm9yZW5zaWNzDQ0NCiAgIGluZm9ybWF0aW9uIGluIGEgd2F5IGFjY2VwdGFi bGUgZm9yIGNoYWluIG9mIGV2aWRlbmNlIGhhbmRsaW5nIGFuZA0NDQogICBnZW5lcmFsIGZvcmVu c2ljcyBleGFtaW5hdGlvbi4gIFRoZXJlIGFyZSB2YXJpb3VzIHByb2dyYW1zIHRoYXQNDQ0KICAg Z2VuZXJhdGUgZm9yZW5zaWNzIGluZm9ybWF0aW9uLCBidXQgZmV3IHRoYXQgZ2VuZXJhdGUgdGhh dA0NDQogICBpbmZvcm1hdGlvbiBpbiBhIHdheSB0aGF0IGlzIGV4Y2hhbmdlYWJsZSBpbiBhIHVu aXZlcnNhbCB3YXkuDQ0NCg0NDQogICBUaGVyZSBoYXZlIGJlZW4gc29tZSBlZmZvcnRzIHRvIGNy ZWF0ZSBpbmRlcGVuZGVudCBzdGFuZGFyZHMsIG9mdGVuDQ0NCiAgIFhNTCBiYXNlZCwgdG8gZXhj aGFuZ2UgZGlnaXRhbCBmb3JlbnNpY3MgaW5mb3JtYXRpb24uICBJbmRlZWQsIHRoaXMNDQ0KICAg c3RhbmRhcmQgaXMgZGVzaWduZWQgdG8gaW5jb3Jwb3JhdGUgZmVhdHVyZXMgZnJvbSB0aG9zZSBl ZmZvcnRzLA0NDQogICBERlhNTCwgREVYRiwgSU9DLCBhbmQgREZSV1MuICBCeSBleHRlbmRpbmcg SU9ERUYsIGhvd2V2ZXIsIHRoZSBnb2FsDQ0NCiAgIG9mIHRoaXMgc3RhbmRhcmQgaXMgdG8gYnVp bGQgdXBvbiBhIHdpZGVseSB1c2VkIElFVEYgc3RhbmRhcmQsIHRha2UNDQ0KICAgYWR2YW50YWdl IG9mIHRoZSBvdGhlciBmZWF0dXJlcyB3aXRoaW4gdGhlIElPREVGIGZhbWlseSBvZiBzdGFuZGFy ZHMuDQ0NCg0NDQogICBUaGUgbWFpbiBwaWVjZXMgb2YgaW5mb3JtYXRpb24gdGhpcyBleHRlbnNp b24gc2Vla3MgdG8gYmUgYWJsZSB0bw0NDQogICBjb252ZXkgYXJlIGluZm9ybWF0aW9uIGFib3V0 IGZpbGUgc3lzdGVtcyBhbmQgdGhlIHJlc3VsdGluZyBwcm9kdWN0cw0NDQogICBmcm9tIGFuYWx5 emluZyBmaWxlIHN5c3RlbXMuICBUaGlzIGluY2x1ZGVzIGluZm9ybWF0aW9uIGFib3V0IGZpbGUN DQ0KICAgY2FydmluZywgc3lzdGVtIG1ldGFkYXRhIGluY2x1ZGluZyBkaXNrIG1ldGFkYXRhLg0N DQoNDQ0KMS4xICBUZXJtaW5vbG9neQ0NDQoNDQ0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJN VVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0NDQogICAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcw0NDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGlu IFJGQyAyMTE5IFtSRkMyMTE5XS4NDQ0KDQ0NCjIuIEZvcmVuc2ljIEV4dGVuc2lvbiB0byBJT0RF Rg0NDQoNDQ0KICAgVGhlIEZvcmVuc2ljcyBEYXRhIGlzIGNhcHR1cmVkIHdpdGhpbiBhIG5ldyBj bGFzcyB3aXRoaW4gSU9ERUYncw0NDQogICBFdmVudCBEYXRhIGNsYXNzLCB3aXRoaW4gaXRzIEFk ZGl0aW9uYWwgRGF0YSBjbGFzcy4gIFRoZSBGb3JlbnNpY3MNDQ0KICAgRGF0YSBpcyBub3QgcmVx dWlyZWQgdG8gYmUgcHJlc2VudCwgYW5kIG1heSBvY2N1ciBhbiB1bmxpbWl0ZWQgbnVtYmVyDQ0N CiAgIG9mIHRpbWVzIGFzIG5lZWRlZC4NDQ0KDQ0NCiAgICstLS0tLS0tLS0tLS0tKw0NDQogICB8 ICAgSW5jaWRlbnQgIHwNDQ0KICAgKy0tLS0tLS0tLS0tLS0rDQ0NCiAgIHwgICAgICAuICAgICAg fA0NDQogICB8ICAgICAgLiAgICAgIHwNDQ0KICAgfCAgICAgIC4gICAgICB8DQ0NCiAgIHwgRXZl bnQgRGF0YSAgfDw+LXswLi4qfS1bIEV2ZW50IERhdGEgXQ0NDQogICB8ICAgICAgICAgICAgIHwg ICAgICAgICAgICB8PD4tezAuLip9LVsgQWRkaXRpb25hbCBEYXRhIF0NDQ0KICAgfCAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8PD4tezAuLip9LVsgRm9yZW5zaWNzIERh dGFdDQ0NCiAgIHwgICAgICAgICAgICAgfA0NDQogICArLS0tLS0tLS0tLS0tLSsNDQ0KDQ0NCg0N DQoNDQ0KMy4gRm9yZW5zaWNzIERhdGENDQ0KIA0NDQoNDQ0KDQ0NCkNocmlzdG9waGVyIEluYWNp byAgICAgIEV4cGlyZXMgQXVndXN0IDIyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0N DQoMDQ0NCklOVEVSTkVUIERSQUZUICAgRGlnaXRhbCBGb3JlbnNpY3MgRXh0ZW5zaW9uIGZvciBJ T0RFRiBGZWJydWFyeSAxOSwgMjAxMg0NDQoNDQ0KDQ0NCiAgICstLS0tLS0tLS0tLS0tLS0tKw0N DQogICB8IEZvcmVuc2ljcyBEYXRhIHwNDQ0KICAgKy0tLS0tLS0tLS0tLS0tLS0rDQ0NCiAgIHwg ICAgICAgICAgICAgICAgfDw+LVtWZXJzaW9uXQ0NDQogICB8ICAgICAgICAgICAgICAgIHwgICAg fDw+LVtNYWpvcl0NDQ0KICAgfCAgICAgICAgICAgICAgICB8ICAgIHw8Pi1bTWlub3JdDQ0NCiAg IHwgICAgICAgICAgICAgICAgfDw+LVtTaXRlIE5hbWVdDQ0NCiAgIHwgICAgICAgICAgICAgICAg fDw+LVtFeGFtaW5lciBOYW1lXQ0NDQogICB8ICAgICAgICAgICAgICAgIHw8Pi1bRXZpZGVuY2Ug SURdDQ0NCiAgIHwgICAgICAgICAgICAgICAgfDw+LVtDcmVhdGlvbiBUaW1lXQ0NDQogICB8ICAg ICAgICAgICAgICAgIHw8Pi1bVG9vbCBOYW1lXQ0NDQogICB8ICAgICAgICAgICAgICAgIHw8Pi1b VG9vbCBWZXJzaW9uXQ0NDQogICB8ICAgICAgICAgICAgICAgIHw8Pi1bSG9zdCBPcGVyYXRpbmcg U3lzdGVtXQ0NDQogICB8ICAgICAgICAgICAgICAgIHwNDQ0KICAgfCAgICAgICAgICAgICAgICB8 PD4tW0RldmljZV0NDQ0KICAgfCAgICAgICAgICAgICAgICB8ICAgICAgIHw8Pi1bRGV2aWNlIFR5 cGVdDQ0NCiAgIHwgICAgICAgICAgICAgICAgfCAgICAgICB8PD4tW0RldmljZSBNb2RlbF0NDQ0K ICAgfCAgICAgICAgICAgICAgICB8ICAgICAgIHw8Pi1bRGV2aWNlIFNlcmlhbF0NDQ0KICAgfCAg ICAgICAgICAgICAgICB8ICAgICAgIHw8Pi17MC4uMX0tW1NlY3RvciBTaXplXQ0NDQogICB8ICAg ICAgICAgICAgICAgIHwgICAgICAgfDw+LXswLi4xfS1bRGV2aWNlIFNlY3RvcnNdDQ0NCiAgIHwg ICAgICAgICAgICAgICAgfCAgICAgICB8PD4tezAuLip9LVtIYXNoXQ0NDQogICB8ICAgICAgICAg ICAgICAgIHwgICAgICAgfCAgICAgICAgICAgIHw8Pi1bSGFzaCBUeXBlXQ0NDQogICB8ICAgICAg ICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgIHw8Pi1bSGFzaCBTaXplXQ0NDQogICB8ICAg ICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgIHw8Pi1bSGFzaCBWYWx1ZV0NDQ0KICAg fCAgICAgICAgICAgICAgICB8ICAgICAgIHw8Pi17MC4uKn0tW0ZpbGUgT2JqZWN0XQ0NDQogICB8 ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfDw+LVtOYW1lXQ0NDQogICB8ICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfDw+LVtJRF0NDQ0KICAgfCAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHw8Pi1bU2l6ZV0NDQ0KICAgfCAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgIHw8Pi1bUGFydGl0aW9uXQ0NDQogICB8ICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgfDw+LVtNb2RlXQ0NDQogICB8ICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgfDw+LVtBQ0xdDQ0NCiAgIHwgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICB8PD4tW210aW1lXQ0NDQogICB8ICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgfDw+LVthdGltZV0NDQ0KICAgfCAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgIHw8Pi1bY3RpbWVdDQ0NCiAgIHwgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICB8PD4tezAuLip9LVtCeXRlIFJ1bl0NDQ0KICAgfCAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8Pi17MS4uKn0tW0hhc2hdDQ0NCiAg IHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8PD4tW0hhc2ggVHlwZV0NDQ0KICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8Pi1bSGFzaCBTaXplXQ0NDQogICB8ICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fDw+LVtIYXNoIFZhbHVlXQ0NDQogICB8ICAgICAgICAgICAgICAgIHw8Pi1bRGlnaXRhbCBTaWdu YXR1cmVdDQ0NCiAgICstLS0tLS0tLS0tLS0tLS0tKw0NDQoNDQ0KDQ0NCjMuMSBGb3JlbnNpY3Mg VHlwZSBEZXNjcmlwdGlvbnMNDQ0KDQ0NCiAgIEFsbCBkYXRlLXRpbWUgc3RhbXBzIGFyZSBjb21w YXRpYmxlIHdpdGggdGhlIGRhdGUtdGltZSBzdHJpbmdzIGFzIGRlZmluZWQgaW4gSU9ERUYgW0lP REVGXSB3aGljaCBhcmUgY29tcGF0aWJsZSB3aXRoIFJGQyAzMzM5IFtSRkMzMzM5XSwgYSByZXN0 cmljdGVkIHN1YnNldCBvZiBJU08gODYwMToyMDAwIFtJU084NjAxXS4NDQ0KDQ0NCjMuMS4xIEhl YWRlciBJbmZvcm1hdGlvbg0NDQogDQ0NCg0NDQoNDQ0KQ2hyaXN0b3BoZXIgSW5hY2lvICAgICAg RXhwaXJlcyBBdWd1c3QgMjIsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQ0NCgwNDQ0K SU5URVJORVQgRFJBRlQgICBEaWdpdGFsIEZvcmVuc2ljcyBFeHRlbnNpb24gZm9yIElPREVGIEZl YnJ1YXJ5IDE5LCAyMDEyDQ0NCg0NDQoNDQ0KICAgICAgTyBWZXJzaW9uIHtNYWpvcixNaW5vcn0g LSBUaGUgdmVyc2lvbiBudW1iZXIgb2YgdGhlIERpZ2l0YWwgRm9yZW5zaWNzIGV4dGVuc2lvbiBz Y2hlbWEgZGVmaW5pdGlvbi4gIFRoZXNlIHdpbGwgYmUgZGVmaW5lZCB3aXRoaW4gdGhlIHN0YW5k YXJkIHNjaGVtYSwgYXZhaWxhYmxlIGZyb20gSUFOQS4NDQ0KDQ0NCiAgICAgIG8gU2l0ZSBOYW1l IC0gQSB0ZXh0IHN0cmluZyB3aGljaCBpcyBhIGh1bWFuIHJlYWRhYmxlIGRlZmluaXRpb24gb2Yg dGhlIHNpdGUgdGhhdCBhbmFseXplZCB0aGUgY29udGFpbmVkIGZvcmVuc2ljcyBkYXRhLg0NDQoN DQ0KICAgICAgbyBDcmVhdG9yIE5hbWUgLSBUaGUgbmFtZSBvZiB0aGUgZXhhbWluZXIgdGhhdCBh bmFseXplZCBvciBwcm92aWRlZCB0aGUgcmF3IGRhdGEgcHJlc2VudGVkIHdpdGhpbiB0aGUgc2ln bmVkIGZvcmVuc2ljcyBleHRlbnNpb24uDQ0NCg0NDQogICAgICBvIEV2aWRlbmNlIElEIC0gQSBz aXRlIHNwZWNpZmljIElEIHVzZWQgZm9yIHRyYWNraW5nIHRoZSBmb3JlbnNpY3MgaW5mb3JtYXRp b24uICBGb3IgZXhhbXBsZSwgYSBjYXNlIG51bWJlciBmb3IgY2hhaW4gb2YgZXZpZGVuY2UgbWFp bnRlbmFuY2UuDQ0NCg0NDQogICAgICBvIENyZWF0aW9uIFRpbWUgLSBUaGUgdGltZSB0aGlzIHJl Y29yZCB3YXMgY3JlYXRlZC4NDQ0KDQ0NCiAgICAgIG8gRGV2aWNlIFRpbWUgLSBBIHJlY29yZCBv ZiB0aGUgY3JlYXRpb24gZnJvbSB0aGUgZm9yZW5zaWMgZGF0YSBzb3VyY2UuDQ0NCg0NDQogICAg ICBvIFRvb2wgTmFtZSAtIEEgc3RyaW5nIGRlZmluaW5nIHRoZSB0b29sIHVzZWQgdG8gcHJvY2Vz cyB0aGUgZm9yZW5zaWNzIGRhdGEuDQ0NCg0NDQogICAgICBvIFRvb2wgVmVyc2lvbiAtIEEgdmVy c2lvbiBzdHJpbmcgY29udGFpbmluZyBhbGwgcmVsZXZhbnQgcmVsZWFzZSBpbmZvcm1hdGlvbiBm b3IgdGhlIGdlbmVyYXRpbmcgZm9yZW5zaWNzIGRhdGEgdG9vbC4NDQ0KDQ0NCiAgICAgIG8gSG9z dCBPcGVyYXRpbmcgU3lzdGVtIC0gVGhlIGhvc3Qgb3BlcmF0aW5nIHN5c3RlbSBvbiB3aGljaCB0 aGUgZm9yZW5zaWNzIHRvb2wgd2FzIHJ1bjsgZGVmaW5lZCBpbiBDUEUgW0NQRV0gZm9ybWF0Lg0N DQoNDQ0KDQ0NCjMuMS4yIERldmljZS9Tb3VyY2UgSW5mb3JtYXRpb24NDQ0KDQ0NCiAgICAgIG8g RGV2aWNlIFR5cGUgKGVudW0/PykNDQ0KICAgICAgbyBEZXZpY2UgTW9kZWwNDQ0KICAgICAgbyBE ZXZpY2UgU2VyaWFsDQ0NCiAgICAgIG8gU2VjdG9yIFNpemUNDQ0KICAgICAgbyBEZXZpY2UgU2Vj dG9ycw0NDQoNDQ0KDQ0NCjMuMS4zIEhhc2ggSW5mb3JtYXRpb24NDQ0KDQ0NCiAgICAgIG8gSGFz aCBUeXBlIChlbnVtIE1ENSwgU0hBLTEsIFNIQS0yNTYpDQ0NCg0NDQogICAgICBvIEhhc2ggU2l6 ZSAob2N0ZXQgY291bnQgb2YgaGFzaCB2YWx1ZSkNDQ0KDQ0NCiAgICAgIG8gSGFzaCBWYWx1ZQ0N DQoNDQ0KDQ0NCjMuMS40IEJ5dGUgUnVuIEluZm9ybWF0aW9uDQ0NCg0NDQogICAgICBvIEJ5dGUg UnVuDQ0NCg0NDQozLjEuNSBGaWxlIE9iamVjdCBJbmZvcm1hdGlvbg0NDQoNDQ0KICAgICAgbyBG aWxlIE9iamVjdCAtIEEgY29sbGVjdGlvbiBvZiB2YWx1ZXMsIGNhcHR1cmluZyB0aGUgcmVsZXZh bnQgZmlsZSBzeXN0ZW0gbWV0YWRhdGEgYWxvbmcgd2l0aCByZWxldmFudCBmb3JlbnNpYyBkYXRh IChieXRlIHJ1bnMgYW5kIGhhc2hlcykgZm9yIGEgZmlsZSBvZiBpbnRlcmVzdC4NDQ0KDQ0NCiAg ICAgIG8gTmFtZSAtIFRoZSBuYW1lIG9mIHRoZSBmaWxlIGFzIGNhcHR1cmVkIGZyb20gdGhlIGZp bGUgc3lzdGVtIG1ldGFkYXRhLg0NDQoNDQ0KICAgICAgbyBJRCAtIEEgc2l0ZSBnZW5lcmF0ZWQg dW5pcXVlIG51bWJlci4NDQ0KIA0NDQoNDQ0KDQ0NCkNocmlzdG9waGVyIEluYWNpbyAgICAgIEV4 cGlyZXMgQXVndXN0IDIyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0NDQoMDQ0NCklO VEVSTkVUIERSQUZUICAgRGlnaXRhbCBGb3JlbnNpY3MgRXh0ZW5zaW9uIGZvciBJT0RFRiBGZWJy dWFyeSAxOSwgMjAxMg0NDQoNDQ0KDQ0NCiAgICAgIG8gU2l6ZSAtIFRoZSBzaXplIG9mIHRoZSBm aWxlLCBhcyBjYXB0dXJlZCBmcm9tIHRoZSBmaWxlIHN5c3RlbSBtZXRhZGF0YS4NDQ0KDQ0NCiAg ICAgIG8gUGFydGl0aW9uIC0gVGhlIHBhcnRpdGlvbiB0aGF0IHRoZSBmaWxlIHN5c3RlbSB0aGF0 IGZpbGUgY2FtZSBmcm9tIHJlc2lkZXMgd2l0aGluLg0NDQoNDQ0KICAgICAgbyBNb2RlIC0gRmls ZSBwZXJtaXNzaW9uIG1vZGUgYXMgY2FwdHVyZWQgZnJvbSB0aGUgZmlsZSBzeXN0ZW0uDQ0NCg0N DQogICAgICBvIEFDTCAtIFRoZSBhY2Nlc3MgY29udHJvbCBsaXN0IGFzIGNhcHR1cmVkIGZyb20g dGhlIGZpbGUgc3lzdGVtLg0NDQoNDQ0KICAgICAgbyBtdGltZSAtIEZpbGUgbW9kaWZpY2F0aW9u IHRpbWUgYXMgY2FwdHVyZWQgZnJvbSB0aGUgbWV0YWRhdGEgZnJvbSB0aGUgZmlsZXN5c3RlbS4N DQ0KDQ0NCiAgICAgIG8gYXRpbWUgLSBMYXN0IGZpbGUgYWNjZXNzIHRpbWUgYXMgY2FwdHVyZWQg ZnJvbSB0aGUgbWV0YWRhdGEgZnJvbSB0aGUgZmlsZXN5c3RlbS4NDQ0KDQ0NCiAgICAgIG8gY3Rp bWUgLSBDcmVhdGlvbiB0aW1lIGFzIGNhcHR1cmVkIGZyb20gdGhlIG1ldGFkYXRhIGZyb20gdGhl IGZpbGVzeXN0ZW0uDQ0NCg0NDQoNDQ0KDQ0NCjIuICBUaXRsZQ0NDQoNDQ0KICAgICAgICAgPERv Y3VtZW50IHRleHQ+DQ0NCg0NDQogICAgICBEZWZpbml0aW9ucyBhbmQgY29kZSB7DQ0NCiAgICAg ICAgbGluZSAxDQ0NCiAgICAgICAgbGluZSAyDQ0NCiAgICAgIH0NDQ0KDQ0NCg0NDQogICBTcGVj aWFsIGNoYXJhY3RlcnMgZXhhbXBsZXM6DQ0NCg0NDQogICBUaGUgY2hhcmFjdGVycyAgLCAsICwg DQ0NCiAgIEhvd2V2ZXIsIHRoZSBjaGFyYWN0ZXJzIFwwLCBcJiwgXCUsIFwiIGFyZSBkaXNwbGF5 ZWQuDQ0NCg0NDQogICAudGkgMCAgaXMgZGlzcGxheWVkIGluIHRleHQgaW5zdGVhZCBvZiB1c2Vk IGFzIGEgZGlyZWN0aXZlLiANDQ0KICAgLlwiICBpcyBkaXNwbGF5ZWQgaW4gZG9jdW1lbnQgaW5z dGVhZCBvZiBiZWluZyB0cmVhdGVkIGFzIGEgY29tbWVudA0NDQoNDQ0KICAgQzpcZGlyXHN1YmRp clxmaWxlLmV4dCAgU2hvd3MgaW5jbHVzaW9uIG9mIGJhY2tzbGFzaCAiXCIuDQ0NCg0NDQoNDQ0K DQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQogDQ0NCg0NDQoNDQ0K Q2hyaXN0b3BoZXIgSW5hY2lvICAgICAgRXhwaXJlcyBBdWd1c3QgMjIsIDIwMTIgICAgICAgICAg ICAgICAgIFtQYWdlIDZdDQ0NCgwNDQ0KSU5URVJORVQgRFJBRlQgICBEaWdpdGFsIEZvcmVuc2lj cyBFeHRlbnNpb24gZm9yIElPREVGIEZlYnJ1YXJ5IDE5LCAyMDEyDQ0NCg0NDQoNDQ0KMyAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMNDQ0KDQ0NCiAgIFRoaXMgc3RhbmRhcmQgaXMgYW4gZXh0ZW5z aW9uIHRvIElPREVGIFtJT0RFRl0gYW5kIGFzIHN1Y2gsIHRoZQ0NDQogICBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyB0aGF0IGFwcGx5IHRvIElPREVGIGFwcGx5IHRvIHRoaXMgZXh0ZW5zaW9uLg0N DQoNDQ0KICAgSW4gYWRkaXRpb24sIHRoZSBzZWN1cml0eSBwcm92aWRlZCBieSB0aGUgcmVsYXRl ZCBSSUQgW1JJRF0NDQ0KICAgZW5oYW5jZW1lbnRzIGFwcGx5IGVxdWFsbHkgdG8gdGhpcyBleHRl bnNpb25zIGFzIHRvIElPREVGIFtJT0RFRl0uDQ0NCg0NDQo0ICBJQU5BIENvbnNpZGVyYXRpb25z DQ0NCg0NDQoNDQ0KICAgUmVnaXN0cmF0aW9uIHJlcXVlc3QgZm9yIHRoZSBJT0RFRiBEaWdpdGFs IEZvcmVuc2ljcyBFeHRlbnNpb24NDQ0KICAgbmFtZXNwYWNlOg0NDQoNDQ0KICAgVVJJOiB1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLWRpZ2l0YWxmb3JlbnNpY3MtMS4wDQ0NCg0NDQogICBS ZWdpc3RyYW50IENvbnRhY3Q6DQ0NCg0NDQogICBDaHJpc3RvcGhlciBJbmFjaW8gQ2FybmVnaWUg TWVsbG9uIFVuaXZlcnNpdHkgNDUwMCA1dGggQXZlDQ0NCiAgIFBpdHRzYnVyZ2gsIFBBIDE1MjEz IFVTQSBpbmFjaW9AY2VydC5vcmcNDQ0KDQ0NCiAgIFhNTDogc2NoZW1hIGluIEFwcGVuZGl4IE4u DQ0NCg0NDQo1ICBSZWZlcmVuY2VzDQ0NCg0NDQo1LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQ0N Cg0NDQogICBbS0VZV09SRFNdIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZQ0NDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAx NCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQ0NCg0NDQogICBbSU9ERUZdICAgIERhbnlsaXcsIFIu LCBNZWlqZXIsIEouLCBhbmQgWS4gRGVtY2hlbmtvLCAiVGhlIEluY2lkZW50DQ0NCiAgICAgICAg ICAgICAgT2JqZWN0IERlc2NyaXB0aW9uIEV4Y2hhbmdlIEZvcm1hdCIsIFJGQyA1MDcwLCBEZWNl bWJlcg0NDQogICAgICAgICAgICAgIDIwMDcuDQ0NCg0NDQogICBbUklEXSAgICAgIE1vcmlhcnR5 LCBLLiwgIlJlYWwtdGltZSBJbnRlci1uZXR3b3JrIERlZmVuc2UgKFJJRCkiLA0NDQogICAgICAg ICAgICAgIFJGQyA2MDQ1LCBOb3ZlbWJlciAyMDEwLg0NDQoNDQ0KICAgW1JGQzMzMzldICBLbHlu ZSwgRy4gYW5kIEMuIE5ld21hbiwgIkRhdGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0Og0NDQog ICAgICAgICAgICAgIFRpbWVzdGFtcHMiLCBSRkMgMzMzOSwgSnVseSAyMDAyLg0NDQoNDQ0KDQ0N CjUuMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0NDQoNDQ0KDQ0NCiAgIFtERlhNTF0JR2FyZmlu a2VsLCBTLiwgIkRpZ2l0YWwgZm9yZW5zaWNzIFhNTCBhbmQgdGhlIERGWE1MIHRvb2xzZXQiLA0N DQogICAgICAgICAgICAgIERpZ2l0YWwgSW52ZXN0aWdhdGlvbiwgMjAxMi4NDQ0KDQ0NCiAgIFtE RVhGXQlHaWwsIFkuIEguLCBIb25nLCBELiwgUnV0a293c2tpLCBBLiBNLiwgIlJldmlzZWQgZHJh ZnQgb24NDQ0KIA0NDQoNDQ0KDQ0NCkNocmlzdG9waGVyIEluYWNpbyAgICAgIEV4cGlyZXMgQXVn dXN0IDIyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0NDQoMDQ0NCklOVEVSTkVUIERS QUZUICAgRGlnaXRhbCBGb3JlbnNpY3MgRXh0ZW5zaW9uIGZvciBJT0RFRiBGZWJydWFyeSAxOSwg MjAxMg0NDQoNDQ0KDQ0NCiAgICAgICAgICAgICAgUmVjb21tZW5kYXRpb24gSVRVLVQgWC5kZWY6 IGRpZ2l0YWwgZm9yZW5zaWNzIGV4Y2hhbmdlDQ0NCiAgICAgICAgICAgICAgZm9ybWF0IiwgSVRV IFN0dWR5IEdyb3VwIDE3LCBTZXB0ZW1iZXIgMiwgMjAxMS4NDQ0KDQ0NCiAgIFtOSUoxOTk0MDhd CSJOSUogU3BlY2lhbCBSZXBvcnQgMTk5NDA4OiBGb3JlbnNpYyBFeGFtaW5hdGlvbiBvZg0NDQog ICAgICAgICAgICAgIERpZ2l0YWwgRXZpZGVuY2U6IEEgR3VpZGUgZm9yIExhdyBFbmZvcmNlbWVu dCIgDQ0NCg0NDQogICBbSVNPODYwMV0JSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0 YW5kYXJkaXphdGlvbiwNDQ0KICAgICAgICAgICAgICAiSW50ZXJuYXRpb25hbCAgICAgICAgIFN0 YW5kYXJkOiBEYXRhIGVsZW1lbnRzIGFuZA0NDQogICAgICAgICAgICAgIGludGVyY2hhbmdlIGZv cm1hdHMgLSBJbmZvcm1hdGlvbiAgICAgICAgIGludGVyY2hhbmdlIC0NDQ0KICAgICAgICAgICAg ICBSZXByZXNlbnRhdGlvbiBvZiBkYXRlcyBhbmQgdGltZXMiLCBJU08gODYwMSwgICAgICAgIA0N DQogICAgICAgICAgICAgIFNlY29uZCBFZGl0aW9uLCBEZWNlbWJlciAyMDAwLg0NDQoNDQ0KDQ0N CkF1dGhvcnMnIEFkZHJlc3Nlcw0NDQoNDQ0KDQ0NCiAgIENocmlzdG9waGVyIEluYWNpbw0NDQog ICA0NTAwIDV0aCBBdmUuDQ0NCiAgIFBpdHRzYnVyZ2gsIFBBIDE1MTQzDQ0NCiAgIFVTQQ0NDQoN DQ0KICAgRU1haWw6IGluYWNpb0BjZXJ0Lm9yZw0NDQoNDQ0KDQ0NCkFwcGVuZGl4IEE6IERpZ2l0 YWwgRm9yZW5zaWNzIFhNTCBTY2hlbWENDQ0KDQ0NCiAgIFtbcHJlbGltaW5hcnkgc2NoZW1hIGhl cmVdXQ0NDQoNDQ0KICAgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NDQ0K ICAgPHhzZDpzY2hlbWEgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YSIgDQ0NCiAgICAgICAgICAgICAgIHhtbG5zOmRpZ2l0YWxmb3JlbnNpY3M9InVybjppZXRmOnBh cmFtczp4bWw6bnM6aW9kZWYtZGlnaXRhbGZvcmVuc2ljcy0xLjAiDQ0NCiAgICAgICAgICAgICAg IHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi1kaWdpdGFsZm9y ZW5zaWNzLTEuMCIgDQ0NCiAgICAgICAgICAgICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlm aWVkIg0NDQogICAgICAgICAgICAgICBhdHRyaWJ1dGVGb3JtRGVmYXVsdD0idW5xdWFsaWZpZWQi Pg0NDQoNDQ0KDQ0NCiAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iZGlnaXRhbGZvcmVuc2ljcyIg dHlwZT0iZGlnaXRhbGZvcmVuc2ljc1R5cGUiLz4NDQ0KDQ0NCiAgICAgICA8eHNkOmVsZW1lbnQg bmFtZT0iZGlnaXRhbGZvcmVuc2ljc1R5cGUiLz4NDQ0KICAgICAgIDx4c2Q6Y29tcGxleFR5cGUg bmFtZT0iZGlnaXRhbGZvcmVuc2ljc1R5cGUiPg0NDQogICAgICAgICAgIDx4c2Q6YXR0cmlidXRl IG5hbWU9Ik1ham9yVmVyc2lvbiJ0eXBlPSJ4c2Q6aW50ZWdlciIgdXNlPSJyZXF1aXJlZCIvPg0N DQogICAgICAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9Ik1pbm9yVmVyc2lvbiJ0eXBlPSJ4c2Q6 aW50ZWdlciIgdXNlPSJyZXF1aXJlZCIvPg0NDQogICAgICAgPC94c2Q6Y29tcGxleFR5cGU+DQ0N Cg0NDQoNDQ0KICAgICAgIDwhLS0gSEFTSCB0eXBlIGRlZmluaXRpb24gLS0+DQ0NCiAgICAgICA8 eHNkOnNpbXBsZVR5cGUgbmFtZT0iaGFzaFR5cGUiPg0NDQogICAgICAgICAgIDx4c2Q6cmVzdHJp Y3Rpb24gYmFzZT0ieHNkOnN0cmluZyI+DQ0NCiANDQ0KDQ0NCg0NDQpDaHJpc3RvcGhlciBJbmFj aW8gICAgICBFeHBpcmVzIEF1Z3VzdCAyMiwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgOF0N DQ0KDA0NDQpJTlRFUk5FVCBEUkFGVCAgIERpZ2l0YWwgRm9yZW5zaWNzIEV4dGVuc2lvbiBmb3Ig SU9ERUYgRmVicnVhcnkgMTksIDIwMTINDQ0KDQ0NCg0NDQogICAgICAgICAgICAgICA8eHNkOmVu dW1lcmF0aW9uIHZhbHVlPSJNRDUiLz4NDQ0KICAgICAgICAgICAgICAgPHhzZDplbnVtZXJhdGlv biB2YWx1ZT0iU0hBLTEiLz4NDQ0KICAgICAgICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1 ZT0iU0hBLTI1NiIvPg0NDQogICAgICAgICAgIDwveHNkOnJlc3RyaWN0aW9uPg0NDQogICAgICAg PC94c2Q6c2ltcGxlVHlwZT4NDQ0KICAgICAgIDx4c2Q6c2ltcGxlVHlwZSBuYW1lPSJoYXNoU2l6 ZSIgdHlwZT0ieHNkOmludGVnZXIiLz4NDQ0KICAgICAgIDx4c2Q6c2ltcGxlVHlwZSBuYW1lPSJo YXNoVmFsdWUiIHR5cGU9InhzZDpzdHJpbmciPg0NDQogICAgICAgICAgIDx4c2Q6cmVzdHJpY3Rp b24+DQ0NCiAgICAgICAgICAgICAgIDxwYXR0ZXJuIHZhbHVlPSdbYS1mQS1GMC05XSsnPg0NDQog ICAgICAgICAgIDwveHNkOnJlc3RyaWN0aW9uPg0NDQogICAgICAgPC94c2Q6c2ltcGxlVHlwZT4N DQ0KICAgICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0iaGFzaCI+DQ0NCiAgICAgICAgICAgPHhz ZDpzZXF1ZW5jZT4NDQ0KICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iaGFzaFR5cGUi Lz4NDQ0KICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iaGFzaFNpemUiLz4NDQ0KICAg ICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iaGFzaFZhbHVlIi8+DQ0NCiAgICAgICAgICAg PC94c2Q6c2VxdWVuY2U+DQ0NCiAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4NDQ0KDQ0NCiAgICAg ICA8IS0tIGJ5dGUgcnVucyAtLT4NDQ0KICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJydW4iPg0N DQogICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+DQ0NCiAgICAgICAgICAgICAgIDx4c2Q6YXR0 cmlidXRlIG5hbWU9ImZpbGVzeXN0ZW1fb2Zmc2V0IiB0eXBlPSJ4c2Q6bm9uTmVnYXRpdmVJbnRl Z2VyIi8+DQ0NCiAgICAgICAgICAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9ImZpbGVfb2Zmc2V0 IiB0eXBlPSJ4c2Q6bm9uTmVnYXRpdmVJbnRlZ2VyIi8+DQ0NCiAgICAgICAgICAgICAgIDx4c2Q6 YXR0cmlidXRlIG5hbWU9ImltYWdlX29mZnNldCIgdHlwZT0ieHNkOm5vbk5lZ2F0aXZlSW50ZWdl ciIvPg0NDQogICAgICAgICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJsZW4iIHR5cGU9Inhz ZDpub25OZWdhdGl2ZUludGVnZXIiLz4NDQ0KICAgICAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4N DQ0KICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJoYXNoIi8+DQ0NCiAgICAgICA8L3hzZDpl bGVtZW50Pg0NDQogICAgICAgPHhzZDplbGVtZW50IG5hbWU9ImJ5dGVfcnVuIj4NDQ0KICAgICAg ICAgICA8eHNkOmNvbXBsZXhUeXBlPg0NDQogICAgICAgICAgICAgICA8eHNkOnNlcXVlbmNlPg0N DQogICAgICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0icnVuIiBtaW5PY2N1cnM9IjEi IG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQ0NCiAgICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNl Pg0NDQogICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPg0NDQogICAgICAgPC94c2Q6ZWxlbWVu dD4NDQ0KDQ0NCiAgICAgICA8IS0tIEZpbGUgT2JqZWN0IERlZmluaXRpb24gLS0+DQ0NCiAgICAg ICA8IS0tIG5hbWUsIElELCBTaXplLCBQYXJ0aXRpb24sIE1vZGUsIEFDTCwgbXRpbWUsIGF0aW1l LCBjdGltZSAtLT4NDQ0KICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJmaWxlX29iamVjdCI+DQ0N CiAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4NDQ0KICAgICAgICAgICAgICAgPHhzZDpzZXF1 ZW5jZT4NDQ0KICAgICAgICAgICAgICAgICAgIDwhLS0gPHhzZDplbGVtZW50IG5hbWU9IiIgdHlw ZT0iIiBtaW5PY2N1cnM9IiIvPiAtLT4NDQ0KICAgICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVu dCBuYW1lPSJmaWxlbmFtZSIgdHlwZT0ieHNkOnN0cmluZyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9IjEiLz4NDQ0KICAgICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJpZCIgdHlw ZT0ieHNkOnN0cmluZyIgbWluT2NjdXJzPSIwIi8+DQ0NCiAgICAgICAgICAgICAgICAgICA8eHNk OmVsZW1lbnQgbmFtZT0iZmlsZXNpemUiIHR5cGU9InhzZDpwb3NpdGl2ZUludGVnZXIiIG1pbk9j Y3Vycz0iMCIvPg0NDQogICAgICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InBhcnRp dGlvbiIgdHlwZT0ieHNkOm5vbk5lZ2F0aXZlSW50ZWdlciIgbWluT2NjdXJzPSIwIi8+DQ0NCiAg ICAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibW9kZSIgdHlwZT0ieHNkOm5vbk5l Z2F0aXZlSW50ZWdlciIgbWluT2NjdXJzPSIwIi8+DQ0NCiANDQ0KDQ0NCg0NDQpDaHJpc3RvcGhl ciBJbmFjaW8gICAgICBFeHBpcmVzIEF1Z3VzdCAyMiwgMjAxMiAgICAgICAgICAgICAgICAgW1Bh Z2UgOV0NDQ0KDA0NDQpJTlRFUk5FVCBEUkFGVCAgIERpZ2l0YWwgRm9yZW5zaWNzIEV4dGVuc2lv biBmb3IgSU9ERUYgRmVicnVhcnkgMTksIDIwMTINDQ0KDQ0NCg0NDQogICAgICAgICAgICAgICAg ICAgPHhzZDplbGVtZW50IG5hbWU9ImFjbCIgdHlwZT0ieHNkOnN0cmluZyIgbWluT2NjdXJzPSIw Ii8+DQ0NCiAgICAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibXRpbWUiIHR5cGU9 IiIgbWluT2NjdXJzPSIwIi8+DQ0NCiAgICAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFt ZT0iYXRpbWUiIHR5cGU9IiIgbWluT2NjdXJzPSIwIi8+DQ0NCiAgICAgICAgICAgICAgICAgICA8 eHNkOmVsZW1lbnQgbmFtZT0iY3RpbWUiIHR5cGU9IiIgbWluT2NjdXJzPSIwIi8+DQ0NCiAgICAg ICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJieXRlX3J1biIgbWluT2NjdXJzPSIwIi8+ DQ0NCiAgICAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJoYXNoIiBtaW5PY2N1cnM9 IjAiLz4NDQ0KICAgICAgICAgICAgICAgPC94c2Q6c2VxdWVuY2U+DQ0NCiAgICAgICAgICAgPC94 c2Q6Y29tcGxleFR5cGU+DQ0NCiAgICAgICA8L3hzZDplbGVtZW50Pg0NDQoNDQ0KICAgPC94c2Q6 c2NoZW1hPg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0N DQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0N Cg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0KDQ0NCg0NDQoNDQ0K Q2hyaXN0b3BoZXIgSW5hY2lvICAgICAgRXhwaXJlcyBBdWd1c3QgMjIsIDIwMTIgICAgICAgICAg ICAgICAgW1BhZ2UgMTBdDQ0NCg== --_003_65E2E0B1101A41578C149B1FA5F1D0FAcertorg_-- From trammell@tik.ee.ethz.ch Wed Feb 29 08:37:16 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7521F872A; Wed, 29 Feb 2012 08:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 5bA6RKz3ARdd; Wed, 29 Feb 2012 08:37:15 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9521F8724; Wed, 29 Feb 2012 08:37:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D474AD9321; Wed, 29 Feb 2012 17:37:00 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id klTiYuATt3kL; Wed, 29 Feb 2012 17:37:00 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2E781D9305; Wed, 29 Feb 2012 17:37:00 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F4DFDB7.4090400@it.aoyama.ac.jp> Date: Wed, 29 Feb 2012 17:36:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C347097-7049-4D94-9269-1019B1181956@tik.ee.ethz.ch> References: <4F4DFDB7.4090400@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1257) Cc: "" , draft-ietf-mile-template@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [mile] APPSDIR review of draft-ietf-mile-template-02 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:37:17 -0000 Hello, Martin, Many thanks for your (thorough!) review! Replies to these points, = inline. On Feb 29, 2012, at 11:28 AM, Martin J. D=FCrst wrote: > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . >=20 > Please resolve these comments along with any other comments you may = receive. Please wait for direction from your document shepherd or AD = before posting a new version of the draft. >=20 > Document: draft-ietf-mile-template-02 > Title: Guidelines for Defining Extensions to IODEF > Reviewer: Martin D=FCrst > Review Date: 2012/02/29 >=20 >=20 > Summary: This document may be ready for publication as a BCP after = fixing some issues. >=20 >=20 > Mayor Issues: >=20 > This draft is extremely short (the main text is less than three = pages). I'm not at all sure if it is worth spending a BCP number on it. = Given the fact that it's a deliverable of the mile WG, for the rest of = this review, I'm assuming that this has been discussed before, and the = answer was positive. However, I'm nevertheless seriously wondering = whether it would not be better to have a bit more experience with actual = extension documents before putting best current practice in RFC form. (I = can only see two extension documents at = http://datatracker.ietf.org/wg/mile/; experience from both the IETF and = the W3C shows that it may take considerable time to get extensions = right.) The status of the draft was indeed discussed in the WG, and we were = indeed expecting a discussion on its intended status after sending it = up. The content of the template itself is essentially informational: we = have a lot of contributions from people just coming into the IETF = community, so we wanted a template to help jumpstart these authors's = efforts.=20 On the other hand, the IANA note requires a standards action. BCP was = the result, but we agree it's a little weird. > Section 6, IANA Considerations, says: > [IANA NOTE: The authors request that IANA include a note at the top > of http://www.iana.org/assignments/xml-registry/schema.html, stating > "Changes to the XML Schema registry for schema names beginning with > 'urn:ietf:params:xml:schema:iodef' are subject to an additional = IODEF > Expert Review [RFC5226]," and naming the designated expert.] > The example in the appendix = (urn:ietf:params:xml:schema:iodef-myextension-1.0) shows that "names = beginning with > 'urn:ietf:params:xml:schema:iodef" refers to a simple textual prefix = match. I'd expect that this is rather difficult to implement for IANA, = and it definitely doesn't scale well at all (e.g. if other frameworks = also add such restrictions). It would probably be better to have a = separate registry e.g. under urn:ietf:params:xml:schema:iodef: or = urn:ietf:params:xml:iodef-extension-schema: or some such. I suppose we could use a separate registry if it simplifies things (we = honestly hadn't considered the scalability issues that would result from = this being a precedent, good point), but there are already extensions in = the present registry following the "textual match" semantics: iodef-phish-1.0 urn:ietf:params:xml:schema:iodef-phish-1.0 [RFC5901] iodef-rid-1.0 urn:ietf:params:xml:schema:iodef-rid-1.0 [RFC6045] iodef-rid-2.0 urn:ietf:params:xml:schema:iodef-rid-2.0 = [RFC-ietf-mile-rfc6045-bis-11.txt] So, we'd have to split the registry.=20 It also appears that "subregistries" (e.g. = urn:ietf:params:xml:schema:pidf:*) are kept in the same registry, so I'm = not sure whether 'urn:ietf:params:xml:schema:iodef-' is harder to manage = than 'urn:ietf:params:xml:schema:iodef:'. Perhaps the right thing here is to refer this to IANA? > Minor Issues: >=20 > The text uses RFC 2119, but also uses the same keywords = non-capitalized, which will lead to confusion. Examples: >=20 > Note that in this final case, the extension will not be directly > interoperable with IODEF implementations, and must "unwrap" the = IODEF > document from its container... (Section 4) >=20 > ENUM for enumerated types; allowable values of the enumeration > must be defined in the attribute definition >=20 > In addition to schema reviews required by > IANA, these registry requests should be accompanied by a review by > IODEF experts to ensure the specified AdditionalData and/or ... > (Intro, where one usually tries to avoid normative stuff) >=20 > Lots and lots of 'should' in Appendix A, which all seem to be > intended normatively and therefor would better go into the main = text. Good points all; we'll have a look at these and make a full = 2119-language pass. Note of course that some of the non-2119 words are = not intended normatively. As for upgrading the shoulds in Appendix A and moving them up, I'm not = sure that that would make the document easier to use. These are advisory = (appendix A is essentially the Informational part of the document), and = bringing them outside the template makes them harder to refer to. = Authors are intended to follow the template by copying the document = template out of appendix A (this becomes much easier when they have the = XML source), then following the instructions to fill it in. (Indeed, I see on review here that we're missing A.7.1 normative = references and A.7.2 informative references) > The shortness of the document tends to give the impression that = writing an extension is easy. However, lots of details about extensions = are already given in RFC5070, and it should be stressed very clearly = that a good knowledge of RFC 5070 is a precondition to writing an = extension. In addition, the document should not only reference RFC 5070, = but also give more explicit pointers with section numbers in more cases. Good point; we'll do this. > Section 4 says: > The attributes which can be extended in this way are defined in = Section > 5.1 of [RFC5070], and limited to the following: [followed by long = list] > This let me think that the list is just a copy of a similar list in = RFC5070. But this is not the case. To get the list, the schema in = RFC5070 has to be searched for ext- attributes. So these attributes are = not actually defined in Section 5.1. Please clarify. We can add section references for each of these. > Also, please tweak the format so such a simple list doesn't take up = almost a whole page. Also please shortly explain the Element@attribute = syntax, which is part of XML 'slang' but not a formal part of the XML = core spec. Check. > The last paragraph of Section 4 says: > XML extensions within an AdditionalData or RecordItem element use a > dtype of "xml", and SHOULD define a schema for the root element > within the AdditionalData or RecordItem attribute. > The term "root element" is very clearly defined (and important) in = XML, and the use here is different from this established use. Please = change. Indeed. Is there a preferred terminology for the root of a subtree = within a document? > Security Section: > It is a general problem of this document that most of the meat is in = the Appendix, but the problem is most apparent here. The Security = Section should clearly *at least* mention that there is additional = security stuff in the Appendix. I'm confused here. Where's the security stuff in the appendix? > p. 9, A.4.1. IODEF Data Types: This looks like a simple repetition = from RFC 5070. A pointer should be better. Also, there are some = inaccuracies: >=20 >=20 > "ML_STRING (for strings in encodings other than that of the enclosing = document)": Here, RFC 5070 says: > STRING data that represents multi-character attributes in a language > different than the default encoding of the document is of the > ML_STRING data type. >=20 > The ML_STRING data type is implemented as an "iodef:MLStringType" in > the schema. > RFC 5070 hopelessly mixes up languages and encodings. This draft = shouldn't make things worse by claiming that XML can contain blobs of = data encoded with a different encoding that the overall entity. = (external entities can have a different encoding, but that's a separate = matter). >=20 >=20 > "DATETIME for ISO 8601:2000 [RFC3339] encoded timestamps" > RFC 5070 correctly says that RFC 3339 is a subset of ISO 8601. This = draft shouldn't give the impression that they are the same. >=20 >=20 > "TIMEZONE for timezones as encoded in section 2.9 of [RFC5070]." > "as encoded in" is confusing. ", encoded as defined in" is clearer. > Same for PORTLIST. >=20 >=20 > "URL for URLs as in [RFC3986].": This repeats an error from RFC5070. = URLs are mentioned shortly in section 1.1.3 of RFC 3986, but not what's = meant here. It at least say: "URL for URIs as in [RFC3986].". It is a = problem that IRIs aren't allowed, but that's a problem that has to be = fixed in RFC 5070, not here. I think we'd like to keep this section in the template, so we'll make = these fixes. > Nits: (will fix these too) > p. 4: involving integration with IODEF within -> > involving integration of IODEF within >=20 > p. 5: SHOULD define the use the "meaning": use or meaning? >=20 > p. 8, A.3. Applicability says: "The primary goal of this > section is to allow readers to see if an extension is indeed = intended > to solve a particular problem." > Are there extensions that are not intended to solve a particular = problem? Please reword. > ibid: "This should also ??? the scope" >=20 > p. 8, A.4. Extension Definition: "enumerating the new values with an > explanation of the meaning of the new value": Singular/plural > alignment problem >=20 > ibid: "or in another referenced MILE extension document": Why the = restriction on MILE? Shouldn't any IODEF extension be okay? Yep; fixed this elsewhere but missed this one... > p. 10, Section A.4: > ... IODEF:Address element, which supports IPv4 and > [RFC4291] IPv6 addresses, as well as MAC, ATM, and BGP autonomous > system numbers. > Why do IPv6 addresses need a reference, but the others don't? At = least, it should be "IPv6 addresses [RFC4291]". But why not just drop = it? "IPv6 addresses formatted as in [RFC4291]" was the intent here. > p. 10, Section A.5: "Guidance should focus > on ensuring the users of this extension do so in a secure fashion," > "do so": do what? Be more specific. >=20 > ibid: "represented by an extension": The paragraph has "this = extension" in the first line, so it should be "represented by this = extension" here. >=20 > p. 11: Appendix A.8: "given in the appendix" -> "given in Appendix A" Best regards, and thanks again! - Brian=