From internet-drafts@ietf.org Sun Jan 1 12:30: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 929851F0C50; Sun, 1 Jan 2012 12:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Jrezfcm3UfNV; Sun, 1 Jan 2012 12:30:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA8D1F0C48; Sun, 1 Jan 2012 12:30:33 -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.64p1 Message-ID: <20120101203033.1762.24955.idtracker@ietfa.amsl.com> Date: Sun, 01 Jan 2012 12:30:33 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-05.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: Sun, 01 Jan 2012 20:30:33 -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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-05.txt Pages : 77 Date : 2012-01-01 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-05.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-rfc6045-bis-05.txt From kathleen.moriarty@emc.com Sun Jan 1 12:49:17 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 B104F1F0C38 for ; Sun, 1 Jan 2012 12:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 4TNNxwQh2xbN for ; Sun, 1 Jan 2012 12:49:16 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id ADDF91F0C36 for ; Sun, 1 Jan 2012 12:49:15 -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 q01KnESo003971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Jan 2012 15:49:14 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Sun, 1 Jan 2012 15:49:01 -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 q01KmxE7016913 for ; Sun, 1 Jan 2012 15:48:59 -0500 Received: from mx06a.corp.emc.com ([169.254.1.218]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Sun, 1 Jan 2012 15:48:59 -0500 From: To: Date: Sun, 1 Jan 2012 15:48:57 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-05.txt Thread-Index: AczIxEtLx7euHn3CRFO8S/mQqu5GPgAAbYxw 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] FW: I-D Action: draft-ietf-mile-rfc6045-bis-05.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: Sun, 01 Jan 2012 20:49:17 -0000 Hello, The attached version includes the schema change to have RID encapsulate IOD= EF documents as well as the signature. This resolves the questions raised = in the transport review as to how the documents would be joined into a docu= ment and also makes this more flexible for other transports to be used in t= he future. This change also makes RID more extensible, this came up in the= apps area review. =20 Note: The signature on the TraceRequest example is only of the IODEF docume= nt as you cannot do a detached signature in the tool I am using unless the = schema resolves. I will need to update the signature after iodef-rid-1.2 g= ets posted. I think every outstanding question has been resolved, please let me know if= this solution is agreeable. Thank you, Kathleen (as editor) Happy new year!! -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Sunday, January 01, 2012 3:31 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-05.txt 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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-05.txt Pages : 77 Date : 2012-01-01 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-05.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-rfc6045-bis-05.txt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From turners@ieca.com Sun Jan 1 19:08:47 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 719C01F0C3B for ; Sun, 1 Jan 2012 19:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 LKdaVLXnEtbO for ; Sun, 1 Jan 2012 19:08:46 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.39.3]) by ietfa.amsl.com (Postfix) with ESMTP id 95F521F0C36 for ; Sun, 1 Jan 2012 19:08:46 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 10ED078E82F37; Sun, 1 Jan 2012 21:08:44 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 06BC478E82F17 for ; Sun, 1 Jan 2012 21:08:44 -0600 (CST) Received: from [96.241.0.5] (port=35555 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RhYGR-0005cm-It; Sun, 01 Jan 2012 21:08:43 -0600 Message-ID: <4F011FBA.3090507@ieca.com> Date: Sun, 01 Jan 2012 22:08:42 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Takeshi Takahashi References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com> <000301ccc524$d981f8d0$8c85ea70$@nict.go.jp> In-Reply-To: <000301ccc524$d981f8d0$8c85ea70$@nict.go.jp> 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: (thunderfish.local) [96.241.0.5]:35555 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Mon, 02 Jan 2012 03:08:47 -0000 Take, If we're importing schema elements from the schemas listed in 4.1.*, then wouldn't the references to those specifications be normative? spt On 12/28/11 12:52 AM, Takeshi Takahashi wrote: > Hello all, > > I've just posted the new version of the mile-sci draft. > Though the text has changed a lot, we basically have only two changes, as > listed below: > > 1. table is changed (see section 4.1) > 2. IANA description was totally changed > > The discussion on EM_XML is still an issue, so I'd appreciate if you could > kindly share your opinion on that. > (I personally like the idea Kathleen kindly proposed.) > The new version tentatively deleted the description of EM_XML, and use the > xml defined by the IODEF dtype. > > Thank you very much for those of you who kindly gave me lots of useful > comments and supports. > I wish you a happy new year. > > Sincerely, > Take > > >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, December 28, 2011 2:40 PM >> To: i-d-announce@ietf.org >> Cc: mile@ietf.org >> Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Managed Incident Lightweight >> Exchange Working Group of the IETF. >> >> Title : IODEF-extension to support structured >> cybersecurity information >> Author(s) : Takeshi Takahashi >> Kent Landfield >> Thomas Millar >> Youki Kadobayashi >> Filename : draft-ietf-mile-sci-01.txt >> Pages : 34 >> Date : 2011-12-27 >> >> This document extends the Incident Object Description Exchange Format >> (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched >> cybersecurity information exchange among cybersecurity entities by >> embedding structured information formatted by specifications, >> including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) >> [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL >> [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt >> >> _______________________________________________ >> mile mailing 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 iesg-secretary@ietf.org Mon Jan 2 09:52: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 05C0721F845B; Mon, 2 Jan 2012 09:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 kaT8GRCxHHD1; Mon, 2 Jan 2012 09:52:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCFE21F8433; Mon, 2 Jan 2012 09:52:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120102175218.17886.56877.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2012 09:52:18 -0800 Cc: mile@ietf.org Subject: [mile] Last Call: (Real-time Inter-network Defense (RID)) to Proposed Standard X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 02 Jan 2012 17:52:19 -0000 The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'Real-time Inter-network Defense (RID)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ No IPR declarations have been submitted directly on this I-D. From david.black@emc.com Mon Jan 2 11:31: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 EAE2E11E80B9 for ; Mon, 2 Jan 2012 11:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9kphDDPvgNMS for ; Mon, 2 Jan 2012 11:31: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 E44F111E80B2 for ; Mon, 2 Jan 2012 11:31:33 -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 q02JVVQL009606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2012 14:31:31 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 2 Jan 2012 14:31:14 -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 q02JVC5b006271; Mon, 2 Jan 2012 14:31:12 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Mon, 2 Jan 2012 14:31:12 -0500 From: To: , Date: Mon, 2 Jan 2012 14:31:10 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-sci-01.txt Thread-Index: AQGULmByYCUpvH5kVtZUifIc/i5AwJZh6blwgAi0MHA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com> <000301ccc524$d981f8d0$8c85ea70$@nict.go.jp> In-Reply-To: <000301ccc524$d981f8d0$8c85ea70$@nict.go.jp> 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] I-D Action: draft-ietf-mile-sci-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: Mon, 02 Jan 2012 19:31:40 -0000 Greetings, > The discussion on EM_XML is still an issue, so I'd appreciate if you coul= d > kindly share your opinion on that. > (I personally like the idea Kathleen kindly proposed.) > The new version tentatively deleted the description of EM_XML, and use th= e > xml defined by the IODEF dtype. I also like Kathleen's suggested approach of using the IODEF dtype instead = of EM_XML, especially as that approach is also being used to include IODEF = content in RID (see the ReportSchema class in draft-ietf-mile-rfc6045-bis-0= 5.txt), so using the same approach twice seems like a good idea for consist= ency. I think some more discussion would be useful (and would like to see the opi= nions of others), as I see some differences between how this is being done = in the rfc6045-bis draft vs. the sci draft: =09 (1) Schema identification RID identifies the included XML schema by XML namespace and version. The X= ML namespace is in the XMLSchemaID or ext-XMLSchemaID attribute of the Repo= rtSchema class, and the schema version is in the Version or ext-Version att= ribute of that class. IODEF 1.0 is the default if these attributes are omi= tted. SCI extension classes (e.g., AttackPattern) use an additional required Spec= ificationID attribute (a short ENUM xsd:string) that includes both an acron= ym and the version of the specification - the XML namespace is left to be d= eclared by the included XML. (2) Version of schema vs. specification For RID, the Version or Version-ext attribute of the ReportSchema class con= tains the XML schema version for the included XML. For SCI, the version that's part of the SpecificationID attribute of the ex= tension classes is the version of the specification for the included XML. = This specification version may not match the version of the XML schema defi= ned by that specification. (3) Version - same attribute name used for two different purposes. For RID, the Version attribute of the ReportSchema class is the schema vers= ion for the included XML for standard schemas (ext-Version is used for non-= standard schemas). For SCI, the Version attribute of the extension classes is the version of t= he IODEF-SCI schema. My 0.02 (which isn't worth much more than that) is that SpecificationID see= ms to be useful as a convenient human-readable string to identify the type = of XML content (for RID, that could default to IODEF if omitted), and I don= 't have a strong preference for the two version topics as long as a single = approach is adopted. Could others on the list speak up to provide opinions on how to handle thes= e topics? Thanks, --David > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Wednesday, December 28, 2011 12:52 AM > To: mile@ietf.org > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; Kent_Landfield@McAf= ee.com > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt >=20 > Hello all, >=20 > I've just posted the new version of the mile-sci draft. > Though the text has changed a lot, we basically have only two changes, as > listed below: >=20 > 1. table is changed (see section 4.1) > 2. IANA description was totally changed >=20 > The discussion on EM_XML is still an issue, so I'd appreciate if you coul= d > kindly share your opinion on that. > (I personally like the idea Kathleen kindly proposed.) > The new version tentatively deleted the description of EM_XML, and use th= e > xml defined by the IODEF dtype. >=20 > Thank you very much for those of you who kindly gave me lots of useful > comments and supports. > I wish you a happy new year. >=20 > Sincerely, > Take >=20 >=20 > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Wednesday, December 28, 2011 2:40 PM > > To: i-d-announce@ietf.org > > Cc: mile@ietf.org > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Managed Incident Lightwei= ght > > Exchange Working Group of the IETF. > > > > Title : IODEF-extension to support structured > > cybersecurity information > > Author(s) : Takeshi Takahashi > > Kent Landfield > > Thomas Millar > > Youki Kadobayashi > > Filename : draft-ietf-mile-sci-01.txt > > Pages : 34 > > Date : 2011-12-27 > > > > This document extends the Incident Object Description Exchange Forma= t > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > cybersecurity information exchange among cybersecurity entities by > > embedding structured information formatted by specifications, > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCI= L > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile >=20 From takeshi_takahashi@nict.go.jp Tue Jan 3 05:04: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 1F4EE21F853F for ; Tue, 3 Jan 2012 05:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=0.150, 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 HZoQz6k3Bk+T for ; Tue, 3 Jan 2012 05:04:58 -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 DD03521F851C for ; Tue, 3 Jan 2012 05:04:57 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q03D4qWn029436; Tue, 3 Jan 2012 22:04:52 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q03D4qXq016890; Tue, 3 Jan 2012 22:04:52 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q03D4qWs016883; Tue, 3 Jan 2012 22:04:52 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 6536516563; Tue, 3 Jan 2012 22:04:52 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 420EB16BA7; Tue, 3 Jan 2012 22:04:52 +0900 (JST) From: "Takeshi Takahashi" To: "'Sean Turner'" References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com> <000301ccc524$d981f8d0$8c85ea70$@nict.go.jp> <4F011FBA.3090507@ieca.com> In-Reply-To: <4F011FBA.3090507@ieca.com> Date: Tue, 3 Jan 2012 22:04:54 +0900 Message-ID: <000101ccca18$498e2520$dcaa6f60$@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: AQGULmByYCUpvH5kVtZUifIc/i5AwAFJmbAoAih/hsSWUD9DkA== Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Tue, 03 Jan 2012 13:04:59 -0000 Hello Sean, Thank you for pointing it out. I appreciate that. I should move these references to normative section. Thank you. Take > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Monday, January 02, 2012 12:09 PM > To: Takeshi Takahashi > Cc: mile@ietf.org > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Take, > > If we're importing schema elements from the schemas listed in 4.1.*, then > wouldn't the references to those specifications be normative? > > spt > > On 12/28/11 12:52 AM, Takeshi Takahashi wrote: > > Hello all, > > > > I've just posted the new version of the mile-sci draft. > > Though the text has changed a lot, we basically have only two changes, > > as listed below: > > > > 1. table is changed (see section 4.1) > > 2. IANA description was totally changed > > > > The discussion on EM_XML is still an issue, so I'd appreciate if you > > could kindly share your opinion on that. > > (I personally like the idea Kathleen kindly proposed.) The new version > > tentatively deleted the description of EM_XML, and use the xml defined > > by the IODEF dtype. > > > > Thank you very much for those of you who kindly gave me lots of useful > > comments and supports. > > I wish you a happy new year. > > > > Sincerely, > > Take > > > > > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > >> Of internet-drafts@ietf.org > >> Sent: Wednesday, December 28, 2011 2:40 PM > >> To: i-d-announce@ietf.org > >> Cc: mile@ietf.org > >> Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Managed Incident > >> Lightweight Exchange Working Group of the IETF. > >> > >> Title : IODEF-extension to support structured > >> cybersecurity information > >> Author(s) : Takeshi Takahashi > >> Kent Landfield > >> Thomas Millar > >> Youki Kadobayashi > >> Filename : draft-ietf-mile-sci-01.txt > >> Pages : 34 > >> Date : 2011-12-27 > >> > >> This document extends the Incident Object Description Exchange > Format > >> (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > >> cybersecurity information exchange among cybersecurity entities > by > >> embedding structured information formatted by specifications, > >> including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) > >> [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], > OCIL > >> [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > >> > >> _______________________________________________ > >> mile mailing 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 Jan 3 05:04: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 20DCD21F8543 for ; Tue, 3 Jan 2012 05:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=0.100, 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 M7B2IludK2sK for ; Tue, 3 Jan 2012 05:04:58 -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 DCF9A21F848A for ; Tue, 3 Jan 2012 05:04:57 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q03D4rco029439; Tue, 3 Jan 2012 22:04:53 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q03D4qoB016895; Tue, 3 Jan 2012 22:04:52 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q03D4qPQ016885; Tue, 3 Jan 2012 22:04:52 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 95C9416BA7; Tue, 3 Jan 2012 22:04:52 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 52EF22C203; Tue, 3 Jan 2012 22:04:52 +0900 (JST) From: "Takeshi Takahashi" To: , References: In-Reply-To: Date: Tue, 3 Jan 2012 22:04:54 +0900 Message-ID: <000201ccca18$499921a0$dccb64e0$@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: AQJ3ZWOThiAOsbYPQAaFl+2/TgdR8ZSlWOuA Content-Language: ja Subject: Re: [mile] FW: I-D Action: draft-ietf-mile-rfc6045-bis-05.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: Tue, 03 Jan 2012 13:04:59 -0000 Hello Kathleen and all, Let me post a quick comment here. I was reading the Section 5.1.1 ("ReportSchema"), and liked the way how you defined the XMLDocument class. I myself was looking for a better way to embed an XML data, and in my humble opinion, this was a smart way to do that. (I have already imported this method into our draft. Thank you.) Though the discrepancy between the UML expression and schema was discussed some time before, in my humble opinion, I do not see such discrepancy between them regarding this section. Thank you. Take PS: By the way, a happy new year, and I wish you all the best in this year 2012. > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > kathleen.moriarty@emc.com > Sent: Monday, January 02, 2012 5:49 AM > To: mile@ietf.org > Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc6045-bis-05.txt > > Hello, > > The attached version includes the schema change to have RID encapsulate > IODEF documents as well as the signature. This resolves the questions > raised in the transport review as to how the documents would be joined > into a document and also makes this more flexible for other transports > to be used in the future. This change also makes RID more extensible, > this came up in the apps area review. > > Note: The signature on the TraceRequest example is only of the IODEF > document as you cannot do a detached signature in the tool I am using > unless the schema resolves. I will need to update the signature after > iodef-rid-1.2 gets posted. > > I think every outstanding question has been resolved, please let me know > if this solution is agreeable. > > Thank you, > Kathleen (as editor) > > Happy new year!! > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Sunday, January 01, 2012 3:31 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Managed Incident Lightweight > Exchange Working Group of the IETF. > > Title : Real-time Inter-network Defense (RID) > Author(s) : Kathleen M. Moriarty > Filename : draft-ietf-mile-rfc6045-bis-05.txt > Pages : 77 > Date : 2012-01-01 > > Security incidents, such as system compromises, worms, viruses, > phishing incidents, and denial of service, typically result in the > loss of service, data, and resources both human and system. Service > providers and Computer Security Incident Response Teams need to be > equipped and ready to assist in communicating and tracing security > incidents with tools and procedures in place before the occurrence > of > an attack. Real-time Inter-network Defense (RID) outlines a > proactive inter-network communication method to facilitate sharing > incident handling data while integrating existing detection, tracing, > source identification, and mitigation mechanisms for a complete > incident handling solution. Combining these capabilities in a > communication system provides a way to achieve higher security levels > on networks. Policy guidelines for handling incidents are > recommended and can be agreed upon by a consortium using the security > recommendations and considerations. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-05.t > xt > > 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-rfc6045-bis-05.tx > t > > _______________________________________________ > mile mailing 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 Jan 3 06:52: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 C6AE521F84FA for ; Tue, 3 Jan 2012 06:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 RdNbxZznMiLD for ; Tue, 3 Jan 2012 06:52:40 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A670521F84F3 for ; Tue, 3 Jan 2012 06:52:40 -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 q03EqaYS018107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 09:52:37 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 3 Jan 2012 09:52:20 -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 q03EqI3W027344; Tue, 3 Jan 2012 09:52:18 -0500 Received: from mx06a.corp.emc.com ([169.254.1.218]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Tue, 3 Jan 2012 09:52:18 -0500 From: To: , , Date: Tue, 3 Jan 2012 09:52:17 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-sci-01.txt Thread-Index: AQGULmByYCUpvH5kVtZUifIc/i5AwJZh6blwgAi0MHCAAU9xZA== Message-ID: References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com> <000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.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] I-D Action: draft-ietf-mile-sci-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: Tue, 03 Jan 2012 14:52:41 -0000 Take and the other authors of he SCI draft are reviewing this issue. Feedb= ack on how RID encapsulates a document would be helpful. The approach used= in RID is consistent with IODEF. =20 I would like to clarify one of the assumptions from below to avoid confusio= n. 1) The version can be left out for IODEF when included in a RID document as= it is listed in the namespace definition, not because it is the default sc= hema. In case other schemas also include the version in the namespace decl= aration, this was left as optional. 3) Are you advocating for a specificationID to be included in addition to t= he namespace declaration? =20 Thanks, Kathleen (editor) ________________________________________ From: Black, David Sent: Monday, January 02, 2012 2:31 PM To: Takeshi Takahashi; mile@ietf.org Cc: Moriarty, Kathleen Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt Greetings, > The discussion on EM_XML is still an issue, so I'd appreciate if you coul= d > kindly share your opinion on that. > (I personally like the idea Kathleen kindly proposed.) > The new version tentatively deleted the description of EM_XML, and use th= e > xml defined by the IODEF dtype. I also like Kathleen's suggested approach of using the IODEF dtype instead = of EM_XML, especially as that approach is also being used to include IODEF = content in RID (see the ReportSchema class in draft-ietf-mile-rfc6045-bis-0= 5.txt), so using the same approach twice seems like a good idea for consist= ency. I think some more discussion would be useful (and would like to see the opi= nions of others), as I see some differences between how this is being done = in the rfc6045-bis draft vs. the sci draft: (1) Schema identification RID identifies the included XML schema by XML namespace and version. The X= ML namespace is in the XMLSchemaID or ext-XMLSchemaID attribute of the Repo= rtSchema class, and the schema version is in the Version or ext-Version att= ribute of that class. IODEF 1.0 is the default if these attributes are omi= tted. SCI extension classes (e.g., AttackPattern) use an additional required Spec= ificationID attribute (a short ENUM xsd:string) that includes both an acron= ym and the version of the specification - the XML namespace is left to be d= eclared by the included XML. (2) Version of schema vs. specification For RID, the Version or Version-ext attribute of the ReportSchema class con= tains the XML schema version for the included XML. For SCI, the version that's part of the SpecificationID attribute of the ex= tension classes is the version of the specification for the included XML. = This specification version may not match the version of the XML schema defi= ned by that specification. (3) Version - same attribute name used for two different purposes. For RID, the Version attribute of the ReportSchema class is the schema vers= ion for the included XML for standard schemas (ext-Version is used for non-= standard schemas). For SCI, the Version attribute of the extension classes is the version of t= he IODEF-SCI schema. My 0.02 (which isn't worth much more than that) is that SpecificationID see= ms to be useful as a convenient human-readable string to identify the type = of XML content (for RID, that could default to IODEF if omitted), and I don= 't have a strong preference for the two version topics as long as a single = approach is adopted. Could others on the list speak up to provide opinions on how to handle thes= e topics? Thanks, --David > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Wednesday, December 28, 2011 12:52 AM > To: mile@ietf.org > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; Kent_Landfield@McAf= ee.com > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Hello all, > > I've just posted the new version of the mile-sci draft. > Though the text has changed a lot, we basically have only two changes, as > listed below: > > 1. table is changed (see section 4.1) > 2. IANA description was totally changed > > The discussion on EM_XML is still an issue, so I'd appreciate if you coul= d > kindly share your opinion on that. > (I personally like the idea Kathleen kindly proposed.) > The new version tentatively deleted the description of EM_XML, and use th= e > xml defined by the IODEF dtype. > > Thank you very much for those of you who kindly gave me lots of useful > comments and supports. > I wish you a happy new year. > > Sincerely, > Take > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Wednesday, December 28, 2011 2:40 PM > > To: i-d-announce@ietf.org > > Cc: mile@ietf.org > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Managed Incident Lightwei= ght > > Exchange Working Group of the IETF. > > > > Title : IODEF-extension to support structured > > cybersecurity information > > Author(s) : Takeshi Takahashi > > Kent Landfield > > Thomas Millar > > Youki Kadobayashi > > Filename : draft-ietf-mile-sci-01.txt > > Pages : 34 > > Date : 2011-12-27 > > > > This document extends the Incident Object Description Exchange Forma= t > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > cybersecurity information exchange among cybersecurity entities by > > embedding structured information formatted by specifications, > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCI= L > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > From internet-drafts@ietf.org Tue Jan 3 08:11: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 83DF821F84EA; Tue, 3 Jan 2012 08:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 lpXmVjavqrPW; Tue, 3 Jan 2012 08:11:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2354221F84BB; Tue, 3 Jan 2012 08:11:27 -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.64p1 Message-ID: <20120103161127.29619.21267.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 08:11:27 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-05.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: Tue, 03 Jan 2012 16:11:27 -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 : Transport of Real-time Inter-network Defense (RID) Messa= ges over HTTP/ TLS Author(s) : Brian Trammell Filename : draft-ietf-mile-rfc6046-bis-05.txt Pages : 8 Date : 2012-01-03 The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-05.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-rfc6046-bis-05.txt From david.black@emc.com Tue Jan 3 09:48: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 4D0DD21F847F for ; Tue, 3 Jan 2012 09:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 gwvCkHD2Jnln for ; Tue, 3 Jan 2012 09:48: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 25DA921F8480 for ; Tue, 3 Jan 2012 09:48:21 -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 q03HmKsp025909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Jan 2012 12:48:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 3 Jan 2012 12:47:59 -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 q03Hlq0a007835 for ; Tue, 3 Jan 2012 12:47:57 -0500 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub22.corp.emc.com (128.222.70.134) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Jan 2012 12:47:53 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Tue, 3 Jan 2012 12:47:53 -0500 From: To: Date: Tue, 3 Jan 2012 12:47:52 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-sci-01.txt Thread-Index: AQGULmByYCUpvH5kVtZUifIc/i5AwJZh6blwgAi0MHCAAU9xZIAAMhJA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com> <000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@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 Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Tue, 03 Jan 2012 17:48:23 -0000 Hi Kathleen, > 3) Are you advocating for a specificationID to be included in addition to= the namespace declaration? Not exactly ;-). I'm not "advocating" for inclusion of specificationID - rather I'd like to = see RID and SCI be consistent in their use of SpecificationID and Version. = For SpecificationID, that could be accomplished by adding it to RID or tak= ing it out of SCI; both approaches seem reasonable to me. What do other people think ought to be done here and why? Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Tuesday, January 03, 2012 9:52 AM > To: Black, David; Takeshi Takahashi; mile@ietf.org > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt >=20 > Take and the other authors of the SCI draft are reviewing this issue. Fe= edback on how RID encapsulates > a document would be helpful. The approach used in RID is consistent with= IODEF. >=20 > I would like to clarify one of the assumptions from below to avoid confus= ion. >=20 > 1) The version can be left out for IODEF when included in a RID document = as it is listed in the > namespace definition, not because it is the default schema. In case othe= r schemas also include the > version in the namespace declaration, this was left as optional. >=20 > 3) Are you advocating for a specificationID to be included in addition to= the namespace declaration? >=20 > Thanks, > Kathleen (editor) > ________________________________________ > From: Black, David > Sent: Monday, January 02, 2012 2:31 PM > To: Takeshi Takahashi; mile@ietf.org > Cc: Moriarty, Kathleen > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt >=20 > Greetings, >=20 > > The discussion on EM_XML is still an issue, so I'd appreciate if you co= uld > > kindly share your opinion on that. > > (I personally like the idea Kathleen kindly proposed.) > > The new version tentatively deleted the description of EM_XML, and use = the > > xml defined by the IODEF dtype. >=20 > I also like Kathleen's suggested approach of using the IODEF dtype instea= d of EM_XML, especially as > that approach is also being used to include IODEF content in RID (see the= ReportSchema class in draft- > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice seems lik= e a good idea for > consistency. >=20 > I think some more discussion would be useful (and would like to see the o= pinions of others), as I see > some differences between how this is being done in the rfc6045-bis draft = vs. the sci draft: >=20 > (1) Schema identification >=20 > RID identifies the included XML schema by XML namespace and version. The= XML namespace is in the > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, and t= he schema version is in the > Version or ext-Version attribute of that class. IODEF 1.0 is the default= if these attributes are > omitted. >=20 > SCI extension classes (e.g., AttackPattern) use an additional required Sp= ecificationID attribute (a > short ENUM xsd:string) that includes both an acronym and the version of t= he specification - the XML > namespace is left to be declared by the included XML. >=20 > (2) Version of schema vs. specification >=20 > For RID, the Version or Version-ext attribute of the ReportSchema class c= ontains the XML schema > version for the included XML. >=20 > For SCI, the version that's part of the SpecificationID attribute of the = extension classes is the > version of the specification for the included XML. This specification ve= rsion may not match the > version of the XML schema defined by that specification. >=20 > (3) Version - same attribute name used for two different purposes. >=20 > For RID, the Version attribute of the ReportSchema class is the schema ve= rsion for the included XML > for standard schemas (ext-Version is used for non-standard schemas). >=20 > For SCI, the Version attribute of the extension classes is the version of= the IODEF-SCI schema. >=20 > My 0.02 (which isn't worth much more than that) is that SpecificationID s= eems to be useful as a > convenient human-readable string to identify the type of XML content (for= RID, that could default to > IODEF if omitted), and I don't have a strong preference for the two versi= on topics as long as a single > approach is adopted. >=20 > Could others on the list speak up to provide opinions on how to handle th= ese topics? >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > Sent: Wednesday, December 28, 2011 12:52 AM > > To: mile@ietf.org > > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; Kent_Landfield@Mc= Afee.com > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Hello all, > > > > I've just posted the new version of the mile-sci draft. > > Though the text has changed a lot, we basically have only two changes, = as > > listed below: > > > > 1. table is changed (see section 4.1) > > 2. IANA description was totally changed > > > > The discussion on EM_XML is still an issue, so I'd appreciate if you co= uld > > kindly share your opinion on that. > > (I personally like the idea Kathleen kindly proposed.) > > The new version tentatively deleted the description of EM_XML, and use = the > > xml defined by the IODEF dtype. > > > > Thank you very much for those of you who kindly gave me lots of useful > > comments and supports. > > I wish you a happy new year. > > > > Sincerely, > > Take > > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of > > > internet-drafts@ietf.org > > > Sent: Wednesday, December 28, 2011 2:40 PM > > > To: i-d-announce@ietf.org > > > Cc: mile@ietf.org > > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. This draft is a work item of the Managed Incident Lightw= eight > > > Exchange Working Group of the IETF. > > > > > > Title : IODEF-extension to support structured > > > cybersecurity information > > > Author(s) : Takeshi Takahashi > > > Kent Landfield > > > Thomas Millar > > > Youki Kadobayashi > > > Filename : draft-ietf-mile-sci-01.txt > > > Pages : 34 > > > Date : 2011-12-27 > > > > > > This document extends the Incident Object Description Exchange For= mat > > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > > cybersecurity information exchange among cybersecurity entities by > > > embedding structured information formatted by specifications, > > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) > > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], O= CIL > > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > From trammell@tik.ee.ethz.ch Tue Jan 3 10:30:17 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 658255E800B for ; Tue, 3 Jan 2012 10:30:17 -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 rDo+EtPHwx9z for ; Tue, 3 Jan 2012 10:30:16 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 913DB5E8009 for ; Tue, 3 Jan 2012 10:30:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 43DF5D930C for ; Tue, 3 Jan 2012 19:30:13 +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 nz4vOoRPe3qM for ; Tue, 3 Jan 2012 19:30:13 +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 EB003D930B for ; Tue, 3 Jan 2012 19:30:12 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jan 2012 19:30:12 +0100 References: <20120103161127.29619.21267.idtracker@ietfa.amsl.com> To: mile@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mile] Fwd: I-D Action: draft-ietf-mile-rfc6046-bis-05.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: Tue, 03 Jan 2012 18:30:17 -0000 Greetings, all, and happy new year! I've submitted rfc6046-bis-05; this, I believe, addresses all comments = received on the -04 revision of the document, and is ready for IETF last = call. Best regards, Brian (as author of 6046-bis) Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 3, 2012 5:11:27 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Managed Incident = Lightweight Exchange Working Group of the IETF. >=20 > Title : Transport of Real-time Inter-network Defense = (RID) Messages over HTTP/ TLS > Author(s) : Brian Trammell > Filename : draft-ietf-mile-rfc6046-bis-05.txt > Pages : 8 > Date : 2012-01-03 >=20 > The Incident Object Description Exchange Format (IODEF) defines a > common XML format for document exchange, and Realtime Internetwork > Defense (RID) defines extensions to IODEF intended for the > cooperative handling of security incidents within consortia of > network operators and enterprises. This document specifies a > transport protocol for RID based upon the passing of RID messages > over HTTP/TLS. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-05.txt >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From iesg-secretary@ietf.org Tue Jan 3 11:35: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 2827C11E80DB; Tue, 3 Jan 2012 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 gzuhdgAbc4Y0; Tue, 3 Jan 2012 11:35:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964E611E80D1; Tue, 3 Jan 2012 11:35:43 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103193543.30656.54012.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 11:35:43 -0800 Cc: mile@ietf.org Subject: [mile] Last Call: (Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS) to Proposed Standard X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 03 Jan 2012 19:35:44 -0000 The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6046-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6046-bis/ No IPR declarations have been submitted directly on this I-D. From david.black@emc.com Fri Jan 6 09:50:24 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 5068321F881F for ; Fri, 6 Jan 2012 09:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 SyTIXE1GE594 for ; Fri, 6 Jan 2012 09:50:23 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE121F87F7 for ; Fri, 6 Jan 2012 09:50:22 -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 q06HoG7X026081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jan 2012 12:50:20 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Fri, 6 Jan 2012 12:49:56 -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 q06Hntnj016626 for ; Fri, 6 Jan 2012 12:49:55 -0500 Received: from mx14a.corp.emc.com ([169.254.2.48]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Fri, 6 Jan 2012 12:49:54 -0500 From: To: Date: Fri, 6 Jan 2012 12:49:53 -0500 Thread-Topic: [mile] Last Call: (Real-time Inter-network Defense (RID)) to Proposed Standard Thread-Index: AczJd1p7BBPTFhEpRsKs7cF8cKmNJgDHzVsw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A6F0F5B9@MX14A.corp.emc.com> References: <20120102175218.17886.56877.idtracker@ietfa.amsl.com> In-Reply-To: <20120102175218.17886.56877.idtracker@ietfa.amsl.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] Last Call: (Real-time Inter-network Defense (RID)) to Proposed Standard 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, 06 Jan 2012 17:50:24 -0000 Hi Kathleen, Nice work on getting the new version of the rfc6045-bis (RID) draft out, an= d likewise to Brian for the new version of the rfc6046-bis (RID transport) = draft. I found a couple of IANA-related concerns in the new material on RID envelo= ping of XML content beyond IODEF: (1) The IANA considerations text (under "Request for managing a namespace l= ist:") doesn't indicate what IANA needs to do. (2) The Version attribute of the ReportSchema class that envelopes the XML = content is required to be 1.0; that may not be appropriate for content othe= r than IODEF, or even future revisions of IODEF. RFCs are long-term archiv= al documents, so it's usually better for an RFC to specify something that's= not likely to need change in the near future. Creating an IANA registry for the standard specifications/namespaces and ve= rsions that RID can envelope would be a good way to deal with both of these= concerns. It'd suffice for the initial contents of the registry to consist of a singl= e entry for IODEF, even though IODEF's the default, as creation of the regi= stry should set up a lightweight process for registering future specificati= ons (Expert Review + Specification Required), but there's no harm in adding= more specifications now. Does anyone have suggestions for specifications beyond IODEF that ought to = be included now (for RID to envelope)? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of T= he IESG > Sent: Monday, January 02, 2012 12:52 PM > To: IETF-Announce > Cc: mile@ietf.org > Subject: [mile] Last Call: (Real-tim= e Inter-network Defense > (RID)) to Proposed Standard >=20 >=20 > The IESG has received a request from the Managed Incident Lightweight > Exchange WG (mile) to consider the following document: > - 'Real-time Inter-network Defense (RID)' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-01-16. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Security incidents, such as system compromises, worms, viruses, > phishing incidents, and denial of service, typically result in the > loss of service, data, and resources both human and system. Service > providers and Computer Security Incident Response Teams need to be > equipped and ready to assist in communicating and tracing security > incidents with tools and procedures in place before the occurrence of > an attack. Real-time Inter-network Defense (RID) outlines a > proactive inter-network communication method to facilitate sharing > incident handling data while integrating existing detection, tracing, > source identification, and mitigation mechanisms for a complete > incident handling solution. Combining these capabilities in a > communication system provides a way to achieve higher security levels > on networks. Policy guidelines for handling incidents are > recommended and can be agreed upon by a consortium using the security > recommendations and considerations. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Tue Jan 10 16:17:14 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 B613111E8096 for ; Tue, 10 Jan 2012 16:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 cin9P9ZChdo2 for ; Tue, 10 Jan 2012 16:17:13 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id BB87011E8095 for ; Tue, 10 Jan 2012 16:17:13 -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 q0B0HBNC010656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 19:17:11 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 10 Jan 2012 19:16:49 -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 q0B0Gmw0023800 for ; Tue, 10 Jan 2012 19:16:48 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Tue, 10 Jan 2012 19:16:47 -0500 From: To: , Date: Tue, 10 Jan 2012 19:16:47 -0500 Thread-Topic: [mile] Last Call: (Real-time Inter-network Defense (RID)) to Proposed Standard Thread-Index: AczJd1p7BBPTFhEpRsKs7cF8cKmNJgDHzVswANWKTeA= Message-ID: References: <20120102175218.17886.56877.idtracker@ietfa.amsl.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A6F0F5B9@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A6F0F5B9@MX14A.corp.emc.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] Last Call: (Real-time Inter-network Defense (RID)) to Proposed Standard 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, 11 Jan 2012 00:17:14 -0000 Hello David, Thank you for your review and comments. I will fix the version attribute, it was just listed the accepted version f= or IODEF, but flexibility would help even if it were only for future IODEF = versions without having to add values to the enumeration list. I think it would be good to start with a different specification to demonst= rate the capability and provide a clear example of how this would be done f= or another schema. =20 Are there suggestions from others on the list as to which schema should be = used for this? Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of dav= id.black@emc.com Sent: Friday, January 06, 2012 12:50 PM To: mile@ietf.org Subject: Re: [mile] Last Call: (Real-t= ime Inter-network Defense (RID)) to Proposed Standard Hi Kathleen, Nice work on getting the new version of the rfc6045-bis (RID) draft out, an= d likewise to Brian for the new version of the rfc6046-bis (RID transport) = draft. I found a couple of IANA-related concerns in the new material on RID envelo= ping of XML content beyond IODEF: (1) The IANA considerations text (under "Request for managing a namespace l= ist:") doesn't indicate what IANA needs to do. (2) The Version attribute of the ReportSchema class that envelopes the XML = content is required to be 1.0; that may not be appropriate for content othe= r than IODEF, or even future revisions of IODEF. RFCs are long-term archiv= al documents, so it's usually better for an RFC to specify something that's= not likely to need change in the near future. Creating an IANA registry for the standard specifications/namespaces and ve= rsions that RID can envelope would be a good way to deal with both of these= concerns. It'd suffice for the initial contents of the registry to consist of a singl= e entry for IODEF, even though IODEF's the default, as creation of the regi= stry should set up a lightweight process for registering future specificati= ons (Expert Review + Specification Required), but there's no harm in adding= more specifications now. Does anyone have suggestions for specifications beyond IODEF that ought to = be included now (for RID to envelope)? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of T= he IESG > Sent: Monday, January 02, 2012 12:52 PM > To: IETF-Announce > Cc: mile@ietf.org > Subject: [mile] Last Call: (Real-tim= e Inter-network Defense > (RID)) to Proposed Standard >=20 >=20 > The IESG has received a request from the Managed Incident Lightweight > Exchange WG (mile) to consider the following document: > - 'Real-time Inter-network Defense (RID)' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-01-16. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Security incidents, such as system compromises, worms, viruses, > phishing incidents, and denial of service, typically result in the > loss of service, data, and resources both human and system. Service > providers and Computer Security Incident Response Teams need to be > equipped and ready to assist in communicating and tracing security > incidents with tools and procedures in place before the occurrence of > an attack. Real-time Inter-network Defense (RID) outlines a > proactive inter-network communication method to facilitate sharing > incident handling data while integrating existing detection, tracing, > source identification, and mitigation mechanisms for a complete > incident handling solution. Combining these capabilities in a > communication system provides a way to achieve higher security levels > on networks. Policy guidelines for handling incidents are > recommended and can be agreed upon by a consortium using the security > recommendations and considerations. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=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 Richard.Struse@HQ.DHS.GOV Tue Jan 10 17:14: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 1ED8121F8555 for ; Tue, 10 Jan 2012 17:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 SY8U4zGK1SwD for ; Tue, 10 Jan 2012 17:14:40 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 61A9F21F851C for ; Tue, 10 Jan 2012 17:14:26 -0800 (PST) Received: from mail173-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Jan 2012 01:14:25 +0000 Received: from mail173-tx2 (localhost [127.0.0.1]) by mail173-tx2-R.bigfish.com (Postfix) with ESMTP id 465B3600513 for ; Wed, 11 Jan 2012 01:14:25 +0000 (UTC) X-SpamScore: -36 X-BigFish: VPS-36(zz9371I542M1432N4015Lzz1202hzz1033IL8275bh8275dhz2dhc1ahc1bh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:216.81.89.167; KIP:(null); UIP:(null); IPV:NLI; H:D1IBLPRHQ102.dhs.gov; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail173-tx2 (localhost.localdomain [127.0.0.1]) by mail173-tx2 (MessageSwitch) id 1326244464410947_16759; Wed, 11 Jan 2012 01:14:24 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.249]) by mail173-tx2.bigfish.com (Postfix) with ESMTP id 2B8A0560042 for ; Wed, 11 Jan 2012 01:13:37 +0000 (UTC) Received: from D1IBLPRHQ102.dhs.gov (216.81.89.167) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Jan 2012 01:13:33 +0000 Received: from D1IBLPRHQ105.dhs.gov (192.168.49.135) by D1IBLPRHQ102.dhs.gov (10.84.128.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 20:19:09 -0500 Received: from D1ABLPRHQ103.DSA.DHS (10.16.146.33) by d1iblprhq105.dhs.gov (10.84.132.100) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 20:15:24 -0500 Received: from ZAS1UG-0361.DHSNET.DS1.DHS (10.79.65.246) by D1ABLPRHQ103.DSA.DHS (10.16.146.33) with Microsoft SMTP Server id 14.1.355.2; Tue, 10 Jan 2012 20:15:01 -0500 Received: from ZAU1UG-0316.DHSNET.DS1.DHS ([10.79.65.217]) by ZAS1UG-0361.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 20:13:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 20:13:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] Last Call: (Real-time Inter-network Defense (RID)) to Proposed Standard Thread-Index: AczJd1p7BBPTFhEpRsKs7cF8cKmNJgDHzVswANWKTeAABGCRvg== From: "Struse, Richard" To: X-OriginalArrivalTime: 11 Jan 2012 01:13:32.0012 (UTC) FILETIME=[3BE09AC0:01CCCFFE] X-OriginatorOrg: hq.dhs.gov X-Mailman-Approved-At: Tue, 10 Jan 2012 18:15:04 -0800 Subject: Re: [mile] LastCall: (Real-timeInter-network Defense (RID)) to Proposed Standard 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, 11 Jan 2012 01:16:51 -0000 I'd suggest CVRF.=20 ----- Original Message ----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] Sent: Tuesday, January 10, 2012 07:16 PM To: david.black@emc.com ; mile@ietf.org = Subject: Re: [mile] LastCall: = (Real-timeInter-network Defense (RID)) to Proposed Standard Hello David, Thank you for your review and comments. I will fix the version attribute, it was just listed the accepted = version for IODEF, but flexibility would help even if it were only for = future IODEF versions without having to add values to the enumeration = list. I think it would be good to start with a different specification to = demonstrate the capability and provide a clear example of how this would = be done for another schema. =20 Are there suggestions from others on the list as to which schema should = be used for this? Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = david.black@emc.com Sent: Friday, January 06, 2012 12:50 PM To: mile@ietf.org Subject: Re: [mile] Last Call: = (Real-time Inter-network Defense (RID)) to Proposed Standard Hi Kathleen, Nice work on getting the new version of the rfc6045-bis (RID) draft out, = and likewise to Brian for the new version of the rfc6046-bis (RID = transport) draft. I found a couple of IANA-related concerns in the new material on RID = enveloping of XML content beyond IODEF: (1) The IANA considerations text (under "Request for managing a = namespace list:") doesn't indicate what IANA needs to do. (2) The Version attribute of the ReportSchema class that envelopes the = XML content is required to be 1.0; that may not be appropriate for = content other than IODEF, or even future revisions of IODEF. RFCs are = long-term archival documents, so it's usually better for an RFC to = specify something that's not likely to need change in the near future. Creating an IANA registry for the standard specifications/namespaces and = versions that RID can envelope would be a good way to deal with both of = these concerns. It'd suffice for the initial contents of the registry to consist of a = single entry for IODEF, even though IODEF's the default, as creation of = the registry should set up a lightweight process for registering future = specifications (Expert Review + Specification Required), but there's no = harm in adding more specifications now. Does anyone have suggestions for specifications beyond IODEF that ought = to be included now (for RID to envelope)? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of The IESG > Sent: Monday, January 02, 2012 12:52 PM > To: IETF-Announce > Cc: mile@ietf.org > Subject: [mile] Last Call: = (Real-time Inter-network Defense > (RID)) to Proposed Standard >=20 >=20 > The IESG has received a request from the Managed Incident Lightweight > Exchange WG (mile) to consider the following document: > - 'Real-time Inter-network Defense (RID)' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-01-16. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Security incidents, such as system compromises, worms, viruses, > phishing incidents, and denial of service, typically result in the > loss of service, data, and resources both human and system. = Service > providers and Computer Security Incident Response Teams need to be > equipped and ready to assist in communicating and tracing security > incidents with tools and procedures in place before the occurrence = of > an attack. Real-time Inter-network Defense (RID) outlines a > proactive inter-network communication method to facilitate sharing > incident handling data while integrating existing detection, = tracing, > source identification, and mitigation mechanisms for a complete > incident handling solution. Combining these capabilities in a > communication system provides a way to achieve higher security = levels > on networks. Policy guidelines for handling incidents are > recommended and can be agreed upon by a consortium using the = security > recommendations and considerations. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=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 _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From mallman@icir.org Wed Jan 11 05:52: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 32D7F21F86E5; Wed, 11 Jan 2012 05:52:56 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Header field occurs more than once: "Cc" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 tC6QtZZ+aBk7; Wed, 11 Jan 2012 05:52:55 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1E21F86E1; Wed, 11 Jan 2012 05:52:55 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q0BDqopm018330; Wed, 11 Jan 2012 05:52:51 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5052515DBEA0; Wed, 11 Jan 2012 08:52:50 -0500 (EST) To: ietf@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Born in the USA X-URL-0: http://www.icir.org/mallman-files/Document62102.doc X-URL-1: http://www.icir.org/mallman-files/Document97827.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma37937-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Jan 2012 08:52:50 -0500 Sender: mallman@icir.org Message-Id: <20120111135250.5052515DBEA0@lawyers.icir.org> X-Mailman-Approved-At: Wed, 11 Jan 2012 07:00:00 -0800 Cc: mile@ietf.org, tsv-area@ietf.org, tsv-dir@ietf.org Subject: [mile] tsv-dir review of draft-ietf-mile-rfc4046-bis-05 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org 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, 11 Jan 2012 13:52:56 -0000 ----------ma37937-1 Content-Type: text/plain Content-Disposition: inline I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This draft is basically ready for publication, but has nits that should be fixed before publication. In reading this document I flagged two issues. Neither of them huge, but I'd think perhaps they should be addressed before publication. (1) The language is a little wonky in my opinion. The document is laying out a 'transport protocol'. But, while this protocol does transport bits of data this is absolutely not a layer 4 protocol and so I was initially a bit confused. This draft lays out an application layer protocol (a slightly tweaked version of HTTP to be exact). It would seem useful to me to clean this up. (2) I wondered why the document said hosts MUST use port 4590. Certainly having a well know port is useful in many cases. But, I don't see why some consortium couldn't decide they were going to use port 4545 or whatever. Likewise, when setting up a callback it'd seem straightforward to give a port number, as well. I am not sure it is the biggest deal in the world, but a solution that leveraged late binding would strikes me as more flexible and hence better. allman ----------ma37937-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk8NlDEACgkQWyrrWs4yIs7S3ACfSB5LMu62jT5ifhdpLmX7lt0o jV0AoJkq8Wdd97cNuYqvOI89sPGEWMVQ =iqhf -----END PGP SIGNATURE----- ----------ma37937-1-- From paul.cichonski@nist.gov Wed Jan 11 09:07: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 1004C21F886F for ; Wed, 11 Jan 2012 09:07:35 -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 YQ23Cm3-Iwjt for ; Wed, 11 Jan 2012 09:07:34 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0B05E21F86E0 for ; Wed, 11 Jan 2012 09:07:33 -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; Wed, 11 Jan 2012 12:07:17 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 11 Jan 2012 12:07:32 -0500 From: "Cichonski, Paul" To: "mile@ietf.org" Date: Wed, 11 Jan 2012 12:07:30 -0500 Thread-Topic: Comments on latest version of RID (rfc6045-bis-05) Thread-Index: AczQg2c3c5fKl2PeRQWfobkE7+MP+A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [mile] Comments on latest version of RID (rfc6045-bis-05) 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, 11 Jan 2012 17:07:35 -0000 Kathleen, et al, A few of us (Dave Waltermire, Rich Struse, and Tom Millar) spent some time reviewing the latest RID draft and have a few comments that I have listed below; Dave will be following up with some comments as well. Some of these comments target the core-structure of RID so I apologize for not getting them in earlier, but we feel that they are important enough to merit attention now. These comments focus primarily on ensuring that RID is as simple as possible so that it is easy for system developers to understand the intent of the message types and, following from that, implement RID quickly. It may not be possible to incorporate all these comments into the current draft, but I think it is still useful to capture the direction that we think RID should head. Comments Below ('+' denotes new comment): + It seems that there is quite a bit of overlap between the RID message types of: Investigation (defined in section 6.4) and TraceRequest (defined in section 6.1). More specifically, TraceRequest seems to be a special case of Investigation, where it is assumed that the investigation will have to traverse multiple hops to find the source of the incident. I do not think there is enough of a difference between these two things to merit the two distinct message types. From a developer perspective, I think it makes more sense to deprecate TraceRequest and just add in normative prose explaining that if an Investigation cannot be completed at the *next-hop* in the chain, then the *next-hop* should forward the Investigation message onward (I would imagine the text could just be copied from the TraceRequest section). If this change is made, then the IODEF properties from the TraceRequest that are not in Investigation would have to be moved over to Investigation and made optional. By deprecating TraceRequest in favor of a more robust Investigation message type we will significantly reduce the complexity of RID, which I think will help reduce the barriers to adoption. + I think it makes sense to allow a RequestAuthorization message to be returned from any RID communication message type that initiates communication (I.e., from an InvestigationRequest, IncidentQuery, or Report). The RequestAuthorization is essentially a status on how the request is being processed, so it makes sense to allow it to be returned for any communication (see last note on potential name change). This also adds to the simplicity of the spec, since developers can just code that a RequestAuthorization may be returned from anything, and does not have to code any semi-complex conditional logic on when to return one. + Also for simplicity sake, I think it may be better to say that a "Result" can be returned from either an InvestigationRequest or a Query, with the result describing the result of how the request was processed. This becomes a simple rule of "every message type requesting info/action will return a result", of course the content of the result will differ depending on what initiated the communciation. + I think it also makes sense for the communication flows from InvestigationRequest and IncidentQuery to both allow for the return of zero-or-more Reports to be returned asynchronously. In many cases this will be needed since the system answering the RID communication may not have all the information right away and may need to return the data piecemeal over a period of time. + It would be nice to add in a very terse section that provides a normative description of the possible communication flows based on RID message types. Section 7 provides a lot of detail on how the communication may work, but a section listing the communication paths in the simplest way possible would greatly aid a developer trying to understand what he has to code. This section would also provide details on if the communication is expected to be synchronous or asynchronous. It is probably okay to roll this into the top of section 7; the key here is to be brief, exact, and simple enough for a developer to get all the normative rules very quickly and then refer to the more descriptive text in other sections if needed. For example, the section would contain sub-sections for those Message Types that initiate a RID communication and would list the expected return communication: 1. InvestigationRequest Description: Asynchronous request for information/action. Possible Responses: - RequestAuthorization (optional) - Result - Report (zero or more) 2. Incident Query (note: the key difference between InvestigationRequest and Query is that the first expects some action/state-change on the receiving system) Description: Synchronous request for information Possible Responses: - RequestAuthorization (optional) - Result - Report (zero or more) 3. Report Description: Asynchronous information report, may be pushed to systems, or may be sent to systems who had requested it via an InvestigationRequest or Query. Possible Responses: - RequestAuthorization (optional) + If possible, I think it would make more sense to change the message type names to the following: - Change "RequestAuthorization" to "Acknowledgement": I think Acknowledgement better reflects what the intention of this message type is doing: acknowledging the request and possibly providing status on how the request is being handled. - Change "Investigation" to "Request": changing it to a verb better reflects what RID is trying to do (I.e., initiate a request for action), removing the "Investigation" part makes it a bit more general-purpose, which will be useful down the road as we find more useful actions that may not align well with the term Investigation. - Change "IncidentQuery" to "Query": Same rationale as above, making it more general purpose will allow us to expand in more directions in the future. From kathleen.moriarty@emc.com Wed Jan 11 09:46: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 09C0221F86FD for ; Wed, 11 Jan 2012 09:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 QQz94J0Obfdl for ; Wed, 11 Jan 2012 09:46:56 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id CBAEC21F86FA for ; Wed, 11 Jan 2012 09:46:55 -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 q0BHkr7x000331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 12:46:54 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 12:46:43 -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 q0BHkgdB019068; Wed, 11 Jan 2012 12:46:42 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Wed, 11 Jan 2012 12:46:42 -0500 From: To: , Date: Wed, 11 Jan 2012 12:46:40 -0500 Thread-Topic: Comments on latest version of RID (rfc6045-bis-05) Thread-Index: AczQg2c3c5fKl2PeRQWfobkE7+MP+AAAV40g 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05) 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, 11 Jan 2012 17:46:57 -0000 Paul, Thank you very much for the detailed comments. I think the requests are re= asonable and are actually quite simple to fix in the document. I don't thi= nk they will cause significant issues. I'll describe below and agree they = will help developers. I'll start my responses with KMM on proposed solutio= ns. Thank you! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Cic= honski, Paul Sent: Wednesday, January 11, 2012 12:08 PM To: mile@ietf.org Subject: [mile] Comments on latest version of RID (rfc6045-bis-05) Kathleen, et al, A few of us (Dave Waltermire, Rich Struse, and Tom Millar) spent some time reviewing the latest RID draft and have a few comments that I have listed below; Dave will be following up with some comments as well. Some of these comments target the core-structure of RID so I apologize for not getting them in earlier, but we feel that they are important enough to merit attention now. These comments focus primarily on ensuring that RID is as simple as possible so that it is easy for system developers to understand the intent of the message types and, following from that, implement RID quickly. It may not be possible to incorporate all these comments into the current draft, but I think it is still useful to capture the direction that we think RID should head. Comments Below ('+' denotes new comment): + It seems that there is quite a bit of overlap between the RID message types of: Investigation (defined in section 6.4) and TraceRequest (defined in section 6.1). More specifically, TraceRequest seems to be a special case of Investigation, where it is assumed that the investigation will have to traverse multiple hops to find the source of the incident. I do not think there is enough of a difference between these two things to merit the two distinct message types. From a developer perspective, I think it makes more sense to deprecate TraceRequest and just add in normative prose explaining that if an Investigation cannot be completed at the *next-hop* in the chain, then the *next-hop* should forward the Investigation message onward (I would imagine the text could just be copied from the TraceRequest section). If this change is made, then the IODEF properties from the TraceRequest that are not in Investigation would have to be moved over to Investigation and made optional. By deprecating TraceRequest in favor of a more robust Investigation message type we will significantly reduce the complexity of RID, which I think will help reduce the barriers to adoption. KMM: Agreed. This is quite easy to accomplish. The difference between the= IODEF data in the TraceRequest and Investigation is the inclusion of the N= PPath information and as you mention, and the concept of tracing through ne= tworks. I will double check, but I believe the Incident request can do thi= s too. I think the simplest way of handling this to prevent any issues at = this point would be to add NPPath capabilities as optional to the Investiga= tion request. Then keep the section on the TraceRequest, but have it use t= he Investigation message where the NPPath is required. The other differenc= e is in the RID MsgType. I think it is valuable to keep the flag that dist= inguishes the Traceback capabilities in the now Investigation request messa= ge for parsing. If it were fully automated, the request to trace data may = be then sent to the management system for conducting a traceback. We can state that the full TraceRequest now uses the Investigation message = in the updates from RFC6045 section. Does that address the issue? The difference between Report and Request are similar as well. It may make= sense to keep this approach consistent for this message type as well where= Result would be a variant of Report with added capabilities required and t= he MsgType enumeration set to Result. Let me know if this is desired as we= ll to ease implementations. + I think it makes sense to allow a RequestAuthorization message to be returned from any RID communication message type that initiates communication (I.e., from an InvestigationRequest, IncidentQuery, or Report). The RequestAuthorization is essentially a status on how the request is being processed, so it makes sense to allow it to be returned for any communication (see last note on potential name change). This also adds to the simplicity of the spec, since developers can just code that a RequestAuthorization may be returned from anything, and does not have to code any semi-complex conditional logic on when to return one. KMM: This won't require a technical change as this is already permitted. I= f you look at the last couple of sentences of 7.3, you can see this is allo= wed and a use case is provided. What I will do here is to edit the diagram= to show that this is an option. =20 Does that meet the request? + Also for simplicity sake, I think it may be better to say that a "Result" can be returned from either an InvestigationRequest or a Query, with the result describing the result of how the request was processed. This becomes a simple rule of "every message type requesting info/action will return a result", of course the content of the result will differ depending on what initiated the communciation. KMM: One of the differences for the Result message from the Report message = is that the RID IncidentSource class is used. The other difference is that= the NPPath information is included so that the final result will show how = the investigation unfolded. Since this is specific to an Investigation or = TraceRequest, I would propose that we instead make Result a variant of Repo= rt. Where you would set the appropriate MsgType (Result) if it was the fin= al response to an Investigation (of either type - assuming the change to ha= ve a TraceRequest be a type of Investigation has been made). From the INCH= working group, the CSIRTs through the Report was a better fit for the Quer= y response since it would not include the additional information in the RID= schema. =20 Let me know what you think of this approach and if it makes sense to also s= implify the development effort required. + I think it also makes sense for the communication flows from InvestigationRequest and IncidentQuery to both allow for the return of zero-or-more Reports to be returned asynchronously. In many cases this will be needed since the system answering the RID communication may not have all the information right away and may need to return the data piecemeal over a period of time. KMM: I agree this makes sense. If the other changes are good, we would hav= e a Report set to Result required, but the ability to send Reports that are= not the final result during the investigation. Since Reports can be sent = unsolicited with no response required, I think this doesn't really break an= ything in the protocol, but explicitly states a function that applications = will need to provide. Does that sound good? + It would be nice to add in a very terse section that provides a normative description of the possible communication flows based on RID message types. Section 7 provides a lot of detail on how the communication may work, but a section listing the communication paths in the simplest way possible would greatly aid a developer trying to understand what he has to code. This section would also provide details on if the communication is expected to be synchronous or asynchronous. It is probably okay to roll this into the top of section 7; the key here is to be brief, exact, and simple enough for a developer to get all the normative rules very quickly and then refer to the more descriptive text in other sections if needed. For example, the section would contain sub-sections for those Message Types that initiate a RID communication and would list the expected return communication: 1. InvestigationRequest Description: Asynchronous request for information/action. Possible Responses: - RequestAuthorization (optional) - Result - Report (zero or more) 2. Incident Query (note: the key difference between InvestigationRequest and Query is that the first expects some action/state-change on the receiving system) Description: Synchronous request for information Possible Responses: - RequestAuthorization (optional) - Result - Report (zero or more) 3. Report Description: Asynchronous information report, may be pushed to systems, or may be sent to systems who had requested it via an InvestigationRequest or Query. Possible Responses: - RequestAuthorization (optional) KMM: I agree, this will help add clarity and avoid confusion for developers= . It is not a technical change, so I don't see any issue with adding this = in. + If possible, I think it would make more sense to change the message type names to the following: - Change "RequestAuthorization" to "Acknowledgement": I think Acknowledgement better reflects what the intention of this message type is doing: acknowledging the request and possibly providing status on how the request is being handled. KMM: I think this makes more sense, any objections? - Change "Investigation" to "Request": changing it to a verb better reflects what RID is trying to do (I.e., initiate a request for action), removing the "Investigation" part makes it a bit more general-purpose, which will be useful down the road as we find more useful actions that may not align well with the term Investigation. KMM: I think this makes sense as well, any objections? - Change "IncidentQuery" to "Query": Same rationale as above, making it more general purpose will allow us to expand in more directions in the future. KMM: I think this makes sense as well, any objections? Thanks again for the detailed review! Kathleen _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.waltermire@nist.gov Wed Jan 11 14:32:24 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 31DEA21F875C for ; Wed, 11 Jan 2012 14:32:24 -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 yAvFZxiV57zm for ; Wed, 11 Jan 2012 14:32:23 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0A121F8755 for ; Wed, 11 Jan 2012 14:32:23 -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; Wed, 11 Jan 2012 17:32:05 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 11 Jan 2012 17:32:21 -0500 From: "Waltermire, David A." To: "mile@ietf.org" Date: Wed, 11 Jan 2012 17:32:20 -0500 Thread-Topic: Comments on rfc6045-bis-05 Thread-Index: AczQsOGA48ihcD9JRxyDHwc1YPiy8A== 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] Comments on rfc6045-bis-05 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, 11 Jan 2012 22:32:24 -0000 Kathleen, et al, In reviewing this document I found a couple items that I wanted to bring to your attention. 1) In section 9.1 the statement "The IODEF/RID document may be encrypted to provide an extra layer of security between peers so that the message is not only encrypted for the transport, but also while stored" implies that messages will be stored as encrypted XML. This statement esentially requires that the signed XML be persisted using a method that will not corrupt the digest. Since this format is largely focused on exchange of messages it may be a step too far to state requirements for storage. My recommendation is to truncate the sentence to "The IODEF/RID document may be encrypted to provide an extra layer of security between peers." 2) In section 5.5 item 3, reads: "Implementations SHOULD NOT download schemas at runtime due to the security implications, and included documents MUST NOT be required to provide a resolvable location of their schema." This is a reasonable requirement, but it might make sense to move or duplicate this wording in a paragraph under section "10 Security Recommendations". Sincerely, David Waltermire From david.waltermire@nist.gov Wed Jan 11 15:20: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 0085021F853C for ; Wed, 11 Jan 2012 15:20:50 -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 U+bG7OVmp6XW for ; Wed, 11 Jan 2012 15:20:49 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 621E021F8537 for ; Wed, 11 Jan 2012 15:20:49 -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; Wed, 11 Jan 2012 18:20:31 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 11 Jan 2012 18:20:47 -0500 From: "Waltermire, David A." To: "mile@ietf.org" Date: Wed, 11 Jan 2012 18:20:46 -0500 Thread-Topic: Comments on rfc6046-bis-05 Thread-Index: AczQt6W0VbJtC7HrSrK5AL5xogLaLw== 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] Comments on rfc6046-bis-05 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, 11 Jan 2012 23:20:50 -0000 Kathleen, et al, After reviewing the document it is not clear to me if all the HTTP status codes are correct in Table 1. Considering the HTTP status codes used: http://datatracker.ietf.org/doc/rfc2616/?include_text=1 200 OK - indicates that "the request has succeded." 202 Accepted - indicates that "the request has been accepted for processing, but the processing has not been completed." The callbacks defined in table 1 provide a mechanism to asyncronously respond during various data flows. The 202 status code required for the callbacks indicate that the information provided in the request have been accepted, but not processed. It might make sense to use a 200 status code instead to indicate that the message has been received and processed as there is no futher mechanism defined for the receiver to acknowledge processing. This is especially true for RequestAuthorization messages which should be immediately processable. This also raises a question regarding rfc6045-bis-05. How would a RID system reject a Result or Report that has been posted? Reasons for rejection might be due to content contained in the message that would prevent the organization from accepting the message for legal or policy reasons. For example if the message contained information of a need-to-know or propriatary nature for which the receiving organization is not authorized. What would be the mechanism for communicating this rejection back to the submitter? Sincerely, David Waltermire From kathleen.moriarty@emc.com Wed Jan 11 15:26: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 39BA521F8552 for ; Wed, 11 Jan 2012 15:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 MTtVYOdYNwTn for ; Wed, 11 Jan 2012 15:26: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 9854B21F8543 for ; Wed, 11 Jan 2012 15:26:08 -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 q0BNQ7N9029065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 18:26:07 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 18:26:00 -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 q0BNPx4p000428; Wed, 11 Jan 2012 18:25:59 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 11 Jan 2012 18:25:59 -0500 From: To: , Date: Wed, 11 Jan 2012 18:25:57 -0500 Thread-Topic: Comments on rfc6045-bis-05 Thread-Index: AczQsOGA48ihcD9JRxyDHwc1YPiy8AAB1vMA 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Comments on rfc6045-bis-05 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, 11 Jan 2012 23:26:09 -0000 Thank you for the comments, Dave! I agree and will update the document accordingly to fix the nits. Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Wal= termire, David A. Sent: Wednesday, January 11, 2012 5:32 PM To: mile@ietf.org Subject: [mile] Comments on rfc6045-bis-05 Kathleen, et al, In reviewing this document I found a couple items that I wanted to bring to= your attention. 1) In section 9.1 the statement "The IODEF/RID document may be encrypted to= provide an extra layer of security between peers so that the message is no= t only encrypted for the transport, but also while stored" implies that mes= sages will be stored as encrypted XML. This statement esentially requires t= hat the signed XML be persisted using a method that will not corrupt the di= gest. Since this format is largely focused on exchange of messages it may b= e a step too far to state requirements for storage. My recommendation is to= truncate the sentence to "The IODEF/RID document may be encrypted to provi= de an extra layer of security between peers." 2) In section 5.5 item 3, reads: "Implementations SHOULD NOT download schemas at runtime due to the security= implications, and included documents MUST NOT be required to provide a res= olvable location of their schema." This is a reasonable requirement, but it might make sense to move or duplic= ate this wording in a paragraph under section "10 Security Recommendations"= . Sincerely, David Waltermire _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Thu Jan 12 07:58:42 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 37C4221F861D for ; Thu, 12 Jan 2012 07:58:42 -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 ZAs1xI4rMnd6 for ; Thu, 12 Jan 2012 07:58:41 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA2A21F8619 for ; Thu, 12 Jan 2012 07:58:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 998F8D930E; Thu, 12 Jan 2012 16:58: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 O40UlZDRreJn; Thu, 12 Jan 2012 16:58:39 +0100 (MET) Received: from [10.216.2.109] (unknown [38.67.0.130]) (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 BEC72D9308; Thu, 12 Jan 2012 16:58:38 +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, 12 Jan 2012 09:58:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC18C12-EB57-4912-B78B-F04D8B6E34B5@tik.ee.ethz.ch> References: To: "Waltermire, David A." X-Mailer: Apple Mail (2.1084) Cc: "mile@ietf.org" Subject: Re: [mile] Comments on rfc6046-bis-05 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, 12 Jan 2012 15:58:42 -0000 Hi, David, all, Thank you for the comments; comments thereon inline. On Jan 11, 2012, at 5:20 PM, Waltermire, David A. wrote: > Kathleen, et al, >=20 > After reviewing the document it is not clear to me if all the HTTP = status codes are correct in Table 1. =20 >=20 > Considering the HTTP status codes used: >=20 > http://datatracker.ietf.org/doc/rfc2616/?include_text=3D1 >=20 > 200 OK - indicates that "the request has succeded." > 202 Accepted - indicates that "the request has been accepted for = processing, but the processing has not been completed." >=20 > The callbacks defined in table 1 provide a mechanism to asyncronously = respond during various data flows. The 202 status code required for the = callbacks indicate that the information provided in the request have = been accepted, but not processed. It might make sense to use a 200 = status code instead to indicate that the message has been received and = processed as there is no futher mechanism defined for the receiver to = acknowledge processing. This is especially true for = RequestAuthorization messages which should be immediately processable. Correct; this is an error in the table. The intention is that callbacks = be answered with a 200. I'll correct this in the -06 rev of the = document. > This also raises a question regarding rfc6045-bis-05. How would a RID = system reject a Result or Report that has been posted? Reasons for = rejection might be due to content contained in the message that would = prevent the organization from accepting the message for legal or policy = reasons. For example if the message contained information of a = need-to-know or propriatary nature for which the receiving organization = is not authorized. What would be the mechanism for communicating this = rejection back to the submitter? I'll leave this question to Kathleen to answer authoritatively; however = AFAIK RID has no method for rejecting a report or result, because each = such message is essentially declarative ("I saw this") -- aside from the = authorizations and requests RID is fire-and-forget, and rejection is = irrelevant as far as the reporter is concerned. Adding a mechanism to = RID at this point to handle ack/nak would change this model. Thanks again, and best regards, Brian (as 6046-bis author)= From trammell@tik.ee.ethz.ch Thu Jan 12 08:22: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 546EF21F859A; Thu, 12 Jan 2012 08:22:30 -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 BhZcZn4RlPbt; Thu, 12 Jan 2012 08:22:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E055821F8539; Thu, 12 Jan 2012 08:22:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3E872D9315; Thu, 12 Jan 2012 17:22: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 KawT6YBn2O6c; Thu, 12 Jan 2012 17:22:28 +0100 (MET) Received: from [10.216.2.109] (unknown [38.67.0.130]) (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 0C4E0D9310; Thu, 12 Jan 2012 17:22:26 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <20120111135250.5052515DBEA0@lawyers.icir.org> Date: Thu, 12 Jan 2012 10:22:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D040FF6-6F6F-48EF-B7DA-CA73318C859F@tik.ee.ethz.ch> References: <20120111135250.5052515DBEA0@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org, tsv-area@ietf.org, tsv-dir@ietf.org Subject: Re: [mile] tsv-dir review of draft-ietf-mile-rfc4046-bis-05 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, 12 Jan 2012 16:22:31 -0000 Hi, Mark, Thanks for the review; I've addressed these issues in an -06 revision to = be submitted after last call is complete. Comments thereon, inline... On Jan 11, 2012, at 7:52 AM, Mark Allman wrote: >=20 > I've reviewed this document as part of the transport area = directorate's > ongoing effort to review key IETF documents. These comments were = written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address > any issues raised. The authors should consider this review together = with > any other last-call comments they receive. Please always CC > tsv-dir@ietf.org if you reply to or forward this review.=20 >=20 > This draft is basically ready for publication, but has nits that = should > be fixed before publication.=20 >=20 > In reading this document I flagged two issues. Neither of them huge, > but I'd think perhaps they should be addressed before publication. >=20 > (1) The language is a little wonky in my opinion. The document is > laying out a 'transport protocol'. But, while this protocol does > transport bits of data this is absolutely not a layer 4 protocol = and > so I was initially a bit confused. This draft lays out an > application layer protocol (a slightly tweaked version of HTTP to = be > exact). It would seem useful to me to clean this up. Agreed completely, and done. > (2) I wondered why the document said hosts MUST use port 4590. > Certainly having a well know port is useful in many cases. But, I > don't see why some consortium couldn't decide they were going to = use > port 4545 or whatever. Likewise, when setting up a callback it'd > seem straightforward to give a port number, as well. >=20 > I am not sure it is the biggest deal in the world, but a solution > that leveraged late binding would strikes me as more flexible and > hence better. Agreed that the restriction is too strict. However, I think it's simpler = at this point to declare the use of ports other than the well-known port = to be configurable out of band, as other RID system and consortium = configuration issues are out of scope for this document as well. So, the = clarifying text would be as follows: Every RID system participating in a consortium SHOULD listen for HTTP/TLS connections on the assigned = port. RID systems MAY be configurable to listen on ports other than the well-known port; this configuration is out of band and out of scope = for this specification. and When performing RID callback, a responding system MUST connect to the host at the network-layer address from which the original request was sent; = there is no mechanism in RID for redirected callback. This callback SHOULD = use TCP port 4590 unless configured out of band to use a different port. Many thanks, best regards, Brian (as 6046-bis author)= From mallman@icir.org Thu Jan 12 09:35:00 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 BB21721F8501; Thu, 12 Jan 2012 09:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 cb+okXLP1REH; Thu, 12 Jan 2012 09:35:00 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3A52421F84B3; Thu, 12 Jan 2012 09:34:59 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q0CHYrPB006197; Thu, 12 Jan 2012 09:34:56 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 651B9160A581; Thu, 12 Jan 2012 12:34:53 -0500 (EST) To: Brian Trammell From: Mark Allman In-Reply-To: <9D040FF6-6F6F-48EF-B7DA-CA73318C859F@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Going to California X-URL-0: http://www.icir.org/mallman-files/Document58554.doc X-URL-1: http://www.icir.org/mallman-files/Document76114.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma6587-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 12 Jan 2012 12:34:53 -0500 Sender: mallman@icir.org Message-Id: <20120112173453.651B9160A581@lawyers.icir.org> X-Mailman-Approved-At: Thu, 12 Jan 2012 09:37:58 -0800 Cc: mile@ietf.org, tsv-area@ietf.org, tsv-dir@ietf.org Subject: Re: [mile] tsv-dir review of draft-ietf-mile-rfc4046-bis-05 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org 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, 12 Jan 2012 17:35:00 -0000 ----------ma6587-1 Content-Type: text/plain Content-Disposition: inline > > (2) I wondered why the document said hosts MUST use port 4590. > > Certainly having a well know port is useful in many cases. But, I > > don't see why some consortium couldn't decide they were going to use > > port 4545 or whatever. Likewise, when setting up a callback it'd > > seem straightforward to give a port number, as well. > > > > I am not sure it is the biggest deal in the world, but a solution > > that leveraged late binding would strikes me as more flexible and > > hence better. > > Agreed that the restriction is too strict. However, I think it's > simpler at this point to declare the use of ports other than the > well-known port to be configurable out of band, as other RID system > and consortium configuration issues are out of scope for this document > as well. That is what I was thinking. I.e., I was not suggesting some way to discover the port or whatnot. Just not mandating that all communication happen on the assigned port (which of course you could never do regardless of what the RFC says). Sounds like a good set of changes to me. allman ----------ma6587-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk8PGbwACgkQWyrrWs4yIs4PHgCgl/wzh1Thsxo4G+MMge7SZIAQ yu4AmQF+oUUdVps3HrvuoKSOcNbv1R7u =fLdq -----END PGP SIGNATURE----- ----------ma6587-1-- From kathleen.moriarty@emc.com Thu Jan 12 11:11: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 310BB21F857D for ; Thu, 12 Jan 2012 11:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 T01a8NezGBAc for ; Thu, 12 Jan 2012 11:11: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 4009821F8574 for ; Thu, 12 Jan 2012 11:11:38 -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 q0CJBZwG007850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 14:11:35 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 12 Jan 2012 14:11:25 -0500 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0CJBOvu014124; Thu, 12 Jan 2012 14:11:25 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub35.corp.emc.com ([::1]) with mapi; Thu, 12 Jan 2012 14:11:24 -0500 From: To: , Date: Thu, 12 Jan 2012 14:11:22 -0500 Thread-Topic: [mile] Comments on rfc6046-bis-05 Thread-Index: AczRQz6aN758GVNZRHyH/stR13n1DAAGY5Xg Message-ID: References: <9BC18C12-EB57-4912-B78B-F04D8B6E34B5@tik.ee.ethz.ch> In-Reply-To: <9BC18C12-EB57-4912-B78B-F04D8B6E34B5@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: Re: [mile] Comments on rfc6046-bis-05 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, 12 Jan 2012 19:11:40 -0000 Hello Brian, If you take a look at section 7.3 of RID, you'll see that a possible respon= se to a Report is a RequestAuthorization message. The RequestAuthorization= message name is misleading, hence David & Paul's request to rename it to A= cknowledgement. The RequestAuthorization responds with a 'yes', 'no', or '= pending' as the RequestStatus and a 'Justification' as to why the Report is= rejected. A Result is really just a slight variant of a Report message, but if there = were problems with the format, you would need to provide that response. Ha= ving it as a variant of the Report solves this use case. Thanks, Kathleen (as RFC6045-bis author) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Thursday, January 12, 2012 10:59 AM To: Waltermire, David A. Cc: mile@ietf.org Subject: Re: [mile] Comments on rfc6046-bis-05 Hi, David, all, Thank you for the comments; comments thereon inline. On Jan 11, 2012, at 5:20 PM, Waltermire, David A. wrote: > Kathleen, et al, >=20 > After reviewing the document it is not clear to me if all the HTTP status= codes are correct in Table 1. =20 >=20 > Considering the HTTP status codes used: >=20 > http://datatracker.ietf.org/doc/rfc2616/?include_text=3D1 >=20 > 200 OK - indicates that "the request has succeded." > 202 Accepted - indicates that "the request has been accepted for processi= ng, but the processing has not been completed." >=20 > The callbacks defined in table 1 provide a mechanism to asyncronously res= pond during various data flows. The 202 status code required for the callba= cks indicate that the information provided in the request have been accepte= d, but not processed. It might make sense to use a 200 status code instead = to indicate that the message has been received and processed as there is no= futher mechanism defined for the receiver to acknowledge processing. This= is especially true for RequestAuthorization messages which should be immed= iately processable. Correct; this is an error in the table. The intention is that callbacks be = answered with a 200. I'll correct this in the -06 rev of the document. > This also raises a question regarding rfc6045-bis-05. How would a RID sys= tem reject a Result or Report that has been posted? Reasons for rejection m= ight be due to content contained in the message that would prevent the orga= nization from accepting the message for legal or policy reasons. For exampl= e if the message contained information of a need-to-know or propriatary nat= ure for which the receiving organization is not authorized. What would be t= he mechanism for communicating this rejection back to the submitter? I'll leave this question to Kathleen to answer authoritatively; however AFA= IK RID has no method for rejecting a report or result, because each such me= ssage is essentially declarative ("I saw this") -- aside from the authoriza= tions and requests RID is fire-and-forget, and rejection is irrelevant as f= ar as the reporter is concerned. Adding a mechanism to RID at this point to= handle ack/nak would change this model. Thanks again, and best regards, Brian (as 6046-bis author) _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Jan 13 11:27: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 1878721F85AD for ; Fri, 13 Jan 2012 11:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 Gnkl2c5GphyE for ; Fri, 13 Jan 2012 11:27: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 B436321F85AF for ; Fri, 13 Jan 2012 11:27:48 -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 q0DJRcKL005355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 14:27:46 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 13 Jan 2012 14:27:25 -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 q0DJROa3017458; Fri, 13 Jan 2012 14:27:24 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Fri, 13 Jan 2012 14:27:24 -0500 From: To: , , Date: Fri, 13 Jan 2012 14:27:23 -0500 Thread-Topic: Comments on latest version of RID (rfc6045-bis-05) Thread-Index: AczQg2c3c5fKl2PeRQWfobkE7+MP+AAAV40gAGkE4uA= 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05) 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, 13 Jan 2012 19:27:50 -0000 Hi, I took another look and NPPath is already in the Investigation message (my = mistake), so the only real difference is how these are handled by the flag = set (MsgType). This is really quite simple to have the Investigation and T= raceRequest implemented once for both purposes. That makes sense from a de= veloper standpoint and will not break anything in terms of interoperability= . If agreeable, I will have a Request message that can set the flag for ei= ther purpose. Thanks, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Wednesday, January 11, 2012 12:47 PM To: paul.cichonski@nist.gov; mile@ietf.org Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05) Paul, Thank you very much for the detailed comments. I think the requests are re= asonable and are actually quite simple to fix in the document. I don't thi= nk they will cause significant issues. I'll describe below and agree they = will help developers. I'll start my responses with KMM on proposed solutio= ns. Thank you! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Cic= honski, Paul Sent: Wednesday, January 11, 2012 12:08 PM To: mile@ietf.org Subject: [mile] Comments on latest version of RID (rfc6045-bis-05) Kathleen, et al, A few of us (Dave Waltermire, Rich Struse, and Tom Millar) spent some time reviewing the latest RID draft and have a few comments that I have listed below; Dave will be following up with some comments as well. Some of these comments target the core-structure of RID so I apologize for not getting them in earlier, but we feel that they are important enough to merit attention now. These comments focus primarily on ensuring that RID is as simple as possible so that it is easy for system developers to understand the intent of the message types and, following from that, implement RID quickly. It may not be possible to incorporate all these comments into the current draft, but I think it is still useful to capture the direction that we think RID should head. Comments Below ('+' denotes new comment): + It seems that there is quite a bit of overlap between the RID message types of: Investigation (defined in section 6.4) and TraceRequest (defined in section 6.1). More specifically, TraceRequest seems to be a special case of Investigation, where it is assumed that the investigation will have to traverse multiple hops to find the source of the incident. I do not think there is enough of a difference between these two things to merit the two distinct message types. From a developer perspective, I think it makes more sense to deprecate TraceRequest and just add in normative prose explaining that if an Investigation cannot be completed at the *next-hop* in the chain, then the *next-hop* should forward the Investigation message onward (I would imagine the text could just be copied from the TraceRequest section). If this change is made, then the IODEF properties from the TraceRequest that are not in Investigation would have to be moved over to Investigation and made optional. By deprecating TraceRequest in favor of a more robust Investigation message type we will significantly reduce the complexity of RID, which I think will help reduce the barriers to adoption. KMM: Agreed. This is quite easy to accomplish. The difference between the= IODEF data in the TraceRequest and Investigation is the inclusion of the N= PPath information and as you mention, and the concept of tracing through ne= tworks. I will double check, but I believe the Incident request can do thi= s too. I think the simplest way of handling this to prevent any issues at = this point would be to add NPPath capabilities as optional to the Investiga= tion request. Then keep the section on the TraceRequest, but have it use t= he Investigation message where the NPPath is required. The other differenc= e is in the RID MsgType. I think it is valuable to keep the flag that dist= inguishes the Traceback capabilities in the now Investigation request messa= ge for parsing. If it were fully automated, the request to trace data may = be then sent to the management system for conducting a traceback. We can state that the full TraceRequest now uses the Investigation message = in the updates from RFC6045 section. Does that address the issue? The difference between Report and Request are similar as well. It may make= sense to keep this approach consistent for this message type as well where= Result would be a variant of Report with added capabilities required and t= he MsgType enumeration set to Result. Let me know if this is desired as we= ll to ease implementations. + I think it makes sense to allow a RequestAuthorization message to be returned from any RID communication message type that initiates communication (I.e., from an InvestigationRequest, IncidentQuery, or Report). The RequestAuthorization is essentially a status on how the request is being processed, so it makes sense to allow it to be returned for any communication (see last note on potential name change). This also adds to the simplicity of the spec, since developers can just code that a RequestAuthorization may be returned from anything, and does not have to code any semi-complex conditional logic on when to return one. KMM: This won't require a technical change as this is already permitted. I= f you look at the last couple of sentences of 7.3, you can see this is allo= wed and a use case is provided. What I will do here is to edit the diagram= to show that this is an option. =20 Does that meet the request? + Also for simplicity sake, I think it may be better to say that a "Result" can be returned from either an InvestigationRequest or a Query, with the result describing the result of how the request was processed. This becomes a simple rule of "every message type requesting info/action will return a result", of course the content of the result will differ depending on what initiated the communciation. KMM: One of the differences for the Result message from the Report message = is that the RID IncidentSource class is used. The other difference is that= the NPPath information is included so that the final result will show how = the investigation unfolded. Since this is specific to an Investigation or = TraceRequest, I would propose that we instead make Result a variant of Repo= rt. Where you would set the appropriate MsgType (Result) if it was the fin= al response to an Investigation (of either type - assuming the change to ha= ve a TraceRequest be a type of Investigation has been made). From the INCH= working group, the CSIRTs through the Report was a better fit for the Quer= y response since it would not include the additional information in the RID= schema. =20 Let me know what you think of this approach and if it makes sense to also s= implify the development effort required. + I think it also makes sense for the communication flows from InvestigationRequest and IncidentQuery to both allow for the return of zero-or-more Reports to be returned asynchronously. In many cases this will be needed since the system answering the RID communication may not have all the information right away and may need to return the data piecemeal over a period of time. KMM: I agree this makes sense. If the other changes are good, we would hav= e a Report set to Result required, but the ability to send Reports that are= not the final result during the investigation. Since Reports can be sent = unsolicited with no response required, I think this doesn't really break an= ything in the protocol, but explicitly states a function that applications = will need to provide. Does that sound good? + It would be nice to add in a very terse section that provides a normative description of the possible communication flows based on RID message types. Section 7 provides a lot of detail on how the communication may work, but a section listing the communication paths in the simplest way possible would greatly aid a developer trying to understand what he has to code. This section would also provide details on if the communication is expected to be synchronous or asynchronous. It is probably okay to roll this into the top of section 7; the key here is to be brief, exact, and simple enough for a developer to get all the normative rules very quickly and then refer to the more descriptive text in other sections if needed. For example, the section would contain sub-sections for those Message Types that initiate a RID communication and would list the expected return communication: 1. InvestigationRequest Description: Asynchronous request for information/action. Possible Responses: - RequestAuthorization (optional) - Result - Report (zero or more) 2. Incident Query (note: the key difference between InvestigationRequest and Query is that the first expects some action/state-change on the receiving system) Description: Synchronous request for information Possible Responses: - RequestAuthorization (optional) - Result - Report (zero or more) 3. Report Description: Asynchronous information report, may be pushed to systems, or may be sent to systems who had requested it via an InvestigationRequest or Query. Possible Responses: - RequestAuthorization (optional) KMM: I agree, this will help add clarity and avoid confusion for developers= . It is not a technical change, so I don't see any issue with adding this = in. + If possible, I think it would make more sense to change the message type names to the following: - Change "RequestAuthorization" to "Acknowledgement": I think Acknowledgement better reflects what the intention of this message type is doing: acknowledging the request and possibly providing status on how the request is being handled. KMM: I think this makes more sense, any objections? - Change "Investigation" to "Request": changing it to a verb better reflects what RID is trying to do (I.e., initiate a request for action), removing the "Investigation" part makes it a bit more general-purpose, which will be useful down the road as we find more useful actions that may not align well with the term Investigation. KMM: I think this makes sense as well, any objections? - Change "IncidentQuery" to "Query": Same rationale as above, making it more general purpose will allow us to expand in more directions in the future. KMM: I think this makes sense as well, any objections? Thanks again for the detailed review! Kathleen _______________________________________________ mile mailing 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 Fri Jan 13 11:43: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 D06B321F852C for ; Fri, 13 Jan 2012 11:43: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 Ew8RdH1fWclm for ; Fri, 13 Jan 2012 11:43:39 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 713E921F858E for ; Fri, 13 Jan 2012 11:43:39 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 13 Jan 2012 14:43:29 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 13 Jan 2012 14:43:38 -0500 From: "Cichonski, Paul" To: "kathleen.moriarty@emc.com" , "mile@ietf.org" Date: Fri, 13 Jan 2012 14:43:34 -0500 Thread-Topic: Comments on latest version of RID (rfc6045-bis-05) Thread-Index: AczSK4jk9IbZRNsnQFqr7Gb1+bXIGA== 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.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05) 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, 13 Jan 2012 19:43:40 -0000 Kathleen, The change you propose for the Investigation/Trace request sounds good to me. One other comment that I had forgotten about: In the "Justification" enum under the RequestStatus class (section 5.2), can we add the values "CannotProcess" and "UnrecognizedFormat" to use when the request fails? As for everything else, I agree with most of your other comments as well; I included some notes inline below. Thanks, Paul On 1/13/12 2:27 PM, "kathleen.moriarty@emc.com" wrote: >Hi, > >I took another look and NPPath is already in the Investigation message >(my mistake), so the only real difference is how these are handled by the >flag set (MsgType). This is really quite simple to have the >Investigation and TraceRequest implemented once for both purposes. That >makes sense from a developer standpoint and will not break anything in >terms of interoperability. If agreeable, I will have a Request message >that can set the flag for either purpose. > > >Thanks, >Kathleen > >-----Original Message----- >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >kathleen.moriarty@emc.com >Sent: Wednesday, January 11, 2012 12:47 PM >To: paul.cichonski@nist.gov; mile@ietf.org >Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05) > >Paul, > >Thank you very much for the detailed comments. I think the requests are >reasonable and are actually quite simple to fix in the document. I don't >think they will cause significant issues. I'll describe below and agree >they will help developers. I'll start my responses with KMM on proposed >solutions. > >Thank you! >Kathleen > >-----Original Message----- >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >Cichonski, Paul >Sent: Wednesday, January 11, 2012 12:08 PM >To: mile@ietf.org >Subject: [mile] Comments on latest version of RID (rfc6045-bis-05) > >Kathleen, et al, > > >A few of us (Dave Waltermire, Rich Struse, and Tom Millar) spent some time >reviewing the latest RID draft and have a few comments that I have listed >below; Dave will be following up with some comments as well. > >Some of these comments target the core-structure of RID so I apologize for >not getting them in earlier, but we feel that they are important enough to >merit attention now. These comments focus primarily on ensuring that RID >is as simple as possible so that it is easy for system developers to >understand the intent of the message types and, following from that, >implement RID quickly. It may not be possible to incorporate all these >comments into the current draft, but I think it is still useful to capture >the direction that we think RID should head. > >Comments Below ('+' denotes new comment): > >+ It seems that there is quite a bit of overlap between the RID message >types of: Investigation (defined in section 6.4) and TraceRequest (defined >in section 6.1). More specifically, TraceRequest seems to be a special >case of Investigation, where it is assumed that the investigation will >have to traverse multiple hops to find the source of the incident. I do >not think there is enough of a difference between these two things to >merit the two distinct message types. From a developer perspective, I >think it makes more sense to deprecate TraceRequest and just add in >normative prose explaining that if an Investigation cannot be completed at >the *next-hop* in the chain, then the *next-hop* should forward the >Investigation message onward (I would imagine the text could just be >copied from the TraceRequest section). If this change is made, then the >IODEF properties from the TraceRequest that are not in Investigation would >have to be moved over to Investigation and made optional. > >By deprecating TraceRequest in favor of a more robust Investigation >message type we will significantly reduce the complexity of RID, which I >think will help reduce the barriers to adoption. > >KMM: Agreed. This is quite easy to accomplish. The difference between >the IODEF data in the TraceRequest and Investigation is the inclusion of >the NPPath information and as you mention, and the concept of tracing >through networks. I will double check, but I believe the Incident >request can do this too. I think the simplest way of handling this to >prevent any issues at this point would be to add NPPath capabilities as >optional to the Investigation request. Then keep the section on the >TraceRequest, but have it use the Investigation message where the NPPath >is required. The other difference is in the RID MsgType. I think it is >valuable to keep the flag that distinguishes the Traceback capabilities >in the now Investigation request message for parsing. If it were fully >automated, the request to trace data may be then sent to the management >system for conducting a traceback. > >We can state that the full TraceRequest now uses the Investigation >message in the updates from RFC6045 section. > >Does that address the issue? > >The difference between Report and Request are similar as well. It may >make sense to keep this approach consistent for this message type as well >where Result would be a variant of Report with added capabilities >required and the MsgType enumeration set to Result. Let me know if this >is desired as well to ease implementations. > >+ I think it makes sense to allow a RequestAuthorization message to be >returned from any RID communication message type that initiates >communication (I.e., from an InvestigationRequest, IncidentQuery, or >Report). The RequestAuthorization is essentially a status on how the >request is being processed, so it makes sense to allow it to be returned >for any communication (see last note on potential name change). This also >adds to the simplicity of the spec, since developers can just code that a >RequestAuthorization may be returned from anything, and does not have to >code any semi-complex conditional logic on when to return one. > >KMM: This won't require a technical change as this is already permitted. >If you look at the last couple of sentences of 7.3, you can see this is >allowed and a use case is provided. What I will do here is to edit the >diagram to show that this is an option. > >Does that meet the request? > >+ Also for simplicity sake, I think it may be better to say that a >"Result" can be returned from either an InvestigationRequest or a Query, >with the result describing the result of how the request was processed. >This becomes a simple rule of "every message type requesting info/action >will return a result", of course the content of the result will differ >depending on what initiated the communciation. > >KMM: One of the differences for the Result message from the Report >message is that the RID IncidentSource class is used. The other >difference is that the NPPath information is included so that the final >result will show how the investigation unfolded. Since this is specific >to an Investigation or TraceRequest, I would propose that we instead make >Result a variant of Report. Where you would set the appropriate MsgType >(Result) if it was the final response to an Investigation (of either type >- assuming the change to have a TraceRequest be a type of Investigation >has been made). From the INCH working group, the CSIRTs through the >Report was a better fit for the Query response since it would not include >the additional information in the RID schema. > >Let me know what you think of this approach and if it makes sense to also >simplify the development effort required. PC: I see, the Result is actually the result of the investigation/action, in which case, a Query would not merit a result. I had thought that the result was the result of the RID request itself (I.e., how it was processed). I withdraw this comment, IncidentQuery does not need a Result since there was no request for action. > >+ I think it also makes sense for the communication flows from >InvestigationRequest and IncidentQuery to both allow for the return of >zero-or-more Reports to be returned asynchronously. In many cases this >will be needed since the system answering the RID communication may not >have all the information right away and may need to return the data >piecemeal over a period of time. > >KMM: I agree this makes sense. If the other changes are good, we would >have a Report set to Result required, but the ability to send Reports >that are not the final result during the investigation. Since Reports >can be sent unsolicited with no response required, I think this doesn't >really break anything in the protocol, but explicitly states a function >that applications will need to provide. > >Does that sound good? > >+ It would be nice to add in a very terse section that provides a >normative description of the possible communication flows based on RID >message types. Section 7 provides a lot of detail on how the communication >may work, but a section listing the communication paths in the simplest >way possible would greatly aid a developer trying to understand what he >has to code. This section would also provide details on if the >communication is expected to be synchronous or asynchronous. > >It is probably okay to roll this into the top of section 7; the key here >is to be brief, exact, and simple enough for a developer to get all the >normative rules very quickly and then refer to the more descriptive text >in other sections if needed. > >For example, the section would contain sub-sections for those Message >Types that initiate a RID communication and would list the expected return >communication: > >1. InvestigationRequest >Description: Asynchronous request for information/action. >Possible Responses: >- RequestAuthorization (optional) >- Result >- Report (zero or more) > >2. Incident Query (note: the key difference between InvestigationRequest >and Query is that the first expects some action/state-change on the >receiving system) >Description: Synchronous request for information >Possible Responses: >- RequestAuthorization (optional) >- Result >- Report (zero or more) > >3. Report >Description: Asynchronous information report, may be pushed to systems, or >may be sent to systems who had requested it via an InvestigationRequest or >Query. >Possible Responses: >- RequestAuthorization (optional) > >KMM: I agree, this will help add clarity and avoid confusion for >developers. It is not a technical change, so I don't see any issue with >adding this in. PC: If I withdraw the above comment about a Query needed to return a Result, Incident Query would change to: 2. Incident Query Description: Synchronous request for information Possible Responses: - RequestAuthorization (optional) - Report (zero or more) > From kathleen.moriarty@emc.com Fri Jan 13 11:48: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 66F6F21F85AE for ; Fri, 13 Jan 2012 11:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 xOH3zTCIlnuy for ; Fri, 13 Jan 2012 11:48:24 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 117FB21F858E for ; Fri, 13 Jan 2012 11:48:23 -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 q0DJmMP0007969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 14:48:23 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 13 Jan 2012 14:48:11 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0DJmB0c019277; Fri, 13 Jan 2012 14:48:11 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Fri, 13 Jan 2012 14:48:10 -0500 From: To: , Date: Fri, 13 Jan 2012 14:48:09 -0500 Thread-Topic: Comments on latest version of RID (rfc6045-bis-05) Thread-Index: AczSK4jk9IbZRNsnQFqr7Gb1+bXIGAAAGFfQ 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05) 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, 13 Jan 2012 19:48:25 -0000 Thank you, Paul. This looks pretty simple and keeps things technically the same. I think th= e justifications make sense to add more detail as to why a request may not = have been approved. I'll add the enumerations. MILE: I will provide a list of changes to the list with the updated draft = on Monday morning after last call ends. This simplifies it and makes most = of the changes text really and could help simplify things for developers. Thank you, Kathleen -----Original Message----- From: Cichonski, Paul [mailto:paul.cichonski@nist.gov]=20 Sent: Friday, January 13, 2012 2:44 PM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: Comments on latest version of RID (rfc6045-bis-05) Kathleen, The change you propose for the Investigation/Trace request sounds good to me. One other comment that I had forgotten about: In the "Justification" enum under the RequestStatus class (section 5.2), can we add the values "CannotProcess" and "UnrecognizedFormat" to use when the request fails? As for everything else, I agree with most of your other comments as well; I included some notes inline below. Thanks, Paul On 1/13/12 2:27 PM, "kathleen.moriarty@emc.com" wrote: >Hi, > >I took another look and NPPath is already in the Investigation message >(my mistake), so the only real difference is how these are handled by the >flag set (MsgType). This is really quite simple to have the >Investigation and TraceRequest implemented once for both purposes. That >makes sense from a developer standpoint and will not break anything in >terms of interoperability. If agreeable, I will have a Request message >that can set the flag for either purpose. > > >Thanks, >Kathleen > >-----Original Message----- >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >kathleen.moriarty@emc.com >Sent: Wednesday, January 11, 2012 12:47 PM >To: paul.cichonski@nist.gov; mile@ietf.org >Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05) > >Paul, > >Thank you very much for the detailed comments. I think the requests are >reasonable and are actually quite simple to fix in the document. I don't >think they will cause significant issues. I'll describe below and agree >they will help developers. I'll start my responses with KMM on proposed >solutions. > >Thank you! >Kathleen > >-----Original Message----- >From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of >Cichonski, Paul >Sent: Wednesday, January 11, 2012 12:08 PM >To: mile@ietf.org >Subject: [mile] Comments on latest version of RID (rfc6045-bis-05) > >Kathleen, et al, > > >A few of us (Dave Waltermire, Rich Struse, and Tom Millar) spent some time >reviewing the latest RID draft and have a few comments that I have listed >below; Dave will be following up with some comments as well. > >Some of these comments target the core-structure of RID so I apologize for >not getting them in earlier, but we feel that they are important enough to >merit attention now. These comments focus primarily on ensuring that RID >is as simple as possible so that it is easy for system developers to >understand the intent of the message types and, following from that, >implement RID quickly. It may not be possible to incorporate all these >comments into the current draft, but I think it is still useful to capture >the direction that we think RID should head. > >Comments Below ('+' denotes new comment): > >+ It seems that there is quite a bit of overlap between the RID message >types of: Investigation (defined in section 6.4) and TraceRequest (defined >in section 6.1). More specifically, TraceRequest seems to be a special >case of Investigation, where it is assumed that the investigation will >have to traverse multiple hops to find the source of the incident. I do >not think there is enough of a difference between these two things to >merit the two distinct message types. From a developer perspective, I >think it makes more sense to deprecate TraceRequest and just add in >normative prose explaining that if an Investigation cannot be completed at >the *next-hop* in the chain, then the *next-hop* should forward the >Investigation message onward (I would imagine the text could just be >copied from the TraceRequest section). If this change is made, then the >IODEF properties from the TraceRequest that are not in Investigation would >have to be moved over to Investigation and made optional. > >By deprecating TraceRequest in favor of a more robust Investigation >message type we will significantly reduce the complexity of RID, which I >think will help reduce the barriers to adoption. > >KMM: Agreed. This is quite easy to accomplish. The difference between >the IODEF data in the TraceRequest and Investigation is the inclusion of >the NPPath information and as you mention, and the concept of tracing >through networks. I will double check, but I believe the Incident >request can do this too. I think the simplest way of handling this to >prevent any issues at this point would be to add NPPath capabilities as >optional to the Investigation request. Then keep the section on the >TraceRequest, but have it use the Investigation message where the NPPath >is required. The other difference is in the RID MsgType. I think it is >valuable to keep the flag that distinguishes the Traceback capabilities >in the now Investigation request message for parsing. If it were fully >automated, the request to trace data may be then sent to the management >system for conducting a traceback. > >We can state that the full TraceRequest now uses the Investigation >message in the updates from RFC6045 section. > >Does that address the issue? > >The difference between Report and Request are similar as well. It may >make sense to keep this approach consistent for this message type as well >where Result would be a variant of Report with added capabilities >required and the MsgType enumeration set to Result. Let me know if this >is desired as well to ease implementations. > >+ I think it makes sense to allow a RequestAuthorization message to be >returned from any RID communication message type that initiates >communication (I.e., from an InvestigationRequest, IncidentQuery, or >Report). The RequestAuthorization is essentially a status on how the >request is being processed, so it makes sense to allow it to be returned >for any communication (see last note on potential name change). This also >adds to the simplicity of the spec, since developers can just code that a >RequestAuthorization may be returned from anything, and does not have to >code any semi-complex conditional logic on when to return one. > >KMM: This won't require a technical change as this is already permitted. >If you look at the last couple of sentences of 7.3, you can see this is >allowed and a use case is provided. What I will do here is to edit the >diagram to show that this is an option. > >Does that meet the request? > >+ Also for simplicity sake, I think it may be better to say that a >"Result" can be returned from either an InvestigationRequest or a Query, >with the result describing the result of how the request was processed. >This becomes a simple rule of "every message type requesting info/action >will return a result", of course the content of the result will differ >depending on what initiated the communciation. > >KMM: One of the differences for the Result message from the Report >message is that the RID IncidentSource class is used. The other >difference is that the NPPath information is included so that the final >result will show how the investigation unfolded. Since this is specific >to an Investigation or TraceRequest, I would propose that we instead make >Result a variant of Report. Where you would set the appropriate MsgType >(Result) if it was the final response to an Investigation (of either type >- assuming the change to have a TraceRequest be a type of Investigation >has been made). From the INCH working group, the CSIRTs through the >Report was a better fit for the Query response since it would not include >the additional information in the RID schema. > >Let me know what you think of this approach and if it makes sense to also >simplify the development effort required. PC: I see, the Result is actually the result of the investigation/action, in which case, a Query would not merit a result. I had thought that the result was the result of the RID request itself (I.e., how it was processed). I withdraw this comment, IncidentQuery does not need a Result since there was no request for action. > >+ I think it also makes sense for the communication flows from >InvestigationRequest and IncidentQuery to both allow for the return of >zero-or-more Reports to be returned asynchronously. In many cases this >will be needed since the system answering the RID communication may not >have all the information right away and may need to return the data >piecemeal over a period of time. > >KMM: I agree this makes sense. If the other changes are good, we would >have a Report set to Result required, but the ability to send Reports >that are not the final result during the investigation. Since Reports >can be sent unsolicited with no response required, I think this doesn't >really break anything in the protocol, but explicitly states a function >that applications will need to provide. > >Does that sound good? > >+ It would be nice to add in a very terse section that provides a >normative description of the possible communication flows based on RID >message types. Section 7 provides a lot of detail on how the communication >may work, but a section listing the communication paths in the simplest >way possible would greatly aid a developer trying to understand what he >has to code. This section would also provide details on if the >communication is expected to be synchronous or asynchronous. > >It is probably okay to roll this into the top of section 7; the key here >is to be brief, exact, and simple enough for a developer to get all the >normative rules very quickly and then refer to the more descriptive text >in other sections if needed. > >For example, the section would contain sub-sections for those Message >Types that initiate a RID communication and would list the expected return >communication: > >1. InvestigationRequest >Description: Asynchronous request for information/action. >Possible Responses: >- RequestAuthorization (optional) >- Result >- Report (zero or more) > >2. Incident Query (note: the key difference between InvestigationRequest >and Query is that the first expects some action/state-change on the >receiving system) >Description: Synchronous request for information >Possible Responses: >- RequestAuthorization (optional) >- Result >- Report (zero or more) > >3. Report >Description: Asynchronous information report, may be pushed to systems, or >may be sent to systems who had requested it via an InvestigationRequest or >Query. >Possible Responses: >- RequestAuthorization (optional) > >KMM: I agree, this will help add clarity and avoid confusion for >developers. It is not a technical change, so I don't see any issue with >adding this in. PC: If I withdraw the above comment about a Query needed to return a Result, Incident Query would change to: 2. Incident Query Description: Synchronous request for information Possible Responses: - RequestAuthorization (optional) - Report (zero or more) > From harold.booth@nist.gov Fri Jan 13 16:22:53 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 AB4941F0C49 for ; Fri, 13 Jan 2012 16:22:53 -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 erwRO3YRmqBF for ; Fri, 13 Jan 2012 16:22:53 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 208AD1F0C46 for ; Fri, 13 Jan 2012 16:22:45 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 13 Jan 2012 19:22:36 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 13 Jan 2012 19:22:44 -0500 From: "Booth, Harold" To: "mile@ietf.org" Date: Fri, 13 Jan 2012 19:22:42 -0500 Thread-Topic: Comments for draft-ietf-mile-rfc6045-bis-05 Thread-Index: AczSUqFXbrsJPNCbQLCCdqFC79iz5w== Message-ID: 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_D7A0423E5E193F40BE6E94126930C493090146C7F3MBCLUSTERxcha_" MIME-Version: 1.0 Subject: [mile] Comments for draft-ietf-mile-rfc6045-bis-05 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, 14 Jan 2012 00:22:53 -0000 --_003_D7A0423E5E193F40BE6E94126930C493090146C7F3MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Hi, I was asked to comment on the document draft-ietf-mile-rfc6045-bis-05, specifically looking at its usage of XML Signature Syntax and Processing. I have a number of specific comments that I have included in the attached pdf. I have used the highlighting and commenting features of Adobe Reader, and hopefully that will work for everyone. In addition to the specific comments in the attached document I noticed the following: - The example including the digital signature did not validate for me. I have attached an example that should validate created using my own tools. I had to place an id on the signature element in order to get the xpath to work. Please note that the file assumes the schema for iodef-rid is co-located with the file and is named iodef-rid-1.2.xsd. There are likely some issues with my working example, but I just figured I could provide a working one if needed. - No mention of what algorithms are required for implementation of xml signing. The default set of algorithms available in the current version of the recommendation are very limited. The next version (1.1), which is still a work in progress, is attempting to fix this but is not yet final. The last version I saw was: http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303 - If you want additional algorithms to be used and to be interoperable, RFC4051 should be referenced as well as "XML Encryption Syntax and Processing", http://www.w3.org/TR/xmlenc-core/. As they both contain additional URIs that should be used to identify the algorithms and methods. - No mention of "XML Signature Best Practices", http://www.w3.org/TR/xmldsig-bestpractices/ which contains a wealth of information regarding security considerations when using xmldsig. I would also suggest that based upon these recommendations that you consider what features of xmldsig should be used. For example XSLT transforms might be restricted or disallowed. - "XML-Signature XPath Filter 2.0" provides better capabilities for selecting nodes and you may want to consider using that in favor of the 1.0 version. - This comment is also in the document but in case it gets lost, if the enveloped signature is intended to be placed into the DetachedSignature element you may want to rename it to Signature. If not, guidance should be added on where an enveloped signature should go. Not really from the document but: - The file name of the schema I initially received contains a space (which is encoded as %20). This is somewhat unusual. Hope this helps. Regards, -Harold --_003_D7A0423E5E193F40BE6E94126930C493090146C7F3MBCLUSTERxcha_ Content-Type: application/pdf; name="draft-ietf-mile-rfc6045-bis-05-comments.pdf" Content-Description: draft-ietf-mile-rfc6045-bis-05-comments.pdf Content-Disposition: attachment; filename="draft-ietf-mile-rfc6045-bis-05-comments.pdf"; size=132007; creation-date="Fri, 13 Jan 2012 17:15:57 GMT"; modification-date="Fri, 13 Jan 2012 18:36:22 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjYNJeLjz9MNCjY2NSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNDYv TGVuZ3RoIDE5NS9OIDYvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN48js0OgkAMhF+lRz2V6gpLYjZB 15+LkaAnjQfQ1ZAYMLIafXtbUC/b/Toz6ahYQwAqjoGIYBQEQIOQJwEp4QHQSHgIpAnGY7RJD5fu +uTU9szPBfpoMxZm1bE+ldWFv6md2/r4W4DSciMzBud15Vlv80qHssVdbguGqLOIqXTXU7M/GMPW JOVyQacxZlHb6Y+6rfbDdboCwu375nD28ouNz71rhUneOLmN0/pxL90dN4/Ci02834ToxnwEGABd A0iNDQplbmRzdHJlYW0NZW5kb2JqDTY2NiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmly c3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjK3UDBQsLHRDzJXMDUw ArKD7OwAAgwALVIENw0KZW5kc3RyZWFtDWVuZG9iag02NjcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jIyt1Qw ULCx0Q8yVzA1MAKyg+zsAAIMAC1lBDgNCmVuZHN0cmVhbQ1lbmRvYmoNNjY4IDAgb2JqDTw8L0Zp bHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVh bQ0KaN4ysjBQMFCwsdEPMlcwNTACsoPs7AACDAAszgQwDQplbmRzdHJlYW0NZW5kb2JqDTY2OSAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2Jq U3RtPj5zdHJlYW0NCmjeMrIwVDBQsLHRDzJXMDUwArKD7OwAAgwALOEEMQ0KZW5kc3RyZWFtDWVu ZG9iag02NzAgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDI5L04g MS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jKyMFIwULCx0Q8yVzA1ALGD7OwAAgwALPQEMg0KZW5k c3RyZWFtDWVuZG9iag02NzEgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVu Z3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jKyMFYwULCx0Q8yVzA1MAKyg+zsAAIM AC0HBDMNCmVuZHN0cmVhbQ1lbmRvYmoNNjcyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9G aXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4ysjBRMFCwsdEPMlcw NTACsoPs7AACDAAtGgQ0DQplbmRzdHJlYW0NZW5kb2JqDTY3MyAwIG9iag08PC9GaWx0ZXIvRmxh dGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMrIw VTBQsLHRDzJXMDUwArKD7OwAAgwALS0ENQ0KZW5kc3RyZWFtDWVuZG9iag02NzQgMCBvYmoNPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3Ry ZWFtDQpo3jKyMFMwULCx0Q8yVzA1MAKyg+zsAAIMAC1ABDYNCmVuZHN0cmVhbQ1lbmRvYmoNNjc1 IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9P YmpTdG0+PnN0cmVhbQ0KaN4ysjBXMFCwsdEPMlcwNTACsoPs7AACDAAtUwQ3DQplbmRzdHJlYW0N ZW5kb2JqDTY3NiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAv TiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMrKwUDBQsLHRDzJXMDUwArKD7OwAAgwALWYEOA0K ZW5kc3RyZWFtDWVuZG9iag02NzcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYv TGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jKysFQwULCx0Q8yVzA1MAKyg+zs AAIMAC15BDkNCmVuZHN0cmVhbQ1lbmRvYmoNNjc4IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29k ZS9GaXJzdCAyOS9MZW5ndGggNTE5L04gNC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3lxS246bMBD9 gv6DRR+WPMD4wiUQwirKqlIfNo2yq76keTBgAi1gBN4m6dfXJtmsWstmdM4ZZsaeoRFGGNGIIMa0 oSjwQm0ZCj2C9obHaDcJxgYBvtmJPyQJrLb6s0GURoZJU1jviYuROdjFB1jLTolOjXYhxnyoM1HM YD0IrmrZPXEl7KeYYqI3IZQSn2EH+w8YP8zgC6JzeP7QtUoJ8e/65tnmJS/DOfWckjLueF7Gncgn 2GFz4RVZGObEy7Qjb4Wuo211HbBFLDSVwlb2b/37zWC3tpPHc9ug32IYdWlLS9/AekyTTBYXpIVu XFqVUn0McDqd3BNz5XAEEkURnCvVNtbVKT6X/B9HjSfPMa9Ey0FDp+CKgw4P+p+Sx6vt1+/vSVf5 IDOuYoJd4pKrPvYiX1rUxS61UJr0qKiHpdWowUqTsefdB0ajujRiaZX6zZ2x/iNMHNyrhRJn5fCm PnZxI0q1yGUjh/gzntZicj/9+CTqY6XiTg4tb67kFO/GWOm9gwmYvGkCvT7mgdIZ7ESu9j5hboQZ CuaRGzAf+YxMOMShwQd4ect+2i+qzn9d0EYqMTOMuvQCXnWJ8GpXmZSqmsGr4VZdJ1Wa6gGbZuFb LzpU8mYUsOWDbia6zecteeTrofPDwCVegMLQoCCa0OGeZur6/9F3IfIxvc7vXwEGALsL45QNCmVu ZHN0cmVhbQ1lbmRvYmoNNjc5IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xl bmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4ysjRXMFCwsdEPMlcwNTACsoPs7AAC DAAtZwQ4DQplbmRzdHJlYW0NZW5kb2JqDTY4MCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUv Rmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMrK0UDBQsLHRDzJX MDUwArKD7OwAAgwALXoEOQ0KZW5kc3RyZWFtDWVuZG9iag02ODEgMCBvYmoNPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jKy tFQwULCx0Q8yVzA1MAKyg+zsAAIMAC2NBDoNCmVuZHN0cmVhbQ1lbmRvYmoNNjgyIDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0 cmVhbQ0KaN4yNjBQMFCwsdEPMlcwNTACsoPs7AACDAAsQwQpDQplbmRzdHJlYW0NZW5kb2JqDTY4 MyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUv T2JqU3RtPj5zdHJlYW0NCmjeMjYwVDBQsLHRDzJXMDUwArKD7OwAAgwALFYEKg0KZW5kc3RyZWFt DWVuZG9iag02ODQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDI4 L04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2MFIwULCx0Q8yVzAFs4Ps7AACDAAsaQQrDQpl bmRzdHJlYW0NZW5kb2JqDTY4NSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9M ZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjYwVjBQsLHRDzJXMDUwArKD7OwA AgwALHwELA0KZW5kc3RyZWFtDWVuZG9iag02ODYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2MFEwULCx0Q8y VzA1MAKyg+zsAAIMACyPBC0NCmVuZHN0cmVhbQ1lbmRvYmoNNjg3IDAgb2JqDTw8L0ZpbHRlci9G bGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4y NjBVMFCwsdEPMlcwNTACsoPs7AACDAAsogQuDQplbmRzdHJlYW0NZW5kb2JqDTY4OCAwIG9iag08 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgMjkvTGVuZ3RoIDU1NC9OIDQvVHlwZS9PYmpTdG0+ PnN0cmVhbQ0KaN6kU9uOmzAQ/YL+w4g+bPKAL4AhYQlRlFWlSs02yq6qStt9cIhZ0gJGZtIk/fra JNtV+1qEfTRnhjnDeByyGBiELIEwtDCBRHCLU5hEATw5nsFmcDgUIrqicPicZXSxtts9BCF3TJ7T 5RMnDNxihD3TpW5RtdiPCt10tUIFX1efYKeLQ2PpOWgD/f6llXgwag6HtqiVNFAa3QBWClCdkBAy pkujJO51eydRje7SgHH78oALZtFn4oaxmzH9AMGErt78IU94ErE//vvVyLKiKDjzlQyVH3Fe+jKS pS9itouThHO5i2ygbJStvXFF0jXEQx/oWneH7rUbdLMcZfNTU8NPZXpb2syzf+3N82yrd2ewjraf eRVil1J6PB7JMSTavFA+nU7pqcKm9i5B6amUfwVae4jsi0o1klrT30mU1Kan9ptSpov1xy+voovC 6K3ElDPCCb/4+04VMy8gjAQe5FkHu72ZeTUaL8/6TrZvNvR4rtXMK+05+f3+l3J5WIe3rvO+rO3Z pLUq8bbQtTbpezY8t0P48ds7tX+pMG21aWR9IYd8V8bL/+vUM+pqzTPa2eWamo/pRhX4JIIpmYgA RCwIiwSIKLnYk9DZz/ThsP0+esB98eMM9xrV2DF47hR9tKnp46jaao3VmD46btG2GvPcDvIwP587 1QKag6JraWy5cL0GV+2p1YQoDkksIEmc4WTji+qgMYzJv6k3CdhZvVyS3wIMAPI9B2ENCmVuZHN0 cmVhbQ1lbmRvYmoNNjg5IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0 aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNjRQMFCwsdEPMlcwNTACsoPs7AACDAAs VwQqDQplbmRzdHJlYW0NZW5kb2JqDTY5MCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmly c3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjY0VDBQsLHRDzJXMDUw ArKD7OwAAgwALGoEKw0KZW5kc3RyZWFtDWVuZG9iag02OTEgMCBvYmoNPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDI5L04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2NFIw ULCx0Q8yVzA1ALGD7OwAAgwALH0ELA0KZW5kc3RyZWFtDWVuZG9iag02OTIgMCBvYmoNPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDI5L0xlbmd0aCA4MzAvTiA0L1R5cGUvT2JqU3RtPj5zdHJl YW0NCmjenFXrbts2FH6CvAOhAq3zQyKpqyXLKoIEAwo0meFkQ4E4P2SJstTKpEbRs7On3yGl2Mka rGkNS4fnwnPj+USPhoggj3qIBkB8FIdAAkRDL0ZpipcRCogLJsssu9d6WBkDTUPfG6k/0id5ONJo pNORxgMNiKYP4P9iAa8b5HpjDHx5Tx2C9EMc8oAvBVeMq36y/HRlX4litwUO9bXYtSVaM9RJVjUH VqJ9o2rUiJJVtmzKlVxJ0THe8A3qcsk4qoREfVGzbd6KIleN4CupaoZ4vmV9lxewYqzskRLa7ZqB PUPaYNiETrtW8tA3qOkRFwqVrGjBvwlYCClZoXQyJr22+caSlUyPWSUvivibyR4czi3qUGKhNueb ucW4/cetBSG2Le+T48756szaSZ40TFUJFJRv+wRMkuc2NnXc405IcW7VSnUJxvv93tl7jpAb7BJC 8Zfrz7emKLvhvcp5wSxTUzKU+nmsdP6miOgF5xz60srO8aVkxsdVrtjkKnEJhT+F+XEDGtkk+EDI h3P8G3Kn+Pq5fuq5nn/U31xPymBdlv6U2ixinu3H1LXzogrsdRTFQRnFZVCGYAiHCKOy1X3FCxSZ McML0e26p2HFy8tJ+hEqeN53Yn3M0rUoH5Hp2msdo3Ec40Ottq2FxtZW+QtD4I3l0D0MrF3mKsfg HsOeKk8uFp/+fAp6UUixzlVCiaPPy+j7jhVzy3WIFmRph8pGzq1WSStLYTb5iUe9emzZ3KoAFnbf /MO0H9KpmWIHZedts+FJyyo1K0QrZPKOmN/MmO9XZ6zZ1CrhQgIKBqHxN0qs7OdA9v4d9Wbm9SOo GaNfQdspxCuYOylfRd6gbtXs9FU4ex2B7//aCTXTMBxWAxaHtQHksBzy+A8wB9VbkPKdE43RQfhm oD738T1gf5jL6ux/cDv63qhZivXUZSnu4NHwAEQvob/3gRs7LnzMA3/qULgMAj8a+DDU/AO+3a2/ Tm5VU3x7RDdCsXMtUY8dw3cwoPhuUq+FUPU5vtOyCw7HmWVwA5gvwe+dHp687Rle6EFSaLxwhuBu FDte6CGdxDTyUeh6Thi4cKu4jh8ED8dQBvcvIvwrwACUGjGCDQplbmRzdHJlYW0NZW5kb2JqDTY5 MyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUv T2JqU3RtPj5zdHJlYW0NCmjeMjY0VzBQsLHRDzJXMDUwArKD7OwAAgwALNwEMQ0KZW5kc3RyZWFt DWVuZG9iag02OTQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDI5L0xlbmd0aCAz OTIvTiA0L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjedJJLb6MwEID/ytySHMAzfuKqihS1qvbSLpvt LeJACGlSVRC1zmH//fpRvHSlShjrm8/DmLEFVYAgyIIQIDiC1sbPBEZZ2IU4wjaKMCtpPueQtW1u b9mm9q8n4EKFyHrN7nZUIoSBJTbs7r1v3Xkc7lvXL+9vOJJ/iJPiKHSBaoG4WLEHkOzxe/30uFQH edxb1RWqtVhI08miEm1XtFJ3ZMThqKVYsRqquA9Wj5frZdo3+3VtD/V4HtzHjkiX1vrfrUyJAhRx j2LCbI0uFf2zCec25CJ6lBNmq1XMnWzCufWLpZAe1YTZKhkWZ5swWym+1E2YreBf6iac21C34tnO cznFupNNOLch18ps57mEMXeyERu27Tvnuy1LshSDVIWGqrJCHtstlG3Y7+v+dfnj/HJ688OtArs/ l57lEHtenvbj6E4r9hzEZhhGt177S/cAvGI/L/0Ax/bto2d1+94PDj7vbKqvrG8vcB0P15gA6aSb XCnelP+/vTW+jzzd6L8CDABdFrboDQplbmRzdHJlYW0NZW5kb2JqDTY5NSAwIG9iag08PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0N CmjeMjYyVTBQsLHRDzJXMDUwArKD7OwAAgwALMoEMA0KZW5kc3RyZWFtDWVuZG9iag02OTYgMCBv YmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0 bT4+c3RyZWFtDQpo3jI2MlMwULCx0Q8yVzA1MAKyg+zsAAIMACzdBDENCmVuZHN0cmVhbQ1lbmRv YmoNNjk3IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEv VHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNjZQMFCwsdEPMlcwNTACsoPs7AACDAAsfwQsDQplbmRz dHJlYW0NZW5kb2JqDTY5OCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5n dGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjY2VDBQsLHRDzJXMDUwArKD7OwAAgwA LJIELQ0KZW5kc3RyZWFtDWVuZG9iag02OTkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0Zp cnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2NlUwULCx0Q8yVzA1 MAKyg+zsAAIMACzeBDENCmVuZHN0cmVhbQ1lbmRvYmoNNzAwIDAgb2JqDTw8L0ZpbHRlci9GbGF0 ZURlY29kZS9GaXJzdCAyOS9MZW5ndGggNDQ4L04gNC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3mxS TY+bMBD9KyMuSw4w/ohDQIRVlFWlHpKibNpLtAcDTrPdgBF4m+Tfr01C1a4q2R7NvPH4ed5wPgMC nMd2A58SEJGzFGYzDnsXJ7AdAGcFm96tcPYlTXGZ22MDjFMXyTJc7WlIwG0Skhdc6caoxvT+96aW 3ZuqoFcGiiscC63NcYKrTknzqpsnaZT/lDBC7aKMRtOYkoCIB0IeJvgFOMH1Z5z/wTdrXyhRxWxa BXEl5sFUFFEQM8kCKauynBUHIXlpE2WtLKm6tqQwB0q44425bt/b8Z+4Xfnp46U+wW/V9ZbbwrP/ 8R6ztNDVFSzQ9AvvaEybIJ7P5/DMQ939RBrHMV6Opj55t6TkcpD/JFp/yOzLo6olWjeopJFoy6O9 c5DJMv/6Y3x0WXa6kCahJKQhveF9q8qFx0ISMg+ytM3+39cU2yxFRzeb4FaVZk+J1QPmzIlD5+4k g0DPxjV+rDK5+WtdqZO/HkPvxS//2byWb1fYaKOGiLm2CnfqYnDnj1ruXGzZNNpkmR2LQbRvrWrg IE+9wlx2tutwn6obLRELyyVgjlwUib943Z8YlPlceRuBIOw2cR8CDABHqMq8DQplbmRzdHJlYW0N ZW5kb2JqDTcwMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMjkv TiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjYxUjBQsLHRDzJXMDUAsYPs7AACDAAsuQQvDQpl bmRzdHJlYW0NZW5kb2JqDTcwMiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9M ZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjYxUzBQsLHRDzJXMDUwArKD7OwA AgwALQUEMw0KZW5kc3RyZWFtDWVuZG9iag03MDMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2MVcwULCx0Q8y VzA1MAKyg+zsAAIMAC0YBDQNCmVuZHN0cmVhbQ1lbmRvYmoNNzA0IDAgb2JqDTw8L0ZpbHRlci9G bGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4y NrFQMFCwsdEPMlcwNTACsoPs7AACDAAtKwQ1DQplbmRzdHJlYW0NZW5kb2JqDTcwNSAwIG9iag08 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgMjkvTGVuZ3RoIDMxMS9OIDQvVHlwZS9PYmpTdG0+ PnN0cmVhbQ0KaN5cUctuwjAQ/JW9QQ6J31m7QpEQCPUCTSm3KAcHTKFCSQTm0L+vHUpUVfJ6tDNe 73gtpAEKQlFgGICBkHlADlJoqCJPYTsIAevZjMzLsG2AKxGZoiCLimahOkTAmiyuzvpz1y6td9Pl C6csLMaZkophStWE0klCViDJ+q+M0vB8lDfrqRBI0aFLhcQmldYcUttQTI9WIZN7kUu+T0gJjOlo hJRdf++fRsn73R7K7tz6W6WjNaExowKYzDNjzDN9SJhnoWqUhrQmW7f3FeqMmTiYQDIdD5lMUxzq hTI1+bg3X9PX8+fpEsInMfffvSMjRXbTU9N1/pSQXRTmbdv5oggzXAHX5K13LRzt5eZIaa+u9fA7 8kd/ZVRwyPPBLaIaX1KPnYZ3/797i6Aof3zQjwADAOBceZQNCmVuZHN0cmVhbQ1lbmRvYmoNNzA2 IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9P YmpTdG0+PnN0cmVhbQ0KaN4yNjVWMFCwsdEPMlcwNTACsoPs7AACDAAs4AQxDQplbmRzdHJlYW0N ZW5kb2JqDTcwNyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAv TiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjY1UTBQsLHRDzJXMDUwArKD7OwAAgwALPMEMg0K ZW5kc3RyZWFtDWVuZG9iag03MDggMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYv TGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2NVUwULCx0Q8yVzA1MAKyg+zs AAIMAC0GBDMNCmVuZHN0cmVhbQ1lbmRvYmoNNzA5IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29k ZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNjVTMFCwsdEP MlcwNTACsoPs7AACDAAtGQQ0DQplbmRzdHJlYW0NZW5kb2JqDTcxMCAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmje MjYzUDBQsLHRDzJXMDUwArKD7OwAAgwALLsELw0KZW5kc3RyZWFtDWVuZG9iag03MTEgMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+ c3RyZWFtDQpo3jI2M1QwULCx0Q8yVzA1MAKyg+zsAAIMACzOBDANCmVuZHN0cmVhbQ1lbmRvYmoN NzEyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAyOS9OIDEvVHlw ZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNjNSMFCwsdEPMlcwNQCxg+zsAAIMACzhBDENCmVuZHN0cmVh bQ1lbmRvYmoNNzEzIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAz MC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNjNWMFCwsdEPMlcwNTACsoPs7AACDAAs9AQy DQplbmRzdHJlYW0NZW5kb2JqDTcxNCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3Qg Ni9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjYzUTBQsLHRDzJXMDUwArKD 7OwAAgwALQcEMw0KZW5kc3RyZWFtDWVuZG9iag03MTUgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jI2M1UwULCx 0Q8yVzA1MAKyg+zsAAIMAC0aBDQNCmVuZHN0cmVhbQ1lbmRvYmoNNzE2IDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0K aN4yNrNUMFCwsdEPMlcwNTACsoPs7AACDAAtZgQ4DQplbmRzdHJlYW0NZW5kb2JqDTcxNyAwIG9i ag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3Rt Pj5zdHJlYW0NCmjeMjY3UDBQsLHRDzJXMDUwArKD7OwAAgwALM8EMA0KZW5kc3RyZWFtDWVuZG9i ag03MTggMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9U eXBlL09ialN0bT4+c3RyZWFtDQpo3jI2N1QwULCx0Q8yVzA1MAKyg+zsAAIMACziBDENCmVuZHN0 cmVhbQ1lbmRvYmoNNzE5IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0 aCAyOS9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNjdSMFCwsdEPMlcwNQCxg+zsAAIMACz1 BDINCmVuZHN0cmVhbQ1lbmRvYmoNNzIwIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJz dCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yNjdTMFCwsdEPMlcwNTAC soPs7AACDAAtQQQ2DQplbmRzdHJlYW0NZW5kb2JqDTcyMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjY3VzBQ sLHRDzJXMDUwArKD7OwAAgwALVQENw0KZW5kc3RyZWFtDWVuZG9iag03MjIgMCBvYmoNPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFt DQpo3jI2t1AwULCx0Q8yVzA1MAKyg+zsAAIMAC1nBDgNCmVuZHN0cmVhbQ1lbmRvYmoNNzIzIDAg b2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpT dG0+PnN0cmVhbQ0KaN4yNrdUMFCwsdEPMlcwNTACsoPs7AACDAAtegQ5DQplbmRzdHJlYW0NZW5k b2JqDTcyNCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAx L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMrYwVTBQsLHRDzJXMDUwArKD7OwAAgwALUIENg0KZW5k c3RyZWFtDWVuZG9iag03MjUgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDQ3L0xl bmd0aCA1NDQvTiA2L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjetJRNb9pAEIb/yt4CB3tn9nurCClK FPWSlNLckA/GLIUqslFiDv333S9v3ahp1UMlzPD6mRmvZ17BjSJAuLHEasItECmZj0iUED4ygkxb /4MT5BrJNmQC2cTUFDFHFqMEmaPKUedockz1EiFHzDHWN9fX9Gbtvx4JU7HDakVvt1gDCRfU0NDb F9eOp6G/a0e3uPvAAP0HGSqpJatAXgFcLek9EfThffz4sNgLJpxmu8oIt69E13VVay2rjGNCWL1X spVLuiao49HpejhfztOL08+Xdr8eTv34ukVUtbWWCC1r4OHVveSTLFSJWuJPmuScQqgBL8UkC5U8 JBea5JyGWmkKndcKFmsnGmVDN64b/clFjX6D4SaacDhbG2Dx6Fzahn657L4tPp6+Hp/9NS6DHr+f HS236NPiuBuG8bikTwHc9P0wrlZ+g/eEGfrp7HpyaJ9fHV23L64fSTZQer60fkSEyzgoHeaVp9aU J8Wpv+09WUTjv1rEAP7JInPsLaJa1AdnD5WGg6iEUZ03S2ertgWrQeyN6dTvLMLetQjHtCqWlpFk oQzSqjJNck59MjdBykkW6lfnkwvN0pp5sgQonUOriabkQpOcdw61yJJxk5xo6BFqM81yTqOtVeyc ZaFGJ1tnmuSc+mQmQmczyUJ9kU8uNMo3tg43o61RJlv7cf8vW6f/wV9sjTizddz0X2y90X4HLFn6 hwADAD6cTNwNCmVuZHN0cmVhbQ1lbmRvYmoNNzI2IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29k ZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4ytjRRMFCwsdEP MlcwNTACsoPs7AACDAAtQwQ2DQplbmRzdHJlYW0NZW5kb2JqDTcyNyAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmje MrY0VTBQsLHRDzJXMDUwArKD7OwAAgwALVYENw0KZW5kc3RyZWFtDWVuZG9iag03MjggMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+ c3RyZWFtDQpo3jK2NFMwULCx0Q8yVzA1MAKyg+zsAAIMAC1pBDgNCmVuZHN0cmVhbQ1lbmRvYmoN NzI5IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlw ZS9PYmpTdG0+PnN0cmVhbQ0KaN4ytjRXMFCwsdEPMlcwNTACsoPs7AACDAAtfAQ5DQplbmRzdHJl YW0NZW5kb2JqDTczMCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGgg MzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMra0UDBQsLHRDzJXMDUwArKD7OwAAgwALY8E Og0KZW5kc3RyZWFtDWVuZG9iag03MzEgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0 IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jK2tFQwULCx0Q8yVzA1MAKy g+zsAAIMAC2iBDsNCmVuZHN0cmVhbQ1lbmRvYmoNNzMyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURl Y29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yMTBQMFCw sdEPMlcwNTACsoPs7AACDAAsWAQqDQplbmRzdHJlYW0NZW5kb2JqDTczMyAwIG9iag08PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0N CmjeMjEwVDBQsLHRDzJXMDUwArKD7OwAAgwALGsEKw0KZW5kc3RyZWFtDWVuZG9iag03MzQgMCBv YmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDI4L04gMS9UeXBlL09ialN0 bT4+c3RyZWFtDQpo3jIxMFIwULCx0Q8yVzAFs4Ps7AACDAAsfgQsDQplbmRzdHJlYW0NZW5kb2Jq DTczNSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5 cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjEwVjBQsLHRDzJXMDUwArKD7OwAAgwALJEELQ0KZW5kc3Ry ZWFtDWVuZG9iag03MzYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3Ro IDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jIxMFEwULCx0Q8yVzA1MAKyg+zsAAIMACyk BC4NCmVuZHN0cmVhbQ1lbmRvYmoNNzM3IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJz dCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN4yMTBVMFCwsdEPMlcwNTAC soPs7AACDAAstwQvDQplbmRzdHJlYW0NZW5kb2JqDTczOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjEwUzBQ sLHRDzJXMDUwArKD7OwAAgwALMoEMA0KZW5kc3RyZWFtDWVuZG9iag03MzkgMCBvYmoNPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDMwL04gMS9UeXBlL09ialN0bT4+c3RyZWFt DQpo3jIxMFcwULCx0Q8yVzA1MAKyg+zsAAIMACzdBDENCmVuZHN0cmVhbQ1lbmRvYmoNNzQwIDAg b2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2L0xlbmd0aCAzMC9OIDEvVHlwZS9PYmpT dG0+PnN0cmVhbQ0KaN4yMbBQMFCwsdEPMlcwNTACsoPs7AACDAAs8AQyDQplbmRzdHJlYW0NZW5k b2JqDTc0MSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNi9MZW5ndGggMzAvTiAx L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeMjGwVDBQsLHRDzJXMDUwArKD7OwAAgwALQMEMw0KZW5k c3RyZWFtDWVuZG9iag03NDIgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDIxL0xl bmd0aCA2MzcvTiAzL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjefJTNbtswDMdfxU8wNmmQukBRIFs9 LMDQAGtzaIcdaIm2hcpWqo9s2dOPFhPXp10sk/z/SIqSvSrXxVWxKm+KmxUvZbG4XhV3d/AZA311 Q4RvZI8UjUKoBuW0Gdosuyp+wCP2lOPwlOp4OhA882ORnzDC9/fzTK94aB6YrzEGYV/xof4v+2Ca hjwNisLP5QpqT0cChd4NoIxXqW8s/QHtIipFXKJLQ4s+9RZTBNe6gd7Ac0mIxmoqrm/hPblIgV2W its1tB6PVCyWJdTJWoqgsW3JnxddWyBrzSGYANRrDB3QkJfGOk4MjUcVDbfTJmNzWktN/LC8absI vRlSgAP52LkUcNDSBqeveTiTkdGLIWS2PvwzZ06f8ehRU4/+DRrDfcH3YMcOdxU8yahetOEhjnt4 FQcPzFIIBqxIHUGQyN+8FIv1FVTJO35ZgUp+PIITG2s+AvdGQ42erRKmxModTtKc87oh3rAZeK43 S7Cu5ctjBxfhEz80NeCpNYE3Qxp6VLkhaj0RHGwKMqv424XEAzPOQ+w4NlmoUiToU7EoryH79Hj0 OZsibaxF4HOf9NxPj0ElmxsqyzH4ntAzMb52aBupcHaGYnG7hE2+GLCRapvZZdvkqwSbaeubfME2 FXy5lK8ErgSuZnA1UVvRbEWznWm2k6aKHTxKuZ3IdyLfzeS7s2Ci+mSjOdgT7ORw94LuBd3P0P3E vEjwuXOerzL5nu9obQOgsChhnLEoZXFKgXkMyJ/nZQwkMAlMM5gmyojGiMbMNGbSEI9hkHJO5E7k biZ3Z8FEaXM0o0OGkARMAqYZmCbiJMGYh3C6uH/JL+ny87u//yfAAHaM7qcNCmVuZHN0cmVhbQ1l bmRvYmoNNzQzIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCAxNC9MZW5ndGggMjg0 L04gMi9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jzSTUvDQBDG8fkoOSoimd2dfZOSS/EkFBE9lR6K BumhrZB68OJHV5c8TyTQf5PAD2YnVmqnnVXtktNuterX58/Tpcu5fzi8TVur1l4/dW7+xf+MJ4oE JCF1jvdIRMqcACMACVAMikExKAYlQolQIpQEJUFJUDKUDCVDyVAKlAKlQKlQOFxdJuJIypmUQykk 5zwbWWDOO5Zn5emF5YjoBXqBntEzekYv0ov0Ir1ELy1nTi/Ry/QyvUyv0Cv0Cr1Kr9KryxK5ReUa lXtUeN451tjMrSsb2Nnb9c9fH2P/uH8fp2FoX9hmfxyn7dXPr3zLQV7lLCe5kXXrsV1ju7u0ey+x XXf/VbmVe9nIS6teR3xwu2H4E2AAv+qH8w0KZW5kc3RyZWFtDWVuZG9iag03NDQgMCBvYmoNPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYwOS9MZW5ndGggMzA0L04gNzYvVHlwZS9PYmpTdG0+ PnN0cmVhbQ0KaN7s0slx5TAMRdFUXgZNECOrXA7C+QdjXOfQu7+SrgbqSFDY0VGYyXI3V065ggoV lWqq9KiWHXJkl34y3959y+27KxV9ZUO77NGha3TqXrp0g27dpEe36ac72+vws+0mh+ZLw+YuB+ch R7fPdnhecnzeCnw+f6bw93dN8Cx8YQp8cRX4Yt8VX4QS366d+KKU3BOtxBejxBdPiW/XKnxpKnx5 VfjSVfhyPx6+vbfwZanwZavx5ajx5VPj22sbX5kaX101vnI1vgoNvj03+Ko0+Ko1+Go0+Opp8O3+ w9emh6+vHr52PXwdevjW9vD1jhdfM1+AvQM+CHsnfCAuZ0e/R2ZnfEDODvmgnJ3ygTkhM5xrMFvo 19e/n/10x/c3+/n+/uQnP/nJ/5q/AgwA98xfWw0KZW5kc3RyZWFtDWVuZG9iag03NDUgMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDYvTGVuZ3RoIDE0MC9OIDEvVHlwZS9PYmpTdG0+ PnN0cmVhbQ0KaN4ysTRUMFCwsdF3LkpNLMnMz3NJLEnVcLEyMjAEIiBhaGpsaqZtYKhuYKCuCVGV X6Th7heq4JpXnFyUWVCiYKhnpmeqZ6Sp75ufgqLd0NjQwtjMyEjXwBSiPaAoP6U0ORWoP8BHwT0j v7gEaoSlngFQf0hmSU6qBtxc/9KSgtISTTs7gAADAHLaLyYNCmVuZHN0cmVhbQ1lbmRvYmoNNzQ2 IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA2NjQvTGVuZ3RoIDEyNDcvTiA3Ny9U eXBlL09ialN0bT4+c3RyZWFtDQpo3rSaz44UNxCHX8VvMK5/LltCKyUk5BQJATfEAZERymUH7U4k 8vb59Qg21ZsTXakLTG+77c9lT312j3Vp640aDW7ahLl508mNehuK/6TNLrjb1tBGqxGxNZQinqPh I6l644kSfTZBPT5Wk62o9Ca41Rc17XhkoGJprCis26NzNV2N3XozbryImlmT7twMVbFIG9REAIim xXATVYiDxVH1XEAVVG3SfDRl0uaoUtwa+NWM2rSmTtwmmpz4ByjWURmqNAb88mbaAd3BYGPrtTRz QTf7aLbQFPXVRve5dbwNBgQRQJQcH2YbhjaJCWiGwgzWhT8TOyAnAosoON8CCUztCIyA3wYKoxn3 LXS47XOhsAK9IxikE31Ah2jrhKB7ZIreCAqbt+ngRcDRr415SFsdLRMqReMojCFYgjoIsVyGoSQE ZQ1cEXqy5jY+89ZtBJ0mrjohljR9i4CgjxtNV8QH47gFw9DLtUUDWPi0BQjVYHRRJW3c3LfIYPTw aQuWgoG32oFH7dYXctTFt8At2yZR3yKHa2a0wYxIYpZsQVRqL16cXl7ur+f76yOmycAcfXN6+XD5 8vPl6/uOK1uIlfKH0+/nP/78+J+/vv74gEcx6uv25Jvz4+Wvh0/nR1T769frb2+vH69nzIV+u/sK DeGCbhevHy6f3p6v70+vf3l1enf+ev1wd3d6c7k90E/v/v5yRuWfz3d3kZBL+BiD9cSn1I/zWRHf inyJ+M0avtkjHx/n+9a3/x+QIqAkALUIkCOgJgC9CFAioCW+wr0IUCPgSABKEaBFQE8AjiLAEQFn AnAVAXoEXMcBpcgjM3qEEx6RIpHMKBL+cZH8dH9/uQ3wty/xE2+RWFbMOpwQixaJZcUpyQmxaJFY 1m5KJsSiRWJZuymZEIvViEXi4lU5IRaTIsC4uOGEWGwUAcbFDSfEYqsIcJdmEmIZXAQYFzeSEMuw IsC4uJHDYpE+9mIZs4g3Zh1JiMVrxCIUs44kxOJaBBizjiTE4l4EGLOO2OEp+W27+O8eusgzFJff kvDMLPIMxbWO+PGAzmcBLdIO72boPMpr39eOT7xFFuJdDk1YaBVZiOMM1X44oN93N0+8RVKSmEM1 8dpsFVlI4gxVPhzQ7xvup5dAvchKEqeoyuEUIOM5cJGldBfhzHu1XqQpjZrSw5qy51mVqMhTussC I/Oyt0hUGkWlniEsUpPGXbkeVpPo8y8+FbnJdrM04SbiIjlZ3MNZzxAW6cjiJs4oQ1jkI4vp3TK/ 40iRgCwmH8v8kCNFxhlx0WEZ40iRcUZ0oiXeuJEWKWbEbGMZxWiRYsYu22QUo0WKGbtsMzOERU4Z u2yTcYoVOWXEt0Qj4xQrcorHbDMyTrEip3jMNiPjlFHkFI/ZZmScMoqc4tF6I+OUUeQUj0vukXGK Fzlld8ZnZJziRU7ZnfIZGad4kVN2RxjG8W3LfL799yLF7H4/HhnFzCLFrKhpzyhmFilmxUH3jGJm kWJWTI+eUcwqUszumIBnFLOKFLM7J+AZxawixewOCnjqBFqNYnR3UsAzR9C6FBHGxZhnzqD1UUQY F2OeOYTWVxFhdIonnMLERYTRKbNnCK2IMDplZg6E0ywijE6ZCacwUxFhdMqUDKEWEUanTM0QehFh dMr8Qaf8I8AAUhcG0A0KZW5kc3RyZWFtDWVuZG9iag03NDcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0ZpcnN0IDIyOS9MZW5ndGggMjMzMS9OIDI2L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmje 7Fpbb9s4Gv0F+x+IDLBNgMri/ZKmKYoWg+nDdLNtsfvQyQMlU4mniuSx5CaZX78fSUmhncRN0Bbo Ai1y8eH5SFPk+W5OBcMII8EIEkQgQTmSWMFvgQiWFAYNIkRweKERkdgAheEFlUjAKFEwLIRAVDMw ZgpRA0sIJhDDBGyYhBeMIcEZYlzDypwgJhSswym8MGDDNeJYwCa4QpyAoSCwFuZgQ/y2uP8BtBRg 7HegPIU1kgr7EQUvjB+RSEnlpwqklPRPY5CWmqGjo/zlCfx4Cxui8Ljvjo/zVx/JDJ4EvvEMn+av Vs72i7Z5bXu3//qQYgJfhBFNOeUZFk8wfnKQ/4p4/vv99Nvf93FVCI2dzirNTcYraTKNizLjc1PR aj6XErOD/ARO15/7u/ykXa6X4fw9+vfazk/aRdN3HwnjM2PC084wQ9x4yEc4sZLNBLlhI0xZP1fh iU3nChrmjmyEKQvGAt+w6VxOvPHERpiy3lhrgHqCI8twMB7ZAE/zd67s4anpjBgSBon2b8BmGtPw 2KCW0/z9uvhz/7fF2XkN3/2Bx/310uXTUP5h/7xo2/78IP/giZdN0/bHx3D7v4JK838tXYMqW3cu P7Er1/T+rcLZh/cXRoAiuAiHrJQH8cRPp3cKN7a99igv8IvHyoupnfJKaJBXxVghyxJnJfzOuNRV VpRCZZRSbGUhHJFllBdL5QXufI+8WHxUHi6Dj3BieZTXyPINeXmYzuUb8mKMbsxlG/Ly0BsH4eoJ jiyNehrZALck4ge9RLghQSJ+699LIhDTtiRCWSKReGoPlQh5tET4bonwDYmAX1WWKS8RzDIuCpwZ iEkZVxAPSUkZdUMEMhsSwfdJROooESXDRQ5wYlWUyMiqDYl4GCRCJzadKweJDKzckIiHYMy0jzFi hBMrgkQmVtwhET8YJKJFkIjf+ldJ5KPPh3BM43Gd7tBMtEw1I2SimXiMD9SMeHRY0QLv0kxKe80Y bKrKmkwp5UAztALNaJMxDaneMserufGakSqVjLg3qkAN4Z+UEhr8d4BTAjDSX93IjpDy1HhMaeNS AzsYTwkvwnTlJCINcGJBBklEGmDKeuOQDm9gkoa98cgOUA+PEI2hBAHIprkjG40ndpi7leDHXd2d 4Ef2zgTvo6fxpdSdCX5iB8h5ajw637jUyIoN17y7OOBC7ygOJvbO4mAqO+4sDiZ2qBUS1ovBeFaN cGKJCUIa2QgZpqnxVLJEOLHReGIjTFdO7zfCicV6434jTFn/vJSGQDXAkeVGhecd2Ai3wpgfjMWQ iWEMXOJ7ZTpxK9NB1Z5EreCNX4ha9xZacnttpnVSaIWT2bX2x2GJ0GkM4Xcq7PWj0yqmO9NqQkOI VFVBS12YzEFezaBPEZk2RGVMlc5yLisspA+Rhm/U9ereuj7qIBXNbVmM7ABTNgkZA5xYLdOQMcCU DXLUUXB6I0RCkRDlOLABbssRBlM5+q1/Lzlyeqvw0uZGMhybL0omLhE60C3JcP5YyTCmd0kmpUEy ZQntHq1ERgotMm4lzrRzFehmrufWgWaU9ZLROpVM3OeGZIiMl4NjFAp5k41wZJmJUWhgB5iyidwG OLF6Q24DTFkvGRJLrQFOrIpyG9kAR8kQHmt1GAySIbEQ81v/dpLpV+tEMeqWYjjsSJqxVpcBPbDw IvcVXm3Tw9t1+4seLToE01BZO7tCl+du5VB/7pBrPru6Xbo5mi/OFr2tUbc4a2y/Br47b9f1HBUO LWtbuvkMoQ8wpXFXParcJepg9yDADp3bz2C9uFjUsHYP9FNkm3lY/6+167wRsstlvXAd6ls/foFs hy5dXc8OdgiZkrSlgIPcUrIkLFUy5U4YKMEyUGyZcdAI1IfUZawSTheiNMr3FG/thYOTubiAk/Gy FhuyjiJ/92r/6MXVRY0+u1UHW3u+B2e69+L4qGjn1wiIpnu+d973y8M8v7y8nF2yWbs6ywkoLb86 7y/qvWh0eFXZDUPAwbIr4QxsDjCb297msHwOcyp7+PLkzX/GN31ZrtrC9ocgWjKjke+Wrny+B5WM Hzg+WsK9rZ7v1f1q7/ioW9rmBqOuv67d870KVJB1i7+dXwcv+2f+hjILwm0Oa1f1z8q2bleHv+Dw 71kwv/zjH84L+7BpVxe2joNhvWFk7/gH1tRR7k/i+Chfwre/suODwdUYHLSk/kO+4GyCm4gTd/tz /32/KD9do7dt7258/QNs4fGZgZCvL1QmL2ePTQR4d3uFN9srPmeVMkUFicDQjFfYZVoQnjllXVFy UomqCi252sgEhG5nAqgz0qZorFbHlmlgh6ZoqmWHHmmI10NTNOaJsUca2dgUTezQIyVsWkMPfc7I jn0OnjqZdG5sbKgaCu6hzxnZ2NhMbIBbWcQPplnk29bBG1kE32reqe84oWIYCg8S0LfKIi9H70TN +qJwK7Ro5osStNecgffbHp2tF3PblKmXV21dt5cQCi7HkXNXL6t1DY7/BtVt+wk4mOr9euUqCCEw HwJHW659gA4+fwl+vW5sUTvv6dViCAPTuw3bgGnFNTAQlboeoJ+/K70Qw8nO9ILZRm1dYmONtDZz cKUZd1Zk1kmaWWm1loTMFb6dXradBf/MLw/ML/+Pars/8VDoQgQkGohj3j+hAAw49dCvTDybkeFW fek/9wZRj5FBBvStIsN/Q+4f7sGf1k3CP2tfxBT/2vUWVDl/P1GuDqcG/JsKZtlQUPjZpe3c03iH zRO4FbjIvgcFNOBbcMeraDxM97c8rflil78ranb5OzFb/l6oimFuMggUBZSTVGe2mhfZvGSVLKUo Cjv/kr/jn/XkQ/39x9HQjvJRzKj/sIKL4EtCsIgTb/qmXixuVY/+Dxhi+izKBPRQL1Zf8GJ3Vdbr bvHZH17TNhDl6sXfwZf8oS69dor6GrUN/Fi5v9aLFQTBeJTpbS36ztXVU1Ss+9AejBZTwO1i0X+N ynDX9eKTgxXXnY+t9+1g9sdql2tzttu1Bd/oFCXGEheqyErBecZpWWW2nFdZqRRWTlvLCvpF15Y/ XfuBrv1DC+ufvxD27H6X5/7jQ98I6OB4QqqIE9d7vMt/HP6cP/6XitP/CTAAAYp9Cg0KZW5kc3Ry ZWFtDWVuZG9iag03NDggMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDgzL0xlbmd0 aCAxMDI1L04gMTAvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN60Vl1v2zYU/QX7D4T3UPuBEr9EUorj IkgxbA9N0zbYS5YHSqJqd7YkSMyS7NfvkooV1VmCGkWDyNa554ri9Tm8pBQSESRFglIGXwJJIuGb I0UgLCmigkJAEkQTopFM4EYLn5oimnLIFxoxJoESCjEOictl/BtiOv7Q2hpVZtvb+NJ0tnbhNQR9 ij/Zwl0naRIRJBIREXib8iBRHtzEn29z99DCY01728ZX/vasrhu3WsHYZ5fwcQEzUX6s1So+v6bw rL9IRG7i884at2nqd8bZ+buMEQr/lFPNOVWYJG8IebOAGYr4/cv0xft5lZcwRcqwzHmJhRYlNlJb TCqtK0MEL4RexJdIpaGmMFeoUAb08daUl82mdv11qqM0TdVjcYgLAVju4chKHiX0iR0gpdLTAUKy EARgsocjmzCfPLIDnLKQnBDPij0cWUF98sgOcMpCMlMsCpMc4Mhy4pNHNsCbQd1URjSlIgSp9i/g kSYslM2TNGj8df775st6C5dbjJqPofhqvs6bxq0Xhw540V380F0JSSIGph7sJVlA3+evhMoX/NXU Dl7XzzdNaSvcbUpMI4b6dXO7LVFu0W1XZxvrqqw1ndn12f1um9V99k364hWbMpZMbAqlHvgUSpj6 lFpmC1lUWBSlwcKWFdZK5lhIIyklokgUgUSzszD13Q6m/ty0YvjhzufLtzBb9I/tepja6QyKnr1d LfOmfEBA1P3pbO1cm8Xx3d1ddMejpvsSU/BCfL92u+1sSMruK/NNIuCQ2RdruzMxQFwaZ2IYPoZn KpOdXf7x5/6lZ0XX5MZlFJwTsYHvW1uczsC5PrBatqjcdKezretmq2XfmvoJo949bO3prAKZcL/5 1/pxSOtOnL132IC16mxrK3dSNNumy34l4e8kpN/99Yv11svqptuZ7RAM4z1GZqsfEX0Z+6mulnEL l/9NV4tHszLoApJD71XBromQA54Y9uv8s9sUfz+gi8bZp+VyBVUdv1KgSx+uFL9C9n1Y+tD39mHJ ju3DgtLX+vCU9v4ueJmWZY6NTggWRiucWqExK5PKMMJUIbnvw1xNLQ0710Ef5pyF1joUh7geuuUe 7lktQh/eswE+9jQeepkOQd/TuPY9TYQhflpPS5/3tHSiFEuP2DHp0TsmJ6/umBMalBJlnuepUpin BpQqYLPUVjKsc0l1UVJOSvV8x0zIi0qF4pBgbNBigCNLddj19myAh0pB0CslYCFpwsMQP00p9exs o9VEKaKOUEocrRSTryo1oUEpmbPclrbAhBjYOKQscK5UjouyVDYneS7o/51t9Etnm6E4OBl6rPdw PNvAYcAfKh7ZAR6eE/wNKAUAlBpG/CGl/hNgADfT5lgNCmVuZHN0cmVhbQ1lbmRvYmoNMiAwIG9i ag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwNDU+PnN0cmVhbQ0KeJyll29z2jgQxt/z KfZdk5mG4D8Eeu8aIDd0kl4KvpnOtPdC2GtQz7YcSYZwn/5Wsk0MgSO+wCQE0P707O6jtfMEva4D PfOsXsO0cz0bwFJ1evA7/Sw7Tx3HLoDqJUzhNqBFQ/NBEHfKOAeGDgx8F4K0czHNNMoM9dVYsljD 4WN2N7rp+f2rBVevvoMvLCuY3ILbc9zL4FfH8yC471zQN5EIixQzDazQKyFVF+BzkoDky5VWIFGh XGPUvfzQcd06JljRHrtA+lsVi18YatACbkePMBgCyyLQK4TpJLiDQBZKf1Bwj0uWEMlxatKjFGuu uMgUzDBhmmdLA7FR42oDRRFm7c+Lldb5b9fX2uAQuxx13BVyeZ3wEDOFVzyLxc9L4BlgHBs9IrMi IqYRRFxx8mJBAbQXfStiWtBIhrJ/TJAppMzXHDcmnN5EB1JCJjEukmT7EZgya7YQoQolXyBsRSHr 8pkqUAm15KG2SW64XplPclJXsSjdQwkjESH9SnORmU0Bn7VkocYIYinS/eWQUjEqFM/CpKDQOU/z hMecAm7nY7gvywOaOEZvLTUylZqjlQZ+t1EiUzTbtLJlzTaZlCh7yM1HETFMSqLQsGFSskxvaYeK srePQR7XZbxV+TFgi8TIoOTJ7GW9X2znUGnoEEgRFaXmbusn+Hv2M0xD/SpkSoZYo01vSjaq358n 3lTZGpZL7wOUKc9EIpbb89EnWIYzWjHbdMmV5qEyVZlmIZXcOOINrEHF8qyh0rTIatMvUG8QMxjN p7Og7OicTjl1o2x0hHJ/BxjucvS6VRdQXtEs2gj59y4IZtMxPKBSbGnO8XFdTq/BMnmaoH19gcjL 8p3LkWZZyfKJU26McGd7p9rW3vF2unybo9E1ZppBsM3xLRU/yipphncrBE2W7F266nrVuZbS2rP6 pod/jCd3V4Y2D1eYsra6/J2ufl2vR0GDdQujhKlW9XcGjXr1q3rNMBdSt9bmeg1dtl74VNAInmum i5aucPsNlmd9Xx7AOc14Oi2tWIMGy6/6+JWlNBVzFrbpIrGGDVa/1EWD3xw621UQEgQNXAnfH+5f rqP/zbrZ91Y7x1esTztdN7aHAU0wrBrwHlajj5/tbQr/h7W4AnhOg+VZliqStooqlttg+bb2a5LF l6WgOtm3sfwGq7/z/P/T1W+wbhpe/VagbHkl8mqvDo7O58lzuGLZ8m2e9V68OrCe+DOn+yFkaWmO A/RdIjanqQ1WSavn9J7PJs+MbjPOnU6/d8A66bF62J7m+v0DVsNj56NPsgZW03F/HSnbEdZ+vdzq 2n2MV8s7revTAesd9eqb8+j79i7sgQKZpNvGV4/Jc87pVhm+FMkW/I/2f5fXq348mr3cv4g4CTrf 6PkvOGA3IA0KZW5kc3RyZWFtDWVuZG9iag01IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggNTY5Pj5zdHJlYW0NCnicnZVdb9owFIbv8yvOXVtpZfkkcMmAdnSlaiGTJk27cIOhnmIH /NE2/37HISkfaQclVhQpsZ+87zlvnBW4LQ9cO6pryp2vkxgWynHhGs+Fs3K8cgJUl5TDtwQndeyN ZO6s13nQ8SAOfUi4cz4SmkpB9eVAkrmG/WNy1W+7YXT5yFTjGdwQYYgswHc9/yL56wQBJLfOefks bgUtXE6XudTQzzk3gqVEs1zAVZa/ALQOjMi/OHM8b0NcM70NdfhK+DKjB0k7xFpdiJyRSNmMCv1g KLp4R+R/WOEba03zGrxa3mFdUcXqWG+jAUzTJ8oJDOicCVaqOd5ju2J1kTWlqZFMF1iwlWGSctSm jme13TeP3dLfr/EtDNiCaZLBlC0E0UZSBUTMYChSWSw/1rrD8pE1pkqRBYVEEqHKdh6vK9xi2ZTd m8eMpfCDFtiCuSRKS5NabYeZ7Wirj90qXz2jn7BUdRSO1rXPKn2aTLPL7/nSOk2p7QRVev8VTVZ7 y6PNaj8XCqvEDF8X/EPPqsmKt1iRrZdkzyS1iRcpfvxr4LRQmnL4qShcG4xxxsR7rE7F8tzWJl9W HC6RpZmjExYHNQuLPurd9U7k7LKw6FPDud2XPrF+h1Xny8NwTeicSop1atbiKNYmE14ZrrtccrT3 TD9P3mWhT2z8qbS4zpcNYi7PFPRmMwzPKS5jm68g8sutepxLRiRmonEMX5fMxvPGZAWEX8q/RnPW 73u7KwR/EDlMnAcc/wCTkIuODQplbmRzdHJlYW0NZW5kb2JqDTggMCBvYmoNPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAxNTE0Pj5zdHJlYW0NCnicbVfRcts2EHzXV+Ct9gylSI7T5LWJnVaZ ZOLammln4jxA4IlETAI0AMpRvr57AEhRdu2xJEvA4m5vbw96FMvFSiz5Nz+rdvbq9q2o/Gwp/sRf NXucreICkZ9UK95vsOgdv7HZzdK+lXi3Em8vL8SmnZ2tTSBnKMyvnNwF8fzn9uOH35eXb+Zb7V98 Jj5J00t3EBfL1cX55sfs9Wux+Tw7Wy2EAKyzZa+Ctub8t9nFRfwEezY1kEqr+pZMEK3dkxe3JJt5 0C2JGM0c4TxZ9yCuaEfGk7g/u11f3Z+Lbzma70BcrQbEYMVf2gfrtBI+yNB7Ib3QQXTO7nUJ/FYb 60TflTKQR3BfXSWN/iU5OA8sRnH02GtHoqamEztnW2FDTU500gUNDJwCLBP07iC0UfG1LwAddAXY jNLKRittOQSkvtfhIIJ0FQVtKgE87YSybdfH/x152ztFgJGm5BMqqU1G0sbrqg54xvudDXy0bIDh SAbPz7avasYUvpaO8ewOq3fWtTGxRQaKhCtrXalN/AAxMzAApW4EE82bn3SohRSe3F4rGrhz4P7u 5v48YyGUnW5QIiFDkOpBBIhmp1XxHObuhtdygs2ehMzblTU7XfUuhaG970n0BhlyctbIpjkIJXvP QAhg21ALbrArMJt4U47FasGI8BoPOCfIB4KmngxO3towF1lAhUDZB3aeZFD1vIFSPJjKQA+Gdx2r tr4RsiwRt0fJNePhdG8hgb5dMJc4j1zL+emoiS2N9cIHnaNAJctPGlT+0BEX5QWniOrD3fp2g+pJ 9IA8TGH2TFnJh0P0rJYWFKmk1cVJK62zDEUN+TScY97toyxKxBL7rwBfHedgqmIQcUYsTjqJVZgF zQVC6NKMYkeNa4otgdbaElNNRlfmtKpDGlzbQqw3k+0Ra+dkjIm5O6qtoT01QlaOKNoCRPf5j/vz IqP5gw/Uxs5BY2oPZG+VjnohU2lD5EBZB6XXUSZRnLH6EjQYrJxnKLubD4fen13ZO7jKsJqCWqDG /9RkpnlzoROVVBZM7KhB31l2J64fFjd9yYpsOwSFJolxZOILYeyR86jYESZZAHPNNZuwFR2JfEhM QXDo7NRRPaO8OhZqoCmmO9nVWBxIySLiKWx9ZjyrtbC7UnP/9k1A40HzY/mSNCHCp1qreoKRVZH7 Hwt7E5uoyA6ajS4DyS2YYBO0bBUqBXPqHZATsXaggAM82gcYXDv1tww1DAWmgVE6673O8DEm0N67 KNAkMT9aQ9fImPx6kGfMlfWMRJRi6RLCV/BIP+TH9o2c4QRcsi0OJ6zmg5OhHzmHmDC7BpFGJ5+w NVgl8zIsAe9yD/OVcLiheJM9IJWkP0xHzmnjH+elPpmX5bN5afsAHSJTyd6TU0pbTvp+2H9iNqJF t9s4lnZSMc/M0uCm+rn35DQwYiVrpkkHVVxZLKef8F1+MTElFkS0pJT2IL1Tf3ruSS0pnKh966MQ ZDSFBqBjRBln9MShYVB/NtTxUsDug9LTJM9j/kc7HkzgOFjhFAaVy0JHahxRRWn85uV2+wNpDpyQ V053MX5OZ9yRIFGu9der64/5gvNm+Xb5HWswFKHvhv3FPfRdxmqwsZcV1/jfL5+xZbhK+Zwfzyse Mj6lh+4o0CqYb4fIZYbpnN5LdUg+7aH9RvLgSs50ktJ49UB3eg6JRTSy83+kPB93npvATq9c8RDb Ta9fOLnlVpUdtiE61lpJSvu4Hk0a7y9VjhDXqJiTppz2sVxswz6dnfayTOKIKlMekZGkzfjySIrs AY01arw/Ta+tlLSd53ILY0AZPDcrTB6+jJ1pbMM9UBrxDQ+rBUo5VOik5dIlh3mItY+6AC6yeQ8f s01jn9IC4Le2pKY49hNkxNeswYGS5fkOgkvZvuhNDjJOJvQVlTjjS5S8Zyc6MmcdZpVMSWQhnBpC ti+2JVPGLkGnQ7/ZboF0eRnz+4K7OK7Nh5ffGK5/drhke/Gph5wui/jN4eWqbzes8Eu+5l9vZn/j 9z898lEKDQplbmRzdHJlYW0NZW5kb2JqDTExIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMTM1MD4+c3RyZWFtDQp4nG1WwXLbNhC96ytwa9yRVcuJk0xvre10lEkmacJDZ5IeYHAp oiYBBgAlM1/ftwBIirbl8UiigN23+95b4Ie42GzFBf/ld9WufvvyRuz96kL8hf/96sdqGxeI/KZa 8WeBRW/5QVGt0r6teLsVb15diqJdvdiZQM5QOL9xsgri8evLu+vXF6+uzu+0f/KbeC9NL90gLi+2 l2fFf6uXL0XxYfUCvxiiUgQr7kgEeU9GqMZ68oGfhZqEt71TJLQR1pXk+HEtm4BvotVB72Wgs19W 2+0Yj/dQVZEKXtgqftVG6ZJM3CNDkOoeb4hiyg1g724EEGsUZ8oIBeE4UOfsAduEFC2F2kaQyrZt b7RC0hjZUUMHicjaVNa1MmhrUEk4EpkcBlu6Ho0TnlTvdBhmOI58Z41HKJKtF99fXH/dfSn89zNx rHVDCKTN/iQMwt/h8VGHGqgO0mlCOBRJD9oHrBUoSXTW+7iu6kPvSJQU0AwAy5GCk2pcOyGQHcqV qiaPluwyQC9aOTAx9PC4Oaih6dGc3UndBana2MbuB5SyK1DGWKlfoyICFm42GQl0nvs315a7etI+ JosrBfGZCecFkgljzfnUy10xA0qpNnhweTmq4eu4MHbG6YNUA/IZz/FiPi8kgKGJtd7X/JOCyIVH vKWuOoseBC2bZgCVCBD0gRa852Z10ntuVe1sj4hcckveyz1FbBxrfsZEsOyBomQhYRVj+efjh0kv 6xH3OtPbaDVMVc/pPbEMoyw5vgeZrQSbxeIB5FBpQ/7Z1vuOlK60YsXLUgbJmvd911kXYuDlcgDd fbq5fZdjlVb1bZQN00QPCg6LBeLbKLpTwI720pXp6Ql5ywZR4oeMkp3vGxivjOER0HjGxdLSqmYP p9JK7oLMgTx10rFbR3DiW5pTr3lO/ZvbI3sUB3JTXes4DPap92h5DsWLrNM/E/iKJLvLR6jMC79P oNCaCpZn5L0/9Q0spunAQ8WQ4gIxEzFCqOFmjowvJXxtLXdJRoNH71ugdSINC67b2CB8cFoFaBOc sQ9RS8PGgdXazULIRXQiQzPoCETqeZ2isneyWaOG3ocktQYENY/dEmoZcjEtHBOwGfjRWMmW3Usz dcjZVvgaU2rJe5652dT+GSVzbtvN6YSSPBZSK++GRRoP+q1ogXkcb2CSxxlagY/aCXs0yTSakjKf x/TpNOhYIMJCVaDHdnOMNEpSx3JI9gbQjQdOri9YZZuReGyKZlmSW9Tgb7RddtWdtw1mth+lesUy vdGsKNiAM3Jnpx8X5DKtvm9bVPiTmwXkx98XGW1OOhkCn9n6AQhhRx+tep9PoCmJOEq/SLSkjIVz 1wco8Sh0DIkUAW5Rm8fJb0uNCeGoanAqJbMGxtN3ZTT3AXM+D5doLRSE+ccFNcMTBC2riNLQyfeF BSqQ55XTSUvZ7KePMjl41fLABy60MwLh475B2mo4pTdyOBk+HYwsgTkSTggRho7i9WOabHFLNB3M 2mhcXVIK3KeO1t1P3p/jzEMx4W4wTXs+H2rpnyB1EKPisVKBVib0BE+88SQA2njcNUomfEaWjuZ4 A0CnETEnxKWlncOMQMfDeIbhqGsk3JCGE/eqtQi4J0MQQAyDVsyRPLmDVjRF2vAxDdpBFwavs6gE 0hkeMenTJeZZyhy1kAH6G28Vw9TnecaOJoVimqgXeXIjYmEm446mzR0Yc47XnaWT8PpViO3mJVb/ ka6VReR9VMfH8YhfY9/VVdz3EaaQDheSJ6/bh07zPHnfY3S9Wser8tNV3z6zBKLrb4vV3/j7H3+f 4asNCmVuZHN0cmVhbQ1lbmRvYmoNMTQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAxMTIzPj5zdHJlYW0NCnicjVZNc+I4EL3zK7pyycyWk8Xkc/bGBmaWKQgZ4lTt1lQOQm5AG9vy SDKEf7/dkm2+cthQxCpZet393muJX9C9jKHLn/op887vsztY2k4XvtF32fnVif0CqB8yhz8TWnTP E8miE/bFcB/D3XUPkrzzaVQ4NAW6i4ERCwfHf7OvD7fd65uLubIn7+C7KCphttDrxr3Pyb+dqytI xp1P4eVvAL1LAhgNgGMsjXBKF7BRbgWP6DbavMGT0WuVooEE5arQmV4qtNHn806vd4h0dRkTVotT LCExQiL0y9JoIVe0C0SR0s79PRz/uSrRWHSgF/Ak5BuNRsVCmzykQ6MAZS/rzRqgX4Au29cCrBMG nC45wS2shIU5YgGqkFmVYkoDCk7b43gva7WLIjKwKD2g05Aj5SArY7BwUFkEKeifwV+VMpjTpKVc d5W4labXm5WGMrBFS0tteJVPgWYIZy/a5QF/VE6yQrDEUS5gTVx4FagG2hviYXp5sIgLrMpUOLQU XbjTynzdMJoOhl/hJ1nkpnvXfQUs1pjpMhDCuq+VIACEmU/42aPvCpOZsBakLpxQRdjkF48GTzpT chsWRG0qrEUoHfeERkOGEF59+oJIU1VTjkWVY+26j7EZcod0PhabIdMoPSvnREp/h+bw3e2kr6VI WU+CMmqx3QGluFCF38dKtnnQ6rXIqroSq3ME4ZxR88oF9x2I9q1SqSjI4hxT5RwwhMPCVgaZN6us 89rnZeZTFiEmU0G+OpaNUvl7Mqb90mzLxoyNpwhu4Z2kRKbcFubkyZQdRtzvaZYL80YWisCWKNVC SZFlW0+t0lT2HwYtVRSs3hbXsO/9ssPiNP3UBXsleM/WTtztzcUWRGY18U7Jog1mP8YicYgXjlrj RNQxSDRx3GVDpccRZZmpDwjvZxlTxBuK0EprDKovjM79/DNS2zI7D0x+WpvL8jwPjglv3ZI32gko cNMsj3Z4s73m/7B9teFTkurerJRcNV6G0FJAZ3NNTWijOgDccArHWfmM5EoUy5ATVVojtkFasfaU OeXr//QGvpeZqBG501m9cE4fnSh0CQkZ2JzT5cA4bEZHSjUZ4btgo+8TFPtr4bGVy1uqOQnXWPuj oSOOoBfBVTgr4l7r/RVm5aLKyPPybWl0VaT7x+lJvvJA/PqKs1vqxZx0EMYpqcpwSfHF4NfToaWq HIRpcpoNf7yMZsMBk0SxqYnaLm7uCgvXEdxEcBvBXQT3EXyJ6Bqvs49pYw1F0q9DVxCJdPwaMVe+ hymwpLv9kDC+ExM0ufLXbXNqscfecAt0K6cWziYvz8lZFJ7wOPXjJmMeP//VH4/bQVhxwBG9mL6M 67U82qE8TCeT4eMgAE36/5yFis6mT8lo+tgfnwW9la1TS7WsPC2C29mfA75SKpvtTq5L0Uo6LYL3 +TrqxfGXV676/t4nNNFGkS7b018ww/eS+s7C94oUILr5l8zpqp9PYolw+0qIw6Tzgz7/AeNW6lAN CmVuZHN0cmVhbQ1lbmRvYmoNMTcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAx NDc5Pj5zdHJlYW0NCnicbVfbcts2EH3XV+At9ozsWo7bZNqnNE5aZ5pJGuut7gNEguTGIMAAoBT1 63sWF1KXyJNxRC7O3s7Zhb+Jm+uVuOGf/LvqFz99eSVav7gRf+Bfu/i2WEUDkX9Vvfh9DaPX/GDd LNK5lXi9Eq/ubsW6X1w8mKCcUeHq3skmiNPPl/dvf7m5+/lqQ/7snfggzSjdXtzerG4v118XL1+K 9V+Li9trId520skK0OQDVV7YRjyYimplgr98sbi9jZbAWHdKtFZqtgg4QqYVUnhVjY7CXlA+JHq5 FxslghXxOzV7EXDU29FVCoirVUG0jq0aMjWABks4bE00Rpo7656F9KLS1kc0fm4dtWRiBB1jMcrk GMaD9Z42WiGvN+YspFrBl6rZUOK7odZkjMqahtrRyUCIgLwf1VI8rCeEpZAM13Cl2ALhcOpuS5US Wm2VzkCydUr17PPp4vGvN0+XS+H3PqgeLvrB2Z48kKVAdj3nv3b2a4JWEXnJD2UG8yixVlf8qB91 oAFfUhmRiiGpr2xzVaKQIcjqGYmX7mWQ0qoKblCD0aMAP+7N04V/uuTawjKhCa61q5UrWFZ0UocY EAVqZVDx/Ghq5ckBeaM6uSW8T72trHNIDIilWcktwTRWGfF+ebgXvfJetsqXKFGsfjRUwQFjhp1S RvDJQMrPwTg1WBfDIbNVPkckDbLaD4pTmcnBJNPa7rxouMSx2gdQzFj5DC+7TpmDomSuzUB8OJM1 UtNlbpaepVMQ4bOxOy4fSuYBD9Q5+eskp2F0A7P7UFHmlNaAiqn2qk7dqlVATUsFl7Ely9OeZBTV MLH8aRbw/1GFztYRW1ZMTk2+gxHcsVxgqce6wETvlNTBBPmxYBrSPEeQBYLBK3WliWPCgzkiJNo0 VB3rOlUtJoEu5AOisz7Wu0wD2zQaAr7OSG+lUxAGbKT2Bx0EpjJ+dFwHGRJ+1KBnmli95dKZg5CY gTPjmBeCoY0F8iYKhtkDWPxfQMQDmi6N1HtPDJlRuC2uJ8PRU1MUVNIlv2SnDYi3PH2HIJWsOvH4 uUwRbXMJBhm6VHEmSEz9YCJnzpzN4ElHUtTELjA9UBz/zCNlmhXKeQz0o4mMHDHAEI9Wpg1dZIfd +CoVU5HLHA77OGhiiJVMDJ6m1mk0y2gW3Dhpqqe2CxzfwTgInbNj280CUN95IyE9CFtumJ2wAu+M mmYw45ZcXviyQpq8JgpP/rQ7TGi3PDKPJOcOZ8QCN4/pukzu5mAkx8ag/2TrqCnqAdkEngJRXmA7 NuQMEmUJT5AYRtzhnEjYU9a8TTDbGPQwBJaAF35AU8DCytkjkCwM9OITHsJT1jSXIHatKKnUfRY2 6OBaxfUtuiyC21Ho0iHZl3qJBgFNSyjDeeiBHWwsDmylprrQF2rxg7UN1zB5lnXtUADl4+TjkcYT uDrdSnPqBQoxVx1EH0G1ktu0cU5ojYS1Ze3mfCPZEgsyEDcx9r9miXqoKVjH0byZtMDq7uPyUFVn 6NuIDHcdQZgc5Rb3p4xVFhIuLrSlesT44T6DZDzvW2noP6TTorND7MUkt5h8bPhUqTRFskRmv/nG EjHiuOKVDXdVDPuYJUdLzOM6hwNbkuLh0/2797FuGHCYzqOLJJG4IiVhlU6XjcOA23R7gYO0Zlhp lRzkhnRcvkjh8WzcLDOrZjbd39vHnDfe5i7PTYtDXTq9Z6f5zhYVyEMOppUcp7zy6jIy8BTK36bb zqPtp4cTPguJ5kVargZxv6aYZhngXGP5YoC3vx6NVyvON39SQ2IWFpz/sTB+K6GfIHBX+bbocNeB bcWzAoMW9E5r84AAfIXidh2NZ3z6eW23EgulDBa+IRRZcsvBGKU1Ggh25p0VCn/xScrd8X6Uw4BW +MwfrVr0uY/3qARdPPoRSpB8Zbq7iwF9RBkkUM//3Hj3fcBt0IsPIzp8t4x/dpxb/fOZy/DqXyC+ Wy/+xs//Wm5lzw0KZW5kc3RyZWFtDWVuZG9iag0yMCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDEyNTA+PnN0cmVhbQ0KeJyFVk1z2zYUvOtXvPGl9ozsWrbTeKan1nYaZZpUtdVD p+4BBEEJNQgw+JDC/PruA0mJlj3jeOIPAVzs27dvwa90fjajc/7qf8p68uP9e1qFyTn9hv+rydfJ LG+g/oes6dclNl3zB8tq0j03o+sZvb+6oGU9OZ7bqLxV8fTWiyrS4b/7Dzc/nV+9Oy10eLFGn4RN wrd0cT67OFn+N7m8pOXvk+Nu0aVYuGRL2qqCggpBOxuo8q6mFJSn0Iao6vDzyQ+Ti4vhOUcU14pE jEI+US1a0laaVCraCK9dChTbRgVyFUXwrbSkWgkbKTqSwE+1At5sNuKBszY4zqvgkpcqTCkkuSYR SNDD31+oMs6Vw4lbHdcgjqWgV1YDH+BA7LFAxisRFH6hQthyq8u4phS10d9FRIGvVsOUx4ylS6Yc FWZ0SaUKUduMkRlrZnpYynatwRyUrItUKCqMk0+qBFcrFR/VkvCKoLWyUQuzQ4I8+yKKhP3Ysxfi 9stDLxNEQfGWHhbkPH1cLhcQ7msCuUAMyjoLu8dyfiVsXzs3wCoZQQi7uPDBW2/1uBMw97jVdrXv cYMdCkd3WvHS8mbxQpa/bhdTmt98xneQdgD3NF9Q41100pk3LQYlsy2Pvru60CocMYwRfqXoqHAR BYSjaS8+HrWH57NCGrqLstQsRBZeeLnOwhOaJCJWWZ/onTFcR+9KiA/EvZ7RJ1jF6xUMxo7ZEX1T wsAnALKlUAtjyKa6wAEjEXONwraH9Bvho5YJBVM3IlOAY9Jq8cRMBfsW9kI6AI+PrYSMZFGhaUej UTcOM14Y9SpVbUvMUnQ+95W1qNGfWoN234JS83Akkz1WqggnnfXw806Jjt3jcXg8ySCWfaFLtuV+ JvhJX8PgZVcwjIC+YPrDs7q1rZyvO9/qOHAYSsgGzlXn+e3ntsDkl+QG+8u1wBacpjG6Mgz92nEa pouBsqu7xRwgZY/xaoiw/ca5MTQwKIXYafOaNBpnnEGbgU7+lLNp9ATHGYXGuYpTIss3qMFBiMIR 6yycGEC83nBwRBGeWIRcia7akf699J33zp71ev7H7d2HKXuM1LeobBf5gNktlHQ/v+VusdopdFGB lgltulwZd6jTcfqm0I/HUBm1qI0zGwV3TEdDtdu1xtPOtx0L2K9Olh2ZKR4ighRMjoZETO5IX75E TMo9YhSvGofZQW8PAFiW/jK8RI9uxqeh8rjlTt48zO+XIQM9dDlNC+82APDhmax33xrFydJ7SL6J tgjc1/01sD0MLdTROJsDlQMdzpLJ69ieemUEB/he/C72eD6kx3Rg7uPW+adeFCFxuwTMjbaw28Cl v3bYx/12DuOuMsjxC1+9oMCz7qqRvAmRayXf+bmTTAOfa85/dP90gB2wdrR3dIfJHCuUzYB0rlPI AQHvqapCuuiN6l9C+JzG5HEf7sl9+/vGggA8CDwUsGROz9vQOKPBHBXXCq8Qw3yHdX/X54LAwUTd IF/4pSXb7jkKN2Pj8DrA7x92ZQbvZX15e4VBSV6Bw13NMwMeziraoj1dZNlQQZhxuomCX2heDsS0 T4ku6JAGKkrgfnRbhWsEf+YDuPF9snolle66Aqirq2ymz7iscH+0L18O4VpcioE+JdPS1TS/JL7c 9c9C4Jq9/heId8vJn/j6H/XhgioNCmVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNPDwvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCAxNDUzPj5zdHJlYW0NCnicdVfbchNHEH3XV/QbUGWDbRwgj4RL yhQUiaOHVAEPo9lZ7cS7M8tcpIivz+m5rHYlYpeRLe30nD59+nTzna6eXtMVf5dXOaye3b+krV9d 0e/42a6+r67TA1Re5EC/rfHQK35j3a7yuWt6dU0vb29oPawe35mgnFHh8q0TbaDTr/v3b15c3f5y udH+7DP6IEwU7kA3V9c3T9b/rJ4/p/XH1WN8IijoQfUHaoXvtDVkHW0UCRlUQ3HEG3sdOgqdIi8G RdFtlZEHEh5Hx84a9eTR6vq6hpOi7zmExQFH0g5DNFqKwJEHJTthtB+o1w+K7u/ePsXZm5t69jUF PMGP9+RtH9OhYCk4IRX/27ZaApmzni/32mx7oFJup/G5dQsgIGpv3QONzu50AyyDOJA2so+Nos4O auvsPmXLIJWTmm89+KAGT20KxmH2nZYdQwV678UWd9IQfQAMPmcbEVQiR5sxBnLqe9RODcoE/5Ro 3akSBzcDhQkEBpqeo+S7KHrwzHl281TO4D/yJdBGyIcNWKfNIZ1589fd/ZpZkta6RpuKJ5NWyErB E10lSg1f8DKdgwqdbTgSUlNjuOC7JZK+IEDGkz0IPBKhKiAuEIdP6VywLvYKGsArPtkLHZhNHPfQ ksdNrbPD7ASeKoGkNUGbmOHzRQxOgeqCI0luxB+j08gS9N4xbZC7l8oIp+1FiaQEalbJnAlAm4Af Tzp44uIXBFKMYgMl2XZCMskWhdppkeAwC4gA4eB2n9sCtAkDMrjg5EPWOZe0ROLUB2t0sI5DcQg8 3x+8Znm8NiR6bmqc26n0cEXrqUehcaYE8pHFr/kaUGmjAyNJ0uhV8NwJnBcoa0Tde2bFNTQKFw4F p2QGlxU7Smsmhxp637GiYt/wBUmjODUqB4ypev8r6zYaySxk+aM4UxQxfQam8ReKxmBLJOu28IYf mUGLmzL5yWayxtvUqxGHtMpiYJR9ahdOUpsSSrCUvHVBR8YqQiUqVZnzyJlXBPqHao6pLz3pzRSp ZsKxNVSZcoCJxJF/PVUbuiahxuuJMWVnbFWTUkydD4Ri65RKLcNVQ6VHbmRtpmZYWGlJFJcFK21f amxylOYy2fZoe80+bZoTG66nqkSF1L0Ome7sQjK6ZCAGPetSpnef3757/4xx/P3pIzVWxmxxJcZ6 epaLNDcJ4vYcldStVtw+9CXPqRc8p74tuf4MV9tayBcXcgyd+XBqxwpjaEZNQhx0KKrmNxKpP/N/ /4jY4kaGC0Vy2FKiNEIC6BFolZm5T0NqMiaYSxIOACyZBM7zBtCGe0TU4VWRlXqV5gYRC5WCNbxl lN52m2wVFX+eIrmja5jU15wR7gAhYmPR/UXjqVd1McafztPaJT7JGI8uFHCeECtoxBTRG2wJaazw DKpe0qEDtnDbAYNfzfyr4D6ZnBO5tSNLmN5uE0x2wA7umH6P4dK2lxu+vxoUCFXGJ3ly1xyNaFkY Fl1WMR+OBpuDSgtNGZrs1Oz3RVQpdgkUDc8KEQJyrNzv7dzm86CERSY7ON0DWKLVaHFBL7AvzW09 2GkQwQ8xKGeRMyA9Tf80eSeiiwguc/ntmDI9uutO6L4a3Fk12Ckr1UisIOXu4a2wiwAxM/+Z1Z/J oaY2FvuqhW6185Wb0jG+LEaNBoiIis5ZmAbIzvY7tcx7Fp1L1bZpK4kI7eDVpRHTsiCMVEeyRdl6 pv3zmGLdP1Kkc0Otu8aJqpeoeBHAjLUBZlaOpYEOpsNxo1t62voosNyabJDnTuK709kyU/9yfKSq hixn7iajek9fHzdY42Q4CYuCPfivT/gQlnZ3GMO0mUxHG9Xw49lYy+Z4NP65ly8W2p9cVDoCYpzA 4Iq8DQDhTrsQlz3+9Qmi3d6m3D6huEnZZ1/v/h3TjvohwoBuL9J/Ys6f+vIHMNKv3xDx3Xr1J77/ A0l6ieUNCmVuZHN0cmVhbQ1lbmRvYmoNMjYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCAxNDY5Pj5zdHJlYW0NCnicdVdNc9s2FLzrV+DWeEZWLMdtcnWUj1EmmUll3eoeQPCJRA0C CgBKUX999wEgJdppPBlZBLHvY/ct4B/iZrEUN/xTPlU3e715K5owuxGf8b+Z/Zgt0wuifKhOvN/i pXf8YLub5X1L8W4p3t7dim03e7W2kbyleP3By10Uz/9tPq3+uLn7/brS4cWa+CJtL/1J3N4sb6+2 /8zevBHbr7NXWKkoHoms2BP5II6tE608kJCNJ6qv+72zog/4bmshK/5t74xWmoKIrXd90wp59dts uRzwlLPB+aj7biHEavwSRKebNiKcMNo+UT1uT3gn7Ov20uuAHcBjpBSyrnXUzkqTM+rIRkR2Yud8 J6Qw0jfkxZEq4bzQaJCMGumjTUfnnwqS25XyYisjInlPRkZKQLElEdHQnVZiL2MbhDxIbWRlSLgD sPFCgbkMthtCBA5cyYCK0CpPDbINKXfjGq2QeIM692FRQNCSKFUU2nIJkoubi/V3rtRTCEgK2Jv1 BxFOIVIX5gnLIQtfEC52iq4PqafKOV9ri6LqkdFKc5EeGeTiq1OiakpSQu/kKZFMP3WI2jaillFy TYgeegWKQ+oTCuHlgR9fccNB8xZrgVTvdTzNGXynm96X2jhAelSTVcCQKUJQLcgMZ4IYn8vGwyAb fiVnPVRoqXFR5wJPZS3lzusdURxKIx+ltok7aQwY+dFrX4RT4ux6Y1hx1pJiwKlaHsdJm4uGYSxv nguqe1VqoqgWj1ejhBmTM+KskdNrKOJlp6+zSEYZsyBub4exmZZOAf03OrTYcNSxFcrooQCJWfXu gHb6RFxFk/m76BO6IDkByBuCA4cYsJggxEGanq6hObwWyB80mHF+KGggeFwydKCLCUSLHr7eP16B +k+9Z2mKWgfVh8CahP9UdHK2vhidoNyecvuxXDvVJ5xBfOC3cx4us0dpe8/pg6AWyybVUVCGHiPT /8ksTLv63TsF2jBYbBgAUqzCmJEZyRI7keMELnvOeR3JmElnn6w72jRFFtVRNpOSvbYHZw6552MU hIV9BsoTMtRwTim0rjcIZoJLNLFs1Ut7KKmzJKUpKBTgLHn1DDhnjjlt/uRN9DNvwveAyZY8f9mN 0lgPNGOQxOphvdnOxerjZguLKmbC8CviyGCcl16vVo9Xc/HZuAqo63OOBeo+BMw9h1lhDDU8NYM8 vvq8vk9bZZaF+PR+zTQmXyvpnZ3lPHV4p5FW/5th0B/eq1wPTZ+GaUbvwZ1u0jsX/L9ZLNH5NMvX ZcJZEHlyeN6+DfNWwvKzMlrcEvwanXIm5ZwrzZyTDYm/xAl07SWsFtY3UcvgwgeytfOZj5RttzdJ qrmkPNCjZLpnKXWkoFUduuKyef2sHTY+zELyuqnVsQV6rjS6gsVDRgCzDfyvWPqJzz7shvl3vYka uY0H2+JZR87TvPOyo9RPGChnBDK4PpzhXW8H0ocOjAflxZAUoEzfs6Gc40oAQfABzM5FlVRPWTid HmhOfRu8pZw8IxISfygtKf0S8bRHBahCeV3lMX2A9zPS3eJ2PNDooiC+ZEjFxMKNUqajayQL/VXY 85hPA+MV09cZZUN7HAg488u2P3vyODW3XOoGDELL80GQ+et9H1vnyxDM8TSAqvMorS/1n0RAYVAS Tf1wO8YfE4Qd93wuHVtQdSlFHYox7rTJlxvJepiIPN9ReJAxwk7lY2e4PMwZk1uKRpZTQuaWA7po tR6uRfd22pAX+SGXobRLb+S0BmfF6aZVj1vaJSX3k87+umzuYnC9VzS9jwz3Qjb5dCuuWM8wdbdD 5uwt5UaZqiWJm9L0KjEe1MW54LzRk+zSTTNdtj30hgsr+80kz6OGjWvYKY2HcRoGtNBjOhLaYGpo TU2wok5bmobJRZVyAHR3l5j7BjWhWaeXfyd8/LnXbG1fepy/d/P098KLl/76zh1c3vwNxI/b2Z/4 +Q9UFVAKDQplbmRzdHJlYW0NZW5kb2JqDTI5IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMTM5Nz4+c3RyZWFtDQp4nHVWXVcbNxB996/QW8I5kGIgTdo8UaA9zmk41LhPSR5k7dhW 2ZU2+oC4v75XI8netVNzOAZ79urOzJ07+ibO30zFefop76qb/DR/J9Z+ci7+wO968m0y5QBR3lQn flsg6H36YLGa5Oem4v1UvLu6EItu8npmAjlD4ezWyVUQh6/57zc/n1+9PVtqf/Sd+ChNlG4rLs6n FyeLfyaXl2Lx5+Q1vgkAW2n1RojFhsScvkXy4TqGjXX6Xxm0NUKaBl/42AbRkfdyTV5IRyJ6akSw J68m02mFU7brotFKBhIBgD7IED1DuAxhV0KKhZOKymHCOjEzz/hLr/lAACYol78uzEYR9bvKR1jT boU2z7ZFVD546wN1vmBJpagP2qzFfHY7IMnptRafp2d6GTZIKD9vo1OU2OK/glJqxdkYGzgORUhB 6MuLdU8pRO0O/xH1cXKipWdyXNEEttQtCudki+9bDvcb3ftUIQnWxlsXdOxe1bR0kgQ+N6Q4OJHv NB9F6SEfbC96Z5ctdYBTuwxUa8E7p1qwcsKgPLcxgI+ysW1EQzih0yZ3cyWRF1jXQknxZOyLqcWa PdRyNw267cGPH1MyF0maH7cRh17vWunJhAKzRFGJDPeslFSsuBaH+vk/5CxPTi+VYtfAMOxx2Dgb 1xvALq1ryCWZ1H4mHO1ye3ZFB4cuH0MmduhXwCAsqbUvvyLm4qIOwxSJ3RnGHj6EwpGR6AmTqCfJ BmXWHhSDdbmT8omEHI1XejWktGfhLtEpxtBdD2VIkwULQUDqURdVsyTfjIhdFGVqo3SDevMIPqCt 6onCiKshanjK0UQHAyknHpHKugeMHrZhfOolTr0BN6nGZ+QZw8N6rXf/Hc1ppnx0sPoBYJbukpL0 nzXzLy1OyDA3a2xnY52i9HpkeYn72C3JiS+vrx/vv5yIzzDV6S+X519TZvelUbPBSTeUJhDx97Ob LycDvA08oqURqxbNBZUyE3Nap2ZvWdDV2sv5aeAHWBbxg5hGBrnERPlxda9QoEqR5/NAchtqkxfA b9BvabYCFWFHbK3t/XFDBxWrEl0524meXE8hSn5WFnUJMUu2vh/UAX1HinSy5YOx5c5B8oDRASnD R4aUc50GOCmp072iRRcTCCVvSYZcRZPPF37DIliT4flEyABKtuSSN5QDR0naPj3AborltUpqhF3k RGu5BlD0HW08aMVbNjQoF4kKHjC90mhh9i4PFEhDBuj2iVWNjT2IysyPGrLcLVxUzvF+KJXIZoHd qvu2mhp7rxS3t/axnjSi+Levu+1gG+7saFBSjFGwyra55CCyYn3u+UFWZ7JP00bNqZDl9gCyfXQ9 No3nBZ1UgkHNqw6e2qPGGitPB/jKqtSUpNqg1dhzSvdZZOm/La+bBoPAa2sdUbAWawlNwkiADwse Bo53WaDWrV1ilaYN3dtWq62A7OC72m8OLKGn7Ppy7Yg6dCLvmcSlrqLdZk6xvHJSbHMWezacupoH zIrHlhLsM/QxZZgI6dQm7p58trqBocd9W7KOP2R+NdpvZNuiAwWqwTS3ECzMbju6ISSQcRGTvILe scq1KTClOp3cpuY21JPJWyFbVWM7zCmGtMwGeEQEuA+5SN9lB92d1tUv1lCBM6mK+5nK95cOu1Jp 1LB+zqWQWRDV3wrOC4/vvuONXq3wJ0AHvWdN5KsGr0HTaPh93CWGgiiApqQfnH6WSFJ7D/fZKTmV DHAuG3MfoQ5V6XnmV/MaszxGTDfiRnsVvd+7/COp6KDvAjLPt4msMJ8vbaflAvqiId1s9W4YxvZT 6ALm6oqH7hMGjMfi6HX3vecLy8eIK/HVKV/5j4I+P6Sr1nT6FYh3i8lf+PkPx64rVg0KZW5kc3Ry ZWFtDWVuZG9iag0zMiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzMjI+PnN0 cmVhbQ0KeJx1Vl1v20YQfNev2LfYgK1aStIE7VNiJ4WDFHFtAX2oi+JInqiryTvmPqSoyI/v7PJI SrZDw5At3s3Nzs7u3le6mC/ogn/yZ9nOfrp9Q3WYXdBv+K1nX2cLWUD5o2zp/QqL3vIXq/Ws37eg twt682pJq3Z2cm2j9lbH8yuv1pEeP7cfL3++ePX6vDDhyTv6pGxSfk/Li8XydPXv7OVLWn2eneCN qr3WFaXOWSr21CkfTWk6FY2tSdtootFhfvpitlwOW26vr8jrr0mHGKhNIVKhqdE1lrYqajK2NBW2 BlK2IusipYAj1s5Tl3zngg7AWywGvJDKDalAQRUuqloTFpbaBufDxnRzoneW9DfVdg1erfPyApj8 X9xogAnMPkTd8ulNqjQOH0hSdORB7LwxrYmHTCOUXJuSF3Reb8E5YxkLtlhioMrauxYRsh5hozwi KXTcaW05LB8IS0CChvRkhPsTj6O9KUVIVZY6BD7H2cZYTVvsBHjgEDrV4b/7U477YFMGyluFhaLS tZ1GUpx/EcDZVamMYIutlfaMP4qoCBLhqPAoeytw5QxmucLGpYZDArRdmzp5VUBnIGmDsLyIaLyW YHFSlyIOO8qfStGxVqVqmj3DgH0SccF8zifCkmutYgKMtozP2YFWO+cfcpitsmAtIagQRCwQVVtl GiEEYVzyAARV5EYP54i6dkzbFvqZuk8c5BQOoHAtRqFLDhHWLDUbgrfen0DELb6rWMXrL1cfPt6f DmiBGrc7I3imVXsxcsHuFqi8jdNQsMcMpz+bbZJgNOcPma2eo5XLSlVIgOTiwOWdLg08K0BBiiro Rvc2E2IaKlmxgJQdC7p1phpLJgPx2t4DzILZ3D6uaRNCYrvvOcUb581/IlNlEHlSTchIYk2GMxaF 1et6eXd9uzoDtcgU44Zl61xjyj3VCbFyEQTCaUiuCRtdjay8S/UGUWjPOAhP0d3ndwcefjlfzvsm dOnaNtmsBa0cDnD1PiOxsK3jQFSQEu/fimLltBFnTNUQOOeKKvi9jEceR0oti9wnD7UFWyLhqoEx mz4X6FXcxUzTQD7uN1xVMNBx+Y3PP9PztF8/fqa1R6zG5/szf/3wGZd8z1IdvmEx+K/pxPPD54D1 uPgpzOGaCfvuht73fer7c4ufwDz7HLF5Xtnp+cj9TNPiF7qSlNINbPXYKH+iz+WiRpYxdaJJLawD k7KBt5LlbB/MQmpNvZHyOBidx/0QU49LDy79gla/kwbbCBCKcnJOboCj1w+dNNRWP+Go1W0hs2b9 iGfuIAzRNwNOSX8iWjIGZdyoOGGhuMTysv5MmDIeR1YeMCokTSEDFX0nmY+FxUXSoQEq4HNnxAIU B3o2XzGYhLJompp72TbPAdr1rWzqY9LNud6SfbBuZ+dDyUJ3EHIP6L7mQfdjoHAAqgwUV+2vtHE7 VvNs6mSAzkQU3xUibg98tE0sGwcu7XkqYlFyzETGOdKf42glh++a4GjXm0Q9Y5E8HoohMmi1To1M 0KG9iSBgUPdtodX4CgSy3HIv6DD1OHnDOGQ162l85ugKbTWav0GuIGhv2qykqirPYxOLRc9BHc5x Pv5AAAHMMwxRrRXanxd7yLzxWol3hpjKhm9tuMh1aG1atWKgPJgGAtmbKkZVPoxXK7Oe2mnfSA97 9nCTursR4jxicT8MBhP/+N5njhprxhrb6+vXUnu/Y0Th/rp/2gg+fOtAItCnhBvKqzO5Bz9Z9NcN 1+di+TcQP6xmf+Dnf9kHsEgNCmVuZHN0cmVhbQ1lbmRvYmoNMzUgMCBvYmoNPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAxMDcyPj5zdHJlYW0NCnicnVZRT+NIDH7vr7D25VgJem3pLiveYIET Kzi4kpNOQgi5idvMbTITZiYtXfHjz55MSlJ4QJeKho7tbz5/tid5gtFwDCP5xHtaDn6fHcHSDUbw B/8tB0+DcXCAeEtLOE3Y6ZssJItBEzeGb2M4mk4gKQd7l9qT1eQPziwuPOxes4vvX0fTLwdz5d7Y 4AfqGu0GJqPx5HPy7+DwEJKrwV60PjbX27CP2T7/NhiPu3gvne/d6wM2xtuL+C8wuzyDF9nloHvJ wodsWyxoPB9fmo3ubuHU2Ixss+kHbB2kTgK9nXfSec+2C/P4/y6BmUw6mp8pS6mH1GjNd2U0eAPc LGtjf4LP0QO3hTYeUIMqS8oUeto6VES2T6x3XahlbQkmx3BNLodb9obEVKYwy00MO91A7ZReAsKi LooNlOxJGZQmowKU5nXm5oz1qi73YW4NZik6LyFcql4LWXqqyXkHa1MXGcwJKuOcmhfEgbVv0shW yiEvDcPePTyMnCLOfugFSdE1SpS4CRg5rghStFYxUZ8ToPeYslw8XwuVgtERiG3KbsXaskL3UwIN Y9uFsSXnyKEpAf8IeJXxpL3CAswiQmWUWsKglHh4VZKos85VmjcrtiZwpraMs0YHKhOIBVPkTE9c JzlXF5xbiXrTUmsVC4nVXhXqFxOspSXIOZl/jgrQLnBssRJhPWvUepUooGDhDOdKugsz7HXfCTiP nHBsiBDL6mTklJUKSX5Ks4+Wfdc5cSthqEfrir3yV9aslEyfWXBcGgTgf0RhlM5mHZKcu1nKy13v RDLmbakIZperyrWFE+7AWTEPFfpxzkpJNqE8vY22+DwiGRByPXid/SKWtG9dShOFZdzldP6MZVUw HUmKeRd1xt1lau1Z94JWVESg73eXs4RRLDiyK5W+EnGQKeet4iaXBnkveU4pwhi7RK1+NTlLReKZ PmUu11KnJcFFCHOv5ZoOx2yWeThDj5BsKmq1kkVWlWmoFQu1sKYMKl3enJ1fQCbuzTCLPEpzGRWP KBZFlCm49ArpBZ0BF0qThHTgAhIzudFNXPCV7THLpEoboXPcni03N1fnJ38O+2lIIqfGFITtmJ7A vPkNKyzqAGep4g5hDRtQIRDRXrcdtlPwnlFAlNS1bEB4Ij89u+O40Se4/+f6yqU5lfjAGfbTZ7zG 1GM+iQVoa9StgVBw6jnYy2hvVXQpN0bo4MKs4frvu0R6u8Otwe1RiBiOz2b+mhufd2pwz28MX0ZH o4dQUdkyM2ktWPvxPJJNIjMZI51ixYcOig7hiLOoXcVHuqjiKkrDMSWFvm9eRr7Ky8hDmNd2iraM kE+BJWmyAU4Y8AOMQutxl8vhsdTB5DbOU9kcWE1+02nI79pYhdZv3j6vzp+rcDD8qPlBNN0Pbz1v nO5vRd3x4QMjnieDv/jzH35T3t4NCmVuZHN0cmVhbQ1lbmRvYmoNMzggMCBvYmoNPDwvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTUzPj5zdHJlYW0NCnichVbBcts2EL3rK/aWZEZ2LVlOcm1j p6NMO01kzfTQ6QEClyJqEqAB0DLz9d0FQBoUPYk0Gkkk8Pbte7tLPMLV5Qqu+J2+ZbP4ZfcBjm5x Bb/T57h4XKzCAkhfsoHf9rToI1/Yl4u4bwUfV/Bhs4Z9s3i71R6tRn9xa0Xp4fy1+/zp/dXm5uKg 3OwefBG6E7aH9dVq/W7/3+L6GvZ/LN7SHWmaptNKCq+MdpcAd0JWsNveQoPOiSOC71tcgqiNPsJJ +QqEBnwWTVvTZeXevVmsVgNagU5adcAClAZfIZSmrs1J0VaHcgixpxvbv27vPl9wHCcrbEREYgyl vTVFJyPIfdwGN+ANuK5tjfUBOYaiRedc3SUBrdcDpRUHtELiDh87dD7EJ42GLfTTofYMz7Aanz20 1jypAm3KYpIiv7rWeYuiAc/AhLj1jNM5okM4SiuvhEcQk8hgLN1NWULQXnulu9k6giCNxyAjG1kb hzYxzXCc6awklKKwlBSYMmRirDoS//SP5O+s8j2RkwSmow45ypQCbT6idUQt5HgQ8gGMThL5k7EP zKM2kvN8lU4KLLznvYRSlkpOvVkTiRTx185XxPh7qMOfeJT05aoi82fuuN55bKC0pgHkak5MZoK6 N6F44no39SatoVilsU1gNeRvk0bOC9+5odJJXssckzrTRK9Doq6rf1Z+WWqf7re7PV20pjtWr5bh YATll+eRCLXCj6kHD0E40MarMnV7lq2vROyqV7070cbodJG6N+aSJZFhidqZsRUGGUPdZLE5gogD Abx4QE2TwlLVZzhb/UQqq2Ncn0Sfyrq5PFt2ri7Pg7EzTxXqeZIzVVOl8rYD1gqfaCtR52wOtLc1 phx1aDvbUk++QP2QfG46Nw9B28CSkPBZuWB7i2gzIIt1HM2VaoO1xhZxBgQ5+0lHTidFmCQTk8/9 fRK1KsaE2ZJxTlyEwGEGx3mRAUWregorOSF6roxWBo2CoVOnbkID8PB+pQGGYrFhQUZiDL7kmDOn TpWi7tYmhWeopHQyiMOInimFEMzbv7iWZUSpS2Oj1uRBqvu89w99bEi3BFcJy6teUSbbsQzzgU2V NEU1y4y6iPuyRejPZuL7UNMR+VuHtv+hYLGucqLiYDo/k4qeJwNdfgyNv0ODhEnJg75j5Yb5mZ0M 9DHL8UkJHjepA+iJ05LzgVYqvyIfWsn1gf0017+5I4maaNt6GAyWikpR84DIn+x00iAM4sdmikON sbTzkwedjhqlYzeFtMjUQTPWvxWWaVJ9SfKanaj7lERalpIchoZrUdLAejnMEJ+vhoj21F/CDSeZ s6tccQkoTMKh+A79MIm1C4qQWt5IU7ORpZCqVn76LJ0czTibWVtAIbwIjw6e76TROHXozyMXzzJh keepu/JasXgUQYk5dDhFpWMiN+/Lee0+nNcmPpIMlkS2zN4iRiGQx5Wsu2IiIA06j9oNU1HZUMmE ttkEtD/pECAsEZm97p5bWu3gS1f3sFmGs+xs0T9f2e7V5l9CvNsvvtH7f78irD8NCmVuZHN0cmVh bQ1lbmRvYmoNNDEgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTI1Pj5zdHJl YW0NCnicfVbfbxs3DH73X8G3JYDj2m7adOvTtqRDigbNYg8YsO5Blni2tjvpoh927r8fKemuvtiY HcOxRX0kP34k/Qzz2QLm/Czvspm8ebqBrZ/M4Td6bSfPk0UygPImG/hlTUYf+It1Ncn3FvBhATfX S1g3k4t7E9AZDFe3TlQBXj+ePv36fn797mqj/ckZfBYmCtfBcr5YXq7/mbx9C+svkws6qYTUtQ4i IDzd34K0TRONliJoa/wMYL2jA3yO6MOKrKIHWQvvgbxEjwqCvfxhslj0cNoovowQ6J5oW2f3ogaf b9oKBKydkFgQwTq4N3v6T2+TR8JiFJePPyaUeyO1QhNWNjqJJ+7JuLUuwGGHZO0Y0tgAokD5fOsg PFQ2GgXCpFsJUlddclGMdtaHbxf+22UCwXCw7t/0+WMBS3d3ialHW2vZlWg4TQKksExlXZNSAfpL JGwdorqK7ZBdy1c1WTOcb1Hqij+xcehaZJpGZYAGvRdbhA1qs015zwhquexJX+eQwMsdNgIUVtoQ 4BikOJKEFoQSQTALPraJPPI9KiO+yJ0w2xSLLvyPktOGoof7r7d3n0BZGRsyKGrRpNNkXdJtBH1D L45dgMdWOBZICZY54HpFz+fMwc9KafYh6luKsoDgC4H6RGtV3OpMWVXji96whjs+80gKJKTCmSfS wgHRMEEFi8vM0l5RZpk4gjofGR8OSGReR0VlsGFXoIoYkm2OKl/20+GoL56Qgbxw0QFJ8rVt8TtH YSdC1kWXVYEyOs4o15JUG04Aa9GR3IVLfVZrVD2WTREOZeFUvxqkPhGe+KMajkryKm1urQLElkfs TrnFHJ5tAElZbRDIg647LhY1eRgiYiBSLYvmhBVKdpObkO4Yn9RI7RSstPWpygdeeEJohym/47Kf FWuRwFjh1P1BH1WVQ+AgCQyNdF3LV2dDc5V0Rz3QE8X6LQGl2cJMZAhUUxouPcccoI1cSRJcasHK 2aY0HwNlCf358GUoHuE2dl+mg6FBkshUmAPkjiICCbzvnhHQAEIxKaTt0ZCWSP4H0AH8zsZacazU 6arOGkMhd6865bQIbXStzUyd0wL3pS3jJle2L3aabhT/qBBs4FCi3nMK7HF6vJT4uDQGp5+KTR6n OfE8d/utQdxmDYzmVBoS9EVaPzSzHkEo5SikPgHF+8cc7580TDsfsDmT/akQOJRtpEDqNHe5JZX2 MnreUBTBCmWy+3F2Mxvlfoznh14/mljQIrq8KA6aZGN4M32XM2NI2tPUNDo2/lStnrgXWQBUaB75 tuYPY4ILUu+/308JjiAe/lit+Xos6QgprVOChycH1WfgMRSgPgFJU4n6c5qzmB6Hmur3hpJxuC2/ NFalt6f9mnR6L2SXK01Xq7yyRZr0fUwMSd9z49Ho6pepynUfGnTYUP+3No8qkH4s1LU9+J+4Xtf5 19KDdVo4cn7yuHtpqfc9fI40/a6n6WfWidFfj9wDi3d/E+TdevI7Pf8DsoxKFA0KZW5kc3RyZWFt DWVuZG9iag00NCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk0ND4+c3RyZWFt DQp4nJ1WUW/bNhB+16+4t7Wo41lOlhTFMCBrnMJFk6a2+tAFfaCpk8RVIhWSiqcu++89UpRt2V4w TIZhUDp+d99331F+gMk4hon7hF9eRT8vLiA30QTe0TePHqLYB0D44RX8nlDQa3cjyaJuXwyvY7g4 m0JSRS/m0qKWaE+uNMss7F+L67fnk7NfTlbCHDyD90w2TLcwncTTl8mf0ekpJB+iFzsRr04Orlcv f4rieD/waZNwftXfosD/gDVEubz9MqxxH+UJDq6nX38jrL8n43H8j0O9d0XcqVLwtgv4eoAxu/18 AxqN1YJboeSRND7EtjU+kwYfGsJYWmYbcyzNMlnMb99BhUwKmf9fNnPJRYrSLlWjOR6k+Rddp9P9 Hg2va5E3GuH0DSQF+rYteYEVC+juJstzjTmzCLxkxqABWzALXEljhW3ovg1bjd8KQvo7QqWYnWiR DqwiWYWmZsSAUV5mIFNlqdbmzaDYTeu2LP9ArUBp+Chx3Bcb2uvrAvJ2YzCFVQusLEluY1iOvnlU sto3bMa4KIV1vOoOhhFPrEhiAyu0a0QJNaI2I89VaSuaihZKb4vKMEXNnHfoAZFZI2VmLh3UWtWo yxa0chqFcsx4yHPXO89xHXhsyFdJSiLkPr+w5bKxhdLiuy9yU4UrUGNNnGDF+De3dC17u5wvEpd4 ebcthnbnQtJ+8m7faatdB9eC2K7QyUNPm057ZLzo3NAai9UWx7tGI0fxSJEMEocRquw9UzNb9MWY zugqc6sdGDrhMsGHOg6H4xkh96ZoqGQoYoGmKe2+nr2fnNxjOAZGHX+ktencLzOlq051JYcU/CaR CUoZSBaKNKA66QhfK/3NkWYSmLW+OV7sXdsJ+UiiidzDD5WYOfk7zehLhoZSUB/SzfBWrHU9c8+9 c4IEkpdN6jUYEO8b7qNGUKDkYW/tqRFJ+B5EVk5kEoVIVSQto2yjUPN2Vm8uvxxNv8lEh4aQwoOv KV0/0wHI09JMGu9dUtwqrkq4795w5+4N99VPonfbbhNMoZqSkPo+UIypWDeutTJGrEo6j2TqBZLK uiqJrW5rUi80/Ni49r64+bxM3B7mcMjCxjowVpIqNCg0hI311UskPk42avD849XsOuCkijfu8HF7 d84mt4Wrqmqk4J7IiBpaic00psz2h/VGF0oQZkhTwULTGstwstGZNFTL2efiwvf7hkadadseviZm f9UEY+B9Qy07G/n/CgdB93dOh/jcvZpmSfSJPj8AbCOKyA0KZW5kc3RyZWFtDWVuZG9iag00NyAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk0ND4+c3RyZWFtDQp4nLVWUW/bNhB+ 16+4t7WrrVlO4hTFsIfFTuGiaTtHA4YFeThTlMyVIlWSSiIs++87UrJl2THQPYxGYIR3/L7vjndH f4NJnMDEf7pvVkY/rS6hsNEE3tNfEX2LkuAA3Rcr4deUnN76jTSP2nMJvE3g8nwKaRm9WirHjeJu PDeYOzhcq+ur2eT8YrwW9sgGH1DVaBqYTpLp6/Sv6OwM0o/Rq4s4ienkcv5FS8EauJJo7esfouk0 mOlguuF7dubtkCMTUjh03IIje8aleOCErnPvCyW3FgsyospAeLwk2eKhtBoMz7nhivEMcm3AGVS2 0saBUAGw38g0q0uuHNy14c3GhOZxKMr7+FBekE8gTNZZpw3XXmoDTgMv10SICpaf54tr0KaD0uRn 4I+bj2DZhpfYk3ZyVtxruW2NXHJviwdZ6tab8Yn1ZpCDbj3vKR+s507Y96AO8E6s50O/xaffb+gS rDOCOaHV1vDzLwP8O/ikM747d/8izI0t0qbqvU7Rkd+cGIXCLWNL9/ckjpN/WrqlYiKj5FINnaLj T248pHyZrvPbo+zokjj+saNrc7/ihRd0RPe9yTzld0SXUtvmgrXS/ye6vWQOqvb+P5TUUVkP1rUo asPh/N1LvdexeAsWheEFzYhtx/h+RAdMK7oSV5PBvTBbkLBxODJyLaV+tO8G0nxl9jF9VjwOrKFg WyQag7WlhqfOD0Ul8gYQNto6an2gOfqozVeaXQ+C8dFhf4bOJwSGlg8QvGbbWMdLiqQsayUYVZcq BoMv7pV5UWsPkvFcKBFqn8ZkC77VaXhQmhtdBoIwoHoMW3Em8kBEp/0kvJhcTu5HcMvb9j2Lk9lw IPWd1MP8yY32oWufLHgv9RplP4qh0kKFSNbIvvqYg5J9nEGGQjwkupuR7UzN0CGUdAeym817HT0Y ywrLvesLCeFwdbtcpSM/oUV3DFRNQ9uMwksS9q1DLzacQNdDbE90vDvHFsAnGauKq4wUPwq3oUrI 0G7A8gpNuMAeykt5QFnvHrC2jihQXw02PFmPG8E2IByU2MDa364VBtfSF0uPVBhdVztplrQtnrCs JIFQALv9tjE6pHCGZ4PIfN5grR0VrR3RRcmm1KYiCYDO0W3R5nyub/v/ylo6QTxU7pUd5JmKtqIy Ez6ito59QDXFmdXG337I8oMfm0WotxFwx4bFtT83yTCbBcONNgKNO3jL/Fo8VYJeG/hQywbOR+FH yJHT3RfqHEgu/aRapNFv9PkXH8uDrQ0KZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag08PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExMDA+PnN0cmVhbQ0KeJztVk1z4kYQvfMruvYSuwo7gB2v r4nNpryVzbKYPcU5DNKAJpFm5PkAk1+f1yMJfUCSyi2HyOUCidbr16/f9MwrTa6nNOG/+jMpRt8u 39PWjSb0I/63o9fRNAZQ/ZEU9MMKQff8YLUZVe9N6X5K729ntCpGF0/aS6ulv3q0YuNpeC0/PNxN br+7Wit38ht9FDoIe6DZZDq7XP02urmh1U+ji+rHz1qSsVQYK6+BM//y9Wk5f8TXVSZpJ/IgHW0Q 4HErvLdqHbykd1ZuldHvSFh5+c1oOu0gBidT8oZSCcqFAv4+E55Kk6vkwC8IKsSBrHwNykpKjHYq lVZ4AAKrRllLZEVK8lYkiBIaj0iUpTU7mdb8FhFzGblEUKWTPKSyhSlC7lWZS3IylwmnQDnWFIN6 cuU8XoYSYMLkN8qTyPMWqDTOqTWA6jp6tB1KlJoSy0F6S5U6bhyjjPUqFG7cYkFOtHJv7O/uGk9n s0a96r02sNOO+c9fP9VVt7SreELTG9FBSXu1OXB9w8bItxISIM5lwkaaQm/R/U0UA9LFl/EFyhex rjrhkBYrjWbslc+gmWhooKxUbtDwlNYHZIOmlRh5JVKmSkcuJFmLJBxyGxdJiI5ajJXkiumgKCft TsEE3HvWvC8arimIPsTwlXle4Ob75m2llVeCi/axkFf4OWLiVtkGeahUbHidjF4unhcvl13Qun5Y UulUISqIfEySl2hplZNj0G9rjB1HOvjqUMZKuUX+AOAtvGx1gXu2SlFIm6gIlYYkajbuw0ifXNdU hpocSTXWGrzq2f9IEbSqoOFOdNoK521IfLCR9YBoK885YeD5uELbRu2kTgHS7Thl6PFaSj2oxHmx xqrLjmv571H2Ks+ZFsjn+aGPlYmd7AKyj3hqeMcVia2VkiV21VBigw64xHVRL2ShYRUbYJKeb08s NwPt58XKVLY735LKOR0PClo+PTYuPGe6WHaJNcBcG2X/0XqDcno+/JfWG0Adffi/9f471rsB7SdO 83Ccl/HJ6fzGlMPO6zIT8rTiqs0521mUYFW9PdZjnefl2gSdYq/AGWA4oDmq3mQ6QLHi9CqUyI0t KZYk1vxtG8AuhwCusnOLhN1L0F52N1u+mq1ka00oq3RdoQtZrKX9S9H6WA4qq41K4mZSb37HMqFQ zDHktWfVBk5uXFCziyKxY6M+qfCiwqtPK5wKVNXAgCLdCZ3A9L3uQzHY2/MhBewiDAOOeY9kdfB5 4j2OPOc+DIWO+fj08CYKnIKYZh+ktZDrHqB4ukBTHBo3Jolni0a2eiF7eKKP9HLxQWnUFTew7nSB uaSwSRZbdTJR4k7P56Y+2jH/mbxIxSdSpVF51NHYrdDqj0rIPk7d5dygbazvmyp4/kV5eZnAek2G aAKMOADc3cUF8slYJSzCT675W4mzq6OPAV64Hcej9UnQLwuB49X0/lcgzlejL/j7E2fay5QNCmVu ZHN0cmVhbQ1lbmRvYmoNNTMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMzIz Pj5zdHJlYW0NCnictVdNc9s2EL3rV2B6aTKjpJbjfPTYJE7HmbRNPbo1PUDAkkQLAgwASta/71uA tEhKaU+VncimgLe7b98+wF/F1fONuOKv4V21qx/uX4s6rq7Ez/hXr76uNnmBGN5UK95usegNP9hW q7JvI95sxOuba7FtV0/uXKLgKD17H2SVxPJ1/+Hdq6ubl892Jp59Jj5K18twFNdXm+un279WL16I 7afVk/LhzXMhPhOFref/8cudU0aTS8K4yodWJuOdSI1MIja+t1o0ck/C+affrzabCRC/AsUUjOIt UewoHYiw9+BFB2w86ZNo5RHLvvYmkKj6kBoKQJpg0F7avkTdETIgobxLBiU4RXh09E6XfDpvkObB pAa/0xxF1oFIP+s7wPSRhMQmueOf6h7lWeMoziqfb1e+bXtnlCylcNLG7b3dM9Ixl2ScNnuje2mj 8EGAMZMMxTlOzlMTMyqSB4MS9UyJ1eBBJXssZZBUjfDMyXPgXF9P6H2JbN8WRt8hJR+S6dv4f/RL neALTgbASrmzJjakR3Lnpf4X1efJC4gVy/Qc59AMmpmu/PJERvBYAUujUBSdgjwtQDy/py9P50iF bS2TRPhtgw4cO0Kzqvys1KYky6wsXSRyIeGBUWzIlJvKlHTQMRMKLS2eL0TAhLCGg1QpCmm9q4d2 P3Ro/qAxsNf4w6AYzq8Em0MhcgM4y00Aahd8AgLpM7m8Qsk/qeBj/DXjS/vW907LYHIztg24j2Qp 9160fUyZBoKMqmGaztTSUoyyLjSiAGtFDiDcEEHsTiHmaX8rk1EBpelD1dyJPHGsuwWTWpsh1ky6 EH7hxYDaCTHZRCQH8G45mEMdoxp4F7Lg8UwMjgbHQTZ3v72//SC0Vz03d45jnLK9Jr0WEOiBwAne 2SLoIZGLnN360aLE/d37kcWlVLOw2FPgOZQXR4gDClPzUuEiu2yJnGEonZ8Acb7Lfhwzm9g1DtCO 0zMxMVuB6t4WCc6RQGl2ImGpBtZJ3KfEkIt8BAUQQAplC2eImebEmvs3JTifSjDY4Y6pcPUCyFmQ N50lp6eJVRMfRjP9xAHmQNnRNG/T3G60LPaKWxR8XzdTmeXqzEA9jyaovKgAgESvDJqnvynF4dzL yZ73LZ90o7042C3Ou+xWWxRL99gLHYzyiYNYOac5EveamQTK384fHPuT1HtGW+cT+GRi5XMUdXZ8 jvGHKKfBFkxo7iHq1H3gKi/s3iNVU+cuj26TPQaHpZ8bDX5UgEkLVqdUFfFQfsYUAKwMdT5yJgLm hYtOP2rVTQ7GkSLZdZAaqxhzWxbESwIu44dRmGV14rHvGrJ6LBTf2lQVeFuaRRV8myv57vxs+Y45 yRMZDRNv0ji1Hcg2O7vICVlnFbe9Taaz49RHFnNL7Y7vWwNvUbY0OdXX56dTHk3fLc4Cm4+WsU8Y uYqJNIXm7J4XLjujcZ84mPsX1FhsZeR7eXK9Bo+f5OGWbzMqUz0SOyQ4OzPMhdvPpbMLm+hBYTBr 3sl+PI+xFtYrzHuNe0Rw5cnogAu++tT4UDwGMz/YaIaU7oL0IY98avpqyRZy4rsucXKG7/ddoFTs uQyGg8OvhwYtx/xxQ9E1075nqzducOLH9h98OIkzB1wgleiuOB57b/CSN/zCl2+NCMbma87pepkH iZYTqwgXYnCRLfjIuK0EshwvbZwMFJ9g3UJZcDdkCJybm9wvRDQyYO/Z6/ahw+BF8bFHgjfr/LfM 2aI/PjPRmx//BOLtdvU7vv4BHIVD9g0KZW5kc3RyZWFtDWVuZG9iag01NiAwIG9iag08PC9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExNDg+PnN0cmVhbQ0KeJyFVk1zGjkUvPMrXvmycRVmAX9u 7SmOya5TsZ3Y+BTnIDRvQLszEpY0YP59WhoNzIC31pQLSoz6tbr7PfFKw8GIhuGV3mXZ+/3xkuau N6S/8D/vvfZG8QFKb7Kk6ykeugoL07xX7xvR1Yguz8Y0LXsfbrVnq9mf3FiRe9r/e/z86WJ4dn4y U+7gO/oidCXshsbD0fh4+k/v9JSmX3sfdg/cPtxMPlNmZFWy9gMs5OQXTIVYE+vcWMnhCxJz1nJD lp3K2NFa+YXSx7/1RqM9QEGZynO2YZMWXhkNPOEjqGOdKT0HsFd+0w9rgGhtPvoorXHuPu4TxbWp dCasYneEPWBoa8C756cpicIZmgVQPwDKeNwicoWD8Js/WYmiYnz+qImdFEumuEKV44y8Cc+AEnhA O+G9VbPK8+C9Yz0xJ61+QPDz4eXwZx+LMvI5H4y6FKZwKldyulm2DvigmYylUugNKD1Ovj/fPk5u 8HG6SLwcQfCo1JYMHXmAHJGwvE+rZAGNcQrhnHKelKaMEZVS6SCyyuGFt0IyhdMtl9YsrRKATEV2 zJ6+0csHfL+Ct/blGC5LVqsAErhYfgW1WEkaOKchYFiP2IMdyl1VeLUstmcpxab2p4BM0LsuCy5Y CJn6kxZmzSu2fVov2Lb4LJEBNSu4T8qTW5iqyAISwgdVIha4GN24GfNVGud3CELKCmHhYgNNnISW IJRIB2coqNr1zHfMatkzuX++Sy7tbAlPB12bJEE5SJNv6iI1VMctk8MgSFDWEVZaFlWGvUrHLY+3 NzDUOfQZpQzEEibfccKeWOYg7qMQce+F/DfyBC2zjFWe/n54/noDqYquFSrviKHce5G3XIiktehw dwxx0cBbQoGx2NXfa+p0jvREt3kLBLcWoTSWQ36FKhpNYr91se7YL0xGAk17Wy6F9CQLxD91Tl5Z 7LNhzSocLI2fpkO6UIftsg01SaEDuybuGdpj1/ZdmDQDHJ0O/oi8TgcjjP+X4wOXxhDnnv3a2H2b oiQHJqEpdIvT/5qka+ytqxDEmsrHwzmHjjxgdAoen3DGevJHRtCM5wY3RuQ0S6MyckuuSOE4fF4v lFy8R6k9M4DYYhi31/WiVJbncc53FW3aPKoKddDLaIx6GoWLJMWpAeI3WNvQjyK1sLTBZBCFkspU bqsMOjhOp9SEnRysQw1nKlx8e1jQE7MEeoqaWs0LJ5NsEVtEGOfEhC3w1QoxFphgFK+/vYZoLvR+ IoCy/cgpsC1UqWq5+nB07XBLslxoU5g5bkxj90PcHuxJkgOfzyDPQzg5yF1XkBK834tgY3fqhaa9 3zO5M8tc4zf2zjZxGqBaoaLv4acC3N7Q3GDW67IG7OpqYtuaRBFa1Bwb2G04m5sgsswwhPS8iyXC ZF0Fl+Y1t1m7LokK4wOjC78odmX/i9d2unUQXQyyDZPMVW5ZtyouGMQHzBvQPVYI8ypWDdZcXEQt 70BEWEzRg7/J21KhCehLha4768cfbwcP/fgWrorx8CcQJ9Ped7x+Abm9LHwNCmVuZHN0cmVhbQ1l bmRvYmoNNTkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMDYzPj5zdHJlYW0N CnichVZNc9s2EL3rV+zk0mTGViX5K5ObWimtMrHlyPIlmRwgcEmiAQEaH5aVX98FQEakqWml8VAD Ag9v377d9RNMxlOYhG/z5NXo980NFHY0gb/orxg9jaZxAzQPXsEfW9r0Pixs81E6N4X3U7i5nMG2 Gr1dKYdGoTtfGJY7eP3ZfPzzenJ5db4TdvAOPjHlmTnAbDKdvdv+M7q4gO3n0dv08moMsHYlGnqu cnAlIejaCa2AflmUyB1mZ8AgQ8uNSK902InvfhtNpx2s8HHELxcc3KFGuH182MIOoTb6WWSYgdV0 jjmotRT8QJBcWMKzwJmijQTYgapYhuA0cK2cUB5BG7BO1+FqEOoZrRMFC3yI+zau5dpUcaWPZEvt ZdZjIlSEWa0Xy49QobWswHZx+VJT1CdwuGTWBhrNxr8F8SFl07q3QhUkVLO6cliB1EUkJ+zr2A7A JMlBnLwlPnlE5cRNuSge3RPSEvRS/xEZcm+EO4BByVyMK2HYMW2czTrZuSYi+OLOn5n0SL/nCiij jNIUVxINkpv2oMqSE5hzRuy8w/GpXD9gK+A3MuDV5Gby/YwWebTI1Xg6oLDBWhv3wEusWC+Or2h0 0HWtiFlIZXdnI6+wieLuELVvcnaCV1Iv+szgkxcG44HcS9nQtQnXRflJMemPlujx2qwWgOQ0qeso mQxVSDo3CDbmsYeRA6uDyTDrAYX0EnvYC1dGVIpiNb+b9yWKka8W96k6Utgl3ZKLZzzmwn44Qhsq AiP4wBjr++1qfTf/TKSXd4+3jQePGMQ4E5wisVGbTFgutfXmlJ6FJ0dJocJeDftS8DIesmQTMijG akk4hgq6FtHCGlhG/o3OOWJFFr8A23K0oDSdZfLoZ6olTixdSHtA5qUWvJ+c1IQ6dzYLmea+ajiU WoXCcgMBXmVHSr1PF1lWYTdkkv9NR+U3yYTklWilgcVvbbEl//VdtPzyuNosF91kYOqQRDm4oW1A JKlrXlvxkpx8IiN0qjlB/MjeqTXvEq+2AC/HM2BUyKm1ksKhPbB+H9IKW9XCfandx4a8I8/vB9HN AjnDOG6osEiUVtaWf1MObSsRSjgRyoWdah9doFD83VbP+m+DmxT4mtKArOq3QJqKe21+QDAwRpQY jvaGDMSyjJJn2yC1EYXojK9TnbTtoIPgL8ahg0VCc+9Kwvp5nD4dEeLcTPZLkyqKQLPhlAgh+/Zg w6zIja4AGVVXw7aNt7MplmBTNX3+nRFBaW0qI6lnaZZ52w4tCtMEeo1ugzAvY5jWy0F2uz2DmmtH 5oYwVRfjP06FuacykprHEcXidMH/1yvE/SpJSSlXGu2L1IW62jQR1sz90tAFG4UYr68jpVtKGzOU 5sGHpj6NCgufvDzA5Vn8d2mw6dt9YDybfifE5Xb0hb7/An0U9yANCmVuZHN0cmVhbQ1lbmRvYmoN NjIgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTEzPj5zdHJlYW0NCnicjVZd c9o6EH3nV+jttjMOF2jSdO5bW+gdOjdtQuhTpw9CFqAbW3IkGfC/71nJNhiTTA0M/lid3T17duVn NhqO2Yg+9b/IB38vbtnGDUbsX/w2g+fBOBiw+k/k7NMSRh/oxnI9iOvG7MOY3V5P2DIfvJlrL62W /mpq+dqz82Px5fP70fXN1Uq53jP2leuS24pNRuPJ2+X/g3fv2PK/wZv48GbI2FzvpPNqw70yGtfL LWBy6RzfSOarQjJcl06mbL+VmvmtZM6UVkhm1m//GozHJ3h0kIFHnGslaOVKZkrusNobnLMdz1Qa vEhWlLYwjnBoEbBOUDpRMSufS1wSHmAy4NkQHUDkQcFOb1ghpWXGdmGE0c5Yr8ocGFkAc1tVOKY0 bFOsAJ42Xq2rgAaS98Y+9XCctDuFlAtrdoqWiQyRIyIs7zASrkKSDQldIL/lHtY5At9J7ZkRorRW pgnYVWLLcl4RTRwe8UD56irELdMujNICYWg/xO3J5KQC78HtQhbI+byUTRURsQ0GJ05avORSRdfG 1tFpw7gIFQFaXRRAqiiL+ffp7AubHQopfKD6rBYZd66NKuYZIiJ839WDMDbWC4Xl3nPxdJ4/FuVR HKuKfX6cL5YuYY78Qg7CMa6pAlKnBHFinnSBpBc9Dm9DV0RCHkppq1eprJV59HCRQmty8O1tGQhb zKfMVTjFzZUpUQrdlgDaO55T//Xi+5imihzxLKsSYs6GkIAhD15qR6SANKtWpZcUJE9TKHt/HpjU ZY5GooCgWKTxz7knMjr4q/AUJHyEByd4IaN9S0JwizPiqHUM+0cpL5ARZfITU+tmdDv6lcAsaupm OO7leuc2UxoEui+oxezhx3wxm8LR7NuPu3qopEfrUByF5kJQMTiaHBlp70JYUhGTJErSIlUolpv0 U9dKacqzKbyQaid7k6sWRIIyJk1jCB5VjQpdnGtJD6U7T9puJ12+ing5lCahOo0wgwSWbmVWoGdM QZrLVQDpZ9QMc2pZjEpi6EmbvU5ijwG76Quy2PJd0BxWYUq7LtQlVh018NpkmdnTTcKzaIkw0rnf NhMWS7sMxVxencNxcjQJ1AL5ZtJuUDKTOfVahsnhGhmcUVZPqPk99ZJFBpc2rej8lBauKY3jrlDK RhIURetZuQ5OKrHd50pDaKu4LXW7oFnXaxYc42Fg+TGEXWfchEwJHqd1J4I2m97kilW7N5kSVRzh YRcOe+XBs7JwmLI87+lrr7KsO2qDItumOdFCf8LhmND8CIR+X8+P+v+zfF5IpC7EC/m0QzfWsXY2 v+9l0fg/2QbaksWNjHQLZ43AuRCyIEX3oIgEYfK81ErEt5Mje+3+CPy1qjVV6/0iUEP/eStw3XQC qIobuX89s+C21l6N88KrXBA71z2ky+9vZxtos6/iS4MlwALp+jqU7s5YxS1eTnoHXjEw1h37WmYV u07Cu23P6Oc9eZpMfgFxthw84PMbdkF8Qg0KZW5kc3RyZWFtDWVuZG9iag02NSAwIG9iag08PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDgwOT4+c3RyZWFtDQp4nK1VYU/bMBD9nl9x4stgtF3S UkBomsRomYpaYG2YJlV8MMk19ZQ4xXYK1dh/39lJadMUtqG5qhLZl/fe2XfP9+A2PHDNr3gGifNh eASRclz4Qv/IuXc8GwDFI0jgs09Bx2bCnzj5dx4ce3B00AQ/cXZ7QqMUqOsdySYaNsfw/OzQPWjX 77iqrMEFExmTC2i6XnPP/+G0WuD3nd1STJCKSaYwhAeup6CnCD0R8BCFHqWZDBCCmClVA6bsYogT LjDce+d4XhVszuIMYYoSgfRMZJoAE8AF15zFoCUjvFQSwxyV5hHTPBUEVQaReJ/Rcg1Eqi2nyoVY lVwAgyGqLNaQoFIswgYhNJtlMa0GAD7quhVE76cCUAVshoVEi6VTE4OC3qYkl2kt+V2mLeC27EZI m3PV6Z7DmLa97R65tzWaDEwW0G54FSEDFfmLGdaJpZTl1bXfu7o87ZOwkT/sXX4xCikdJhTcLeBh yoNpSR0uobYoW8l+m8KOOQphj+I/CN0isMzxT3pXco14j74Y4iyVehRMMWGFVJ+2Z306r1hTgFR7 LIokUqHhclbY7Rz2OtdpzINFPl0+cQOYq1I5IM9rn81mMp1T4RTTEyplLoI4U0YuIRPqsihVIW7O WU5YEbitbPfrL439LRv7VFjAOnSxUjrF11EreFvG02Zc9/JmAN9Q2sxficurxrbievTTx0/E/tP7 VegYw/dBv5MGWUK+U3x9u5WT4vJMaav/zLkeXXC6jUZOO4abYX8jzwrn3+7HS3HPnO8Lzg5qRorC EY+oHzIyyrdxvn6mm3W1Ps55ZGjbJ9XGOTN1udZVGKM5EFP9TJubgrpYU+e+UNHACJfuiUkax+mD OlkJXjvdsr8IcgHDtH78pnGJLJnFqO0KhMul4vYx3rPda3hKISddY0em2IxlFt1mMiLkXGih0OYR ZXTbxQSrStKonZ89aWVJZHnmcrM3IdPU2oaAYBVq44M7j0m8Q7YTlqCMX3IRVeLoxdpHiMapaOo5 UeMNh4c2tUEqOZN6UT3I7uOMS1RwkcULOKjZW74SNL4mM4Jmy1RZ13e+0u83iH4/Yw0KZW5kc3Ry ZWFtDWVuZG9iag02OCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwMjQ+PnN0 cmVhbQ0KeJyNVt9z2jgQfvdfsZOXS2aIiylcOn1LS3rjTtL0wOl0ru2DsNegG1tyJTmB//5WsowR MNeaMIC9++233/5QfsI4TmBsX/4zr6NXixtY62gMf9F7Hf2MEmcA/iOv4V1GRm/sjayMOr8E3iRw M51AVkeXqTCoBJrruWKlgeNr8eH9n+Pp7HrF9ckz+MhEy9QOJuNkcpX9G71+Ddl9dNk9fFrcX/0R TSYHt+j6B5UEqeBRYGxNYoBbUFiiQpEjGAlmg/D14R50vsGaARd51RZYkGG2QUJMkhCRQKBghoHZ NQhEs8CSCyzIE74R/dn4ZvwDlpgbLgVM4mQGTMPFVr8lsAGGid3TIr2wXpZBF70L6n/cy5w5jJL4 p4/zuw82GqsUsmIXYPWce7BFOvcYI9A2Q/KjPyENCMxRaysipe79Ql4uwSFkIfO2RmF0fKzuHA2j IMWSrwUzrQpxnPAUo6ZEfVonDj0BygpyWTcVGleLM6r3NOCFm41L0smvG8x5ySn11c7d5ZLK8fZu a1Bo0i4jo4BWXjGtHR8SxP2gXKtKvmjnvm55gRWVU58tZwA1g5cNtZHzCxpCo7GZX2zr6oLqXECN THCxHp4FOJ3dUA5yAbq1T7lnixU6BehrqynjIxjqZ9botmLGU/Jqg97LvWLWT4oDpQKIBeZSFanB 2ktjxfY9FXaDpfuMipdO9QBEKr7mFJA6SJbOtbYdt6b5g7QESXeU706qO7FyyXChDfV1iFR2UUcW ZQcPT8sMGiWfqUSuUMxOMGXzsmHGEyZaBAe8BBZAnRGDZPRghWt3NyVNqxqp8aTXbfsusJHKLLs1 0YXbMNs+rQJmjOKr1uDhlH9BpY+b5vFzlj5+urV7yK0kC+ztBhDLzQr37B+Itl6hlfPMYLjlsZ+C YZHFkMTjHkiKagcNqpobQ1bPrGqpzXTAbChyvwlpQFpFe9KQM4F19WP9Y2NV5yEGa6yk3TSmt59u Yb9GPJl+U406uYeMbXEDqBXaWTkphO/1rbl2Sdh1LgA1tT76tPxsWBuk2QvjxGcUpGuJfe77kR/t V/gsTk5oWAK/W94D21+V+Aw7P0P7FX9Y4W4vBJjdMA1lCgfKzR4VTvhsqTz2u63UvnSH5bX9vUIk 3gXFDtulOzmRiKNitqsqro2bpD7Zg3qfCEhpdJOUzn8p4IHtqYA0v8LY5j8n3vfL/nAWjLZQw3L8 ftVL+n+H/gARBKd+6pPrZq47dCjpmtQacOd+TYYLutvf/jA8N5IjaEVFy9LKzW3vsarflOGY0fo6 HrVRL8g+04NDfOhqwplOnUgPtKiZMjs4ue62DVd0An5sieJ05P7dOjH69plWOkymPwjxLov+ptd/ J5j5YQ0KZW5kc3RyZWFtDWVuZG9iag03MSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDg5MD4+c3RyZWFtDQp4nKVWW3PaOhB+96/YyctJpoWDKTQd3jiBdOjk0oJzpjNtHxR7bau1 JUeSc+n0x3dlG7BiN2mnyzCArP3224s+cQOjoQ8j+2o+w9z7d30MifZG8JbeiXfj+dUGaD7CHP4L aNMbuxDEXu3nwxsfjidjCHLvcCUMKoFmsFAsNvDY1qcnr0eT6eCa684zeMdEydQDjEf++Cj46r16 BcGZd7h7flAqMeNo4lnBFMv17D7PZkLPuIwwHvjD0cEQIEgJmhmj+HVpEM6vNgFcI2g0R/94vu8i 8hhWl4vlKUgFTMBqfjEHVhRK3mIEOkwxZ0BwXIRZGWE0JIjx2IUgw3szuGVZiRR+LgB1yAqEagVK TUhG2j0o6JvDbthDiWyD2ND6RPWajo5HX17SYmi4FDAd+h0alsDH87NNRXi1oMd7vMv3weryYn5G 3C4FMQxSfLy/VS5iZ2gDj1AYHnNUPQw/H1K5uaC8BMtRFyzEz0cg48qTYHeF21YNdkEdZg4Dqs3/ qLTNUBcY8vihgoulyplpgS9kWOZEzkHCDO1ahcJUU3Re+2xZtNoppKnr64DcNuFpjp4aB5MSn5Rp GioUwKKo6q+DZMOiIJqKGXqacW1sIu2EWy2cDsdUoTXelKjNxjBT6gbNVs1ZhzBjWtsUiB1LEoUJ RdiuiirwmqpZLQwdTq69GDxjL/ons2U/HlHrbvjb+L+O/Iw9FfkHLC+uzkERccXrE/XHzvPSpFLx 78y6O+n/hvO7UtuTFbJO7KedN8F6dfG2OkV98X/buS/+087P2F/3uUdRd3bKk5IO9OtZz2E4sVP+ zFGxBzXmt7iXOD3b821Nwa800/ase6twEdkKYq2WEddhJjUR7Tk1SUlimpFcansN3KU8TCsnTdcB KmoJqZ2pcRTpXsGtkNFOFqWo0D3EFYsdIFhhou9W0MiXZYQZloqbB9CkesTSbPU8TCUP0cFqJHUf s1mIGoG1HFIpSLa46RTAQYpllsm7OpCmG6GdMpX/oFXlg0aaRa2/nYusZ7KdUOvlh6vVerloNwYr gSXU6sLV+wuAEmgqBKynMUSrkEKj3VdXohofLhI42azWwbYgup4n+sXcZii6+JqZ24ovlV/Z2tEf oDupvtn8JpMq7DmlxRS1pmPL+4ITFxKG7AEmL6t/P51Nn96zBGE8/UKIy8D7QK+fyImPTA0KZW5k c3RyZWFtDWVuZG9iag03NCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDkxMD4+ c3RyZWFtDQp4nM1WTXPaSBC961f0bZMqm0UYTKr25KydLKnEeEE5pXIYSS00G2lGng9j8uu3eyQc bEk+R4CB0czrfq9fN76H6SSGKT+696yO/twsYWejKXyk1y66j+KwAbq3rIb3CW16xwtJEbXnYngX w3I+g6SO3qyUQ6PQnV8bUTh4eW0+/H05nS/OU2l79+CTUF6YA8ym8ext8l90cQHJ5+jN0/14AnDV NEY/YE4fkxLBGZEh7IUF0d0AoXLYy6qCFHdSAT1diW//iOL4ORpfmTcGlYPt3YR2zGbPd8woyDUq ORAtD8sd+ClMu1HhoxsLWWmLlvdCJhR4S7AlqVGjtWJHXzQUsiIROVpRyAwKo+uOw3Mo31hnUNSM 5a1Uu5AMPoq6qRAakf1Ax3glVg3U0smdcDiIhEWBmbOgiwAhnKPDQDxDtozBy1Z7Q/xpudHWyrTC SQ+J2W/w3hPFK+9KbeRP4aRWT/xqT+RTTs9aUjDlQC1+D4sOUwWF0yYUVRCw9ZV7gvIMcFTnVFin e1gn+VM0qXKZsRgi4+QsOPEDj16B1fr65gP8Iy1FPvSQsooyH7LLBRX/DglZ7dioe0GKU01aY4rq LyLgZI3aO2jQSJ1DSVKmiGrEKlTbrMT8DPalzEr6yuyPriPLdMHAOuG8ZY16yb5aihT59A4VGtIi H+I0Jybk5XPK3yOzUoA2Ew1CWGlLQILSHkqmTYvcY2TqXXDHEK8tHjX+RvNgMV1Ov5/RYigFLCbx UCKfyDay4KLRppc013fJan179ZkSvLn9+oXrQJLLHCkZVtESbsEu6tqZnHUUbzjFTqGxobA9WIc1 uTEYimXh4rTuktZ6bkJyD/VTaygb9tsROVwpHOy1r3LuC6kedPXwa7aYtoJjhuPK0ujphOnGD6oH rHRDIDl1kBMVWLmjRvIGg+QXs+Xi+0g2hZBVW1OqsMyFG1Rh3gu9Ds3aJZCjC9YdiE91GNUBjy1f HWlToToNN5hpk69IR6Ln6FfiKdGe6V9LfMEeUZk5NJ1eX5WgQcZ8cwzLL1X/dfaStq/prmlZEpk9 /9G81NnMti3QHYcsVFVpnngjrGk4ZMijcCjb5e/Sfs8GyDbMm/P2N26sEbfJZnX7MfRGjYKESQ/d HDvNd0SVgXAnvF6n8DKnjtFiEaJ8IVhh3AF6181jI6mLadJUB5ifhf9Cepu+3fHgnF1y99wk0b/0 +B+xQZg7DQplbmRzdHJlYW0NZW5kb2JqDTc3IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggNjgwPj5zdHJlYW0NCnicnVXfb9owEH7PX3FvazfIEihQVdOk/oCKqYWOZk9VH0xyCd4S u7WdUbTuf985yQoh6bTtIpTIPt999/m74xE81wfPPtU7zJz3ixEk2vHgkn6J8+j4hQNUrzCDs4Cc ju1CEDvlOR+OfRgd9SDInIOpMKgEmu6FYrGBfVtMzofe0aC75LqxB5+YyJnaQM/ze4fBV6ffh+DK Odju59rwmIfMcCm6+GQO3zi9Xt2HbH4TTOez0ysX4DZYTGeX9HEKGTKhYbmB9YqHKzASKACKCMwK KY7vN+LU0gEzRvFlbtCGRYTp/GI8gTsqaOCNvPsOLYaF48D13S2wgdunA1MR8giFuZW5Cm06myhY 4d4GhCnTGogbRgmTRGHCzMuqsFBhMb0oF9wqTGXvuk1711bY835Su/Z3sWpRmva87zKefbkGhZqY K7lpurRE+fCxlvgOSpwTmdNtkd3/B5LX0vzwXPftzzLNTEa44/DvaV6jrUWjv23Ck1whjE7a1HBu r3lHLJhiRruadMAMhFKQPg0pstBFq5JimaZyfbKFuUNlDftckK7P5vOr8enMLbPVJSki2whIXzEw 0OXemukWhRUwqHEwssqPC3TbAzvbHeDGij3l2mBUCbwGq7iSqmyQNhS5v6h/n9dA5UV3lrnInVec 7OWtd86EpfoPx4Q07UcttiaHlrkC9Usr55pqo3FTBdkQfSupqRwFNCfXUn1r4TDC7zzETsmJrZlp rAUpSN0QbxkJIctyUcwpkdj5UEOVodYswXbCKMjSRo4w5oIXLVpj2eJXWFQQK5mVQrODrwWyfsBw Oy5bBmPf9YcNFK8OwRVxLwVu5+6OindGCi0Oh0W8a6k4U2bTbLLx0wOnIzTQ0w0cdYr/l4bT3Q2x BL2Rbftx4Hym5xeB1dW8DQplbmRzdHJlYW0NZW5kb2JqDTgwIDAgb2JqDTw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTMyMj4+c3RyZWFtDQp4nH1W227jNhB991cQfmkC+J5kNzCaAu0m23qR W2MHLbC7D4xEW1zQpEJSvvTre4akZSkpaiNQYJFnzpyZOeQrGw3GbETf9MzWneHTR7ZynRH7HX+r zmtnHBaw9MjW7LcFFl3SD4tlJ+4bs8sx+3g+YYt152SmvbBa+P615UvP3n6ePn/6MDq/6L9I9+4d +8J1xe2eTUbjyeniR+fsjC1uOyf1+4fHxezh/tfbAWM39893eCwK4HDvrXypvGBS5zLjXjjmC8Fy 6TJlXGXF6U+d8biNtapkLpTUtNawbSGzImxyQufCMrErReYjjhWZLKXQnlbyvBBWDIB4xAosakBW WrPB/45pg71cATOrrPR75qTOwNIzGZGzwshMtLDM8k3M9ENusmqdOBRGGwuYdwK0kJZGKbONgRxf i2bK3LGuFQ7bMi+N7rLKiRzysdnD9c1nym4yCXpdDM4R5Wl2ze4JYl7yTLgUZgFgeuOyQqw5y0Wm uCVwprHW0VJi35UmF8u+lXl/PJh0Gdc50ltJh0ZxrcpAmBLaf/377paiue9UaI7CBFZ9ilXLcPc8 XxBrSi/xeRvoyAKJkQrelH0lNkIxoURAAWT/OkEi2MwnqIxr9kJVWKLYqFlOiiVBp0d1sPLnJgTb ICXoedUdD8ajLlNcr666Qvef5923PbhbK+2mNeWrbmX1VAq/nJbc8rWbYsG0uSIkdazwzslpVP7W oOcpauF9OR0Ot9vtQHLNB8auhtw5udJEzg2B2I/K2/3wiBRRhq1Ag53Lu780++CC9NGZqnKpV7Ei DF1oIKxlqBg7iHBoj5nGe5oldKyrytJYn5oeqhAGR+9taCzQJJ/ms6fFvBcWHHuqpRnVRAYCAj30 lkHOPWdrpKAGsTPje5oO5UyiJHZeaCdflOgxofmLIhphPkK4YAViY9QGEZTBu6300Ra0ELkD0QQU 6LrD/GG+Sf9gOJVzGIHCbAnrQNfXfEioQw8nrJaIh3eBCvWq5SuRjCmZCM2Pt5U77LdChfK7QpaO YagpL1egZ31hTbUqTOUZAGhYoDTUjQrR7Iis0PK1qkca84s5po7BdmeAwD0sL5Rci21UeSuVgrd5 RH6tJHbwWFMasMY4HstY+1QJa6R5Tu0QvUns0m6QK63cwL9JioRyFAR5ig0nR9RqH6yYkb2DaIbk ASerNSK1VYyDnLBSOWphYrcJojKPHgYHc+5gF0jg0SiZ7ePPUbUEhSj10DfOH+qFYNHEgiiSY8A4 bAAM8ckfjo20rKDlfwxTnUHq5ug9VIaGiwcPrLOLS0Te9qdxAqhzT24d9mLg6cDiYE2mgwxqz+yh SKgUd6mi7fMzeX3e8FhKMiWybJxD/29r48GoO2jxnYDvX4XQIIUNjo5inZmKbhWOHR0gb6lEJ0du wonr33Gt6EDHVOi8R+uSaAw9biiDbyc0UNTOaE4cbmiob6c9hno2epmFOVtzGS4Hb4/kA2QNgBwe A3kXh+WliYPxDJOCMmovl/uA1e5a0rK+kuxZwWFI2jQwUiTqB2VWMmt19LEmsUzBHRqUaKgbWLW+ JG+lcfMwKy3/gTSHU1Lq1pkeTCEQy5ucDh4//+Ph+fYacv2ALbaF4nQ5cHvt+Y4Ja41t1/6Mjph1 GaNGTzug3T+gW81WK8Pz2q1Bw4K5xMUkrxru065/bZwS0DIela4XbLRupqP0oZYULdTs/Dwg3Rkr uQXEu8/NrpR05/lSwZPOe+Hq+m7R10cy8cnldyDeLDp/4vsvoHaU4Q0KZW5kc3RyZWFtDWVuZG9i ag04MyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDExMTM+PnN0cmVhbQ0KeJxt VttuGzkMffdXEHnZFnB8a5q07lO2dhcukm7rOIsFij7IMsejrUaaSBpf/r6kpPGl3jECIxJ5SB4e cvwCg94QBvzJ37Lq9Od3sPadAfxFf+vOS2cYDSB/yQr+XJDROz5YFJ3kN4R3Q7i7GcGi6ryamYDO YLieOFEE+P2Zf/p4O7h5e71U/uIOPgvTCLeH0WA4er34r/PmDSweOq/yrcOXRjlcQbBQO7tRKwRB p97qjVhqBG2lCMoasAWEEpUDL0usRO/1H53RqIValAi4E1Wt0YMyUjcrwlQGnlBG7ztYYWWND04E hNJuQRiY/T2ZfoKVlU2FJhDgcNgCqiNML8EfUFP8LieUAMjWYU05E0iMSkiMMcfauvAUzUF4KKzW duvHZ5nT8w86TzmO4WrYG1xlZ3r+fXxIzrMJ3TXOjBWGYlwLJyo/3lV6bPxY2RUW1+eOcyzQoZH4 PH8gzzKEetzvb7fbnhJG9Kxb94X3am24bN8npGuHa0Xk7PtnLNCTqu0fwvR2fnV1wf1pRObD1sy6 0Hp/5K2wLhPm6YwIDWwptEOx2p+Tb7jVMJ9Ncnhq1ioepX8fWk2QP6WlTGzSE2K0md1/uc9cfKSO k6JctPbgsxg4E9wFNCtl1tFHU/HcUFGzCClZ4j4H8xmLBLrEM21xfgxFsI3D6NJqieBlKcwaPes0 S/6WkmSfR/Re0NUFi4mdiqjWXFrSC8Ui7fgapSpUCvydBu7t4G7wI1UiZJmn44xFDlWlUBD2NaWS e3WklYI0PmFKWy2VSbRuVShTMrn2tizPLBRCKq0CzxFDkWPVGJU6wjGmnM9pYNgIp7Dl0Wu1LkMU BqdfiRC7Wzeuth4/QMky6sau5OWQIm94ibClcNhCHUhpeaDw91qD1KRv9F1Anby7IEJwatmEeBpk jyOIkIEIshVSK75Y/vWk7SdbbIRWh3tpadh3STTMQ0bKdX/gFYMbdF3wtkr6So1sJ4NxUr8ZuqLC RLBUIVXSrg8ilxyy66HTp8z2LnXz+Py0YKEWDQ1fRlK8F6u0naiBaDzrlZReowNaJ57HgAsh6k5U 48937BcbcJxWYYt32MzRS1B/mmArVgZTJJask33UjNI6LcajPg8sEr2H18D/lgmFsxUlKn8i7QxT N6HbVmYkzTcBEHu0kr0Kjcj8ii0RawiFjJLO6Jy2tuNOi0YH7mdzlGVDQYluVsVhKDjF6YbwJwSf VHXCyW1vyA1wQuKc8kffymmCXjoVG82E0ZS11XD0VlKKFxJ9Ez0ch16vW+t+nlFEsiCvaO0z2YZF l1NralrZKCoInANY3qqn521ptnF8HVcE2xaFklBSsUtEWqJMYByjLKe0d1gTJ8y1hHuYT789z+bT tPtOqz/oJo4pWeYXOq9uZ5t1ef7mY83MjgHGJ++v2eSr1Uqyfm9vo/2jdUo4EtPFM93VpBwPnxva KTfd+Dvjwuj7V2Z/9P4HIU4XnW/0+QUTx905DQplbmRzdHJlYW0NZW5kb2JqDTg2IDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA4Mz4+c3RyZWFtDQp4nH1WwXLbNhC96yt2cqk9 oziS7NQZ31rL6SiTpK6lQ2dsH2ByRbEmARkAlfDv+xaARErsVBrbMoB9u+/tw1JvNLmY0kTe6W9W jz48XFPhRhP6Az/F6G00DQco/clq+n2FQ59kYbUexbgpfZrS9dWMVvXobKE9W83+/dyqtafT18Pn 218nVx/fv5RusEdflG6UbWk2mc7OV/+MLi9p9XV01gUv5lSzc6pg8u2Wx7TQWZmz9ov5mJTOKWfn S618aTRtTVVm7fkvo+n0GKbUa2PrcAi7s9l+d/Hn/O4zIA+7N9hOYauyZlp6VW8dPZ3N2XPmZW0s izZ9vNN5/PDAWxMXn84vOpB9tbSQ3+W6ZAuww2pWKef6nI6Cb41ey3rGZFGdLsisyXHW2NK34JRA gFdvVeaDHF3MqQwhV8TvBMBr2TrPddwm9KhxnJM3VJXO04vxG/IbCGEaizokxbxTvFfs3c8tBIp9 iFhuY5oqpxc+QFp+axAMlJYcjkOPjFA5YtxpuTiOSK9eWfCMY1mRSlyoZEDjXqHSXp9FK41kyCwm coEltH7hotRaxPxRJm6prNMKjC0L4WlsJFDqcNpblQklgYj+uduhDXPlVYTMlOfC2LbTxrGX6t+h PKuct03mG8vvBhwCkHgpMzaP9o6fF4cOsRMk9L5qcib+CXtWTGj/K/uBhgKABsJzfWEsV8rHhgif vY8uiL4bzzexiq74fmjKmxMwo26lRUVKXGm0SOS8Er9C/IMqfShSeV4GqJBd+YM3EL9j2ILtrsz4 A+bJD2NfaWvNDuXJrVneP513WFvpN4K8OL9X47GouKo6VzZ3hAOEa2HbbUgfRgf661VFrizQ5kaY PGJaXc6uPz6P6fHvb1+x8zw+UlVWE8zzzWn/5qeAtLamRnWgHC/w7XLxsIKzOl7RmOCtcxwY3AI0 qDcDx6DtkmCqqvauFmGbLYzFqj7yZ0/7nKHUBqEgMGROIknfbOidbQcGHRIMEymU3nFb3ge1VYPq MfQymVY4h/9O6R1RC1oJ4aFIGZgF/fwGEypFdNwSWY2qd1yZ7f+xlATx2uYma2ox/ilLie1bxe2d jmHWpocMbmdhmSXepQdRtPoRv1rZV7buOMNvNJ+bJSmPhrxiWmjaqB3jrEzFMNyACDM2VaCM3tby Ue556K1MgKNElZGR0xuOLsmdcuBmLzzwW5moO1WV+wsH/GYv42mO0EESYasezmrD8eb1pwJr9VKx S0Ahb17D9DCkTM8wsWA/tljEvImlYXTh4kazblQOO6PHeZsMfsCypik2XSFpLKRK/uvpWjfygKmc 2T949lCYmvFU23FdSfqHOP5dNOAhVW8uLtaHm5Q2+4GpV+EW5uWObSEliUqhD0c5xgHo6iq07hue MPgm0dLghYdpGKxfmqqlq3H4ejQ49Hgv34ouJ89AvFuN/sL7X/VaFIINCmVuZHN0cmVhbQ1lbmRv YmoNODkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMDUxPj5zdHJlYW0NCnic fVZdbxo5FH3nV9y3JhJhA0mbirduSVdUjTYlVFopzYOZuQzezNgT25OU/fV7rscDTMguKEGM7XPP OffDPNH5aEzn8k6fWTX4bXFFhR+c0x/4KwZPg3HcQOkjq+j3JTZ9lAfL9aA9N6aPY7q6nNCyGpzM TWBnOJzNnFoHev1afPn84fzy/dlK+6M1+qpMo9yWJufjyeny78HFBS2/DU6w4rlWTgUmbXxQJmMy TbViRzc/7pa0Ymo859SYHI/ChsmrimluMp2zCfPZiGi54dN3g/G4Q9wvHmHaNc3/nF1/oUyZHXaw lFnnuBQW7UcOQIHSCYpyFRTCq0BQB8JBoBSVyhWA7baNcGwyiTw+jCagtuCnhn341ISNdfofFbQ1 CXrGPnO6lidTSABsxd6rgiWCl5jgJYK10UHjpCloAUl+6wNXtHa26qmWrYZ/BWpqHxyrimpnn0HL vfOk6rrUWQxP1nUYOXtdGJFLa+sSL5VlXO+iZbaqGpOOeqGUUEELZ6oEaWJ416pNQHA+NB774lrW wGGIQv28WPd44BTFDIJBWdoXiXuIDC8W199/zBfXM+H4X4bubUgmQrLJY65ausjyxtmm2Ex7gUXi fB9umqi3K7cWnm33j9L+Lk1hW/PwoNiGMSQ8hXkt+boD2NNrXwcKe3RoVzF3rXlZqbyf9iikFZTf 0qmMFz3PsWhy5XIfzWKTuW2ssJaaLnRQJbVJbxxMukfTXkyu3j8M6f6vm29YeRj2+MrTBPMwfc11 9hpQWAG2tiaXRH6+my+WUm9dJUZWCrmDYTrT4cibTlWn8qb1ehjLPdbRMWaGYo/1GtBEe6u6NDVe 1tDubJ65tDVKAZqOzRi9Vie7Dh30sb61A8Bqm3KLnBeOuYIen/KPQfFaVaXcIzvfj/DpqN9XKnt8 o+mPFKOf2wbuxfnfvoWvghqit1CSetPYoNdp0yhZ1xtFz+ywAYUSR99uxBzModTetQob2qjOf8cZ 6+fYdbwD2+WwdvysbePfwBi1BBJMd1KV3r7BpZWjRccLFKOmTAMDhkIEEm2NZA8TFPyTacBtZaaI /Xn5ltF7pXt/mG4TTDfivBS1lYbOVFluqWDDLs5VXJQoUUWTswrkAieQoCu2TaAXjTmGzzbEGYzJ ea0NDkqj5DijQU4F+ZbFMgzqkfHfdtO6FrIs23Ptu297c5IrcgfC2rncWWliCGsMLr23SE5hqBYy viQgqtknoTVDxc8THctoSwqtjtrZ3cc/T9NtbcOmXwGHBZByi6ZSqzLmkfsBIoG223YCRe9Ou41Z FbEV2qOQ+zpJXaOMpbCz0nrumsjbxsV6T1i19V4jtKTy8jI2zg0E4zbfHv9iuf5VaxmRXxsk9HIY f7kcbbq/lfK8GD8A8Xo5+I73v1euAHwNCmVuZHN0cmVhbQ1lbmRvYmoNOTIgMCBvYmoNPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5Mjg+PnN0cmVhbQ0KeJx1VU1z2zYQvfNX7ORSe0ZWJNlO Mu4pjZRWmWaSyMyp7gEClxQaEqABMC7/fXYBUBJlGZIlGVi8ffv2g48wm85hxq/0LZvs9eYtVC6b wZ/0V2WP2TwYQPqSDfyRk9E73sjLLN6bw7s5vL1ZQN5kF2vt0Wr0V0srSg+na/Pxw5vZze3VVrln Z/BJ6E7YHhaz+eIy/y+7vob87+zizfR6SjfRdbW//C1bLMIu2S/RSatar4y+g3xHkA06JyoEpQsl hUcHfic8fSB4KySCsXT2E51XleB7hDefD3g74WCLqEGapq3RYwFCF9Ba81MVAQvBBhrEJ6d/IqfB K2ExitKy7thc6dLYJrgBej/tkAAsU9DGgwBnOkuUnshraTodnZFJwknHxyh+Z01X7QKRtZZESvv7 aCZr4dyI1p7O4f7n7/c5VAa2Qv4AbwKOsapSms51BZv1ElzvPDZRty1WQh9RGknHgQRRyet7Pahk oRE9dA4pmh5012w55JJVCXQT0o5irdllIfyghGNKwkm0XiidktbhIASBEBnhPZFnl3WdsOiAbVvj nNrWY8UGZCZlIjcWf8uJFIWqe/AKi314SRPWgWqg6TRXEeG4JMt0VH+sdWnq2jxxJMduqRQ3q2/f 15vVkizsSaG4kOknVddEZFSBScRiyPTdyB/3DzFbHxzdJeb7w6+mVrIf7aZbQ2v4vsXJvnrWy0kg U3BedSTfDhgHXvt1FOQpNVoDKsSiPKWRv1C2QwZD+ckdNoIFpBoquCIoX/gCmXLcRQFYlWrctwHa nSUkioL62T1coHu4nJ4GtP6yXH18We1cNQj3XjStg4eLJY0L6Xlvwps2/VzpIv7YYGviZvR0RrT1 QN8S3n43KHScsNP7TCXMttRsV1E5LruGik7RJIt9GnQmwahY65cUTV5+j6Nii8M0K1jsNP9a6gfk DLkWJfGVoW/1KSmlnRd637gD9DOZaX0wuuRDMrZxEtEdh7Kzyvf7m6xK0wrpQ3YPd86EEkQ7k1Ja 93G+xcI7KrNaOZoLxsfpmsqTHS0PrXHG01F5RKg0ueKcCgBNR8hcxYOGlI2SZVNupBkJa0osJmTT ORL6sVOWtSDxutZ5GlhNzPSGjogUu6KWORfkXxSMoSdpjPKV4KZ/xZys2nYeT9srzGoSlifdmRi9 +IGa3dzehoPP9MygCu/h2Vr93yqqEPjU0WS9mYQn+TOjf77yHLpe/EuIqzz7Rq9fNw+PbA0KZW5k c3RyZWFtDWVuZG9iag05NSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyODQ+ PnN0cmVhbQ0KeJx9Vl1T4zgQfM+vmOJlQ1XgSGCPPd72FvaOrWWPS3JVVwU8KLacaCNbRpID/vfX I8khJqkjReXDck9PT8+Mn+nsdExn/ErvWTn4ZXpJSzc4oz/wvxw8D8bhAKW3rKTf5zj0iX+YF4N4 35g+jenyYkLzcjC8rby0lfQn11YUnt7/Tb9++fXs4uPJQrm9a/RNVI2wLU3OxpPj+c/B+TnNvw+G 2+t/KucNrmdaOEdCO0OV8RIfq5aMX0lLC5Gtl9Y0VU6qKowthVemOv4wGI/7WKrKdJOratlBLEzj CRiUmapQuawySVpupCZjyQIGR03BJ4D2hmOla7TfDXaK65NJP9q98KvdM4xUSedlTtPba3ItPpZu RAu5VFXFoV4U7ojB3lO38rnBveClcFpAEmqc5IQDf28FqDeOUW7/ur75SjcbWflr4UVA7dHPhJdL 1tRJZG/oCCStcN42mW+sPDolmgMTgnua3ZNWgTOKx5Fm9z0svxKetGHIPFx3prGgElVjXkWhMnoc 8rfamg1UtghccRneIUmaRmFL6ZxYysfjQ7KGxEY4mhmbj2CDPH2+hZzRJigt0orVliRfRVnrQ6LW MI70LmBEK+2Wy0odszKBG+DYIb5H+nFoaj4sNMgS/YCtriLDHlSikhNiyFBLZdl/PSyHLIKFnRdV lPCtiKizyHMV0AIhyB4MgC+4bSPbHhbKVrP9cMmL7P+tOkO4XNjcEc4QesC2IacgSw67eaHJqSVc 1zDrB/Tz+eTy49PovaQP/959x8GnUfiUkJ6uDhTx+j0sZ5us82V2O51zA27twrxEgyJUXmXKtwdK idv75hlRYU0ZKrcPmFkZm9uvlOsJl+5OrSQq6IFxYGoojZT25TjkUD64K6PrKp7ToqXaaJW1MO7S SlkiJRdNnKPMBxIrhV1L6/pxPm95oisdu41n4JtT4ZOY317qHxwPn16cOIj4ZkxFVbQ7mgWb7XT1 CrkspKy6jo+TIgkInzUsTTy6a/9StMyB3xACCNuGGFEu6zgMKIzsYZoEUaVujGC3vBi75i54Wals FWe2Vpw5gFcGkwpKCA+zr0ArAX3GigCr0DNiDdqLNs0wzpb7oqlNHKC5cpnZSLsNuZ1jXXZpxrqV aXS+m0MalwDlBHFBLLQMARpvoIDc2R8i/9k4XwbeBRVKY3Eybz6isMkwxmBP7DL8zhALCL0mfF2E 9SayDHVPWNwVzLREzqqSj0P3eLzNA15DrQSmgPVdSkGedaKbYiesxDwzZW0l+sypDQZnZZrl6o2G 0Jq6VZ+oUIOW1DsJhlKwTaLgIWwN89VWsRJdNQzvUKMRhNc4Jl9j0deoocOWS1AmKIAtLE+0KpVP 3kbbIG63WBAp08bJzvupbKIDqY1zCvXo98+sC8iNB2obAa+lJg0tGXRsXNqwOB5o/0Z3/8zmEKrX PzFTVQVLZaiT7weLS4E17z/LbJtJvtbgEUPF5Z2gytLkQTWtexFTPbvckqqd5qHu6REFJ0V42piz eafbh4ikzi2Gm/Nq2S28eDnOPo5wpEwuiyvh21oejbgiXQHxw6jztPdWLeDY5Kx+lm/90q0rfvYK Xkq0u64P5A8VMyQRu8/Y7R7eoVnCdB2ZHbPF1bztE+YcsGIKQpvukUtgCrnMqrrbjxcXQeo7PG2h f1ra+7t5rcMG/9boli5G4el179DDPU/o8/MnIN7MB3/j9R9YoZ5ODQplbmRzdHJlYW0NZW5kb2Jq DTk4IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTYyPj5zdHJlYW0NCnicfVVd c9o4FH33r7iTlyYzhAVC2k72rYXu0NnOpsR9avogZBnU2JIjyaT+93sk2WATWjMBR9I995z7pWea jKc08Z/2l5fJX+t3tLXJhP7B3zZ5TqbhALU/vKQPKQ699wtpnkS7Kb2f0rv5jNIyuVwpJ4wS7nph WO7o9Fl/+vh2Mr+93kj7ao8+M1Uz09BsMp1dpT+TmxtK/00usZPuBF0w11TigphzRm5qJ0gqcthY /qoEd8xJrYgXzFriTBErrKaNoNqKjJy+epNMpx2cEc+1sI78saoyujKSAY/xgPGyE1in1DAu1u1J bWil9niT2+AIcH0gqClZJsZYns2Cl7fj+ZiGNtSCtbYLYbmRld+5g0APIaxlW0Fep4cM1AMbL9Pq 2nBBOg//OYQ3l3wgCyYbUUixh5nSDqp9AGyldS6ycYxiVZtK2wPMn0R1dAALpAKwJrCDmfglYaW2 tJEFImdYQZUQ5gBQBDy7k5X1WdImE8aDgJXMmwCBGnnR5okQ/r3027wALxtYY7+FGores0JmnXSs MIcDJejshUKOOK+NEdkIMZN8h4w0Xj/roAS2pWuuAz2ESCoOx8r1staWWq6LQr94fVLl2pQxfYjD evn122q9XODESUF0URskpI2gRaFl3rzVCgk7o+vt7m7g2bfHagHYg8u7lvpx814XkjeD5XanXzwj gERtq8UoOM88UxWZVh3Gkejh6ek95bb6b7H89Ht2qUQiHhwrkfLHy4Vw6Em/NvKLpn1dqiy+rEWl 4+Lj1XiA0zGnlf+WuURpPF4eVkOD9/Wd2nsqvnNJ1eUGttexjXzCyrpwsipC83BkBVXFyCLNhfhd NKKXv+nLt4fUFxNWitpnUJ7pn/VxGjB1Skoq65iKtYy5c7744vNRq9xv4rBhoc1g05XvwdJHpaww s0KCjzZnpISgxUCd+nporBNlOze7mePbHQ1OG+12QeZDbEPvaHGspDOeeuURodoZjaHN+FMAKGsg YxCILoZdP0s7iFk7t0Y4U9vQXtL4WCB4dWWdEawczmi4QiOcE/n6hrA7XRdZ737o3QkNXAsuT6dr fOIdYdvZ6tiTUHFytXOrnVjnWNwzRLM/UJBVBZfwb0MWcHHpsqyV5DHre8m8ojMsusEyAomtVMqf fpFtsszhzpJbnylUfi8VgxiHRsCut4/9vfSjdMEci3hgIrYad7IVLt6iR+MLaDEMmai5q4248Jpv bwPRL/CNpm/o1YNUSIPe+1wXDc1H4a5/dej7vZ9kN/MfQFymyVd8/gdohKD1DQplbmRzdHJlYW0N ZW5kb2JqDTEwMSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyNTQ+PnN0cmVh bQ0KeJx9Vl1v2zgQfPev2LdLADcX56Mt8pZr0kOK5tqzfcABaR5oae3wLJEKSdnV/fqbpWhZsoNz ENiSyNnd2dmhXun8bELn8pe+s3L06/QDrfzonH7H/2r0OprEBZS+spJ+m2PRR7kxX47afRP6OKEP Vxc0L0cnDyawMxze3Tm1DHT4mX7+9P786vrdQvujZ/RFmVq5hi7OJxen839Gl5c0/zo66Z7fb9iE MU05sy4fkzJ5+v0QuKSsUN6zp2BJm6yocyb+qcqq4NNfRpPJEKpS2ZqDjxg2vLDDnqV1pQraGnJc qMC5QOGZwOkcoc+I/rCBb4B3kNRgd4qeE2AZWK+1dshLkUeyiKeND8pkTHZ5jHSngsIKUnmuI1rM QQWqfZsQIDbc0Ow7aggvchlUFgZAvWTO8ODiolf7DKFz5XJPWENsMtdUMY4wkeuVDqogr1dGhVqy fkLHLi8+XD+PD1l8+vvxKxY+j+OvhPR8cxgQn7tDWFo6WyJNVIgszYp846WFnk0ul0L69OHujb6V 7L1a8RjF+0SIKoq03wNyY4sNC8epcxv2Qa8iFwOOai+BFOUM+l6wAzUc109CTF9k6JBrjkh9s0a7 7Or5NHuYzgl8o2tCu6qRnAk606FpVXBYZ2JgX29kTO52WJWzG8jS9VjTflBj2ryr1SD7DRe2+r9q JcTDt7v7zwOk3GZ1KRPwRuUC1deR30k+p0VDlS101mBYV45ZIHw7uDl0/lZ/lVuz88M4M85qJ1Ql 4AjTDblkrBa6kAWQQ0plIEpZMwgmUxNB0KRYcV8nMQwuD/iTdVW9QDm05mY/vHI/l92m3S1ta/UI v5j37INMXS6i02SOlVgVuNJL0rvp3YpfKJo7lfH0IAcIGhrE7liil27VRmONwQLaajTfpDIFapCA 2FkjJVQMbjEwHlNTVZCN7NCObutgjS1t7WnWTuKPk9vZj9MEBrHtixpYHQoIL3xE2DaKAEGhAVVY s+pRteWFsI4jYmvdulOxJ5+MLkqffV3s8TJbFznVAU3+l3tYXpXc2mBKxHOILXU1sokujiz9i65a u2tzhdR3XtCNV3ipRVG5zlpDUqYh2KrspqDWbDoq20q1FCiuwHmCSo4Daw/QpFoUHNW1wOmSrKhz u6j/nmLgCq3b7TvnU7yDZTGsr5CVRoDWSw4zBRcJSsli4TGpvEtejhc5nOQQEgcFhGe30bgsGBbR m9a9BHQ82eEXcaQ171JEWo9/zeYyU0vtyn0TA94AlpgWZFfDpJsOCr5j4vnamZqvfcWZ3EoiWzBq Ex7Xw24IdwlnH08qUx4P9z2OhR70rFQNcMUuA7wP7QtdTkICrY3d9sdXina2Dq2RxTRt7cARzmYn U5doVQFHyDoh7b1iJ95+C7ED+N+TJ84i3Lflw9vvF7c42CLpJedaVFUpF8B7S/dCXK+I/dto3u5x +wO612ZnHhi4il3RJAr6p0zfdt+fXSOdKVfW7ezpjn3mdHT5GxALLe5KBFG7E0IkGhmOlPbIDHbg wGnuo0YlhlAT35Bap++9cg0i5Rb1G7tLKR0IwyGwwk0chTHeADOuYjJLXXASRxuvb5dggvVGOjds P14ybKajVuXAWsC1haPr61jGI6SMljR09Ln/WcV3vi81iL4axzfao0VP36Wiy+tnIN7PR3/i7z9/ rrLfDQplbmRzdHJlYW0NZW5kb2JqDTEwNCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDk5OD4+c3RyZWFtDQp4nHVWXW8aORR951fct00kQgNJm6r7toGuqJptC1RaKcmDmTHgjcee 2B7S+fd7rj0DDNBBAcu+H+eee3wnr3Q9GNI1f5rfrOi9m93R2veu6W/8rXuvvWE0oOYnK+ivBYw+ 8sZi1Ut+Q/o4pLvbES2K3sXUBOmMDFdjJ1aBjp/Z5/sP17fvr5bKn5zRF2Eq4WoaXQ9Hl4v/ejc3 tPjau8DJYiNpZbW2b8qsSZmVdYUIyhpCnNnkx8/pbDKGhaOZLK0LVEjvxVp6EianN6U1LeXlH73h sI1YOrtVucwpbJyt1ptPOB2N2lNGOh3TdJ+Izy/2ZeDwu9Uqq+OyyUahLmUfXhkimzAd92P6XPqg TIJbRqcOkvQc1HSMpFt8LoJIVd9/e3iY/DNG4WpFYiuUFkstY8pMGBS8K/I43+9qnn4bTz7/vuqF KiTNgyhKT08XYxlkFnivz5uuWU5MnhapE7x+uhx04rQE0ZS/1UpJh3i73UwL7w9phD+SO5FJMlWx lO4Mf1dUeXSTJVBUOqgSTAR28WTBDnlwhy3VBP2THn7OF0kUh03IdMWiAKEBrDdiAtu+lBmAZhQs CIahD8IAD8c2xzFihsExuXjurVnxIRwd+EU34e9lVjkV6p0nc1GUIguxlXufM1VHqhK9x7nmtQ+y SBZcQaQH6LXygZY2bGKFc1u5LGlmvJfpmUwHokihlIkBRAgiezkHYLJFLSyDzLo83YS0nu5woTlA 1LBO8heUpc+VCTJeZEiXGcghl8MR4KQWIRXHiFoaO115urAlGwt9hi2o1+TC5T7KB1S7Ohqn26vW KggNAa1BTuWA+RFT7GZ09/65f4z18d+HrzB87sdVE+n55J7hGR+HpZWzBcCroJI0eLD42MQ+CPBN +4TWZwhKdh5UZFJt2ZuZcEm+FWufVSvNVmpbIhDAtYV1aNqhOddQdjokh9O9Vsoh3rJuJhv6vHZS FuDfN9MP8+oM4kK4F+l8N8+8vQpN4Bhmp48ot6XSbAAmGigdptmmkyyzeB9xENu50e3ATtTwQVkt gZ9eZN2YNrwcDu99RwaM1eQoIE2Xo7B+Yyudk7GBUYtWikmde+EWouYp3d5M3I0k5dOR0AQ4dGap JuCutD5OouCACQWxXgK/hoGeZzTM+yRDNogdaWI1yf1GcAPfFAZCulolRrmCyiujUU7afFPIEDub U1UiO9sfVLXXXYcjvLmcBFC8DXyCtot+QFsLqCGPgdnlqvIZU4EqoQO7lZ1OiDzHReT5gfOIEEFu b2PXH6xTSFLTyTP5VSq+v18qXdNtP/6fcWL0+J1B3Hx4RsTJovcDn/8B0q3Emw0KZW5kc3RyZWFt DWVuZG9iag0xMDcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5NjQ+PnN0cmVh bQ0KeJx1Vl1z2joQffev2LcmM4QL5KuTPrWF3qHTzk2I+3TTB2HLoFtbcqR1KP/+7koy2IaaIQhp dfbs7tklrzAZT2HCr/iZVclfq3vYuGQCf9N7k7wmU28A8SOr4FNKRu95Iy2ScG8K76dwfzODtEou lhql1RKv5lYUCMNn9eXz3eTm9mqt3MkZfBW6EXYPs8l0dpn+l1xfQ/otuaATJ7VTqN4kKF0YWwlU RsNa0lryYa70BgSsZG0sQiWdExs5BvgYty7fJdNpCxaPoRJ7guDrCFLhVlpAA4UqJQhNjjKV85EN oMbSFn1xtdFOEiBDkT2ZLqPpUyPtfkQ7OeQCxYG1wj1UjUP2ltFtMrYyZ7i1wW2EyoSTjiinWwnP j1AL3PaCpYRpg6BlxvQpS3QEuKXtGA85dhFLIexUWQZ/VdVolQkkj7myMsOSw8adlBpwZwAtUaPD 1XIObk/Lyo0JZzbz+bob3xGpXoTRyVy6zKqayT141j2jQ5aJYOMInlJl5WsjKQ1tantV6cZaWFNR OU+Zxfy0QFmoU9nkklLRFuVQOd1Ua2lHoAr4pc1Oj7iIuURBJc57DsXaNHgGgkMveH8IymFFTD7t C6+tqNHkSrM0ewhdxxyBFE75mlBc2FDz+GQdybRpiFFTDI3zem/QVL6ulcStyV1gy4i/RVWTjGuR /ZIs3YhkvMhJDgQ0FFfMo5clDqsZogz0IlZsi9hEBy4fgpOdcixILcq9LzgNhTcCY1/hxgHltSFR 5h3FQahxYcrS7DjOAdHV4unHcrWY+wYYdl+nBEdpcUPSxdqaN8UR4taaZrN96Pnk4UQ6Wx6dPUSO x8NHU6ps39uOJ63acV9T3C2l5TxOAyqb0iGCusU48js8nUiH3Jb/zBdfuuzg5cL45hPly2Wfaqoq miFIGnBkNZdITc97I960cbnQeVgE7fL65XLcw2nDgCX/VYUi8bxcHHazUjjXDXZ4n6lYkcm2Z67C JOC6VU2JiiWKbODAkG6BVV3KP6UmePkA3388pyy5o2CLU8FyvYUeslHaodBEyBTdET8eJpuez0YX fEjGlvJNMqQ7TmaN5Wl+6GVKR0Vdhr7MxztnYvDZChka+nr2sy1YdOdlqfg3g/rJx/dsGptJ72h+ 1NMZT12ReKjY0QKR5sE5AgvuTVZCZmweJBvWywMvqhExaodtHDBnnIeR4zxGGDfd9rWy9AMrzLfu D8ERoatrJnt76z18N1aRePdw8ix+1zRCHHxtaIrejPy/DydG/z5ye17f/yTERZo80et/TP3EQA0K ZW5kc3RyZWFtDWVuZG9iag0xMTAgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAx MTEyPj5zdHJlYW0NCnicdVZdc9pIEHznV8zbJVWYGLAPJ285f1yRSi4O5qquyuWHRRrBnqVdeXcF 5t9fz2plvnxQNpQ029PT0zPihc4HQzqXd/rMqt6n2YSWvndOf+Jv2XvpDWMApY+soj/mCLqSC/Oi 154b0tWQJhcjmle9D1MT2BkOZzdOFYGOX7O769/PLy7PFtqf3KNvyjTKbWl0Phx9nP/bG49p/r33 ob35EJTJlcs9FdYRm8xt66CtIVymXC91UCV5vTQqNI49PSLVeDS5fOp//K03HO4hPf7z4zsCn/rx W0J6+oKw0WgvDK+bY1gqnK0orJiuH6azOYHJwz1po4NWQZtlvDWb3hynxKti79WS+1Qr7zmnYEmV gN76wJUnxxnrdQcxNZnO2YRfDbstwHYwjZcYZaDAmktbAwlFnAoweKccCdwXTrK+NNoBY7Gl2pY6 2/ZJLR1zheS+32qrgnqvHuWe2fnDPHNwrx1YOUD72hrPUuhJSZ0aBBsomnFtXeiuDQ6S/WjKoOsS kem8R+YtLRgJUKcBd/GDItEFYS8RXhciUXckCRi2dUwoRTNUzwcEViCHa5nyaI3w3DWibQ15NjAd 4KY/b27vElZus0Y0osyaoGAAxFenVIUZmqyNh3szuNIKsYTRhQ1a3fbSdTZwXJfbWG/t+MxzQJ2l rnRIoiYg01QLKA7sjpbfqaMNWROhoHFKhRpthbgc91s87RPWZV+wkW4t1QmJHWY0/0LORoLWUqkc Gkb0E4GOglPGF+wSVMVhZfO3fvlGB3EahyCxKyiKSYndizBvx6NK4rpBAhLK19YUolYG9u2oJdjG t0X+v8eCTTieS84C5ICoux5tdFjFgXppMEBgs9JLqeY0o3BOUJuVEtHI15zpQkcvzcVI+6ykNDEW cqxY7IgLlYqz96b3Uol0CJaBbC2K6jt2tGgCGSucu1QZvLiwTXiz/KmbHmzjwFqG9wZG16bNOd3L LzQFF1QNs/hAF92YnAiJsjTWerQLzNFSjh3aUUnkugqOSMmu2XBZSkfTVp+AqPT/Gk5sjM5aXrev GUResj9ZK4UtS7uJc4kmSiwyl9pAXWGcHcAUCG0fFJICQhzsFFV6sbhdg5snflUVpja6LlnmaKv9 ZQN/oTt57Khs1R3A5PjW0EjWj8+by8n48olUnmP5xbajs9EKhzvtq/eYKLFTaBGn992hDlT2YhZg SFgV6nKt4EHpVdhY95zUdaIUrbiM+zvXBYZHxH649xD36ymNdoI/jSbvAe0XPRkMgfB37YNjVdHc qYyPOnWHqvfmM9d4bqiqVeOwNdKCiDBrF+87vTqQBxtiw9xuh+7xiLhdfYm8l42RpcehCkFlz2L+ +7NhPxHD91Ff/o9l/0ENOe3ZrTXKQTsTUOcF59ueKCc7fG3LNedvRo6ldK0PUZDTOkTCz59jIT+s 08qF7enPnNvXWssvlG8NmnvRjz93ToIe72V1ja+egHg77/3C+z+sfRNsDQplbmRzdHJlYW0NZW5k b2JqDTExMyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDgxNz4+c3RyZWFtDQp4 nJVW72/aMBD9nr/ivq2VCCOBtXSrJvXn1KqTOpoPk6Z9MIkBr4kvtZ0ypv3xOzsOIoEOcQglJOfn 996dr32BQT+Cgf34a1oE7yenMNfBAL7Qdx68BJFLAH9JC7hMKGlsHySzoF4XwTiC01EMSREc3UnD leQmvFZsZqAbk9urk8HoQzgVeusd3DNZMbWCeBDFx8mvYDiE5CE4sq8ujGHpM1xz7TGfHsNocy39 jjfuh829X/ik0uN3QRyvAaN+84rib5NHOVG0zqFQvERleOZyMm54Sj/aSHG/reJOCiOY4WAUSznl uqxhJ+sBU5uDSsyF3Nq2FWahsJovGqRuVKU2irOCZLeJjTpbYhiGieU04S8VGRna+NzAfuhvQ29G 4tX8h2g3Gic6hp10djoPPaGLyizIkD/MCJQhNsxO9zA7wMpu7LG2G29aPd5DcYf1a+PP9qzthINp WVv386ANcx6uY6e7FHiYVw5yA8sjbJ6p6CApvm5s98k7JDRWikxBCTR5lqjsof7e4Ra/6Y9Vpavc hJ3AnW1xK+aV4jD+CJsFhSssikqK1LkLtzku/epLPkPKZ/U4AJp7oqldj/qPw+TuGvRKG16AXmCV Z/DKlZitQMyAtftZSG2YtEpnbmkNiYrQtShEzhQNrJoP7SPRAEuNeOUkPWnStedVsBVMOeV78wQN bqkp+ZOFVo51D0qFryLjitA4TUGDdg2b5gTW2FNPRSiR1pOunF5Xek3RKyOO5I50KSgpqdm3AVGM xPXtzKCNi9pFXaULYNrhPNUsmczcHwEh65SN9J6HYlpj6vyFkhqLG91zyyyKkCmpkaZRn3EtlJdD z4ggfYEgGywoqRaYOTWi4E6sKoQk8OkKWEa3gmYCM6h0v9Vx1vC01RQzagoCKFC6FdwKY1Qi2HVA W3UvuNZs7ppHW/a2DGgWTlKGS+mnUsm5WkutxyHLvRLfF6isx9RY7e4lYLJFNC3ZxVzURfBQWDo5 RMKwZ1sS12X0xG5NdS2RrktB/Kw0e7IaAXUfEsxo5KR9JZJMmdX2ib75XQqCgvsqX8Go5/4l2Er6 8WhNGZ79JMSbJPhGn39RoT8RDQplbmRzdHJlYW0NZW5kb2JqDTExNiAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDEzNjM+PnN0cmVhbQ0KeJyNV9tuGzcQfddXDPJSG3BUyXHrAH1y I6dQkItrqUCBOA8UyZVY75JrkitZ/frO8KbVxYUjBLZ2ycMzZ87M0E8wGo5hRJ/0kzeDn++vYekG I/gD/y8HT4NxWADpB2/g9zkuek8P5tUg7hvD+zFcX13CvBmcTbWXVkv/dmJZ5eHw3/3HD7+Orn55 u1Du6B18YrpjdguXo/Hl+fyfwbt3MP88OMM3xqql0swbC6YCv5Jg5VMnnYeGbaEydW020LWwUX4V Xguz0c5byRpopaRd5z8NxuOMR0tmd6D02tRrKaBzSi+BaZjqNaKqJfPK6HKINyC166zEjczjOgQj GMbDMozFs0eJv1SgDe5yrdFO0nMruVR4whDgq/ErOqXFZ3UnpCMWCejl+CprGuSpvEJKxBG03MDc Mi7v45IEsdi2zIUwUnCBqpBaYXw9xAtiycATAjHUUgpcsZBbo0XCCltbo7RH3jcaiZOEbQiWBF9I 1NwG1ESNvhlwUoudOi9qiTojv65NCUoRH1NOOHkn8pbadMsVHorHNxF3wxzgEciQNhkQynF0YID0 tpPgTGd5ETqexbxn/JFEqCrFo8gxGq7wfA8rpkVNYvaOGiLG5WW20ByXt9a0qExJOMW2lxsSmEH6 ctP5FSb63wC2Z8dGOseWchhRTy3PS6CW3vXTicI/ajS/qkruZEruRtU1cKPRNx051wbt6L2Wz36n P1brxthHPH0a1LFZrEAeY1zUstmVVvGR6/gKGK2pmKpDdRhYs1oJ5mUvfwK97VkNTi3R4rQOSQvJ 7bb1+4gvStUTCb78NZuTAx3lCU/cFwPzdrIBPJz1FdoCQxpobDBalj2ONfLhnCJeK5ErCSEc2Wy1 DV8TiwTFTVeLgLMIbuD4NhT7jXNdEyGY7+Ukp0Nc5BYihKIgUZ++cVxf7+QuU71OoE0gZTjvLPR7 Qq6jkngVq6RldJLpZSyWTC6WXCVW1phYkTXPtYLRftO4muVtyiWYynRaxKy6rvaFIPqqn7zj5he0 wo0ZSEgcKign9altbhaBdr8TxLyF1rGzujC8a/CwbGk0BdMxtts1Pp8wzy4wu+j6kBxs6ZFfoPcG 8S1DuTpOxn0TKzRhneJAJVM7gwMFeSCqDj0xZSDt+7/6dlmUSllMFRLEefhwVkQ5mhfo12zfGoli MTvKUX/jQSk8nO9FcZwbqUNpIsr3v798Tt9+lI7fS1eplKLuTgm2MJ3fb6rJHywMiW2anml2lu5z PBGpuwRdcs+gMkfxEFLx1GoOwkDvvELsYkSlS5X9BmHabZRDEG3KCML0H+2LnE/X5OHaBFSqOu2Z eeyIxW6TMPqoYg7bV7xH7JTGq4QrR9BI5itj4gQiOfPNhGayNy0p1qgwivuNORd26FB54ueukKYC VSHwOmOvZMliLs7WYIvBEVEyeEQ+cnORdLxG4C3Ep0ZFBZKb4aEb05Gxd+4s0ZvE18MxfjDP08n+ 5L19Zk1b51Bprsr4BGoVSoS4VIfzesGocI3eN66VrbF+b2RnsHJ1mH6b3H4s7SaPcmSFsxYvj5QN jhVKOmx6I1aHu6AIc7Sl+4RVlCQqtgNqWZPOHbST6eTO1IpvI/5wP9gl3j7jDZUyHAL+MJvez1NM 4UqZgCZmli9GKnTTJRZFaUhlaszu0hF5njD36Mq1YtcbcV/v8pGTSMW/Ymu5N1myN0V0mn3FNDoI 86RSyu1aacbysj2RdlRfyFbx4Is0Fa1cK4O1KRRbWtakIYE4V1fBBF/Qj8z67fHfMbfPrULp4FNX b+HqIvw9c7To+x1RvBr9QMTb+eBP/PwHIV+G1A0KZW5kc3RyZWFtDWVuZG9iag0xMTkgMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMzc4Pj5zdHJlYW0NCniclVZtb9s2EP7uX3HT PrgFrMRS3KY16mBZnG4umiZz3GFA1w+0dHK4SJRCUkn073dHvVhKsg2z0Rglj8/dPffckXcwPQhg yt/mN8pGh+tj2JnRFH6hf7vR3ShwBtD8RBn8vCGjd7ywSUb1uQDeBXA8C2GTjV6tlEWt0PpLLRIL Tz/rj2dvp7M3/laaZ3vwSahS6ArCaRC+3vw1OjqCzefRK9oZn1oroltYorFjoLMaC40GyVkM2wqC 9+HB9CA8eHsMf74SKobrKz/48/UBwOYGwatPvx6PgqBFvNaRA0oFxQsyJiiZSEKTCiydWaMpUwsZ GiN2CPgosiJFEKbzdXRMgAzF/qSSVoo0rdjCahFJtYMozQ2B23x/5g2FNObgnPO92waqcb4hAFzj XUnpMuDZ9Wq98T9erv3Lr2t/eXlxuvoycX4ZK/xXrPVqCXEelRltQ5LrFx3w2pgsrytjMSM81YCM L8yOSZdKWJmr8YAAKA2nyYe/5DFSvsIYSpBiOuq4bYBK84/cch68LOKMaDTEnqUwBymR2zagU7by o1xRSe1PAYmXvuG4yaICg0JHN3SEc93zPuHdtmADR5moYIsQyyRBzSTZG1HHSU4oc1uiiipoPDp9 dTixZFZEOiQ0j6JSa1Ym2gdExYSELANHDMFbzk7ltqtUlJYxxk6wLXkcAKnnXkYIhc7viQw9zCk8 DI8deQ8dO2JLGiVHVtxizWnEAfISJYt+KjPJCaLUrNIkkVHTI6zJiQt00pN1HYwit5mrPzzkZcp5 cQOmlDI5l/amdlVQmIWW5KduwgbnXqSSUgPMhEwdak7muiO0D08C0Uh0liwM04TG2mqwnMKA+ix/ MJ2YSVqQJyAgKbkB70py6EQT5+RSQWO2utqXjWaHYVK2HbdxB3d9RX5PVUXCKArWN2Hjo+Qe2DUI GlMXr7mRBcWh86w5WfdBPyMuBm0pkeGkTbllOJY7aSlbI3fUXqVGuEdNoUctGXuYPW1NU1Qusra7 rC7NEybNPjNh2wKlLXYqqnoymbIocm0Bu3oRndpw0nyGpOkcEhmKSuKGiHFDgkmCgsYq2oGzbnTY G1pu5yZ5QuXUKYhZHpDYFQA1h10PctcpnfJs3mA1Nr2DLqH6UjB5qalJtkgmyNJvh5Ku+7GbiPtm GO+7YexMh81gyi1dYcxB22xTYoWEB2E79LeSOTG37UxrEjUUBonzgKzCsL1rVrVJkrNuObjGeNJK 99sfF59JBN85tB0q5OhadQxurU4ppkGr58SulLFQ0RAroMABfqdictI0JWm3Cb6zaapv+qOM/Lpb Id3lmno7cxP911M/oL+XXz8v4cvlhrLszfUJDSqEb3y3B+9n310nJaV2co3RUtubHiEfJPVI4msZ z/luesxSZebd2sIrtZpLtMm8EFpkZk4G876FT+PeG7DS//Tg/gOK+PFO6iyGIV3l1CYV0M23qQpc eP3Z7jVpv/QZXpULr7tPWzcDR7WXNe64Otr9LDx6PWlxRoOFiiLLzDt8cnLO8+VkH0OzetpMNGpu pKpVC08W9zOfB5130t0XHw4H1nvowxewe5Fu6t5gMsA6Rur31PPoVs20oLLywFt4Z+fP3i1eL/wX tn8Mp8d+8DS0PbA7/eEH34fV5fL8o79snzbtJcoNybry/ZdyWSPr/ZoeCJloe2Ph9aQwNKc+6RzE de6kIY+eLkJRI9f/69fjSVCpYCNU3vOatSlR7eklIqNaMwox9m3u36r8wYOi1AU9IReem3tb5vyk L8D/S/ts5lrmghpbaFs9l/D5YyF5uHwq6SKdTdxL/JnRtyt+tc2C74R4vhn9Rt+/ATV+xswNCmVu ZHN0cmVhbQ1lbmRvYmoNMTIyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODE0 Pj5zdHJlYW0NCniczVZtb9MwEP6eX3EKHwBBWsdN0xfRClg3KGIvdOETQshznM6QxJnjFsqv55r0 ba077cskkja2fOfn7h77zr4D0vCBLN9VyzOnOenAtHQIfMD/1Llz/EoBVg3P4H2ESt3lQJQ49Twf uj50AgpR5rwY50boXBhvpFliYP+ZnJ2EJGh7N7I8kMEnls+YXgAlPn0Z/XRaLYg+Oy+2Cienk8g7 u5x4l18n3ujy/N344hklHc9/+dzx/V3lN02pYpH0xzmXscjNeDREnQ3Um1o6EkZwE8lMDCkhgUco /iJK+0GvT4NXhPQJWSPt6FqQrg3TNiD/EGirasGZiEJZgFp9Sg6AdnStsZVcy8JIlQ8/qtKAzOcq nYsYOzBS18CMYfzXNrytugXtXVmKssyQyXvSjXycFYwbKMVcaGkWAzdVv13gKitSscQcuAmTqYhd MItCDNxYlW7zvqHmg5ZWdk5UbpaGtEoRhWvBjNJrUKWnLJd/2dKga/dzNf+CIWnYL400M5HzhcdX wInS4PdogzRoo9Xew2geglitnGYYrBX/7RZ7jVYr26hY2bHxcDpHgkbMMLsDZ0j/nmS7VRelERlw ZsRUaVyqUs00F/uE7cy4wK9Fut0ccaxxzXYgZTEPPIbD7vAYmXurXkPYfGg+6MQ6KKHnkguQxY9C K6O4SgduaItpM+UKk2fY6nbCzUpUI8c9WNk45LW5S+yjaccyMBXmqWkPO/8j7V3ylJyvhZYsWKfP nwKLeVUodmrWrZzeuoAZVxUsjbR6qcyk8W6xfh4GZSm0h4FMNihg8ERMJAeeqlKAUVAn3rHQjuNu Ksc2CnuYE8GVjo85XkstReTRwQFEtwLGV/MAsPz/EstDhqezGA+Z36yEWVmfNgaV4groBgfqc+f4 kj9s8p7v42VGxXXxr/Z+7YU7DNoEnzalLO7Z3F5Kk4SEPPATTliX+IQShl9se50wxrnYbQkc7frE jhEwv4VmqI9YLA47lcUg7IZ+KMIbvJb0wqTTpiQMsaWUIEYQVHeUc6Ul3gEW+4gAuKISExI+zdIF BK+rm9CB0rcrNhUQ0O+IeBo5X/D9B3OWjZMNCmVuZHN0cmVhbQ1lbmRvYmoNMTI1IDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTQwPj5zdHJlYW0NCnicpVZtc9o4EP7uX7FHPlw7 rbBkjMEMdCYNpEevaXLG7bWTyQfVFuDUlh1JBOivPxmCwQauecEDRt5nn320u5J8B7hOAOfXwz1I DNNrwUQaGD7o78S4M8gKAA+3IIH3vga18wf+2Fj7EWgTaNkW+InxasgVE5wp1Bd0rKD68c7PHGw3 0Y9I7tngI+UzKpZgYWK99m+NRgP8T8arKsxpOKRlOU3HaTWdwAlaroVXY+LYjuswp6XHttN23FbD wk3r9Z8GIQeZbMduWAxTjajYumaUhmzc8ViQinCoWPKuCipD+lTRCqQMKBk3psE942rPtbs2/hVJ lYpllbVkzJUBDVSU8l5NUMVQHCWRQtNUqtq+5LWvDsj8KGHvLIwJwi4ito/bHeJ2MHmDcQfjjb4C eYRpyIMo1FMY9oHThPVqZ6Oh56PzSw9dfvFQ//LidPh5XwfAIdyJLhsix9K8DXV0WkwGIsryXOxH /JyqaBwFNLeC1DygUuBsoWCWSSUYTWB0BUGcSiZyE3GtOq5b9UbzmKDj4TaInRodrP5+gauT3Zq6 5vCyPzhH/TSYJRXLygeJKOx8u/hUAnT/QAgGPIR0DGV/iHgQz0IW6j/g6fohtPUYKSpU7hMyRYOp BmlikNGEUzUT7JjvTjFWavoP3qPCMVTLTHfJIolrkDDKIz5Zj3ZiF+CNZkh5vITwQfhbmEdxDIJl MQ0YzKeMQxESkboFemvJdPtreTnpZl6h7GypdUguO6Hs1aZKZR3TnM/n9XmjnoqJqRcFNrFrakyo p3xSK/mzcMjH6TMJzihPuW7COPq1asQLpqZpCKfxJBWRmiZH2IhJcM6G2CJAAbH5SW3bMk9SYu7n 4tEasL3hQUkq2ImQFMkpbRLr5Wo8NmaCcV3PL96wV1u3qi90gT12N2NSDRaE1Fdt8/sIOemh7Gs+ LsepSOQzy1cQ/DZbJQLG71mcZixExQp6ecYeqcX3TOK6rukNztAio2qK8iEhxHmuhELBtytN9zTf akj9e8hPbza56raZnyky012wc4RU9kFzs1VekxuzOE7zwfrY3f4rP8835euclNx0zc1s1nMzd9P7 jOL/33J9TrVLemQhqB9N9MJ45PItEetVS14mqQj/lcazp26n1m1y24qbYjTHy68/zPv439Oc9PvP v83v7+c/ezsnWznONh3FfpE/su3Vy92FToA+tpaw9xksskgwCR9n+hyx367eL/dA11d0wsBu3GjG gW/8o6//APT2MMsNCmVuZHN0cmVhbQ1lbmRvYmoNMTI4IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMTgyOT4+c3RyZWFtDQp4nKWWWbPaVhLH3++noJKHSYobawUh19zUHK1o3wXS 1DxoR6AF7YJPPwg7tnM98xAHFSVVn+4f3fxb53Szgj8gK3i5Pt+j8gUyiVXWvcAr/vHNXpoX5Omw +nyLyhVlP5x2i8FOXz7FIasdsiJwdGWXL78IVZ+0VdL/xrRB2q/ef0yO3sL45rcw775bW4lBNQTt bYXCCPqrfX7BsJUtv/zyTyjuPlp5ViWxUKX177/+4wVBPq18Xgj6oU3coBiS1VwWVfcx7t5+OvX9 9SMETdP0YcI+1G0GoTAMQzAJPXziLs9+/mlB/SIKSi3Bu13oXzYuQTKZ5VWueqqO2CVhs5MxXtSH R7F2nb113tNhbtudB5TUs5vqYDBGZN1FFvPmWN4UCw+eBQHy+kN0hcNw64usJE1SHe2t2ezErt5D 56OOYqx6vykdq7TuqB13/o7PMWLANp67Ya8T3LUNnZG+ufAKarfBm+2BYE9xDMfCzY2iw02zRkdQ GE6wk60qIncinFt4gslBhepzgBUXxDngDgbVDEqH68Dn+P5YTQvvnMh0oJ20DrK4rEsctLu4rOz5 KKLVYxlb3ZpgN8k+K5wguulS6Jdtw5eNYA20iaRHxthIuLaLTKIi24VHFPVk6Keuqfr2wKL7HcIK RKkQahI7bno14tRPJPD2tvh+kfKrYk8NFiGl5LbI+wMKLtHHDUwyQR/8jXBrCM9J1KtB+SNt9Oxg VgGCDBjGZC3rjbYE0/5XUkYforp8pdVPhlfNeWMVeqXRtvaqLY+v8tteu17yqq+rV8t+U8Ar/eZY n6DPf+xddn/Kmk7aPk/zKOh/JGtFEJjiTtOgWmdgEiiQCSJQ1voVHotsxPcKgHnaanhLCDHGYCnG cICyh2f6DkQqU10KeDYoXFsxumdz0YbHuIYhsJOoGjZrKRTgAeKw1KyIFk9OAVoMMU8OijFNdPb0 ldhJ5WxHmVkb6J+YnU2zrrrwjBulG4ipKwY+MeDpz7CTyzhwYbkMGylU/W1+IjA91UBU0SlM4B+Q s1yqY2iDhJvg+Vmvzd6U82XWbANXmVPwsN8+2bwvtv9X3/vanrxv62P/Wn3va1t4P1bfQz9LmBjD E6XaF05jpIKHVguPMgCTZawOmIePUdOPZwoo54BuDsXVP+PUtnRCqmf1k0LaJ1d3svOwLo6ykMhb mIhOaJpmwJkuRJ8nC8/xstb1TgexSa6mE0znwVJtrLypyqXpj7PcoyrcXddoh5A7xOjtM6DKjEDV XMqKNV8P6Q4y74fYPSIW+czPrr3Wd/JeDjSdNTc9JV7vTRMO9zrW7j7S426CTOQgx+XGrJqcDIiz wwEyyHNSAueozm2kQLLb3rjpz81tJ3hRc1HWnWnzVmbGPD9gCEysnX3cQwE9uUQiEPpWKskGp+gM KHp+E+9TskZRMVZCjNjr2flkbd1qt/DsuVB0sSIMQVOJzD2icGBhnBzUJKP5BuQDvIVuWrnVNQw2 i7MkrcuWKc0UThUaTCwAgRIoVDZx2Wd9TbgAxh6iwLM/BGnyKMpw9mBS3uunftaOAnLTr+kOTkde y6wMOu4GH6tP4cJDooQgU44TSpsjlIDeocTcZvM1wrRdOa+JeYDy7fkStJOHwfv6xJ/2u93m6qY0 VeO9M5XccdDLbnP28XHhDYN46bP0HiT11t+mLgaHFne6ZGHO20o2BlukDiB0b3rnGg8gOgKyfo3F ub8prZQXoTMXJLw7xkkJu/bC07W1F48lNuLAKELuPjvtPTlcsWyjrteYMzCFlEsw4CNWSdYintYK Nd4vt6s8yiYXFaPPD3REWhWUCcJTD2G9z9HLnndk/ngyt5iYDsghqlxi7AjicfIgo1zm0n1OukRx CRWZ3ONAB2OGMKI7CSm4YrXUXKQjoTx5SZaNXOljpmUYpg2+HlLvttbf/7SwHDTfnls/Onos4aYF /iZBqeOhGLofiL6ptXQNDkWpZ/vGNzseNtbsHdE4h7Rojdi6UXfCx9bub3ufXAPKpu0BFTdmTvdu znnldVtwZktrGwF5vn1JKMA3q0FSdsA8zLpVRHA/YneXRjQF8AEzeqjQ0Ec8yDfQndyrPuKmrgxz 2invC0uC+xrfmfsSZstKW3jNdSC0E0yo1QE7ucSRQfEeDQs+aWSkHVTDYZBGkuGaVm+5qB+OB0aI GWGtT6fTrTHu25lTfIniYC8g0oV3tMeNEaMYWcvUscfPHVQ3IdpmrATAtJaFSqcIIvQKeB7TLlrT GidfD+ms8860K9MeZDg2UG4amlc5eu6GfXOGlU3BkBcmHyFhG9Y7IjX5g1K326DTfO4xK0/fjD6f pfoiHTtf6yqp+r+oHTAA9eT9Ef+1Pb9pp6/G/2n5Y5Z+N5Qtps3mOV4/qsiDtr99P6k/fjdvk24l DsVthb8+J/bvnP6tB1mywvH/PIis/WI8rv8Ca1vS7Q0KZW5kc3RyZWFtDWVuZG9iag0xMzEgMCBv YmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4NDM+PnN0cmVhbQ0KeJy1Vttu2kAQffdX TN2HNlINmBBIUYiUBlIRhSQFV6pU9WFjr802eNfZXZO4X99Z21wMblKlqlGwmJkz9znKA7QaLrTM p3z7sdWc9iBSVgs+419kPVhubgDly4/hk4dGx0bghVaBc+HYhV6nDV5svR9zTSWn2hlKEmrYfaYX 591W58i5Y2pPB5eEp0Rm0G657QPvp3V4CN6V9R41J00mAho6kgX9IdXEn9NgxiJOdCrp6cE7y3Vz 05M3jgMjHoAIISjt4NvkCtTKGBj3F2mAYsZhOh6C4xj8bpApTYTUM8THpNRX1OPhrVgwP8t1Oxoj 63bzfHoNt9FuYNn0IaVKn6V6LiT7RTQTHCZUKRJRGD2ROFlQRLXbq4K9OQVayOvBcQnGPmIhkqpE cEVBC9BzummIcSWJT0sfa9iCKY09IHdiSRtFuNktQolGXz5lS1SiI/yR48oOYbAiUsB4ZGKRJJHo ITfVJg74gmuGY+S+abVRMAm4D49C3jcqJZ5UmgZP8YKr/lo2sFPJ+4zqsJ8QSWLVR4P+toWDrbUr le48Wx5f8OY2WvZqC3YTK+YMExV5WUIHdt007DW29kHsECGM58boYjycZdj/eCtoJWwRc0ojM2mZ vwY2XpYk5zhlXEyWxnZzH9y/xu/TSjKl4iwIcHIKfKJpJGQ2sFmy7DgExfap+7HdaOGednvlJq/M KxGa9SG20sZNC0Pmmz6Bzpt1pvEG72tTHXOfBZRrHD0nMdqej6aec3EzdW6+Tp3hzeRsfG1Xa6mx eNtu9Ry3Js2N+63B/vGC9+ZeDHmmkTMUVGZdyLC0YvWDTXE1NFBuu6GBw5wGVLrQNYe/f/K54bNH Xj3s4qAr57A5bsSvXJm5gOCLDC8VZYAkTSWQWpIpE3tkel6ccjVkuBCPhmhL1wpDjTFnksEdRY8B QyZZMcd27oTDmC/NQUQFl5Uks5uq6S/OUK3Ih4dCxgUCS0t1npESqUSqwTTML5LvG0Yo2Iv4xlqB JvcUCxClp5jlode0ZZZ2i5v+LzG9ipVeoiSzLc+R0F8w0Ovpp557/pl4Op28fRNcRyJ1tl/U6CnB FVNwmeI2dz7k/zbsGX2/NavUOfqBHkee9QU/vwGvyq/TDQplbmRzdHJlYW0NZW5kb2JqDTEzNCAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDc3MT4+c3RyZWFtDQp4nKVW23LaMBR8 91eo7kOTaQWycW5MwiSNoSWThBbcTmc6fVBkQdXYkiMJGvr1lS+AwYakKQbb+OzZo7Na2X4AqOEA lG7FkcRWc3gEJspC4IP5TawHy8kAoDiQGLwPDOg4vRCMrTzPAccOOPJcEMTWXp9rKjnV0Jd4rMHm Z9i7PETeAbxjqhIDV5hPsZwDFznufvDLarVAcG3tpaHTJhMhHbdvzb6z/8ZynFUoi0DJwnZgao4Z CeYJBdrszuwLrTG5t5tpTgnd7nPCQsp13wccxwZ42R0GsDcYwsGXIfQHNxf9W3uZBEBN+LWLjqCz 5G1uEmfZp68gBP2B3+1BX5BpbCKAcRJNQxqaEzA0A4BwY3RZL0OaCKlH5CeNMfhKpWKCn9lOA5WG VYJ/u7leFgjz3h/jyAYxxZzxSf6v1NDpxqAinIIoX8OstwQkVVoyorORcEpDqAW85+K3DZKpTIQy RbXEhN6lmpeIXiz7s6TfIf9acZ9qSnTAYtpxEfIgcs03cN22d9J2vbcItRFa8JSwFZ6RxrKOxqnS rKAVlnx+KzSttosqNCVsTVeKSJakk9L5KFRqr5mIZrm9fDECOFsCq8ZW8ArXhVJUqdQPtZMXJ5ho oOiMSqbnZ3aUzjwRcRLR3BNjzCIa2sXaC4UqLbzVHNVWKWpcCq7TIlJEhoFIirWQC0IhJ8bMf3Ba rNZeRfatsVbHnCvN9JRyMoekoB0LCZwTt4EabqN1UGegMkVNhW5sWqzlPl/xLrhycFWAoka1++7M iOJjjXc0V0iDw5jxp4WpleYizX2GJk+rsqHLGvG5Yx4sZnO3ybFLkCVxz5isvuRorjSNAcGaToQ0 dmTpoyemITNXNlVYZi0eIGux1QIIQ3OTU2XSZOZBbC7bnW0irXk7J6hWb24tv7xXZP3U6lMRYadf /tcx/+qZbb1uN81u2yx4t/tmt3N2eeel7qn4x/OyF5AbIZm5xc9B5dN9TJixAriaRnPgvcteaiqg 75/whALv8Idh7AbWZ7P9BXsPpM0NCmVuZHN0cmVhbQ1lbmRvYmoNMTM3IDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggNjQ4Pj5zdHJlYW0NCniczVXfb9MwEH7PX3HKC5tEO9tJnASx SsA22ARolLwhhDzHaQ1tHBy3o/89l/7a2jQVe5iEo8SJv7vPd9/F9m8gfQqkuda9nHpnwxhGtUfg Pd4j77dHlwaw7uQU3mZolDQDWeGt/CgkFOKQQTb1Tq5Lp2ypXO/CisLBfhteveMkjHp3um5hcCPK mbALYISy0+ynFwSQffRO9s1ea5Or4tWbPLeqrkEKp0bGLs59Xc3DnsBhf0BT1id91g9OX3iUHqY5 2+EZoOXJYYvP+GzBG/DronZqugdvwKuJud+BNsDlXJXuQjjxCD2KdUNbsDXZFlnF+Eip2sysVH47 qSMJP1H4qFvPLsWP671ORdm5lgp09aOyxhlpJuc+b2eydbg11g2CJObRhn450lnOFX9HPQ8Xu0Nk J+xIuecUmcf/k8gJeR6FuxfTelH8qZR0wmlTQq3mymqHco31aOyDkM3wuW9Rxt5ET7XrjU3dKsqa 6ULV0uqqcWmFP9wygMOtrdAS5MTUCpyB1XI6nFAX53a1P0R/KLmhksbmh8NdYa3t4B8TAsjGCq5v 5yFUQv5SDnQpJ7Nc5XAvapjV+KJLcGiUL2nucEA4h7ZdpT023U7M181Kyd2iUuv/ehWBPwgjgi1i TOTpPkODFAXhMqSFJCIhlDAi8Il9GvMc/fA1UDiaUNL2DwUNkJ5R5BE5j5czhTzhlCt+x0ic8iKO GOEce8bIvj8POI0ZjziPIy65jFP0ab4pD3mKHDF+N3xpHDDMoTU/DwOmiOhS70GajrXRUe9d+GkH ygddO9xdGiAMl8fkJ2O1sG4BrYZ/qsYtBW5mkwWEL5fHdMvo260YKQjj78h4mXlf8PoLPS4c9Q0K ZW5kc3RyZWFtDWVuZG9iag0xNDAgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4 NjE+PnN0cmVhbQ0KeJy1Vdtu2zgQfddXzLoP22IrR5KdtWskAbJx3KhoLmurQIGiDwxF2WwlUiGp uO7Xd6hLLNneXoCuZFkQz8yZy6FGD+D1ffDsWd9p5hzNR7DUjgev8Vo6D45fGkB9oxn8E6HR2C5E iVP5+TD2YTQMIMqc56EwTAlm3KkiiYHdYz67+NsbHrv3XO9h8IaIgqgNBJ4fvIg+OYMBRG+d5w18 wmXMkskV10aqTWhYBoQaLsVpTxHD3JRn3LgrqU3v7MWfju93vJ/8p2gb8YydBZ43dL0Af1EQTI4H E8//y/MmnndytGOJbPs8oaA8ZsKEUxAkY6e9i0U4j9zZ7dy9fTd3p7fX5+FNb8cX4JDVs8Abuf5O lKPdMIfTmDJNFc9tH/Zi3UjDE06JBUEjCRgJgn0xUOTaKEYyWNwBTaVmykL+q6Dv9YP+4PhwLv8V q8Fb0nTxX1PuJzVDwUaT4HdptrgbfE8shJ8Nglf+/yHTFRYO20awGBKpIBjCShZK71r/SIyfkKOL t7DdajpQeDu9nLlTSYusA9VOruLx5P31247ByR+uC5ciBplA1x+4oGkRY7FcwBwFcd2Gsk04Z7lU ZkFXLCM13oHD6Z1MOW2KONlCTQ0LbCLd7oeWRYXMZCHiM6MK1iZuY13XyQ3+txtTrZ7HsWJaA75t bIldPe3x/HHoElzunT29WKOmw7X5lvtoj7ydzoFidtpg1+qBOcJIAKF4ZNrwZfX2z9lDgY9wIbOs EM1MmKVyjX5B0IzKaMUg5mSpcDTcM0RBFiblgmkwCFmduryq4u3MW9qJkViWe2bWjFVC643GHakB sZgnCVN2N+AnYy3VZ11ufVJ3RTNaKG42dq+U5cOamxUQ+CzkGida2QwgVSv7Vfa5kjlOM1zJpdCs ZsLhRsTh1AE/RQT7o4vUQIZEZMls+xJbsWIlXLMg932Kw6vMwvajpngJuqCYlyVKCE8LdMOIjyTl MW6H0jTmS25I2lTGl4IYa4flxoyqTW66jKSR7LwwK6n41yrpOkHM6qlH1VhvOUtV9+K7DBqnSxpv K3vEDtcsRKPderUpHxt7as1BSINiWnuK6yzuI8F4XCp/jTGIQrX2jssvOUdB4E2RbmD4svzA7xl9 uLNRhuOPyHgZOf/i+Q1DyIE5DQplbmRzdHJlYW0NZW5kb2JqDTE0MyAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDEwMTA+PnN0cmVhbQ0KeJyVVlFv4jgQfudXjHjprtQEktKloHZ1 vQIrVtelR3NPp3twHYf4mtip7dByuh9/YyeBBKqtzqigODPfzHzzedwXGPoBDO2n/qV5b7Aew0b3 hvAN/za9l17gDKD+oTn8GqHRld2Ikl7lF8BVAONRCFHe+7QUhinBjDdTJDFwvNaLuy/D0aX3xPXJ O/hOREnUDsJhEH6O/u5dXED0W+9T8/rWGEKfYcZ0jfv44AVdBNwJj8wfFf181gvDDlTgN69x/dvY ol0QdOxwKVZIZVjs7GJmGMWHU8TQ72YyQ0uVc8FAy1JR9i52Z8kENKOl4mYHXFAeM2FO41wcxZGe 5y3FFjnhG2K4FPjsfUW/vcfoyON4rZlmRNH04wyPV5MlEBG3I3604j03pCiULBQnhv0fAEJtpRqM BEOe2SlLl0c1X3vVwlrLzNQPEv2OJNasBd+UisFkCh1u4U7meSk4rZ4WmXw9xB77oY+6OvJYs5fS Cnb+RvIia6qMUgaJzNCfiw2w6h1IkbnWZ2XMsDi0WS9nni4Y5QmnljbCM+079063lqvZfGG7cFBQ zojGEjQQrEPznGdEOb4QNVKEsjqxOiEuEqlyl/I5vHKTOkP2RlnhyjApMW6rUjPg8X0W8lW4oCZt 6lKMMr61NWHmoHfasPxgi+GfGNBMatakUsFVJR1OioWqXNCXi9gSjieQC+dTVRtLWuYoPkw35TQF YtnUyKpqnx6LVMHqOnzGtcUiGnQhZcLic+BJW4h+R05RiikkCI0BEUNI03QICFRyQq61JhtmMW1+ qm45OmIW3E2LQ69s4NSVVlVT9+G2NKlU/J9KNdi4AgV+lIubd4iKIwkNsECs42kHd/N15C1Wa2/1 x9qbre5vlz9cW4JJ6A9RlF/Gfj0Zue6k4khCaVUwaH5uzSdXTsSYHIZqpFm7Vz1jasv3fULetgik HPNVxzXIqrYmg4twEI5Bl094MdS9plLgyDXWqwayDqlE3vZely2Z1eozRBk7Kds8E10jnN0hZ4ab kgm68+oIvwR4v+EnPOuQec1lzBJP8XhqpfqWZ0JP93s3/VKJKWcmmRZEkVxP0WDatvAQsf+TkdkC /AAs8If9/cDupvUgM053cK830a5gN/3OaOn/dGKij70ouXC2N/1HdwhWybI+G/3WHdEKWkVcs02l wo3zfWBMRdJ+9wcnbtMf+N25cOr92zhGlWqwZ3cj1e6mz4vtyCO43f/a9HhydT3omLfxB+8GaGWL gyzByWjJAeMYqi7y99JsCsdmC5Kj6TvHxpEyGrmO3uNpRLHtTqmdvxXcTtbvJY7r0bn7d+XE6M8H OxFGk78QcR71fsfPfwijlc8NCmVuZHN0cmVhbQ1lbmRvYmoNMTQ2IDAgb2JqDTw8L0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGggODEzPj5zdHJlYW0NCniczVZRk5s2EH7nV2zpQ5NJZQuM71zPnafp 4Wudyd2lPtrpTKfTUcQaqwGJCNmJ8+srMNjYcGleMlM0Bix9+lb77WrFe6ADD2jZ6ifPnOHyEpLC ofCz/SXOe8erAFA/eAY/RRY0KTuilbOf58HEg8vAhyhzni2kQS3RkFCzlYHza3l7c0GDMXkris4Y vGJyw/QOfOr5z6N/nNEIotfOs2b4Zr6MyO3Dkjz8tiThw93Lxf23Pp0Q7/l3jue1oFdDoWJcTReS ixilWYQzC7GDV98QAouHcH5LQsU3mR0DIXm6iTG2L7BchEBIDa6YKiKiRTxdYq60eeRrzBj8jroQ Sl673oC6LXx7wh93rw9GYrPL8dr9mKUuZMikkMn+32Hu1dmyUlZCULYQp06BxsJowU21DokYE6PI O6k+uJBvdK4Ka1CZNWq341BLGZAss8AebU/8+qz4/yV7y3CIBrmJRIYzn9KAUJ/QcUQnU280HY1e UDqltOFpYTs8j4bpp2i8U5ojtMMyl/GXLaUBdhj2WfEEyfiUpIXt0aXgWuRlMGe/qKJMy61Kt/u0 DNUjMGMYf3eU5gjvcL0sCiyKMotOItiEPssZN1DgFrUwu2s3LTOGqyxPcZ9LKyZSjF3Y56xGrqQ7 nHXj3GuntnKjpCnNaJVaDq6RGaUbSqUTuwU+sdKc27fGeva9Tc2ZfS+MMBuUfEd4TbtSGrwf/AEd +IPR+IRh2KXosTDPrJO93D96th7a5h9iX0G77tcWerJqayUJmWF9hm+t3Cf9x5TeFQYz4MxgorQN TKE2mqN7hj7g7+29M3ZMgji2BaJo0Yl8GxBmu91Zv3Rn0d0TdK0PP2O+cQX1VnAEkf+da2UUV+m1 e9H15DDhjd0Ys8ALfK+hr3qesl3zn+s4bAv5hSLb4pCg+ZoiX1z+n0Se0K+jcDPUye9mU3zMbTGv tnyr9qxFsnaB1YeYrXn2TBOJVfPcjZ4yeb70xXE2fFhjefLBfgvBmhXwFlFWZU6rTBQY93t2ZiAI qs+KO6WFPUR20LmsW8JGEF5t0h0E31efLh3Qn29YgjCmf1nGeeT8atu/7bSVhw0KZW5kc3RyZWFt DWVuZG9iag0xNDkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4MzU+PnN0cmVh bQ0KeJyFVW1zm0YQ/s6v2NAPTaY9dGA5chjLM6qREzJR7Ep0pjOdfjjDCV0Ch8wditVf3+VNAUTi YySk22dfbp/dvSeglg20fJp3mBqT9QxiZVB4j5/YeDLsCgDNK0zhjwBBV+VGsDVqPRuubJhNHQhS 47UvNc8l18TL2VbDcK3vbt/S6SV5FOpMBh+ZLFh+BIfazpvgi3FxAcEn43Urvp6ILOJbd/m856Fm WmTy5s2vhm13UCfMgUvtMc1KRCurRR+E0ll+7AiGIl/zFFhYOpibj0kWfiW7TGmzp3JSQi88ECm/ cSidEuoQehnQK9d+51L7N0pdStugTshRO74MRYRR+x5IlvK5ebvx1wG5u1+T+7/WxLtfLfzPwxgA xlC/OPSK2AMvk6GbHxyHqzAX+za7PV++PHClRVzlHnL+VOBfUGgNdAabB9hmOdjvHItajnVxOR7A jxy08g4JXfIm4+wNj9UR+Pfe8o54WVikXcF3JZKLyP179WkAuX5FCCxlBNkW+jZAyDApIh7hD1gj UYSch1hZXfN9lutNuOMpG8ZaA3zvIUtE2J5kICt3m/KfYS4dC1unTvei0LssF//VHKy4UizmsHxm 6T7hqOU4bTsEOw683h9XThtl7EVR0qn2mVS8pFLveK+zxolPkAvMBXvMDtyq/WEN6B3TCAm5OKAQ LbX4Jg3fmIJCssek8nRgiYiwLypgJGKhWQJKxJLpIudQqNJGBgwDRwJE2EAbW1h6kZBxxYU6YjSp 1UvBdS+p8JwmUrmnvblZ5NIVXG/dPctZqlwEuF0EsS3HHM6Y7upYfMGabdFO816PVAKsVBwc99j5 Y2yZw2bsL9T1Sookq8cWWt1UCelNjI7b2ueaxzWjcaWF0ztnt1gFWLyiSM3JubL7Gb/7k6ERLKII a0hByVGMPTo3xf4wJQy3zZt2KrydtR3bwEf68sxFJ+wAr5WtCMs8ga6StdCahV9HQz0fqcuXJuoI 4mya/myU/qzHB7zXJG/wJisU9Liu9+amx6Xg0QvMl+tjgdRvy+6oaFx875ayck6pGRkys1lV2Sv0 zXJ9PDeNt61AntBFcoTp79XlfAb656GcI5f2v2hxGRh/4vM/kaZYwA0KZW5kc3RyZWFtDWVuZG9i ag0xNTIgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTAzPj5zdHJlYW0NCnic lVbfc+I2EH7nr9jhpXcz2MGGXK7M5WbSADfcNJeUuNOHm3sQ9tpWY0uOJJO4f31X/oWBdNqKAYO0 +2n3228lnmHqejC1r/YZ5qOL7RUkejSFL/RORs8jrzaA9hHm8EtARh/tRBCPGj8PPnpwNfchyEfv NsKgEmicpWKxgdOxXd9+mM4vnR3XZ2vwlYmSqQr8qee/D/4czWYQ/Dp6d+XOXPLEQioDtzLPS8FD ZrgUsM7ky/ufRr5fGxJEkCJEnCWK5bBDWgVZmowL1GBoabtZdkDhEVBsTXdoXhAFAXpeB2g9dKUN 5hrILuJxjAqFAcrxRaon7R7t343HB8c7T3C47JNf7+G58AUFKmYQuAh5ZHfgIpYqr+M7CqkbTERQ KCyYwi6pHLVmCZ6H5LvHAUinGY1f++PzMKTZicfpWPMMQTXbciKGGbZj2m7dlu1Nn6SkYL3p4n+U 85/rRRoqNUZgJPEg98TakDM4oU0XGPKYhz3BGiI0GBpCIGsrj7amlPnmjSJAzqqWoR2CTon3qNMM 3D5utgFJRAHVw/CQF+Qjklo/qdTGhmp/m5TrFqQBps3+SAmA9WRq+hYi32M06UXbSBDyUhvYo+Jx RUvMtEjWqvVOmQYhDbBMIYsqio+wY6pV5DZ09vISZb5DZVXUovQrtpYT0GWYAmv6JsVXFhF9Ocso v/AJTa2+3iPMmNY9TM/YBEImLFldmaiItVxfuEkBX7muOeq0AwSlONYtdVL9VthgqoIkkGUVRBKb TFO2x5o9XUih0RYvtkHTNkQla7FIILuMGKx3NmfAh3QZxIxnVqYU755lPLJNSR4tUMQTbogGzRPB jLX7TofazL+6/GGrTyypqjBtSZ5L1GbSB7FtJm5Kk0rF/2pV1aZGwWrLJW07cJaqqdt/QdCpLLOo 74UGhWmyeEmrQQqdfVibWw6pROQV0jzp5NCB9uT1Dmfv6pXlRYaD6sQyo0a0NcRmjTqJakO6yMro cOY6fe9RxxG7us6pboRDfx7kT5ophZYZdZFtzlMJkO4PO5Dt5mE/b1U5VM7mfrlak0zCMre0Wr2e 186SznOeMdXy3gEoFmJL9lDR7snxRP5d5jbwQynslrGSeX0TTOB2tQ2c9f3Wuf996yzv724236Bu 30P+3s++O3V998PVxMZirwgy6ae92dSeGMNgbDOWqpAa67uJiTZ4Zgyx0RBlpHyCIqNsjkP/xGWE saN4tLDny2ueCb3o567HpRILjiZeUL+yXC/IYDG0cDzXH795LbVjgPgvaJ47HR+unuPAHqwKKrjT SVAVeD1utDC2E0u0p0dNBM1vlo/1ETkeXmIDrAZoi4ltGFU/rscPiCqQ9nN8ce63+EafR3dit3AT RXTcaDrdDCZSVddjXuznDqPp8edBwT5dHNlbrPm85uuOupfuieqct9VrwckYvpbUSPNJ/WfozOj7 gxXZpf+DEFfB6Dd6/Q0FRfNbDQplbmRzdHJlYW0NZW5kb2JqDTE1NSAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDc5Nz4+c3RyZWFtDQp4nM1WbW/aMBD+nl/hZR/WajM4AQpFBa0r sFG1paOZNGmaJs8x1GsSp45Dy379LoHQvFFtHyY1EUmI757nufPdKfeINCxEknN7Z77RnHfRMjII +gi/pXFvWKkB2t6Yjz44YNRLXjgLY+NnoZ6Fum0bOb5xMA00VwHXeKToQqPyMZ+cHZF2B/8UUWUN ndMgpmqNbGLZh84vo9VCzoVxsF09aQrp8kX/Cq7DwzeGZRVW00WshNt3gHkhmLMOOdJwGZinWlN2 ZzYTt6JDfxow4fJAT0cooD7Yno3nDp7M5nj2ZY5Hs8vT6ZWZ90OoxuK1TY6xlUdvluEzjJNXGKPp bDSe4JFksQ+LSATMi13uwgOagxKMq0rT0OY8lErfsFvu04KonM3Xy4sdsLuJ/9H3TORzGohgufn3 5HxS0uLRxIYHeZNiLEjxSCvBtJDBwAw4d7GW+C6QDyYKYxXKCChVqhT4zJeQ9Bz3iGvOtCN8PrQJ aWNiY9JxLNK3rT7pvSWkT0gGlLOtAt1oqvbhdIo4T6ZVmHHg1oC0OuBeBMkMqxCbqqiT0u23SiHl bOtyEzElwmRjh59kBIXpeYIJ7a0RZYxHEZQodX2oUvgr40DXJD+PUWU4BYwoSgqtuL1ZYfghZRpF fMWV0OuBeSuWtyZi0g89vqm3KAYlHJrFLAAUj03Zp1KLXb9jOpPBIikSxpGiOu2LlKs4I5rPqX5C 0oloJT3gZIpTLZW5lSDVErruN020m/uEJO5X0AdDeI600DHIWmO2xV1Ihaxju0EadqPVKUI0qxh1 HGOfCq8W/b0F0x9Oe1dlqWlNDrYcdRW8gsSMqKa13BNPPgxLW5V10DrS3EeMar6UCnY7krFi3Cyb 7xyy0V/e9qy4XBdGU5QDFOGqjSm8Nod7Ulja6A1CjYDmcwqyeLhaCSgoEf4IldSSSW9gHtWEs/O4 hl4ctuyebWUE6Zu99FuGSj6b+YT+bbZhKC25/r/ZPuq+tGzb9j+nut1OvzQupRIwx9eocowfQwGR oPMYJmX7XfoBUzH6dk2XHHVa3wFx7Bif4fwDbAKKQQ0KZW5kc3RyZWFtDWVuZG9iag0xNTggMCBv YmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3NDM+PnN0cmVhbQ0KeJyNVVtv2jAUfs+v OOseRrU5TQKsLWorbQW6VO2gkE2T1j2YxKHeSExtZ23+/U4CoblR7QSI5e87F5+LeQTLtMHKnu3b j4yj2TEslWHBFX6XxqNh5wTYvvwIPntIOsk2vNDY6NlwYsNxzwEvMjpurJmMmSZDSUMNdZmNLz9a vT5ZcNXA4JrGCZUpOJbtHHq/jW4XvBujU2KcHXERsHAwT5Vm0cXhO8O2q5yCMV6Jpwzv1PZHf1ms h1TTCrjBvnClhUzLSB1z0S1QX3MRnx9IqhlZ8Yhr8iCUPqgq7lTRG/N4xC4cy+oRyyFW37OtgXMy sKz3loW/RXA7ZrshN/Z5gOG7Q4hpxM4PLufuzCPjyYxMvs3IcHL7yf3aiAKgjfbWsU6JXfdzVHe0 70hM+ZKvszQ03RXaINlaSA0qW2sB8ymEQoJ96piW6Zjd/h7ve40XhFIt2krcKGP9WGXEnQxHYzIU fhJVkBc1Inkw+HF7U+ecvSEERnEAIoSqFeCxv0oCFuACZlgtQhrB5FZneYLm/gOL6B6GO5yKFfd3 p6mB2fZ2TI7NnvmS/LuE4SRdiihKYu7TLJmQzQTyHacYGe+BQcDpUtIIFgxREIle8Zgp0AhloVft +RV74cbeywgumH5ibHNmlY+oAuQFPAyZzBKDF8OTkH+UWQmjkPmU2LBfEHbK9bFNuGIxy6YQKDbb Y8KUzlqs5VoALAUi0SZw/FBQa+bzkPu1LuRF98ZJtGASsGN3Wzpds2bkjlmNUxBCKmkj5fqjdGsK dfnOJA9TWOeFLwfeerBXhWJ/Bgyv5AirCjwENITtpoA945Q0RvcVyUZ3m+O8sctB1RLSq53vjGxk 0+6btSj77qPCJ6WEz7Nabq8NvDG2/tqPvUjbarUtUYWZJSHkq8LyfUfdH7Z3YC5jvkwkA9se/M80 9fu5kVshOZU6bSZu9LzmEjN+naxS6H3I/90apJ9TumTQ7/1CiyPPuMPnH8iJ88QNCmVuZHN0cmVh bQ1lbmRvYmoNMTYxIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTE3Mz4+c3Ry ZWFtDQp4nIVWXXfiNhB951fMcR+anMOX2aTZ0k3OSfPRsidfy3qfmj4Ie2zU2hKRZIj76zuSZbCB bckJGGt0NXPn3jFvMB6GMLZ//jMueqP5BWS6N4bf6D/rvfVCFwD+Iy7g14iCPtobUdqr94XwMYSL swlERe9kJgwqgWZwq1hqYP81v7/5aXx2PlhwfbAGn5komapgMg4np9FfvQ8fIHrondBKtESYiZgn KMyXEimmQK1ZhhDLoigFj5nhUoDCGPkaNTC61CspNIJMgZ3+2AvDBmyOK6lMgzAEmKVg6IDufaAM sViZqu8Wa7iEiwyWUhsCtFAJT0BIA0u2pg0ilaqoE2FrxnO2yBGMBL1kCmHDzdJDvZWojVRDV5iH 4r48EGWxQAVMJO1D57Nb0JU2WPSBadhgnttPi2cUE9qm3vdQTGuuDSG6ZfomY16nJdN2Bq0ziCdN GaAjzmJ5qJgJWCCkPMfEhRMrtmCWb1ilQcucx9xgsmVROeIYrJSk6gtXtccy32tiH3QZL205DFLi rVSOtjXLecIMuo0Jz7hhuYfSPBPM2DipIMFYVSvTrow4ona6y+vSLKXi/9QE7JrbIFnK6bAjjflv BL2UZZ54FKp2TXV5FKYpbrOs3NedUCnccUd8UnxM94k3AphMnDIvhmfD0PLYoejunRWrvBHJoQ+a VhasssDeAIltvsY1KpZDrUrt+O0YgVpf5qYRhalWzixvDneBVnUrVHZ3q7/7Om3UW0tRirzq+MAT k9Qmmj3f3t1DIuOysAhWT7MXWLH4b9w6ihnmivFMCUTabjtETiciDLZbRWn9Lje2zj5w8rkrwiNR KdtcKT2/o0ll324KC8aFhqdvDw99l5nZWnObY53dhpP3fHoEk5dJzfeuwjnGUiUzMivEOfnvl5YD pDVJK7MWWZ5Emwg5q1RkR1p0hTPFSVROHS2smGmbAmmNW/+Ig6paRNp4zQqka7NBbGBuvs7mkT7O CbEwovN35beTrSdDV//1iChJ13uJkzB826w8u/OMeutRMhQkWOrw6wl7Pd2bx68n+vW0ZRfnBmKs litdNE4Of54Mx8PJ8ANJQryVXNnj2EKWplukn0w7O7hVu8RTTtXf3M2jwf3zfPD8bT64fX68nj39 MAnHg3A7HVx6Tg2HROyPlB1yTRJJtv5ilkqW2bIlN0bzxsb6Z5qN9tOvNfeOmawRIXHroXbPuGsB WI+SJnGibNe2hVxjl9xPXCaYDhRPprZX70Uu9HR77zIolZhyNOmUWswKPaWAaTuCeJoEHX73Xi3E /0ELh+Pgyle0n9iLfQJV8KiziKx/GXSmY7DddPRFm26pOVw4Gi8DgvvqJNk6rXNefdgcs/q3RuZ2 vSCqSNr3YHS4b/pE71edPPzCdZLQANZkJIOZVNVlwFfrswGj28HVVsSfRp3ozgGj4ye0Eo7oR1jK Y0uNG42XwbUx5OWjmTbUUbcFDYrL4IgDgm4p3/XIkTR38K1ejo40s1neW7S3Ly6cmB7pccyUqQ5b eve+4sQTfC7pQXTWdz8lD4L+eLEP5PPzPwnxLup9ob9/AYLbdOQNCmVuZHN0cmVhbQ1lbmRvYmoN MTY0IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTc3Pj5zdHJlYW0NCnicrVZt b9s2EP6uX3HTPiwdKkty3DYz4hTdkgzp8tIlKjBg2AdGOsvcJFIhqdjer9+RkmUpdpBunZzACnnP 8Z675455gGgUQ2Q/7XdaeuHtO8i1F8HP9Jt7D17sDKD9Skv4MSGjI7uQzL0GF8NRDO8mY0hK7+BC GFQCTXCq2NzA0+f2/Ke30eRNcM/1zh58ZKJmag3jKB6/Sv70Dg8hufQOjkaEuziFu3SBJYNTnHPB DZfi1XfeeOxMjt+vygIeUWlanvnxKPIBRSozLvKZ/zk5D4789ydkH8fOHo5Xeqobf4QUesplhvNA 8Wzm10pMOZr5tGKKlXpKBtO+RRCPxj75OoA+9gWcDamPWemZvzCmmobhcrkcLQ9HUuXhOIri8Ler y4bqAJA9B4jC6IeQbDLN829biGEqR3PNStQVS/FfccICSxTmXKqSUs3qwsz8h5oVfM4x84EZo/h9 bXBgUIutyYnzYzPMy0oqA+IL43Bla6pyKVNmXC03nK1T4s2ZYI4508RX2Ei1ZR8ozLk2ah02DsLO 5WilMz9sgoJnwvqCxO4NzDod4pLbDSRIpcLBH0HjYhtQq144/iYI4PuvfHrq/lpXG3/OEzUfsiIw vERw3R1Qey+l+st2IgqNELj2JNluWrT/DDwBdJokVKe+1+QqxfIele39eHcy7POULHBbQqB5ktnB gBkYCbquXImNYkK7NzmHi5vTs/N9niCTae2UBHOpAFfpgomcRgdwkfKMNuiFdkpX+dEzMf1PGQ+C tn9IEzatRFCzHDWwlOJj9CNotD1iISt04Ta0mMhcFToqrd5hkA5KWcsObUb20euf715m7mlEkLwk gsa4wwHc1TkFb6gsWTe3XdhbbjbRPVybga43qGGZENK46PozvGnmDeFmuyfCpWJVRYrqcnQc7pg3 TMOdI5pj20noVDbzKWAfzLqi1064U1pMaGk4X1JZVgWu7MYW68xOuqq4CwgfarqlcLsKg3OVvVUG Z32SBU/XPpRc3KRprehOiLZnv4S3x2lzRzRr/R99XLSKuZO1SvF5Jy6nT/m5xV5yno7Az5pkwgW0 gX6ozUIq/rerClw1fbDRTifT3ToNae5UrL+9rd1QVHsquAPrZcxpdHMvtoBB9Jtgak07ilxx1V2U 0Mu65vbcTW62e82uogAUT1067pl1RYvXV8nNL2fX/j7AcsEN3rn5+MiKmgCpLApWaRwWvFd2Qd2h moy3kA9VpeQjtlfWZOLydEXUmDLr3Sl9tqqInIaPdbGGyWv3z9yO0e+fbCnfvP2DPJ4l3q/0+Qcq 0Q3VDQplbmRzdHJlYW0NZW5kb2JqDTE2NyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDY5Nz4+c3RyZWFtDQp4nNVVW2/TMBR+z6845IVNIvSyjk1TiwS0Qx1sHW3eEA9uctIZEjvz hbX8enxJ26TtpA3EA4naOD7+vnP7HN9D+3UH2vaunkkRtKZnsJBBGz6a3yK4DzpuAVSPpID3sVl0 bifiLPC4Dpx34KzXhbgIjsZMoWCooqEgmYLda3r54U27dxrNqdyzwRVhmogVdNud7nH8PTg5gfhz cNRY01/KC2S6QEEU5Qx+klzjIBwio5iGrbfHL4NO58mwW2QpZQuPexIClypyw31Mv2UgAqUSNLGQ pt1ZJS3KHONViTWjsxBlYHOtGob6PDBSVP7faXXHBf3lApsporQM9+KvLmV8DULr2vCYTEFL885L CyV5I4lD7q60VDSjiXMV7mT0WEIba60YMCfSB3JzHU8+jW7CQ4CHO6pwVpIE1/VOeJ6TUh4o96Mt mq2kwmKKkmuRPAdo64pMrbP9U+BE0AV9DnzEErEqn+lzYlyK/0y4TTX9vWQP+anlEVZUlKeY1ROM 7PyWyOWRcJvhcp1it+s/Iv0XUTRmCU1Nf2HmFAVjlnFR+OqaERip6VzBNUpJFhhFntf1IcfCAn1o ax5P04guEjS9aNrjTYzbD1q/GehBXodr1kjivUaWNPZoPTyBWT0Oz3PJNUubYjmMubgx/yEUlE2S RAs5CNu7vS3Icm3TbG6JsUHtNbYX5T/s79FOOp68nvlWh3POcyTV5qwLo9abgbuMFEgexbSwIjEH YWROwgcufsAQM2QS4ZbnNFlBBNPxsBp7pAupIrGrKaNbfW3W2rfCycxsDJ+Fl9smKlsxxrgi6428 EY81pTzRNl1vNbzrgMwWSx27EoTJkgsFPNs20ftE6SrZJPFab+357fWc32tzUBGhVvvbfLQsqekZ XOl8Bb1X7tTfW/T11riF07NvhnEUB1/M/RtXvoejDQplbmRzdHJlYW0NZW5kb2JqDTE3MCAwIG9i ag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDY2MD4+c3RyZWFtDQp4nNVWy07bQBTd+ytu sylIdROHUBACpJbQKlAIJN5VXUzGY2cqe2zmAXG/vnds52GHIKer1lbs5N5zX3OOZvIEvY8e9Oxd vWnidCcnECmnB9/wEzlPjlcAoHrRBL74CDq1Bj90yjgPTj04GfTBT5yDkdBMCqbdoSShhuY1+Xr1 qTc4dmdcbfnghghDZA79ntc/9H85R0fgf3cO4Pyd68JkNHxIY05z4CJMZUI0TwW8cD0HxbTmIqo5 Yq40C9BkAw/fO55X5iquIKUmYUKXUNe9REC/XxVbqDMWM+sGQRJ20VlV7oDOMzTwNGChK3lwtnL5 6Oh0L2uFbCaaJlnMFtbdzFaE2IiyKYtW7MkwQdnaCrV+JAs3q5d5JizCKTqQkMWYUiPVRceIWWpE wIKypbdTnd3jsw2wqOkjrSGnRfN/X3IkKA/QNhpiEi6WSXqt25iwLJV6SucsIbtTnHdfW1Sblmgt +czoJSt3KipHMgp/SQzhEmdp0MMtmRbX7FIyhfloIacZsSnQeH/nj2+v7ztN8MucazbNCGXwTGKD YJrGMclUg4VqAQRKVZZKreDIAWUTO5bSLUMq9Gej56nkvwtf61Bl4rZ1RuIZy/BovwKWy9YFSuU8 GibzljFsod3ia0Ne3TpzTd1ss13YV9JZml/Tky250lS5a9iUCBJRJbI0s0VJvG5qhzCHdkVFuaL/ hT5xi5vmuP0mLfHT1EjKxuGS23+e1hojTXZrrS+vPRjfaL124GzO5OrVebOeYOOs2cxfP8xqZ0Zd Pq/E72wxelOMb8lxPz3uKchdUrmKOS6Bn04fyojBoDik73AvJFLnW3TB9SLDmRTcmDiHwYfiL8kW 6McDiRgcn/7EjNe+84j3H+Pzx1QNCmVuZHN0cmVhbQ1lbmRvYmoNMTczIDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggNjU1Pj5zdHJlYW0NCnicxVbbbtpAEH33V0z90kSqC05Ik6Kk UhNolJRACk5VqerDsh5gW3vX2UsCf9/14gRzE45UNbawYWbOzNnxmTX3UH8fQj0/iztNvVr/GMbK q8Ol/Yy9ey90AVDcaArnkQ06yQ3RyJvjQjgJ4bhxAFHq7V1xjZKjDlqSjDSsHv0vFx/qjaNgyNSa D64JN0TO4KAeHuxHv73DQ4g63t4i4HSqmshNipJoJjg8kMTgmT+4jcRFwpBrv/Zp/60XhtVwlqsk F4IrITUz6Ry8G3aLKCORX6sizlE/IvJFKVUV+ZlKoVTX2UhyLgyPiWRYGd8hj20+EpJi+tye3Sic 6sB9XQGc1my8RKUlo3l82el8iqVZgtEsw5LLeYi2oKHRS46yHThJi9ISxza5v0x1cWib/szPq1ko H/tglP0tsnmPypRdZSpyTtMyKWfHxPXk2bYwFVQiq+ARoznQL+XcnHLLcnKuBUGJ94ZJjP2lrm1r 2txV6jUMiZovu3sT9b62u/5a9OOEaRxkhOLTg6QiSUimVp/jdrlpTeifqtFdK2shK4db+esXiLCX N59Z0RvFOKrKku/pSfXJfGWlO3n8T52fvgmCO4UxaAGM08TECIQD8gdMRGbtP246EAtq3BwwDv2r VhAU2LUJ6WNm97MBnWBK/IIvEzGOAsniZtnrhqhWnrUS3Q3ZNgydsvODnOLq+DxRkjgqV7cLaRXr 8CFlvEepkerMD7f1OyXTRUxtd5XmXb+zlLn+rzI7/i20ozjBeMDGnGgj8cW1DB/m7wu746xKZUMr Nyn0O0qVb8Qrwnu1/avRcO/1GyEZkXq2vvj2NLM7rIJrk8yg8c79kVgL+nlLxghHH3/ZjO3I+2bP v/VSlUMNCmVuZHN0cmVhbQ1lbmRvYmoNMTc2IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggOTA3Pj5zdHJlYW0NCnic1Vbfb9s2EH7XX3Hwy1rASSzHbVqjHbDN3uCu6TpbHQYEeWCk s8xNohSScu399ftI0ZZ/JHvYniYjsMi7++677450HmlwGdPAfcJ3WkZX8xvKTTSgn/CXR49R7B0o fKUlfZ/A6Y3bSJZRGxfTm5huRkNKyujFTFnWiu3FRIulpdNn/uMPrwejVxcP0pzZ6INQjdBbGg7i 4cvkj+j6mpKP0YvO4d3GjFk1JWthZaVoLYqG3/fiy0Hv6tuX30RxfBLwT1G8sRf+tY3dR727gr9m Y7VMnf+h0duMLOuCk23NByZvERZBD409MhzukxJlSP0bawP03mHqw8cC/33PpUOsynvUGKyr2lES xRHnp1L8fvtxka64FLPJaehRQc/V05oOZKAHYVpCn26TX36efuqdeX9dScuLWqS80zitikLU5lTi Z3vSaDWWbJfjWmhRmvGmLMbKjGWV8fJi3+b/R4MPO/Dfm+zTp5Ujtjlk5msvuGRlu85PqrRxO0/l bVN6RcfTjWXlptAhdtnOMSdsBWrJFjJXwjaa/xVyK67XxG2E4/32kmjBaaOl3dKcHxupfWoDl+Ew uMRwQmE0kbm0oqA9EUNCZTRVqd561QKv+WxCBa8xETlceCONhb5kdnmMRZjQWRueCSuoFPpP+BiS 6ugqAdTnqpDplmxFUEECluyKSbdcM5+oMFQtO/xlpb0Pb9KVUDkHWnCRKpWZU1YqOJV+YlFcAmc0 34PsucG3aDIGk4XnCcQA5LToknGQAsG8V4Lu4BSW922ZrXgBwnQS3uFavh7evLrv+yBY7gOljkut qzWIU1qw0FSyXVWZCVAQBt0GFBgKC6MxXneBHc+S+yQasFdWpsJy1vd83Fal5V9YB6C2SEA47fYw JbOluu2B86i1XAu85w0IFVKFISiFVFbI3QhgwbnT57IbJGx/Z8jUnMqlROekCp1ECwV6ArJOOq+k XeE3Kgsnqe/9oM3RaARBOyk7JT0j16VnG6J9w7M9W59hiQuz+upGNcV1a8ZH1J88ALvJavsFOXMJ A8bPl4DZ0biP3bHChQczzdQabzJvr0odDLdfFsnpD6gbR0FZOPoHRaLdbkHoE4bBwSrepQsEiu5+ CDeJobTy7elkn3Na6WxmucRUCWMccBgzhI9GnsstEIXGlJ89000t3fR+aIotjfr+34Yzp7vPGCF6 PbgH4jSJfsXnb8K3sBwNCmVuZHN0cmVhbQ1lbmRvYmoNMTc5IDAgb2JqDTw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTM2Nz4+c3RyZWFtDQp4nG1WXXPbNhB816/AW50Z2ZEc56N9cyulo0w8 SWRlph3HDxB5ktCSAAOAltVf3z18iKRkeTQekcDi9m5vDz/F5GoqJvyX/hf16PXyvdi60UT8ie92 9HM0DQtE+lfU4vcVFn3gB6vNKO6big9T8f7mWqzq0cVCe7Ka/OXMyo0Xp5/lxz/eTW7eXq6VO3sn PkndSnsQ15Pp9avVP6M3b8Tq8+givpSt35H2qpBeGS28EbKqRNs4b0nWopEW71QjtXdC4f2OhLey IGEsfhhHr34ZTac9QKWfTPVEZV6N3+S82gb8KyFuAa+081IX5ITZiCUVxpYLTzWgEkhjzZMqAbI+ BBBj1VZp6XFoLQ9izbClwpIW0R6EU1tN5VhIXXYYsiwVnymr3hECXK3CwQDuSBLZM3Yd0IBBPj8e meNjhHCg3obfpfRyLPY7VVGHU0ulPb55USJ1Ft7hx4X78YrJiJK8LHbUY8XnSt9aios21tRDMEs/ W4RrLHK98AKCUHVjLPLtubra+F5Ifif9MWBem2ilp73AKnqiCpD3CnUTdVt51fTJdUtdSBE9K+fF Xvkd8iq1WHyZzT+K0hRtDY6BHC/Lhe0hBUql2mzI8kpnWguljENAR/Ycq2yaSr0UbIcVombapOW6 orCudcSyQ0x/3X0+ZriDBsn5c1G1Tj31oiqkNhpdUqn/og4QwHL+7ftiOZ8J6QJywMsMt6TJgljJ K7nH+oICfNm1yHIxEzU5J7eUM8aPZym0+yNpqoixOyTwiNS5wvdYXEtRVNI5kFjtUj3j3rvv9ysW boO3ODo2eodkCV2uiNs8ga64EZZRTdzti0EbJJldAeH6Ore/geRCZodrsXkAVho0IISYEyHksHgD PwkdgdYWXiFHXtbNkUqbiJB2zBBBR2EEMeP5moZ9g9WbYFtJwJc705waIKujkI5CAlEDVHCFgzug VIOcpaDr33qNEtI/Fg+w5LeT95NHcU8FI7+5mv56NR0jvg4rEIghIeymtQ0M9SylH7GATTlLxB+a 3A+bFs9DCK9ZREfx5QxF1qcphbRhQSgToUyVafrqz47mSAc3C86GXCZH7tnrMG/c0LA32lrlD7yB QSAqgksDhqNzB4cEndH70kSXrlBljQojmhficuLu9u9j0fexnwaskMe9tCHonAdIobWJ6+kcWmxi 1k2T2nlYlphfWGcsdyQZ0roxVWX24fW2VSXPMeEatM9GHVu6w2JPmMHjPKy5a+QHPAa1x7wxJTFI YW+4YWpj+6J7ISHDRPI5c13YQ6CTdpoo4hcEkqYYxR2xjVKJgzCeMQZFJQ9kT9MM3Tsq2lDmNfk9 kU4D1JlunmStqtjoRleHPpt8am5HnKYde9hYrFtMhwpYYXoKnmRUZjtb004+qf5w3pu2KpmK3FoC Ytsgj8O4uH1EYbQDvmrrMT+A7ZOtle6PVlYxttjLHPxaOoVGK6lJzYAVR+5sgMoGcbgwantes8tB 8bQtj1lB4aWN9uIi9UybBR0drDdRF7OvplLFIVoKeoNKF20NpSI0qI96KyqSwELNxjyJeKIhc2V/ 3gyT3MngIV4c3/HF8fGsM29PjTyZfsig1JjeTGrgS5FrVNepciyxoDgd1rTbXc8TXELC5nxp9Eg5 8QUIp+tkMb0WlUBz8PBgw7bFUGF0XuZ2qkHRzgSepZahXxh9WWVpr4Z7gRluzmpznNO4g++N/VcE MbIm2Cx6lxfTywfnG7eY8fFcW1OpMFHitRoiKMOFLJSWKwtxc9ZubkLW7nA5wrqDOPvMnxvFlvip xeX3Zhxu9meLHr5yEO+mj0Ccr0bf8Pc/+iEIiQ0KZW5kc3RyZWFtDWVuZG9iag0xODIgMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjk2Pj5zdHJlYW0NCnichVddc9s2EHzXr7jJ S5OO7UiyE2fyWH80TuM4dZSZziR5gEhIQkMCDABaUX999wBQBGm1sccjmwT27nb3DvB3mp7MaMrf 6bOoJ8/vz2ntJlP6HT/ryffJLCyg9FHU9NsCi17xg8VqEvfN6NWMzs/mtKgnT2+0l1ZLf3xpxcrT +Ov++uLl9OzF8VK5R+/ordCtsDuaT2fzZ4u/J6entHg3eRpfftNmW8lyLcmsyG8kWfm9lc5TYRBS e3dEQpckqFRWFvy4rlutCuGV0dQIv3n2y2Q2yxBLIx1p40n+UM6fEN1oAAtsFU4ehRj3N5cfTKWK HRWVcI6QdetkScsdwBKM4oprWSrhJeJYrwDLqWBxLfAWP9iiNDCksOTlD3+C7fN5l4shWiCYKEKq XnyTmpeHBKRrK0+1dE6g9FrsaClJ6sLuGg/U1im95pXj4r7J3ZgoY9VaaeGNPVhrXkdfXVdQITQ9 KLkd0aL0ytg6csw1s0phibeikLQRrodaStQFWZpKcuq8vDRBAC3xtzfkpAybIxOcZawAnKOYHinV z0G30kqqVK18BxH2uq74xFws8Q10NjbTLqmaFbE1bVUOOEYad9hst4qZUh669gD3Vxd3t7dX7y+v Ljl62hSCwZNwIt3cXV5dPwdjKLZoazwNlXNJQuclPcjKNCjCqTVEai2CIa0A1Ss30vQkOCdDYScj iX2TjPzDgILNVaiSM4nVellVePwzTwfnJ19yP3UxOrR8+wOSU+tIafBZvhC20GXFxoU/RrY42BnK lHL12gLTqtgkwuPXZYvsnPQOdTfQXUTlO9Yaqx5EsRt3BrLOKUidigBdmyYL0enJnBdjZL2Ynk9P +vKuTVWZbWo8WreqFEw5x/3r9l3uzsTWR1m0VvmM4HvoB3ewHRy/5tWpDf+nVm7CZSg555ql2+sN nwVTQy/4MVZFGVocTX2KPZDNU+o4lD8KiBWH7p6yrF/GBszzNk0MKLVYVjKnpRCNWKpKBVulUFlT Ji8MgqPy0El9F315ioSqtmQdmAGMVakdR/zy7KhH2yq/YVFhELVSxZ4dYAbAI3RXgu4RaLvhuVIb m+XVTZkhm1hWSgfiysgFHZYuHxp8Yu0PBSmKzSH1WKbbTx8XLHjqvB5BFIWx0XVcHyOugjZKgNXd 436QikfYfjr2SCnyiNuk/l6J4WsUegEQg7HQ1hkWp2zsWmj1TwrtNmHAID2H9BgUrbZvGJAML1iJ xXqdD7Eke8NnDCzyaCZc5eUtBbMDsnPi0SIM+rpH/TWcJvkapIJl3CZPwqjw8klswXgqgIM9HyzE eI6EEy07iruWwe1DNYp3xcN5NBKYpIHd+ZBtl6h0eGYnkGSqeALShz9uENRveWSy2txAA6SPb+4+ vbskUQb/ojTuDNE0gA9NWEiItuJbUaJ3xwkNk7F8/BZswbWVo3mQ8oBRkdhnjMbTl2fnX7vu4j0D LL6EGV3tooPj1AhYh/PIHg9G0yArB+FjVkNf/ExjvmQce3PMV5T/EvqAxl0P9kKHc97hgKZQmt8Y l9owD8E9ilN3SAemWCn7K0IpvEgC763Ga1K3ju01wApzQ+lSPaiyFVVgdbtReBgDc+l8jOuSuwPH PrEbYYG1NW0zgGLfpZsl65QyqiUqK6Nyh2w1rOywnge9dMDAZ2eB9FtcdHDZ2NGjL3Q8Rqyjty0Y PzsK/yI8WvT5A99xXs6/AvFqMfkT3/8CopkY/Q0KZW5kc3RyZWFtDWVuZG9iag0xODUgMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjk3Pj5zdHJlYW0NCnicnVZdb9w2EHy/X7HI S5Pi7Poc56tvaewUTmPUda5AgaYPPGqlY02RF5I6+/rrO0tKd5KdAm1tBA4kcnZ2dnZXX+jkeEEn 8tv/1e3su5tX1MTZCf2If83sy2yRD1D/R7f0wxKHXsuDZT0r9xb0ekGvzk5p2c6eXrrEwXE6Og+q TvTw5+b9u5cnZy+OViY+ekcflOtU2NHpyeL02fLP2fPntPw4e7p/X/tAac3URSZf083l+THRW2qC 7zZ0yzsyDu+BbFxMymmmwDWHSMmTevbNbLGY4kXjGsv55uencde2nILRn58BRCUCDgJVcpmdDrtN ysFX1utbhAfeAalSSYHLspBDxDuT1uSYq6Pkj26dvyOlNcdIm2C2xnLDkVq1oxVPcBqzZTccRWAJ GNcqgIaw3BpFiiLrLjBVJoLuqkvGuwkI0lj7ap7l4nvVbizPEddvTYWEH6IPaUuACUyfNELnZFjp tahe8tt0K1vuxGPcOj0dKfst0WUN6YWeFnYiZeQkIZ+Ui0/mObi2CkxAs/K6a9kluvr10/IrlVqB qLxGgbVlBRvwfcqCF+gkiWnl5KAOJhmtLJmaNIekzFQeyCekoiSjDpHBAvfxPyPaDk8hvdBeDWWY IIkuvkvjVONAquiNKteW783KWJN2+QJSUFNCxmmcdFmfHIUEtKeOt6hjq7KOdWC2gFlzmPpGbRAP 1lKJ/1s5Kq5VZxPqId4dxypqfq1rih9hIx+yoaS7pjxhTW19FJduPMq9gxx8NGUcgnINcFa7YgXf tp1D3XIpNyokww+s5Yku7jeonir1WylpT4TbWKW5FLHOYONke3d8f4j+j4L05fGOByCMmGJSjtmx X5FjjIMyWNAeeqs30+XP5xfv95b69/Xp6RhXYWRUHRxdkP4/oQj1TI2+HQGhdlWPdMDQa2OrgFGU dcAwzEen1MUwh5LjYC61RAN/RVvGJDftxsPG0kgSO5UBkqfQhHmLiaQaeR53MXFL1twW9WX63uu1 eAUBkkiqLHoA4yCiz7cD75H90IJXyu1gKRypOPR2iehVW0krG7f1dgvvyITcMAcE7mF6482zKtG3 TE0HDGtcURFtliQPUVOG/rwnXG70IAnWjpJ4Hh/aQwoEG5ZTP3/A8noQDBVTGItxjWOF5kCnTJEx CeE8ahZIX+Y9GOTFgDlT2NfQ6Wil9O0BS3OFnpQZ9Yn5MAjfHJ/lG2+OX2R4VVVG3sgMHXX1fs2I sMjOdG1xz/VPlw/EfuyUgdvDqgw7PSYfFGosePuC5y17cMmYDNQUexyMI9sUk9R2kEtVMiHlAwAl w75Wdt5TD9zkxOYy753qs8TTzvaEZD73+Q9t41Gbpn+d/EHO7ASNBsubaTT+upAtLiy3qG1/GbIL 5esyEaVJeijHspHlyyd5b7MkMEMehGWafekwR2R45KVVct77MRtkgCpekDcwBzc+mL+KUYltj5BN j23BgaByBVc1YPbOuxS8jWLZHkvZuA9QHQrFLk996cS0G/fEnlcdfCteD9W0q/AMn2rNmn67+jh8 XoguE7OIRPvlqUYJ7V2x35cD/awQdO5b8GCYG85dOBEM7Q7B050Pt9IIb6vWOPmSUjBgBOSWc5qq X9n7esu2oQrzM5aPB1eObZWx6N28c3wXNJeW8HgZ0II6o5ZtYgKgzs4yuStUBqLs6NEPVhyKHelD hyl3Ns8fw48O/X4tvfLy+R9AvFjOfsHv3xJcxWYNCmVuZHN0cmVhbQ1lbmRvYmoNMTg4IDAgb2Jq DTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTQ0MT4+c3RyZWFtDQp4nHVX21IbORB991fo DVJlWCDk9pgQZ5dsqGLBm9qqkAd5pm1rMyNNdDHM3+e0LuMZILhc4LF01H369GnxU5wcn4oTfuXf VTv74+aN2LjZifgT783s5+w0LhD5V9WKD0ssessPlutZ2ncq3p6KN+dnYtnODi+1J6vJH320cu3F 45+bTxevT85fHa2Ue/Kd+Cx1kLYXZyenZy+W/89evhTLL7NDfAPAe2N/CKlr0UqlPd6iMtpb0wiz FkpXqibt8ceOnFcb6ZXRTtwrv8VKvyVlXxzMTk8LoLnXBfRYiOU2uLm4ufwoOmt2QHK8RciVapTv xdpY0UnrVaU6AOsNoEZRYbFBVFpuKJ0U0R1VwfLuHCYOaGhHVm4AwOsyiNKAb2O8olHOU41HHMu1 aVTVH2PZ2VkM+93xGWK9Iuf4pKWV2nXG+oyzRMC+PBOuo0qtVZV5kJbEOjRNL2paK53OkIgRaUlP ojZVaMHfhKNvqVivuVjfj9MJGRcA+7PAmTcVMhRX/94uRXAkSFe27/jsHB0YytSihkLWteIvZRM5 iSUc+OIao8K04U9zcb9VTeHKhY5PZALb4AO2ywAmtc+JglZrwmYrVuqoVpaqfEhF2BTZKEiBOURO 73UP1JWjn4Hls0+qJb819UCX25rQIGn5AwnUOwkFbgoWgqcHVI7Dch7hS1u7KBqS4ILl2XYNMb8p yn2G6bNZZyRWoOuhgdYhtltUmr/ekxlB/aTQQOddbVKFE8plLGJdVanS/vfayHXtrNrJKpFfKpGB oF+HutmRlFA/iwMBnkSVBJuL7EE7MLDJq13hKJaNtyPeIjYXTxtkUSgHyqiqNGqVkmSK2RISpPk0 /doIbbywhKhMSvxROvm8Wqz6R7w0sicrZGM0ZVZGzFsoBIqKcWckjv4ROVyfSTzMVq1cFSJb4Ok2 iVK8g+kOdYdJuYGWUcfnts7GFJsMwnderNicGmKuNrBMyJFwDjUg3KYitkQ+U7fvaE0VB4YlQ7eN 8+LiSJawpyOzPsLuIznqb5ByWfrZWCT9/PFzsby4Lg2DQAtFyF+6UTWDxsOm564Zktv7tUB8lluy WH/pLCyWoBCJTIm6wDEsstA6mHEvdpxmsmNHDVifeFZL1VZq5dokQo8BMGGqJh4oInTcrsVshjCR N7tc7MYB8h6SRbJtG3TsrWFMcFKiI7Iuua4mtdmujOXMqyFqIPID1Pp4YgTRVMusKD4Sg66pa0wv /lour2+Z2pG1T4U9cvcnvh6RTJeMsumLxQoDCDuydheq7bR+HxpTYfYtHjz3Oqtx8cCkYjZdF6Lu Dj8sFtd3L+KZL0/ennxPyc1jhP9dfSnGXuS4Djr2B6ZlrMszQyY2AD52rJ7BR2lMthRdWGF6ih/E K9ZWOm9D5QO68e7w+u9LRJQG9mADo0IYW0SuabxMIpwQBzR7k++Ryqfsx+XWg6jFmu7TSJBcLffM kKA1lOOZS+lxcO6TfDugejwso4ENUy9jIQG+8TQhL7ihTZpzJYz4BCn3Bw753lzeHDhkzNu2CmfY atvPM9aOdI0klHMBJ48GJSqA57LjSFhUvMBGi4gVh4NmhK+yUXUaZHeHi6846GKEEufYaLKXQTM1 zgwF25Y+EVCN2vl3JurgoucR9d3xq6kb3ObmCS7BYR7Vk7FST316BZch0vsrXe66vSNww8skVL4P RPxhktu1rCiHrXn+8RATq+SSGfPAPTvlFxKNlbfFKwzv3C9Jd6ri5o+H2cS95cYSQoueVS5Cj6Rt aRMamRuMLQmimg+WLm6/vM/D9UkERqPZ4v003ULSRUFPaRz6Jp6La7Ta6Mg16zde5dhEGmcSJkQP bTFWmbRcrAAqGiCdn0fqr2CUmEL9038XFg8dcnfic0Bo5/P4b8OTRd+u+bL8+vw7EBfL2T94/QIi 80+/DQplbmRzdHJlYW0NZW5kb2JqDTE5MSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDE0MTE+PnN0cmVhbQ0KeJx9VslyGzcQvfMrcItdJcmkFi9HRrYT2VKiSHSVU7YP4ExzBjEG GGOhxHx9XmMwC6lyxFJxGeB1v+7Xyw8xP1mIOb/ye9HMXty9EpWfzcVv+K9mP2aLdEDkt6IRv65w 6DX/sNrMunsL8XohXp2filUze3ZlAjlD4fitk5sgDv/u3l++nJ9fHK+Vf/JMfJAmSrcTp/PF6fPV P7OzM7G6nj3Dk4YoKFOJUJNolFFNbISjH1E5asgEYTdC6so6FerGC2lK8Z12QpOpQu2f/zJbLHok 8kGutfI1lWK9S4CFNd66oGJzJFoiB0NHwjpxf708EWKFE540FYFKIDFG4XZtsJWTba2KqeENbvld 01BweEAmHVTWHIlSVSpInQG8qowM0ZE/Ss7W0tdiE03Bh724+XS/SpQHrp6KCBtMaUvag29GYv+D ashnT0ebwgeX+HdwsqzJ4awVqmnBNtmlR/6YoRxVUcvOA8STkZXZWr1FpAobDThRR7GUQeJuUUtT 0Qmun5724f0zhmO7OV4zemGbJhpVZMySSv4MNDhxfwtwKEUmygn17urtXqZAysuKs/5goy5F6+xW lQQmpeJLUo9hkV48kNb8XkFCEtBDttiXB1UiEGXk3AoJV4ySmh315LaqAGgIsviOIL6HJ/Qom1YT 50bYjtAESzBvQ1o0cpe0o3wSoLYV+GnRSmgOJjbKgKvdkkuxpEecg/mMhBJ5sI4t/k/I2IKxQawJ 7DlUjA8HW+u9WmvqvQIWETKeyeRIOahrHUP31SdAX6dQrjvR85mUjoyDgwE6z6kv8Bil1Ugjq67K /M4Hgsyjx62csjFNJxnlhkJtS89ZngIm0QSkxif5MTWpve24JX/hSe1srOq+SoDM4hg1PdHam5Mz xO42opYL8RHFfmU2TkLzseDCyhD32eMH1CfMUJ8VR1nptWr9QAWcdYTC4L8n8VDb1A72RMlAykBC Y9PowGXlILnj2MJh2YJR6xTEzrHaqyxkOfvGVnO7maClQnYRktr3cRqvzGJoASlo8GntVFmx5pyo FWrLFXVSzO3HK3ADIVXUYm05FLDrAaVtl7exgD/fXI9lNbakGJRW/wIbOByq3HwFp5SdLYirWfgI C3K/48pkn9kmGaAKnIIsObOomoKTYgLKsVdMKnI+aqhgbbldJpp6H98Z/UugGCUsNFtYjeBdy12n 6kFq/UOfcVIYM6Fpw+QCRNB3gj/v8RqVhrHSDwFCvjapo6HkFcKpvI/dVMm38eVyOMUWlhHSSp5/ fXa5/Pq8r5jl35zWVFY/i8HIXgKEI5YxR0FNqPTR5lRNYsMT4nL5k/oVDVweOsrAgOmgsw6joJVg RN2QZVEG+Z178hY9F30ipUc1SkvXe7WBpYBWlLWR/Oq3hFOxQfpdmgqskuz28u7qjxd3V3f5ci/0 MTSdpvBDbqNjy8ss+XFPs0/7QdxYBfmaP4j1JLceP1O5BzSJ8xDJPthPVSe+dDvPS955vh10sAXc Xe75lW38bn3wUGNBatvNrDFX1E105AibTBrpmDFqw8uM7HqtJ1MeNK480blusQJBq2IrtSpTGnOq 4csnz8bysjJZU1JJZNfSspLhpk51bdCIzycX8zfsUmreZ3uFMpRIn5NBZiyr3UCsL4VJzmjqf85y MpWhRoO+pWKoOT/dDboGdECunzYHt0yZJnkXJpk3KvwqHWabx27Gyqy5H3KCL05fz7/15ZxJbKzW 9qHrmdaVvAfYbuuxbdJ8DlkSK0QIh/Z0lutItNFh4KcV733U+olbKfsqixjLCXbGYc2YDpEU0CHg ztpuCewKgRwM8+48zRdAzs+Tgm7QtlKGnvy9e2wVK+RDROc8P0rL+5NDX25ZIS8vOETvVrO/8PoP hyUimw0KZW5kc3RyZWFtDWVuZG9iag0xOTQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCAxNDE1Pj5zdHJlYW0NCnicfVbbcts2EH3XV+z4pfGM7VryLZk+JbbTqrWniaxM2kn0AJEr EQ0I0gAoRf36ngVBXZ1a4xsJnD179vpM52d9OpdP+p2VvZ9HNzT3vXP6Fd/z3nOvHw9Q+pWV9G6M Q6/lwXjWa+/16XWfbi4HNC57r4Y2sLMcTu+cmgXa/xq9v70+v7w6nWp/8I5+V7ZRbkWD8/7gePxP 7+KCxg+9V3jjeFFlKujKUlZw9u2MaFwwNZ6pmlGu5zooQ17PrQqNY0/a0mh4R389PlDJ3qs5++Of ev1+B/j46WlMs8qYakkBSJ8rZ3L6rHP8yVO6rayvXNBNSV9ffb64/XoMCllVlmzzSMPjsgOiYK3N kl/ZoL6TsjnVrspgWNs5LQu2xBpmXLQlpNhmblULUgL5gqfp4YQqd+hTPIH/Jif0BSpeDG6uJgQV oUFOS6DrDkpRXmUNqIYzPBkMOp+HgUo9LwJNmQo29awxFCrKeaYtgzTx98DWi8h4LExVg5826Fb6 HQE94lAyTqkgFDypEJyeNoEpYyg3k0t4LFyvbq6EqyXfZAXoLdUqXuz4WlJ1bXQX4KpBKGC6KpWY NmYFjsiqUmhCzChk0ZSqc1hLzi2EKK5DEsucQxQ4IQ5UTv8LVxDA54Z9+IWKaskLdifiYhfCmrOW skAgpVqm25IAt2pCfJdVNUv8AYCnL4u9lZ6141NfKAdK33jlqYT7CEGGLEK+yWPB2tWaojobuSUa wSnra6QlGbVihxoYzloKVd257tlwFjiPzu265TtfOYjBUEhEjj6A3FNL7g9e0a2uoa5vtMROaI3X Rh/EaMJ44qxxOqxQHeOHp6/HRzHOl4ObN5O2tKacqotzqdU1yIuMYF0irLQBC5BS4Fgrh/xZixvx 0TmupXNMtqR+c3ZxNoCJx8YEffpbVYuxjEdtsOntfgbvxaaM1wpc29NfaFga2gVQ9Lx9ljIIOu/E pq1AKfKDGzEiYI9UjJZqwyRGgoa8UPfpg28tdZmMRMbNBSNJrI0xfvwhQ0+j+4+fhqP7O1rX/rbz vq1ObReVEcSOAIwC9502SqyhB7jGd7Xo2LShKXTt6fHt3xLJ6OCUw5LhY83Ij5hedsOtC+Quwy4T 4n1JpkxJp4BUjmN+ojTnGu0NrxALlVBSwxYHtwAB4aVsQRgGRbbUpLrjM2Tbbg2+B24NQWIXgWvK w7G2MkR4qcOlaqNTOw0yQTqFthnK0u7WX4GebqSZs/QZT1MlPjW19ErAaUyGXEvCijxtPe/EYrvZ 7HndpdVJnBuCZrQXdzGEZsIkY5KkgPG25/C67bVEpRGgablc5ou4Ui1kjikq0O3xTHnfoAABY8De iNENyFphqeb2zSHxNWUhIXPVr8CwbAshUTFN3lbvPgIpU8kUxIiSnhcQDxyDK2XqdK3Xa6TNG1HH mC2DvsOvFcBST4RfhUKuq29s416wxWqDhWRKwog1VzXzFmD45939e7qXqN6poCgzkAsTxEdfN7wk JrH5JyLCOnnjuxJLzStyOkGao59Jt91DklyeV1hzNhMTUTsCWac8ajGTaX+0N002Yf1Rx/rfQEkl 7uRzCpjsCgeLxksx7LqYxCNJsBY5nm5qcGdVxtCk9ewQeuaqMh5/KYlqdhIvyJiqaoSVy+VDOdSG JeVnG7N2viRtZalKMIdWd4dOSwJL3XqjQoMSGBWHEPaafH+xS/5sELvOVoNV2jQgDGZWbOyx7WJf ZDTy9U62W1SSPgxb8c5qjaemJmZDkoKwopmoaIJZKKPzVBytRi/sibJxDV6fT3b7QkckkzW2yqVX JZ7PjXYsQ/ZkX/VcKiJywwEVh8zlZUyhRyRaZH7wdf+91rKB/95gb7s8icv8waEvH6RjX19PgHg/ 7n3E5z+8CR5nDQplbmRzdHJlYW0NZW5kb2JqDTE5NyAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDE0Mjk+PnN0cmVhbQ0KeJxtV01z2zYQvetX4NZkRnEtR43TY5uPjpJm6trKKckB BJckahJgAFCK8uv7FgAp0rY9Ho1IYHfx9r238HdxebERl/ybP1W3+vX2WtR+dSn+wl+9+r7axAUi f6hO/LnHotf8YF+t0r6NeL0R19srse9Wz3YmkDMUXrx1sgri4c/t+zevLre/vSi0f/ROfJBmkO4k ri43V8/3/61evhT7v1fP8GYwqpGmplJIL6Rw9H0gHwSC9NJ7ftxaU4uCwpHIiN7Zgy7JYa0peVVo 6Pkvq81mjGdNexLUUkcmiMo6cWy0aniZ8Lo2MgyOeJ/s+1ZTeSHErhKyLHXQ1sgWsTjKLSnryl2g Dit5g1HtUKIabWKo0qohZpBBDL0PjmQnekJd61wRR9EGUWU7iyawBzB8+ny3Fz7otsWBO4mgRx1S kSUFqRoqc4ipZhS65zMMhWeIkHoeNZ3Xi06eAFXchWKL06wYri4eFGhyIhwJQCKONoCpk3z+CFh6 eUAXdB2fIvUfwiObGasqyFClgwgWqwEmd027hHnsCWBJYQLVToeTsFV8UOkWJBKDnw6I5WQ8DhgJ oOedR/TZce9u/Ij+hHhwUhFi51jzY2W8ght8QKybjzswyduRQJE44p5OPhaDXDlGqWsdZAsSMYhx 1Qxo1aK0iNKeU99mtuL7bo7YWI8VHVGCYg4RwJADHpqgFdbnhliH1KDgqAGG3ZxyqMayKFI9vQRX MqAJAd/YoS2587JoifMeyOnqlBiVTvSQUDj3mHkG0gWWXV2NYtqlhEp6BjZLSRpmMbneaT9Gud29 BUNMyRJeIBNxPatTg6OjhNcPRFk528VHs+hRKMVCf4teJ32dAeOW391EGdTgqJMBkAhDx8lYmFQ0 EfnMJG5VV7CxZGQRBoz31gU9xPf4hl4NtBD4Uia76slOMqeRNKznb2Pf727WOZRU8QE0WFAj22os YwYGvPdo3T0ss2QpBxjF/TpBxNR+ksDr5CyxZwdqbQ8MJ8hTPdUAG9r98/bd+8nWzvwF3bk3vG6i 7EzP815HvjJsUf62qgDmaKegR7R3T+6gQdjsU4k8TAp7NFGjsT2KU2JP3q1s1w0mSgUNmUYBb4u8 O3mWJs+DWGZIBjpDLsfJ+HkUymbSS8eH6VMnsraSnkbajWqCKZPrtKEZ+R7CwaXkfvuZin6/2CLf m4lJaXDdDEWrlfhIJ2ischIsHBS3ZERsvgHBuV6eQ+gjpANmHQEgCkMy1Kg9OryESRypWM7FKsk8 mhfX2pH3EkSsmbdhZiHGshfEJpZwLDWywVGbOtDofpo0qRqO6W1HD1q1hn+zYbDZ2qkNY//k5ARc 3JPjiKGScQgop4u0cK6+vMVRD6x81v9MtSqeKacRioevbPXPafgAbzs4RbNKJdNwHTNP4AKOekCE FgxI7o+ZsayFEUWeYJVtH9fBYEFJOnn4FDf6LzflSYRHnJLlz7nKbGBtqkbTIYnTkOJ+unFetHjR conKQvPuDCf9wFdNRtEL30jH4WRn8yA4l5zDMMGDpgStnro+RyY0zg51E9WrCJsrbj9KtmD4WM4X 3A5fvtpef8MZD5qOfqGqpKce+EGuvDcxNZ5hwiFHsq6WRv/MXoBWLEp8jDrP/Og0KJU7Z5HLjVei wfXgZSwGWfhmUkmlW/hneMDlDFK+hCSxTXMeypTi63RBXuOQNfasRW0xh00XrZ/KIYVagyj6wBlG QxpnAAV18fX5cgR/jhYpR3MswSFIYeD6zmDnSwzue2dDnAatX/gAHES2qLc8LbrYESQar1wg+X1u wNN8BAZjL6oZ3PnaF6+ZceYwVgXx7T3y3Eb7B5ETtuM2Pu12G6v7hMkInp8e//vw7kcPJ/Liw4Cx tl3HfyMeLfpyI2sSr66/IeK7/epf/P4PbZZT7g0KZW5kc3RyZWFtDWVuZG9iag0yMDAgMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTY4Pj5zdHJlYW0NCnicfVbBcts2EL3rK/YW e0ZWLMdO3OTkWm7GaZ2qlnKqe4DIFYUaBGgAtKO/71sQlER7ptJ4RJPYh7dv9y34RKeTKZ3KN/8W 9ej9/SeqwuiUvuKvGj2NpmkB5Z+ipl+XWHQpN5brURc3pcspfTo/o2U9Orq1kb3leDLzah3p9ef+ t+uPp+cXJysd3jyjb8q2ym/p7HR6drz8d/ThAy3/GB3hya0lFzfs6cX5MoypcDY4H3VbB1y3pqSG 5amOm7zwcEV0x+9G02kPxlatDGNFXbdWFypqB/g13d/OqOYQVMWBVhxfmC0BjBoFoEI3WGkrWszD BHiCtMTD+e+3pIzDg7T7HdfOK1vKvsC8qjxzzTZmmiumNnAJSmS0fcw4K2QFzqX2XETnNQtnChvl sXm7MrqgR96Stmvn646vtqRo5XVZ8ZhUxtlo9soXm+2YnMfzAL6SqXchnBSMLNZ9vp5Nuggb3Ug6 Z2e9PNcHyikTHFnuCHOIEE6HDVWtLhn8wROMiFWxGYo00Hsxl2hVoiyMq0mn2/3N9Z93dzffZzez QzxtC9OW/HlAyRHNN9sA7oagLRlXpevGqwKbdnI13kXIl8oYtiFyHb5kXRD/HfV0/jGFq6YxvQ5G baF8jpUbktABhAQMssFn0DlpkyFV7xpgos6vhTrAHe9abZw4eX5qIXD4kjfMWFfSX+j3Xe3QEA7k t13UsKZ7OVCpmNruNfVOp2ewItWit23MwWMoH7nyOmboxutnVWyHvSGFW7c2KRWo5FB4vUJ3rFO7 7T33LpB3JjlHGcMGNlJR/KAGhMQ7a0brJwqTvaH2N0MXWrTeg6zZEv/UIRKckUXyHBos02Lp1Ix9 l4pXAyMQKR0WQpKTPaJvQ8wgtcPTkAmkB/mWbLRzbGibBvkd9s/eqBnp0KOt+K+DA0DNcePKkMV1 0RXOhKG8qdpUKNsZr6+UzKCgaibDz9ASMu7ykowH7TjQtx9iAGTsKtVGzMMRy5BGgQNmB5dtF6lM mhqVe8YAz70jIAXouxoNbTsLPRynFITUYn7A/5fJxUSaP7WNTBE0p+3SXaSepx9wxNddITJ8H6BD gAHIK7CiWtmttFMH8YI+PRT2RAQXaXUYpCsewghNtcJI0lAr0ayc6lSLrmkkDmnWOuqqG+iyhNdr +F9Gdqal9hpjJIGzjf3gup3NkwWpMCpgYoVdg8BSrhaPAjLjsNAuuiMAFNJxkjPe5YdulQaR80PL iQPE0hVtvdszY/WBImk3RtKQ2eEkp9z9WCzlmFFlCWsIMd2dYuCdcXKswHSHZWd9JSTQTLATdt6N 4hS8dsa4F6g1HMz9VJ13nep3Zf+8H2F9gZF9qaKCsazGIYe9QOA9ShG6/2AYvDzALGKdGed5/HqA LfJYfji6nS0CejGNnhhV8Yh5lIMmb0fy/3A4INAP/b6gEROV38xQvNlg5qLF5FzdH7PZH69O0949 V8JxA9isWaD54LUCVZLjIb1ELOai38VFArnDCwFWbt++L938bNDugb61mIvn4/Te9GbR33McMvTx 8h8g3ixHf+H7H3PJOBcNCmVuZHN0cmVhbQ1lbmRvYmoNMjAzIDAgb2JqDTw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTA2OD4+c3RyZWFtDQp4nJVWwXLbNhC98yt2fIk9I7mSYidpb7GTdpxp UtVST00PEAiRiEmABkApzNf3LUiKopTJTKTxSLIWb3ffe7vQM82u5zTjZ/cqy+SXx9eU+WRGf+Av S56TeQyg7kWWdLdG0Bv+x3qbtOfm9GZOr28WtC6TywcTlDMqTN85sQ10+nj8/f7V7OZ2utH+7Dv6 IEwtXEOL2Xxxtf6SvHxJ6z+TS3xjie5rH2ypHAF8b92Tp1I0pI0s6lSRMKQ4c+W0VxNSaS1F0NaI YnL1IpnPeyA8MrtDhSXCJ2Qd2ZADVIQgZK7SAT1YBl0tqRIuaKkr4JkMCYHXIT0+vENMSh//Wa1p o1AQKtnWRdGQ2AunyG4J6OSVrJ0OTQxGhTshmwFFWuN1qlys19MWNdWeUwH+GmGLxXdY8Iek2uBE icp/nGxEwUlKbagqhFS0aRhCO26bjzMex1owUJecYZ9rmQ+1cwBiIaagUpUb5X6m4pCL0CVMRRAk QTin3eui4EAPjaDDafWtYqtlLNw69MFiSVtWhQqwAgXHzdSmUN6ziCJzSrHg5ENUcWggYu3hGe4h 6gfMlka300Ap1E4VA4JHXWGvVAw60rA3J5e/Wo5JWLKBlKcHs7PFDn13Kd6y555+61BA1bJVq1cS CpnASuKzoNz6gJMDBDcWEa6/i9CyHBUmX8uchG8bs7WTKhaaKg822pDaAxUnzq1SlrXR7TRRVbvK evTCMxThSmt0sI795+JAwC9GyaDSgZ1upj5f+s9XZ/5YOhsQz+ioOvpg62wJnnkGdlrtgb3hScd4 wzVaQOOqozRO46hergmjmkfSDHPOTWZt+U491/h4cGI/Byodl3U/eP5+NCpHYq0aH1TJvAHWB6e5 ZzbiYQCxm6KElIPsgrvZ65Dr3jqjsgsrRQGgDFleeCiz1eA1Tic3UlXOYpa5dZh7u9Uy7glutiN3 YHtQhDVG3ie83WkR1WHfEG+XYjTZovBYdxudjoajXQdHcaiM+81q9AVg5c/UPGIFJed6o+PWPIMZ L1WeZRb9lBWYc+gcW5UHm+ONNdPW+wc6QDxzGHqDgzd3xImOHhjYw3IQ+3ZVD6LQFwjnU9250XV6 jJuMF9z0Jx3SL41KKccNDFx0a7EVIMUyUu3Nc7azh2vrZCZRZF10mzxuVHCGtoY9hYEleGRgo23L Tw57QRnpmiqiqa8VCovW0WV827ubj1wTrXPtj4g9uoOPm2oLQTMsSWad/sZ+PDp4cdfWNxDpL5jy i7fSWe8/dbf3na1NKhxm/eJHXuubPeP101/rw9QfrMLXA18M6SnHou0ScI3trj8vbaXi8jFpN1IV 9pAOoV1LsBGXHbfTdHyp97N1uDu4g9vbmO8jKMEINOc/gt5/rTQopw81RLyZxB9DZ0H/LkWm6NWv /wHx/Tr5G8//AcEEHpkNCmVuZHN0cmVhbQ1lbmRvYmoNMjA2IDAgb2JqDTw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTQ4OD4+c3RyZWFtDQp4nIVXXW8bNxB8168g8pIEkF3Lcev0MamdwkGc upYKFAjyQPGoO9Y88sIPOfr3neWH7iSlqAVb8Ikc7s7OzlLf2MX5gl3Qq7yLfvbT4zVr/eyC/Y7f dvZttkgLWHkTPXu/wqK39GC1meV9C/Z2wa6vLtmqn726M0E6I8PZjeObwI5/Hj/89svF1c9na+VP PmMfuYnc7djlxeLy9eqf2Zs3bPVp9gqfWMaWOx9kz6KXbC3Ds5SGCWu8dUHF3jOhufdqo2TDuH/9 crZY1L34efFOOOv9Zx6UNVy/t9E03CnpX7D7v5Yr5qQfpAjMlAVsnVfsmPI+SsIrSNw0TKteBez5 hk+CZ8EyPgzODk7xIJkf46TFxoa0QnRKbuUIFDqpHLPPhvFW4ixalIGto3iCUwgogMSNEljNA2Jh Ftvcs/IToEE67ArI+1mFThlCBjPRBArfsOdOiS49HKR0yrQT2kYUnKga6c/x5PKyMrfCJi9FdCrs UjJIccvFLiFguUt0ecTt6Xy+tlsk7STbIAeceFCGSbHmbPmAP4QoSS6A9TIT2TopWRysOc/HpwfN GT0pwQ5WK4HSsZ7voAS24UJpFThFEDpnY9sl8u0mJf14d/NAO3ZZIYBd2r7S9x/5UAq8acCJn4AW NNZGLNXKIATkWZCkEW430PaUVqNahKSZVy00FYEEVTIQLJxaAxN1WUJwtPzX88Uh63QGSo0cNlHT ykYGqrGh2lEQwUXUxUYnUpbcYJFATCYknRywDgFtpSN2+6iDGrRkaM5n6548CQ2UC9v30SiRtFuL XQE9ZVNS5DHYnlZRDNQxoEqWMikDKvpEH7PrwMFOwzbO9kUGtF+ZLWSt2ryKqlcTy5DpQDq8VK5k 2FmfemIEKgmgenZLVSOqGrbeTXcVjNI/iPIuMN/ZqLFwj2OzZnioa7Gxl6LjRvk+o/JkHIyjkqbV 8uz47AJF2XDtLXMcUp7qSsANfW0IaFAlVkt4Be28oNzL0NnG55AIMqMVFCqKjg2RZb0slmC2VqPp fLDU2lXWXDzJkE/1UDvT0rShS6eqnqoFQok4lD9nXXfAsuWUajRXAHn31qh8wqgeAlcwmehzz0D1 KUvgjZEIPvA1tSc17EiQP2RmQCFQeq71DhJEKwaFnLZcq6q9Ax8sjV+kXbuizzGiZpVVFP1mOVXw UQ1LqKndbQzkAHvtCTuUf9CKjRWxR4Rzto6hRtSNhdkLq0iKuBj9Y2LL5EujfRSkIy1kg9qH/qOg JyqtIBwToB/SqKFRJB2oLCEQOs7Nk+x87y8wI5gTNYCtap6kNm1oAwfODcbN7n/iyX6wt9fcJC9R 786qYlcF4aTfGjlgEKI3DLlLamM/r/b6HSOGauWtjsmk8/jQVsBltWyV1ylYnP9w3Hyqjg4nW+5S wqnGP0wkwm1QyEZyHVLpWLGH3LpnlSN7tnzAwVupc7mzhijBrB3SNTHdowK8xVGno/XY8E59HVVF YyKeJHIKcBxHAD+ar0WD+w4q3pxg92eVWQ1BcvYoPYZCCREZ8krUmiwMUhbhaP6VwTqZdl/+vv9U /v2K5+DDDmP/0567P25uP+x7KLFFxJTDJ0KbA7528xDXGNqnw/VJ7umCH4FXnmSxfECy7zRdPTml rnfztIanGVuD4U/SVPcoPFCFqW4HAyjz7VBcrmXVS+3W41OJYhqtaTS2FnIcbx6T4UrBl6uh8nsR kXEPNN1whaPJKGvJi+HN6/0RNcUtYhxWNdZDDzncTF3+ZOiKCYAyKXCH447cuEQOEZc7QxrRCXVD Zj2ZpcXeqCVwsXFQBcwltUZ2ikPgakjpukhORBeHDrSlGTAdPYfj//BaNWHcSS151p2PuMoeKEZt mEo349zb6fZ/0AF3Jo3A/QQIkRf/yNXwec6r2mz59oe6Ifhe+ep7LJpEJXCurlLL3SMlZLw7/Rpz +31QdOP7GMHT1Tx9nTlZ9OWBWu764isQb1ezP/H6Fx5biD4NCmVuZHN0cmVhbQ1lbmRvYmoNMjA5 IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTUwMz4+c3RyZWFtDQp4nG1XXY/b NhB896/YtyaA73q+XJu8tvloEyTANWegBYI+0BQlsUeRCknZcX59Z/khy/HlkhwskcvZ3ZlZ+ivd XG/ohn/Kbzmsfv78krqwuqE/8K9bfV1t0gIqv+RAv2+x6BU/2LarvG9Drzb08u6WtsPq2Xsblbcq Xr3xoo3045/P717/enP3y9VOh4t39EHYSfgj3d5sbp9v/1u9eEHbj6tneBPc5KUiYZs1aUtx8nZN wiuagmooOhIxCvlILvbKUziGqIZwTfQea3sRn/+02mzmWDpOImqHCFhNXo1TTJ/JtSRoNwVtVQjk PP52wurv+e0gjrQDBo6W4kTxqNaMKcURMq3ih/Nafu6sOZJoGs2vhQH81vkhhSyBgMD5iDw4M+z4 rMJkIg0AITrF2aU4XnfaYp/tSoKcX8vvKiAlJ6/jEXGkbpSNhCILGrRFKvXZmsIkexL85rsbdlqV aKmUJRKAjMLHXBAjfKeughRG0Zs37qHUek3KBpwHOAyvBMGJqQIlkGsTQAIhDs4/0mSjRgki9QCw U6hUq78h81KvMLWtlhowkdt2TqxRUgcuLqIbBVaVkpyA+5D6IJ0NKKWehsBrGgUuIv0aR4yjd6PX IipqRBS8hk/twaSGOr1XmS4peOfQLHdW3xE4gC/TQacjEHCPumYGLMJHJXuLpQgx8nJePLd7ECiw dMNotKipYsc38NIAdJBel02hd5NhYkgz4RQkJLQBNdsSi489dRsM9g34n3EBQnyC4fxkso/WHdC6 WpjUUezkIo5e7Tlc7hsKA76eE3ivQtRdigjwHx3SXJ9EESEK7LCirDfiEFKDGy1jqs0Ptcr8ZyJl DZVQfGwt+SW3wzWW3d5WUd97vReSSYS6KmYDGhQmRYdeWeSDUKArUtjX1nuBp4GXVnZen9nEOxyv vgk0CfnoliNWk5HAwozZYR9zWCxwzkY1cxe1sie/scRojrMiCoF8Ff8oYl/bBIyykm9O7MC2N7NU HnfctnNg2fiQIyuXjaUotqo7pnZYF5n9AKi92JkSdGFPJHZuwjEHV5qZuxuqpSbmAMwO4U1qX4ED iHRIxM2oqUMPPKjArDOqyaYmjJnthnWqmsQGNh6t2Lz/dAeu1ZoBQ216YJoIG8tmdzgVKVQ9uGQ/ NBo8PBNEL0ycfXrPTILNy0zGXuFlfy720p9w1heZkhImuDwJ8gyg5mSDudJJ0rqCKi1mpoHGDhJD X6aBNZakxanU/Zfez/NjrlO2AabictqwarmbyQ1YHJxe4RAcWNmGw/cuxOsS6X1OSoqgkslbPFmo GpL8OuHjmuXj1cX8ebinObtMyHIaXiQWHbQxCCIV6y17UAqYEkY90DGUv1svCt56pa6Ye8kJmVgi 1LCNk7lesrAKs0f648jc/vLPp4/l078lFE/wXM5x2hmo8lHN9VjoMaF1eYwV9ltXrhAP96dReGq/ 4MqIPO/RyJh8KNt3gVAmg5DZ3kM/z9TYezd1fdr794vXZ7h/GC1cpBqPZQXPMIrzP/c8NDGwuuYL TVgzmWZrgTJ4nOYpbs8uMZ2HjhK0k+FVgIKV0Rl1YVGn+9TyDlXn2zCF+WY0jSxVttzEvHNSB7Ta DTimcQcbIgo60KhQ89Sh2VmeOH3LR+fzFqKyy+Fk4BjmNB/FLrA/ZK3ABOqonlVSb2+gQiFIftVq UCub+XyVqXbDReW5pzocWIJzXR3MyucT+HIw3wDq9aViaiNbUrWudBXKOk6utcYNNBYvhgCmOJ9c A9YqSzcW4WFhlcjTYxFklbiWhzQOiz4uRL8wnSLXM36UTKVxYb6UlnEHEHthdB00M/P4+hDyLauA 5hsadzMNqd/gurMmzobAw32+Mnhl8P/SQPTi6gPVInNottE+XXY8OJj2JEr2eqw4E2i8y4pfXOkS /vXTABqXXJVP1sUExU4bpg2CBKVKoLu7VKJPcEjMruPl95q330YECPRhwleBu3X6fnOx6Ms91/7l hk3s7Xb1F37+B+hljIoNCmVuZHN0cmVhbQ1lbmRvYmoNMjEyIDAgb2JqDTw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTQ5ND4+c3RyZWFtDQp4nG1XTXPbNhS861fgFmdGdm3HbTLTU9IkHWea jmupp6YHCHwSEZMAgw8p/PfZhw+KstJM4yENLt7bt7tAvonrqxtxzX/KT9Uvfnl8LXZ+cS3+xP+7 xbfFTVogyg/Vi3drLHrDL9bbRf7uRry5Ea/vbsW6X1zcm0DOULh87+Q2iOf/PX7847fru18vN9qf /U58kiZKN4rb65vbl+uvi1evxPqvxQV+oyxgTfDCbkVoSQxSPVEQ1qWnQN+DaMgrp4egrRFbTV3z 5cJ/eSm04SUvXyxubiqYo2+RfLgSYt2ijJ68lzugjAOJxpIXxoa0SDsS0oxCqoS6GQsUg2jus6dG y0Di8f698KMP1PuloO+KhiCCBUYnx3m9eMdPhutdPUxIZUloU0nkaGsdLdPb542X2kUP4A0JMsqN Q6CmYG0LIyAjaCNT2bmwDH1a9uoBuKYbURA1nqt7MvZQoFp74DcNSFDhZO/SRS8NaHO1srerv7mV Q6tVO+PJ2+gUifsHIZvGgWqU3Vmz81dYcHtbZ7J2UoH5PgIffXW000H3XKQnFZ0O4yWziU6xidJN 4kSaJs0qerxG6ydTHqIbrAemjyhI4qfc2MCDBkeKjLfOt3oAL28NZib7oSPuJS/fABNPpQnuL9PI u3cR9Ao552PTWfXEwA4lXna612HWQ0WBI7Za8frB0R4tAA1l93lOW2d79K7NTvhWOrS0oXAgMtyf 40nNaK02E18uQGpwGhLFh1Ipphg7YK7akNjjS4An/QxywBM8kZjKTjj7NFUhobt+oKCDdS88qrVN VFwtPm0wcuBPbMqCBcawoX82V9Tp5CVUDLqDjn2yCsD7aLRKfXtwpkE25KH5WXZCew9ilyfjJD+Q 0rKDWg8tFcsQOS79CO+5JaiDS230dgsvGfbyjjcqhWJK2Rn+qujuMQ8S3r03e3bOLk/ETe9ZaeVp 8lpOhUQ2xs3fJGn5YIdp1EnPsmFPV9vIAXQOTh91wVLbRVTNE8uqHjHZqpGqxZkKUfhH7XxYzhTx MzI+/7tai2QWvc1BxCGXw6SKsZVBKIl0m8lUzcTHX23S2GfpC3ylkVi8YUqRrSCp2oJwLKGkzrRZ hvatjV2TfM5OwRsWVPX5FIvZ5pPvCwggV4QdmhyQIQcHlA0kXnbQoWWhGjqrRmg2gfd5Q/kTylKu wpT8mkQcTjx3vvwF+wXZCcuAgbmZO3nwp9Fy4J6rVyhZ7FhXqhdvIuwy1maSK3ODs4kduwpSG15j N18paVFuOo5lJAOMshQ2BpRxpCSPOu+RB1Ow2JN5m3KsSLGXnW7EmfCOUOlo2ibBzmLyuAGoQTwd rHsq6vmdTxQo2i2FzucXR/eGZqMLdtacNhGFKGf9HCmaRjqNTQ/JUymsyxmJ2DhiVWsZjiuwgH7f jRWXSZu0w+RLlAK889rnBsurcxJ4KMOngUHHrdxTwiMEDmKSpdCzyckhrWYZOwVHDelGBskqmRpu ppqSQH0S+qSLNB1H8ml2LLHQSlG72JVETTPDLHLOJR2OmatilxQMiqSvzclQZloJyEN7dkiz953e S5WoVDiBPCzs86kMAEzAZylOp33OciF7m0k/CfXgYvo4BQpWabO33T6jVeUXxSGhVg8I4nKAVOss a/1goPrzdAXb8D14nm4JPzuCOKcrUudtkqWzAb3wN3wk1hITrzidk3pL/fUmWT4BYs2w9G6PHMNg W2fjrs1nQMTfmHjePhVfbnL8iOk1VsU+33H8cdgjU8InOk03xhwMmUXcEviXqOYDsnh2KU3jnkLM cUqByI2+zJe7fOg+qykdsp5Mk1OIwcpFecZ4rJXETYd4n/XwhGJLcsQBBiDZ8+HY2IMpTzyt2ppN O2GbehdPSzMFwu7JlWtz8uTx3i5NmcfRpNNXWNBQuRwXf1xOt2WWOz3jaK8lZLkCzt1d0udnixh1 YTz/d8qH7wOI8+JThL/vlunfK2eL/nvgRl7f/g/ED+vFP/jzA5NifRENCmVuZHN0cmVhbQ1lbmRv YmoNMjE1IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTI3MT4+c3RyZWFtDQp4 nJ1Wy3LbOBC86yvmFqdK8Uryc49eP3adp9dRqlKV+ABBkIQNCTAAKFt/nx48KNLe2sPa5ZJFAs3u np4Bf9LkcEoT/s2fsh79dn9Gaz+a0J/4W49+jqZxAeUPWdMfcyw65wvz1Sjtm9L5lM6OZzSvRwe3 JihnVHhz5cQq0POf+5vL08nxyZuF9i/u0VthWuF2NJtMZ6/n/4yOjmj+fnSAO3arHIWNouCE8Y11 gRpng5W2om8J85QxHw6J5lh2f3tFtfJerJWnWuxooV6/Gk2nBW+ppNs1QS1JBFJCbuIOv/NB1aQN WbfkB1p+SqNcteN/JAAjCad+tsoHIEZuDhcqPINvabOyrhZBW8NU7FLsXvmyWZs1NfYRyFBfWwc5 G2EyjG9XKy21MoGfi+vLSkXIWhtdi4oWLUiB2oqUiewZDsuKGHzNUEwn6K0CbY+dFYVdoyUg+rYc YnE2eDoB189Ktk6HHV1a4zXkRxEeq2azYhvv3wh21AC6bGA7tFM1qPtISA4QQFxXAc5AFvQ8q4PX 66iJlZaSjoGNgoMwbjxuNMojYBYWS6cXKBoqlJAYoyN+3+cBdrkINyiQAKe6qVRQtNXqkXEL/XGG eUZaG1m1y1QBsRW6Egtd8XJeuMJCE7RIFyA5Y0CjWkcuWCTRB54Qh2FwIS5YhwrEjaSeJGq9VqDU gewjNHD/DvZAFfSH1hhVwVkVHhUykYIL86VUKRdcKUiuW4PCJ0WwcOB96xkpRnwLPS91dWrAtIUG 3JFFMHbprZC7zLmoXIoguKWGrYrmUA6VuM65tSblVq91EFXJP4IgQutUZEqi8jZRzHC3n66ub2hp ZcsFpgoJQbA3zrbr2L2lG5uk9n8JG4pijhAhVS59iWnHAcAhhT5RFE1TZbuz5ow0d60PuS1BbqOb JHIhWCBWN+0CO+mH2nH5nfDBtZLNoO8Hd+9uv78eIkXxnqQwiABhFAls95vUGdJZ798gfUGvCps8 gJTPMI8bBWwWHjQM5+ZgPngUBlTFY4gnnQiDNvCNkgyZMTAEkOJoBDsVJxZHDy6BV8Tm2ceYcSh0 hICtvW9V6ZrWxGHLj4sP3yEqPNSPTo/PHtD1K204FIbK2UJfD08mv9NdMu2dKgW7HVp3uX8i3UXg SORy4MwdCozyd87cOFGrR+t+JELp7EhBTFMnm6W9jXNrb5fdFyJjhX6x+NFi7VSeT6V1Sw3Ge9PS 0t5YQg/pth53s5W/i3zS9SA///Xpy/urbpBxml6Wqil6c2m5YjG7OePcN8rxBKJGhA1t0TPLaFVp MDMsJVfqZHY+eRjH+C41CqAXbTQX42pjNB+Wcdns5PzkoczbfnUu0IXWFen3as0gqT77W3sRGaGT MhyTz1x5bnSxKQ6YEu94PtRRY29Aci5RUrPMsWafWj48+Ut8YShnSA7uv43GMpBgjGx9lyPdP6KY chz6aT71D9T+8ZLOsKfeKOrpLCO4V5yOVefUuD/aoppOS+GZ7VnweSuRoyUt0qtNZ6B1L7KJEeKU CClM1veJ9d8zptB6e/Hx4r/eMeZsTTdiQdDTl/uPsb/KCwB9/fCeDPrUN0Kq1Fp8ycuNqoUfFPEb bqTrD/EggMuRpUXNXQoaoqX4ENa+HrxjAOf4OOJ8QAKFg+0vfq6fGs1H1tsWL1vH4/jq+mLRtzvO zNnRAxCv56O/8fsL0LjJ+Q0KZW5kc3RyZWFtDWVuZG9iag0yMTggMCBvYmoNPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAxMTI5Pj5zdHJlYW0NCnicxVZLb9tGEL7rVwx8SQLIriQ7saGbGzut gth1LRUoEPiwIofi1uQuvbu0rPz6frNc6mGjyLESbAnkzsz3mBnqiUYnYxrJO31m9eCX+3Na+cGI fsPfavA0GMcDlD6ymn5d4NCFXFgUgy5uTBdjOj+b0KIevJ+ZwM5wOL5yqgj0+nX/5fOn0dnH46X2 b+7RV2Va5TY0GY0nHxb/DE5PafFt8B53viPu9NPFxcPJh3eDyaS/fM8r7YNTQVtDjp9a9oEK6yiU TNrmXBw7nZNRNftGZTxFtMT9dT+bUuvMVHMopo1yqvbTl7qaGj/dhh2PTybpfF/HBPpsTVBZmNKc OZY5umxDad07T5d57tj7I/KcRUS2wAntkWQ87iHnNmtrNuGQyN8336Z0aw2fEN32aAWmRwAZG8Cu QXIEkjJynHzDmS50FsmfvAL6E0FifFZyrX6qSDr2/6kiGecp9GJIR/ezK5pHUHTFhTZa7hwN+7QH qTqUOxVqZdRKmxWpXU9QBRK9DHgBb0ypqt0ZT4Y5p2BpyZBVaLPrLsCN2eXtpfhjvQ7WbQ6I4YVD /BLY5FEYNkAHgxAthbfmqBCcXrYBtbSRKztE90jtQuKcVcp7dMlCDBXywBkTRf68jxliVLrWKLXL BTDosiHlIh0woNbsj6vrL3HCPo7ORw9DWpc6KyVam6xqc5xSHjx3SVSWcSMM9sg8q6rlHZumcbZx Grf2mIklaabHE3CYt3WtomA7z2F163TYSHGdw0dPpXpGlmqtNh76s6FcF2j8tgpCBw0IEwUhPPBy 0RYHFgge31hbAKW3rYM0Qzkav3YKxXnBVQWTlvi31nkoqQ260j/ivcQdpJYV16L/LMGTTA2CWQSz BXwmX9k18TO+rUuOXtLsjlQ3BykTDj8auzapp6AexnLJmWqRKVnZY/RxknVqOCwDXWz2OiQB0EBG GFxIl+IhvMoeI6kQgVjywTYkg4DGWYk5uzTpNOQUccHwhjHBuZewyFSqxlyd4PG4DIZygIAuDLre 5nJodC/bStpTTCrXQBYnL4EKgesmiJK3HNbWPYq4zyjkumHrFbeVzjT7WFm1wdax2+odtszWSxUi 4RKZWXYOF2jEmHx+1yseJ3gvgzUyrRESUm9dzFSjlvA9SNFX1FOmQwHgTPZYbWitAakNW9eONZ6E sAW965FEMGGL+X4tyXNylRa1hKJ9M1RyaIQfgAdWdWvSdie/wcKpO7bW5docWpdz6BbkMGIDp66V E/Y+C9oiqd/3FS4qoDOrircqdWagP7cGQkZZuskfGTSMYtQmccCCvtt1a8okq4AVFomSJ1XYq/5f cLv4fkAOscv9bov6aPWhPgemKVi7ekVn21tpcx6GgyxWmq0bLNJSpqx0tl2VsRDmMeUCgaLilzhn 3c7E8+l4qTwi+oeOxwR6ubBEYVlVs9/nXgYOAiLN2VlcSjfouziob17XLw3m3NPXFh11Noy/hN4c +n6nVowfXA/IeL0Y/In3v+RcKEkNCmVuZHN0cmVhbQ1lbmRvYmoNMjIxIDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggMTE4Mj4+c3RyZWFtDQp4nIVWXXPiNhR951fcyUuTGSCYQCA7 fckH6SYlXQqe6XY2+6CYa1BiS0SSk7i/vkey2YQCXRgG25LuPefonis/U6cdUcd/6/8kbxxPB7Sw jQ79ht+i8dyIwgSq/5KcLmJMGvoHcdqo1kU0jGjQ61KcNw5vlGOj2LWujEgd/fczvb487fT6rQdp t8boVqhCmJK6nah7FD82Tk4oHjcOMWJL6zi3baJzio1IeMrPBVtH2tCNesGVXAgntSJTDyB+ovO8 UDIRjufk9NEvjShaBxSKipV1hkVOswlu55SLEqttkWGx2pjgfEafqnoukpApRAzgnF750VwGFExu ySScE8mTX5qmMgHwGA9ztlYs2JIwvAGvjiRyrRa0YjaWXqVbkuWkMNKVyLxkw8ohawg/vbmqo0ms sMmSc66DrIx+kXNPeWl0sVgSv0no46c58BRmbskWyZKEpa93Y2KVmHIVKGG4DjKXC+lERlYulHAF dAGFic5k4rGk2uSV3F5mYYxEOoiziWwNSDrLWfoDjp9UWOiZrudXcZHAr63h2zDoZM5ZWcd5Fyxg DVrNJrZJr0sJOoCCtNBIAncaditBIGi2BK8MArQRqK6p6MSn49SLmrDFQLe7Hogw9EfF8IU3J3kY 31DD3Sg6+050YcRcsWnSrN2kg9+5pFft5fXZPUVIgsnWb9qNmoet3qjCj8ZA3UqDXQTeMb9wZg+a dHE5oajX9EHIp2zSnTCgGp2dDdrvmNeg+sM+QH3Whc24xKp2qOtJG4/SNBcKGNf2pK/tfueMJsUD pCcg34frRqVGwAdF4quAvqzYBP2h8cRopxOd2U90HVce+hzHk4NmLdSm7cnD8wRKD/9sG/5Jd+Dh j5AtE0/cpCuIOmWxyHB9i2uf4KpNM51pMLk/HL05VlY+ZOxleSpW+ziMhVoUqMf7I1/wrdm6pmlW KifeKpWMxhZbVMlBpbeHs4NJtQHdTqe7g8HpcAgGdywyX24g68vCG/9mFF8Hs015ATOast7cYVQn w8rmPvjvbbHT207a6w58KY6MVowdnlSb/rlNMbqCTllJADmYGG7Nlmg7c7/ZdClX6Ce2kC6U9c60 vojRa5VdaYOaFCUbmq370f1hPJ7dH9VaeQw7tLrihPMHLAPy/jbyfmfQAfIrocpMvvp6hWIsH72h 1vv9dxtRcrQ39aTXWta23of7y8MjJw7LbGJk1ddGbwl6wILpOti6Ru3z/wT1Dpf1u0OP+lLrlQfq i3Qm4CprtaoawTUaImdZdXOhueRqYB/gD4atSP/V9q326Sd2/X+jXrJxMg0tJ8T8eD/lF1130TGq cTvW/eHldAy3wBSpzHitF5hXBoYywx3KDPrewBv0t7jNUJiFCU3z4FzRmuA+bc6dM/KhcJuEalyh RM8Lt9RG/hP47Os9Hlrz4/tFZxs+3ktO/XvJ931YYIY8D8wugq9/eAMnGfpU1vKnVcWoBUo4Cp52 VRcsiaPh/hCHHSS+q18JoPGHwovQF35dOrf6dHyMGL1egHMHnsLAfVuf0dsKh4el2yIrCQeGf4Pa mvRtgkSEJouIo7jxJ77/AhH9yT0NCmVuZHN0cmVhbQ1lbmRvYmoNMjI0IDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggMTA2Nz4+c3RyZWFtDQp4nJWWUXPaOBDH3/kUO7w0mbGNDYQk nZubCYQ0SSFHwb32JumDEAvWxZaoJAf49reySUJjuLvAMAgj7+7/t6td/4QwiCB07+03z2qN8Sks TC2ET/RZ1H7WomIDbL94Bt2YNp25C/G8Vt4XwVkEp+0mxFnt6EZa1BKtf6nZ3MLb1/iq1wnbJ/5U mMp/cMtkzvQGmmHUPI7/rrVaEA9qR79uskqlJhBo54HSi0Zis7Qxc758d83PRIq+nnPy0nFe/LD5 e3D8odZsPtu6/z4cREH4g5ZdzTYexIEHQ5ai9qBPyxFTqfDglpaTJeop6oU/5F9yROlBj64yOSOD UbQnuKsA/qL9yHIP6v21RWnENEUyrx/zJQyYXORsgfBwREE8HAPFUffgW6tHBt+YGiNXWYZyxqxQ Emi/2+3BnXrCjIIiSuGZV73vt8Ta5cdGY7VaBatWwSgeN9ZEaQ+HO5ah+XFIzSuea5WmJNshuqSf A7bJGNG4oHWspoKW4xIMXAfVkOJEZUbRpnrhb8k4GhAvmohGnAg9g/5MOK0Px/+TCQWD/AXG+Xtg +NJFsg8JSq43S3sQyk3Gcs1KLJeCsKwcpO5Wfj+AicgKrU5dvzRGwVZjm2ykZevirpFWhMQIuSiV V4RW795V3vQOCyU5Plca90k1PMGMHVTq0rYs8nZN6rqIPCnTT4dFSSTVw63quwCGFCymRiVyT7AF i0nhjY6XthB9hInVObe5RrNf84R+Fgftja1tkXjwB7dqC6D9ntSXqv1oLxGxKPoCxYhpqa+rNq7s XTu4Uusy0wM2ZJwLtpv3QxR3ysGfiIVkTvO/Jf8/y74k8wriNpf47m4wI6nVwohaQTOgGpdzpTPy 9oTkfI6aqgjN1vo99fDovOUa6DVbPQpZlMhtUIiJA4Jn0ZDgT7mgihCSzjpZA66xCN87BMpgirxU 5CxpXAhjdSlZzekaXORWSZWp3BA/YzGjznExce2iKrzbG0HHc/MGXLCuaDVPaH3eeZN22tLqtE9J Ti9RjwmT1PwnRbb1jBLixgCborVljxui1nTqXyYBbT0k6JsbAs/zEL4HJ+E5jPJpKjh8xo2DrJl5 PgXQQ23FXHCiV1UzopHEN4W/130OzEgzYub66ZWmjrZS+rFeqnaa9nDZHR+tPSTCM5fYsTJYln89 ThC6qeKPBnYGWn/NiRRNMqpeq7hKoUe1VD+Y3CIisv2cB/IeVb2fnLZOXB6Uta4MhmVNDQL4Exdq RsetThOZzl0KXw3CzeipDRezGbUQ47rIwTFGpRCdtEoszoW3+6QRVsNwTygUxlBpQY2A+txnB2KM LPWtyMixy6lPSXW4qRPPiYqb6eOby20xHmTgTP8yw0v/7Xax/9kjVF799VKQTjrr6QbaXvGIVNl0 P3LPFqcd19H7ce0Lvf8BpLyUZQ0KZW5kc3RyZWFtDWVuZG9iag0yMjcgMCBvYmoNPDwvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCA3MjY+PnN0cmVhbQ0KeJxlVNtu2zAMffdXEH1pCzhenHZN16fl 0ltaD1niYRiKPqg2bSuWpVSSk/nvRzk2sLQxAgsieXhIHvodhkEIQ/d076TyvqzGkBtvCPf0z713 L2wdoHslFUxjcrp2F3HmHeJCuA5hfDmCuPLOHqVFLdEO5pplFj7+Vnezq+Hl18EbN59ssGCyZrqB 0TAcnccb7+IC4mfvjCwvLi78dvkKsFSi9CEOfJgVKH14plNcU0rtw5rOTKawDOBBZVnFyH6yxqTW 3Dbnp14Y9oD//WZKGp6iZpbTCTKlwRYI64fJYNiiuVMIERrDchzMeY7GEtgHmInIFaUpKnPiuzLB 8fUhYjopXEVhQDGjUU9gkpRS7QWmOVYorekAIyYbSs9kacAqSJQQyPIaTcvE8eobTLaqqiUV1lLW uOO45zI/KtMFOT/KQCZQsoVIVVK7K2AG9iiEe2+12vHUOWk8RKSHhnTEiIzh1VbwrGlRjesqtnAU ahUxvYGVekNt4SmAWS0lgRWs8mFZBHO/g5k10hacwTyAKHlmnAY01wH85kJwVsHaauQC3fWj2HBr qHc7JmGKfCNrwlpb3GGHNSXqRJp8/9CAYY5VQooolQ8LZHJwp5lMFOksUjpzXhS7JQf4obQtktra ntQCs0xjA+ukIB5OSFPNKWusGTVCCJqnIi3BnIYj+J70pmhKMavfWtFROzTroO4DmDclmkPVJMcn Ri3SXCLcK5VyF9BZWpBVbUu1NyWnPrCK6w5mxTaSSkvcLY0FpoIlZadtVguY8aSg2ZTciapbk0lt C6VPDUzSVJNYj+TmaAik4qPA9YMz/WEhbqMZbYLeqsMedDzC8RWsFQG3k8Fe9g9qW3JpFTU1mnR3 v0iKSMtimcXj3EuiijfH2SrGSS89q6Cn9J1mGJD8XPz1Vevdmz5/Lm7/bjkVCotaNECr5j4bn5xe lrS0MB6/EuRt7P2k5x8jvm71DQplbmRzdHJlYW0NZW5kb2JqDTIyOSAwIG9iag08PC9CQm94WzAu MCAwLjAgMTguMCAxOC4wXS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI5NC9SZXNvdXJjZXM8 PC9FeHRHU3RhdGU8PC9HUzA8PC9BSVMgZmFsc2UvQk0vTm9ybWFsL0NBIDAuNi9UeXBlL0V4dEdT dGF0ZS9jYSAwLjY+Pj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIieSS TU7EMAyFr/IuUGOn+T3BSEgsEEvEhiAG0MwCWHB9XtIWGgEnQJFqf67zEr/2FdbX2xGKZyYf8Lhi fCFf4vZO8YCLw43i+M6qchkKgmjRjHpGkuRhTqJFnDHt8YQpi/tmUtLUyLL/IpPoC+rG0yx5tmVv Zy9zDJsSKZW8HrNCxZ5OGDoHkeGEiuECJwy3Gy6+H6riCY+4pg+Hbpxu1qlE/dW9fdthbQ3lr9af DrcKnVUx75gycZkSyrfMvXWw0Czk3UvBZFIiQ5AQQis6bqQFsQUTPmtDdb4J5OiaJYWz8QizDsET Sh+XMjFkGO2kWJSUHGZxzm3gaWf/gAsmCVqaCD0rEvnUNVbsivvmUWchjhLTskH7qv/wV7vHpwAD ACFstbwNCmVuZHN0cmVhbQ1lbmRvYmoNMjMxIDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAxOC4wIDE4 LjBdL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjk0L1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8 L0dTMDw8L0FJUyBmYWxzZS9CTS9Ob3JtYWwvQ0EgMC42L1R5cGUvRXh0R1N0YXRlL2NhIDAuNj4+ Pj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ5JJNTsQwDIWv8i5QY6f5 PcFISCwQS8SGIAbQzAJYcH1e0hYaASdAkWp/rvMSv/YV1tfbEYpnJh/wuGJ8IV/i9k7xgIvDjeL4 zqpyGQqCaNGMekaS5GFOokWcMe3xhCmL+2ZS0tTIsv8ik+gL6sbTLHm2ZW9nL3MMmxIplbwes0LF nk4YOgeR4YSK4QInDLcbLr4fquIJj7imD4dunG7WqUT91b1922FtDeWv1p8OtwqdVTHvmDJxmRLK t8y9dbDQLOTdS8FkUiJDkBBCKzpupAWxBRM+a0N1vgnk6JolhbPxCLMOwRNKH5cyMWQY7aRYlJQc ZnHObeBpZ/+ACyYJWpoIPSsS+dQ1VuyK++ZRZyGOEtOyQfuq//BXu8enAAMAIWy1vA0KZW5kc3Ry ZWFtDWVuZG9iag0yMzIgMCBvYmoNPDwvQkJveFswLjAgMC4wIDE4LjAgMTguMF0vRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAyOTQvUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvR1MwPDwvQUlTIGZh bHNlL0JNL05vcm1hbC9DQSAwLjYvVHlwZS9FeHRHU3RhdGUvY2EgMC42Pj4+Pj4+L1N1YnR5cGUv Rm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSInkkk1OxDAMha/yLlBjp/k9wUhILBBLxIYgBtDM AlhwfV7SFhoBJ0CRan+u8xK/9hXW19sRimcmH/C4YnwhX+L2TvGAi8ON4vjOqnIZCoJo0Yx6RpLk YU6iRZwx7fGEKYv7ZlLS1Miy/yKT6AvqxtMsebZlb2cvcwybEimVvB6zQsWeThg6B5HhhIrhAicM txsuvh+q4gmPuKYPh26cbtapRP3VvX3bYW0N5a/Wnw63Cp1VMe+YMnGZEsq3zL11sNAs5N1LwWRS IkOQEEIrOm6kBbEFEz5rQ3W+CeTomiWFs/EIsw7BE0oflzIxZBjtpFiUlBxmcc5t4Gln/4ALJgla mgg9KxL51DVW7Ir75lFnIY4S07JB+6r/8Fe7x6cAAwAhbLW8DQplbmRzdHJlYW0NZW5kb2JqDTIz MyAwIG9iag08PC9CQm94WzExNC4xOTEgMzEwLjE4MSA1MTUuODAyIDM4Ny4zNTldL0ZpbHRlclsv RmxhdGVEZWNvZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDI2MC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4w IC0xMTQuMTkxIC0zMTAuMTgxXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9G b3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiWTSO27EMAwE0N6n0AkEUqQ+PM8C2WbTpMn1Qy2W GUvqjDFm/CCLEydKP8+Lcqu9pt+LuWUzq0l6y5WJ07dn6o9mno1sw1pCMvyhkib0Rs9U/NXjqlw8 E0X28qxm7YLifxDbaIXgcX3dXK2ertZ3V5fd5WvhIppfaMjcRTIZjCaSWEcvDKus6imrbZe1sst8 7SNTUc+0IXt51t2hBU0ksY5eGFaZlFM2K6tMaZepnGcW2f3Mookk1tELwyorfMqK7LJiu8zX4szG +74YMj+z8b5UiuYt+ayjF4ZVxnTK5tVcZTx2ma+FzOZfkY7MZTb/nRQ0b8lnHb0wTNmfAAMAgmi3 zg0KZW5kc3RyZWFtDWVuZG9iag0yMzQgMCBvYmoNPDwvQkJveFswLjAgMC4wIDQwMS42MTEgNzcu MTc3NF0vRm9ybVR5cGUgMS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4 WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmpl Y3Q8PC9Gb3JtIDIzMyAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K L0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTIzNSAwIG9iag08PC9CQm94WzAuMCAwLjAgNDAx LjYxMSA3Ny4xNzc0XS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4w IDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRp cGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSAy MzQgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdG T0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTI1MSAwIG9iag08PC9CQm94Wzc4LjE5MTcgMzc2 LjE4MSAxNDkuODA3IDM4Ny4zNTldL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0 aCA5OC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC03OC4xOTE3IC0zNzYuMTgxXS9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTN MQ6AMAgF0J1TcAICFQqcx0QXXVy8vji03X5e+B9GQcbnBKZubvhCCG7eyYQFb/Aga6xFQRnZcUIo mVX478OJWybuINopK026ipLUw1ZlyVidtfF5hwM+AQYAcMYevA0KZW5kc3RyZWFtDWVuZG9iag0y NTIgMCBvYmoNPDwvQkJveFswLjAgMC4wIDcxLjYxNTYgMTEuMTc3NF0vRm9ybVR5cGUgMS9Hcm91 cDw8L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAg MC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDI1MSAwIFI+Pj4+ L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL0Zvcm0gRG8KDQplbmRzdHJlYW0N ZW5kb2JqDTI1MyAwIG9iag08PC9CQm94WzAuMCAwLjAgNzEuNjE1NiAxMS4xNzc0XS9Gb3JtVHlw ZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8 L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+ Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSAyNTIgMCBSPj4+Pi9TdWJ0eXBlL0Zv cm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJlYW0N ZW5kb2JqDTI2MyAwIG9iag08PC9CQm94WzExNC4xOTEgMzc2LjE4MSA1MTUuODAyIDQzMS4zNTld L0ZpbHRlclsvRmxhdGVEZWNvZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDI3Mi9NYXRyaXhbMS4wIDAu MCAwLjAgMS4wIC0xMTQuMTkxIC0zNzYuMTgxXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4v U3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiWSSMXLEIAxFe5+CEzCSJQE6z85k m02TJtePlAFLxh3zzP9+CLBggfLzPqA26VJ+D8RWVVUKn1AFAcu3MbalqrGz6tBWEhlVBLhEjrDC aZ9eB4ttV6ZgH2NSuVNKJjLbI7ccXsdXMgN9miHuZth3M2ubZjScCQX7GFPz4JRMZLZHbjm4Gelw itmMtNlSWsoGWf1XLswEwBi1bCZAPiGMZCKzPXLZ7Dq7/+oxM4/cZwZtn5m1LTP0WyEOZmb4f3cR DDC7r9RlcPca/eHlY797kcrm5W3rlXVnHMgeWfeLI4lgkFV+xZbB3au3p1cfu9fg3cvaptfJfvKe 2MeYj6djJIOs9sgtBzf7E2AABta32A0KZW5kc3RyZWFtDWVuZG9iag0yNjQgMCBvYmoNPDwvQkJv eFswLjAgMC4wIDQwMS42MTEgNTUuMTc3NF0vRm9ybVR5cGUgMS9Hcm91cDw8L1MvVHJhbnNwYXJl bmN5Pj4vTGVuZ3RoIDkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDI2MyAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9U eXBlL1hPYmplY3Q+PnN0cmVhbQ0KL0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTI2NiAwIG9i ag08PC9CQm94WzAuMCAwLjAgMzk1LjYxMSAzMy4xNzc0XS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9N YXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1Iw PDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZd L1hPYmplY3Q8PC9NV0ZPRm9ybSAyNjkgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0 Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTI2OCAwIG9i ag08PC9CQm94WzExNC4xOTEgNDQyLjE4MSA1MDkuODAyIDQ3NS4zNTldL0ZpbHRlclsvRmxhdGVE ZWNvZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDE2Ni9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0xMTQu MTkxIC00NDIuMTgxXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQpIiWTOMQ7DMAiF4d2n4AQIbLDDeSI1S7p06fWLpVJSZ4t+65GP gYHgdRTCrkPhXZg7mpmCdEFlYnh6m59m3vxxsw5ZRkVVEsjdUKTqT3tRmq1d2unNUEbjXGaJ67kL w14eF5m2u0x1lXVeZX7tK5NB3iTT6alNRs9hljj+m4Xg3yX17hJZXUqry6+FS7f5g5rNYe5xxpbL LHE9d2GYso8AAwDmxV27DQplbmRzdHJlYW0NZW5kb2JqDTI2OSAwIG9iag08PC9CQm94WzAuMCAw LjAgMzk1LjYxMSAzMy4xNzc0XS9Gb3JtVHlwZSAxL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9M ZW5ndGggOS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0gMjY4IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9i amVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMjcxIDAgb2JqDTw8L0JC b3hbMC4wIDAuMCA0MDEuNjExIDU1LjE3NzRdL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwL01hdHJpeFsx LjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMg ZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+L1Byb2NTZXRbL1BERl0vWE9iamVj dDw8L01XRk9Gb3JtIDI2NCAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVh bQ0KL1IwIGdzCi9NV0ZPRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMjc0IDAgb2JqDTw8L0xl bmd0aCAzNTAxL1N1YnR5cGUvWE1ML1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJl Z2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxu czp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4yLWMwMDEgNjMu MTM5NDM5LCAyMDEwLzA5LzI3LTEzOjM3OjI2ICAgICAgICAiPgogICA8cmRmOlJERiB4bWxuczpy ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6 Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkdQTCBHaG9z dHNjcmlwdCA5LjAyPC9wZGY6UHJvZHVjZXI+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAg ICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4bXA9Imh0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgogICAgICAgICA8eG1wOk1vZGlmeURhdGU+MjAx Mi0wMS0xM1QxODozNjoyMi0wNTowMDwveG1wOk1vZGlmeURhdGU+CiAgICAgICAgIDx4bXA6Q3Jl YXRlRGF0ZT4yMDEyLTAxLTAxVDIxOjUzOjU2KzAxOjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAgICAg ICAgPHhtcDpDcmVhdG9yVG9vbD5HTlUgRW5zY3JpcHQgMS42LjUuMjwveG1wOkNyZWF0b3JUb29s PgogICAgICAgICA8eG1wOk1ldGFkYXRhRGF0ZT4yMDEyLTAxLTEzVDE4OjM2OjIyLTA1OjAwPC94 bXA6TWV0YWRhdGFEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5h ZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eG1wTU06RG9jdW1lbnRJRD40NTAzNDk3 MC02Y2Q3LTExZWMtMDAwMC1hMzU5NjI2ODQ1M2M8L3htcE1NOkRvY3VtZW50SUQ+CiAgICAgICAg IDx4bXBNTTpJbnN0YW5jZUlEPnV1aWQ6MGY4ZTVjYjgtMDhiYy00YTk2LTkyYjQtZDJjZjQ1ZTE3 YjI0PC94bXBNTTpJbnN0YW5jZUlEPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlv bi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFs dD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5FbnNjcmlwdCBP dXRwdXQ8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRpdGxl PgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNr ZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NZW5kb2JqDTQ5MyAwIG9iag08PC9BY3JvRm9ybSA0OTgg MCBSL01ldGFkYXRhIDI3NCAwIFIvTmFtZXMgNDk5IDAgUi9QYWdlcyA0ODkgMCBSL1R5cGUvQ2F0 YWxvZz4+DWVuZG9iag00OTYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTY0 Pj5zdHJlYW0NCniclVbLcuM2ELzrK6b2ErnKevkRO3vL2totbdYbx2ZVDlEOEAiSiEmCi4dt/X16 QOhlO8lGKhUpEGj09PQM+I2m4xlN+ZuushlM7i6odIMpfcKvHHwbzOIEShfZ0IcMky55ICsG/boZ Xc7o4vyUsmYwvFl8mdPvxj7otqRP1oSOvv/zy5hujNXC+vVR9tdgNqPsy2C4aL2yrfKjaysK/z/g 9j/zm6ujHwbDX1fO1Mor955+nJ6d03KoCxJdZ82jypdH/4bwWbRB2DXNjulkOjthNGbW5ion54UP wLz3os2FzR1lVsgHnjN/7rTl/T6Hek1n28WnpzG4V9vcKVGPvG4UxbhHCPwJctK1KlTrFBjfLa6X R0BI8rxBNWehRlr5YtToWo1sITna0Uq70fR87J89lp+cxOU/r5wHVx5hqHslg9V+TbqVOletd8fk gqxIOHJr51VD0jTQq9FO4Rm4Nbg8ahv4/wGtrtKuYh/sYUEfwq0WNZmCnLKPWqpj8utOS1FDIWgV ao8l5CuVSNXGuYPpufCix8J0E6xUjlbGV1SFRrTxQU92zBHFRQmKMw0u1sVJVwglQOVd2ItEFXlw nWHBMyUaR61Cmr2h1QZIfQu66zDYsxD5mh8L57SL7KFSE1oE5VkBnsQy871LeyWgrTj0pBGBN6bu yYGqVHlAhIzX1UIqbF8Yq1gaMhIwVrUYNUXC4ti9h/PG320kMsHXusUmYicR/KAfFbbdX7gXkWmp Ub4yUZICYdUaFaDIVcIixBeRUYVwag6d80ZPFTwZsUvbq6OeIVp8jtKUDH+8Ues4YfVZpoini0Si t0CjvS43pCT20g4Jg04kole53v+REdpB4KUQDGZY6ZYHIS8EkqITK45M9xnY6HOoQyqK5CuoSE+i t4KstIKIlS4rOGyTdaoxWLuEBYAkrwODW1NruaYyAKnPCUex5bpzirCbiKxiOn0XYjEkLLBSJErL hg2wMK3WUYjWGet1aCi4FONLJ26xYmS9CXkd10s/NN71jfvY8rgqPcqcblRjEkzG/180bYy4sEKm PFhByyLUNWMjPhQsEtt7P1b8XgNhUV3kgn0+XN3SxWVkFW9/2mODyYc7Ro24O8WDKDcyNFG5yFdt J9O8LSG0Sq7dbZ0J90AfDXtuOVzMs4/LIyToq/FcfMITmg2SWvIB56hBxkXtDOXwsdWrsDXcawLi pTac+AyUam4coNdXtd/NSlApLCiJ7Svvu/eTCdcTF8qDsmNu92Njy0ns/m6ScCb/rVJcsEfxUdQ6 TwXUiGfdwDTcffUzNab1lTtQKpYgBIDrQgdCKj+Gk2K7wh1ATDpzc3Zir9ueHB4AGwNyt4Iai+gX 3cZzucP7AItu4Fv1mr7DXoWKbTCBNJhu4/lieZXUMWUo0X5rZK/lZe9iT+PGag2KxbnxuwOh3nLx k4ZrVTzQuXL3T3RWeXhlurVFuXs2yu7M2Q0vhxIdl+cTewpvCcH5/nCAAzocS+z1TZPjknapKM7O IrHN69EbLzj9e8YBqdez/rgVpaLZn0CcZ4Pf8P0bkfAlDg0KZW5kc3RyZWFtDWVuZG9iag01MTMg MCBvYmoNPDwvQkJveFswLjAgMC4wIDQwMS42MTEgNDQuMTc3M10vRm9ybVR5cGUgMS9MZW5ndGgg MjAvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8 PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4vUHJvY1NldFsv UERGXS9YT2JqZWN0PDwvTVdGT0Zvcm0gNTE0IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9i amVjdD4+c3RyZWFtDQovUjAgZ3MKL01XRk9Gb3JtIERvCg0KZW5kc3RyZWFtDWVuZG9iag01MTQg MCBvYmoNPDwvQkJveFswLjAgMC4wIDQwMS42MTEgNDQuMTc3M10vRm9ybVR5cGUgMS9Hcm91cDw8 L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4w XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDUxNSAwIFI+Pj4+L1N1 YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5k b2JqDTUxNSAwIG9iag08PC9CQm94WzExNC4xOTEgNTYzLjE4MSA1MTUuODAyIDYwNy4zNTldL0Zp bHRlclsvRmxhdGVEZWNvZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwNi9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIC0xMTQuMTkxIC01NjMuMTgxXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3Vi dHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiWSQS26DIQwG95zCJ0D2jx/4PJHaTbrJ JtevUYrdkB0aaT4GCAgQHt8Nu4oJPBuzdndmENcuhAQ/wTiO7MFm9+kKSRTjIMiQnqJ1vNzh1gQx 2NBi92Cjsw0qM0mup5cNt/bViNYNLiBTdhnR6ohhmfZyi/h47ZcXa7uMrnUDF4syktVRYoK9XdYu eO8y/uwyPbvmdXbF2vljyf79WJpF9np5u+G9TMdnmcpZZnSWxdpf2WXr7UbF7sHWB6mWWWSvl7cb VtmvAAMApX18Gg0KZW5kc3RyZWFtDWVuZG9iag01MTYgMCBvYmoNPDwvQkJveFswLjAgMC4wIDE4 LjAgMTguMF0vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyOTQvUmVzb3VyY2VzPDwvRXh0R1N0 YXRlPDwvR1MwPDwvQUlTIGZhbHNlL0JNL05vcm1hbC9DQSAwLjYvVHlwZS9FeHRHU3RhdGUvY2Eg MC42Pj4+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSInkkk1OxDAMha/y LlBjp/k9wUhILBBLxIYgBtDMAlhwfV7SFhoBJ0CRan+u8xK/9hXW19sRimcmH/C4YnwhX+L2TvGA i8ON4vjOqnIZCoJo0Yx6RpLkYU6iRZwx7fGEKYv7ZlLS1Miy/yKT6AvqxtMsebZlb2cvcwybEimV vB6zQsWeThg6B5HhhIrhAicMtxsuvh+q4gmPuKYPh26cbtapRP3VvX3bYW0N5a/Wnw63Cp1VMe+Y MnGZEsq3zL11sNAs5N1LwWRSIkOQEEIrOm6kBbEFEz5rQ3W+CeTomiWFs/EIsw7BE0oflzIxZBjt pFiUlBxmcc5t4Gln/4ALJglamgg9KxL51DVW7Ir75lFnIY4S07JB+6r/8Fe7x6cAAwAhbLW8DQpl bmRzdHJlYW0NZW5kb2JqDTUxNyAwIG9iag08PC9CQm94WzAuMCAwLjAgMTguMCAxOC4wXS9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI5NC9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9HUzA8PC9B SVMgZmFsc2UvQk0vTm9ybWFsL0NBIDAuNi9UeXBlL0V4dEdTdGF0ZS9jYSAwLjY+Pj4+Pj4vU3Vi dHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIieSSTU7EMAyFr/IuUGOn+T3BSEgsEEvE hiAG0MwCWHB9XtIWGgEnQJFqf67zEr/2FdbX2xGKZyYf8LhifCFf4vZO8YCLw43i+M6qchkKgmjR jHpGkuRhTqJFnDHt8YQpi/tmUtLUyLL/IpPoC+rG0yx5tmVvZy9zDJsSKZW8HrNCxZ5OGDoHkeGE iuECJwy3Gy6+H6riCY+4pg+Hbpxu1qlE/dW9fdthbQ3lr9afDrcKnVUx75gycZkSyrfMvXWw0Czk 3UvBZFIiQ5AQQis6bqQFsQUTPmtDdb4J5OiaJYWz8QizDsETSh+XMjFkGO2kWJSUHGZxzm3gaWf/ gAsmCVqaCD0rEvnUNVbsivvmUWchjhLTskH7qv/wV7vHpwADACFstbwNCmVuZHN0cmVhbQ1lbmRv YmoNNTIxIDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAzNTMuNjExIDMzLjE3NzNdL0Zvcm1UeXBlIDEv TGVuZ3RoIDIwL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvRXh0 R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+L1By b2NTZXRbL1BERl0vWE9iamVjdDw8L01XRk9Gb3JtIDUyMiAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9U eXBlL1hPYmplY3Q+PnN0cmVhbQ0KL1IwIGdzCi9NV0ZPRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRv YmoNNTIyIDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAzNTMuNjExIDMzLjE3NzNdL0Zvcm1UeXBlIDEv R3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAg MC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9ybSA1MjMgMCBS Pj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg0KZW5kc3Ry ZWFtDWVuZG9iag01MjMgMCBvYmoNPDwvQkJveFsxMzIuMTkxIDY1MS4xODEgNDg1LjgwMiA2ODQu MzU5XS9GaWx0ZXJbL0ZsYXRlRGVjb2RlXS9Gb3JtVHlwZSAxL0xlbmd0aCAxNjYvTWF0cml4WzEu MCAwLjAgMC4wIDEuMCAtMTMyLjE5MSAtNjUxLjE4MV0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG XT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlkzjEOwzAIheHdp+AECAzY 5jyRmiVduvT6JVJcWmdDv/TQx8BA8NoLYbNu8C4siu5eoXVBY2J4Rqtxeotm6COOLIPRjBRyNxSp usNWtLdomumI5KhdLIdZ5vPvbAq28vhxtXp3NV1dnVZXfJuuUaOJZwvYsJOhucwyv+duGv5lxneZ ySozX2Xx7ZLJoGim2Y5oEg7LYYbrd66m4HR9BBgAas9dnQ0KZW5kc3RyZWFtDWVuZG9iag01MjYg MCBvYmoNPDwvQkJveFswLjAgMC4wIDM1OS42MTEgMzMuMTc3NF0vRm9ybVR5cGUgMS9MZW5ndGgg MjAvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8 PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4vUHJvY1NldFsv UERGXS9YT2JqZWN0PDwvTVdGT0Zvcm0gNTI3IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9i amVjdD4+c3RyZWFtDQovUjAgZ3MKL01XRk9Gb3JtIERvCg0KZW5kc3RyZWFtDWVuZG9iag01Mjcg MCBvYmoNPDwvQkJveFswLjAgMC4wIDM1OS42MTEgMzMuMTc3NF0vRm9ybVR5cGUgMS9Hcm91cDw8 L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4w XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDUyOCAwIFI+Pj4+L1N1 YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5k b2JqDTUyOCAwIG9iag08PC9CQm94WzEzMi4xOTEgMzIxLjE4MSA0OTEuODAyIDM1NC4zNTldL0Zp bHRlclsvRmxhdGVEZWNvZGVdL0Zvcm1UeXBlIDEvTGVuZ3RoIDE2My9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIC0xMzIuMTkxIC0zMjEuMTgxXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3Vi dHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiWSOMQ7DMAhFd5+CEyBjIDbnidQs6dKl 1y+pSkmczXrofT8CggqvrVRctCu8C7GgmTVgYVSqBE9nzZ+2OFO04Y8kSqhaBdJTwdrMYC0yhjMe yfYiRiidOc0ksZ5eNKzlcSr7fj6VHcdrmdS5zNduZcHOZWEmifX0ouFa1uhe1nguazaX+elXRnaw wcl2Z907+jiZSWL970XDUfYRYABnZl33DQplbmRzdHJlYW0NZW5kb2JqDTUzMiAwIG9iag08PC9C Qm94WzAuMCAwLjAgMzcxLjYxMSA0NC4xNzczXS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhb MS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlT IGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmpl Y3Q8PC9NV0ZPRm9ybSA1MzMgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTUzMyAwIG9iag08PC9C Qm94WzAuMCAwLjAgMzcxLjYxMSA0NC4xNzczXS9Gb3JtVHlwZSAxL0dyb3VwPDwvUy9UcmFuc3Bh cmVuY3k+Pi9MZW5ndGggOS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0gNTM0IDAgUj4+Pj4vU3VidHlwZS9Gb3Jt L1R5cGUvWE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNNTM0IDAg b2JqDTw8L0JCb3hbMTMyLjE5MSA1MzAuMTgxIDUwMy44MDIgNTc0LjM1OV0vRmlsdGVyWy9GbGF0 ZURlY29kZV0vRm9ybVR5cGUgMS9MZW5ndGggMTk5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgLTEz Mi4xOTEgLTUzMC4xODFdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0v VHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJZM4xDsMwCIXh3afwCSywwZjzRGqXdOnS65dEISTOZv3S wx9mzJC/7wSls3D+JWxUVLVm7q0wAuaPtWpP7da46LBHFMHCDJRjJ1SgquYlkW6tSbTVmhSSVmMZ xa/Hzg1Lel1kXJ8yplnWYZbZNZcJWKNIBpO2MS7DKH78nLng7iJ8uqjNLtLZZdcOF8P2wf5ldRjD zsBYXspxPXZuuMsaPGX2mGRtzDK7dshwDGuDoq0JFc0hellG8evnzg2b7C/AAF21e8wNCmVuZHN0 cmVhbQ1lbmRvYmoNNTM4IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAzNzcuNjExIDMzLjE3NzRdL0Zv cm1UeXBlIDEvTGVuZ3RoIDIwL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3Vy Y2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3Rh dGU+Pj4+L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L01XRk9Gb3JtIDUzOSAwIFI+Pj4+L1N1YnR5 cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL1IwIGdzCi9NV0ZPRm9ybSBEbwoNCmVuZHN0 cmVhbQ1lbmRvYmoNNTM5IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAzNzcuNjExIDMzLjE3NzRdL0Zv cm1UeXBlIDEvR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4w IDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9y bSA1NDAgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERv Cg0KZW5kc3RyZWFtDWVuZG9iag01NDAgMCBvYmoNPDwvQkJveFsxMzIuMTkxIDQ3NS4xODEgNTA5 LjgwMiA1MDguMzU5XS9GaWx0ZXJbL0ZsYXRlRGVjb2RlXS9Gb3JtVHlwZSAxL0xlbmd0aCAxNzEv TWF0cml4WzEuMCAwLjAgMC4wIDEuMCAtMTMyLjE5MSAtNDc1LjE4MV0vUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlkzjEOwyAM heGdU/gElg024PNEapd06dLr11QFt2RDv/Kcj4GB4HlPhFWbwitxETSzDGINlYnh4S3706o3Q+v+ WEVJUZUE1k6pI2UzOJJS9VY02unNUFrhWK6yrq/dMhzp9iPr9SrrfZOJySYb176yz+dWerQzifFw lFhGmddjNw3/sqZXWWu7rJdd5temLI8/SIvmsjIckmMZZV6P3TQM2VuAAQDXeF5xDQplbmRzdHJl YW0NZW5kb2JqDTU0NCAwIG9iag08PC9CQm94WzAuMCAwLjAgNDAxLjYxMSAzMy4xNzc0XS9Gb3Jt VHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNl czw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRl Pj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSA1NDUgMCBSPj4+Pi9TdWJ0eXBl L0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJl YW0NZW5kb2JqDTU0NSAwIG9iag08PC9CQm94WzAuMCAwLjAgNDAxLjYxMSAzMy4xNzc0XS9Gb3Jt VHlwZSAxL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9MZW5ndGggOS9NYXRyaXhbMS4wIDAuMCAw LjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0g NTQ2IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoN CmVuZHN0cmVhbQ1lbmRvYmoNNTQ2IDAgb2JqDTw8L0JCb3hbMTE0LjE5MSAzNzYuMTgxIDUxNS44 MDIgNDA5LjM1OV0vRmlsdGVyWy9GbGF0ZURlY29kZV0vRm9ybVR5cGUgMS9MZW5ndGggMTcwL01h dHJpeFsxLjAgMC4wIDAuMCAxLjAgLTExNC4xOTEgLTM3Ni4xODFdL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJZNAxDsMwCIXh 3afgBAhisM15IjVLunTp9Uuk2LjOFv3WQ5/CwEDwORJh0arwTcwFzUwhW0NlYnh7E/80AyFCa1Zg KgVVSWDshAxp86c9KW/eskQ7vSlKzTGMcN8eqyHY02tytfpw5WaLK5surutad9HV8tTc5URncCyj 9Oux64Z/WS1PWW2rrMkq82u3TNh/wpxOT9kZojGM0o+PWRdcrp8AAwAlz11tDQplbmRzdHJlYW0N ZW5kb2JqDTU1NiAwIG9iag08PC9CQm94WzAuMCAwLjAgMzc3LjYxMSAxMTAuMTc3XS9Gb3JtVHlw ZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8 L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+ Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSA1NTcgMCBSPj4+Pi9TdWJ0eXBlL0Zv cm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJlYW0N ZW5kb2JqDTU1NyAwIG9iag08PC9CQm94WzAuMCAwLjAgMzc3LjYxMSAxMTAuMTc3XS9Gb3JtVHlw ZSAxL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9MZW5ndGggOS9NYXRyaXhbMS4wIDAuMCAwLjAg MS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0gNTU4 IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVu ZHN0cmVhbQ1lbmRvYmoNNTU4IDAgb2JqDTw8L0JCb3hbMTMyLjE5MSA0OTcuMTgxIDUwOS44MDIg NjA3LjM1OV0vRmlsdGVyWy9GbGF0ZURlY29kZV0vRm9ybVR5cGUgMS9MZW5ndGggNTMxL01hdHJp eFsxLjAgMC4wIDAuMCAxLjAgLTEzMi4xOTEgLTQ5Ny4xODFdL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJZJU7rt0wDAX7uwqv wKDEj6T1PCBpbpo02X5Iw/xY7owDzNGYkuV2tAOOv78/cAoPPv59GtK51uoHLzm5QTv+aNb1cYlm 81xTHyIRoJMZ6AhOYJzQ1zp+Pr11zWZGX434pKErBRhJlDsWBj+fX5/erX/M6tW7WcxeUE+y3rni RcsyHFWM1lANLGQk0R7cwywnNvk9sTm2ifHCbWLW5mZz2gozMzNr5oFJZuLtybnD02zQ22zIbjb7 bqZtt1kbYJsimX01Q/Ww+QcZSbQH5w6X2by2mB5mE2zvVmEjif7g0oxB7N25mjEsm1BLMhNvT+5h Fu8u+J6Z8D6z0faZadtrNz2ru+lkJt6enDs8zbi/zZh2M4HdTNtuM0Sbo5Tsq5l9iDySzMTbk3MH M0OyFaSKIdmjUEEjiXrH0ouu/cVVvWiaBRYwEy9Prnrlm1N7T4xwnxitfWLa5mZse0IlUzO5dm4m WZK7PTl3eJohvM1syE8znLuZtrnZ9YVRRip2fYZYwJLc5YG5wdOrrbdXb7tXH7uXtvntv2wBmZnp 9b9MQzDJktztybnDdcbgOnlSzRBMfbRkS3L3J5dmDLYCSjVjwPt+cLIkzW8M56pZvjvM98wa7DNr ss9M2153mWf1LnOyJLDfZe7wMLNf2W5Ga+1mwLuZtvkp6zZHmpnpMev2HRImGUm0BxcOZvZfgAEA Huioxw0KZW5kc3RyZWFtDWVuZG9iag02NTEgMCBvYmoNPDwvQkJveFswLjAgMC4wIDk1LjYxNTIg MTEuMTc3M10vRm9ybVR5cGUgMS9MZW5ndGggMjAvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAg MC4wXS9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9U eXBlL0V4dEdTdGF0ZT4+Pj4vUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvTVdGT0Zvcm0gNjUyIDAg Uj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovUjAgZ3MKL01XRk9Gb3Jt IERvCg0KZW5kc3RyZWFtDWVuZG9iag02NTIgMCBvYmoNPDwvQkJveFswLjAgMC4wIDk1LjYxNTIg MTEuMTc3M10vRm9ybVR5cGUgMS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0 cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hP YmplY3Q8PC9Gb3JtIDY1MyAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVh bQ0KL0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTY1MyAwIG9iag08PC9CQm94WzMzMC4xODgg NjE4LjE4MSA0MjUuODAzIDYyOS4zNTldL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xl bmd0aCAxMDMvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAtMzMwLjE4OCAtNjE4LjE4MV0vUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K SIlMzkEKQzEIRdG5q3grEDVq4noCv5N20km33xT6SWZy4D5UKATvBwln9MCHWjOuSkPq4FBRvJbJ OjORJlyjEockR4hjd1YsVoVJbj/zse25LNi7t10e8l/f3f3DpIu+AgwAcJchuw0KZW5kc3RyZWFt DWVuZG9iag02NTQgMCBvYmoNPDwvQkJveFswLjAgMC4wIDk1LjYxNTIgMTEuMTc3M10vRm9ybVR5 cGUgMS9MZW5ndGggMjAvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8 PC9FeHRHU3RhdGU8PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+ Pj4vUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvTVdGT0Zvcm0gNjU1IDAgUj4+Pj4vU3VidHlwZS9G b3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovUjAgZ3MKL01XRk9Gb3JtIERvCg0KZW5kc3RyZWFt DWVuZG9iag02NTUgMCBvYmoNPDwvQkJveFswLjAgMC4wIDk1LjYxNTIgMTEuMTc3M10vRm9ybVR5 cGUgMS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4WzEuMCAwLjAgMC4w IDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDY1 NiAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL0Zvcm0gRG8KDQpl bmRzdHJlYW0NZW5kb2JqDTY1NiAwIG9iag08PC9CQm94Wzk2LjE5MTQgNTk2LjE4MSAxOTEuODA3 IDYwNy4zNTldL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCAxMDAvTWF0cml4 WzEuMCAwLjAgMC4wIDEuMCAtOTYuMTkxNCAtNTk2LjE4MV0vUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlEzjEOgEAIRNGeU8wJ CGwW2DmPiTba2Hh9tXDtyCOf4HAYzk1MMypwCYeSLARTw81xyDs1aw89u8HEB2ldI6zji9JKrZFY xMdro/+2i9O1V/EPp8zbs5sPLLLKLcAAC+AhVw0KZW5kc3RyZWFtDWVuZG9iag02NTcgMCBvYmoN PDwvQkJveFswLjAgMC4wIDQwNy42MSA0NC4xNzczXS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRy aXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwv QUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hP YmplY3Q8PC9NV0ZPRm9ybSA2NTggMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5z dHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTY1OCAwIG9iag08 PC9CQm94WzAuMCAwLjAgNDA3LjYxIDQ0LjE3NzNdL0Zvcm1UeXBlIDEvR3JvdXA8PC9TL1RyYW5z cGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9ybSA2NTkgMCBSPj4+Pi9TdWJ0eXBlL0Zv cm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg0KZW5kc3RyZWFtDWVuZG9iag02NTkg MCBvYmoNPDwvQkJveFs5Ni4xOTE0IDUzMC4xODEgNTAzLjgwMiA1NzQuMzU5XS9GaWx0ZXJbL0Zs YXRlRGVjb2RlXS9Gb3JtVHlwZSAxL0xlbmd0aCAyMTIvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAt OTYuMTkxNCAtNTMwLjE4MV0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXT4+L1N1YnR5cGUvRm9y bS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlkjjGOwzAMBHu9gi8QSImkzPcEuGt8TZp8/9aIZDpO Jww0yxESYnr+Fq5uw+hVYqsRMci8VxMW+ivh1Ro3IKuxhdMJhlQzVjqloZVbBD1KVwXzRDvQqDrM 0kuypk9tnX+UnyLixz6+WVtRIoonds30rSZxfs+nh7XZpcpgemE7WEeGSppJ1np6q+GzTOW7DCO3 Mo17GdZmmfFxoXuyHezo6JLmhcz19FbDZ1nn77Le7mV9u5dhbZa1ge8xJNkOZuhwT/NC5np6q+Eo +xdgAKAvexANCmVuZHN0cmVhbQ1lbmRvYmoNNjYyIDAgb2JqDTw8L0JCb3hbMC4wIDAuMCA1My42 MTU5IDExLjE3NzNdL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAg MC4wIDAuMF0vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9BSVMgZmFsc2UvQk0vTXVsdGlw bHkvVHlwZS9FeHRHU3RhdGU+Pj4+L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L01XRk9Gb3JtIDY2 MyAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL1IwIGdzCi9NV0ZP Rm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNNjYzIDAgb2JqDTw8L0JCb3hbMC4wIDAuMCA1My42 MTU5IDExLjE3NzNdL0Zvcm1UeXBlIDEvR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5 L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG XS9YT2JqZWN0PDwvRm9ybSA2NjQgMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5z dHJlYW0NCi9Gb3JtIERvCg0KZW5kc3RyZWFtDWVuZG9iag02NjQgMCBvYmoNPDwvQkJveFszMzAu MTg4IDY4NC4xODEgMzgzLjgwNCA2OTUuMzU5XS9GaWx0ZXIvRmxhdGVEZWNvZGUvRm9ybVR5cGUg MS9MZW5ndGggMTAxL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgLTMzMC4xODggLTY4NC4xODFdL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCkiJRM4xDoAwCIXhnVO8ExBoC5bzNNFFFxevL0vbjXzJDygUgvciYbfD8FGthSO8wHtjU1E8 aZKje5pz9HBsicJm0rC7MJYSgUG1S5q1bXda5ZaXdjhh7V7V/GDQSb8AAwA7BCGHDQplbmRzdHJl YW0NZW5kb2JqDTc0OSAwIG9iag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNS9QcmVkaWN0b3Ig MTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPEY1REI2MTU5Qjk5QjAzNTNEMTlDMTlCQjM0QTk4 ODczPjwwMTZDM0UyREZDQjA2QzQxQTBBRkVBRkQ2RjUwRTlGMT5dL0luZm8gNDkxIDAgUi9MZW5n dGggMTQzMS9Sb290IDQ5MyAwIFIvU2l6ZSA3NTAvVHlwZS9YUmVmL1dbMSAzIDFdPj5zdHJlYW0N Cmje7Nd5UBZ1HAbw3X15BRQTCQu5EkERBcIDFcNQA+XSxiuIYtRkUEPFPCqBEEfMEcsDBSdkYijy CNMxRQ6F5JACVLxAAjFNRAQvDAXB992e3/cVWV5A3yb+qfGfZ5757Hd3f7vsvu+LwHF8EycIHP+A F0TOa6aIPJzLRKgV0N89oEQeDCK5KUOfYatA7r9PUqWF7vvhE+Ru1V7X5Oj+t1qQiU4kV3qgf7S9 GRkfTVKhjb4w8TEydgNJmQ76ksIm5LZ5JCW66CuyGpGblpGc74m+OucRcn0wSXEv9DXhD1keJTml hx55rwEZ4k5S0Bt9Y+BfyFUXSfJfQd9s/wC5rA9Jbh/06PJ65OJAkhP6bG1n77N1riDJ7Isel38P GRBBkmGAnvD+XeQc1d1IfRU9qegO0m8tyRFD9H2bbyNnZ5Mc6of+05M65PT3SA68hv5zfC3SO50k +XX0lF63kB5TSfYaoWfMqEG66pL80B890+AmcqI3yXfG6NnV1cjxoSQJJuh5F28gx20liTdFL3Sr Qo4aSPKNGfqZG9eRDutJYs3RLyz4EzmsB8n2N9AvFVxDWu8h2ToAveLgVaRlHsnXFuhXm/9AmoeR RA1ErxKuII0/I9lgiV7rUIk0VK050gr9rv9lpL5qPWsHoT9YWIHUMyYJH4z+SKccqfMFSag1enPE 70gtHZLPhwgiz5mUCaKoVD0tq2wg8pOXII8LSJYPheiOK4U89CEJHgbpbVcCqV9AstgWYhh3EVKr IFlkBzGyvQCpXkoSaA8x+fQ85Lo1yfw3IeZu5yBXPyCZ6wCxuHUWUplB4j8cMtiyGFK2jsRvBMRm 5xlIiQGJz0iIncVpyLlNJLNGQYannYKcbiSZ7ghxNC2CFMSSTBsNGetZCMlXvadeYyDjrQsg2dtI 3MdCJrr8BslU/XXcnCCuLr9CMtaQTBoHmWKcD0lV/ZVd3oJ43D8JSVG9O87OkKk5eZBDchKn8ZCZ 83IhyYtIRr8N8U3Pgew2JBnpAvE3yIYkZpE4TIDMbzkB2VVGYjcRsij/F0iMPsnQSZDgmCzIFlcS 63cgq5ZnQjZ+TGLlCgnxPA6JjCGxcIOEZx2DRFiRmE+GRJZmQEJU77vJFEiUIh2yso7EyB2yzSQN suQsST8PSKxfKmThDhIDT0hcr6OQgGqSPl6QhPoUyBwZiZ43JCngCMRvOyfw/L4oDt1nNevJeCs5 TmiQ5BWW/G02M62Eda4HJd99yfOHHeksTm3n8tpDW7XaJnkNjpMSRGuuZUfw2M8kbQLr7rmsp/vR cSKYTB7C5Fge624udASByfHLTFwHtYrqyPj2+bJbr5rj26WSE4MVrPeVnDGi+47PQtFhssMMp3jx OpfTjLFknStbO7Z+RV0m2fqJZOuWDluXSrZGt26FB3W2fszE0IxccoTAf3MH6Lw7qOtJjjn3RXcY e8VT15bs5d/FZGKHNft1MZnUflKa2Gu2ZDJZcq9m8J1f79Orbunmt1UtZdzzzv4y/yupTOnw5Cjb uiCyp24X+4QsDECKYwR6Dukzs8iffWY67qan8ccXPQ/Yy7eFTTYbkYgapcgXj7jHPr3NWr8jkHtb v6d40dZGLpnH/wV8aVFzu3leHGIrPF2DyJfPUqhttfq+P229+WymslxUm7Ew6ym5FvzfwV+LbFSb MVvRW22myqCBrVMy0/+G/tPVKjllv3rqXCeJ21un/Ww9NQlN7c4lioZLuC73fZn/18RTcVvWxZui 2+m7c2dHs/q7Q795pCI4UzelrGNPac8y+bMjNJY+aT8vyt2oW9KqwqiHdeihXXgXXVigwWRI5y6L 6vzsWt+2uVCjwRoGPG/l/E6NryhU06vW5C4JEequ0ZFD/tn9l1VKzhjd+iTgJ8kklrrhSD7Fnvtb gAEA7CarAg0KZW5kc3RyZWFtDWVuZG9iag1zdGFydHhyZWYNCjEzMDMxMg0KJSVFT0YNCg== --_003_D7A0423E5E193F40BE6E94126930C493090146C7F3MBCLUSTERxcha_ Content-Type: application/xml; name="rid-trace-request-example-7.1.1.xml" Content-Description: rid-trace-request-example-7.1.1.xml Content-Disposition: attachment; filename="rid-trace-request-example-7.1.1.xml"; size=7686; creation-date="Fri, 13 Jan 2012 19:15:53 GMT"; modification-date="Fri, 13 Jan 2012 19:15:53 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+PGlv ZGVmLXJpZDpSSUQgeG1sbnM6aW9kZWYtcmlkPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVm LXJpZC0xLjIiIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCIg eG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeHNp OnNjaGVtYUxvY2F0aW9uPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0xLjIgaW9k ZWYtcmlkLTEuMi54c2QiPg0KICAgIDxpb2RlZi1yaWQ6UklEUG9saWN5IE1zZ0Rlc3RpbmF0aW9u PSJSSURTeXN0ZW0iIE1zZ1R5cGU9IlRyYWNlUmVxdWVzdCI+DQogICAgICAgIDxpb2RlZi1yaWQ6 UG9saWN5UmVnaW9uIHJlZ2lvbj0iSW50cmFDb25zb3J0aXVtIi8+DQogICAgICAgIDxpb2RlZjpO b2RlPg0KICAgICAgICAgICAgPGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImlwdjQtYWRkciI+MTky LjAuMi4zPC9pb2RlZjpBZGRyZXNzPg0KICAgICAgICA8L2lvZGVmOk5vZGU+DQogICAgICAgIDxp b2RlZi1yaWQ6VHJhZmZpY1R5cGUgdHlwZT0iQXR0YWNrIi8+DQogICAgICAgIDxpb2RlZjpJbmNp ZGVudElEIG5hbWU9IkNFUlQtRk9SLU9VUi1ET01BSU4iPg0KICAgICAgICAgICAgQ0VSVC1GT1It T1VSLURPTUFJTiMyMDctMQ0KICAgICAgICA8L2lvZGVmOkluY2lkZW50SUQ+DQogICAgICAgIDwh LS0gSU9ERUYtRG9jdW1lbnQgaW5jbHVkZWQgaW4gUklEIC0tPg0KICAgICAgICA8aW9kZWYtcmlk OlJlcG9ydFNjaGVtYSBWZXJzaW9uPSIxLjAiPg0KICAgICAgICAgICAgPGlvZGVmLXJpZDpYTUxE b2N1bWVudCBkdHlwZT0ieG1sIiBtZWFuaW5nPSJ4bWwiPg0KICAgICAgICAgICAgICAgIDxJT0RF Ri1Eb2N1bWVudCBsYW5nPSJlbiI+DQogICAgICAgICAgICAgICAgICAgIDxpb2RlZjpJbmNpZGVu dCBwdXJwb3NlPSJ0cmFjZWJhY2siIHJlc3RyaWN0aW9uPSJuZWVkLXRvLWtub3ciPg0KICAgICAg ICAgICAgICAgICAgICAgICAgPGlvZGVmOkluY2lkZW50SUQgbmFtZT0iQ0VSVC1GT1ItT1VSLURP TUFJTiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ0VSVC1GT1ItT1VSLURPTUFJTiMy MDctMQ0KICAgICAgICAgICAgICAgICAgICAgICAgPC9pb2RlZjpJbmNpZGVudElEPg0KICAgICAg ICAgICAgICAgICAgICAgICAgPGlvZGVmOkRldGVjdFRpbWU+MjAwNC0wMi0wMlQyMjo0OToyNCsw MDowMDwvaW9kZWY6RGV0ZWN0VGltZT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxpb2RlZjpT dGFydFRpbWU+MjAwNC0wMi0wMlQyMjoxOToyNCswMDowMDwvaW9kZWY6U3RhcnRUaW1lPg0KICAg ICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOlJlcG9ydFRpbWU+MjAwNC0wMi0wMlQyMzoyMDoy NCswMDowMDwvaW9kZWY6UmVwb3J0VGltZT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxpb2Rl ZjpEZXNjcmlwdGlvbj5Ib3N0IGludm9sdmVkIGluIERvUyBhdHRhY2s8L2lvZGVmOkRlc2NyaXB0 aW9uPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOkFzc2Vzc21lbnQ+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOkltcGFjdCBjb21wbGV0aW9uPSJmYWlsZWQiIHNl dmVyaXR5PSJsb3ciIHR5cGU9ImRvcyIvPg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9pb2Rl ZjpBc3Nlc3NtZW50Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOkNvbnRhY3Qgcm9s ZT0iY3JlYXRvciIgdHlwZT0ib3JnYW5pemF0aW9uIj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8aW9kZWY6Q29udGFjdE5hbWU+Q29uc3RpdHVlbmN5LWNvbnRhY3QgZm9yIDE5Mi4wLjIu MzUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2lvZGVmOkNvbnRhY3ROYW1lPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxpb2RlZjpFbWFpbD5Db25zdGl0dWVuY3ktY29udGFj dEAxOTIuMC4yLjM1PC9pb2RlZjpFbWFpbD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvaW9k ZWY6Q29udGFjdD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxpb2RlZjpFdmVudERhdGE+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOkZsb3c+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxpb2RlZjpTeXN0ZW0gY2F0ZWdvcnk9InNvdXJjZSI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8aW9kZWY6Tm9kZT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1h ZGRyIj4xOTIuMC4yLjM1DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC9pb2RlZjpBZGRyZXNzPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9p b2RlZjpOb2RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOlNl cnZpY2UgaXBfcHJvdG9jb2w9IjYiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxpb2RlZjpQb3J0PjM4NzY1PC9pb2RlZjpQb3J0Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9pb2RlZjpTZXJ2aWNlPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L2lvZGVmOlN5c3RlbT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGlvZGVmOlN5c3RlbSBjYXRlZ29yeT0idGFyZ2V0Ij4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxpb2RlZjpOb2RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxpb2RlZjpBZGRyZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiPjE5Mi4wLjIu NjcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2lvZGVmOkFkZHJl c3M+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2lvZGVmOk5vZGU+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8aW9kZWY6U2VydmljZSBpcF9wcm90 b2NvbD0iNiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVm OlBvcnQ+ODA8L2lvZGVmOlBvcnQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2lvZGVmOlNlcnZpY2U+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvaW9k ZWY6U3lzdGVtPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvaW9kZWY6Rmxvdz4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8aW9kZWY6RXhwZWN0YXRpb24gYWN0aW9uPSJyYXRl LWxpbWl0LWhvc3QiIHNldmVyaXR5PSJoaWdoIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGlvZGVmOkRlc2NyaXB0aW9uPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUmF0ZS1saW1pdCB0cmFmZmljIGNsb3NlIHRvIHNvdXJjZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L2lvZGVmOkRlc2NyaXB0aW9uPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvaW9kZWY6RXhwZWN0YXRpb24+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGlvZGVmOlJlY29yZD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVm OlJlY29yZERhdGE+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8aW9kZWY6 RGVzY3JpcHRpb24+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhl IElQdjQgcGFja2V0IGluY2x1ZGVkIHdhcyB1c2VkIGluIHRoZSBkZXNjcmliZWQgYXR0YWNrDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2lvZGVmOkRlc2NyaXB0aW9uPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOlJlY29yZEl0ZW0gZHR5 cGU9ImlwdjQtcGFja2V0Ij40NTAwMDA1MjJhZDkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAwMDAwZmYwNmM0MWZjMGE4MDEwMjBhMDEwMTAyOTc2ZDAwNTAxMDNlMDIw ODEwZDkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA0YTEzNTAwMjEw MDBhZDY3MDAwMDU0Njg2MTZlNmIyMDc5NmY3NTIwNjY2ZjcyMjANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA2MzYxNzI2NTY2NzU2YzZjNzkyMDcyNjU2MTY0Njk2ZTY3 MjA3NDY4Njk3MzIwNTINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA0 NjQzMmUwYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9pb2RlZjpSZWNv cmRJdGVtPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2lvZGVmOlJlY29yZERh dGE+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9pb2RlZjpSZWNvcmQ+DQogICAgICAg ICAgICAgICAgICAgICAgICA8L2lvZGVmOkV2ZW50RGF0YT4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxpb2RlZjpIaXN0b3J5Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxpb2RlZjpI aXN0b3J5SXRlbSBhY3Rpb249InJhdGUtbGltaXQtaG9zdCI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxpb2RlZjpEYXRlVGltZT4yMDAxLTA5LTE0VDA4OjE5OjAxKzAwOjAwPC9p b2RlZjpEYXRlVGltZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOklu Y2lkZW50SUQgbmFtZT0iQ1NJUlQtRk9SLU9VUi1ET01BSU4iPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ1NJUlQtRk9SLU9VUi1ET01BSU4jMjA3LTENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPC9pb2RlZjpJbmNpZGVudElEPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8aW9kZWY6RGVzY3JpcHRpb24+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOb3RpZmljYXRpb24gc2VudCB0byBuZXh0IHVwc3RyZWFtIFNQIGNs b3NlciB0byAxOTIuMC4yLjM1DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvaW9k ZWY6RGVzY3JpcHRpb24+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9pb2RlZjpIaXN0 b3J5SXRlbT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvaW9kZWY6SGlzdG9yeT4NCiAgICAg ICAgICAgICAgICAgICAgPC9pb2RlZjpJbmNpZGVudD4NCiAgICAgICAgICAgICAgICA8L0lPREVG LURvY3VtZW50Pg0KICAgICAgICAgICAgPC9pb2RlZi1yaWQ6WE1MRG9jdW1lbnQ+DQogICAgICAg ICAgICA8IS0tIEVuZCBvZiBJT0RFRi1Eb2N1bWVudCBpbmNsdWRlZCBpbiBSSUQgLS0+DQogICAg ICAgICAgICA8IS0tIFN0YXJ0IG9mIGRldGFjaGVkIFhNTCBzaWduYXR1cmUgaW5jbHVkZWQgaW4g UklEIC0tPg0KICAgICAgICAgICAgPGlvZGVmLXJpZDpEZXRhY2hlZFNpZ25hdHVyZSBkdHlwZT0i eG1sIiBtZWFuaW5nPSJ4bWwiPg0KICAgICAgICAgICAgICAgIDwhLS0gU2lnbmF0dXJlIG9mIElP REVGIG9ubHkgZG9jdW1lbnQsIHdpbGwgcmVwbGFjZSB3aGVuIGlvZGVmLXJpZC0xLjIgaXMgcG9z dGVkIC0tPg0KICAgICAgICAgICAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC8wOS94bWxkc2lnIyIgSWQ9ImRzaWctMTIzNDU2Ij48U2lnbmVkSW5mbz48Q2Fub25pY2Fs aXphdGlvbk1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1sLWV4 Yy1jMTRuIyIvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8y MDAxLzA0L3htbGRzaWctbW9yZSNyc2Etc2hhMjU2Ii8+PFJlZmVyZW5jZSBVUkk9IiI+PFRyYW5z Zm9ybXM+PFRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1s LWV4Yy1jMTRuIyIvPjxUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAy LzA2L3htbGRzaWctZmlsdGVyMiI+PFhQYXRoIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAy LzA2L3htbGRzaWctZmlsdGVyMiIgeG1sbnM6ZHNpZz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8w OS94bWxkc2lnIyIgeG1sbnM6ZHNpZy10cmFucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMi8wNi94 bWxkc2lnLWZpbHRlcjIiIEZpbHRlcj0iaW50ZXJzZWN0Ij4vL2RzaWc6U2lnbmF0dXJlW0BJZCA9 ICdkc2lnLTEyMzQ1NiddL2FuY2VzdG9yOjppb2RlZi1yaWQ6UmVwb3J0U2NoZW1hL2lvZGVmLXJp ZDpYTUxEb2N1bWVudC9JT0RFRi1Eb2N1bWVudFsxXS9pb2RlZjpJbmNpZGVudFsxXS9pb2RlZjpF dmVudERhdGFbMV0vaW9kZWY6UmVjb3JkWzFdL2lvZGVmOlJlY29yZERhdGFbMV0vaW9kZWY6UmVj b3JkSXRlbVsxXTwvWFBhdGg+PC9UcmFuc2Zvcm0+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2Qg QWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNzaGEyNTYiLz48RGln ZXN0VmFsdWU+TlF1SWhQamRadVpKblBpL2hXNjJkd0pUMWRSK3ZxY1pWOG1wZW1DVk41Zz08L0Rp Z2VzdFZhbHVlPjwvUmVmZXJlbmNlPjwvU2lnbmVkSW5mbz48U2lnbmF0dXJlVmFsdWU+bG5xL2VQ UTRBVnB4Q1IwaWZDcDlzTXNXMHIvQWRUM0MyR1IvemFOMVYraFovTkFwT3lnVWpNelRDUW54K1J2 R1BOa08vUlZxQkVJRA0KZ1pRVUVuUVpuL3VTYm1yMHRRNnhwQmZheEYxRENvc0xnaVp5KzJqRnpw WHJ3b04vakhOZ3R4Ui85UUxXOW1aK0k3VjZMRUVKNzNLdQ0KdCtkMG5hVEdIbHlpNjRhYjJQcXNW dVJYUTRwWFVLYmhNa2h6ZVRJcXZGTEs5M0tHZnNJTWQ2Q2IrbjJ1L0FCeUxrYytnZmxKWVVXVg0K UDREeGtRNGN5ZXg2aE02UllUUlVTcjdqVkQ5SzRkOEtGUDJnODVpNjlZTHRTdTAxVzFOcDBhZnBK NGE5TUswRTdJU01OUm1DOHdJaw0KbENBc1NYaUJScXlhRXdhU3kvY2x5YkkwdkNUUHFHT1loMy9T Wmc9PTwvU2lnbmF0dXJlVmFsdWU+PEtleUluZm8+PEtleVZhbHVlPjxSU0FLZXlWYWx1ZT48TW9k dWx1cz56OGFkclg5bTBTOE94SXhOK2Z1aTMzd2l6NFpZZ2I0eFBiUjlNUzVwT3AxQThrVnBINUV3 M042TzMvZE1zMmE0ZGlJeHlHTFZoMHI4DQo2UVhXSC9XNlQySUMybnkraGkraldSd1hydmdUWTNa QUZnZVB2ejJPZFJoVk4vY1ViT3RvNFBhNEkybVZaV1crL1EwRm43WXBxUEJEDQpEeGxHcS94eUZQ dVlxLzR5N1krQWgrdkhPMlpTYWlRamJqOEYzOFhyR2h3bGNiRlZ5SzhBbXhLM3oweld3WDg2dU1F cVZDalc2czZqDQoyS0FXZGJBakVwZ1pIbEpZODdpL0RxbkZneGZtZGczb3J1K1llaUVQVlJZOGh5 UXBZYnRncnl2ZVpPSFRnbkNIbVMvNTNVOWpTUzBjDQp5Yi9BRHVqMXVwZnlOb09pTU1nUXI3T2xo YzVwVHZ1V0FsNEZudz09PC9Nb2R1bHVzPjxFeHBvbmVudD5BUUFCPC9FeHBvbmVudD48L1JTQUtl eVZhbHVlPjwvS2V5VmFsdWU+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvaW9kZWYtcmlkOkRldGFj aGVkU2lnbmF0dXJlPg0KICAgICAgICAgICAgPCEtLSBFbmQgb2YgZGV0YWNoZWQgWE1MIHNpZ25h dHVyZSBpbmNsdWRlZCBpbiBSSUQgLS0+DQogICAgICAgIDwvaW9kZWYtcmlkOlJlcG9ydFNjaGVt YT4NCiAgICA8L2lvZGVmLXJpZDpSSURQb2xpY3k+DQo8L2lvZGVmLXJpZDpSSUQ+ --_003_D7A0423E5E193F40BE6E94126930C493090146C7F3MBCLUSTERxcha_-- From kathleen.moriarty@emc.com Fri Jan 13 17:37: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 1924421F85E3 for ; Fri, 13 Jan 2012 17:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 9b99jNWBuJTG for ; Fri, 13 Jan 2012 17:37:37 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF421F85F4 for ; Fri, 13 Jan 2012 17:37:36 -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 q0E1bWbp004065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 20:37:34 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 13 Jan 2012 20:37:18 -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 q0E1bFlx004691; Fri, 13 Jan 2012 20:37:15 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Fri, 13 Jan 2012 20:37:15 -0500 From: To: , Date: Fri, 13 Jan 2012 20:37:13 -0500 Thread-Topic: Comments for draft-ietf-mile-rfc6045-bis-05 Thread-Index: AczSUqFXbrsJPNCbQLCCdqFC79iz5wACRtGg 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Comments for draft-ietf-mile-rfc6045-bis-05 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, 14 Jan 2012 01:37:38 -0000 Hi Harold, Thank you very much for your review and comments! I was aware that the sig= nature was not working as specified. I appreciate receiving your signed ex= ample as I am having tool issues and was trying to resolve them to properly= sign the example (Oxygen digital signatures don't work perfectly). There = may be an opportunity to update the example right after the schema is poste= d if you can assist (assuming that was the issue with needing the schema be= ing co-located). I appreciate it!! =20 Thank you for the additional reference on specifying algorithms, I will inc= lude that in the update. There was a recent change to prevent the use of S= HA-1, so this is helpful. I will also include the "XML Digital Signature B= est Practices" reference. Using/requiring XPath Filter 2.0 makes sense. I will make that update. I'll change the name to Signature, that makes sense, thanks! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Boo= th, Harold Sent: Friday, January 13, 2012 7:23 PM To: mile@ietf.org Subject: [mile] Comments for draft-ietf-mile-rfc6045-bis-05 Hi, I was asked to comment on the document draft-ietf-mile-rfc6045-bis-05, sp= ecifically looking at its usage of XML Signature Syntax and Processing. I = have a number of specific comments that I have included in the attached pdf= . I have used the highlighting and commenting features of Adobe Reader, and= hopefully that will work for everyone. In addition to the specific comments in the attached document I noticed the= following: - The example including the digital signature did not validate for me. I h= ave attached an example that should validate created using my own tools. I = had to place an id on the signature element in order to get the xpath to wo= rk. Please note that the file assumes the schema for iodef-rid is co-locat= ed with the file and is named iodef-rid-1.2.xsd. There are likely some iss= ues with my working example, but I just figured I could provide a working o= ne if needed. - No mention of what algorithms are required for implementation of xml sign= ing. The default set of algorithms available in the current version of the= recommendation are very limited. The next version (1.1), which is still a= work in progress, is attempting to fix this but is not yet final. The last= version I saw was: http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303 - If you want additional algorithms to be used and to be interoperable, RFC= 4051 should be referenced as well as "XML Encryption Syntax and Processing"= , http://www.w3.org/TR/xmlenc-core/. As they both contain additional URIs = that should be used to identify the algorithms and methods. - No mention of "XML Signature Best Practices", http://www.w3.org/TR/xmldsi= g-bestpractices/ which contains a wealth of information regarding security = considerations when using xmldsig. I would also suggest that based upon th= ese recommendations that you consider what features of xmldsig should be us= ed. For example XSLT transforms might be restricted or disallowed. - "XML-Signature XPath Filter 2.0" provides better capabilities for selecti= ng nodes and you may want to consider using that in favor of the 1.0 versio= n. - This comment is also in the document but in case it gets lost, if the env= eloped signature is intended to be placed into the DetachedSignature elemen= t you may want to rename it to Signature. If not, guidance should be added = on where an enveloped signature should go. Not really from the document but: - The file name of the schema I initially received contains a space (which = is encoded as %20). This is somewhat unusual. Hope this helps. Regards, -Harold From harold.booth@nist.gov Fri Jan 13 19:45: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 3C72611E809D for ; Fri, 13 Jan 2012 19:45:07 -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 aRQCHlviz5MH for ; Fri, 13 Jan 2012 19:45:06 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6B46011E8083 for ; Fri, 13 Jan 2012 19:45:06 -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; Fri, 13 Jan 2012 22:44:45 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 13 Jan 2012 22:45:05 -0500 From: "Booth, Harold" To: "kathleen.moriarty@emc.com" , "mile@ietf.org" Date: Fri, 13 Jan 2012 22:41:55 -0500 Thread-Topic: Comments for draft-ietf-mile-rfc6045-bis-05 Thread-Index: AczSUqFXbrsJPNCbQLCCdqFC79iz5wACRtGgAASb3+A= 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: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [mile] Comments for draft-ietf-mile-rfc6045-bis-05 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, 14 Jan 2012 03:45:07 -0000 You're welcome and glad I could help. If you would like to make changes to the example I provided, either before or after you release a final version, I can work with you to get that done. Changing it up should be relatively quick on my end. Regards, -Harold -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] Sent: Friday, January 13, 2012 8:37 PM To: Booth, Harold; mile@ietf.org Subject: RE: Comments for draft-ietf-mile-rfc6045-bis-05 Hi Harold, Thank you very much for your review and comments! I was aware that the signature was not working as specified. I appreciate receiving your signed example as I am having tool issues and was trying to resolve them to properly sign the example (Oxygen digital signatures don't work perfectly). There may be an opportunity to update the example right after the schema is posted if you can assist (assuming that was the issue with needing the schema being co-located). I appreciate it!! Thank you for the additional reference on specifying algorithms, I will include that in the update. There was a recent change to prevent the use of SHA-1, so this is helpful. I will also include the "XML Digital Signature Best Practices" reference. Using/requiring XPath Filter 2.0 makes sense. I will make that update. I'll change the name to Signature, that makes sense, thanks! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Booth, Harold Sent: Friday, January 13, 2012 7:23 PM To: mile@ietf.org Subject: [mile] Comments for draft-ietf-mile-rfc6045-bis-05 Hi, I was asked to comment on the document draft-ietf-mile-rfc6045-bis-05, specifically looking at its usage of XML Signature Syntax and Processing. I have a number of specific comments that I have included in the attached pdf. I have used the highlighting and commenting features of Adobe Reader, and hopefully that will work for everyone. In addition to the specific comments in the attached document I noticed the following: - The example including the digital signature did not validate for me. I have attached an example that should validate created using my own tools. I had to place an id on the signature element in order to get the xpath to work. Please note that the file assumes the schema for iodef-rid is co-located with the file and is named iodef-rid-1.2.xsd. There are likely some issues with my working example, but I just figured I could provide a working one if needed. - No mention of what algorithms are required for implementation of xml signing. The default set of algorithms available in the current version of the recommendation are very limited. The next version (1.1), which is still a work in progress, is attempting to fix this but is not yet final. The last version I saw was: http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303 - If you want additional algorithms to be used and to be interoperable, RFC4051 should be referenced as well as "XML Encryption Syntax and Processing", http://www.w3.org/TR/xmlenc-core/. As they both contain additional URIs that should be used to identify the algorithms and methods. - No mention of "XML Signature Best Practices", http://www.w3.org/TR/xmldsig-bestpractices/ which contains a wealth of information regarding security considerations when using xmldsig. I would also suggest that based upon these recommendations that you consider what features of xmldsig should be used. For example XSLT transforms might be restricted or disallowed. - "XML-Signature XPath Filter 2.0" provides better capabilities for selecting nodes and you may want to consider using that in favor of the 1.0 version. - This comment is also in the document but in case it gets lost, if the enveloped signature is intended to be placed into the DetachedSignature element you may want to rename it to Signature. If not, guidance should be added on where an enveloped signature should go. Not really from the document but: - The file name of the schema I initially received contains a space (which is encoded as %20). This is somewhat unusual. Hope this helps. Regards, -Harold From kathleen.moriarty@emc.com Fri Jan 13 21:09: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 0C2CD21F857A for ; Fri, 13 Jan 2012 21:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 jZZ3rL88otW9 for ; Fri, 13 Jan 2012 21:09:10 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FE21F8577 for ; Fri, 13 Jan 2012 21:09:09 -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 q0E594DU024534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2012 00:09:07 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 14 Jan 2012 00:08:52 -0500 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0E58ole007707; Sat, 14 Jan 2012 00:08:51 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Sat, 14 Jan 2012 00:08:50 -0500 From: To: , Date: Sat, 14 Jan 2012 00:08:49 -0500 Thread-Topic: Comments for draft-ietf-mile-rfc6045-bis-05 Thread-Index: AczSUqFXbrsJPNCbQLCCdqFC79iz5wACRtGgAASb3+AAAwYaMA== 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Comments for draft-ietf-mile-rfc6045-bis-05 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, 14 Jan 2012 05:09:11 -0000 Awesome, I was hoping that would be the case since it was that easy with Ox= ygen (if it really worked)! I was thinking I needed to increment the schem= a version since there are some new enumeration values and should probably g= o to 2.0 for the published version. Thanks! Kathleen -----Original Message----- From: Booth, Harold [mailto:harold.booth@nist.gov]=20 Sent: Friday, January 13, 2012 10:42 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: Comments for draft-ietf-mile-rfc6045-bis-05 You're welcome and glad I could help. If you would like to make changes to = the example I provided, either before or after you release a final version,= I can work with you to get that done. Changing it up should be relatively= quick on my end. Regards, -Harold -----Original Message----- From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com]=20 Sent: Friday, January 13, 2012 8:37 PM To: Booth, Harold; mile@ietf.org Subject: RE: Comments for draft-ietf-mile-rfc6045-bis-05 Hi Harold, Thank you very much for your review and comments! I was aware that the sig= nature was not working as specified. I appreciate receiving your signed ex= ample as I am having tool issues and was trying to resolve them to properly= sign the example (Oxygen digital signatures don't work perfectly). There = may be an opportunity to update the example right after the schema is poste= d if you can assist (assuming that was the issue with needing the schema be= ing co-located). I appreciate it!! =20 Thank you for the additional reference on specifying algorithms, I will inc= lude that in the update. There was a recent change to prevent the use of S= HA-1, so this is helpful. I will also include the "XML Digital Signature B= est Practices" reference. Using/requiring XPath Filter 2.0 makes sense. I will make that update. I'll change the name to Signature, that makes sense, thanks! Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Boo= th, Harold Sent: Friday, January 13, 2012 7:23 PM To: mile@ietf.org Subject: [mile] Comments for draft-ietf-mile-rfc6045-bis-05 Hi, I was asked to comment on the document draft-ietf-mile-rfc6045-bis-05, sp= ecifically looking at its usage of XML Signature Syntax and Processing. I = have a number of specific comments that I have included in the attached pdf= . I have used the highlighting and commenting features of Adobe Reader, and= hopefully that will work for everyone. In addition to the specific comments in the attached document I noticed the= following: - The example including the digital signature did not validate for me. I h= ave attached an example that should validate created using my own tools. I = had to place an id on the signature element in order to get the xpath to wo= rk. Please note that the file assumes the schema for iodef-rid is co-locat= ed with the file and is named iodef-rid-1.2.xsd. There are likely some iss= ues with my working example, but I just figured I could provide a working o= ne if needed. - No mention of what algorithms are required for implementation of xml sign= ing. The default set of algorithms available in the current version of the= recommendation are very limited. The next version (1.1), which is still a= work in progress, is attempting to fix this but is not yet final. The last= version I saw was: http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303 - If you want additional algorithms to be used and to be interoperable, RFC= 4051 should be referenced as well as "XML Encryption Syntax and Processing"= , http://www.w3.org/TR/xmlenc-core/. As they both contain additional URIs = that should be used to identify the algorithms and methods. - No mention of "XML Signature Best Practices", http://www.w3.org/TR/xmldsi= g-bestpractices/ which contains a wealth of information regarding security = considerations when using xmldsig. I would also suggest that based upon th= ese recommendations that you consider what features of xmldsig should be us= ed. For example XSLT transforms might be restricted or disallowed. - "XML-Signature XPath Filter 2.0" provides better capabilities for selecti= ng nodes and you may want to consider using that in favor of the 1.0 versio= n. - This comment is also in the document but in case it gets lost, if the env= eloped signature is intended to be placed into the DetachedSignature elemen= t you may want to rename it to Signature. If not, guidance should be added = on where an enveloped signature should go. Not really from the document but: - The file name of the schema I initially received contains a space (which = is encoded as %20). This is somewhat unusual. Hope this helps. Regards, -Harold From kathleen.moriarty@emc.com Sat Jan 14 08:10:53 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 C8D0721F846A for ; Sat, 14 Jan 2012 08:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 g9sCosqQY6SN for ; Sat, 14 Jan 2012 08:10:53 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0937021F844A for ; Sat, 14 Jan 2012 08:10: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 q0EGAppZ012673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2012 11:10:51 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 14 Jan 2012 11:10:33 -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 q0EGAV9t010943; Sat, 14 Jan 2012 11:10:31 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Sat, 14 Jan 2012 11:10:31 -0500 From: To: , , Date: Sat, 14 Jan 2012 11:10:29 -0500 Thread-Topic: [mile] Comments on rfc6046-bis-05 Thread-Index: AczRQz6aN758GVNZRHyH/stR13n1DAAGY5XgAF5rwcA= Message-ID: References: <9BC18C12-EB57-4912-B78B-F04D8B6E34B5@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] Comments on rfc6046-bis-05 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, 14 Jan 2012 16:10:54 -0000 Hi All, The Result and Report are remaining as is in RFC6045-bis. However, I will = make it more clear that a status message (RequestAuthorization moving to 'A= cknowledgement') can be a valid response to any message type in case of err= ors or the inability to process a message. Nested within the TraceRequest = example, it does say that if there is a problem with the Result message, th= e response is an Acknowledgement (using the new name) to provide the reason= or 'Justification'. I think the listings Paul suggested will help clear u= p this confusion. I also went through all of the text to make sure this is= very consistently described. This is not a change, but making the text mo= re clear. Thank you, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Thursday, January 12, 2012 2:11 PM To: trammell@tik.ee.ethz.ch; david.waltermire@nist.gov Cc: mile@ietf.org Subject: Re: [mile] Comments on rfc6046-bis-05 Hello Brian, If you take a look at section 7.3 of RID, you'll see that a possible respon= se to a Report is a RequestAuthorization message. The RequestAuthorization= message name is misleading, hence David & Paul's request to rename it to A= cknowledgement. The RequestAuthorization responds with a 'yes', 'no', or '= pending' as the RequestStatus and a 'Justification' as to why the Report is= rejected. A Result is really just a slight variant of a Report message, but if there = were problems with the format, you would need to provide that response. Ha= ving it as a variant of the Report solves this use case. Thanks, Kathleen (as RFC6045-bis author) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Thursday, January 12, 2012 10:59 AM To: Waltermire, David A. Cc: mile@ietf.org Subject: Re: [mile] Comments on rfc6046-bis-05 Hi, David, all, Thank you for the comments; comments thereon inline. On Jan 11, 2012, at 5:20 PM, Waltermire, David A. wrote: > Kathleen, et al, >=20 > After reviewing the document it is not clear to me if all the HTTP status= codes are correct in Table 1. =20 >=20 > Considering the HTTP status codes used: >=20 > http://datatracker.ietf.org/doc/rfc2616/?include_text=3D1 >=20 > 200 OK - indicates that "the request has succeded." > 202 Accepted - indicates that "the request has been accepted for processi= ng, but the processing has not been completed." >=20 > The callbacks defined in table 1 provide a mechanism to asyncronously res= pond during various data flows. The 202 status code required for the callba= cks indicate that the information provided in the request have been accepte= d, but not processed. It might make sense to use a 200 status code instead = to indicate that the message has been received and processed as there is no= futher mechanism defined for the receiver to acknowledge processing. This= is especially true for RequestAuthorization messages which should be immed= iately processable. Correct; this is an error in the table. The intention is that callbacks be = answered with a 200. I'll correct this in the -06 rev of the document. > This also raises a question regarding rfc6045-bis-05. How would a RID sys= tem reject a Result or Report that has been posted? Reasons for rejection m= ight be due to content contained in the message that would prevent the orga= nization from accepting the message for legal or policy reasons. For exampl= e if the message contained information of a need-to-know or propriatary nat= ure for which the receiving organization is not authorized. What would be t= he mechanism for communicating this rejection back to the submitter? I'll leave this question to Kathleen to answer authoritatively; however AFA= IK RID has no method for rejecting a report or result, because each such me= ssage is essentially declarative ("I saw this") -- aside from the authoriza= tions and requests RID is fire-and-forget, and rejection is irrelevant as f= ar as the reporter is concerned. Adding a mechanism to RID at this point to= handle ack/nak would change this model. Thanks again, and best regards, Brian (as 6046-bis author) _______________________________________________ mile mailing 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 Mon Jan 16 19:46: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 DB7E521F8549; Mon, 16 Jan 2012 19:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 ouAEMzPNEugK; Mon, 16 Jan 2012 19:46:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C5721F84B5; Mon, 16 Jan 2012 19:46:04 -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.64p1 Message-ID: <20120117034604.11676.9773.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2012 19:46:04 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-06.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: Tue, 17 Jan 2012 03:46:26 -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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-06.txt Pages : 80 Date : 2012-01-16 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-06.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-rfc6045-bis-06.txt From kathleen.moriarty@emc.com Mon Jan 16 19:50: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 D4FF321F8602 for ; Mon, 16 Jan 2012 19:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 rcHlFIuUHj33 for ; Mon, 16 Jan 2012 19:50:11 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id F014121F8600 for ; Mon, 16 Jan 2012 19:50:10 -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 q0H3o8wM018543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jan 2012 22:50:08 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 16 Jan 2012 22:49:52 -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 q0H3npkS009579 for ; Mon, 16 Jan 2012 22:49:52 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Mon, 16 Jan 2012 22:49:51 -0500 From: To: Date: Mon, 16 Jan 2012 22:49:50 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-06.txt Thread-Index: AczUyr+mrxvVxldUSgqE5cNQlIZdjAAAAyGg Message-ID: References: <20120117034604.11676.9773.idtracker@ietfa.amsl.com> In-Reply-To: <20120117034604.11676.9773.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-mile-rfc6045-bis-06.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: Tue, 17 Jan 2012 03:50:11 -0000 Thank you for the reviews and comments during last call! The updated versi= on of RID addresses all comments received during the last call period and a= re as follows: Updates the schema: Adds two Justification enumerations Adds language support with lang attribute at the top level Removes attributes that were listed in the UML description, but not=20 implemented in the schema URL definition fixed in schema Adds more references for XML digital signature and encryption guidance to=20 increase interoperability between implementations. Replaces the Traceback example, fixing the problem with the detached signat= ure=20 from the limit of a tool Removes the term network provider to use the more generic service provider= =20 everywhere in the document as it still appeared in a few places. Combines the definition of TraceRequest and Investigation into one definiti= on for=20 'Request' with the ability to still select either 'TraceRequest' or=20 InvestigationRequest' as the MsgType for parsing and handling purposes. Changes IncidentQuery name to the more generic 'Query' Changes the name RequestAuthorization to Acknowledgement as it more=20 appropriately fits the purpose of this message. The ability to respond to any message type with an Acknowledgement message= =20 was nested deeply in the communication flow section. The text has been adj= usted=20 to make sure this ability is clear and information is not conflicting throu= ghout the=20 document. The possible responses for messages are now succinctly described. It is now explicitly stated that a stream of Report messages are possible d= uring an=20 investigation. Since Report messages can be pushed asynchronously, this wa= s=20 possible, but not stated. IANA text and supporting information to send other XML documents over RID w= as=20 added, using CVRF as the example and first entry in the IANA registry. Thi= s ability=20 supports the application area review looking for extensibility and a reques= t to the=20 mailing list for this functionality. Fixed 'updates RFC6045' text according to AD guidance. Added in explicit text to state the use of shared keys is acceptable per th= e security=20 review recommendation. removed option for nesting enveloped signatures as the guidance on it is on= ly at a=20 high level and may result in incompatibility issues. Thank you! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Monday, January 16, 2012 10:46 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-06.txt 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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-06.txt Pages : 80 Date : 2012-01-16 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-06.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-rfc6045-bis-06.txt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From pkampana@cisco.com Mon Jan 16 20:33: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 414AA21F8584 for ; Mon, 16 Jan 2012 20:33:15 -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 k2rTEshWShKh for ; Mon, 16 Jan 2012 20:33:14 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E42E521F857A for ; Mon, 16 Jan 2012 20:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=8724; q=dns/txt; s=iport; t=1326774794; x=1327984394; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=EmY0PR0x2ja0IpmIR/xmwQwhNQvvG91n9M5CBtHQdNY=; b=K/ZJBzeUrCTToMrfmqTbYE24L6Iw0PJkuB8Cr/tU+jiZzBPWCuYj5Y5k k8PUy4kfGAZGKCDd02rFlsR8Geui+tRXGZecKJKmVaX+SaWmdDmVH88li ZgU31If3jA+09SpQABfVRTIWYasapLOCNyEoGsiKRUWiuQ6KX8U5xvtqY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAACr5FE+tJV2Y/2dsb2JhbAA6Cpx5gWuNTIEMgQWBcgEBAQMBAQEBBQoBFQIQNAUGBQcBAwIJDwIEAQEoBxkOHwkIAgQBEgkCF4dYCJdhAZ40iFpRAQEwAgEBCw8KARsHJgECAQkBAQEEAQGDAlcWAQEBAoMqBIg7hH+aNg X-IronPort-AV: E=Sophos;i="4.71,521,1320624000"; d="scan'208";a="51578775" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jan 2012 04:33:12 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0H4XCo2028452; Tue, 17 Jan 2012 04:33:12 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jan 2012 22:33:12 -0600 Received: from WINICH1QO6NCS6 ([10.82.254.70]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jan 2012 22:33:11 -0600 From: "Panos Kampanakis" To: , References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com><000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> Date: Mon, 16 Jan 2012 23:32:47 -0500 Organization: Cisco Systems Inc. Message-ID: <000001ccd4d1$10d80e30$32882a90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQGULmByYCUpvH5kVtZUifIc/i5AwJZh6blwgAi0MHCAAU9xZIAAMhJAgBUfFYA= Content-Language: en-us X-OriginalArrivalTime: 17 Jan 2012 04:33:11.0991 (UTC) FILETIME=[1EFAD470:01CCD4D1] Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Tue, 17 Jan 2012 04:33:15 -0000 I agree David. It seems the RID's XMLSchemaID and SCI's SpecificationID are equivalent and depict the included schema identifier. But for RID the XMLSchemaID is the namespace of the included schema (default IODEF), and in SCI the SpecificationID is the "notional" string ID for various schemata. For the Version, RID is IODEF version but in SCI it is the IODEF-SCI version. 2 inconsistencies that would be better if they matched in Rid and SCI. IMO, changing SCI's SpecificationID to be the IANA supported namespace for XDDF, CCE, CAPEC etc and making the Version to be the IODEF version (as in RID) would be sufficient. I am not sure why the IODEF-SCI version needs to be in the extension classes since it is included in the iodef-sci namespace definition earlier anyway. Rgs, Panos -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of david.black@emc.com Sent: Tuesday, January 03, 2012 12:48 PM To: kathleen.moriarty@emc.com Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt Hi Kathleen, > 3) Are you advocating for a specificationID to be included in addition to the namespace declaration? Not exactly ;-). I'm not "advocating" for inclusion of specificationID - rather I'd like to see RID and SCI be consistent in their use of SpecificationID and Version. For SpecificationID, that could be accomplished by adding it to RID or taking it out of SCI; both approaches seem reasonable to me. What do other people think ought to be done here and why? Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Tuesday, January 03, 2012 9:52 AM > To: Black, David; Takeshi Takahashi; mile@ietf.org > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Take and the other authors of the SCI draft are reviewing this issue. Feedback on how RID encapsulates > a document would be helpful. The approach used in RID is consistent with IODEF. > > I would like to clarify one of the assumptions from below to avoid confusion. > > 1) The version can be left out for IODEF when included in a RID document as it is listed in the > namespace definition, not because it is the default schema. In case other schemas also include the > version in the namespace declaration, this was left as optional. > > 3) Are you advocating for a specificationID to be included in addition to the namespace declaration? > > Thanks, > Kathleen (editor) > ________________________________________ > From: Black, David > Sent: Monday, January 02, 2012 2:31 PM > To: Takeshi Takahashi; mile@ietf.org > Cc: Moriarty, Kathleen > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Greetings, > > > The discussion on EM_XML is still an issue, so I'd appreciate if you could > > kindly share your opinion on that. > > (I personally like the idea Kathleen kindly proposed.) > > The new version tentatively deleted the description of EM_XML, and use the > > xml defined by the IODEF dtype. > > I also like Kathleen's suggested approach of using the IODEF dtype instead of EM_XML, especially as > that approach is also being used to include IODEF content in RID (see the ReportSchema class in draft- > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice seems like a good idea for > consistency. > > I think some more discussion would be useful (and would like to see the opinions of others), as I see > some differences between how this is being done in the rfc6045-bis draft vs. the sci draft: > > (1) Schema identification > > RID identifies the included XML schema by XML namespace and version. The XML namespace is in the > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, and the schema version is in the > Version or ext-Version attribute of that class. IODEF 1.0 is the default if these attributes are > omitted. > > SCI extension classes (e.g., AttackPattern) use an additional required SpecificationID attribute (a > short ENUM xsd:string) that includes both an acronym and the version of the specification - the XML > namespace is left to be declared by the included XML. > > (2) Version of schema vs. specification > > For RID, the Version or Version-ext attribute of the ReportSchema class contains the XML schema > version for the included XML. > > For SCI, the version that's part of the SpecificationID attribute of the extension classes is the > version of the specification for the included XML. This specification version may not match the > version of the XML schema defined by that specification. > > (3) Version - same attribute name used for two different purposes. > > For RID, the Version attribute of the ReportSchema class is the schema version for the included XML > for standard schemas (ext-Version is used for non-standard schemas). > > For SCI, the Version attribute of the extension classes is the version of the IODEF-SCI schema. > > My 0.02 (which isn't worth much more than that) is that SpecificationID seems to be useful as a > convenient human-readable string to identify the type of XML content (for RID, that could default to > IODEF if omitted), and I don't have a strong preference for the two version topics as long as a single > approach is adopted. > > Could others on the list speak up to provide opinions on how to handle these topics? > > Thanks, > --David > > > -----Original Message----- > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > Sent: Wednesday, December 28, 2011 12:52 AM > > To: mile@ietf.org > > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; Kent_Landfield@McAfee.com > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Hello all, > > > > I've just posted the new version of the mile-sci draft. > > Though the text has changed a lot, we basically have only two changes, as > > listed below: > > > > 1. table is changed (see section 4.1) > > 2. IANA description was totally changed > > > > The discussion on EM_XML is still an issue, so I'd appreciate if you could > > kindly share your opinion on that. > > (I personally like the idea Kathleen kindly proposed.) > > The new version tentatively deleted the description of EM_XML, and use the > > xml defined by the IODEF dtype. > > > > Thank you very much for those of you who kindly gave me lots of useful > > comments and supports. > > I wish you a happy new year. > > > > Sincerely, > > Take > > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > > > internet-drafts@ietf.org > > > Sent: Wednesday, December 28, 2011 2:40 PM > > > To: i-d-announce@ietf.org > > > Cc: mile@ietf.org > > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. This draft is a work item of the Managed Incident Lightweight > > > Exchange Working Group of the IETF. > > > > > > Title : IODEF-extension to support structured > > > cybersecurity information > > > Author(s) : Takeshi Takahashi > > > Kent Landfield > > > Thomas Millar > > > Youki Kadobayashi > > > Filename : draft-ietf-mile-sci-01.txt > > > Pages : 34 > > > Date : 2011-12-27 > > > > > > This document extends the Incident Object Description Exchange Format > > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > > cybersecurity information exchange among cybersecurity entities by > > > embedding structured information formatted by specifications, > > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) > > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL > > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > > > _______________________________________________ > > > mile mailing 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 Mon Jan 16 21:14: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 F0D8B21F8581 for ; Mon, 16 Jan 2012 21:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=0.075, 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 z077LQMPnzJv for ; Mon, 16 Jan 2012 21:14:33 -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 BD13121F857D for ; Mon, 16 Jan 2012 21:14:32 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q0H5EPmr001177; Tue, 17 Jan 2012 14:14:25 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q0H5EPKZ014833; Tue, 17 Jan 2012 14:14:25 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q0H5EPs8014830; Tue, 17 Jan 2012 14:14:25 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 756571676F; Tue, 17 Jan 2012 14:14:25 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 6E63716763; Tue, 17 Jan 2012 14:14:25 +0900 (JST) From: "Takeshi Takahashi" To: "'Panos Kampanakis'" , , References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com><000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> <000001ccd4d1$10d80e30$32882a90$@com> In-Reply-To: <000001ccd4d1$10d80e30$32882a90$@com> Date: Tue, 17 Jan 2012 14:14:25 +0900 Message-ID: <001c01ccd4d6$e13182f0$a39488d0$@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: AQGULmByYCUpvH5kVtZUifIc/i5AwAFJmbAoAhjiZJ0Bxi7GkwHAclepAegsa9aWOsPMsA== Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Tue, 17 Jan 2012 05:14:34 -0000 Hi Panos, Thank you for the kind comments. I agree to change the draft to avoid any inconsistency between the drafts. > IMO, changing SCI's SpecificationID to be the IANA supported namespace > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF version In this case, we do not need the "notional" string ID defined in the IANA table. Currently, each entry of the table has (ID, specification name, version, namespace, specification url, applicable classes). So, I would delete the "ID" and change the entry into (namespace, specification name, version, specification url, applicable classes) Also, for the rest of the comments, I like your proposal, and let me change the draft. I appreciate your assistance. Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Panos Kampanakis > Sent: Tuesday, January 17, 2012 1:33 PM > To: david.black@emc.com; kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > I agree David. > > It seems the RID's XMLSchemaID and SCI's SpecificationID are equivalent > and depict the included schema identifier. But for RID the XMLSchemaID > is the namespace of the included schema (default IODEF), and in SCI the > SpecificationID is the "notional" string ID for various schemata. For > the Version, RID is IODEF version but in SCI it is the IODEF-SCI version. > 2 inconsistencies that would be better if they matched in Rid and SCI. > > IMO, changing SCI's SpecificationID to be the IANA supported namespace > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF version > (as in > RID) would be sufficient. I am not sure why the IODEF-SCI version needs > to be in the extension classes since it is included in the iodef-sci > namespace definition earlier anyway. > > Rgs, > Panos > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > david.black@emc.com > Sent: Tuesday, January 03, 2012 12:48 PM > To: kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Hi Kathleen, > > > 3) Are you advocating for a specificationID to be included in addition > > to > the namespace declaration? > > Not exactly ;-). > > I'm not "advocating" for inclusion of specificationID - rather I'd like > to see RID and SCI be consistent in their use of SpecificationID and > Version. > For SpecificationID, that could be accomplished by adding it to RID or > taking it out of SCI; both approaches seem reasonable to me. > > What do other people think ought to be done here and why? > > Thanks, > --David > > > -----Original Message----- > > From: Moriarty, Kathleen > > Sent: Tuesday, January 03, 2012 9:52 AM > > To: Black, David; Takeshi Takahashi; mile@ietf.org > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Take and the other authors of the SCI draft are reviewing this issue. > Feedback on how RID encapsulates > > a document would be helpful. The approach used in RID is consistent > > with > IODEF. > > > > I would like to clarify one of the assumptions from below to avoid > confusion. > > > > 1) The version can be left out for IODEF when included in a RID > > document > as it is listed in the > > namespace definition, not because it is the default schema. In case > > other > schemas also include the > > version in the namespace declaration, this was left as optional. > > > > 3) Are you advocating for a specificationID to be included in addition > > to > the namespace declaration? > > > > Thanks, > > Kathleen (editor) > > ________________________________________ > > From: Black, David > > Sent: Monday, January 02, 2012 2:31 PM > > To: Takeshi Takahashi; mile@ietf.org > > Cc: Moriarty, Kathleen > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Greetings, > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if you > could > > > kindly share your opinion on that. > > > (I personally like the idea Kathleen kindly proposed.) The new > > > version tentatively deleted the description of EM_XML, and use > the > > > xml defined by the IODEF dtype. > > > > I also like Kathleen's suggested approach of using the IODEF dtype > > instead > of EM_XML, especially as > > that approach is also being used to include IODEF content in RID (see > > the > ReportSchema class in draft- > > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice seems > > like > a good idea for > > consistency. > > > > I think some more discussion would be useful (and would like to see > > the > opinions of others), as I see > > some differences between how this is being done in the rfc6045-bis > > draft > vs. the sci draft: > > > > (1) Schema identification > > > > RID identifies the included XML schema by XML namespace and version. > > The > XML namespace is in the > > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, > > and > the schema version is in the > > Version or ext-Version attribute of that class. IODEF 1.0 is the > > default > if these attributes are > > omitted. > > > > SCI extension classes (e.g., AttackPattern) use an additional required > SpecificationID attribute (a > > short ENUM xsd:string) that includes both an acronym and the version > > of > the specification - the XML > > namespace is left to be declared by the included XML. > > > > (2) Version of schema vs. specification > > > > For RID, the Version or Version-ext attribute of the ReportSchema > > class > contains the XML schema > > version for the included XML. > > > > For SCI, the version that's part of the SpecificationID attribute of > > the > extension classes is the > > version of the specification for the included XML. This specification > version may not match the > > version of the XML schema defined by that specification. > > > > (3) Version - same attribute name used for two different purposes. > > > > For RID, the Version attribute of the ReportSchema class is the schema > version for the included XML > > for standard schemas (ext-Version is used for non-standard schemas). > > > > For SCI, the Version attribute of the extension classes is the version > > of > the IODEF-SCI schema. > > > > My 0.02 (which isn't worth much more than that) is that > > SpecificationID > seems to be useful as a > > convenient human-readable string to identify the type of XML content > > (for > RID, that could default to > > IODEF if omitted), and I don't have a strong preference for the two > version topics as long as a single > > approach is adopted. > > > > Could others on the list speak up to provide opinions on how to handle > these topics? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > > Sent: Wednesday, December 28, 2011 12:52 AM > > > To: mile@ietf.org > > > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; > Kent_Landfield@McAfee.com > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > Hello all, > > > > > > I've just posted the new version of the mile-sci draft. > > > Though the text has changed a lot, we basically have only two > > > changes, > as > > > listed below: > > > > > > 1. table is changed (see section 4.1) 2. IANA description was > > > totally changed > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if you > could > > > kindly share your opinion on that. > > > (I personally like the idea Kathleen kindly proposed.) The new > > > version tentatively deleted the description of EM_XML, and use > the > > > xml defined by the IODEF dtype. > > > > > > Thank you very much for those of you who kindly gave me lots of > > > useful comments and supports. > > > I wish you a happy new year. > > > > > > Sincerely, > > > Take > > > > > > > > > > -----Original Message----- > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > Behalf > Of > > > > internet-drafts@ietf.org > > > > Sent: Wednesday, December 28, 2011 2:40 PM > > > > To: i-d-announce@ietf.org > > > > Cc: mile@ietf.org > > > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. This draft is a work item of the Managed Incident > Lightweight > > > > Exchange Working Group of the IETF. > > > > > > > > Title : IODEF-extension to support structured > > > > cybersecurity information > > > > Author(s) : Takeshi Takahashi > > > > Kent Landfield > > > > Thomas Millar > > > > Youki Kadobayashi > > > > Filename : draft-ietf-mile-sci-01.txt > > > > Pages : 34 > > > > Date : 2011-12-27 > > > > > > > > This document extends the Incident Object Description Exchange > Format > > > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > > > cybersecurity information exchange among cybersecurity entities > by > > > > embedding structured information formatted by specifications, > > > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], > CVE(R) > > > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] > > > > [CWSS], > OCIL > > > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > > > > > _______________________________________________ > > > > mile mailing 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 pkampana@cisco.com Tue Jan 17 06:38:51 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 9062B21F86DA for ; Tue, 17 Jan 2012 06:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=1.450, 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 qDyBRthJ3NTo for ; Tue, 17 Jan 2012 06:38:50 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 34BCB21F86D6 for ; Tue, 17 Jan 2012 06:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=11066; q=dns/txt; s=iport; t=1326811130; x=1328020730; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=hFkwXsY97cfQSVse5uT7gGa7yRD+quklzNOk4zagL7w=; b=ly1EzZh7E0nCuOhUUufUyB7xsmed5Nn4z2kLRoCuZTaJ0A13BvfL/obx 5e/ldxZMPMbDKvlc3zK5Wd92yAWeMCWGgxsA7t3uY9KxttCZUcBZkTM3j z2HYghofsXg4gxj67kyXNeKTYcdBh1CxawO+OxAGXVXOvdD27RxamDliy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAADyHFU+tJV2b/2dsb2JhbAA6Cp0IgWuNTIEGgQWBcgEBAQMBAQEBBQoBFQIQNAUGBQcBAwIJDwIEAQEoBxkOHwkIAgQBEgkCF4dYCJg+AZ5BiFogMQEBMAIBAQsPCgEbBycCAQkBAQEEAQGDAlcWAQEBAoMqBIg7hH+aNg X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="51716324" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jan 2012 14:38:49 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0HEcnDR011163; Tue, 17 Jan 2012 14:38:49 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 08:38:49 -0600 Received: from WINICH1QO6NCS6 ([64.102.221.225]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 08:38:48 -0600 From: "Panos Kampanakis" To: "'Takeshi Takahashi'" , , References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com><000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> <000001ccd4d1$10d80e30$32882a90$@com> <001c01ccd4d6$e13182f0$a39488d0$@nict.go.jp> In-Reply-To: <001c01ccd4d6$e13182f0$a39488d0$@nict.go.jp> Date: Tue, 17 Jan 2012 09:38:24 -0500 Organization: Cisco Systems Inc. Message-ID: <008a01ccd525$ab4c91d0$01e5b570$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQGULmByYCUpvH5kVtZUifIc/i5AwAFJmbAoAhjiZJ0Bxi7GkwHAclepAegsa9aWOsPMsIAAmzyQ Content-Language: en-us X-OriginalArrivalTime: 17 Jan 2012 14:38:49.0054 (UTC) FILETIME=[B98E9FE0:01CCD525] Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Tue, 17 Jan 2012 14:38:51 -0000 Looks good to me Take. So after this change takes place, the Specification or XMLSchema or SpecificationID ENUM type of the extension classes (AttackPattern, Vulnerability etc) will include the namespace of each specification right? Panos -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, January 17, 2012 12:14 AM To: 'Panos Kampanakis'; david.black@emc.com; kathleen.moriarty@emc.com Cc: mile@ietf.org Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt Hi Panos, Thank you for the kind comments. I agree to change the draft to avoid any inconsistency between the drafts. > IMO, changing SCI's SpecificationID to be the IANA supported namespace > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF version In this case, we do not need the "notional" string ID defined in the IANA table. Currently, each entry of the table has (ID, specification name, version, namespace, specification url, applicable classes). So, I would delete the "ID" and change the entry into (namespace, specification name, version, specification url, applicable classes) Also, for the rest of the comments, I like your proposal, and let me change the draft. I appreciate your assistance. Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Panos Kampanakis > Sent: Tuesday, January 17, 2012 1:33 PM > To: david.black@emc.com; kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > I agree David. > > It seems the RID's XMLSchemaID and SCI's SpecificationID are equivalent > and depict the included schema identifier. But for RID the XMLSchemaID > is the namespace of the included schema (default IODEF), and in SCI the > SpecificationID is the "notional" string ID for various schemata. For > the Version, RID is IODEF version but in SCI it is the IODEF-SCI version. > 2 inconsistencies that would be better if they matched in Rid and SCI. > > IMO, changing SCI's SpecificationID to be the IANA supported namespace > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF version > (as in > RID) would be sufficient. I am not sure why the IODEF-SCI version needs > to be in the extension classes since it is included in the iodef-sci > namespace definition earlier anyway. > > Rgs, > Panos > > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > david.black@emc.com > Sent: Tuesday, January 03, 2012 12:48 PM > To: kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Hi Kathleen, > > > 3) Are you advocating for a specificationID to be included in addition > > to > the namespace declaration? > > Not exactly ;-). > > I'm not "advocating" for inclusion of specificationID - rather I'd like > to see RID and SCI be consistent in their use of SpecificationID and > Version. > For SpecificationID, that could be accomplished by adding it to RID or > taking it out of SCI; both approaches seem reasonable to me. > > What do other people think ought to be done here and why? > > Thanks, > --David > > > -----Original Message----- > > From: Moriarty, Kathleen > > Sent: Tuesday, January 03, 2012 9:52 AM > > To: Black, David; Takeshi Takahashi; mile@ietf.org > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Take and the other authors of the SCI draft are reviewing this issue. > Feedback on how RID encapsulates > > a document would be helpful. The approach used in RID is consistent > > with > IODEF. > > > > I would like to clarify one of the assumptions from below to avoid > confusion. > > > > 1) The version can be left out for IODEF when included in a RID > > document > as it is listed in the > > namespace definition, not because it is the default schema. In case > > other > schemas also include the > > version in the namespace declaration, this was left as optional. > > > > 3) Are you advocating for a specificationID to be included in addition > > to > the namespace declaration? > > > > Thanks, > > Kathleen (editor) > > ________________________________________ > > From: Black, David > > Sent: Monday, January 02, 2012 2:31 PM > > To: Takeshi Takahashi; mile@ietf.org > > Cc: Moriarty, Kathleen > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Greetings, > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if you > could > > > kindly share your opinion on that. > > > (I personally like the idea Kathleen kindly proposed.) The new > > > version tentatively deleted the description of EM_XML, and use > the > > > xml defined by the IODEF dtype. > > > > I also like Kathleen's suggested approach of using the IODEF dtype > > instead > of EM_XML, especially as > > that approach is also being used to include IODEF content in RID (see > > the > ReportSchema class in draft- > > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice seems > > like > a good idea for > > consistency. > > > > I think some more discussion would be useful (and would like to see > > the > opinions of others), as I see > > some differences between how this is being done in the rfc6045-bis > > draft > vs. the sci draft: > > > > (1) Schema identification > > > > RID identifies the included XML schema by XML namespace and version. > > The > XML namespace is in the > > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, > > and > the schema version is in the > > Version or ext-Version attribute of that class. IODEF 1.0 is the > > default > if these attributes are > > omitted. > > > > SCI extension classes (e.g., AttackPattern) use an additional required > SpecificationID attribute (a > > short ENUM xsd:string) that includes both an acronym and the version > > of > the specification - the XML > > namespace is left to be declared by the included XML. > > > > (2) Version of schema vs. specification > > > > For RID, the Version or Version-ext attribute of the ReportSchema > > class > contains the XML schema > > version for the included XML. > > > > For SCI, the version that's part of the SpecificationID attribute of > > the > extension classes is the > > version of the specification for the included XML. This specification > version may not match the > > version of the XML schema defined by that specification. > > > > (3) Version - same attribute name used for two different purposes. > > > > For RID, the Version attribute of the ReportSchema class is the schema > version for the included XML > > for standard schemas (ext-Version is used for non-standard schemas). > > > > For SCI, the Version attribute of the extension classes is the version > > of > the IODEF-SCI schema. > > > > My 0.02 (which isn't worth much more than that) is that > > SpecificationID > seems to be useful as a > > convenient human-readable string to identify the type of XML content > > (for > RID, that could default to > > IODEF if omitted), and I don't have a strong preference for the two > version topics as long as a single > > approach is adopted. > > > > Could others on the list speak up to provide opinions on how to handle > these topics? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > > Sent: Wednesday, December 28, 2011 12:52 AM > > > To: mile@ietf.org > > > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; > Kent_Landfield@McAfee.com > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > Hello all, > > > > > > I've just posted the new version of the mile-sci draft. > > > Though the text has changed a lot, we basically have only two > > > changes, > as > > > listed below: > > > > > > 1. table is changed (see section 4.1) 2. IANA description was > > > totally changed > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if you > could > > > kindly share your opinion on that. > > > (I personally like the idea Kathleen kindly proposed.) The new > > > version tentatively deleted the description of EM_XML, and use > the > > > xml defined by the IODEF dtype. > > > > > > Thank you very much for those of you who kindly gave me lots of > > > useful comments and supports. > > > I wish you a happy new year. > > > > > > Sincerely, > > > Take > > > > > > > > > > -----Original Message----- > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > Behalf > Of > > > > internet-drafts@ietf.org > > > > Sent: Wednesday, December 28, 2011 2:40 PM > > > > To: i-d-announce@ietf.org > > > > Cc: mile@ietf.org > > > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. This draft is a work item of the Managed Incident > Lightweight > > > > Exchange Working Group of the IETF. > > > > > > > > Title : IODEF-extension to support structured > > > > cybersecurity information > > > > Author(s) : Takeshi Takahashi > > > > Kent Landfield > > > > Thomas Millar > > > > Youki Kadobayashi > > > > Filename : draft-ietf-mile-sci-01.txt > > > > Pages : 34 > > > > Date : 2011-12-27 > > > > > > > > This document extends the Incident Object Description Exchange > Format > > > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > > > cybersecurity information exchange among cybersecurity entities > by > > > > embedding structured information formatted by specifications, > > > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], > CVE(R) > > > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] > > > > [CWSS], > OCIL > > > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > > > > > _______________________________________________ > > > > mile mailing 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 Tue Jan 17 08:45: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 50F5721F86CF for ; Tue, 17 Jan 2012 08:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[AWL=0.060, 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 GM2cBMg9WZX0 for ; Tue, 17 Jan 2012 08:45:21 -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 D64BD21F868C for ; Tue, 17 Jan 2012 08:45:20 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q0HGjDF8019791; Wed, 18 Jan 2012 01:45:13 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q0HGjDK3025854; Wed, 18 Jan 2012 01:45:13 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id q0HGjCWw025851; Wed, 18 Jan 2012 01:45:12 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id B83D22CEB; Wed, 18 Jan 2012 01:45:12 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 8E0902B64; Wed, 18 Jan 2012 01:45:12 +0900 (JST) From: "Takeshi Takahashi" To: "'Panos Kampanakis'" , , References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com><000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> <000001ccd4d1$10d80e30$32882a90$@com> <001c01ccd4d6$e13182f0$a39488d0$@nict.go.jp> <008a01ccd525$ab4c91d0$01e5b570$@com> In-Reply-To: <008a01ccd525$ab4c91d0$01e5b570$@com> Date: Wed, 18 Jan 2012 01:45:12 +0900 Message-ID: <000d01ccd537$61744870$245cd950$@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: AQGULmByYCUpvH5kVtZUifIc/i5AwAFJmbAoAhjiZJ0Bxi7GkwHAclepAegsa9YB8u7F3AHZbiJxlh0SfxA= Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Tue, 17 Jan 2012 16:45:22 -0000 Hi Panos, thank you for your confirmation. Yes, each class has a field containing the namespace. SpecificationID field will be used for describing the namespace, instead of the notional IDs. As an example, let me put the text of the AttackPattern class after the modification. The description of the SpecificationID was changed, and the version attribute was deleted(, and we do not have the notional string ID). ---------------------------------------------------------------------------- -- 4.3.1. AttackPattern An AttackPattern consists of an extension to the Incident.Method.AdditionalData element with a dtype of "xml". The extension describes attack patterns of incidents or events. It is recommended that Method class SHOULD contain one or more of the extension elements whenever available. An AttackPattern class is structured as follows. +------------------------+ | AttackPattern | +------------------------+ | ENUM SpecificationID |<>--(0..*)-[ RawData ] | STRING AttackPatternID |<>--(0..*)-[ Reference ] | |<>--(0..*)-[ PlatformID ] +------------------------+ Figure 2: AttackPattern class This class has the following attributes. SpecificationID: REQUIRED. ENUM. The namespace of the specification and its version that the RawData element follows. The value should be chosen from the namespaces listed in Section 4.1, which could be developed further by IANA. In case a RawData or Reference element is provided along with this attribute, writers/senders MUST ensure that this namespace is consistent with the one provided by the element; if a reader/ receiver detects an inconsistency, it SHOULD prefer the value of this attribute, and SHOULD log the inconsistency so a human can correct the problem. AttackPatternID: OPTIONAL. STRING. An ID of an attack pattern to be reported. This attribute SHOULD be used whenever such ID is available, but could be omitted if no such ID is available. In this case, either RawData or Reference elements, or both of them, MUST be provided. In case a RawData or Reference element is provided along with this attribute, writers/senders MUST ensure that this ID is consistent with the one provided by the element; if a reader/receiver detects an inconsistency, it SHOULD prefer the value of this attribute, and SHOULD log the inconsistency so a human can correct the problem. The AttackPattern class is composed of the following aggregate classes. RawData: Zero or more. XMLDATA. A complete document that is formatted according to the specification and its version identified by the value of the SpecificationID with the Section 4.1. Reference: Zero or more of iodef:Reference [RFC5070]. This element allows an IODEF document to include a link to a structured information instead of directly embedding it into a RawData element. PlatformID: Zero or more. An identifier of software platform involved in the specific attack pattern, which is elaborated in Section 4.3.2. Some of the structured information embedded in the RawData element may include the identifier within it. In this case, this PlatformID element SHOULD NOT be used. If a reader/ receiver detects the identifiers in both RawData and PlatformID elements and their inconsistency, it SHOULD prefer the identifiers derived from the PlatformID element, and SHOULD log the inconsistency so a human can correct the problem. ---------------------------------------------------------------------------- -- Let me change the other parts including schema for the next version of the draft. Thank you. Take > -----Original Message----- > From: Panos Kampanakis [mailto:pkampana@cisco.com] > Sent: Tuesday, January 17, 2012 11:38 PM > To: 'Takeshi Takahashi'; david.black@emc.com; > kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Looks good to me Take. > So after this change takes place, the Specification or XMLSchema or > SpecificationID ENUM type of the extension classes (AttackPattern, > Vulnerability etc) will include the namespace of each specification > right? > > Panos > > > > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, January 17, 2012 12:14 AM > To: 'Panos Kampanakis'; david.black@emc.com; kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Hi Panos, > > Thank you for the kind comments. > I agree to change the draft to avoid any inconsistency between the drafts. > > > IMO, changing SCI's SpecificationID to be the IANA supported namespace > > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF > > version > > In this case, we do not need the "notional" string ID defined in the IANA > table. > Currently, each entry of the table has (ID, specification name, version, > namespace, specification url, applicable classes). > So, I would delete the "ID" and change the entry into (namespace, > specification name, version, specification url, applicable classes) > > Also, for the rest of the comments, I like your proposal, and let me change > the draft. > > I appreciate your assistance. > Thank you. > > Take > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Panos Kampanakis > > Sent: Tuesday, January 17, 2012 1:33 PM > > To: david.black@emc.com; kathleen.moriarty@emc.com > > Cc: mile@ietf.org > > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > I agree David. > > > > It seems the RID's XMLSchemaID and SCI's SpecificationID are > > equivalent and depict the included schema identifier. But for RID the > > XMLSchemaID is the namespace of the included schema (default IODEF), > > and in SCI the SpecificationID is the "notional" string ID for various > > schemata. For the Version, RID is IODEF version but in SCI it is the > IODEF-SCI version. > > 2 inconsistencies that would be better if they matched in Rid and SCI. > > > > IMO, changing SCI's SpecificationID to be the IANA supported namespace > > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF > > version (as in > > RID) would be sufficient. I am not sure why the IODEF-SCI version > > needs to be in the extension classes since it is included in the > > iodef-sci namespace definition earlier anyway. > > > > Rgs, > > Panos > > > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of david.black@emc.com > > Sent: Tuesday, January 03, 2012 12:48 PM > > To: kathleen.moriarty@emc.com > > Cc: mile@ietf.org > > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Hi Kathleen, > > > > > 3) Are you advocating for a specificationID to be included in > > > addition to > > the namespace declaration? > > > > Not exactly ;-). > > > > I'm not "advocating" for inclusion of specificationID - rather I'd > > like to see RID and SCI be consistent in their use of SpecificationID > > and Version. > > For SpecificationID, that could be accomplished by adding it to RID > or > > taking it out of SCI; both approaches seem reasonable to me. > > > > What do other people think ought to be done here and why? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Moriarty, Kathleen > > > Sent: Tuesday, January 03, 2012 9:52 AM > > > To: Black, David; Takeshi Takahashi; mile@ietf.org > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > Take and the other authors of the SCI draft are reviewing this issue. > > Feedback on how RID encapsulates > > > a document would be helpful. The approach used in RID is consistent > > > with > > IODEF. > > > > > > I would like to clarify one of the assumptions from below to avoid > > confusion. > > > > > > 1) The version can be left out for IODEF when included in a RID > > > document > > as it is listed in the > > > namespace definition, not because it is the default schema. In case > > > other > > schemas also include the > > > version in the namespace declaration, this was left as optional. > > > > > > 3) Are you advocating for a specificationID to be included in > > > addition to > > the namespace declaration? > > > > > > Thanks, > > > Kathleen (editor) > > > ________________________________________ > > > From: Black, David > > > Sent: Monday, January 02, 2012 2:31 PM > > > To: Takeshi Takahashi; mile@ietf.org > > > Cc: Moriarty, Kathleen > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > Greetings, > > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if > > > > you > > could > > > > kindly share your opinion on that. > > > > (I personally like the idea Kathleen kindly proposed.) The new > > > > version tentatively deleted the description of EM_XML, and use > > the > > > > xml defined by the IODEF dtype. > > > > > > I also like Kathleen's suggested approach of using the IODEF dtype > > > instead > > of EM_XML, especially as > > > that approach is also being used to include IODEF content in RID > > > (see the > > ReportSchema class in draft- > > > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice > > > seems like > > a good idea for > > > consistency. > > > > > > I think some more discussion would be useful (and would like to see > > > the > > opinions of others), as I see > > > some differences between how this is being done in the rfc6045-bis > > > draft > > vs. the sci draft: > > > > > > (1) Schema identification > > > > > > RID identifies the included XML schema by XML namespace and version. > > > The > > XML namespace is in the > > > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, > > > and > > the schema version is in the > > > Version or ext-Version attribute of that class. IODEF 1.0 is the > > > default > > if these attributes are > > > omitted. > > > > > > SCI extension classes (e.g., AttackPattern) use an additional > > > required > > SpecificationID attribute (a > > > short ENUM xsd:string) that includes both an acronym and the version > > > of > > the specification - the XML > > > namespace is left to be declared by the included XML. > > > > > > (2) Version of schema vs. specification > > > > > > For RID, the Version or Version-ext attribute of the ReportSchema > > > class > > contains the XML schema > > > version for the included XML. > > > > > > For SCI, the version that's part of the SpecificationID attribute > of > > > the > > extension classes is the > > > version of the specification for the included XML. This > > > specification > > version may not match the > > > version of the XML schema defined by that specification. > > > > > > (3) Version - same attribute name used for two different purposes. > > > > > > For RID, the Version attribute of the ReportSchema class is the > > > schema > > version for the included XML > > > for standard schemas (ext-Version is used for non-standard schemas). > > > > > > For SCI, the Version attribute of the extension classes is the > > > version of > > the IODEF-SCI schema. > > > > > > My 0.02 (which isn't worth much more than that) is that > > > SpecificationID > > seems to be useful as a > > > convenient human-readable string to identify the type of XML content > > > (for > > RID, that could default to > > > IODEF if omitted), and I don't have a strong preference for the two > > version topics as long as a single > > > approach is adopted. > > > > > > Could others on the list speak up to provide opinions on how to > > > handle > > these topics? > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > > > Sent: Wednesday, December 28, 2011 12:52 AM > > > > To: mile@ietf.org > > > > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; > > Kent_Landfield@McAfee.com > > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > Hello all, > > > > > > > > I've just posted the new version of the mile-sci draft. > > > > Though the text has changed a lot, we basically have only two > > > > changes, > > as > > > > listed below: > > > > > > > > 1. table is changed (see section 4.1) 2. IANA description was > > > > totally changed > > > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if > > > > you > > could > > > > kindly share your opinion on that. > > > > (I personally like the idea Kathleen kindly proposed.) The new > > > > version tentatively deleted the description of EM_XML, and use > > the > > > > xml defined by the IODEF dtype. > > > > > > > > Thank you very much for those of you who kindly gave me lots of > > > > useful comments and supports. > > > > I wish you a happy new year. > > > > > > > > Sincerely, > > > > Take > > > > > > > > > > > > > -----Original Message----- > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > > Behalf > > Of > > > > > internet-drafts@ietf.org > > > > > Sent: Wednesday, December 28, 2011 2:40 PM > > > > > To: i-d-announce@ietf.org > > > > > Cc: mile@ietf.org > > > > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. This draft is a work item of the > > > > > Managed Incident > > Lightweight > > > > > Exchange Working Group of the IETF. > > > > > > > > > > Title : IODEF-extension to support structured > > > > > cybersecurity information > > > > > Author(s) : Takeshi Takahashi > > > > > Kent Landfield > > > > > Thomas Millar > > > > > Youki Kadobayashi > > > > > Filename : draft-ietf-mile-sci-01.txt > > > > > Pages : 34 > > > > > Date : 2011-12-27 > > > > > > > > > > This document extends the Incident Object Description > > > > > Exchange > > Format > > > > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > > > > cybersecurity information exchange among cybersecurity > > > > > entities > > by > > > > > embedding structured information formatted by specifications, > > > > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], > > CVE(R) > > > > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] > > > > > [CWSS], > > OCIL > > > > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > > > > > > > _______________________________________________ > > > > > mile mailing 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 Jan 17 08:52:02 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 A6F6E21F849A for ; Tue, 17 Jan 2012 08:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 49pigaw9qriH for ; Tue, 17 Jan 2012 08:52:01 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2528621F84D8 for ; Tue, 17 Jan 2012 08:52: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 q0HGpwwN024663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 11:51:59 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 17 Jan 2012 11:51:40 -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 q0HGpc5a000396; Tue, 17 Jan 2012 11:51:39 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Tue, 17 Jan 2012 11:51:38 -0500 From: To: , , Date: Tue, 17 Jan 2012 11:51:37 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-sci-01.txt Thread-Index: AQGULmByYCUpvH5kVtZUifIc/i5AwAFJmbAoAhjiZJ0Bxi7GkwHAclepAegsa9YB8u7F3AHZbiJxlh0SfxCAABPnwA== Message-ID: References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com><000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> <000001ccd4d1$10d80e30$32882a90$@com> <001c01ccd4d6$e13182f0$a39488d0$@nict.go.jp> <008a01ccd525$ab4c91d0$01e5b570$@com> <000d01ccd537$61744870$245cd950$@nict.go.jp> In-Reply-To: <000d01ccd537$61744870$245cd950$@nict.go.jp> 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] I-D Action: draft-ietf-mile-sci-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: Tue, 17 Jan 2012 16:52:02 -0000 Hi Take, The closer you can match it to RID, the better as it may ease the task for = IANA and help integrators. Thank you! Kathleen (as author) -----Original Message----- From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] Sent: Tuesday, January 17, 2012 11:45 AM To: 'Panos Kampanakis'; Black, David; Moriarty, Kathleen Cc: mile@ietf.org; Kent_Landfield@McAfee.com Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt Hi Panos, thank you for your confirmation. Yes, each class has a field containing the namespace. SpecificationID field will be used for describing the namespace, instead of the notional IDs. As an example, let me put the text of the AttackPattern class after the modification. The description of the SpecificationID was changed, and the version attribute was deleted(, and we do not have the notional string ID). ---------------------------------------------------------------------------= - -- 4.3.1. AttackPattern An AttackPattern consists of an extension to the Incident.Method.AdditionalData element with a dtype of "xml". The extension describes attack patterns of incidents or events. It is recommended that Method class SHOULD contain one or more of the extension elements whenever available. An AttackPattern class is structured as follows. +------------------------+ | AttackPattern | +------------------------+ | ENUM SpecificationID |<>--(0..*)-[ RawData ] | STRING AttackPatternID |<>--(0..*)-[ Reference ] | |<>--(0..*)-[ PlatformID ] +------------------------+ Figure 2: AttackPattern class This class has the following attributes. SpecificationID: REQUIRED. ENUM. The namespace of the specification and its version that the RawData element follows. The value should be chosen from the namespaces listed in Section 4.1, which could be developed further by IANA. In case a RawData or Reference element is provided along with this attribute, writers/senders MUST ensure that this namespace is consistent with the one provided by the element; if a reader/ receiver detects an inconsistency, it SHOULD prefer the value of this attribute, and SHOULD log the inconsistency so a human can correct the problem. AttackPatternID: OPTIONAL. STRING. An ID of an attack pattern to be reported. This attribute SHOULD be used whenever such ID is available, but could be omitted if no such ID is available. In this case, either RawData or Reference elements, or both of them, MUST be provided. In case a RawData or Reference element is provided along with this attribute, writers/senders MUST ensure that this ID is consistent with the one provided by the element; if a reader/receiver detects an inconsistency, it SHOULD prefer the value of this attribute, and SHOULD log the inconsistency so a human can correct the problem. The AttackPattern class is composed of the following aggregate classes. RawData: Zero or more. XMLDATA. A complete document that is formatted according to the specification and its version identified by the value of the SpecificationID with the Section 4.1. Reference: Zero or more of iodef:Reference [RFC5070]. This element allows an IODEF document to include a link to a structured information instead of directly embedding it into a RawData element. PlatformID: Zero or more. An identifier of software platform involved in the specific attack pattern, which is elaborated in Section 4.3.2. Some of the structured information embedded in the RawData element may include the identifier within it. In this case, this PlatformID element SHOULD NOT be used. If a reader/ receiver detects the identifiers in both RawData and PlatformID elements and their inconsistency, it SHOULD prefer the identifiers derived from the PlatformID element, and SHOULD log the inconsistency so a human can correct the problem. ---------------------------------------------------------------------------= - -- Let me change the other parts including schema for the next version of the draft. Thank you. Take > -----Original Message----- > From: Panos Kampanakis [mailto:pkampana@cisco.com] > Sent: Tuesday, January 17, 2012 11:38 PM > To: 'Takeshi Takahashi'; david.black@emc.com; > kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Looks good to me Take. > So after this change takes place, the Specification or XMLSchema or > SpecificationID ENUM type of the extension classes (AttackPattern, > Vulnerability etc) will include the namespace of each specification > right? > > Panos > > > > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, January 17, 2012 12:14 AM > To: 'Panos Kampanakis'; david.black@emc.com; kathleen.moriarty@emc.com > Cc: mile@ietf.org > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Hi Panos, > > Thank you for the kind comments. > I agree to change the draft to avoid any inconsistency between the drafts= . > > > IMO, changing SCI's SpecificationID to be the IANA supported namespace > > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF > > version > > In this case, we do not need the "notional" string ID defined in the IANA > table. > Currently, each entry of the table has (ID, specification name, version, > namespace, specification url, applicable classes). > So, I would delete the "ID" and change the entry into (namespace, > specification name, version, specification url, applicable classes) > > Also, for the rest of the comments, I like your proposal, and let me change > the draft. > > I appreciate your assistance. > Thank you. > > Take > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Panos Kampanakis > > Sent: Tuesday, January 17, 2012 1:33 PM > > To: david.black@emc.com; kathleen.moriarty@emc.com > > Cc: mile@ietf.org > > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > I agree David. > > > > It seems the RID's XMLSchemaID and SCI's SpecificationID are > > equivalent and depict the included schema identifier. But for RID the > > XMLSchemaID is the namespace of the included schema (default IODEF), > > and in SCI the SpecificationID is the "notional" string ID for various > > schemata. For the Version, RID is IODEF version but in SCI it is the > IODEF-SCI version. > > 2 inconsistencies that would be better if they matched in Rid and SCI. > > > > IMO, changing SCI's SpecificationID to be the IANA supported namespace > > for XDDF, CCE, CAPEC etc and making the Version to be the IODEF > > version (as in > > RID) would be sufficient. I am not sure why the IODEF-SCI version > > needs to be in the extension classes since it is included in the > > iodef-sci namespace definition earlier anyway. > > > > Rgs, > > Panos > > > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of david.black@emc.com > > Sent: Tuesday, January 03, 2012 12:48 PM > > To: kathleen.moriarty@emc.com > > Cc: mile@ietf.org > > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Hi Kathleen, > > > > > 3) Are you advocating for a specificationID to be included in > > > addition to > > the namespace declaration? > > > > Not exactly ;-). > > > > I'm not "advocating" for inclusion of specificationID - rather I'd > > like to see RID and SCI be consistent in their use of SpecificationID > > and Version. > > For SpecificationID, that could be accomplished by adding it to RID > or > > taking it out of SCI; both approaches seem reasonable to me. > > > > What do other people think ought to be done here and why? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Moriarty, Kathleen > > > Sent: Tuesday, January 03, 2012 9:52 AM > > > To: Black, David; Takeshi Takahashi; mile@ietf.org > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > Take and the other authors of the SCI draft are reviewing this issue. > > Feedback on how RID encapsulates > > > a document would be helpful. The approach used in RID is consistent > > > with > > IODEF. > > > > > > I would like to clarify one of the assumptions from below to avoid > > confusion. > > > > > > 1) The version can be left out for IODEF when included in a RID > > > document > > as it is listed in the > > > namespace definition, not because it is the default schema. In case > > > other > > schemas also include the > > > version in the namespace declaration, this was left as optional. > > > > > > 3) Are you advocating for a specificationID to be included in > > > addition to > > the namespace declaration? > > > > > > Thanks, > > > Kathleen (editor) > > > ________________________________________ > > > From: Black, David > > > Sent: Monday, January 02, 2012 2:31 PM > > > To: Takeshi Takahashi; mile@ietf.org > > > Cc: Moriarty, Kathleen > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > Greetings, > > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if > > > > you > > could > > > > kindly share your opinion on that. > > > > (I personally like the idea Kathleen kindly proposed.) The new > > > > version tentatively deleted the description of EM_XML, and use > > the > > > > xml defined by the IODEF dtype. > > > > > > I also like Kathleen's suggested approach of using the IODEF dtype > > > instead > > of EM_XML, especially as > > > that approach is also being used to include IODEF content in RID > > > (see the > > ReportSchema class in draft- > > > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice > > > seems like > > a good idea for > > > consistency. > > > > > > I think some more discussion would be useful (and would like to see > > > the > > opinions of others), as I see > > > some differences between how this is being done in the rfc6045-bis > > > draft > > vs. the sci draft: > > > > > > (1) Schema identification > > > > > > RID identifies the included XML schema by XML namespace and version. > > > The > > XML namespace is in the > > > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema class, > > > and > > the schema version is in the > > > Version or ext-Version attribute of that class. IODEF 1.0 is the > > > default > > if these attributes are > > > omitted. > > > > > > SCI extension classes (e.g., AttackPattern) use an additional > > > required > > SpecificationID attribute (a > > > short ENUM xsd:string) that includes both an acronym and the version > > > of > > the specification - the XML > > > namespace is left to be declared by the included XML. > > > > > > (2) Version of schema vs. specification > > > > > > For RID, the Version or Version-ext attribute of the ReportSchema > > > class > > contains the XML schema > > > version for the included XML. > > > > > > For SCI, the version that's part of the SpecificationID attribute > of > > > the > > extension classes is the > > > version of the specification for the included XML. This > > > specification > > version may not match the > > > version of the XML schema defined by that specification. > > > > > > (3) Version - same attribute name used for two different purposes. > > > > > > For RID, the Version attribute of the ReportSchema class is the > > > schema > > version for the included XML > > > for standard schemas (ext-Version is used for non-standard schemas). > > > > > > For SCI, the Version attribute of the extension classes is the > > > version of > > the IODEF-SCI schema. > > > > > > My 0.02 (which isn't worth much more than that) is that > > > SpecificationID > > seems to be useful as a > > > convenient human-readable string to identify the type of XML content > > > (for > > RID, that could default to > > > IODEF if omitted), and I don't have a strong preference for the two > > version topics as long as a single > > > approach is adopted. > > > > > > Could others on the list speak up to provide opinions on how to > > > handle > > these topics? > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > > > Sent: Wednesday, December 28, 2011 12:52 AM > > > > To: mile@ietf.org > > > > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; > > Kent_Landfield@McAfee.com > > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > Hello all, > > > > > > > > I've just posted the new version of the mile-sci draft. > > > > Though the text has changed a lot, we basically have only two > > > > changes, > > as > > > > listed below: > > > > > > > > 1. table is changed (see section 4.1) 2. IANA description was > > > > totally changed > > > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate if > > > > you > > could > > > > kindly share your opinion on that. > > > > (I personally like the idea Kathleen kindly proposed.) The new > > > > version tentatively deleted the description of EM_XML, and use > > the > > > > xml defined by the IODEF dtype. > > > > > > > > Thank you very much for those of you who kindly gave me lots of > > > > useful comments and supports. > > > > I wish you a happy new year. > > > > > > > > Sincerely, > > > > Take > > > > > > > > > > > > > -----Original Message----- > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > > Behalf > > Of > > > > > internet-drafts@ietf.org > > > > > Sent: Wednesday, December 28, 2011 2:40 PM > > > > > To: i-d-announce@ietf.org > > > > > Cc: mile@ietf.org > > > > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. This draft is a work item of the > > > > > Managed Incident > > Lightweight > > > > > Exchange Working Group of the IETF. > > > > > > > > > > Title : IODEF-extension to support structured > > > > > cybersecurity information > > > > > Author(s) : Takeshi Takahashi > > > > > Kent Landfield > > > > > Thomas Millar > > > > > Youki Kadobayashi > > > > > Filename : draft-ietf-mile-sci-01.txt > > > > > Pages : 34 > > > > > Date : 2011-12-27 > > > > > > > > > > This document extends the Incident Object Description > > > > > Exchange > > Format > > > > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > > > > cybersecurity information exchange among cybersecurity > > > > > entities > > by > > > > > embedding structured information formatted by specifications, > > > > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], > > CVE(R) > > > > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] > > > > > [CWSS], > > OCIL > > > > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > > > > > > > _______________________________________________ > > > > > mile mailing 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 Tue Jan 17 09:08:01 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 8D7411F0C44 for ; Tue, 17 Jan 2012 09:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=0.050, 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 F+QJ5NWBoWUo for ; Tue, 17 Jan 2012 09:08:00 -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 DC88821F8587 for ; Tue, 17 Jan 2012 09:07:59 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q0HH7qMI019805; Wed, 18 Jan 2012 02:07:52 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q0HH7qow021274; Wed, 18 Jan 2012 02:07:52 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q0HH7qF2021271; Wed, 18 Jan 2012 02:07:52 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 6FB762C9F; Wed, 18 Jan 2012 02:07:52 +0900 (JST) Received: from TakeVAIO (unknown [133.243.119.203]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 57FAC2C76; Wed, 18 Jan 2012 02:07:52 +0900 (JST) From: "Takeshi Takahashi" To: , , References: <20111228054002.11528.53128.idtracker@ietfa.amsl.com><000301ccc524$d981f8d0$8c85ea70$@nict.go.jp>, <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9B@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7BBF2@MX14A.corp.emc.com> <000001ccd4d1$10d80e30$32882a90$@com> <001c01ccd4d6$e13182f0$a39488d0$@nict.go.jp> <008a01ccd525$ab4c91d0$01e5b570$@com> <000d01ccd537$61744870$245cd950$@nict.go.jp> In-Reply-To: Date: Wed, 18 Jan 2012 02:07:51 +0900 Message-ID: <001501ccd53a$8bf10630$a3d31290$@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: AQGULmByYCUpvH5kVtZUifIc/i5AwAFJmbAoAhjiZJ0Bxi7GkwHAclepAegsa9YB8u7F3AHZbiJxAYOO/wsBeqTwbJYFNetA Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Tue, 17 Jan 2012 17:08:01 -0000 Hi Kathleen, Thank you for the comment. Yes I agree. I guess you are talking about the attribute name and its explanation, especially the "XMLSchemaID" attribute (in RID draft). I also thought I could use the same attribute name, but I am rather hesitant to use the name "XMLSchemaID" in the SCI draft since I would like to identify namespace (instead of directly identifying the schema), at this moment. In any case, I basically agree to minimize the differences between the two drafts. So, let me still modify sentences before submitting the next version. Thank you. Take > -----Original Message----- > From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, January 18, 2012 1:52 AM > To: takeshi_takahashi@nict.go.jp; pkampana@cisco.com; > david.black@emc.com > Cc: mile@ietf.org; Kent_Landfield@McAfee.com > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Hi Take, > > The closer you can match it to RID, the better as it may ease the task > for IANA and help integrators. > > Thank you! > Kathleen (as author) > > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Tuesday, January 17, 2012 11:45 AM > To: 'Panos Kampanakis'; Black, David; Moriarty, Kathleen > Cc: mile@ietf.org; Kent_Landfield@McAfee.com > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > Hi Panos, thank you for your confirmation. > > Yes, each class has a field containing the namespace. > SpecificationID field will be used for describing the namespace, instead > of the notional IDs. > > As an example, let me put the text of the AttackPattern class after the > modification. > The description of the SpecificationID was changed, and the version > attribute was deleted(, and we do not have the notional string ID). > > -------------------------------------------------------------------- > -------- > -- > 4.3.1. AttackPattern > > An AttackPattern consists of an extension to the > Incident.Method.AdditionalData element with a dtype of "xml". The > extension describes attack patterns of incidents or events. > > It is recommended that Method class SHOULD contain one or more of the > extension elements whenever available. > > An AttackPattern class is structured as follows. > > +------------------------+ > | AttackPattern | > +------------------------+ > | ENUM SpecificationID |<>--(0..*)-[ RawData ] > | STRING AttackPatternID |<>--(0..*)-[ Reference ] > | |<>--(0..*)-[ PlatformID ] > +------------------------+ > > Figure 2: AttackPattern class > > This class has the following attributes. > > SpecificationID: REQUIRED. ENUM. The namespace of the > specification and its version that the RawData element follows. > The value should be chosen from the namespaces listed in > Section 4.1, which could be developed further by IANA. In case > a > RawData or Reference element is provided along with this > attribute, writers/senders MUST ensure that this namespace is > consistent with the one provided by the element; if a reader/ > receiver detects an inconsistency, it SHOULD prefer the value of > this attribute, and SHOULD log the inconsistency so a human can > correct the problem. > > AttackPatternID: OPTIONAL. STRING. An ID of an attack pattern to > be reported. This attribute SHOULD be used whenever such ID is > available, but could be omitted if no such ID is available. In > this case, either RawData or Reference elements, or both of them, > MUST be provided. In case a RawData or Reference element is > provided along with this attribute, writers/senders MUST ensure > that this ID is consistent with the one provided by the element; > if a reader/receiver detects an inconsistency, it SHOULD prefer > the value of this attribute, and SHOULD log the inconsistency so > a > human can correct the problem. > > The AttackPattern class is composed of the following aggregate > classes. > > RawData: Zero or more. XMLDATA. A complete document that is > formatted according to the specification and its version > identified by the value of the SpecificationID with the > Section 4.1. > > Reference: Zero or more of iodef:Reference [RFC5070]. This element > allows an IODEF document to include a link to a structured > information instead of directly embedding it into a RawData > element. > > PlatformID: Zero or more. An identifier of software platform > involved in the specific attack pattern, which is elaborated in > Section 4.3.2. Some of the structured information embedded in the > RawData element may include the identifier within it. In this > case, this PlatformID element SHOULD NOT be used. If a reader/ > receiver detects the identifiers in both RawData and PlatformID > elements and their inconsistency, it SHOULD prefer the identifiers > derived from the PlatformID element, and SHOULD log the > inconsistency so a human can correct the problem. > -------------------------------------------------------------------- > -------- > -- > > Let me change the other parts including schema for the next version of > the draft. > > Thank you. > Take > > > > > -----Original Message----- > > From: Panos Kampanakis [mailto:pkampana@cisco.com] > > Sent: Tuesday, January 17, 2012 11:38 PM > > To: 'Takeshi Takahashi'; david.black@emc.com; > > kathleen.moriarty@emc.com > > Cc: mile@ietf.org > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Looks good to me Take. > > So after this change takes place, the Specification or XMLSchema or > > SpecificationID ENUM type of the extension classes (AttackPattern, > > Vulnerability etc) will include the namespace of each specification > > right? > > > > Panos > > > > > > > > -----Original Message----- > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > Sent: Tuesday, January 17, 2012 12:14 AM > > To: 'Panos Kampanakis'; david.black@emc.com; > kathleen.moriarty@emc.com > > Cc: mile@ietf.org > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > Hi Panos, > > > > Thank you for the kind comments. > > I agree to change the draft to avoid any inconsistency between the > drafts. > > > > > IMO, changing SCI's SpecificationID to be the IANA supported > > > namespace for XDDF, CCE, CAPEC etc and making the Version to be the > > > IODEF version > > > > In this case, we do not need the "notional" string ID defined in the > > IANA table. > > Currently, each entry of the table has (ID, specification name, > > version, namespace, specification url, applicable classes). > > So, I would delete the "ID" and change the entry into (namespace, > > specification name, version, specification url, applicable classes) > > > > Also, for the rest of the comments, I like your proposal, and let me > change > > the draft. > > > > I appreciate your assistance. > > Thank you. > > > > Take > > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > Behalf > > > Of Panos Kampanakis > > > Sent: Tuesday, January 17, 2012 1:33 PM > > > To: david.black@emc.com; kathleen.moriarty@emc.com > > > Cc: mile@ietf.org > > > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > I agree David. > > > > > > It seems the RID's XMLSchemaID and SCI's SpecificationID are > > > equivalent and depict the included schema identifier. But for RID > > > the XMLSchemaID is the namespace of the included schema (default > > > IODEF), and in SCI the SpecificationID is the "notional" string ID > > > for various schemata. For the Version, RID is IODEF version but in > > > SCI it is the > > IODEF-SCI version. > > > 2 inconsistencies that would be better if they matched in Rid and > SCI. > > > > > > IMO, changing SCI's SpecificationID to be the IANA supported > > > namespace for XDDF, CCE, CAPEC etc and making the Version to be the > > > IODEF version (as in > > > RID) would be sufficient. I am not sure why the IODEF-SCI version > > > needs to be in the extension classes since it is included in the > > > iodef-sci namespace definition earlier anyway. > > > > > > Rgs, > > > Panos > > > > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > Behalf > > > Of david.black@emc.com > > > Sent: Tuesday, January 03, 2012 12:48 PM > > > To: kathleen.moriarty@emc.com > > > Cc: mile@ietf.org > > > Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > Hi Kathleen, > > > > > > > 3) Are you advocating for a specificationID to be included in > > > > addition to > > > the namespace declaration? > > > > > > Not exactly ;-). > > > > > > I'm not "advocating" for inclusion of specificationID - rather I'd > > > like to see RID and SCI be consistent in their use of > > > SpecificationID and Version. > > > For SpecificationID, that could be accomplished by adding it to RID > > or > > > taking it out of SCI; both approaches seem reasonable to me. > > > > > > What do other people think ought to be done here and why? > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Moriarty, Kathleen > > > > Sent: Tuesday, January 03, 2012 9:52 AM > > > > To: Black, David; Takeshi Takahashi; mile@ietf.org > > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > Take and the other authors of the SCI draft are reviewing this issue. > > > Feedback on how RID encapsulates > > > > a document would be helpful. The approach used in RID is > > > > consistent with > > > IODEF. > > > > > > > > I would like to clarify one of the assumptions from below to avoid > > > confusion. > > > > > > > > 1) The version can be left out for IODEF when included in a RID > > > > document > > > as it is listed in the > > > > namespace definition, not because it is the default schema. In > > > > case other > > > schemas also include the > > > > version in the namespace declaration, this was left as optional. > > > > > > > > 3) Are you advocating for a specificationID to be included in > > > > addition to > > > the namespace declaration? > > > > > > > > Thanks, > > > > Kathleen (editor) > > > > ________________________________________ > > > > From: Black, David > > > > Sent: Monday, January 02, 2012 2:31 PM > > > > To: Takeshi Takahashi; mile@ietf.org > > > > Cc: Moriarty, Kathleen > > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > Greetings, > > > > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate > if > > > > > you > > > could > > > > > kindly share your opinion on that. > > > > > (I personally like the idea Kathleen kindly proposed.) The new > > > > > version tentatively deleted the description of EM_XML, and use > > > the > > > > > xml defined by the IODEF dtype. > > > > > > > > I also like Kathleen's suggested approach of using the IODEF dtype > > > > instead > > > of EM_XML, especially as > > > > that approach is also being used to include IODEF content in RID > > > > (see the > > > ReportSchema class in draft- > > > > ietf-mile-rfc6045-bis-05.txt), so using the same approach twice > > > > seems like > > > a good idea for > > > > consistency. > > > > > > > > I think some more discussion would be useful (and would like to > > > > see the > > > opinions of others), as I see > > > > some differences between how this is being done in the rfc6045-bis > > > > draft > > > vs. the sci draft: > > > > > > > > (1) Schema identification > > > > > > > > RID identifies the included XML schema by XML namespace and version. > > > > The > > > XML namespace is in the > > > > XMLSchemaID or ext-XMLSchemaID attribute of the ReportSchema > > > > class, and > > > the schema version is in the > > > > Version or ext-Version attribute of that class. IODEF 1.0 is the > > > > default > > > if these attributes are > > > > omitted. > > > > > > > > SCI extension classes (e.g., AttackPattern) use an additional > > > > required > > > SpecificationID attribute (a > > > > short ENUM xsd:string) that includes both an acronym and the > > > > version of > > > the specification - the XML > > > > namespace is left to be declared by the included XML. > > > > > > > > (2) Version of schema vs. specification > > > > > > > > For RID, the Version or Version-ext attribute of the ReportSchema > > > > class > > > contains the XML schema > > > > version for the included XML. > > > > > > > > For SCI, the version that's part of the SpecificationID attribute > > of > > > > the > > > extension classes is the > > > > version of the specification for the included XML. This > > > > specification > > > version may not match the > > > > version of the XML schema defined by that specification. > > > > > > > > (3) Version - same attribute name used for two different purposes. > > > > > > > > For RID, the Version attribute of the ReportSchema class is the > > > > schema > > > version for the included XML > > > > for standard schemas (ext-Version is used for non-standard schemas). > > > > > > > > For SCI, the Version attribute of the extension classes is the > > > > version of > > > the IODEF-SCI schema. > > > > > > > > My 0.02 (which isn't worth much more than that) is that > > > > SpecificationID > > > seems to be useful as a > > > > convenient human-readable string to identify the type of XML > > > > content (for > > > RID, that could default to > > > > IODEF if omitted), and I don't have a strong preference for the > > > > two > > > version topics as long as a single > > > > approach is adopted. > > > > > > > > Could others on the list speak up to provide opinions on how to > > > > handle > > > these topics? > > > > > > > > Thanks, > > > > --David > > > > > > > > > -----Original Message----- > > > > > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > > > > Sent: Wednesday, December 28, 2011 12:52 AM > > > > > To: mile@ietf.org > > > > > Cc: Brian Trammell; Moriarty, Kathleen; Black, David; > > > Kent_Landfield@McAfee.com > > > > > Subject: RE: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > > Hello all, > > > > > > > > > > I've just posted the new version of the mile-sci draft. > > > > > Though the text has changed a lot, we basically have only two > > > > > changes, > > > as > > > > > listed below: > > > > > > > > > > 1. table is changed (see section 4.1) 2. IANA description was > > > > > totally changed > > > > > > > > > > The discussion on EM_XML is still an issue, so I'd appreciate > if > > > > > you > > > could > > > > > kindly share your opinion on that. > > > > > (I personally like the idea Kathleen kindly proposed.) The new > > > > > version tentatively deleted the description of EM_XML, and use > > > the > > > > > xml defined by the IODEF dtype. > > > > > > > > > > Thank you very much for those of you who kindly gave me lots of > > > > > useful comments and supports. > > > > > I wish you a happy new year. > > > > > > > > > > Sincerely, > > > > > Take > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > > > Behalf > > > Of > > > > > > internet-drafts@ietf.org > > > > > > Sent: Wednesday, December 28, 2011 2:40 PM > > > > > > To: i-d-announce@ietf.org > > > > > > Cc: mile@ietf.org > > > > > > Subject: [mile] I-D Action: draft-ietf-mile-sci-01.txt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > Internet-Drafts directories. This draft is a work item of the > > > > > > Managed Incident > > > Lightweight > > > > > > Exchange Working Group of the IETF. > > > > > > > > > > > > Title : IODEF-extension to support structured > > > > > > cybersecurity information > > > > > > Author(s) : Takeshi Takahashi > > > > > > Kent Landfield > > > > > > Thomas Millar > > > > > > Youki Kadobayashi > > > > > > Filename : draft-ietf-mile-sci-01.txt > > > > > > Pages : 34 > > > > > > Date : 2011-12-27 > > > > > > > > > > > > This document extends the Incident Object Description > > > > > > Exchange > > > Format > > > > > > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > > > > > > cybersecurity information exchange among cybersecurity > > > > > > entities > > > by > > > > > > embedding structured information formatted by > specifications, > > > > > > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], > > > CVE(R) > > > > > > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] > > > > > > [CWSS], > > > OCIL > > > > > > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-01.txt > > > > > > > > > > > > _______________________________________________ > > > > > > mile mailing 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 sbarnum@mitre.org Tue Jan 17 11:41:14 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 9FC9021F84A1 for ; Tue, 17 Jan 2012 11:41:14 -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 JI7oEBfA1mXy for ; Tue, 17 Jan 2012 11:40:59 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 40ACB11E80AD for ; Tue, 17 Jan 2012 11:40:59 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA40621B17A3 for ; Tue, 17 Jan 2012 14:40:58 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9802221B01BE for ; Tue, 17 Jan 2012 14:40:58 -0500 (EST) Received: from IMCMBX03.MITRE.ORG ([169.254.3.140]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 17 Jan 2012 14:40:57 -0500 From: "Barnum, Sean D." To: "mile@ietf.org" Thread-Topic: Version 0.7 of the Cyber Observable eXpression (CybOX_v0.7) is now available Thread-Index: AczVT+7OH0vECSlKQHC7Jk3EntzVMA== Date: Tue, 17 Jan 2012 19:40:57 +0000 Message-ID: <7F48813B48558A4BB5CB7BB714E5B5A90BE898@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.59] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0277_01CCD526.05FF9050" MIME-Version: 1.0 Subject: [mile] Version 0.7 of the Cyber Observable eXpression (CybOX_v0.7) is now available 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, 17 Jan 2012 19:41:15 -0000 ------=_NextPart_000_0277_01CCD526.05FF9050 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0278_01CCD526.05FF9050" ------=_NextPart_001_0278_01CCD526.05FF9050 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit If you are interested, version 0.7 of the Cyber Observable eXpression (CybOX_v0.7) is now finished, has been released and is live on the website (http://cybox.mitre.org/language/index.html). The Version 0.7 release of CybOX includes a significant number of changes to improve the expressiveness of the schema to better support the broad set of use cases it targets (malware characterization, indicator and incident data sharing, event management, etc.), to improve simplicity and efficiency, and to mature descriptive formality for reference and implementation by other standards and users. We still have several things to work on and it is still evolving (as evidenced by the sub-v1 version #) but we think that this release is a significant improvement and a big step in the right direction. Please take a look and give us your constructive feedback. Release notes are on the site and highlight changes are included below. Sean Barnum sbarnum@mitre.org (703-473-8262) Highlight changes from CybOX_v0.62 to CybOX_v0.7: . Annotated all Attributes, Elements & Types throughout the core schema and most of the defined object schemas. A formal specification is in the works. . Greatly increased the expressiveness of object attributes enabling a variety of condition specifications including use of regex. The new structure enables specification not only of attribute value "equal to" something but also conditions such as: contains, does not contain, start with, ends with, greater than, greater than or equal to, less than, less than or equal to, is in range, is not in range, is in set, is not in set, fits pattern (enabling use of regex, xpath or any other pattern syntax), bitwise and, bitwise or. . Greatly enhanced the expressiveness of the Action construct to more fully characterize cyber actions for use cases such as malware characterization and event management. Details are in the bullets below. . Added the capability to describe Measure_Source content directly to Event, Action and Object constructs to enable description of the producing/observing source for each of these constructs. . Flattened out the core schema in several places through restructuring for expressiveness, yielding a simpler and more efficient schema. . For attributes and elements with enumerated value restrictions, the inline restrictions for enumerated values have been replaced with enumerated restriction types offering greater flexibility and maintainability. . Added global Pools at the highest level of the core schema for Events, Actions, Objects and Attributes to enable potential reduction of redundancy and referential efficiencies. ------=_NextPart_001_0278_01CCD526.05FF9050 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

If you are = interested, version 0.7 of the Cyber Observable eXpression (CybOX_v0.7) = is now finished, has been released and is live on the website (http://cybox.mitre.or= g/language/index.html).

The Version = 0.7 release of CybOX includes a significant number of changes to improve = the expressiveness of the schema to better support the broad set of use = cases it targets (malware characterization, indicator and incident data = sharing, event management, etc.), to improve simplicity and efficiency, = and to mature descriptive formality for reference and implementation by = other standards and users.

We still = have several things to work on and it is still evolving (as evidenced by = the sub-v1 version #) but we think that this release is a significant = improvement and a big step in the right direction.

Please take = a look and give us your constructive feedback.

Release = notes are on the site and highlight changes are included = below.

 <= /o:p>

Sean Barnum

sbarnum@mitre.org

(703-473-8262)

 <= /o:p>

Highlight changes from CybOX_v0.62 to = CybOX_v0.7:

·        = Annotated all Attributes, Elements = & Types throughout the core schema and most of the defined object = schemas. A formal specification is in the works.

·        = Greatly increased the expressiveness = of object attributes enabling a variety of condition specifications = including use of regex. The new structure enables specification not only = of attribute value “equal to” something but also conditions = such as: contains, does not contain, start with, ends with, greater = than, greater than or equal to, less than, less than or equal to, is in = range, is not in range, is in set, is not in set, fits pattern (enabling = use of regex, xpath or any other pattern syntax), bitwise and, bitwise = or.

·        = Greatly enhanced the expressiveness of = the Action construct to more fully characterize cyber actions for use = cases such as malware characterization and event management. Details are = in the bullets below.

·        = Added the capability to describe = Measure_Source content directly to Event, Action and Object constructs = to enable description of the producing/observing source for each of = these constructs.

·        = Flattened out the core schema in = several places through restructuring for expressiveness, yielding a = simpler and more efficient schema.

·        = For attributes and elements with = enumerated value restrictions, the inline restrictions for enumerated = values have been replaced with enumerated restriction types offering = greater flexibility and maintainability.

·        = Added global Pools at the highest = level of the core schema for Events, Actions, Objects and Attributes to = enable potential reduction of redundancy and referential = efficiencies.

 

 

------=_NextPart_001_0278_01CCD526.05FF9050-- ------=_NextPart_000_0277_01CCD526.05FF9050 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 Fw0xMjAxMTcxOTQwNTdaMCMGCSqGSIb3DQEJBDEWBBRZaoPmw1Gdc6Yo+QY81FOTlmla6jByBgkr BgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUg QXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAllKMHQG CyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgJZ SjCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcN AwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDAN BggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASBgIsCam2KGL13cpkBlo2gOP7Qg9B8gkmJVp3YNRg6+k3vChVT 5+fzcB7YYFsWzMKCGEwyCk52DRUGe7kUT3LRpJhXnt9rK6tfwYTPFlQNW0LbF0xJJal0eX+1q1ce Zm05xmxn9cg4ziwFe02ba+GuMhs131Afc6nyXXOl+p8N8XcHAAAAAAAA ------=_NextPart_000_0277_01CCD526.05FF9050-- From internet-drafts@ietf.org Tue Jan 17 14:00: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 5881311E80CE; Tue, 17 Jan 2012 14:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 xQJf6eo6EKd5; Tue, 17 Jan 2012 14:00:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC721F86B9; Tue, 17 Jan 2012 14:00:30 -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.64p1 Message-ID: <20120117220030.5666.23728.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 14:00:30 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-06.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: Tue, 17 Jan 2012 22:00:31 -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 : Transport of Real-time Inter-network Defense (RID) Messa= ges over HTTP/ TLS Author(s) : Brian Trammell Filename : draft-ietf-mile-rfc6046-bis-06.txt Pages : 8 Date : 2012-01-17 The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-06.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-rfc6046-bis-06.txt From trammell@tik.ee.ethz.ch Tue Jan 17 14:02: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 11C5521F851B for ; Tue, 17 Jan 2012 14:02:39 -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 Eqr-4HR+ETtV for ; Tue, 17 Jan 2012 14:02:38 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E988421F85ED for ; Tue, 17 Jan 2012 14:02:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 76C21D930A for ; Tue, 17 Jan 2012 23:02:27 +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 Sb6PxHl0cNVt for ; Tue, 17 Jan 2012 23:02:27 +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 29006D9305 for ; Tue, 17 Jan 2012 23:02:27 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Brian Trammell In-Reply-To: <20120117220030.5666.23728.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 23:02:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0979CDEB-3825-40AA-98EB-9468423908A2@tik.ee.ethz.ch> References: <20120117220030.5666.23728.idtracker@ietfa.amsl.com> To: mile@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-06.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: Tue, 17 Jan 2012 22:02:39 -0000 Greetings, all, This revision of rfc6046-bis addresses all IETF Last Call comments = received. Best regards, Brian (as author of rfc6046-bis) On Jan 17, 2012, at 11:00 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Managed Incident = Lightweight Exchange Working Group of the IETF. >=20 > Title : Transport of Real-time Inter-network Defense = (RID) Messages over HTTP/ TLS > Author(s) : Brian Trammell > Filename : draft-ietf-mile-rfc6046-bis-06.txt > Pages : 8 > Date : 2012-01-17 >=20 > The Incident Object Description Exchange Format (IODEF) defines a > common XML format for document exchange, and Realtime Internetwork > Defense (RID) defines extensions to IODEF intended for the > cooperative handling of security incidents within consortia of > network operators and enterprises. This document specifies a > application-layer protocol for RID based upon the passing of RID > messages over HTTP/TLS. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-06.txt >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Tue Jan 17 19:06: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 AAA3711E8080 for ; Tue, 17 Jan 2012 19:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.539 X-Spam-Level: X-Spam-Status: No, score=-8.539 tagged_above=-999 required=5 tests=[AWL=2.060, 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 Ob7IZxnd8e0B for ; Tue, 17 Jan 2012 19:06: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 EE81611E8076 for ; Tue, 17 Jan 2012 19:06:47 -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 q0I36jNe025678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 22:06:45 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 17 Jan 2012 22:06:28 -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 q0I36QeC032201; Tue, 17 Jan 2012 22:06:26 -0500 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 17 Jan 2012 22:06:26 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Tue, 17 Jan 2012 22:06:26 -0500 From: To: , Date: Tue, 17 Jan 2012 22:06:25 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-06.txt Thread-Index: AczVY+GLzOxSjmrUSA2QhIi0XBRq3wAKbY+w Message-ID: References: <20120117220030.5666.23728.idtracker@ietfa.amsl.com> <0979CDEB-3825-40AA-98EB-9468423908A2@tik.ee.ethz.ch> In-Reply-To: <0979CDEB-3825-40AA-98EB-9468423908A2@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] I-D Action: draft-ietf-mile-rfc6046-bis-06.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: Wed, 18 Jan 2012 03:06:48 -0000 Hi Brian, In RID's last call a couple of the message names changed, which should be r= eflected in RFC6046-bis. =20 RequestAuthorization is now Acknowledgement (makes more sense with the func= tion actually served) IncidentQuery is now Query - this was to generalize it a bit more and was o= ne of the requests. Also, any message can receive a response of Acknowledgement. This was poss= ible back in RFC6045, but nested within the communication flow section, so= it wasn't readily apparent. I adjusted the text in RFC6045 to make this m= ore clear as a possible response. If there is a problem decrypting a messa= ge or other processing issue, you need a way to provide that. This is done= through the Acknowledgement using the Justification class enumerations. Thanks, Kathleen (as author) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Tuesday, January 17, 2012 5:02 PM To: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-06.txt Greetings, all, This revision of rfc6046-bis addresses all IETF Last Call comments received= . Best regards, Brian (as author of rfc6046-bis) On Jan 17, 2012, at 11:00 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Managed Incident Lightweight Exchan= ge Working Group of the IETF. >=20 > Title : Transport of Real-time Inter-network Defense (RID) Mes= sages over HTTP/ TLS > Author(s) : Brian Trammell > Filename : draft-ietf-mile-rfc6046-bis-06.txt > Pages : 8 > Date : 2012-01-17 >=20 > The Incident Object Description Exchange Format (IODEF) defines a > common XML format for document exchange, and Realtime Internetwork > Defense (RID) defines extensions to IODEF intended for the > cooperative handling of security incidents within consortia of > network operators and enterprises. This document specifies a > application-layer protocol for RID based upon the passing of RID > messages over HTTP/TLS. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-06.txt >=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 trammell@tik.ee.ethz.ch Wed Jan 18 06:03: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 8F36821F8800 for ; Wed, 18 Jan 2012 06:03:26 -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 h3E4ND1Xnn5g for ; Wed, 18 Jan 2012 06:03:25 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7933E21F87FF for ; Wed, 18 Jan 2012 06:03:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A1376D9307; Wed, 18 Jan 2012 15:03:24 +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 QKLQ6lRaA2yA; Wed, 18 Jan 2012 15:03:24 +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 63974D9304; Wed, 18 Jan 2012 15:03:24 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Wed, 18 Jan 2012 15:03:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CD14F23-56DA-4520-B2E5-EC7C771695F5@tik.ee.ethz.ch> References: <20120117220030.5666.23728.idtracker@ietfa.amsl.com> <0979CDEB-3825-40AA-98EB-9468423908A2@tik.ee.ethz.ch> To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-06.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: Wed, 18 Jan 2012 14:03:27 -0000 Hi, Kathleen, Oops... Was so busy tracking LC that I forgot to check rfc6045-bis-06. = I've fixed this in rfc6046-bis-07, just submitted. Thanks for catching this! Cheers, Brian (apparently-distracted author hat) On Jan 18, 2012, at 4:06 AM, = wrote: > Hi Brian, >=20 > In RID's last call a couple of the message names changed, which should = be reflected in RFC6046-bis. =20 >=20 > RequestAuthorization is now Acknowledgement (makes more sense with the = function actually served) > IncidentQuery is now Query - this was to generalize it a bit more and = was one of the requests. >=20 > Also, any message can receive a response of Acknowledgement. This was = possible back in RFC6045, but nested within the communication flow = section, so it wasn't readily apparent. I adjusted the text in RFC6045 = to make this more clear as a possible response. If there is a problem = decrypting a message or other processing issue, you need a way to = provide that. This is done through the Acknowledgement using the = Justification class enumerations. >=20 > Thanks, > Kathleen (as author) >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of Brian Trammell > Sent: Tuesday, January 17, 2012 5:02 PM > To: mile@ietf.org > Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-06.txt >=20 > Greetings, all, >=20 > This revision of rfc6046-bis addresses all IETF Last Call comments = received. >=20 > Best regards, >=20 > Brian (as author of rfc6046-bis) >=20 > On Jan 17, 2012, at 11:00 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Managed Incident = Lightweight Exchange Working Group of the IETF. >>=20 >> Title : Transport of Real-time Inter-network Defense = (RID) Messages over HTTP/ TLS >> Author(s) : Brian Trammell >> Filename : draft-ietf-mile-rfc6046-bis-06.txt >> Pages : 8 >> Date : 2012-01-17 >>=20 >> The Incident Object Description Exchange Format (IODEF) defines a >> common XML format for document exchange, and Realtime Internetwork >> Defense (RID) defines extensions to IODEF intended for the >> cooperative handling of security incidents within consortia of >> network operators and enterprises. This document specifies a >> application-layer protocol for RID based upon the passing of RID >> messages over HTTP/TLS. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-06.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-06.txt >>=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 internet-drafts@ietf.org Wed Jan 18 06:03: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 9A5F821F880D; Wed, 18 Jan 2012 06:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 JuxcmtXHxc+9; Wed, 18 Jan 2012 06:03:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781021F8805; Wed, 18 Jan 2012 06:03:33 -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.64p1 Message-ID: <20120118140333.27081.46258.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 06:03:33 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-07.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: Wed, 18 Jan 2012 14:03:33 -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 : Transport of Real-time Inter-network Defense (RID) Messa= ges over HTTP/ TLS Author(s) : Brian Trammell Filename : draft-ietf-mile-rfc6046-bis-07.txt Pages : 8 Date : 2012-01-18 The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-07.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-rfc6046-bis-07.txt From kathleen.moriarty@emc.com Thu Jan 19 08:26: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 6A97921F84E4 for ; Thu, 19 Jan 2012 08:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.017 X-Spam-Level: X-Spam-Status: No, score=-9.017 tagged_above=-999 required=5 tests=[AWL=1.430, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] 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 VM5ojCk+thn8 for ; Thu, 19 Jan 2012 08:26:20 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D970A21F84DD for ; Thu, 19 Jan 2012 08:26:19 -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 q0JGQIlZ004665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jan 2012 11:26:18 -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 ; Thu, 19 Jan 2012 11:26:04 -0500 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0JGQ42d011987 for ; Thu, 19 Jan 2012 11:26:04 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub35.corp.emc.com ([::1]) with mapi; Thu, 19 Jan 2012 11:26:03 -0500 From: To: Date: Thu, 19 Jan 2012 11:26:02 -0500 Thread-Topic: UTF-8 Thread-Index: AczWxwjUKGsbolvEQiaMttX4EbK/hw== 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] UTF-8 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, 19 Jan 2012 16:26:20 -0000 Hello, For those who have implemented IODEF, do you use any other encoding besides= UTF-8? I'd like to know if it is OK to restrict RID to only allow this en= coding type. It came up as a discuss in the IESG review. If it is OK, tha= n I can close out that discuss and it will remove unnecessary complexity fo= r developers. Thank you, Kathleen Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-58= 07 | Kathleen.Moriarty@emc.com | EMC Corporation From kathleen.moriarty@emc.com Thu Jan 19 14:52:51 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 EC33621F858E for ; Thu, 19 Jan 2012 14:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.342 X-Spam-Level: X-Spam-Status: No, score=-9.342 tagged_above=-999 required=5 tests=[AWL=1.257, 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 s0xnnUf-DD22 for ; Thu, 19 Jan 2012 14:52:51 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8FB21F855A for ; Thu, 19 Jan 2012 14:52:50 -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 q0JMqmKb022496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jan 2012 17:52:49 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Thu, 19 Jan 2012 17:52: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 q0JMqWr4020326 for ; Thu, 19 Jan 2012 17:52:32 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Thu, 19 Jan 2012 17:52:31 -0500 From: To: Date: Thu, 19 Jan 2012 17:52:30 -0500 Thread-Topic: IESG Review and Internationalization Thread-Index: AczW/QYcPa/uMb3lQzCrR7tBPBhcRQ== 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] IESG Review and Internationalization 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, 19 Jan 2012 22:52:52 -0000 Hello, An issue came up in the IESG review for the reuse of the Node class from IO= DEF. IODEF doesn't handle internationalization issues with respect to full= y qualified domain names (FQDNs). The following text was agreed upon by th= e IESG: > 11. Internationalization Considerations > > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, they MUST ensure that the domain name is > represented only using ASCII characters, i.e., all of its labels > MUST be either A-labels or NR-LDH labels [RFC5890] and > internationalized labels MUST be encoded as A-labels using the > Punycode encoding [RFC3492] as described in the protocol > specification for Internationalized Domain Names in Applications > [RFC5891]. If this will cause any issues for implementations, please speak now. I thi= nk it will be fine as we mainly use it to ensure incident numbers are uniqu= e (that was the purpose in the IncidentID for this value). It would also b= e used in pulling reports and could be tied to your trust relationship mana= gement. Thank you! Kathleen Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-58= 07 | Kathleen.Moriarty@emc.com | EMC Corporation From kathleen.moriarty@emc.com Thu Jan 19 19:34: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 04CAA21F85A5 for ; Thu, 19 Jan 2012 19:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.372 X-Spam-Level: X-Spam-Status: No, score=-9.372 tagged_above=-999 required=5 tests=[AWL=1.227, 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 eeMQN0iTB77i for ; Thu, 19 Jan 2012 19:34:32 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5C02921F858A for ; Thu, 19 Jan 2012 19:34:32 -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 q0K3YSTD018779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jan 2012 22:34:29 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 19 Jan 2012 22:34:13 -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 q0K3YAfH002336 for ; Thu, 19 Jan 2012 22:34:11 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Thu, 19 Jan 2012 22:33:10 -0500 From: To: Date: Thu, 19 Jan 2012 22:34:08 -0500 Thread-Topic: IESG Review and Internationalization Thread-Index: AczW/QYcPa/uMb3lQzCrR7tBPBhcRQAJzoew 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IESG Review and Internationalization 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, 20 Jan 2012 03:34:33 -0000 Please post any objections or positive comments before Wednesday. Thank you! Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Thursday, January 19, 2012 5:53 PM To: mile@ietf.org Subject: [mile] IESG Review and Internationalization Hello, An issue came up in the IESG review for the reuse of the Node class from IO= DEF. IODEF doesn't handle internationalization issues with respect to full= y qualified domain names (FQDNs). The following text was agreed upon by th= e IESG: > 11. Internationalization Considerations > > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, they MUST ensure that the domain name is > represented only using ASCII characters, i.e., all of its labels > MUST be either A-labels or NR-LDH labels [RFC5890] and > internationalized labels MUST be encoded as A-labels using the > Punycode encoding [RFC3492] as described in the protocol > specification for Internationalized Domain Names in Applications > [RFC5891]. If this will cause any issues for implementations, please speak now. I thi= nk it will be fine as we mainly use it to ensure incident numbers are uniqu= e (that was the purpose in the IncidentID for this value). It would also b= e used in pulling reports and could be tied to your trust relationship mana= gement. Thank you! Kathleen Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-58= 07 | Kathleen.Moriarty@emc.com | EMC Corporation _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From ramartin@mitre.org Thu Jan 19 19:45: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 3E25B21F85BD for ; Thu, 19 Jan 2012 19:45:03 -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 y-4Ocg4w9Sp5 for ; Thu, 19 Jan 2012 19:45:02 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D8FD421F85A3 for ; Thu, 19 Jan 2012 19:44:51 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C628421B07FD; Thu, 19 Jan 2012 22:44:50 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AE10E21B0737; Thu, 19 Jan 2012 22:44:50 -0500 (EST) Received: from bva-172-31-16-237.mitre.org (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.339.1; Thu, 19 Jan 2012 22:44:50 -0500 Message-ID: <4F18E330.1020208@mitre.org> Date: Thu, 19 Jan 2012 22:44:48 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.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] IESG Review and Internationalization 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, 20 Jan 2012 03:45:03 -0000 This change makes sense given the role envisioned for these efforts in coordination and sharing of incident information across the world. Bob On 1/19/12 10:34 PM, kathleen.moriarty@emc.com wrote: > Please post any objections or positive comments before Wednesday. > > Thank you! > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com > Sent: Thursday, January 19, 2012 5:53 PM > To: mile@ietf.org > Subject: [mile] IESG Review and Internationalization > > Hello, > > An issue came up in the IESG review for the reuse of the Node class from IODEF. IODEF doesn't handle internationalization issues with respect to fully qualified domain names (FQDNs). The following text was agreed upon by the IESG: > >> 11. Internationalization Considerations >> >> The Node class identifies a host or network device. This document >> re-uses the definition of Node from the IODEF specification >> [RFC5070], Section 3.16. However, that document did not clearly >> specify whether a NodeName could be an Internationalized Domain Name >> (IDN). RID systems MUST treat the NodeName class as a domain name >> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >> class; if they do so, they MUST ensure that the domain name is >> represented only using ASCII characters, i.e., all of its labels >> MUST be either A-labels or NR-LDH labels [RFC5890] and >> internationalized labels MUST be encoded as A-labels using the >> Punycode encoding [RFC3492] as described in the protocol >> specification for Internationalized Domain Names in Applications >> [RFC5891]. > > > If this will cause any issues for implementations, please speak now. I think it will be fine as we mainly use it to ensure incident numbers are unique (that was the purpose in the IncidentID for this value). It would also be used in pulling reports and could be tied to your trust relationship management. > > Thank you! > Kathleen > > Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-5807 | Kathleen.Moriarty@emc.com | EMC Corporation > > > > _______________________________________________ > mile mailing 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 Jan 20 06:38:21 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 6399621F859B; Fri, 20 Jan 2012 06:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 WGMr4kismrAZ; Fri, 20 Jan 2012 06:38:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0721F8576; Fri, 20 Jan 2012 06:38:20 -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.64p1 Message-ID: <20120120143820.25714.28859.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 06:38:20 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-07.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, 20 Jan 2012 14:38:21 -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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-07.txt Pages : 83 Date : 2012-01-20 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-07.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-rfc6045-bis-07.txt From david.black@emc.com Fri Jan 20 15:42: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 1C7C021F84F1 for ; Fri, 20 Jan 2012 15:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.007 X-Spam-Level: X-Spam-Status: No, score=-109.007 tagged_above=-999 required=5 tests=[AWL=1.592, 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 bZkS7EKdvcIm for ; Fri, 20 Jan 2012 15:42:40 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8233E21F84F7 for ; Fri, 20 Jan 2012 15:42:34 -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 q0KNgXAf030908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jan 2012 18:42:33 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 20 Jan 2012 18:42:16 -0500 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0KNgFA1017461 for ; Fri, 20 Jan 2012 18:42:16 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub36.corp.emc.com ([::1]) with mapi; Fri, 20 Jan 2012 18:42:15 -0500 From: To: , Date: Fri, 20 Jan 2012 18:42:14 -0500 Thread-Topic: IESG Review and Internationalization Thread-Index: AczW/QYcPa/uMb3lQzCrR7tBPBhcRQAwDJYA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1284@MX14A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] IESG Review and Internationalization 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, 20 Jan 2012 23:42:41 -0000 Hello Kathleen, > An issue came up in the IESG review for the reuse of the Node class from = IODEF. IODEF doesn't handle > internationalization issues with respect to fully qualified domain names = (FQDNs). The following text > was agreed upon by the IESG: >=20 > > 11. Internationalization Considerations > > > > The Node class identifies a host or network device. This document > > re-uses the definition of Node from the IODEF specification > > [RFC5070], Section 3.16. However, that document did not clearly > > specify whether a NodeName could be an Internationalized Domain Nam= e > > (IDN). RID systems MUST treat the NodeName class as a domain name > > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > > class; if they do so, they MUST ensure that the domain name is > > represented only using ASCII characters, i.e., all of its labels > > MUST be either A-labels or NR-LDH labels [RFC5890] and > > internationalized labels MUST be encoded as A-labels using the > > Punycode encoding [RFC3492] as described in the protocol > > specification for Internationalized Domain Names in Applications > > [RFC5891]. >=20 >=20 > If this will cause any issues for implementations, please speak now. I t= hink it will be fine as we > mainly use it to ensure incident numbers are unique (that was the purpose= in the IncidentID for this > value). It would also be used in pulling reports and could be tied to yo= ur trust relationship > management. I'm not a RID implementer, and so would like to hear from those who are (or= expect to be). I have a design concern about this proposed approach, based in part upon yo= ur other suggestion that UTF-8 should be the only encoding for RID documents (FWIW, that sugges= tion seems like a good idea to me). This concern is not major, as the above punycode approach is = workable, but there may be a difference in usability of RID in practice. Punycode was originally devised to cope with the fact that the deployed DNS= could not deal directly with Unicode, and in particular with UTF-8, courtesy of the DNS not being 8= -bit [character] clean. In contrast, it appears that RID is about to require that UTF-8 be the only= XML document encoding, and hence all systems that process RID have to be 8-bit clean and capable o= f dealing with UTF-8. Punycode uses a subset of the 7-bit ASCII characters to encode the offset n= umbers for a finite state machine that generates the non-ASCII Unicode characters, and hence pu= nycode is not really human-readable (humans can't readily determine what the Unicode was that ge= nerated the punycode - the punycode suffix looks like ASCII gobbledygook). See http://en.wikipe= dia.org/wiki/Punycode, and keep in mind that the simple example on that page only has one non-ASCI= I character whose Unicode code point has a relatively small value. In contrast, UTF-8 is byte-encoded, and hence is human readable, albeit wit= h some effort to understand multi-byte characters when they don't display as Unicode. That = effort's akin to remembering that %20 in a URL encodes a space, although it's not that simpl= e. Assuming that RID is going to require UTF-8, it seems simpler to put IDNs i= nto RID as UTF-8 and do any Unicode-punycode conversion in the DNS clients used by systems that = process RID messages. In contrast, using punycode in RID either displays punycode (may be ok if i= t never has to be matched against the domain name elsewhere), or requires additional function= ality to convert between Unicode and punycode in systems that process RID, instead of isolat= ing that functionality to the DNS clients (where punycode belongs, IMHO). Beyond that, there's a = distinct possibility that the same IDN may be sent as punycode in the Node class and as UTF-8 el= sewhere in the same RID message (e.g., in a syslog or trace record in the XML that's enveloped = by RID), and that doesn't seem helpful to an incident handler. I wouldn't ban punycode - if the only alternative to using punycode is to n= ot send the incident information, then punycode probably ought to be used. OTOH, banning use of= UTF-8 for IDNs in a document that MUST be in UTF-8 seems peculiar. What do other people think about this? 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 kathleen.moriarty@emc.com Fri Jan 20 16:27: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 7D81E21F8589 for ; Fri, 20 Jan 2012 16:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.452 X-Spam-Level: X-Spam-Status: No, score=-9.452 tagged_above=-999 required=5 tests=[AWL=1.147, 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 An3TmJQ1mU02 for ; Fri, 20 Jan 2012 16:27:21 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 784FB21F8587 for ; Fri, 20 Jan 2012 16:27:21 -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 q0L0RKbA006419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jan 2012 19:27:20 -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 ; Fri, 20 Jan 2012 19:27:12 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0L0RB0L020589 for ; Fri, 20 Jan 2012 19:27:12 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Fri, 20 Jan 2012 19:27:11 -0500 From: To: Date: Fri, 20 Jan 2012 19:27:06 -0500 Thread-Topic: IESG Review and Internationalization Thread-Index: AczX02qMX6c3glqlQv+dgpasON+FHQ== Message-ID: <3BF3DEAB-AC08-4C59-86B1-7D5A7BEA0B18@emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1284@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1284@MX14A.corp.emc.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] IESG Review and Internationalization 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, 21 Jan 2012 00:27:22 -0000 Thank you, David. You make really good points and the explanation is appre= ciated. Do others have opinions? Thanks, Kathleen Sent from my iPhone On Jan 20, 2012, at 6:42 PM, "Black, David" wrote: > Hello Kathleen, >=20 >> An issue came up in the IESG review for the reuse of the Node class from= IODEF. IODEF doesn't handle >> internationalization issues with respect to fully qualified domain names= (FQDNs). The following text >> was agreed upon by the IESG: >>=20 >>> 11. Internationalization Considerations >>>=20 >>> The Node class identifies a host or network device. This document >>> re-uses the definition of Node from the IODEF specification >>> [RFC5070], Section 3.16. However, that document did not clearly >>> specify whether a NodeName could be an Internationalized Domain Name >>> (IDN). RID systems MUST treat the NodeName class as a domain name >>> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >>> class; if they do so, they MUST ensure that the domain name is >>> represented only using ASCII characters, i.e., all of its labels >>> MUST be either A-labels or NR-LDH labels [RFC5890] and >>> internationalized labels MUST be encoded as A-labels using the >>> Punycode encoding [RFC3492] as described in the protocol >>> specification for Internationalized Domain Names in Applications >>> [RFC5891]. >>=20 >>=20 >> If this will cause any issues for implementations, please speak now. I = think it will be fine as we >> mainly use it to ensure incident numbers are unique (that was the purpos= e in the IncidentID for this >> value). It would also be used in pulling reports and could be tied to y= our trust relationship >> management. >=20 > I'm not a RID implementer, and so would like to hear from those who are (= or expect to be). >=20 > I have a design concern about this proposed approach, based in part upon = your other suggestion > that UTF-8 should be the only encoding for RID documents (FWIW, that sugg= estion seems like a good > idea to me). This concern is not major, as the above punycode approach i= s workable, but there > may be a difference in usability of RID in practice. >=20 > Punycode was originally devised to cope with the fact that the deployed D= NS could not deal directly > with Unicode, and in particular with UTF-8, courtesy of the DNS not being= 8-bit [character] clean. > In contrast, it appears that RID is about to require that UTF-8 be the on= ly XML document encoding, > and hence all systems that process RID have to be 8-bit clean and capable= of dealing with UTF-8. >=20 > Punycode uses a subset of the 7-bit ASCII characters to encode the offset= numbers for a finite > state machine that generates the non-ASCII Unicode characters, and hence = punycode is not really > human-readable (humans can't readily determine what the Unicode was that = generated the punycode > - the punycode suffix looks like ASCII gobbledygook). See http://en.wiki= pedia.org/wiki/Punycode, > and keep in mind that the simple example on that page only has one non-AS= CII character whose > Unicode code point has a relatively small value. >=20 > In contrast, UTF-8 is byte-encoded, and hence is human readable, albeit w= ith some effort to > understand multi-byte characters when they don't display as Unicode. Tha= t effort's akin to > remembering that %20 in a URL encodes a space, although it's not that sim= ple. >=20 > Assuming that RID is going to require UTF-8, it seems simpler to put IDNs= into RID as UTF-8 and > do any Unicode-punycode conversion in the DNS clients used by systems tha= t process RID messages. >=20 > In contrast, using punycode in RID either displays punycode (may be ok if= it never has to be > matched against the domain name elsewhere), or requires additional functi= onality to convert > between Unicode and punycode in systems that process RID, instead of isol= ating that functionality > to the DNS clients (where punycode belongs, IMHO). Beyond that, there's = a distinct possibility > that the same IDN may be sent as punycode in the Node class and as UTF-8 = elsewhere in the same > RID message (e.g., in a syslog or trace record in the XML that's envelope= d by RID), and that > doesn't seem helpful to an incident handler. >=20 > I wouldn't ban punycode - if the only alternative to using punycode is to= not send the incident > information, then punycode probably ought to be used. OTOH, banning use = of UTF-8 for IDNs in a > document that MUST be in UTF-8 seems peculiar. >=20 > What do other people think about this? >=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 From internet-drafts@ietf.org Sun Jan 22 14:37:32 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 D6B6D21F85A3; Sun, 22 Jan 2012 14:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 6aXmugLLEcwg; Sun, 22 Jan 2012 14:37:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7067421F8562; Sun, 22 Jan 2012 14:37:32 -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.64p1 Message-ID: <20120122223732.29508.25128.idtracker@ietfa.amsl.com> Date: Sun, 22 Jan 2012 14:37:32 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-08.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: Sun, 22 Jan 2012 22:37:33 -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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-08.txt Pages : 83 Date : 2012-01-22 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-08.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-rfc6045-bis-08.txt From kathleen.moriarty@emc.com Sun Jan 22 14:44: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 A7CFF21F859E for ; Sun, 22 Jan 2012 14:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.476 X-Spam-Level: X-Spam-Status: No, score=-9.476 tagged_above=-999 required=5 tests=[AWL=1.123, 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 MZrlkvlSHtPt for ; Sun, 22 Jan 2012 14:44:40 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id C648C21F8595 for ; Sun, 22 Jan 2012 14:44:39 -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 q0MMicIX029178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 Jan 2012 17:44:38 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Sun, 22 Jan 2012 17:44: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 q0MMiOuK013120 for ; Sun, 22 Jan 2012 17:44:24 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Sun, 22 Jan 2012 17:43:13 -0500 From: To: Date: Sun, 22 Jan 2012 17:44:23 -0500 Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-08.txt Thread-Index: AczZVofXWLWCjgpaQe2jKtnBzi1uPgAAAQCe Message-ID: References: <20120122223732.29508.25128.idtracker@ietfa.amsl.com> In-Reply-To: <20120122223732.29508.25128.idtracker@ietfa.amsl.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: [mile] FW: I-D Action: draft-ietf-mile-rfc6045-bis-08.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: Sun, 22 Jan 2012 22:44:40 -0000 Hello, The attached version corrects a couple of nits from 07 through the IESG rev= iew. Comments on the Internationalization questions (and points) raised by David= Black are encouraged. Also, in the IESG review, there were some issues with a couple of the enume= rations for PolicyRegion and TrafficTypes. LawEnforcement was removed and = section 9.6 was added to discuss application level profiles for sharing gro= ups and entities. The AcrossNationalBoundaries was changed to DataWithHand= lingRequirements and the definition was changed. The OfficialBusiness enum= eration was changed to RestrictedAudience with an updated definition. The = new name "RestrictedAudience" is not a perfect fit for the function, so if = there are suggestions that would improve the label to better meet the defin= ition, please post them to the list. Please provide any comments to the list by Wednesday. Thank you! Kathleen (as author) ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of internet-d= rafts@ietf.org [internet-drafts@ietf.org] Sent: Sunday, January 22, 2012 5:37 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-08.txt 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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-08.txt Pages : 83 Date : 2012-01-22 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-08.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-rfc6045-bis-08.txt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From internet-drafts@ietf.org Sun Jan 22 23:32: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 D2D0321F863B; Sun, 22 Jan 2012 23:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cmUpRHADA3Pp; Sun, 22 Jan 2012 23:32:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180D521F8456; Sun, 22 Jan 2012 23:32:10 -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.64p1 Message-ID: <20120123073210.16029.292.idtracker@ietfa.amsl.com> Date: Sun, 22 Jan 2012 23:32:10 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-08.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: Mon, 23 Jan 2012 07:32:26 -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 : Transport of Real-time Inter-network Defense (RID) Messa= ges over HTTP/ TLS Author(s) : Brian Trammell Filename : draft-ietf-mile-rfc6046-bis-08.txt Pages : 8 Date : 2012-01-22 The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-08.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-rfc6046-bis-08.txt From trammell@tik.ee.ethz.ch Sun Jan 22 23:38: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 163FC11E8073 for ; Sun, 22 Jan 2012 23:38:09 -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 8-o9+E100AMc for ; Sun, 22 Jan 2012 23:38: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 5B8CF11E8072 for ; Sun, 22 Jan 2012 23:38:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 73845D9305; Mon, 23 Jan 2012 08:38:07 +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 nFB-DBOTf-61; Mon, 23 Jan 2012 08:38:07 +0100 (MET) Received: from [10.90.4.76] (unknown [89.200.200.49]) (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 B1647D9300; Mon, 23 Jan 2012 08:38:06 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Brian Trammell Date: Mon, 23 Jan 2012 08:38:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1104CBBC-083A-4A19-BF74-EE6D6D5BF805@tik.ee.ethz.ch> References: <20120123073210.16029.292.idtracker@ietfa.amsl.com> To: mile@ietf.org X-Mailer: Apple Mail (2.1084) Cc: mile-chairs@tools.ietf.org Subject: [mile] Fwd: I-D Action: draft-ietf-mile-rfc6046-bis-08.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: Mon, 23 Jan 2012 07:38:09 -0000 Greetings, all, Revision 08 of 6046-bis is now available; this revision addresses all = still-outstanding comments, including those from the Gen-ART review (and = therefore the subject of the DISCUSS on the document). Important = changes: * 3xx redirects permitted but not recommended, to allow RID messages to = be sent from an HTTP client which cannot disable redirection (e.g. = w3c-standard XmlHttpRequest) * clarified language on TLS mutual authentication I believe this revision addresses all outstanding concerns with the = document. Best regards, Brian (as author of 6046-bis) Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 23, 2012 8:32:10 AM GMT+01:00 > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Managed Incident = Lightweight Exchange Working Group of the IETF. >=20 > Title : Transport of Real-time Inter-network Defense = (RID) Messages over HTTP/ TLS > Author(s) : Brian Trammell > Filename : draft-ietf-mile-rfc6046-bis-08.txt > Pages : 8 > Date : 2012-01-22 >=20 > The Incident Object Description Exchange Format (IODEF) defines a > common XML format for document exchange, and Realtime Internetwork > Defense (RID) defines extensions to IODEF intended for the > cooperative handling of security incidents within consortia of > network operators and enterprises. This document specifies a > application-layer protocol for RID based upon the passing of RID > messages over HTTP/TLS. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-08.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-08.txt >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Mon Jan 23 08:56: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 94C0621F873C for ; Mon, 23 Jan 2012 08:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.700, 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 ot4yAzoRo3Tu for ; Mon, 23 Jan 2012 08:56:13 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 087C021F872D for ; Mon, 23 Jan 2012 08:56:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 39F27D9304 for ; Mon, 23 Jan 2012 17:56:12 +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 6tDOav72XPaq for ; Mon, 23 Jan 2012 17:56:12 +0100 (MET) Received: from [192.168.1.9] (unknown [109.130.57.164]) (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 E94D2D9300 for ; Mon, 23 Jan 2012 17:56:11 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jan 2012 17:56:11 +0100 Message-Id: <4E075BF1-5F73-4B12-B77F-3F69010784F7@tik.ee.ethz.ch> To: mile@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mile] CN-ID vs DNS-ID for RID over HTTPS 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, 23 Jan 2012 16:56:13 -0000 Greetings, all, In addressing Gen-ART review comments on rfc6046-bis, a question about = certificates identifying RID endpoints has arisen. We certainly prefer DNS-ID (per RFC 6125) identifiers for X.509 = certificates identifying RID systems; however, does anyone see a need to = support "legacy" CN-ID (i.e., to support older certificate authorities) = for RID? The preference is _not_ to support CN-ID (see section 2.3 of = RFC 6125 for reasons why) in new protocols. Best regards, Brian (as 6046-bis author)= From Kent_Landfield@mcafee.com Mon Jan 23 09:05: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 D534A21F86EB for ; Mon, 23 Jan 2012 09:05:44 -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 p2Dxy5fuynJc for ; Mon, 23 Jan 2012 09:05:44 -0800 (PST) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 0289021F86CF for ; Mon, 23 Jan 2012 09:05:43 -0800 (PST) Received: from (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 41af_0305_6f278310_45e4_11e1_bd08_00219b929abd; Mon, 23 Jan 2012 11:05:21 -0600 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Mon, 23 Jan 2012 11:04:00 -0600 From: To: , Date: Mon, 23 Jan 2012 11:04:36 -0600 Thread-Topic: [mile] CN-ID vs DNS-ID for RID over HTTPS Thread-Index: AczZ8QAuetq2ddLMTj6MIMUu/gUs7Q== Message-ID: In-Reply-To: <4E075BF1-5F73-4B12-B77F-3F69010784F7@tik.ee.ethz.ch> 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_CB42EE6B29577kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [mile] CN-ID vs DNS-ID for RID over HTTPS 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, 23 Jan 2012 17:05:44 -0000 --_000_CB42EE6B29577kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, I see no reason to include legacy support if we have a preference to NOT su= pport it going forward. This could lead to unneeded confusion and adds no v= alue from my perspective. Thanks. 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: Brian Trammell > Date: Mon, 23 Jan 2012 10:56:11 -0600 To: "mile@ietf.org" > Subject: [mile] CN-ID vs DNS-ID for RID over HTTPS Greetings, all, In addressing Gen-ART review comments on rfc6046-bis, a question about cert= ificates identifying RID endpoints has arisen. We certainly prefer DNS-ID (per RFC 6125) identifiers for X.509 certificate= s identifying RID systems; however, does anyone see a need to support "lega= cy" CN-ID (i.e., to support older certificate authorities) for RID? The pre= ference is _not_ to support CN-ID (see section 2.3 of RFC 6125 for reasons = why) in new protocols. Best regards, Brian (as 6046-bis author) _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_CB42EE6B29577kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bria= n,

I see no reason to include legacy support if we= have a preference to NOT support it going forward. This could lead to= unneeded confusion and adds no value from my perspective.

Thanks.

Kent Landfield
Director Content Strategy, A= rchitecture and Standards


5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Brian Trammell <trammell@tik.ee.ethz.ch>
Date: Mon, 23 Jan 2012 10:56:11 -0600
To: "mile@ietf.org" <mile@ietf.org= >
Subject: [mile] CN-ID vs D= NS-ID for RID over HTTPS

Greetings, all,

In addressing Gen-ART review comments on rfc6046-bis, a question abo= ut certificates identifying RID endpoints has arisen.

<= div>We certainly prefer DNS-ID (per RFC 6125) identifiers for X.509 certifi= cates identifying RID systems; however, does anyone see a need to support "= legacy" CN-ID (i.e., to support older certificate authorities) for RID? The= preference is _not_ to support CN-ID (see section 2.3 of RFC 6125 for reas= ons why) in new protocols.

Best regards,

Brian (as 6046-bis author)
______________________= _________________________
mile mailing list

--_000_CB42EE6B29577kentlandfieldmcafeecom_-- From trammell@tik.ee.ethz.ch Tue Jan 24 06:03:12 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 6C09A21F852B for ; Tue, 24 Jan 2012 06:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 rvGjq9wEYQ+2 for ; Tue, 24 Jan 2012 06:03:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 04CDE21F84F6 for ; Tue, 24 Jan 2012 06:03:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BC2BAD9307; Tue, 24 Jan 2012 15:03:09 +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 rJTfRyOmPBc3; Tue, 24 Jan 2012 15:03:09 +0100 (MET) Received: from [172.17.206.142] (unknown [147.67.4.98]) (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 49B2DD9300; Tue, 24 Jan 2012 15:03:09 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <3BF3DEAB-AC08-4C59-86B1-7D5A7BEA0B18@emc.com> Date: Tue, 24 Jan 2012 15:03:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6396304D-F34A-419B-A578-F2386CA7C680@tik.ee.ethz.ch> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1284@MX14A.corp.emc.com> <3BF3DEAB-AC08-4C59-86B1-7D5A7BEA0B18@emc.com> To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] IESG Review and Internationalization 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, 24 Jan 2012 14:03:12 -0000 Hi, Kathleen, all, Speaking as a contributor, I agree in the large with David's assessment = here. First off, mandating UTF-8 for RID in general, as in another thread, = seems to me to really be the only choice. This makes the choice of = Punycode look a little odd, especially since there doesn't seem to be = much benefit to being "closer to the wire" for DNS. While Node will be used by RID implementations for display, it will = probably also be commonly used in comparisons (lookups will often be = done based on IncidentSource, for instance). In this case, a normalized = representation is crucial. Either U-label or A-label forms of an IDN = suffice here, I believe. So I think it makes sense to call NodeName in the Node class in RID a = domain name slot [RFC5890], but to allow the U-label and A-label (and by = extension NR-LDH) forms. Since U- and A-labels are both 1. = programmatically recognizable and 2. mutually convertible to each other, = this allows RID implementations to use whichever form is more convenient = at the time without losing any information. None of this fixes the fact that we have the same issue in IODEF; I = think after we have finished 6045-bis and 6046-bis, we should look into = what can be done to define IDN support for IODEF, based on the 6045-bis = definition. Best regards, Brian (author hat) On Jan 21, 2012, at 1:27 AM, = wrote: > Thank you, David. You make really good points and the explanation is = appreciated. Do others have opinions? >=20 > Thanks, > Kathleen >=20 > Sent from my iPhone >=20 > On Jan 20, 2012, at 6:42 PM, "Black, David" = wrote: >=20 >> Hello Kathleen, >>=20 >>> An issue came up in the IESG review for the reuse of the Node class = from IODEF. IODEF doesn't handle >>> internationalization issues with respect to fully qualified domain = names (FQDNs). The following text >>> was agreed upon by the IESG: >>>=20 >>>> 11. Internationalization Considerations >>>>=20 >>>> The Node class identifies a host or network device. This = document >>>> re-uses the definition of Node from the IODEF specification >>>> [RFC5070], Section 3.16. However, that document did not clearly >>>> specify whether a NodeName could be an Internationalized Domain = Name >>>> (IDN). RID systems MUST treat the NodeName class as a domain = name >>>> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >>>> class; if they do so, they MUST ensure that the domain name is >>>> represented only using ASCII characters, i.e., all of its labels >>>> MUST be either A-labels or NR-LDH labels [RFC5890] and >>>> internationalized labels MUST be encoded as A-labels using the >>>> Punycode encoding [RFC3492] as described in the protocol >>>> specification for Internationalized Domain Names in Applications >>>> [RFC5891]. >>>=20 >>>=20 >>> If this will cause any issues for implementations, please speak now. = I think it will be fine as we >>> mainly use it to ensure incident numbers are unique (that was the = purpose in the IncidentID for this >>> value). It would also be used in pulling reports and could be tied = to your trust relationship >>> management. >>=20 >> I'm not a RID implementer, and so would like to hear from those who = are (or expect to be). >>=20 >> I have a design concern about this proposed approach, based in part = upon your other suggestion >> that UTF-8 should be the only encoding for RID documents (FWIW, that = suggestion seems like a good >> idea to me). This concern is not major, as the above punycode = approach is workable, but there >> may be a difference in usability of RID in practice. >>=20 >> Punycode was originally devised to cope with the fact that the = deployed DNS could not deal directly >> with Unicode, and in particular with UTF-8, courtesy of the DNS not = being 8-bit [character] clean. >> In contrast, it appears that RID is about to require that UTF-8 be = the only XML document encoding, >> and hence all systems that process RID have to be 8-bit clean and = capable of dealing with UTF-8. >>=20 >> Punycode uses a subset of the 7-bit ASCII characters to encode the = offset numbers for a finite >> state machine that generates the non-ASCII Unicode characters, and = hence punycode is not really >> human-readable (humans can't readily determine what the Unicode was = that generated the punycode >> - the punycode suffix looks like ASCII gobbledygook). See = http://en.wikipedia.org/wiki/Punycode, >> and keep in mind that the simple example on that page only has one = non-ASCII character whose >> Unicode code point has a relatively small value. >>=20 >> In contrast, UTF-8 is byte-encoded, and hence is human readable, = albeit with some effort to >> understand multi-byte characters when they don't display as Unicode. = That effort's akin to >> remembering that %20 in a URL encodes a space, although it's not that = simple. >>=20 >> Assuming that RID is going to require UTF-8, it seems simpler to put = IDNs into RID as UTF-8 and >> do any Unicode-punycode conversion in the DNS clients used by systems = that process RID messages. >>=20 >> In contrast, using punycode in RID either displays punycode (may be = ok if it never has to be >> matched against the domain name elsewhere), or requires additional = functionality to convert >> between Unicode and punycode in systems that process RID, instead of = isolating that functionality >> to the DNS clients (where punycode belongs, IMHO). Beyond that, = there's a distinct possibility >> that the same IDN may be sent as punycode in the Node class and as = UTF-8 elsewhere in the same >> RID message (e.g., in a syslog or trace record in the XML that's = enveloped by RID), and that >> doesn't seem helpful to an incident handler. >>=20 >> I wouldn't ban punycode - if the only alternative to using punycode = is to not send the incident >> information, then punycode probably ought to be used. OTOH, banning = use of UTF-8 for IDNs in a >> document that MUST be in UTF-8 seems peculiar. >>=20 >> What do other people think about this? >>=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 kathleen.moriarty@emc.com Wed Jan 25 06:45: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 ED1C221F86F4 for ; Wed, 25 Jan 2012 06:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.543 X-Spam-Level: X-Spam-Status: No, score=-9.543 tagged_above=-999 required=5 tests=[AWL=1.055, 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 DY4bAscDg1AU for ; Wed, 25 Jan 2012 06:45:26 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id C806221F86F3 for ; Wed, 25 Jan 2012 06:45:25 -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 q0PEjNjn008431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 09:45:24 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 25 Jan 2012 09:45:18 -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 q0PEjHNw030974; Wed, 25 Jan 2012 09:45:18 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 25 Jan 2012 09:45:17 -0500 From: To: , , Date: Wed, 25 Jan 2012 09:45:16 -0500 Thread-Topic: [mile] CN-ID vs DNS-ID for RID over HTTPS Thread-Index: AczZ8QAuetq2ddLMTj6MIMUu/gUs7QBfgLIA Message-ID: References: <4E075BF1-5F73-4B12-B77F-3F69010784F7@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: multipart/alternative; boundary="_000_AE31510960917D478171C79369B660FA0E2BFCCA37MX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: karen.reinhardt@rsa.com Subject: Re: [mile] CN-ID vs DNS-ID for RID over HTTPS 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, 25 Jan 2012 14:45:27 -0000 --_000_AE31510960917D478171C79369B660FA0E2BFCCA37MX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, I agree that we should not need to support CN-IDs. I reached out to the RS= A lead PKI Architect who has tons of recent experience with a vast array of= PKI implementations to ask her about the level of support for DNS-IDs. E= ssentially, she does not think it would be a hurdle for a new product deplo= yment. Here is her response: --------- As a practical matter, DNS-ID has been supported by most CAs for a number o= f years now. If a CA system does not support the DNS-ID, I would suggest t= hat that CA be encouraged/forced to live up to the standard rather than per= petuate possible security weaknesses. Because of this, I believe that lega= cy support should not be extended. Regards, Karen Reinhardt Lead PKI Architect, Professional Services RSA, The Security Division of EMC ------- The guidance in RFC6125 is very good, but I am not sure we will need to pro= vide that support unless people in the IESG see older CAs that do not suppo= rt DNS-IDs still. RFC6125 cites that this may only be an issue for older C= As and allowed for support when necessary for that reason. RFC6125 was pub= lished in March 2011 and is general to all TLS connections. Our use case i= s one that deals with (potentially) very sensitive information. If it was = allowed, I would add a security consideration to have peers include this in= their policy reviews when developing sharing agreements. This would help = them to understand it is a control they should be aware of when sharing inf= ormation. Thank you, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Monday, January 23, 2012 12:05 PM To: trammell@tik.ee.ethz.ch; mile@ietf.org Subject: Re: [mile] CN-ID vs DNS-ID for RID over HTTPS Brian, I see no reason to include legacy support if we have a preference to NOT su= pport it going forward. This could lead to unneeded confusion and adds no v= alue from my perspective. Thanks. 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: Brian Trammell > Date: Mon, 23 Jan 2012 10:56:11 -0600 To: "mile@ietf.org" > Subject: [mile] CN-ID vs DNS-ID for RID over HTTPS Greetings, all, In addressing Gen-ART review comments on rfc6046-bis, a question about cert= ificates identifying RID endpoints has arisen. We certainly prefer DNS-ID (per RFC 6125) identifiers for X.509 certificate= s identifying RID systems; however, does anyone see a need to support "lega= cy" CN-ID (i.e., to support older certificate authorities) for RID? The pre= ference is _not_ to support CN-ID (see section 2.3 of RFC 6125 for reasons = why) in new protocols. Best regards, Brian (as 6046-bis author) _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_AE31510960917D478171C79369B660FA0E2BFCCA37MX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,

&nb= sp;

I agree that we should not = need to support CN-IDs.  I reached out to the RSA lead PKI Architect w= ho has tons of recent experience with a vast array of PKI implementations t= o ask her about the level of support for DNS-IDs.   Essentially, = she does not think it would be a hurdle for a new product deployment. = Here is her response:

 

---------

As a practical matter, DNS-ID has been suppor= ted by most CAs for a number of years now.  If a CA system does not su= pport the DNS-ID, I would suggest that that CA be encouraged/forced to live= up to the standard rather than perpetuate possible security weaknesses.&nb= sp; Because of this, I believe that legacy support should not be extended.<= o:p>

 

Regards,

 

Karen Reinhardt

Lead PKI Ar= chitect, Professional Services

RSA, The = Security Division of EMC

-------<= o:p>

 

The guidance in RFC6125 is very good, but I a= m not sure we will need to provide that support unless people in the IESG s= ee older CAs that do not support DNS-IDs still.  RFC6125 cites that th= is may only be an issue for older CAs and allowed for support when necessar= y for that reason.  RFC6125 was published in March 2011 and is general= to all TLS connections.  Our use case is one that deals with (potenti= ally) very sensitive information.  If it was allowed, I would add a se= curity consideration to have peers include this in their policy reviews whe= n developing sharing agreements.  This would help them to understand i= t is a control they should be aware of when sharing information.=

 

Thank you,

Kathleen

 <= /o:p>

From: mile-bounces@ietf.= org [mailto:mile-bounces@ietf.org] On Behalf Of Kent_Landfield@McAfe= e.com
Sent: Monday, January 23, 2012 12:05 PM
To: tramm= ell@tik.ee.ethz.ch; mile@ietf.org
Subject: Re: [mile] CN-ID vs DN= S-ID for RID over HTTPS

 

 

From: Brian Trammell <trammell@tik.ee.ethz.ch>
Date: M= on, 23 Jan 2012 10:56:11 -0600
To: "mile@ietf.org" <mile@= ietf.org>
Subject: [mile] CN-ID vs DNS-ID for RID over HTT= PS

 

Greetings, all,

<= o:p> 

In addressing Gen-ART review comments on rfc6046-bis, a questio= n about certificates identifying RID endpoints has arisen.

 = ;

We certainly prefer DNS-ID (per RFC 6125) identifiers for X.509 certific= ates identifying RID systems; however, does anyone see a need to support &q= uot;legacy" CN-ID (i.e., to support older certificate authorities) for= RID? The preference is _not_ to support CN-ID (see section 2.3 of RFC 6125= for reasons why) in new protocols.

 

Best regards,

=  

Brian (as 6046-bis author)

_____________________________= __________________

mile mailing list

 =

= --_000_AE31510960917D478171C79369B660FA0E2BFCCA37MX06Acorpemcc_-- From david.black@emc.com Wed Jan 25 09:39: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 3891A11E8094 for ; Wed, 25 Jan 2012 09:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.15 X-Spam-Level: X-Spam-Status: No, score=-109.15 tagged_above=-999 required=5 tests=[AWL=1.449, 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 1vHnKtAtmCBp for ; Wed, 25 Jan 2012 09:39:37 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0ED21F8613 for ; Wed, 25 Jan 2012 09:39:37 -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 q0PHdaBi013125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2012 12:39:36 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 25 Jan 2012 12:39:17 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PHdG5F008279 for ; Wed, 25 Jan 2012 12:39:17 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Wed, 25 Jan 2012 12:39:16 -0500 From: To: Date: Wed, 25 Jan 2012 12:39:13 -0500 Thread-Topic: 6046-bis - Client certificate identity check Thread-Index: AczbiEB/wUKqGdW7T4qJBVN+0iRGCQ== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {EC21195D-6166-4052-9464-C6A2867CE447} x-cr-hashedpuzzle: Aoia ApTc BC5A Bups Cs/O DzYf EFsb Eapy Fp6O FueY GywM IQ+h JDed Jze2 KJzS Ko6a; 1; bQBpAGwAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EC21195D-6166-4052-9464-C6A2867CE447}; ZABhAHYAaQBkAC4AYgBsAGEAYwBrAEAAZQBtAGMALgBjAG8AbQA=; Wed, 25 Jan 2012 17:39:13 GMT; NgAwADQANgAtAGIAaQBzACAALQAgAEMAbABpAGUAbgB0ACAAYwBlAHIAdABpAGYAaQBjAGEAdABlACAAaQBkAGUAbgB0AGkAdAB5ACAAYwBoAGUAYwBrAA== 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: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 17:39:38 -0000 Brian and Kathleen, I think I found something in looking at the text related to the question ab= out certificate identities, but some more input would be useful. The 6046-bis-08 draft says: RID systems MUST verify the identity of their peers against that stored in the certificate presented, as in section 6 of [RFC6125]. That covers verification of the identity of the receiving system (the ident= ity in the TLS server certificate has to match host component of URI for HTTP),= but I don't think it covers verification of the identity of the sending system,= as Section 6 of RFC 6125 concerns only service identity. I'd suggest adding some text that requires that the identity of the sending system in the TLS client certificate match the NodeName in the Node element of the RIDPolicy class if the NodeName is present. That "is present" compli= cation is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, because RFC 5070 does not require that NodeName be present.=20 I'm not sure what to do if NodeName is absent - a possible approach would b= e to not go there, and instead add a requirement to 6045-bis that NodeName MUST = be present in the Node element of the RIDPolicy class in order to facilitate this identity check. What do other people think? 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 kathleen.moriarty@emc.com Wed Jan 25 10:21:12 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 EDB9421F85CE for ; Wed, 25 Jan 2012 10:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.564 X-Spam-Level: X-Spam-Status: No, score=-9.564 tagged_above=-999 required=5 tests=[AWL=1.035, 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 drKNQaGfIVdQ for ; Wed, 25 Jan 2012 10:21:12 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8E521F85C4 for ; Wed, 25 Jan 2012 10:21:11 -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 q0PIL7CG020520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2012 13:21:10 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 25 Jan 2012 13:20:53 -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 q0PIKrKL030598 for ; Wed, 25 Jan 2012 13:20:53 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Wed, 25 Jan 2012 13:20:53 -0500 From: To: , Date: Wed, 25 Jan 2012 13:20:52 -0500 Thread-Topic: 6046-bis - Client certificate identity check Thread-Index: AczbiEB/wUKqGdW7T4qJBVN+0iRGCQAAxUtQ Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 18:21:13 -0000 Hi David, Thank you for the comments. If text is added, it will need to be specific = to the instance of Node in RID or IODEF. This would mean the CN would be u= sed for this purpose (if UTF-8 names are OKed for use in RID NodeNames with= the internationalization discussions). RID uses Node in two places and it= may make more sense to reference the one in the IODEF document or change s= omething in RID. Instances of where 'Node' appears: 1) Node in SourceFound would not apply here. 2) Node in RID RIDPolicy is tied to MsgDestination and would be the receivi= ng Node or the suspected source of an incident if a traceback were in play.= =20 3) This means the connection would need to be to the IODEF document and wou= ld require the document to be decrypted to verify if this were necessary. = Or adding a Node instance specific to the sending host information. 4) If it were tied to IODEF, the use of Node in the System class is specifi= c to the source and destination addresses involved in an attack. The EventD= ata where contact category is set to "infrastructure" is the place where sy= stems involved in communicating IODEF documents are listed. This is the pa= th information for incident data (lists all of the 'from' systems in RID co= mmunications). Thanks, Kathleen (as editor) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of dav= id.black@emc.com Sent: Wednesday, January 25, 2012 12:39 PM To: mile@ietf.org Subject: [mile] 6046-bis - Client certificate identity check Brian and Kathleen, I think I found something in looking at the text related to the question ab= out certificate identities, but some more input would be useful. The 6046-bis-08 draft says: RID systems MUST verify the identity of their peers against that stored in the certificate presented, as in section 6 of [RFC6125]. That covers verification of the identity of the receiving system (the ident= ity in the TLS server certificate has to match host component of URI for HTTP),= but I don't think it covers verification of the identity of the sending system,= as Section 6 of RFC 6125 concerns only service identity. I'd suggest adding some text that requires that the identity of the sending system in the TLS client certificate match the NodeName in the Node element of the RIDPolicy class if the NodeName is present. That "is present" compli= cation is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, because RFC 5070 does not require that NodeName be present.=20 I'm not sure what to do if NodeName is absent - a possible approach would b= e to not go there, and instead add a requirement to 6045-bis that NodeName MUST = be present in the Node element of the RIDPolicy class in order to facilitate this identity check. What do other people think? 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 ---------------------------------------------------- _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Jan 25 11:00: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 66C7421F85EE for ; Wed, 25 Jan 2012 11:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.168 X-Spam-Level: X-Spam-Status: No, score=-109.168 tagged_above=-999 required=5 tests=[AWL=1.431, 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 fPobeuBh47Qa for ; Wed, 25 Jan 2012 11:00:37 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6096811E8081 for ; Wed, 25 Jan 2012 11:00:34 -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 q0PJ0Y14026604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2012 14:00:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 25 Jan 2012 14:00:23 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PJ0L58030777 for ; Wed, 25 Jan 2012 14:00:21 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 25 Jan 2012 14:00:21 -0500 From: To: , Date: Wed, 25 Jan 2012 14:00:19 -0500 Thread-Topic: 6046-bis - Client certificate identity check Thread-Index: AczbiEB/wUKqGdW7T4qJBVN+0iRGCQAAxUtQAADOplA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 19:00:38 -0000 Hi Kathleen, I missed the connection between Node and MsgDestination in 6045-bis - my mi= stake. It might be useful to repeat the following text from the specification of "= MsgDestination" in the specification of the Node element in RIDPolicy, as those specificati= ons are 5 pages apart, and the current specification of the Node element is not preci= se about usage: the meaning of the value in the Node element is determined by the MsgDestination element OTOH, I now don't see anything in RID that represents the identity of the s= ystem sending the RID message, and I don't think adding that is important enough to make = a change at this juncture. I also don't see any point in trying to use the enveloped I= ODEF document to carry the identity of the sending RID system, as that document could get= forwarded in a different RID message, for which it would contain the wrong sending RI= D system identity. If there's no instance of the sending RID system's identity in the RID mess= age, then I suppose the client identity verification would have to be based on the info= rmation used to set up the trust relationships in the consortium. The 6046-bis draft al= ready has a reference to the PKI discussion in 6045-bis. Would it make sense to clarify= 6046-bis to indicate that RFC 6125 Section 6 applies only to server identity verific= ation and the PKI material in 6045-bis applies to both server and client identity verific= ation? Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, January 25, 2012 1:21 PM > To: Black, David; mile@ietf.org > Subject: RE: 6046-bis - Client certificate identity check >=20 > Hi David, >=20 > Thank you for the comments. If text is added, it will need to be specifi= c to the instance of Node in > RID or IODEF. This would mean the CN would be used for this purpose (if = UTF-8 names are OKed for use > in RID NodeNames with the internationalization discussions). RID uses No= de in two places and it may > make more sense to reference the one in the IODEF document or change some= thing in RID. >=20 > Instances of where 'Node' appears: > 1) Node in SourceFound would not apply here. >=20 > 2) Node in RID RIDPolicy is tied to MsgDestination and would be the recei= ving Node or the suspected > source of an incident if a traceback were in play. >=20 > 3) This means the connection would need to be to the IODEF document and w= ould require the document to > be decrypted to verify if this were necessary. Or adding a Node instance= specific to the sending host > information. >=20 > 4) If it were tied to IODEF, the use of Node in the System class is speci= fic to the source and > destination addresses involved in an attack. The EventData where contact = category is set to > "infrastructure" is the place where systems involved in communicating IOD= EF documents are listed. > This is the path information for incident data (lists all of the 'from' s= ystems in RID > communications). >=20 > Thanks, > Kathleen (as editor) >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of d= avid.black@emc.com > Sent: Wednesday, January 25, 2012 12:39 PM > To: mile@ietf.org > Subject: [mile] 6046-bis - Client certificate identity check >=20 > Brian and Kathleen, >=20 > I think I found something in looking at the text related to the question = about > certificate identities, but some more input would be useful. >=20 > The 6046-bis-08 draft says: >=20 > RID systems MUST verify the identity of their peers against that > stored in the certificate presented, as in section 6 of [RFC6125]. >=20 > That covers verification of the identity of the receiving system (the ide= ntity > in the TLS server certificate has to match host component of URI for HTTP= ), but > I don't think it covers verification of the identity of the sending syste= m, as > Section 6 of RFC 6125 concerns only service identity. >=20 > I'd suggest adding some text that requires that the identity of the sendi= ng > system in the TLS client certificate match the NodeName in the Node eleme= nt > of the RIDPolicy class if the NodeName is present. That "is present" comp= lication > is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, becau= se > RFC 5070 does not require that NodeName be present. >=20 > I'm not sure what to do if NodeName is absent - a possible approach would= be to > not go there, and instead add a requirement to 6045-bis that NodeName MUS= T be > present in the Node element of the RIDPolicy class in order to facilitate > this identity check. >=20 > What do other people think? >=20 > 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-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Jan 25 11:28: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 19F7F21F85BB for ; Wed, 25 Jan 2012 11:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.584 X-Spam-Level: X-Spam-Status: No, score=-9.584 tagged_above=-999 required=5 tests=[AWL=1.015, 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 U15l6sKpyvJ7 for ; Wed, 25 Jan 2012 11:28: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 3267921F854E for ; Wed, 25 Jan 2012 11:28:27 -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 q0PJSPPk007025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2012 14:28:26 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 25 Jan 2012 14:28:10 -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 q0PJSAVC032118 for ; Wed, 25 Jan 2012 14:28:10 -0500 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub17.corp.emc.com (10.254.93.46) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 25 Jan 2012 14:28:10 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Wed, 25 Jan 2012 14:28:09 -0500 From: To: , Date: Wed, 25 Jan 2012 14:28:08 -0500 Thread-Topic: 6046-bis - Client certificate identity check Thread-Index: AczbiEB/wUKqGdW7T4qJBVN+0iRGCQAAxUtQAADOplAAAfCbcA== Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 19:28:28 -0000 Hi David, Thank you. The Node information contained within IODEF is important to kno= w the systems involved in handling an incident. This is important at the I= ODEF document level as the incident information would stay with the IODEF d= ocument even though a new RID message may be used. I hope that helps to cl= arify the reason for this information at the IODEF document level. I am not sure. RFC6045-bis would say verify the role as opposed to client = for authentication and I am pretty sure that is already in there. The only= thing I think that needs to be decided is if we have to clarify the NOT RE= COMMENDED in the paragraph about mutual authentication since this may be re= ad as specific to mutual authentication, where DNS-ID is required. Maybe i= t is fine... I think the only outstanding issue is with RFC6045 and if Punycode should b= e allowed in the RID XML document. Thanks, Kathleen -----Original Message----- From: Black, David=20 Sent: Wednesday, January 25, 2012 2:00 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: 6046-bis - Client certificate identity check Hi Kathleen, I missed the connection between Node and MsgDestination in 6045-bis - my mi= stake. It might be useful to repeat the following text from the specification of "= MsgDestination" in the specification of the Node element in RIDPolicy, as those specificati= ons are 5 pages apart, and the current specification of the Node element is not preci= se about usage: the meaning of the value in the Node element is determined by the MsgDestination element OTOH, I now don't see anything in RID that represents the identity of the s= ystem sending the RID message, and I don't think adding that is important enough to make = a change at this juncture. I also don't see any point in trying to use the enveloped I= ODEF document to carry the identity of the sending RID system, as that document could get= forwarded in a different RID message, for which it would contain the wrong sending RI= D system identity. If there's no instance of the sending RID system's identity in the RID mess= age, then I suppose the client identity verification would have to be based on the info= rmation used to set up the trust relationships in the consortium. The 6046-bis draft al= ready has a reference to the PKI discussion in 6045-bis. Would it make sense to clarify= 6046-bis to indicate that RFC 6125 Section 6 applies only to server identity verific= ation and the PKI material in 6045-bis applies to both server and client identity verific= ation? Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, January 25, 2012 1:21 PM > To: Black, David; mile@ietf.org > Subject: RE: 6046-bis - Client certificate identity check >=20 > Hi David, >=20 > Thank you for the comments. If text is added, it will need to be specifi= c to the instance of Node in > RID or IODEF. This would mean the CN would be used for this purpose (if = UTF-8 names are OKed for use > in RID NodeNames with the internationalization discussions). RID uses No= de in two places and it may > make more sense to reference the one in the IODEF document or change some= thing in RID. >=20 > Instances of where 'Node' appears: > 1) Node in SourceFound would not apply here. >=20 > 2) Node in RID RIDPolicy is tied to MsgDestination and would be the recei= ving Node or the suspected > source of an incident if a traceback were in play. >=20 > 3) This means the connection would need to be to the IODEF document and w= ould require the document to > be decrypted to verify if this were necessary. Or adding a Node instance= specific to the sending host > information. >=20 > 4) If it were tied to IODEF, the use of Node in the System class is speci= fic to the source and > destination addresses involved in an attack. The EventData where contact = category is set to > "infrastructure" is the place where systems involved in communicating IOD= EF documents are listed. > This is the path information for incident data (lists all of the 'from' s= ystems in RID > communications). >=20 > Thanks, > Kathleen (as editor) >=20 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of d= avid.black@emc.com > Sent: Wednesday, January 25, 2012 12:39 PM > To: mile@ietf.org > Subject: [mile] 6046-bis - Client certificate identity check >=20 > Brian and Kathleen, >=20 > I think I found something in looking at the text related to the question = about > certificate identities, but some more input would be useful. >=20 > The 6046-bis-08 draft says: >=20 > RID systems MUST verify the identity of their peers against that > stored in the certificate presented, as in section 6 of [RFC6125]. >=20 > That covers verification of the identity of the receiving system (the ide= ntity > in the TLS server certificate has to match host component of URI for HTTP= ), but > I don't think it covers verification of the identity of the sending syste= m, as > Section 6 of RFC 6125 concerns only service identity. >=20 > I'd suggest adding some text that requires that the identity of the sendi= ng > system in the TLS client certificate match the NodeName in the Node eleme= nt > of the RIDPolicy class if the NodeName is present. That "is present" comp= lication > is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, becau= se > RFC 5070 does not require that NodeName be present. >=20 > I'm not sure what to do if NodeName is absent - a possible approach would= be to > not go there, and instead add a requirement to 6045-bis that NodeName MUS= T be > present in the Node element of the RIDPolicy class in order to facilitate > this identity check. >=20 > What do other people think? >=20 > 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-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Jan 25 11:47: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 3C3C411E8075 for ; Wed, 25 Jan 2012 11:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.186 X-Spam-Level: X-Spam-Status: No, score=-109.186 tagged_above=-999 required=5 tests=[AWL=1.413, 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 0uowAngJm1Gl for ; Wed, 25 Jan 2012 11:47:12 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 30CB221F8427 for ; Wed, 25 Jan 2012 11:47:11 -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 q0PJlBbe013953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2012 14:47:11 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 25 Jan 2012 14:46:49 -0500 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PJkd5j019574 for ; Wed, 25 Jan 2012 14:46:49 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Wed, 25 Jan 2012 14:46:45 -0500 From: To: , Date: Wed, 25 Jan 2012 14:46:44 -0500 Thread-Topic: 6046-bis - Client certificate identity check Thread-Index: AczbiEB/wUKqGdW7T4qJBVN+0iRGCQAAxUtQAADOplAAAfCbcAAAVRxA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91838@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 19:47:13 -0000 Hi Kathleen, Thank you for the response. > I think the only outstanding issue is with RFC6045 and if Punycode should= be allowed in the RID XML > document. Ok, adding text to the Node description in RIDPolicy to say that MsgDestina= tion determines what Node means is editorial. I missed this connection due to the distance between the desc= riptions of Node and MsgDestination, but if you don't see the need for this as editor of the dra= ft, that's your choice. My outstanding concern for 6046-bis is that the following text in -08 appea= rs to be wrong because section 6 of RFC 6125 doesn't apply to client identity verification: > > RID systems MUST verify the identity of their peers against that > > stored in the certificate presented, as in section 6 of [RFC6125]. For the client certificate, it looks like the only means of identity verifi= cation is path validation of the TLS client certificate against the server's trust store. A sentence= to say that directly could be an alternative to a pointer to 6045-bis's PKI material. Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, January 25, 2012 2:28 PM > To: Black, David; mile@ietf.org > Subject: RE: 6046-bis - Client certificate identity check >=20 > Hi David, >=20 > Thank you. The Node information contained within IODEF is important to k= now the systems involved in > handling an incident. This is important at the IODEF document level as t= he incident information would > stay with the IODEF document even though a new RID message may be used. = I hope that helps to clarify > the reason for this information at the IODEF document level. >=20 > I am not sure. RFC6045-bis would say verify the role as opposed to clien= t for authentication and I am > pretty sure that is already in there. The only thing I think that needs = to be decided is if we have > to clarify the NOT RECOMMENDED in the paragraph about mutual authenticati= on since this may be read as > specific to mutual authentication, where DNS-ID is required. Maybe it is= fine... >=20 > I think the only outstanding issue is with RFC6045 and if Punycode should= be allowed in the RID XML > document. >=20 > Thanks, > Kathleen >=20 > -----Original Message----- > From: Black, David > Sent: Wednesday, January 25, 2012 2:00 PM > To: Moriarty, Kathleen; mile@ietf.org > Subject: RE: 6046-bis - Client certificate identity check >=20 > Hi Kathleen, >=20 > I missed the connection between Node and MsgDestination in 6045-bis - my = mistake. >=20 > It might be useful to repeat the following text from the specification of= "MsgDestination" > in the specification of the Node element in RIDPolicy, as those specifica= tions are 5 > pages apart, and the current specification of the Node element is not pre= cise about > usage: >=20 > the meaning of the value > in the Node element is determined by the MsgDestination element >=20 > OTOH, I now don't see anything in RID that represents the identity of the= system sending > the RID message, and I don't think adding that is important enough to mak= e a change at > this juncture. I also don't see any point in trying to use the enveloped= IODEF document > to carry the identity of the sending RID system, as that document could g= et forwarded > in a different RID message, for which it would contain the wrong sending = RID system > identity. >=20 > If there's no instance of the sending RID system's identity in the RID me= ssage, then I > suppose the client identity verification would have to be based on the in= formation used > to set up the trust relationships in the consortium. The 6046-bis draft = already has a > reference to the PKI discussion in 6045-bis. Would it make sense to clari= fy 6046-bis > to indicate that RFC 6125 Section 6 applies only to server identity verif= ication and the > PKI material in 6045-bis applies to both server and client identity verif= ication? >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Moriarty, Kathleen > > Sent: Wednesday, January 25, 2012 1:21 PM > > To: Black, David; mile@ietf.org > > Subject: RE: 6046-bis - Client certificate identity check > > > > Hi David, > > > > Thank you for the comments. If text is added, it will need to be speci= fic to the instance of Node > in > > RID or IODEF. This would mean the CN would be used for this purpose (i= f UTF-8 names are OKed for > use > > in RID NodeNames with the internationalization discussions). RID uses = Node in two places and it may > > make more sense to reference the one in the IODEF document or change so= mething in RID. > > > > Instances of where 'Node' appears: > > 1) Node in SourceFound would not apply here. > > > > 2) Node in RID RIDPolicy is tied to MsgDestination and would be the rec= eiving Node or the suspected > > source of an incident if a traceback were in play. > > > > 3) This means the connection would need to be to the IODEF document and= would require the document > to > > be decrypted to verify if this were necessary. Or adding a Node instan= ce specific to the sending > host > > information. > > > > 4) If it were tied to IODEF, the use of Node in the System class is spe= cific to the source and > > destination addresses involved in an attack. The EventData where contac= t category is set to > > "infrastructure" is the place where systems involved in communicating I= ODEF documents are listed. > > This is the path information for incident data (lists all of the 'from'= systems in RID > > communications). > > > > Thanks, > > Kathleen (as editor) > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= david.black@emc.com > > Sent: Wednesday, January 25, 2012 12:39 PM > > To: mile@ietf.org > > Subject: [mile] 6046-bis - Client certificate identity check > > > > Brian and Kathleen, > > > > I think I found something in looking at the text related to the questio= n about > > certificate identities, but some more input would be useful. > > > > The 6046-bis-08 draft says: > > > > RID systems MUST verify the identity of their peers against that > > stored in the certificate presented, as in section 6 of [RFC6125]. > > > > That covers verification of the identity of the receiving system (the i= dentity > > in the TLS server certificate has to match host component of URI for HT= TP), but > > I don't think it covers verification of the identity of the sending sys= tem, as > > Section 6 of RFC 6125 concerns only service identity. > > > > I'd suggest adding some text that requires that the identity of the sen= ding > > system in the TLS client certificate match the NodeName in the Node ele= ment > > of the RIDPolicy class if the NodeName is present. That "is present" co= mplication > > is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, bec= ause > > RFC 5070 does not require that NodeName be present. > > > > I'm not sure what to do if NodeName is absent - a possible approach wou= ld be to > > not go there, and instead add a requirement to 6045-bis that NodeName M= UST be > > present in the Node element of the RIDPolicy class in order to facilita= te > > this identity check. > > > > What do other people think? > > > > 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= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Wed Jan 25 11:50: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 13D5D11E8081 for ; Wed, 25 Jan 2012 11:50:58 -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 HgRVwdmSlnhn for ; Wed, 25 Jan 2012 11:50:57 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D563F21F84B6 for ; Wed, 25 Jan 2012 11:50:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 46C43D9309; Wed, 25 Jan 2012 20:50: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 eExJZF79Hrg0; Wed, 25 Jan 2012 20:50:55 +0100 (MET) Received: from [172.20.10.2] (unknown [213.55.184.215]) (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 4FE6BD9300; Wed, 25 Jan 2012 20:50:54 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> Date: Wed, 25 Jan 2012 20:50:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 19:50:58 -0000 Hi, David, Thanks for the comments; I've been out of contact all day so am catching = up. I'll top-post my summary reply at first; I may have further detail = replies in a subsequent message. 1. I would need to think more deeply about the implications of any = authentication also cross-checking the DNS-ID against not only = network-layer available identifiers but also against information stored = within the RID document itself. There seems to be a bit of a chicken and = egg problem there, and it seems to me that there may be valid exceptions = to a policy that would be simple enough to be (a) implementable and (b) = verifiable.=20 2. It is not the intent that 6125 section 4 applies solely to the = authentication of the TLS server; _all_ authentication in RID over HTTPS = must be mutual, and I believe the current proposed text (copied below = straight from xml source) to be clear on this point, in context. If = that's not the case, then we'll need to change it. RID systems MUST use TLS version 1.1 = or higher for confidentiality, identification, and authentication, when = sending RID messages over HTTPS. HTTPS is specified in Section 2 of . RID systems MUST use mutual authentication; = that is, both RID systems acting as HTTPS clients and RID systems acting as = HTTPS servers MUST be identified by an X.509 certificate. Mutual authentication requires full path = validation on each certificate, as defined in . The TLS session MUST use non-NULL ciphersuites for = authentication, integrity, and confidentiality. Sessions MAY be renegotiated within = these constraints. RID systems MUST verify the identity of their peers against that = stored in the certificate presented. All RID systems MUST be identified by = a certificate containing a DNS-ID = identifier as in section 6.4 of . The inclusion of = Common Names (CN-IDs) in certificates identifying RID systems is NOT = RECOMMENDED. Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate identifying a RID system. Additional general information on the use = of PKI with RID systems is detailed in Section 9.3 of . RID systems MUST support TLS version 1.1 and SHOULD support TLS = version 1.2 ; RID systems MUST NOT request, offer, = or use any version of SSL, or any version of TLS prior to 1.1, due to known security vulnerabilities in prior versions of the protocol; see = Appendix E of for more. Best regards, Brian On Jan 25, 2012, at 8:00 PM, wrote: > Hi Kathleen, >=20 > I missed the connection between Node and MsgDestination in 6045-bis - = my mistake. >=20 > It might be useful to repeat the following text from the specification = of "MsgDestination" > in the specification of the Node element in RIDPolicy, as those = specifications are 5 > pages apart, and the current specification of the Node element is not = precise about > usage: >=20 > the meaning of the value > in the Node element is determined by the MsgDestination = element >=20 > OTOH, I now don't see anything in RID that represents the identity of = the system sending > the RID message, and I don't think adding that is important enough to = make a change at > this juncture. I also don't see any point in trying to use the = enveloped IODEF document > to carry the identity of the sending RID system, as that document = could get forwarded > in a different RID message, for which it would contain the wrong = sending RID system > identity. >=20 > If there's no instance of the sending RID system's identity in the RID = message, then I > suppose the client identity verification would have to be based on the = information used > to set up the trust relationships in the consortium. The 6046-bis = draft already has a > reference to the PKI discussion in 6045-bis. Would it make sense to = clarify 6046-bis > to indicate that RFC 6125 Section 6 applies only to server identity = verification and the > PKI material in 6045-bis applies to both server and client identity = verification? >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Wednesday, January 25, 2012 1:21 PM >> To: Black, David; mile@ietf.org >> Subject: RE: 6046-bis - Client certificate identity check >>=20 >> Hi David, >>=20 >> Thank you for the comments. If text is added, it will need to be = specific to the instance of Node in >> RID or IODEF. This would mean the CN would be used for this purpose = (if UTF-8 names are OKed for use >> in RID NodeNames with the internationalization discussions). RID = uses Node in two places and it may >> make more sense to reference the one in the IODEF document or change = something in RID. >>=20 >> Instances of where 'Node' appears: >> 1) Node in SourceFound would not apply here. >>=20 >> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the = receiving Node or the suspected >> source of an incident if a traceback were in play. >>=20 >> 3) This means the connection would need to be to the IODEF document = and would require the document to >> be decrypted to verify if this were necessary. Or adding a Node = instance specific to the sending host >> information. >>=20 >> 4) If it were tied to IODEF, the use of Node in the System class is = specific to the source and >> destination addresses involved in an attack. The EventData where = contact category is set to >> "infrastructure" is the place where systems involved in communicating = IODEF documents are listed. >> This is the path information for incident data (lists all of the = 'from' systems in RID >> communications). >>=20 >> Thanks, >> Kathleen (as editor) >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of david.black@emc.com >> Sent: Wednesday, January 25, 2012 12:39 PM >> To: mile@ietf.org >> Subject: [mile] 6046-bis - Client certificate identity check >>=20 >> Brian and Kathleen, >>=20 >> I think I found something in looking at the text related to the = question about >> certificate identities, but some more input would be useful. >>=20 >> The 6046-bis-08 draft says: >>=20 >> RID systems MUST verify the identity of their peers against that >> stored in the certificate presented, as in section 6 of [RFC6125]. >>=20 >> That covers verification of the identity of the receiving system (the = identity >> in the TLS server certificate has to match host component of URI for = HTTP), but >> I don't think it covers verification of the identity of the sending = system, as >> Section 6 of RFC 6125 concerns only service identity. >>=20 >> I'd suggest adding some text that requires that the identity of the = sending >> system in the TLS client certificate match the NodeName in the Node = element >> of the RIDPolicy class if the NodeName is present. That "is present" = complication >> is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, = because >> RFC 5070 does not require that NodeName be present. >>=20 >> I'm not sure what to do if NodeName is absent - a possible approach = would be to >> not go there, and instead add a requirement to 6045-bis that NodeName = MUST be >> present in the Node element of the RIDPolicy class in order to = facilitate >> this identity check. >>=20 >> What do other people think? >>=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 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Jan 25 11:51: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 07BA311E8083 for ; Wed, 25 Jan 2012 11:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.603 X-Spam-Level: X-Spam-Status: No, score=-9.603 tagged_above=-999 required=5 tests=[AWL=0.996, 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 cr3xlqNQ9U+a for ; Wed, 25 Jan 2012 11:51:12 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E664A21F84B6 for ; Wed, 25 Jan 2012 11:51:11 -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 q0PJpBpG030927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2012 14:51:11 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 25 Jan 2012 14:50:47 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PJokZF018626 for ; Wed, 25 Jan 2012 14:50:47 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Wed, 25 Jan 2012 14:50:46 -0500 From: To: , Date: Wed, 25 Jan 2012 14:50:45 -0500 Thread-Topic: 6046-bis - Client certificate identity check Thread-Index: AczbiEB/wUKqGdW7T4qJBVN+0iRGCQAAxUtQAADOplAAAfCbcAAAVRxAAAC4iuA= Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91838@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91838@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 19:51:13 -0000 I am happy to add some text to the Node description, sorry I didn't address= that in my last email. I'll leave the other comment to Brian. Thank you, Kathleen (as editor) -----Original Message----- From: Black, David=20 Sent: Wednesday, January 25, 2012 2:47 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: 6046-bis - Client certificate identity check Hi Kathleen, Thank you for the response. > I think the only outstanding issue is with RFC6045 and if Punycode should= be allowed in the RID XML > document. Ok, adding text to the Node description in RIDPolicy to say that MsgDestina= tion determines what Node means is editorial. I missed this connection due to the distance between the desc= riptions of Node and MsgDestination, but if you don't see the need for this as editor of the dra= ft, that's your choice. My outstanding concern for 6046-bis is that the following text in -08 appea= rs to be wrong because section 6 of RFC 6125 doesn't apply to client identity verification: > > RID systems MUST verify the identity of their peers against that > > stored in the certificate presented, as in section 6 of [RFC6125]. For the client certificate, it looks like the only means of identity verifi= cation is path validation of the TLS client certificate against the server's trust store. A sentence= to say that directly could be an alternative to a pointer to 6045-bis's PKI material. Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, January 25, 2012 2:28 PM > To: Black, David; mile@ietf.org > Subject: RE: 6046-bis - Client certificate identity check >=20 > Hi David, >=20 > Thank you. The Node information contained within IODEF is important to k= now the systems involved in > handling an incident. This is important at the IODEF document level as t= he incident information would > stay with the IODEF document even though a new RID message may be used. = I hope that helps to clarify > the reason for this information at the IODEF document level. >=20 > I am not sure. RFC6045-bis would say verify the role as opposed to clien= t for authentication and I am > pretty sure that is already in there. The only thing I think that needs = to be decided is if we have > to clarify the NOT RECOMMENDED in the paragraph about mutual authenticati= on since this may be read as > specific to mutual authentication, where DNS-ID is required. Maybe it is= fine... >=20 > I think the only outstanding issue is with RFC6045 and if Punycode should= be allowed in the RID XML > document. >=20 > Thanks, > Kathleen >=20 > -----Original Message----- > From: Black, David > Sent: Wednesday, January 25, 2012 2:00 PM > To: Moriarty, Kathleen; mile@ietf.org > Subject: RE: 6046-bis - Client certificate identity check >=20 > Hi Kathleen, >=20 > I missed the connection between Node and MsgDestination in 6045-bis - my = mistake. >=20 > It might be useful to repeat the following text from the specification of= "MsgDestination" > in the specification of the Node element in RIDPolicy, as those specifica= tions are 5 > pages apart, and the current specification of the Node element is not pre= cise about > usage: >=20 > the meaning of the value > in the Node element is determined by the MsgDestination element >=20 > OTOH, I now don't see anything in RID that represents the identity of the= system sending > the RID message, and I don't think adding that is important enough to mak= e a change at > this juncture. I also don't see any point in trying to use the enveloped= IODEF document > to carry the identity of the sending RID system, as that document could g= et forwarded > in a different RID message, for which it would contain the wrong sending = RID system > identity. >=20 > If there's no instance of the sending RID system's identity in the RID me= ssage, then I > suppose the client identity verification would have to be based on the in= formation used > to set up the trust relationships in the consortium. The 6046-bis draft = already has a > reference to the PKI discussion in 6045-bis. Would it make sense to clari= fy 6046-bis > to indicate that RFC 6125 Section 6 applies only to server identity verif= ication and the > PKI material in 6045-bis applies to both server and client identity verif= ication? >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Moriarty, Kathleen > > Sent: Wednesday, January 25, 2012 1:21 PM > > To: Black, David; mile@ietf.org > > Subject: RE: 6046-bis - Client certificate identity check > > > > Hi David, > > > > Thank you for the comments. If text is added, it will need to be speci= fic to the instance of Node > in > > RID or IODEF. This would mean the CN would be used for this purpose (i= f UTF-8 names are OKed for > use > > in RID NodeNames with the internationalization discussions). RID uses = Node in two places and it may > > make more sense to reference the one in the IODEF document or change so= mething in RID. > > > > Instances of where 'Node' appears: > > 1) Node in SourceFound would not apply here. > > > > 2) Node in RID RIDPolicy is tied to MsgDestination and would be the rec= eiving Node or the suspected > > source of an incident if a traceback were in play. > > > > 3) This means the connection would need to be to the IODEF document and= would require the document > to > > be decrypted to verify if this were necessary. Or adding a Node instan= ce specific to the sending > host > > information. > > > > 4) If it were tied to IODEF, the use of Node in the System class is spe= cific to the source and > > destination addresses involved in an attack. The EventData where contac= t category is set to > > "infrastructure" is the place where systems involved in communicating I= ODEF documents are listed. > > This is the path information for incident data (lists all of the 'from'= systems in RID > > communications). > > > > Thanks, > > Kathleen (as editor) > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= david.black@emc.com > > Sent: Wednesday, January 25, 2012 12:39 PM > > To: mile@ietf.org > > Subject: [mile] 6046-bis - Client certificate identity check > > > > Brian and Kathleen, > > > > I think I found something in looking at the text related to the questio= n about > > certificate identities, but some more input would be useful. > > > > The 6046-bis-08 draft says: > > > > RID systems MUST verify the identity of their peers against that > > stored in the certificate presented, as in section 6 of [RFC6125]. > > > > That covers verification of the identity of the receiving system (the i= dentity > > in the TLS server certificate has to match host component of URI for HT= TP), but > > I don't think it covers verification of the identity of the sending sys= tem, as > > Section 6 of RFC 6125 concerns only service identity. > > > > I'd suggest adding some text that requires that the identity of the sen= ding > > system in the TLS client certificate match the NodeName in the Node ele= ment > > of the RIDPolicy class if the NodeName is present. That "is present" co= mplication > > is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, bec= ause > > RFC 5070 does not require that NodeName be present. > > > > I'm not sure what to do if NodeName is absent - a possible approach wou= ld be to > > not go there, and instead add a requirement to 6045-bis that NodeName M= UST be > > present in the Node element of the RIDPolicy class in order to facilita= te > > this identity check. > > > > What do other people think? > > > > 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= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Jan 25 11:55: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 3080321F8598 for ; Wed, 25 Jan 2012 11:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.622 X-Spam-Level: X-Spam-Status: No, score=-9.622 tagged_above=-999 required=5 tests=[AWL=0.977, 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 ut3OvvgPsXvL for ; Wed, 25 Jan 2012 11:55:57 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8037B21F855E for ; Wed, 25 Jan 2012 11:55:30 -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 q0PJtQS4014584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 14:55:28 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 25 Jan 2012 14:55:14 -0500 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PJtDOE025690; Wed, 25 Jan 2012 14:55:13 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Wed, 25 Jan 2012 14:55:12 -0500 From: To: , Date: Wed, 25 Jan 2012 14:55:11 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczbmqtpQzD6tu/0SBeZZ3gHTFRKOQAAGDIQ Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> In-Reply-To: <35D05F86-6239-49C3-88AD-3237A144A6D3@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: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 19:55:58 -0000 Hi Brian, You can save your time on #1, the question/request was withdrawn. The send= ing RID server may only appear within the IODEF document and not the RID XM= L document. Thank you, Kathleen -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Wednesday, January 25, 2012 2:51 PM To: Black, David Cc: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check Hi, David, Thanks for the comments; I've been out of contact all day so am catching up= . I'll top-post my summary reply at first; I may have further detail replie= s in a subsequent message. 1. I would need to think more deeply about the implications of any authenti= cation also cross-checking the DNS-ID against not only network-layer availa= ble identifiers but also against information stored within the RID document= itself. There seems to be a bit of a chicken and egg problem there, and it= seems to me that there may be valid exceptions to a policy that would be s= imple enough to be (a) implementable and (b) verifiable.=20 2. It is not the intent that 6125 section 4 applies solely to the authentic= ation of the TLS server; _all_ authentication in RID over HTTPS must be mut= ual, and I believe the current proposed text (copied below straight from xm= l source) to be clear on this point, in context. If that's not the case, th= en we'll need to change it. RID systems MUST use TLS version 1.1 or h= igher for confidentiality, identification, and authentication, when sending R= ID messages over HTTPS. HTTPS is specified in Section 2 of . RID systems MUST use mutual authentication; that = is, both RID systems acting as HTTPS clients and RID systems acting as HTTP= S servers MUST be identified by an X.509 certificate. Mutual authentication requires full path validation= on each certificate, as defined in . The TLS session MUST use non-NULL ciphersuites for authentication, integrity, and confidentiality. Sessions MAY be renegotiated within the= se constraints. RID systems MUST verify the identity of their peers against that sto= red in the certificate presented. All RID systems MUST be identified by a certificate containing a DNS-ID identifier as in section 6.4 of . The inclusion of Commo= n Names (CN-IDs) in certificates identifying RID systems is NOT RECOMMEND= ED. Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate identifying a RID system. Additional general information on the use of = PKI with RID systems is detailed in Section 9.3 of . RID systems MUST support TLS version 1.1 and SHOULD support TLS vers= ion 1.2 ; RID systems MUST NOT request, offer, or= use any version of SSL, or any version of TLS prior to 1.1, due to known security vulnerabilities in prior versions of the protocol; see Appendi= x E of for more. Best regards, Brian On Jan 25, 2012, at 8:00 PM, wrote: > Hi Kathleen, >=20 > I missed the connection between Node and MsgDestination in 6045-bis - my = mistake. >=20 > It might be useful to repeat the following text from the specification of= "MsgDestination" > in the specification of the Node element in RIDPolicy, as those specifica= tions are 5 > pages apart, and the current specification of the Node element is not pre= cise about > usage: >=20 > the meaning of the value > in the Node element is determined by the MsgDestination element >=20 > OTOH, I now don't see anything in RID that represents the identity of the= system sending > the RID message, and I don't think adding that is important enough to mak= e a change at > this juncture. I also don't see any point in trying to use the enveloped= IODEF document > to carry the identity of the sending RID system, as that document could g= et forwarded > in a different RID message, for which it would contain the wrong sending = RID system > identity. >=20 > If there's no instance of the sending RID system's identity in the RID me= ssage, then I > suppose the client identity verification would have to be based on the in= formation used > to set up the trust relationships in the consortium. The 6046-bis draft = already has a > reference to the PKI discussion in 6045-bis. Would it make sense to clari= fy 6046-bis > to indicate that RFC 6125 Section 6 applies only to server identity verif= ication and the > PKI material in 6045-bis applies to both server and client identity verif= ication? >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Wednesday, January 25, 2012 1:21 PM >> To: Black, David; mile@ietf.org >> Subject: RE: 6046-bis - Client certificate identity check >>=20 >> Hi David, >>=20 >> Thank you for the comments. If text is added, it will need to be specif= ic to the instance of Node in >> RID or IODEF. This would mean the CN would be used for this purpose (if= UTF-8 names are OKed for use >> in RID NodeNames with the internationalization discussions). RID uses N= ode in two places and it may >> make more sense to reference the one in the IODEF document or change som= ething in RID. >>=20 >> Instances of where 'Node' appears: >> 1) Node in SourceFound would not apply here. >>=20 >> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the rece= iving Node or the suspected >> source of an incident if a traceback were in play. >>=20 >> 3) This means the connection would need to be to the IODEF document and = would require the document to >> be decrypted to verify if this were necessary. Or adding a Node instanc= e specific to the sending host >> information. >>=20 >> 4) If it were tied to IODEF, the use of Node in the System class is spec= ific to the source and >> destination addresses involved in an attack. The EventData where contact= category is set to >> "infrastructure" is the place where systems involved in communicating IO= DEF documents are listed. >> This is the path information for incident data (lists all of the 'from' = systems in RID >> communications). >>=20 >> Thanks, >> Kathleen (as editor) >>=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = david.black@emc.com >> Sent: Wednesday, January 25, 2012 12:39 PM >> To: mile@ietf.org >> Subject: [mile] 6046-bis - Client certificate identity check >>=20 >> Brian and Kathleen, >>=20 >> I think I found something in looking at the text related to the question= about >> certificate identities, but some more input would be useful. >>=20 >> The 6046-bis-08 draft says: >>=20 >> RID systems MUST verify the identity of their peers against that >> stored in the certificate presented, as in section 6 of [RFC6125]. >>=20 >> That covers verification of the identity of the receiving system (the id= entity >> in the TLS server certificate has to match host component of URI for HTT= P), but >> I don't think it covers verification of the identity of the sending syst= em, as >> Section 6 of RFC 6125 concerns only service identity. >>=20 >> I'd suggest adding some text that requires that the identity of the send= ing >> system in the TLS client certificate match the NodeName in the Node elem= ent >> of the RIDPolicy class if the NodeName is present. That "is present" com= plication >> is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, beca= use >> RFC 5070 does not require that NodeName be present. >>=20 >> I'm not sure what to do if NodeName is absent - a possible approach woul= d be to >> not go there, and instead add a requirement to 6045-bis that NodeName MU= ST be >> present in the Node element of the RIDPolicy class in order to facilitat= e >> this identity check. >>=20 >> What do other people think? >>=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 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Jan 25 12:25: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 0587E11E808F for ; Wed, 25 Jan 2012 12:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.203 X-Spam-Level: X-Spam-Status: No, score=-109.203 tagged_above=-999 required=5 tests=[AWL=1.396, 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 PVes6Tbb1UM4 for ; Wed, 25 Jan 2012 12:25:18 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A980311E8087 for ; Wed, 25 Jan 2012 12:25:18 -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 q0PKPGJl001759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 15:25:18 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 25 Jan 2012 15:25:03 -0500 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PKP2AH022652; Wed, 25 Jan 2012 15:25:02 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Wed, 25 Jan 2012 15:25:01 -0500 From: To: Date: Wed, 25 Jan 2012 15:24:56 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczbmqtpQzD6tu/0SBeZZ3gHTFRKOQAAGDIQAAC3NCA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {20612DA5-8C4B-4773-A165-A8B0EEE8952C} x-cr-hashedpuzzle: An84 CgzU D+ov E+8K FmOH JYzy Jg8H KhCy O0oP PVsU QDdw QbC/ SMEh Sa8d UC/P UsvP; 2; bQBpAGwAZQBAAGkAZQB0AGYALgBvAHIAZwA7AHQAcgBhAG0AbQBlAGwAbABAAHQAaQBrAC4AZQBlAC4AZQB0AGgAegAuAGMAaAA=; Sosha1_v1; 7; {20612DA5-8C4B-4773-A165-A8B0EEE8952C}; ZABhAHYAaQBkAC4AYgBsAGEAYwBrAEAAZQBtAGMALgBjAG8AbQA=; Wed, 25 Jan 2012 20:24:56 GMT; UgBFADoAIABbAG0AaQBsAGUAXQAgADYAMAA0ADYALQBiAGkAcwAgAC0AIABDAGwAaQBlAG4AdAAgAGMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGkAZABlAG4AdABpAHQAeQAgAGMAaABlAGMAawA= 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] 6046-bis - Client certificate identity check 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, 25 Jan 2012 20:25:20 -0000 Hi Brian, Kathleen quickly disposed of #1, so please ignore that. She'll add some te= xt to 6045-bis to help other readers avoid the mistake that I made. For #2, the short summary of my concern with the current text involves this= sentence: > RID systems MUST verify the identity of their peers against that s= tored > in the certificate presented. How does a RID system (as TLS client or server) do that? The next sentence explains what the identity is, but not how to verify it: > All RID systems MUST be identified by a > certificate containing a DNS-ID identifier > as in section 6.4 of . In particular, section 6.4 of RFC 6125 doesn't specify what the certificate= identity is checked against. It may even be that section 6.4 of RFC 6125 doesn't ap= ply to client certificates, because the client identity check my be subsumed by PK= IX path validation of the client certificate against the server's trust store, whic= h does name comparison according to RFC 5280, not RFC 6125. A sentence or two on how to do that required (MUST) identity verification w= ould help. Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, January 25, 2012 2:55 PM > To: Brian Trammell; Black, David > Cc: mile@ietf.org > Subject: RE: [mile] 6046-bis - Client certificate identity check >=20 > Hi Brian, >=20 > You can save your time on #1, the question/request was withdrawn. The se= nding RID server may only > appear within the IODEF document and not the RID XML document. >=20 > Thank you, > Kathleen >=20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, January 25, 2012 2:51 PM > To: Black, David > Cc: Moriarty, Kathleen; mile@ietf.org > Subject: Re: [mile] 6046-bis - Client certificate identity check >=20 > Hi, David, >=20 > Thanks for the comments; I've been out of contact all day so am catching = up. I'll top-post my summary > reply at first; I may have further detail replies in a subsequent message= . >=20 > 1. I would need to think more deeply about the implications of any authen= tication also cross-checking > the DNS-ID against not only network-layer available identifiers but also = against information stored > within the RID document itself. There seems to be a bit of a chicken and = egg problem there, and it > seems to me that there may be valid exceptions to a policy that would be = simple enough to be (a) > implementable and (b) verifiable. >=20 > 2. It is not the intent that 6125 section 4 applies solely to the authent= ication of the TLS server; > _all_ authentication in RID over HTTPS must be mutual, and I believe the = current proposed text (copied > below straight from xml source) to be clear on this point, in context. If= that's not the case, then > we'll need to change it. >=20 > RID systems MUST use TLS version 1.1 or= higher > for confidentiality, identification, and authentication, when sending= RID > messages over HTTPS. HTTPS is specified in Section 2 of target=3D"RFC2818"/>. RID systems MUST use mutual authentication; tha= t is, > both RID systems acting as HTTPS clients and RID systems acting as HT= TPS > servers MUST be identified by an X.509 > certificate. Mutual authentication requires full path validati= on on > each certificate, as defined in . >=20 > The TLS session MUST use non-NULL ciphersuites for authentication, > integrity, and confidentiality. Sessions MAY be renegotiated within t= hese > constraints. >=20 > RID systems MUST verify the identity of their peers against that s= tored > in the certificate presented. All RID systems MUST be identified by a > certificate containing a DNS-ID identifier > as in section 6.4 of . The inclusion of Com= mon > Names (CN-IDs) in certificates identifying RID systems is NOT RECOMME= NDED. > Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate > identifying a RID system. Additional general information on the use o= f PKI > with RID systems is detailed in Section 9.3 of target=3D"I-D.ietf-mile-rfc6045-bis"/>. >=20 > RID systems MUST support TLS version 1.1 and SHOULD support TLS ve= rsion > 1.2 ; RID systems MUST NOT request, offer, = or use > any version of SSL, or any version of TLS prior to 1.1, due to known > security vulnerabilities in prior versions of the protocol; see Appen= dix E > of for more. >=20 > Best regards, >=20 > Brian >=20 > On Jan 25, 2012, at 8:00 PM, wrote: >=20 > > Hi Kathleen, > > > > I missed the connection between Node and MsgDestination in 6045-bis - m= y mistake. > > > > It might be useful to repeat the following text from the specification = of "MsgDestination" > > in the specification of the Node element in RIDPolicy, as those specifi= cations are 5 > > pages apart, and the current specification of the Node element is not p= recise about > > usage: > > > > the meaning of the value > > in the Node element is determined by the MsgDestination element > > > > OTOH, I now don't see anything in RID that represents the identity of t= he system sending > > the RID message, and I don't think adding that is important enough to m= ake a change at > > this juncture. I also don't see any point in trying to use the envelop= ed IODEF document > > to carry the identity of the sending RID system, as that document could= get forwarded > > in a different RID message, for which it would contain the wrong sendin= g RID system > > identity. > > > > If there's no instance of the sending RID system's identity in the RID = message, then I > > suppose the client identity verification would have to be based on the = information used > > to set up the trust relationships in the consortium. The 6046-bis draf= t already has a > > reference to the PKI discussion in 6045-bis. Would it make sense to cla= rify 6046-bis > > to indicate that RFC 6125 Section 6 applies only to server identity ver= ification and the > > PKI material in 6045-bis applies to both server and client identity ver= ification? > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Moriarty, Kathleen > >> Sent: Wednesday, January 25, 2012 1:21 PM > >> To: Black, David; mile@ietf.org > >> Subject: RE: 6046-bis - Client certificate identity check > >> > >> Hi David, > >> > >> Thank you for the comments. If text is added, it will need to be spec= ific to the instance of Node > in > >> RID or IODEF. This would mean the CN would be used for this purpose (= if UTF-8 names are OKed for > use > >> in RID NodeNames with the internationalization discussions). RID uses= Node in two places and it > may > >> make more sense to reference the one in the IODEF document or change s= omething in RID. > >> > >> Instances of where 'Node' appears: > >> 1) Node in SourceFound would not apply here. > >> > >> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the re= ceiving Node or the suspected > >> source of an incident if a traceback were in play. > >> > >> 3) This means the connection would need to be to the IODEF document an= d would require the document > to > >> be decrypted to verify if this were necessary. Or adding a Node insta= nce specific to the sending > host > >> information. > >> > >> 4) If it were tied to IODEF, the use of Node in the System class is sp= ecific to the source and > >> destination addresses involved in an attack. The EventData where conta= ct category is set to > >> "infrastructure" is the place where systems involved in communicating = IODEF documents are listed. > >> This is the path information for incident data (lists all of the 'from= ' systems in RID > >> communications). > >> > >> Thanks, > >> Kathleen (as editor) > >> > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf O= f david.black@emc.com > >> Sent: Wednesday, January 25, 2012 12:39 PM > >> To: mile@ietf.org > >> Subject: [mile] 6046-bis - Client certificate identity check > >> > >> Brian and Kathleen, > >> > >> I think I found something in looking at the text related to the questi= on about > >> certificate identities, but some more input would be useful. > >> > >> The 6046-bis-08 draft says: > >> > >> RID systems MUST verify the identity of their peers against that > >> stored in the certificate presented, as in section 6 of [RFC6125]. > >> > >> That covers verification of the identity of the receiving system (the = identity > >> in the TLS server certificate has to match host component of URI for H= TTP), but > >> I don't think it covers verification of the identity of the sending sy= stem, as > >> Section 6 of RFC 6125 concerns only service identity. > >> > >> I'd suggest adding some text that requires that the identity of the se= nding > >> system in the TLS client certificate match the NodeName in the Node el= ement > >> of the RIDPolicy class if the NodeName is present. That "is present" c= omplication > >> is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, be= cause > >> RFC 5070 does not require that NodeName be present. > >> > >> I'm not sure what to do if NodeName is absent - a possible approach wo= uld be to > >> not go there, and instead add a requirement to 6045-bis that NodeName = MUST be > >> present in the Node element of the RIDPolicy class in order to facilit= ate > >> this identity check. > >> > >> What do other people think? > >> > >> 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 > >> ---------------------------------------------------- > >> > >> _______________________________________________ > >> mile mailing 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 From Kent_Landfield@mcafee.com Wed Jan 25 12:31: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 8510F11E80A6 for ; Wed, 25 Jan 2012 12:31: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=[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 n2s24jm6EWhp for ; Wed, 25 Jan 2012 12:31:36 -0800 (PST) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74D11E8087 for ; Wed, 25 Jan 2012 12:31:33 -0800 (PST) Received: from (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 1632_850f_8f4dca22_4793_11e1_b2e0_00219b929abd; Wed, 25 Jan 2012 14:31:28 -0600 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 25 Jan 2012 14:29:05 -0600 From: To: , , Date: Wed, 25 Jan 2012 14:29:39 -0600 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: Aczbn/uOQ4iF9mlxSL2BajEEiYC/ww== 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_CB45C0552A44Dkentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 20:31:37 -0000 --_000_CB45C0552A44Dkentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, I must have been asleep here but we are not looking to put punycode into t= he XML are we? That would be really ugly=85 Why shouldn't the punycode translation be handled by the DNS client and kee= p the XML document to UTF-8 encoding, including the NodeName? Thanks. 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: Kathleen Moriarty > Date: Wed, 25 Jan 2012 13:50:45 -0600 To: "david.black@emc.com" >, "mile@ietf.org" > Subject: Re: [mile] 6046-bis - Client certificate identity check I am happy to add some text to the Node description, sorry I didn't address= that in my last email. I'll leave the other comment to Brian. Thank you, Kathleen (as editor) -----Original Message----- From: Black, David Sent: Wednesday, January 25, 2012 2:47 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: 6046-bis - Client certificate identity check Hi Kathleen, Thank you for the response. I think the only outstanding issue is with RFC6045 and if Punycode should b= e allowed in the RID XML document. Ok, adding text to the Node description in RIDPolicy to say that MsgDestina= tion determines what Node means is editorial. I missed this connection due to the distance between the desc= riptions of Node and MsgDestination, but if you don't see the need for this as editor of the dra= ft, that's your choice. My outstanding concern for 6046-bis is that the following text in -08 appea= rs to be wrong because section 6 of RFC 6125 doesn't apply to client identity verification: > RID systems MUST verify the identity of their peers against that > stored in the certificate presented, as in section 6 of [RFC6125]. For the client certificate, it looks like the only means of identity verifi= cation is path validation of the TLS client certificate against the server's trust store. A sentence= to say that directly could be an alternative to a pointer to 6045-bis's PKI material. Thanks, --David -----Original Message----- From: Moriarty, Kathleen Sent: Wednesday, January 25, 2012 2:28 PM To: Black, David; mile@ietf.org Subject: RE: 6046-bis - Client certificate identity check Hi David, Thank you. The Node information contained within IODEF is important to kno= w the systems involved in handling an incident. This is important at the IODEF document level as the= incident information would stay with the IODEF document even though a new RID message may be used. I = hope that helps to clarify the reason for this information at the IODEF document level. I am not sure. RFC6045-bis would say verify the role as opposed to client = for authentication and I am pretty sure that is already in there. The only thing I think that needs to= be decided is if we have to clarify the NOT RECOMMENDED in the paragraph about mutual authentication= since this may be read as specific to mutual authentication, where DNS-ID is required. Maybe it is f= ine... I think the only outstanding issue is with RFC6045 and if Punycode should b= e allowed in the RID XML document. Thanks, Kathleen -----Original Message----- From: Black, David Sent: Wednesday, January 25, 2012 2:00 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: 6046-bis - Client certificate identity check Hi Kathleen, I missed the connection between Node and MsgDestination in 6045-bis - my mi= stake. It might be useful to repeat the following text from the specification of "= MsgDestination" in the specification of the Node element in RIDPolicy, as those specificati= ons are 5 pages apart, and the current specification of the Node element is not preci= se about usage: the meaning of the value in the Node element is determined by the MsgDestination element OTOH, I now don't see anything in RID that represents the identity of the s= ystem sending the RID message, and I don't think adding that is important enough to make = a change at this juncture. I also don't see any point in trying to use the enveloped I= ODEF document to carry the identity of the sending RID system, as that document could get= forwarded in a different RID message, for which it would contain the wrong sending RI= D system identity. If there's no instance of the sending RID system's identity in the RID mess= age, then I suppose the client identity verification would have to be based on the info= rmation used to set up the trust relationships in the consortium. The 6046-bis draft al= ready has a reference to the PKI discussion in 6045-bis. Would it make sense to clarify= 6046-bis to indicate that RFC 6125 Section 6 applies only to server identity verific= ation and the PKI material in 6045-bis applies to both server and client identity verific= ation? Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, January 25, 2012 1:21 PM > To: Black, David; mile@ietf.org > Subject: RE: 6046-bis - Client certificate identity check > > Hi David, > > Thank you for the comments. If text is added, it will need to be specifi= c to the instance of Node in > RID or IODEF. This would mean the CN would be used for this purpose (if = UTF-8 names are OKed for use > in RID NodeNames with the internationalization discussions). RID uses No= de in two places and it may > make more sense to reference the one in the IODEF document or change some= thing in RID. > > Instances of where 'Node' appears: > 1) Node in SourceFound would not apply here. > > 2) Node in RID RIDPolicy is tied to MsgDestination and would be the recei= ving Node or the suspected > source of an incident if a traceback were in play. > > 3) This means the connection would need to be to the IODEF document and w= ould require the document to > be decrypted to verify if this were necessary. Or adding a Node instance= specific to the sending host > information. > > 4) If it were tied to IODEF, the use of Node in the System class is speci= fic to the source and > destination addresses involved in an attack. The EventData where contact = category is set to > "infrastructure" is the place where systems involved in communicating IOD= EF documents are listed. > This is the path information for incident data (lists all of the 'from' s= ystems in RID > communications). > > Thanks, > Kathleen (as editor) > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bo= unces@ietf.org] On Behalf Of david.black@emc.com > Sent: Wednesday, January 25, 2012 12:39 PM > To: mile@ietf.org > Subject: [mile] 6046-bis - Client certificate identity check > > Brian and Kathleen, > > I think I found something in looking at the text related to the question = about > certificate identities, but some more input would be useful. > > The 6046-bis-08 draft says: > > RID systems MUST verify the identity of their peers against that > stored in the certificate presented, as in section 6 of [RFC6125]. > > That covers verification of the identity of the receiving system (the ide= ntity > in the TLS server certificate has to match host component of URI for HTTP= ), but > I don't think it covers verification of the identity of the sending syste= m, as > Section 6 of RFC 6125 concerns only service identity. > > I'd suggest adding some text that requires that the identity of the sendi= ng > system in the TLS client certificate match the NodeName in the Node eleme= nt > of the RIDPolicy class if the NodeName is present. That "is present" comp= lication > is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, becau= se > RFC 5070 does not require that NodeName be present. > > I'm not sure what to do if NodeName is absent - a possible approach would= be to > not go there, and instead add a requirement to 6045-bis that NodeName MUS= T be > present in the Node element of the RIDPolicy class in order to facilitate > this identity check. > > What do other people think? > > 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) 3= 94-7754 > ---------------------------------------------------- > > _______________________________________________ > mile mailing 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_CB45C0552A44Dkentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Folks, 

I must have been asleep here but we are not looki= ng to put punycode into  the XML are we?  That would be really ug= ly=85

Why shouldn't t= he punycode translation be handled by the DNS client and keep the XML docum= ent to UTF-8 encoding, including the NodeName? 

Thanks.

Kent Landfield
Director Content Stra= tegy, Architecture and Standards

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

Direct: +1.972.963.7096 
Mobile: +1.817.63= 7.8026
= We= b: www.mcafee.com

From: Kathleen Moriarty &= lt;kathleen.moriarty@emc.com>
Date: Wed, 25 Jan 2012 1= 3:50:45 -0600
To: "david.black@emc.com" <david.black@emc.com>, "mile@ietf.org" <mile@ietf.org>
Subje= ct: Re: [mile] 6046-bis - Client certificate identity check

<= div>
I am happy to add some text to the Node description, sorry I didn'= t address that in my last email.

I'll leave the ot= her comment to Brian.

Thank you,
Kathlee= n (as editor)

-----Original Message-----
From: Black, David
Sent: Wednesday, January 25, 2012 2:47 PM
To: Moriarty, Kathleen; mile@ietf.= org
Subject: RE: 6046-bis - Client certificate identity check=

Hi Kathleen,

Thank you f= or the response.

I think the only outstanding issue is with RFC6045 and = if Punycode should be allowed in the RID XML
document.

Ok, adding text to the Node description in RID= Policy to say that MsgDestination determines what Node means
is e= ditorial. I missed this connection due to the distance between the descript= ions of Node and
MsgDestination, but if you don't see the need fo= r this as editor of the draft, that's your choice.

My outstanding concern for 6046-bis is that the following text in -08 appe= ars to be wrong because
section 6 of RFC 6125 doesn't apply to cl= ient identity verification:

>    RID systems MUST= verify the identity of their peers against that
>  = ;  stored in the certificate presented, as in section 6 of [RFC61= 25].

For the client certificate, it l= ooks like the only means of identity verification is path validation
<= div>of the TLS client certificate against the server's trust store. &n= bsp;A sentence to say that directly
could be an alternative to a = pointer to 6045-bis's PKI material.

Thanks,
<= div>--David


-----Original Message-----
From: M= oriarty, Kathleen
Sent: Wednesday, January 25, 2012 2:28 PM
To: Black, David; mile@ietf.org=
Subject: RE: 6046-bis - Client certificate identity check
=
Hi David,
Thank you.  Th= e Node information contained within IODEF is important to know the systems = involved in
handling an incident.  This is important a= t the IODEF document level as the incident information would
sta= y with the IODEF document even though a new RID message may be used. &= nbsp;I hope that helps to clarify
the reason for this informatio= n at the IODEF document level.
I am not sure. &= nbsp;RFC6045-bis would say verify the role as opposed to client for authent= ication and I am
pretty sure that is already in there. &nbs= p;The only thing I think that needs to be decided is if we have
= to clarify the NOT RECOMMENDED in the paragraph about mutual authentication= since this may be read as
specific to mutual authentication, wh= ere DNS-ID is required.  Maybe it is fine...
I think the only outstanding issue is with RFC6045 and if Punycode shoul= d be allowed in the RID XML
document.
Tha= nks,
Kathleen
-----Original Message-----<= /div>
From: Black, David
Sent: Wednesday, January 25, 2012 = 2:00 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: RE: 6046-bis - Client certificate id= entity check
Hi Kathleen,
I m= issed the connection between Node and MsgDestination in 6045-bis - my mista= ke.
It might be useful to repeat the following text = from the specification of "MsgDestination"
in the spec= ification of the Node element in RIDPolicy, as those specifications are 5
pages apart, and the current specification of the Node element is= not precise about
usage:
  &nbs= p;       the meaning of the value
<= div>          in the Node= element is determined by the MsgDestination element
= OTOH, I now don't see anything in RID that represents the identity of the = system sending
the RID message, and I don't think adding that is= important enough to make a change at
this juncture.  = I also don't see any point in trying to use the enveloped IODEF document
to carry the identity of the sending RID system, as that document = could get forwarded
in a different RID message, for which it wou= ld contain the wrong sending RID system
identity.
If there's no instance of the sending RID system's identity in the= RID message, then I
suppose the client identity verification wo= uld have to be based on the information used
to set up the trust= relationships in the consortium.  The 6046-bis draft already has= a
reference to the PKI discussion in 6045-bis. Would it make se= nse to clarify 6046-bis
to indicate that RFC 6125 Section 6 appl= ies only to server identity verification and the
PKI material in= 6045-bis applies to both server and client identity verification?
Thanks,
--David
> -----= Original Message-----
> From: Moriarty, Kathleen
&= gt; Sent: Wednesday, January 25, 2012 1:21 PM
> To: Black, Da= vid; mile@ietf.org
> Sub= ject: RE: 6046-bis - Client certificate identity check
>
> Hi David,
>
> Thank you for the com= ments.  If text is added, it will need to be specific to the inst= ance of Node
in
> RID or IODEF.  This wo= uld mean the CN would be used for this purpose (if UTF-8 names are OKed for=
use
> in RID NodeNames with the internationalizat= ion discussions).  RID uses Node in two places and it may
> make more sense to reference the one in the IODEF document or chan= ge something in RID.
>
> Instances of where 'No= de' appears:
> 1) Node in SourceFound would not apply here.
>
> 2) Node in RID RIDPolicy is tied to MsgDesti= nation and would be the receiving Node or the suspected
> sou= rce of an incident if a traceback were in play.
>
= > 3) This means the connection would need to be to the IODEF document an= d would require the document
to
> be decrypted to = verify if this were necessary.  Or adding a Node instance specifi= c to the sending
host
> information.
&g= t;
> 4) If it were tied to IODEF, the use of Node in the Syst= em class is specific to the source and
> destination addresse= s involved in an attack. The EventData where contact category is set to
> "infrastructure" is the place where systems involved= in communicating IODEF documents are listed.
> This is the p= ath information for incident data (lists all of the 'from' systems in RID
> communications).
>
> Thanks,
> Kathleen (as editor)
>
> -----Orig= inal Message-----
> Sent: Wednesday, January = 25, 2012 12:39 PM
> Subject: [mile] 6046-bis - Client certificate= identity check
>
> Brian and Kathleen,
>
> I think I found something in looking at the text r= elated to the question about
> certificate identities, but so= me more input would be useful.
>
> The 6046-bis= -08 draft says:
>
>    RID = systems MUST verify the identity of their peers against that
>= ;    stored in the certificate presented, as in section= 6 of [RFC6125].
>
> That covers verification o= f the identity of the receiving system (the identity
> in the= TLS server certificate has to match host component of URI for HTTP), but
> I don't think it covers verification of the identity of the = sending system, as
> Section 6 of RFC 6125 concerns only serv= ice identity.
>
> I'd suggest adding some text = that requires that the identity of the sending
> system in th= e TLS client certificate match the NodeName in the Node element
= > of the RIDPolicy class if the NodeName is present. That "is prese= nt" complication
> is courtesy of 6045-bis reusing the I= ODEF Node class from RFC 5070, because
> RFC 5070 does not re= quire that NodeName be present.
>
> I'm not sur= e what to do if NodeName is absent - a possible approach would be to
<= div> > not go there, and instead add a requirement to 6045-bis that Node= Name MUST be
> present in the Node element of the RIDPolicy c= lass in order to facilitate
> this identity check.
= >
> What do other people think?
>
> Thanks,
> --David
> --------------------= --------------------------------
> David L. Black, Distinguis= hed Engineer
> EMC Corporation, 176 South St., Hopkinton, MA&= nbsp; 01748
--_000_CB45C0552A44Dkentlandfieldmcafeecom_-- From trammell@tik.ee.ethz.ch Wed Jan 25 13:17: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 12A6F21F85FD for ; Wed, 25 Jan 2012 13:17:50 -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 VuMuPQxVg0zV for ; Wed, 25 Jan 2012 13:17:48 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8441421F862A for ; Wed, 25 Jan 2012 13:17:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CE994D9309; Wed, 25 Jan 2012 22:17:47 +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 MVdsALQ+le0d; Wed, 25 Jan 2012 22:17:47 +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 1534FD9300; Wed, 25 Jan 2012 22:17:47 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> Date: Wed, 25 Jan 2012 22:17:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> To: "david.black@emc.com> , Kathleen Moriarty X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org, Alexey Melnikov , Peter Saint-Andre Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 21:17:50 -0000 Hi, David, The reference identifier (defined in RFC 6215 section 1.8; explained in = 6.2) in RID transport is (presumably) the identity one system uses to = connect to another (see paragraph 12 of 6046-bis-08 section 3: "...the = use of stable DNS names to address RID Systems is RECOMMENDED"). This = could perhaps be made more explicit but it seemed obvious enough. For mutual authentication, this would have to be derived from a reverse = mapping of the network address back to a name (either by DNS PTR = records, or a whitelist of consortium members).=20 Perhaps stating "each RID system MUST maintain a DNS-ID reference = identifier for those RID systems it participates in a consortium with, = and use this for comparison with the DNS-ID stored in the certificate = presented by RID system peers" would address this concern? Regards, Brian On Jan 25, 2012, at 9:24 PM, = wrote: > Hi Brian, >=20 > Kathleen quickly disposed of #1, so please ignore that. She'll add = some text to > 6045-bis to help other readers avoid the mistake that I made. >=20 > For #2, the short summary of my concern with the current text involves = this sentence: >=20 >> RID systems MUST verify the identity of their peers against = that stored >> in the certificate presented. >=20 > How does a RID system (as TLS client or server) do that? >=20 > The next sentence explains what the identity is, but not how to verify = it: >=20 >> All RID systems MUST be identified by a >> certificate containing a DNS-ID = identifier >> as in section 6.4 of . >=20 > In particular, section 6.4 of RFC 6125 doesn't specify what the = certificate identity > is checked against. It may even be that section 6.4 of RFC 6125 = doesn't apply to > client certificates, because the client identity check my be subsumed = by PKIX path > validation of the client certificate against the server's trust store, = which does > name comparison according to RFC 5280, not RFC 6125. >=20 > A sentence or two on how to do that required (MUST) identity = verification would help. >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Wednesday, January 25, 2012 2:55 PM >> To: Brian Trammell; Black, David >> Cc: mile@ietf.org >> Subject: RE: [mile] 6046-bis - Client certificate identity check >>=20 >> Hi Brian, >>=20 >> You can save your time on #1, the question/request was withdrawn. = The sending RID server may only >> appear within the IODEF document and not the RID XML document. >>=20 >> Thank you, >> Kathleen >>=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Wednesday, January 25, 2012 2:51 PM >> To: Black, David >> Cc: Moriarty, Kathleen; mile@ietf.org >> Subject: Re: [mile] 6046-bis - Client certificate identity check >>=20 >> Hi, David, >>=20 >> Thanks for the comments; I've been out of contact all day so am = catching up. I'll top-post my summary >> reply at first; I may have further detail replies in a subsequent = message. >>=20 >> 1. I would need to think more deeply about the implications of any = authentication also cross-checking >> the DNS-ID against not only network-layer available identifiers but = also against information stored >> within the RID document itself. There seems to be a bit of a chicken = and egg problem there, and it >> seems to me that there may be valid exceptions to a policy that would = be simple enough to be (a) >> implementable and (b) verifiable. >>=20 >> 2. It is not the intent that 6125 section 4 applies solely to the = authentication of the TLS server; >> _all_ authentication in RID over HTTPS must be mutual, and I believe = the current proposed text (copied >> below straight from xml source) to be clear on this point, in = context. If that's not the case, then >> we'll need to change it. >>=20 >> RID systems MUST use TLS version 1.1 = or higher >> for confidentiality, identification, and authentication, when = sending RID >> messages over HTTPS. HTTPS is specified in Section 2 of > target=3D"RFC2818"/>. RID systems MUST use mutual authentication; = that is, >> both RID systems acting as HTTPS clients and RID systems acting as = HTTPS >> servers MUST be identified by an X.509 >> certificate. Mutual authentication requires full path = validation on >> each certificate, as defined in . >>=20 >> The TLS session MUST use non-NULL ciphersuites for = authentication, >> integrity, and confidentiality. Sessions MAY be renegotiated = within these >> constraints. >>=20 >> RID systems MUST verify the identity of their peers against = that stored >> in the certificate presented. All RID systems MUST be identified = by a >> certificate containing a DNS-ID = identifier >> as in section 6.4 of . The inclusion of = Common >> Names (CN-IDs) in certificates identifying RID systems is NOT = RECOMMENDED. >> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate >> identifying a RID system. Additional general information on the = use of PKI >> with RID systems is detailed in Section 9.3 of > target=3D"I-D.ietf-mile-rfc6045-bis"/>. >>=20 >> RID systems MUST support TLS version 1.1 and SHOULD support TLS = version >> 1.2 ; RID systems MUST NOT request, = offer, or use >> any version of SSL, or any version of TLS prior to 1.1, due to = known >> security vulnerabilities in prior versions of the protocol; see = Appendix E >> of for more. >>=20 >> Best regards, >>=20 >> Brian >>=20 >> On Jan 25, 2012, at 8:00 PM, wrote: >>=20 >>> Hi Kathleen, >>>=20 >>> I missed the connection between Node and MsgDestination in 6045-bis = - my mistake. >>>=20 >>> It might be useful to repeat the following text from the = specification of "MsgDestination" >>> in the specification of the Node element in RIDPolicy, as those = specifications are 5 >>> pages apart, and the current specification of the Node element is = not precise about >>> usage: >>>=20 >>> the meaning of the value >>> in the Node element is determined by the MsgDestination = element >>>=20 >>> OTOH, I now don't see anything in RID that represents the identity = of the system sending >>> the RID message, and I don't think adding that is important enough = to make a change at >>> this juncture. I also don't see any point in trying to use the = enveloped IODEF document >>> to carry the identity of the sending RID system, as that document = could get forwarded >>> in a different RID message, for which it would contain the wrong = sending RID system >>> identity. >>>=20 >>> If there's no instance of the sending RID system's identity in the = RID message, then I >>> suppose the client identity verification would have to be based on = the information used >>> to set up the trust relationships in the consortium. The 6046-bis = draft already has a >>> reference to the PKI discussion in 6045-bis. Would it make sense to = clarify 6046-bis >>> to indicate that RFC 6125 Section 6 applies only to server identity = verification and the >>> PKI material in 6045-bis applies to both server and client identity = verification? >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Wednesday, January 25, 2012 1:21 PM >>>> To: Black, David; mile@ietf.org >>>> Subject: RE: 6046-bis - Client certificate identity check >>>>=20 >>>> Hi David, >>>>=20 >>>> Thank you for the comments. If text is added, it will need to be = specific to the instance of Node >> in >>>> RID or IODEF. This would mean the CN would be used for this = purpose (if UTF-8 names are OKed for >> use >>>> in RID NodeNames with the internationalization discussions). RID = uses Node in two places and it >> may >>>> make more sense to reference the one in the IODEF document or = change something in RID. >>>>=20 >>>> Instances of where 'Node' appears: >>>> 1) Node in SourceFound would not apply here. >>>>=20 >>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the = receiving Node or the suspected >>>> source of an incident if a traceback were in play. >>>>=20 >>>> 3) This means the connection would need to be to the IODEF document = and would require the document >> to >>>> be decrypted to verify if this were necessary. Or adding a Node = instance specific to the sending >> host >>>> information. >>>>=20 >>>> 4) If it were tied to IODEF, the use of Node in the System class is = specific to the source and >>>> destination addresses involved in an attack. The EventData where = contact category is set to >>>> "infrastructure" is the place where systems involved in = communicating IODEF documents are listed. >>>> This is the path information for incident data (lists all of the = 'from' systems in RID >>>> communications). >>>>=20 >>>> Thanks, >>>> Kathleen (as editor) >>>>=20 >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On = Behalf Of david.black@emc.com >>>> Sent: Wednesday, January 25, 2012 12:39 PM >>>> To: mile@ietf.org >>>> Subject: [mile] 6046-bis - Client certificate identity check >>>>=20 >>>> Brian and Kathleen, >>>>=20 >>>> I think I found something in looking at the text related to the = question about >>>> certificate identities, but some more input would be useful. >>>>=20 >>>> The 6046-bis-08 draft says: >>>>=20 >>>> RID systems MUST verify the identity of their peers against that >>>> stored in the certificate presented, as in section 6 of [RFC6125]. >>>>=20 >>>> That covers verification of the identity of the receiving system = (the identity >>>> in the TLS server certificate has to match host component of URI = for HTTP), but >>>> I don't think it covers verification of the identity of the sending = system, as >>>> Section 6 of RFC 6125 concerns only service identity. >>>>=20 >>>> I'd suggest adding some text that requires that the identity of the = sending >>>> system in the TLS client certificate match the NodeName in the Node = element >>>> of the RIDPolicy class if the NodeName is present. That "is = present" complication >>>> is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, = because >>>> RFC 5070 does not require that NodeName be present. >>>>=20 >>>> I'm not sure what to do if NodeName is absent - a possible approach = would be to >>>> not go there, and instead add a requirement to 6045-bis that = NodeName MUST be >>>> present in the Node element of the RIDPolicy class in order to = facilitate >>>> this identity check. >>>>=20 >>>> What do other people think? >>>>=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 >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 From kathleen.moriarty@emc.com Wed Jan 25 13:54: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 3E74611E80BC for ; Wed, 25 Jan 2012 13:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.639 X-Spam-Level: X-Spam-Status: No, score=-9.639 tagged_above=-999 required=5 tests=[AWL=0.960, 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 pdQ6KhhjNi6h for ; Wed, 25 Jan 2012 13:54:25 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id BF49411E80A6 for ; Wed, 25 Jan 2012 13:54:25 -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 q0PLsK3A025526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 16:54:23 -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, 25 Jan 2012 16:54:05 -0500 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PLs4bJ014281; Wed, 25 Jan 2012 16:54:05 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Wed, 25 Jan 2012 16:54:04 -0500 From: To: , Date: Wed, 25 Jan 2012 16:54:03 -0500 Thread-Topic: [mile] 6046-bis Thread-Index: Aczbptw3tGIB2ji9TGGVjzqsRgSG3gABHS+A Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> In-Reply-To: <699A7BD6-15F4-46EE-84C7-64E6362E419F@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, alexey.melnikov@isode.com, stpeter@stpeter.im Subject: Re: [mile] 6046-bis 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, 25 Jan 2012 21:54:27 -0000 Hello, The comment period on changes to this draft has a come to a close. Thank y= ou all for your comments and contributions to improve the work. Thank you = Brian for your efforts to resolve any issues or discussions. Please post a= n -09 version to finalize any of the discussion points that were agreed upo= n. Great job! Best regards, Kathleen (as a WG chair) -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Wednesday, January 25, 2012 4:18 PM To: Black, David; Moriarty, Kathleen Cc: Peter Saint-Andre; Alexey Melnikov; Sean Turner; mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check Hi, David, The reference identifier (defined in RFC 6215 section 1.8; explained in 6.2= ) in RID transport is (presumably) the identity one system uses to connect = to another (see paragraph 12 of 6046-bis-08 section 3: "...the use of stabl= e DNS names to address RID Systems is RECOMMENDED"). This could perhaps be = made more explicit but it seemed obvious enough. For mutual authentication, this would have to be derived from a reverse map= ping of the network address back to a name (either by DNS PTR records, or a= whitelist of consortium members).=20 Perhaps stating "each RID system MUST maintain a DNS-ID reference identifie= r for those RID systems it participates in a consortium with, and use this = for comparison with the DNS-ID stored in the certificate presented by RID s= ystem peers" would address this concern? Regards, Brian On Jan 25, 2012, at 9:24 PM, wr= ote: > Hi Brian, >=20 > Kathleen quickly disposed of #1, so please ignore that. She'll add some = text to > 6045-bis to help other readers avoid the mistake that I made. >=20 > For #2, the short summary of my concern with the current text involves th= is sentence: >=20 >> RID systems MUST verify the identity of their peers against that s= tored >> in the certificate presented. >=20 > How does a RID system (as TLS client or server) do that? >=20 > The next sentence explains what the identity is, but not how to verify it= : >=20 >> All RID systems MUST be identified by a >> certificate containing a DNS-ID identifier >> as in section 6.4 of . >=20 > In particular, section 6.4 of RFC 6125 doesn't specify what the certifica= te identity > is checked against. It may even be that section 6.4 of RFC 6125 doesn't = apply to > client certificates, because the client identity check my be subsumed by = PKIX path > validation of the client certificate against the server's trust store, wh= ich does > name comparison according to RFC 5280, not RFC 6125. >=20 > A sentence or two on how to do that required (MUST) identity verification= would help. >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Wednesday, January 25, 2012 2:55 PM >> To: Brian Trammell; Black, David >> Cc: mile@ietf.org >> Subject: RE: [mile] 6046-bis - Client certificate identity check >>=20 >> Hi Brian, >>=20 >> You can save your time on #1, the question/request was withdrawn. The s= ending RID server may only >> appear within the IODEF document and not the RID XML document. >>=20 >> Thank you, >> Kathleen >>=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Wednesday, January 25, 2012 2:51 PM >> To: Black, David >> Cc: Moriarty, Kathleen; mile@ietf.org >> Subject: Re: [mile] 6046-bis - Client certificate identity check >>=20 >> Hi, David, >>=20 >> Thanks for the comments; I've been out of contact all day so am catching= up. I'll top-post my summary >> reply at first; I may have further detail replies in a subsequent messag= e. >>=20 >> 1. I would need to think more deeply about the implications of any authe= ntication also cross-checking >> the DNS-ID against not only network-layer available identifiers but also= against information stored >> within the RID document itself. There seems to be a bit of a chicken and= egg problem there, and it >> seems to me that there may be valid exceptions to a policy that would be= simple enough to be (a) >> implementable and (b) verifiable. >>=20 >> 2. It is not the intent that 6125 section 4 applies solely to the authen= tication of the TLS server; >> _all_ authentication in RID over HTTPS must be mutual, and I believe the= current proposed text (copied >> below straight from xml source) to be clear on this point, in context. I= f that's not the case, then >> we'll need to change it. >>=20 >> RID systems MUST use TLS version 1.1 or= higher >> for confidentiality, identification, and authentication, when sending= RID >> messages over HTTPS. HTTPS is specified in Section 2 of > target=3D"RFC2818"/>. RID systems MUST use mutual authentication; tha= t is, >> both RID systems acting as HTTPS clients and RID systems acting as HT= TPS >> servers MUST be identified by an X.509 >> certificate. Mutual authentication requires full path validati= on on >> each certificate, as defined in . >>=20 >> The TLS session MUST use non-NULL ciphersuites for authentication, >> integrity, and confidentiality. Sessions MAY be renegotiated within t= hese >> constraints. >>=20 >> RID systems MUST verify the identity of their peers against that s= tored >> in the certificate presented. All RID systems MUST be identified by a >> certificate containing a DNS-ID identifier >> as in section 6.4 of . The inclusion of Com= mon >> Names (CN-IDs) in certificates identifying RID systems is NOT RECOMME= NDED. >> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate >> identifying a RID system. Additional general information on the use o= f PKI >> with RID systems is detailed in Section 9.3 of > target=3D"I-D.ietf-mile-rfc6045-bis"/>. >>=20 >> RID systems MUST support TLS version 1.1 and SHOULD support TLS ve= rsion >> 1.2 ; RID systems MUST NOT request, offer, = or use >> any version of SSL, or any version of TLS prior to 1.1, due to known >> security vulnerabilities in prior versions of the protocol; see Appen= dix E >> of for more. >>=20 >> Best regards, >>=20 >> Brian >>=20 >> On Jan 25, 2012, at 8:00 PM, wrote: >>=20 >>> Hi Kathleen, >>>=20 >>> I missed the connection between Node and MsgDestination in 6045-bis - m= y mistake. >>>=20 >>> It might be useful to repeat the following text from the specification = of "MsgDestination" >>> in the specification of the Node element in RIDPolicy, as those specifi= cations are 5 >>> pages apart, and the current specification of the Node element is not p= recise about >>> usage: >>>=20 >>> the meaning of the value >>> in the Node element is determined by the MsgDestination element >>>=20 >>> OTOH, I now don't see anything in RID that represents the identity of t= he system sending >>> the RID message, and I don't think adding that is important enough to m= ake a change at >>> this juncture. I also don't see any point in trying to use the envelop= ed IODEF document >>> to carry the identity of the sending RID system, as that document could= get forwarded >>> in a different RID message, for which it would contain the wrong sendin= g RID system >>> identity. >>>=20 >>> If there's no instance of the sending RID system's identity in the RID = message, then I >>> suppose the client identity verification would have to be based on the = information used >>> to set up the trust relationships in the consortium. The 6046-bis draf= t already has a >>> reference to the PKI discussion in 6045-bis. Would it make sense to cla= rify 6046-bis >>> to indicate that RFC 6125 Section 6 applies only to server identity ver= ification and the >>> PKI material in 6045-bis applies to both server and client identity ver= ification? >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Wednesday, January 25, 2012 1:21 PM >>>> To: Black, David; mile@ietf.org >>>> Subject: RE: 6046-bis - Client certificate identity check >>>>=20 >>>> Hi David, >>>>=20 >>>> Thank you for the comments. If text is added, it will need to be spec= ific to the instance of Node >> in >>>> RID or IODEF. This would mean the CN would be used for this purpose (= if UTF-8 names are OKed for >> use >>>> in RID NodeNames with the internationalization discussions). RID uses= Node in two places and it >> may >>>> make more sense to reference the one in the IODEF document or change s= omething in RID. >>>>=20 >>>> Instances of where 'Node' appears: >>>> 1) Node in SourceFound would not apply here. >>>>=20 >>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the re= ceiving Node or the suspected >>>> source of an incident if a traceback were in play. >>>>=20 >>>> 3) This means the connection would need to be to the IODEF document an= d would require the document >> to >>>> be decrypted to verify if this were necessary. Or adding a Node insta= nce specific to the sending >> host >>>> information. >>>>=20 >>>> 4) If it were tied to IODEF, the use of Node in the System class is sp= ecific to the source and >>>> destination addresses involved in an attack. The EventData where conta= ct category is set to >>>> "infrastructure" is the place where systems involved in communicating = IODEF documents are listed. >>>> This is the path information for incident data (lists all of the 'from= ' systems in RID >>>> communications). >>>>=20 >>>> Thanks, >>>> Kathleen (as editor) >>>>=20 >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf O= f david.black@emc.com >>>> Sent: Wednesday, January 25, 2012 12:39 PM >>>> To: mile@ietf.org >>>> Subject: [mile] 6046-bis - Client certificate identity check >>>>=20 >>>> Brian and Kathleen, >>>>=20 >>>> I think I found something in looking at the text related to the questi= on about >>>> certificate identities, but some more input would be useful. >>>>=20 >>>> The 6046-bis-08 draft says: >>>>=20 >>>> RID systems MUST verify the identity of their peers against that >>>> stored in the certificate presented, as in section 6 of [RFC6125]. >>>>=20 >>>> That covers verification of the identity of the receiving system (the = identity >>>> in the TLS server certificate has to match host component of URI for H= TTP), but >>>> I don't think it covers verification of the identity of the sending sy= stem, as >>>> Section 6 of RFC 6125 concerns only service identity. >>>>=20 >>>> I'd suggest adding some text that requires that the identity of the se= nding >>>> system in the TLS client certificate match the NodeName in the Node el= ement >>>> of the RIDPolicy class if the NodeName is present. That "is present" c= omplication >>>> is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, be= cause >>>> RFC 5070 does not require that NodeName be present. >>>>=20 >>>> I'm not sure what to do if NodeName is absent - a possible approach wo= uld be to >>>> not go there, and instead add a requirement to 6045-bis that NodeName = MUST be >>>> present in the Node element of the RIDPolicy class in order to facilit= ate >>>> this identity check. >>>>=20 >>>> What do other people think? >>>>=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 >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 From internet-drafts@ietf.org Wed Jan 25 14:03: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 7EADA21F854E; Wed, 25 Jan 2012 14:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 LVWpUlaVcoXo; Wed, 25 Jan 2012 14:03:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F7921F8542; Wed, 25 Jan 2012 14:03:29 -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.64p1 Message-ID: <20120125220329.31133.87247.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 14:03:29 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-09.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: Wed, 25 Jan 2012 22:03: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 : Transport of Real-time Inter-network Defense (RID) Messa= ges over HTTP/ TLS Author(s) : Brian Trammell Filename : draft-ietf-mile-rfc6046-bis-09.txt Pages : 8 Date : 2012-01-25 The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-09.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-rfc6046-bis-09.txt From trammell@tik.ee.ethz.ch Wed Jan 25 14:05: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 BFC7911E8098 for ; Wed, 25 Jan 2012 14:05: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 QXLWdJ3Kv5-k for ; Wed, 25 Jan 2012 14:05:22 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F07CA11E807A for ; Wed, 25 Jan 2012 14:05:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 56EDBD9309 for ; Wed, 25 Jan 2012 23:05: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 0Oe3uZBlCmSa for ; Wed, 25 Jan 2012 23:05:21 +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 E859BD9300 for ; Wed, 25 Jan 2012 23:05:20 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 23:05:20 +0100 References: <20120125220329.31133.87247.idtracker@ietfa.amsl.com> To: mile@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mile] Fwd: I-D Action: draft-ietf-mile-rfc6046-bis-09.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: Wed, 25 Jan 2012 22:05:22 -0000 Greetings, all, I've submitted the -09 revision of rfc6046-bis; I believe this addresses = the outstanding issues with certificate verification and identification = of RID systems. Best regards, Brian (author hat) Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 25, 2012 11:03:29 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Managed Incident = Lightweight Exchange Working Group of the IETF. >=20 > Title : Transport of Real-time Inter-network Defense = (RID) Messages over HTTP/ TLS > Author(s) : Brian Trammell > Filename : draft-ietf-mile-rfc6046-bis-09.txt > Pages : 8 > Date : 2012-01-25 >=20 > The Incident Object Description Exchange Format (IODEF) defines a > common XML format for document exchange, and Realtime Internetwork > Defense (RID) defines extensions to IODEF intended for the > cooperative handling of security incidents within consortia of > network operators and enterprises. This document specifies a > application-layer protocol for RID based upon the passing of RID > messages over HTTP/TLS. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-09.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-09.txt >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Jan 25 14:07: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 7ACA921F8554 for ; Wed, 25 Jan 2012 14:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.657 X-Spam-Level: X-Spam-Status: No, score=-9.657 tagged_above=-999 required=5 tests=[AWL=0.942, 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 QczeHYhtUb7v for ; Wed, 25 Jan 2012 14:07:28 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id D7C5E21F8552 for ; Wed, 25 Jan 2012 14:07:27 -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 q0PM7LNd019546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 17:07:24 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 25 Jan 2012 17:07:01 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0PM703N003975; Wed, 25 Jan 2012 17:07:00 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Wed, 25 Jan 2012 17:07:00 -0500 From: To: , , Date: Wed, 25 Jan 2012 17:06:58 -0500 Thread-Topic: IDN issue Thread-Index: AczXAch0C2+AUXg6RraiC+lSbWVgcQEnt22Q Message-ID: References: <4F184E34.1070708@ieca.com> <4F185585.9060003@stpeter.im> <4F185837.40301@stpeter.im> <4F189166.6080404@stpeter.im> <4F189CF3.1070802@qualcomm.com> <4F18A360.50607@ieca.com> In-Reply-To: <4F18A360.50607@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] IDN issue 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, 25 Jan 2012 22:07:28 -0000 Hello Pete, Peter, and Sean, The working group provided a few comments, they agree with internationaliza= tion support, but would prefer to keep the RID message in UTF-8. They woul= d prefer any translation to punycode happen by the DNS supporting the RID a= pplication. Are you OK with changing the text as follows: 11. Internationalization Considerations The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC 5980]; A-labels MUST NOT be used. A RID system can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. From: >> 11. Internationalization Considerations >> >> The Node class identifies a host or network device. This document >> re-uses the definition of Node from the IODEF specification >> [RFC5070], Section 3.16. However, that document did not clearly >> specify whether a NodeName could be an Internationalized Domain Name >> (IDN). RID systems MUST treat the NodeName class as a domain name >> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >> class; if they do so, they MUST ensure that the domain name is >> represented only using ASCII characters, i.e., all of its labels >> MUST be either A-labels or NR-LDH labels [RFC5890] and >> internationalized labels MUST be encoded as A-labels using the >> Punycode encoding [RFC3492] as described in the protocol >> specification for Internationalized Domain Names in Applications >> [RFC5891]. >> Thank you, Kathleen (as author) From trammell@tik.ee.ethz.ch Wed Jan 25 14:18: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 33EE111E80B9 for ; Wed, 25 Jan 2012 14:18:06 -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 mLfUE6m02sYj for ; Wed, 25 Jan 2012 14:18:05 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6091211E807A for ; Wed, 25 Jan 2012 14:18:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BA9A6D930A for ; Wed, 25 Jan 2012 23:18:04 +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 Q+h-WmX34R+z for ; Wed, 25 Jan 2012 23:18:04 +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 58368D9300 for ; Wed, 25 Jan 2012 23:18:04 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Brian Trammell In-Reply-To: Date: Wed, 25 Jan 2012 23:18:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <467A545F-58AF-43DD-B816-516555B0C50D@tik.ee.ethz.ch> References: <4F184E34.1070708@ieca.com> <4F185585.9060003@stpeter.im> <4F185837.40301@stpeter.im> <4F189166.6080404@stpeter.im> <4F189CF3.1070802@qualcomm.com> <4F18A360.50607@ieca.com> To: mile@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [mile] rfc6045-bis IDN issue 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, 25 Jan 2012 22:18:06 -0000 Greetings, all, It appears that WG discussion on this last issue is closed, at least; = from my point of view, the draft is ready for submission of the next = (and hopefully final :) ) revision. Cheers, Brian (as WG chair) On Jan 25, 2012, at 11:06 PM, wrote: > Hello Pete, Peter, and Sean, >=20 > The working group provided a few comments, they agree with = internationalization support, but would prefer to keep the RID message = in UTF-8. They would prefer any translation to punycode happen by the = DNS supporting the RID application. Are you OK with changing the text = as follows: >=20 > 11. Internationalization Considerations >=20 > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name = MUST > be used, i.e., all of the domain name's labels MUST be U-labels > expressed in UTF-8 or NR-LDH labels [RFC 5980]; A-labels > MUST NOT be used. A RID system can convert between A-labels > and U-labels by using the Punycode encoding [RFC3492] for A-labels > as described in the protocol specification for Internationalized > Domain Names in Applications [RFC5891]. >=20 >=20 >=20 > From: >>> 11. Internationalization Considerations >>>=20 >>> The Node class identifies a host or network device. This document >>> re-uses the definition of Node from the IODEF specification >>> [RFC5070], Section 3.16. However, that document did not clearly >>> specify whether a NodeName could be an Internationalized Domain Name >>> (IDN). RID systems MUST treat the NodeName class as a domain name >>> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >>> class; if they do so, they MUST ensure that the domain name is >>> represented only using ASCII characters, i.e., all of its labels >>> MUST be either A-labels or NR-LDH labels [RFC5890] and >>> internationalized labels MUST be encoded as A-labels using the >>> Punycode encoding [RFC3492] as described in the protocol >>> specification for Internationalized Domain Names in Applications >>> [RFC5891]. >>>=20 >=20 > Thank you, > Kathleen (as author) From stpeter@stpeter.im Wed Jan 25 14:38: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 ED9D111E807A for ; Wed, 25 Jan 2012 14:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 9XB1tYWuIBtZ for ; Wed, 25 Jan 2012 14:38:36 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0721F8572 for ; Wed, 25 Jan 2012 14:38:36 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 704EA40058; Wed, 25 Jan 2012 15:48:21 -0700 (MST) Message-ID: <4F20846A.6090906@stpeter.im> Date: Wed, 25 Jan 2012 15:38:34 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <4F184E34.1070708@ieca.com> <4F185585.9060003@stpeter.im> <4F185837.40301@stpeter.im> <4F189166.6080404@stpeter.im> <4F189CF3.1070802@qualcomm.com> <4F18A360.50607@ieca.com> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: presnick@qualcomm.com, mile@ietf.org Subject: Re: [mile] IDN issue 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, 25 Jan 2012 22:38:37 -0000 On 1/25/12 3:06 PM, kathleen.moriarty@emc.com wrote: > Hello Pete, Peter, and Sean, Howdy. :) > The working group provided a few comments, they agree with > internationalization support, but would prefer to keep the RID > message in UTF-8. UTF-8 is a character encoding scheme (RFC 6365). The data of a RID document could contain A-labels (or other text with characters only from the ASCII range) yet still be encoded in UTF-8. So the choice of UTF-8 encoding for the RID document is somewhat orthogonal to the question of whether to use A-labels or U-labels in the domain name slot of the NodeName class. > They would prefer any translation to punycode > happen by the DNS supporting the RID application. That is one option, yes. > Are you OK with > changing the text as follows: > > 11. Internationalization Considerations > > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name > MUST be used, i.e., all of the domain name's labels MUST be U-labels > expressed in UTF-8 or NR-LDH labels [RFC 5980]; A-labels MUST NOT be > used. A RID system can convert between A-labels and U-labels by > using the Punycode encoding [RFC3492] for A-labels as described in > the protocol specification for Internationalized Domain Names in > Applications [RFC5891]. Well, it's important to understand what you're signing up for when you say that you want to use U-labels instead of A-labels. Please consider the definition of U-label from RFC 5890: o A "U-label" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8). It is also subject to the constraints about permitted characters that are specified in Section 4.2 of the Protocol document and the rules in the Sections 2 and 3 of the Tables document, the Bidi constraints in that document if it contains any character from scripts that are written right to left, and the symmetry constraint described immediately below. Conversions between U-labels and A-labels are performed according to the "Punycode" specification [RFC3492], adding or removing the ACE prefix as needed. Notice what's entailed here... 1. Unicode Normalization Form C (NFC): http://www.unicode.org/reports/tr15/tr15-31.html 2. Constraints on permitted characters from RFC 5891: http://tools.ietf.org/html/rfc5891#section-4.2 3. The property rules from RFC 5892: http://tools.ietf.org/html/rfc5892#section-2 http://tools.ietf.org/html/rfc5892#section-3 4. The bidi constraints from RFC 5892, see also RFC 5893: http://tools.ietf.org/html/rfc5893 Do IODEF/RID implementations want to sign up for all that? Furthermore, if we start accepting input strings then we might well need to specify mappings of the kind that are explained in RFC 5895. Notice the very helpful Section 3 in the latter specification: If you are implementing a mapping for an application or operating system by using exactly the four steps in Section 2, the authors of this document have a request: please don't. We mean it. Section 2 does not describe a universal mapping algorithm because, as we said, there is no universally-applicable mapping algorithm. If you read the material in Section 2 without reading Section 1, go back and carefully read all of Section 1; in many ways, Section 1 is more important than Section 2. Further, you can probably think of user interface considerations that we did not list in Section 1. If you did read Section 1 but somehow decided that the algorithm in Section 2 is completely correct for the intended users of your application or operating system, you are probably not thinking hard enough about your intended users. In short, there be dragons. Your life will be simpler if you say "we might get some IDNs out of the DNS or from somewhere else, and for our purposes we're going to assume that they're all A-labels because we don't want to deal directly with all that i18n madness, since it's just not a critical feature for RID itself and we're just a consumer of DNS names". Just my centigram of silver. :) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jan 25 15:16: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 3C00311E80DF for ; Wed, 25 Jan 2012 15:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 C9uwx0aEMlhQ for ; Wed, 25 Jan 2012 15:16:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2B11E80DE for ; Wed, 25 Jan 2012 15:16:33 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3EB5C40058; Wed, 25 Jan 2012 16:26:18 -0700 (MST) Message-ID: <4F208D4E.8040105@stpeter.im> Date: Wed, 25 Jan 2012 16:16:30 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Brian Trammell References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> In-Reply-To: <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mile@ietf.org, Alexey Melnikov Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 23:16:34 -0000 David is right that TLS client needs to have some expectations about the domain name of the TLS server. In RFC 6125 this is called a "reference identifier". In client-server protocols the expectation is typically set by a human user who has configured a client with account information, typed a URL in a browser location bar, etc. In protocols that have two servers interacting, you'd typically get the reference identifier from user-generated messages (e.g., email or IM) or in the case of something like RID have a whitelist of entities that are members of your consortium. So the text that Brian suggests seems reasonable to me. On 1/25/12 2:17 PM, Brian Trammell wrote: > Hi, David, > > The reference identifier (defined in RFC 6215 section 1.8; explained > in 6.2) in RID transport is (presumably) the identity one system uses > to connect to another (see paragraph 12 of 6046-bis-08 section 3: > "...the use of stable DNS names to address RID Systems is > RECOMMENDED"). This could perhaps be made more explicit but it seemed > obvious enough. > > For mutual authentication, this would have to be derived from a > reverse mapping of the network address back to a name (either by DNS > PTR records, or a whitelist of consortium members). > > Perhaps stating "each RID system MUST maintain a DNS-ID reference > identifier for those RID systems it participates in a consortium > with, and use this for comparison with the DNS-ID stored in the > certificate presented by RID system peers" would address this > concern? > > Regards, > > Brian > > On Jan 25, 2012, at 9:24 PM, > wrote: > >> Hi Brian, >> >> Kathleen quickly disposed of #1, so please ignore that. She'll add >> some text to 6045-bis to help other readers avoid the mistake that >> I made. >> >> For #2, the short summary of my concern with the current text >> involves this sentence: >> >>> RID systems MUST verify the identity of their peers against >>> that stored in the certificate presented. >> >> How does a RID system (as TLS client or server) do that? >> >> The next sentence explains what the identity is, but not how to >> verify it: >> >>> All RID systems MUST be identified by a certificate containing a >>> DNS-ID identifier as in section 6.4 >>> of . >> >> In particular, section 6.4 of RFC 6125 doesn't specify what the >> certificate identity is checked against. It may even be that >> section 6.4 of RFC 6125 doesn't apply to client certificates, >> because the client identity check my be subsumed by PKIX path >> validation of the client certificate against the server's trust >> store, which does name comparison according to RFC 5280, not RFC >> 6125. >> >> A sentence or two on how to do that required (MUST) identity >> verification would help. >> >> Thanks, --David >> >> >>> -----Original Message----- From: Moriarty, Kathleen Sent: >>> Wednesday, January 25, 2012 2:55 PM To: Brian Trammell; Black, >>> David Cc: mile@ietf.org Subject: RE: [mile] 6046-bis - Client >>> certificate identity check >>> >>> Hi Brian, >>> >>> You can save your time on #1, the question/request was withdrawn. >>> The sending RID server may only appear within the IODEF document >>> and not the RID XML document. >>> >>> Thank you, Kathleen >>> >>> -----Original Message----- From: Brian Trammell >>> [mailto:trammell@tik.ee.ethz.ch] Sent: Wednesday, January 25, >>> 2012 2:51 PM To: Black, David Cc: Moriarty, Kathleen; >>> mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate >>> identity check >>> >>> Hi, David, >>> >>> Thanks for the comments; I've been out of contact all day so am >>> catching up. I'll top-post my summary reply at first; I may have >>> further detail replies in a subsequent message. >>> >>> 1. I would need to think more deeply about the implications of >>> any authentication also cross-checking the DNS-ID against not >>> only network-layer available identifiers but also against >>> information stored within the RID document itself. There seems to >>> be a bit of a chicken and egg problem there, and it seems to me >>> that there may be valid exceptions to a policy that would be >>> simple enough to be (a) implementable and (b) verifiable. >>> >>> 2. It is not the intent that 6125 section 4 applies solely to the >>> authentication of the TLS server; _all_ authentication in RID >>> over HTTPS must be mutual, and I believe the current proposed >>> text (copied below straight from xml source) to be clear on this >>> point, in context. If that's not the case, then we'll need to >>> change it. >>> >>> RID systems MUST use TLS version 1.1 >>> or higher for confidentiality, identification, and >>> authentication, when sending RID messages over HTTPS. HTTPS is >>> specified in Section 2 of . RID systems >>> MUST use mutual authentication; that is, both RID systems acting >>> as HTTPS clients and RID systems acting as HTTPS servers MUST be >>> identified by an X.509 certificate. >>> Mutual authentication requires full path validation on each >>> certificate, as defined in . >>> >>> The TLS session MUST use non-NULL ciphersuites for >>> authentication, integrity, and confidentiality. Sessions MAY be >>> renegotiated within these constraints. >>> >>> RID systems MUST verify the identity of their peers against >>> that stored in the certificate presented. All RID systems MUST be >>> identified by a certificate containing a >> target="RFC5280">DNS-ID identifier as in section 6.4 of >>> . The inclusion of Common Names (CN-IDs) >>> in certificates identifying RID systems is NOT RECOMMENDED. >>> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a >>> certificate identifying a RID system. Additional general >>> information on the use of PKI with RID systems is detailed in >>> Section 9.3 of . >>> >>> RID systems MUST support TLS version 1.1 and SHOULD support >>> TLS version 1.2 ; RID systems MUST NOT >>> request, offer, or use any version of SSL, or any version of TLS >>> prior to 1.1, due to known security vulnerabilities in prior >>> versions of the protocol; see Appendix E of >> target="RFC5246"/> for more. >>> >>> Best regards, >>> >>> Brian >>> >>> On Jan 25, 2012, at 8:00 PM, wrote: >>> >>>> Hi Kathleen, >>>> >>>> I missed the connection between Node and MsgDestination in >>>> 6045-bis - my mistake. >>>> >>>> It might be useful to repeat the following text from the >>>> specification of "MsgDestination" in the specification of the >>>> Node element in RIDPolicy, as those specifications are 5 pages >>>> apart, and the current specification of the Node element is not >>>> precise about usage: >>>> >>>> the meaning of the value in the Node element is determined by >>>> the MsgDestination element >>>> >>>> OTOH, I now don't see anything in RID that represents the >>>> identity of the system sending the RID message, and I don't >>>> think adding that is important enough to make a change at this >>>> juncture. I also don't see any point in trying to use the >>>> enveloped IODEF document to carry the identity of the sending >>>> RID system, as that document could get forwarded in a different >>>> RID message, for which it would contain the wrong sending RID >>>> system identity. >>>> >>>> If there's no instance of the sending RID system's identity in >>>> the RID message, then I suppose the client identity >>>> verification would have to be based on the information used to >>>> set up the trust relationships in the consortium. The 6046-bis >>>> draft already has a reference to the PKI discussion in >>>> 6045-bis. Would it make sense to clarify 6046-bis to indicate >>>> that RFC 6125 Section 6 applies only to server identity >>>> verification and the PKI material in 6045-bis applies to both >>>> server and client identity verification? >>>> >>>> Thanks, --David >>>> >>>>> -----Original Message----- From: Moriarty, Kathleen Sent: >>>>> Wednesday, January 25, 2012 1:21 PM To: Black, David; >>>>> mile@ietf.org Subject: RE: 6046-bis - Client certificate >>>>> identity check >>>>> >>>>> Hi David, >>>>> >>>>> Thank you for the comments. If text is added, it will need >>>>> to be specific to the instance of Node >>> in >>>>> RID or IODEF. This would mean the CN would be used for this >>>>> purpose (if UTF-8 names are OKed for >>> use >>>>> in RID NodeNames with the internationalization discussions). >>>>> RID uses Node in two places and it >>> may >>>>> make more sense to reference the one in the IODEF document or >>>>> change something in RID. >>>>> >>>>> Instances of where 'Node' appears: 1) Node in SourceFound >>>>> would not apply here. >>>>> >>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would >>>>> be the receiving Node or the suspected source of an incident >>>>> if a traceback were in play. >>>>> >>>>> 3) This means the connection would need to be to the IODEF >>>>> document and would require the document >>> to >>>>> be decrypted to verify if this were necessary. Or adding a >>>>> Node instance specific to the sending >>> host >>>>> information. >>>>> >>>>> 4) If it were tied to IODEF, the use of Node in the System >>>>> class is specific to the source and destination addresses >>>>> involved in an attack. The EventData where contact category >>>>> is set to "infrastructure" is the place where systems >>>>> involved in communicating IODEF documents are listed. This is >>>>> the path information for incident data (lists all of the >>>>> 'from' systems in RID communications). >>>>> >>>>> Thanks, Kathleen (as editor) >>>>> >>>>> -----Original Message----- From: mile-bounces@ietf.org >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>> david.black@emc.com Sent: Wednesday, January 25, 2012 12:39 >>>>> PM To: mile@ietf.org Subject: [mile] 6046-bis - Client >>>>> certificate identity check >>>>> >>>>> Brian and Kathleen, >>>>> >>>>> I think I found something in looking at the text related to >>>>> the question about certificate identities, but some more >>>>> input would be useful. >>>>> >>>>> The 6046-bis-08 draft says: >>>>> >>>>> RID systems MUST verify the identity of their peers against >>>>> that stored in the certificate presented, as in section 6 of >>>>> [RFC6125]. >>>>> >>>>> That covers verification of the identity of the receiving >>>>> system (the identity in the TLS server certificate has to >>>>> match host component of URI for HTTP), but I don't think it >>>>> covers verification of the identity of the sending system, >>>>> as Section 6 of RFC 6125 concerns only service identity. >>>>> >>>>> I'd suggest adding some text that requires that the identity >>>>> of the sending system in the TLS client certificate match the >>>>> NodeName in the Node element of the RIDPolicy class if the >>>>> NodeName is present. That "is present" complication is >>>>> courtesy of 6045-bis reusing the IODEF Node class from RFC >>>>> 5070, because RFC 5070 does not require that NodeName be >>>>> present. >>>>> >>>>> I'm not sure what to do if NodeName is absent - a possible >>>>> approach would be to not go there, and instead add a >>>>> requirement to 6045-bis that NodeName MUST be present in the >>>>> Node element of the RIDPolicy class in order to facilitate >>>>> this identity check. >>>>> >>>>> What do other people think? >>>>> >>>>> 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 >>>>> ---------------------------------------------------- >>>>> >>>>> _______________________________________________ mile mailing >>>>> 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 tony@yaanatech.com Wed Jan 25 15:51: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 76C3211E8089 for ; Wed, 25 Jan 2012 15:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBG7c7qgu8dr for ; Wed, 25 Jan 2012 15:51:11 -0800 (PST) Received: from extmail1.prd.yaanatech.com (extmail1.prd.yaanatech.com [205.140.198.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACCE11E8071 for ; Wed, 25 Jan 2012 15:51:10 -0800 (PST) Received: from localhost (pool-173-72-136-146.clppva.fios.verizon.net [173.72.136.146]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by extmail1.prd.yaanatech.com (Postfix) with ESMTP id 7001858071; Wed, 25 Jan 2012 23:51:09 +0000 (UTC) Date: Wed, 25 Jan 2012 18:51:05 -0500 Message-ID: Importance: normal From: Tony To: stpeter@stpeter.im, trammell@tik.ee.ethz.ch MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_12375324489784" Cc: mile@ietf.org, alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 25 Jan 2012 23:51:11 -0000 ----_com.android.email_12375324489784 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T2YgY291cnNlIHlvdSBjb3VsZCB1c2UgYW4gRVZjZXJ0IC0gYXJndWFibHkgYSBiZXR0ZXIgc29s dXRpb24uCgoKU2VudCBmcm9tIFNhbXN1bmcgTW9iaWxl ----_com.android.email_12375324489784 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5PZiBjb3Vyc2UgeW91IGNvdWxkIHVz ZSBhbiBFVmNlcnQgLSBhcmd1YWJseSBhIGJldHRlciBzb2x1dGlvbi48YnI+PGJyPjxicj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjg3JSI+U2VudCBmcm9tIFNhbXN1bmcgTW9iaWxlPC9zcGFuPiA8 L2JvZHk+PC9odG1sPg== ----_com.android.email_12375324489784-- From david.black@emc.com Wed Jan 25 16:06: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 9B7AD11E80CD for ; Wed, 25 Jan 2012 16:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.22 X-Spam-Level: X-Spam-Status: No, score=-109.22 tagged_above=-999 required=5 tests=[AWL=1.379, 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 oIfgvRMh9eUg for ; Wed, 25 Jan 2012 16:06:55 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7088621F85C0 for ; Wed, 25 Jan 2012 16:06:55 -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 q0Q06q7a030266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 19:06:53 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 25 Jan 2012 19:06:35 -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 q0Q06YfJ003481; Wed, 25 Jan 2012 19:06:34 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Wed, 25 Jan 2012 19:06:34 -0500 From: To: , Importance: high X-Priority: 1 Date: Wed, 25 Jan 2012 19:06:33 -0500 Thread-Topic: [mile] IDN issue Thread-Index: AczbsjFeK8jk2240SWWTjoWB8sikVgAAeDoAAAJKKHA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: presnick@qualcomm.com Subject: [mile] FW: IDN issue 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, 26 Jan 2012 00:06:56 -0000 Hello Peter, > In short, there be dragons. Indeed (as I'm entirely too well-aware of from the pr=E9cis WG), however, t= he goal here is to find a suitable cave in which to confine the dragons :-). The place to start looking for that cave is an understanding of how NodeNam= e is used. The quick summary is that there are three cases: (1) RIDPolicy class, MsgDestination=3DRIDSystem. The NodeName is the destination of the RID message, so it can be required t= o work in the DNS, which already has to deal with figuring out whether a U-Label i= s valid. Text could be added to require that the NodeName either be used to send the= RID message via DNS lookup or that it has been looked up at some point in the p= ast and resolves to the IP address to which the RID message is sent. Both of these approaches rely on the DNS implementation to validate the U-label. (2) RIDPolicy class, MsgDestination=3DSourceOfIncident, and also the Incide= ntSource class. In both of these cases the IP address is the primary identifier (IncidentSo= urce needs additional text to state that the IP address is required - that appea= rs to have been overlooked). There are a couple of options here: a) The simplest is to prohibit NodeName usage. b) NodeName could be required to correspond to the IP address via DNS looku= p. (3) RIDPolicy class, MsgDestination=3Dext-value. This is an escape that al= lows extensions to MsgDestination. The description of this should include a "th= ere be dragons" warning about IDNs in NodeName. So, the answer to the somewhat rhetorical question: > Do IODEF/RID implementations want to sign up for all that? Is approximately "Yes, by relying on the DNS implementation," with the addi= tion of a "there be dragons" warning to the MsgDestination ext-value extension t= ext to communicate that to designers of extensions, and a possible prohibition = of use of NodeName when the IP address is the primary identifier. 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 ---------------------------------------------------- > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of P= eter Saint-Andre > Sent: Wednesday, January 25, 2012 5:39 PM > To: Moriarty, Kathleen > Cc: presnick@qualcomm.com; mile@ietf.org > Subject: Re: [mile] IDN issue >=20 > On 1/25/12 3:06 PM, kathleen.moriarty@emc.com wrote: > > Hello Pete, Peter, and Sean, >=20 > Howdy. :) >=20 > > The working group provided a few comments, they agree with > > internationalization support, but would prefer to keep the RID > > message in UTF-8. >=20 > UTF-8 is a character encoding scheme (RFC 6365). The data of a RID > document could contain A-labels (or other text with characters only from > the ASCII range) yet still be encoded in UTF-8. So the choice of UTF-8 > encoding for the RID document is somewhat orthogonal to the question of > whether to use A-labels or U-labels in the domain name slot of the > NodeName class. >=20 > > They would prefer any translation to punycode > > happen by the DNS supporting the RID application. >=20 > That is one option, yes. >=20 > > Are you OK with > > changing the text as follows: > > > > 11. Internationalization Considerations > > > > The Node class identifies a host or network device. This document > > re-uses the definition of Node from the IODEF specification > > [RFC5070], Section 3.16. However, that document did not clearly > > specify whether a NodeName could be an Internationalized Domain Name > > (IDN). RID systems MUST treat the NodeName class as a domain name > > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > > class; if they do so, the UTF-8 representation of the domain name > > MUST be used, i.e., all of the domain name's labels MUST be U-labels > > expressed in UTF-8 or NR-LDH labels [RFC 5980]; A-labels MUST NOT be > > used. A RID system can convert between A-labels and U-labels by > > using the Punycode encoding [RFC3492] for A-labels as described in > > the protocol specification for Internationalized Domain Names in > > Applications [RFC5891]. >=20 > Well, it's important to understand what you're signing up for when you > say that you want to use U-labels instead of A-labels. Please consider > the definition of U-label from RFC 5890: >=20 > o A "U-label" is an IDNA-valid string of Unicode characters, in > Normalization Form C (NFC) and including at least one non-ASCII > character, expressed in a standard Unicode Encoding Form (such as > UTF-8). It is also subject to the constraints about permitted > characters that are specified in Section 4.2 of the Protocol > document and the rules in the Sections 2 and 3 of the Tables > document, the Bidi constraints in that document if it contains any > character from scripts that are written right to left, and the > symmetry constraint described immediately below. Conversions > between U-labels and A-labels are performed according to the > "Punycode" specification [RFC3492], adding or removing the ACE > prefix as needed. >=20 > Notice what's entailed here... >=20 > 1. Unicode Normalization Form C (NFC): >=20 > http://www.unicode.org/reports/tr15/tr15-31.html >=20 > 2. Constraints on permitted characters from RFC 5891: >=20 > http://tools.ietf.org/html/rfc5891#section-4.2 >=20 > 3. The property rules from RFC 5892: >=20 > http://tools.ietf.org/html/rfc5892#section-2 > http://tools.ietf.org/html/rfc5892#section-3 >=20 > 4. The bidi constraints from RFC 5892, see also RFC 5893: >=20 > http://tools.ietf.org/html/rfc5893 >=20 > Do IODEF/RID implementations want to sign up for all that? >=20 > Furthermore, if we start accepting input strings then we might well need > to specify mappings of the kind that are explained in RFC 5895. Notice > the very helpful Section 3 in the latter specification: >=20 > If you are implementing a mapping for an application or operating > system by using exactly the four steps in Section 2, the authors of > this document have a request: please don't. We mean it. Section 2 > does not describe a universal mapping algorithm because, as we said, > there is no universally-applicable mapping algorithm. >=20 > If you read the material in Section 2 without reading Section 1, go > back and carefully read all of Section 1; in many ways, Section 1 is > more important than Section 2. Further, you can probably think of > user interface considerations that we did not list in Section 1. If > you did read Section 1 but somehow decided that the algorithm in > Section 2 is completely correct for the intended users of your > application or operating system, you are probably not thinking hard > enough about your intended users. >=20 > In short, there be dragons. >=20 > Your life will be simpler if you say "we might get some IDNs out of the > DNS or from somewhere else, and for our purposes we're going to assume > that they're all A-labels because we don't want to deal directly with > all that i18n madness, since it's just not a critical feature for RID > itself and we're just a consumer of DNS names". >=20 > Just my centigram of silver. :) >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From karen.reinhardt@rsa.com Wed Jan 25 00:00: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 9F17C21F865A for ; Wed, 25 Jan 2012 00:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 F8wJj7dYwTz9 for ; Wed, 25 Jan 2012 00:00:38 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7D27921F863F for ; Wed, 25 Jan 2012 00:00:37 -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 q0P80aH8011559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2012 03:00:37 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 25 Jan 2012 03:00:19 -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 q0P80Jqn006941 for ; Wed, 25 Jan 2012 03:00:19 -0500 Received: from mx16a.corp.emc.com ([169.254.1.202]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 25 Jan 2012 03:00:18 -0500 From: To: Date: Wed, 25 Jan 2012 03:00:13 -0500 Thread-Topic: Re: [mile] CN-ID vs DNS-ID for RID over HTTPS Thread-Index: AczbN15E5KlOtvnBRTeyOIkwut8nDQ== Message-ID: <3BF28BC7EFEEC6439F066FB2D164645211619556A5@MX16A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3BF28BC7EFEEC6439F066FB2D164645211619556A5MX16Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 26 Jan 2012 08:30:36 -0800 Subject: Re: [mile] CN-ID vs DNS-ID for RID over HTTPS 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, 25 Jan 2012 08:03:18 -0000 --_000_3BF28BC7EFEEC6439F066FB2D164645211619556A5MX16Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, I am a colleague of Kathleen Moriarty's and she asked that I comment on thi= s thread. As a practical matter, DNS-ID has been supported by most CAs for= a number of years now. If a CA system does not support the DNS-ID, I woul= d suggest that that CA be encouraged/forced to live up to the standard rath= er than perpetuate possible security weaknesses. Because of this, I believ= e that legacy support should not be extended. Regards, Karen Reinhardt Lead PKI Architect, Professional Services RSA, The Security Division of EMC (512)788-4333 --_000_3BF28BC7EFEEC6439F066FB2D164645211619556A5MX16Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,

 

I am a = colleague of Kathleen Moriarty’s and she asked that I comment on this= thread.  As a practical matter, DNS-ID has been supported by most CAs= for a number of years now.  If a CA system does not support the DNS-I= D, I would suggest that that CA be encouraged/forced to live up to the stan= dard rather than perpetuate possible security weaknesses.  Because of = this, I believe that legacy support should not be extended.

<= p class=3DMsoNormal> 

Regards,=

 

Ka= ren Reinhardt

Lead PKI Architect, Profes= sional Services

RSA, The Security Divisi= on of EMC

(512)788-4333

= --_000_3BF28BC7EFEEC6439F066FB2D164645211619556A5MX16Acorpemcc_-- From internet-drafts@ietf.org Thu Jan 26 09:25:02 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 EE19C21F8705; Thu, 26 Jan 2012 09:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 WegxqMFLeNIN; Thu, 26 Jan 2012 09:25:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7621F86DC; Thu, 26 Jan 2012 09:25:02 -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.64p1 Message-ID: <20120126172502.2574.38759.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2012 09:25:02 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-09.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, 26 Jan 2012 17:25:03 -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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-09.txt Pages : 84 Date : 2012-01-26 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-09.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-rfc6045-bis-09.txt From alexey.melnikov@isode.com Thu Jan 26 11:21:42 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 A47EF21F86D0 for ; Thu, 26 Jan 2012 11:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.614 X-Spam-Level: X-Spam-Status: No, score=-100.614 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_21=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=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 V9heevCqUW1b for ; Thu, 26 Jan 2012 11:21:41 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0687A21F86CF for ; Thu, 26 Jan 2012 11:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327605699; d=isode.com; s=selector; i=@isode.com; bh=UdcxV88AQDQ1dyor5vecvD8O16zXod/eT33yVGleMSE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=XphIxp4kXOefooyl7JqReA1J0p9mvf9S5m1p9Ogly/y0n+8J30MwgewGnrcphz2IEjshXX 7n/QpjDrm5rAURIx81k6MUiGvlQfc2lhDLbl8G0A96oXErF8CdtJWIRydZRkyHnyphszqZ c43cqRPgEY0tdsK58jYGMX+yMnAtVo4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 26 Jan 2012 19:21:34 +0000 Message-ID: <4F21A7B6.9030603@isode.com> Date: Thu, 26 Jan 2012 19:21:26 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Brian Trammell References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> In-Reply-To: <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 Jan 2012 11:24:13 -0800 Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 26 Jan 2012 19:21:42 -0000 On 25/01/2012 21:17, Brian Trammell wrote: > Hi, David, > > The reference identifier (defined in RFC 6215 section 1.8; explained in 6.2) in RID transport is (presumably) the identity one system uses to connect to another (see paragraph 12 of 6046-bis-08 section 3: "...the use of stable DNS names to address RID Systems is RECOMMENDED"). This could perhaps be made more explicit but it seemed obvious enough. > > For mutual authentication, this would have to be derived from a reverse mapping of the network address back to a name (either by DNS PTR records, or a whitelist of consortium members). David is correct that RFC 6125 can only be used by the entity that actively connect to another one (i.e. by the client to verify the server). If you find the burden of maintaining the reverse DNS mapping to be acceptable for your protocol (for deployments of some other protocols, like SMTP that burden was found to be unacceptable), then you can use RFC 6125 for verifying clients by servers. If you are not concerned about one RID member masquerading as another, it might be sufficient for your protocol to allow client certificates to come from a known CA (or a set of CAs), or be whitelisted. So basically you will use more relaxed verification rules from RFC 5280. > Perhaps stating "each RID system MUST maintain a DNS-ID reference identifier for those RID systems it participates in a consortium with, and use this for comparison with the DNS-ID stored in the certificate presented by RID system peers" would address this concern? > Regards, > > Brian > > On Jan 25, 2012, at 9:24 PM, wrote: > >> Hi Brian, >> >> Kathleen quickly disposed of #1, so please ignore that. She'll add some text to >> 6045-bis to help other readers avoid the mistake that I made. >> >> For #2, the short summary of my concern with the current text involves this sentence: >> >>> RID systems MUST verify the identity of their peers against that stored >>> in the certificate presented. >> How does a RID system (as TLS client or server) do that? >> >> The next sentence explains what the identity is, but not how to verify it: >> >>> All RID systems MUST be identified by a >>> certificate containing aDNS-ID identifier >>> as in section 6.4 of. >> In particular, section 6.4 of RFC 6125 doesn't specify what the certificate identity >> is checked against. It may even be that section 6.4 of RFC 6125 doesn't apply to >> client certificates, because the client identity check my be subsumed by PKIX path >> validation of the client certificate against the server's trust store, which does >> name comparison according to RFC 5280, not RFC 6125. >> >> A sentence or two on how to do that required (MUST) identity verification would help. >> >> Thanks, >> --David >> >> >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Wednesday, January 25, 2012 2:55 PM >>> To: Brian Trammell; Black, David >>> Cc: mile@ietf.org >>> Subject: RE: [mile] 6046-bis - Client certificate identity check >>> >>> Hi Brian, >>> >>> You can save your time on #1, the question/request was withdrawn. The sending RID server may only >>> appear within the IODEF document and not the RID XML document. >>> >>> Thank you, >>> Kathleen >>> >>> -----Original Message----- >>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>> Sent: Wednesday, January 25, 2012 2:51 PM >>> To: Black, David >>> Cc: Moriarty, Kathleen; mile@ietf.org >>> Subject: Re: [mile] 6046-bis - Client certificate identity check >>> >>> Hi, David, >>> >>> Thanks for the comments; I've been out of contact all day so am catching up. I'll top-post my summary >>> reply at first; I may have further detail replies in a subsequent message. >>> >>> 1. I would need to think more deeply about the implications of any authentication also cross-checking >>> the DNS-ID against not only network-layer available identifiers but also against information stored >>> within the RID document itself. There seems to be a bit of a chicken and egg problem there, and it >>> seems to me that there may be valid exceptions to a policy that would be simple enough to be (a) >>> implementable and (b) verifiable. >>> >>> 2. It is not the intent that 6125 section 4 applies solely to the authentication of the TLS server; >>> _all_ authentication in RID over HTTPS must be mutual, and I believe the current proposed text (copied >>> below straight from xml source) to be clear on this point, in context. If that's not the case, then >>> we'll need to change it. >>> >>> RID systems MUST use TLS version 1.1 or higher >>> for confidentiality, identification, and authentication, when sending RID >>> messages over HTTPS. HTTPS is specified in Section 2 of>> target="RFC2818"/>. RID systems MUST use mutual authentication; that is, >>> both RID systems acting as HTTPS clients and RID systems acting as HTTPS >>> servers MUST be identified by anX.509 >>> certificate. Mutual authentication requires full path validation on >>> each certificate, as defined in. >>> >>> The TLS session MUST use non-NULL ciphersuites for authentication, >>> integrity, and confidentiality. Sessions MAY be renegotiated within these >>> constraints. >>> >>> RID systems MUST verify the identity of their peers against that stored >>> in the certificate presented. All RID systems MUST be identified by a >>> certificate containing aDNS-ID identifier >>> as in section 6.4 of. The inclusion of Common >>> Names (CN-IDs) in certificates identifying RID systems is NOT RECOMMENDED. >>> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate >>> identifying a RID system. Additional general information on the use of PKI >>> with RID systems is detailed in Section 9.3 of>> target="I-D.ietf-mile-rfc6045-bis"/>. >>> >>> RID systems MUST support TLS version 1.1 and SHOULD support TLS version >>> 1.2; RID systems MUST NOT request, offer, or use >>> any version of SSL, or any version of TLS prior to 1.1, due to known >>> security vulnerabilities in prior versions of the protocol; see Appendix E >>> of for more. >>> >>> Best regards, >>> >>> Brian >>> >>> On Jan 25, 2012, at 8:00 PM, wrote: >>> >>>> Hi Kathleen, >>>> >>>> I missed the connection between Node and MsgDestination in 6045-bis - my mistake. >>>> >>>> It might be useful to repeat the following text from the specification of "MsgDestination" >>>> in the specification of the Node element in RIDPolicy, as those specifications are 5 >>>> pages apart, and the current specification of the Node element is not precise about >>>> usage: >>>> >>>> the meaning of the value >>>> in the Node element is determined by the MsgDestination element >>>> >>>> OTOH, I now don't see anything in RID that represents the identity of the system sending >>>> the RID message, and I don't think adding that is important enough to make a change at >>>> this juncture. I also don't see any point in trying to use the enveloped IODEF document >>>> to carry the identity of the sending RID system, as that document could get forwarded >>>> in a different RID message, for which it would contain the wrong sending RID system >>>> identity. >>>> >>>> If there's no instance of the sending RID system's identity in the RID message, then I >>>> suppose the client identity verification would have to be based on the information used >>>> to set up the trust relationships in the consortium. The 6046-bis draft already has a >>>> reference to the PKI discussion in 6045-bis. Would it make sense to clarify 6046-bis >>>> to indicate that RFC 6125 Section 6 applies only to server identity verification and the >>>> PKI material in 6045-bis applies to both server and client identity verification? >>>> >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Wednesday, January 25, 2012 1:21 PM >>>>> To: Black, David; mile@ietf.org >>>>> Subject: RE: 6046-bis - Client certificate identity check >>>>> >>>>> Hi David, >>>>> >>>>> Thank you for the comments. If text is added, it will need to be specific to the instance of Node >>> in >>>>> RID or IODEF. This would mean the CN would be used for this purpose (if UTF-8 names are OKed for >>> use >>>>> in RID NodeNames with the internationalization discussions). RID uses Node in two places and it >>> may >>>>> make more sense to reference the one in the IODEF document or change something in RID. >>>>> >>>>> Instances of where 'Node' appears: >>>>> 1) Node in SourceFound would not apply here. >>>>> >>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the receiving Node or the suspected >>>>> source of an incident if a traceback were in play. >>>>> >>>>> 3) This means the connection would need to be to the IODEF document and would require the document >>> to >>>>> be decrypted to verify if this were necessary. Or adding a Node instance specific to the sending >>> host >>>>> information. >>>>> >>>>> 4) If it were tied to IODEF, the use of Node in the System class is specific to the source and >>>>> destination addresses involved in an attack. The EventData where contact category is set to >>>>> "infrastructure" is the place where systems involved in communicating IODEF documents are listed. >>>>> This is the path information for incident data (lists all of the 'from' systems in RID >>>>> communications). >>>>> >>>>> Thanks, >>>>> Kathleen (as editor) >>>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of david.black@emc.com >>>>> Sent: Wednesday, January 25, 2012 12:39 PM >>>>> To: mile@ietf.org >>>>> Subject: [mile] 6046-bis - Client certificate identity check >>>>> >>>>> Brian and Kathleen, >>>>> >>>>> I think I found something in looking at the text related to the question about >>>>> certificate identities, but some more input would be useful. >>>>> >>>>> The 6046-bis-08 draft says: >>>>> >>>>> RID systems MUST verify the identity of their peers against that >>>>> stored in the certificate presented, as in section 6 of [RFC6125]. >>>>> >>>>> That covers verification of the identity of the receiving system (the identity >>>>> in the TLS server certificate has to match host component of URI for HTTP), but >>>>> I don't think it covers verification of the identity of the sending system, as >>>>> Section 6 of RFC 6125 concerns only service identity. >>>>> >>>>> I'd suggest adding some text that requires that the identity of the sending >>>>> system in the TLS client certificate match the NodeName in the Node element >>>>> of the RIDPolicy class if the NodeName is present. That "is present" complication >>>>> is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, because >>>>> RFC 5070 does not require that NodeName be present. >>>>> >>>>> I'm not sure what to do if NodeName is absent - a possible approach would be to >>>>> not go there, and instead add a requirement to 6045-bis that NodeName MUST be >>>>> present in the Node element of the RIDPolicy class in order to facilitate >>>>> this identity check. >>>>> >>>>> What do other people think? >>>>> >>>>> 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 >>>>> ---------------------------------------------------- >>>>> >>>>> _______________________________________________ >>>>> mile mailing 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 Thu Jan 26 11:34: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 EED7E21F86E2 for ; Thu, 26 Jan 2012 11:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.073 X-Spam-Level: X-Spam-Status: No, score=-8.073 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_21=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=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 tsOJj5wQrc8Z for ; Thu, 26 Jan 2012 11:34:20 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87921F8665 for ; Thu, 26 Jan 2012 11:34:19 -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 q0QJYGUU013759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 14:34:18 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 26 Jan 2012 14:34:01 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0QJY0Cr000427; Thu, 26 Jan 2012 14:34:00 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Thu, 26 Jan 2012 14:33:59 -0500 From: To: , Date: Thu, 26 Jan 2012 14:33:51 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczcX9dMQGDHjV8mT4Gm15DayJPiawAAJO4w Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> In-Reply-To: <4F21A7B6.9030603@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CBDU EDz8 H7e5 IAUl LP9x MUgb PUO7 QRlz QTD5 W3YX b1jK fxO9 kPGi oP7B rbns tYos; 5; YQBsAGUAeABlAHkALgBtAGUAbABuAGkAawBvAHYAQABpAHMAbwBkAGUALgBjAG8AbQA7AG0AaQBsAGUAQABpAGUAdABmAC4AbwByAGcAOwBzAHQAcABlAHQAZQByAEAAcwB0AHAAZQB0AGUAcgAuAGkAbQA7AHQAcgBhAG0AbQBlAGwAbABAAHQAaQBrAC4AZQBlAC4AZQB0AGgAegAuAGMAaAA7AHQAdQByAG4AZQByAHMAQABpAGUAYwBhAC4AYwBvAG0A; Sosha1_v1; 7; {D4BD61E1-4199-43D8-957B-D4D677FA0866}; awBhAHQAaABsAGUAZQBuAC4AbQBvAHIAaQBhAHIAdAB5AEAAZQBtAGMALgBjAG8AbQA=; Thu, 26 Jan 2012 19:33:51 GMT; UgBFADoAIABbAG0AaQBsAGUAXQAgADYAMAA0ADYALQBiAGkAcwAgAC0AIABDAGwAaQBlAG4AdAAgAGMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGkAZABlAG4AdABpAHQAeQAgAGMAaABlAGMAawA= x-cr-puzzleid: {D4BD61E1-4199-43D8-957B-D4D677FA0866} 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] 6046-bis - Client certificate identity check 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, 26 Jan 2012 19:34:22 -0000 Hello Alexy, If you look at the current version, the sentence that said the CA was trust= ed as opposed to having an association of a certificate to an entity, has b= een removed. That should no longer be a concern. Here is the text in RFC6= 046-bis in the current draft that is relevant: HTTPS is specified in Section 2 of [RFC2818]. RID systems MUST use mutual authentication; that is, both RID systems acting as HTTPS clients and RID systems acting as HTTPS servers MUST be identified by an X.509 certificate [RFC5280]. Mutual authentication requires full path validation on each certificate, as defined in [RFC5280]. I'll let Brian address the second question on stable DNS names. Thanks, Kathleen -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Thursday, January 26, 2012 2:21 PM To: Brian Trammell Cc: Black, David; Moriarty, Kathleen; Peter Saint-Andre; Sean Turner; mile@= ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check On 25/01/2012 21:17, Brian Trammell wrote: > Hi, David, > > The reference identifier (defined in RFC 6215 section 1.8; explained in 6= .2) in RID transport is (presumably) the identity one system uses to connec= t to another (see paragraph 12 of 6046-bis-08 section 3: "...the use of sta= ble DNS names to address RID Systems is RECOMMENDED"). This could perhaps b= e made more explicit but it seemed obvious enough. > > For mutual authentication, this would have to be derived from a reverse m= apping of the network address back to a name (either by DNS PTR records, or= a whitelist of consortium members). David is correct that RFC 6125 can only be used by the entity that=20 actively connect to another one (i.e. by the client to verify the server). If you find the burden of maintaining the reverse DNS mapping to be=20 acceptable for your protocol (for deployments of some other protocols,=20 like SMTP that burden was found to be unacceptable), then you can use=20 RFC 6125 for verifying clients by servers. If you are not concerned about one RID member masquerading as another,=20 it might be sufficient for your protocol to allow client certificates to=20 come from a known CA (or a set of CAs), or be whitelisted. So basically=20 you will use more relaxed verification rules from RFC 5280. > Perhaps stating "each RID system MUST maintain a DNS-ID reference identif= ier for those RID systems it participates in a consortium with, and use thi= s for comparison with the DNS-ID stored in the certificate presented by RID= system peers" would address this concern? > Regards, > > Brian > > On Jan 25, 2012, at 9:24 PM, = wrote: > >> Hi Brian, >> >> Kathleen quickly disposed of #1, so please ignore that. She'll add some= text to >> 6045-bis to help other readers avoid the mistake that I made. >> >> For #2, the short summary of my concern with the current text involves t= his sentence: >> >>> RID systems MUST verify the identity of their peers against that= stored >>> in the certificate presented. >> How does a RID system (as TLS client or server) do that? >> >> The next sentence explains what the identity is, but not how to verify i= t: >> >>> All RID systems MUST be identified by a >>> certificate containing aDNS-ID identifier<= /xref> >>> as in section 6.4 of. >> In particular, section 6.4 of RFC 6125 doesn't specify what the certific= ate identity >> is checked against. It may even be that section 6.4 of RFC 6125 doesn't= apply to >> client certificates, because the client identity check my be subsumed by= PKIX path >> validation of the client certificate against the server's trust store, w= hich does >> name comparison according to RFC 5280, not RFC 6125. >> >> A sentence or two on how to do that required (MUST) identity verificatio= n would help. >> >> Thanks, >> --David >> >> >>> -----Original Message----- >>> From: Moriarty, Kathleen >>> Sent: Wednesday, January 25, 2012 2:55 PM >>> To: Brian Trammell; Black, David >>> Cc: mile@ietf.org >>> Subject: RE: [mile] 6046-bis - Client certificate identity check >>> >>> Hi Brian, >>> >>> You can save your time on #1, the question/request was withdrawn. The = sending RID server may only >>> appear within the IODEF document and not the RID XML document. >>> >>> Thank you, >>> Kathleen >>> >>> -----Original Message----- >>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>> Sent: Wednesday, January 25, 2012 2:51 PM >>> To: Black, David >>> Cc: Moriarty, Kathleen; mile@ietf.org >>> Subject: Re: [mile] 6046-bis - Client certificate identity check >>> >>> Hi, David, >>> >>> Thanks for the comments; I've been out of contact all day so am catchin= g up. I'll top-post my summary >>> reply at first; I may have further detail replies in a subsequent messa= ge. >>> >>> 1. I would need to think more deeply about the implications of any auth= entication also cross-checking >>> the DNS-ID against not only network-layer available identifiers but als= o against information stored >>> within the RID document itself. There seems to be a bit of a chicken an= d egg problem there, and it >>> seems to me that there may be valid exceptions to a policy that would b= e simple enough to be (a) >>> implementable and (b) verifiable. >>> >>> 2. It is not the intent that 6125 section 4 applies solely to the authe= ntication of the TLS server; >>> _all_ authentication in RID over HTTPS must be mutual, and I believe th= e current proposed text (copied >>> below straight from xml source) to be clear on this point, in context. = If that's not the case, then >>> we'll need to change it. >>> >>> RID systems MUST use TLS version 1.1 = or higher >>> for confidentiality, identification, and authentication, when sendi= ng RID >>> messages over HTTPS. HTTPS is specified in Section 2 of>> target=3D"RFC2818"/>. RID systems MUST use mutual authentication; t= hat is, >>> both RID systems acting as HTTPS clients and RID systems acting as = HTTPS >>> servers MUST be identified by anX.509 >>> certificate. Mutual authentication requires full path valida= tion on >>> each certificate, as defined in. >>> >>> The TLS session MUST use non-NULL ciphersuites for authenticatio= n, >>> integrity, and confidentiality. Sessions MAY be renegotiated within= these >>> constraints. >>> >>> RID systems MUST verify the identity of their peers against that= stored >>> in the certificate presented. All RID systems MUST be identified by= a >>> certificate containing aDNS-ID identifier<= /xref> >>> as in section 6.4 of. The inclusion of Co= mmon >>> Names (CN-IDs) in certificates identifying RID systems is NOT RECOM= MENDED. >>> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate >>> identifying a RID system. Additional general information on the use= of PKI >>> with RID systems is detailed in Section 9.3 of>> target=3D"I-D.ietf-mile-rfc6045-bis"/>. >>> >>> RID systems MUST support TLS version 1.1 and SHOULD support TLS = version >>> 1.2; RID systems MUST NOT request, offer,= or use >>> any version of SSL, or any version of TLS prior to 1.1, due to know= n >>> security vulnerabilities in prior versions of the protocol; see App= endix E >>> of for more. >>> >>> Best regards, >>> >>> Brian >>> >>> On Jan 25, 2012, at 8:00 PM, wrote: >>> >>>> Hi Kathleen, >>>> >>>> I missed the connection between Node and MsgDestination in 6045-bis - = my mistake. >>>> >>>> It might be useful to repeat the following text from the specification= of "MsgDestination" >>>> in the specification of the Node element in RIDPolicy, as those specif= ications are 5 >>>> pages apart, and the current specification of the Node element is not = precise about >>>> usage: >>>> >>>> the meaning of the value >>>> in the Node element is determined by the MsgDestination elemen= t >>>> >>>> OTOH, I now don't see anything in RID that represents the identity of = the system sending >>>> the RID message, and I don't think adding that is important enough to = make a change at >>>> this juncture. I also don't see any point in trying to use the envelo= ped IODEF document >>>> to carry the identity of the sending RID system, as that document coul= d get forwarded >>>> in a different RID message, for which it would contain the wrong sendi= ng RID system >>>> identity. >>>> >>>> If there's no instance of the sending RID system's identity in the RID= message, then I >>>> suppose the client identity verification would have to be based on the= information used >>>> to set up the trust relationships in the consortium. The 6046-bis dra= ft already has a >>>> reference to the PKI discussion in 6045-bis. Would it make sense to cl= arify 6046-bis >>>> to indicate that RFC 6125 Section 6 applies only to server identity ve= rification and the >>>> PKI material in 6045-bis applies to both server and client identity ve= rification? >>>> >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Wednesday, January 25, 2012 1:21 PM >>>>> To: Black, David; mile@ietf.org >>>>> Subject: RE: 6046-bis - Client certificate identity check >>>>> >>>>> Hi David, >>>>> >>>>> Thank you for the comments. If text is added, it will need to be spe= cific to the instance of Node >>> in >>>>> RID or IODEF. This would mean the CN would be used for this purpose = (if UTF-8 names are OKed for >>> use >>>>> in RID NodeNames with the internationalization discussions). RID use= s Node in two places and it >>> may >>>>> make more sense to reference the one in the IODEF document or change = something in RID. >>>>> >>>>> Instances of where 'Node' appears: >>>>> 1) Node in SourceFound would not apply here. >>>>> >>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the r= eceiving Node or the suspected >>>>> source of an incident if a traceback were in play. >>>>> >>>>> 3) This means the connection would need to be to the IODEF document a= nd would require the document >>> to >>>>> be decrypted to verify if this were necessary. Or adding a Node inst= ance specific to the sending >>> host >>>>> information. >>>>> >>>>> 4) If it were tied to IODEF, the use of Node in the System class is s= pecific to the source and >>>>> destination addresses involved in an attack. The EventData where cont= act category is set to >>>>> "infrastructure" is the place where systems involved in communicating= IODEF documents are listed. >>>>> This is the path information for incident data (lists all of the 'fro= m' systems in RID >>>>> communications). >>>>> >>>>> Thanks, >>>>> Kathleen (as editor) >>>>> >>>>> -----Original Message----- >>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of david.black@emc.com >>>>> Sent: Wednesday, January 25, 2012 12:39 PM >>>>> To: mile@ietf.org >>>>> Subject: [mile] 6046-bis - Client certificate identity check >>>>> >>>>> Brian and Kathleen, >>>>> >>>>> I think I found something in looking at the text related to the quest= ion about >>>>> certificate identities, but some more input would be useful. >>>>> >>>>> The 6046-bis-08 draft says: >>>>> >>>>> RID systems MUST verify the identity of their peers against that >>>>> stored in the certificate presented, as in section 6 of [RFC6125]. >>>>> >>>>> That covers verification of the identity of the receiving system (the= identity >>>>> in the TLS server certificate has to match host component of URI for = HTTP), but >>>>> I don't think it covers verification of the identity of the sending s= ystem, as >>>>> Section 6 of RFC 6125 concerns only service identity. >>>>> >>>>> I'd suggest adding some text that requires that the identity of the s= ending >>>>> system in the TLS client certificate match the NodeName in the Node e= lement >>>>> of the RIDPolicy class if the NodeName is present. That "is present" = complication >>>>> is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, b= ecause >>>>> RFC 5070 does not require that NodeName be present. >>>>> >>>>> I'm not sure what to do if NodeName is absent - a possible approach w= ould be to >>>>> not go there, and instead add a requirement to 6045-bis that NodeName= MUST be >>>>> present in the Node element of the RIDPolicy class in order to facili= tate >>>>> this identity check. >>>>> >>>>> What do other people think? >>>>> >>>>> 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 >>>>> ---------------------------------------------------- >>>>> >>>>> _______________________________________________ >>>>> mile mailing 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 stpeter@stpeter.im Thu Jan 26 11:34:24 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 A189F21F86FD for ; Thu, 26 Jan 2012 11:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.045 X-Spam-Level: X-Spam-Status: No, score=-101.045 tagged_above=-999 required=5 tests=[AWL=-1.646, BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_21=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=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 S0o5g9POTEay for ; Thu, 26 Jan 2012 11:34:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 788DE21F86F4 for ; Thu, 26 Jan 2012 11:34:23 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8168F40058; Thu, 26 Jan 2012 12:44:11 -0700 (MST) Message-ID: <4F21AABD.9060603@stpeter.im> Date: Thu, 26 Jan 2012 12:34:21 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> In-Reply-To: <4F21A7B6.9030603@isode.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 26 Jan 2012 19:34:24 -0000 On 1/26/12 12:21 PM, Alexey Melnikov wrote: > On 25/01/2012 21:17, Brian Trammell wrote: >> Hi, David, >> >> The reference identifier (defined in RFC 6215 section 1.8; explained >> in 6.2) in RID transport is (presumably) the identity one system uses >> to connect to another (see paragraph 12 of 6046-bis-08 section 3: >> "...the use of stable DNS names to address RID Systems is >> RECOMMENDED"). This could perhaps be made more explicit but it seemed >> obvious enough. >> >> For mutual authentication, this would have to be derived from a >> reverse mapping of the network address back to a name (either by DNS >> PTR records, or a whitelist of consortium members). > David is correct that RFC 6125 can only be used by the entity that > actively connect to another one (i.e. by the client to verify the server). English nit: s/i.e./e.g./ (because it can be used by one server connecting to another server, as we're sort of doing here). > If you find the burden of maintaining the reverse DNS mapping to be > acceptable for your protocol (for deployments of some other protocols, > like SMTP that burden was found to be unacceptable), then you can use > RFC 6125 for verifying clients by servers. My sense is that in RID consortia, this is seen as an acceptable burden because the number of members in each consortium is manageable. But that's something that RID participants probably need to verify. > If you are not concerned about one RID member masquerading as another, > it might be sufficient for your protocol to allow client certificates to > come from a known CA (or a set of CAs), or be whitelisted. So basically > you will use more relaxed verification rules from RFC 5280. Well, I think you'd probably still want to do the domain check, no? >> Perhaps stating "each RID system MUST maintain a DNS-ID reference >> identifier for those RID systems it participates in a consortium with, >> and use this for comparison with the DNS-ID stored in the certificate >> presented by RID system peers" would address this concern? > >> Regards, >> >> Brian >> >> On Jan 25, 2012, at 9:24 PM, >> wrote: >> >>> Hi Brian, >>> >>> Kathleen quickly disposed of #1, so please ignore that. She'll add >>> some text to >>> 6045-bis to help other readers avoid the mistake that I made. >>> >>> For #2, the short summary of my concern with the current text >>> involves this sentence: >>> >>>> RID systems MUST verify the identity of their peers against >>>> that stored >>>> in the certificate presented. >>> How does a RID system (as TLS client or server) do that? >>> >>> The next sentence explains what the identity is, but not how to >>> verify it: >>> >>>> All RID systems MUST be identified by a >>>> certificate containing aDNS-ID >>>> identifier >>>> as in section 6.4 of. >>> In particular, section 6.4 of RFC 6125 doesn't specify what the >>> certificate identity >>> is checked against. It may even be that section 6.4 of RFC 6125 >>> doesn't apply to >>> client certificates, because the client identity check my be subsumed >>> by PKIX path >>> validation of the client certificate against the server's trust >>> store, which does >>> name comparison according to RFC 5280, not RFC 6125. >>> >>> A sentence or two on how to do that required (MUST) identity >>> verification would help. >>> >>> Thanks, >>> --David >>> >>> >>>> -----Original Message----- >>>> From: Moriarty, Kathleen >>>> Sent: Wednesday, January 25, 2012 2:55 PM >>>> To: Brian Trammell; Black, David >>>> Cc: mile@ietf.org >>>> Subject: RE: [mile] 6046-bis - Client certificate identity check >>>> >>>> Hi Brian, >>>> >>>> You can save your time on #1, the question/request was withdrawn. >>>> The sending RID server may only >>>> appear within the IODEF document and not the RID XML document. >>>> >>>> Thank you, >>>> Kathleen >>>> >>>> -----Original Message----- >>>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>>> Sent: Wednesday, January 25, 2012 2:51 PM >>>> To: Black, David >>>> Cc: Moriarty, Kathleen; mile@ietf.org >>>> Subject: Re: [mile] 6046-bis - Client certificate identity check >>>> >>>> Hi, David, >>>> >>>> Thanks for the comments; I've been out of contact all day so am >>>> catching up. I'll top-post my summary >>>> reply at first; I may have further detail replies in a subsequent >>>> message. >>>> >>>> 1. I would need to think more deeply about the implications of any >>>> authentication also cross-checking >>>> the DNS-ID against not only network-layer available identifiers but >>>> also against information stored >>>> within the RID document itself. There seems to be a bit of a chicken >>>> and egg problem there, and it >>>> seems to me that there may be valid exceptions to a policy that >>>> would be simple enough to be (a) >>>> implementable and (b) verifiable. >>>> >>>> 2. It is not the intent that 6125 section 4 applies solely to the >>>> authentication of the TLS server; >>>> _all_ authentication in RID over HTTPS must be mutual, and I believe >>>> the current proposed text (copied >>>> below straight from xml source) to be clear on this point, in >>>> context. If that's not the case, then >>>> we'll need to change it. >>>> >>>> RID systems MUST use TLS version 1.1 >>>> or higher >>>> for confidentiality, identification, and authentication, when >>>> sending RID >>>> messages over HTTPS. HTTPS is specified in Section 2 of>>> target="RFC2818"/>. RID systems MUST use mutual authentication; >>>> that is, >>>> both RID systems acting as HTTPS clients and RID systems acting >>>> as HTTPS >>>> servers MUST be identified by anX.509 >>>> certificate. Mutual authentication requires full path >>>> validation on >>>> each certificate, as defined in. >>>> >>>> The TLS session MUST use non-NULL ciphersuites for >>>> authentication, >>>> integrity, and confidentiality. Sessions MAY be renegotiated >>>> within these >>>> constraints. >>>> >>>> RID systems MUST verify the identity of their peers against >>>> that stored >>>> in the certificate presented. All RID systems MUST be identified >>>> by a >>>> certificate containing aDNS-ID >>>> identifier >>>> as in section 6.4 of. The inclusion of >>>> Common >>>> Names (CN-IDs) in certificates identifying RID systems is NOT >>>> RECOMMENDED. >>>> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate >>>> identifying a RID system. Additional general information on the >>>> use of PKI >>>> with RID systems is detailed in Section 9.3 of>>> target="I-D.ietf-mile-rfc6045-bis"/>. >>>> >>>> RID systems MUST support TLS version 1.1 and SHOULD support >>>> TLS version >>>> 1.2; RID systems MUST NOT request, >>>> offer, or use >>>> any version of SSL, or any version of TLS prior to 1.1, due to >>>> known >>>> security vulnerabilities in prior versions of the protocol; see >>>> Appendix E >>>> of for more. >>>> >>>> Best regards, >>>> >>>> Brian >>>> >>>> On Jan 25, 2012, at 8:00 PM, wrote: >>>> >>>>> Hi Kathleen, >>>>> >>>>> I missed the connection between Node and MsgDestination in 6045-bis >>>>> - my mistake. >>>>> >>>>> It might be useful to repeat the following text from the >>>>> specification of "MsgDestination" >>>>> in the specification of the Node element in RIDPolicy, as those >>>>> specifications are 5 >>>>> pages apart, and the current specification of the Node element is >>>>> not precise about >>>>> usage: >>>>> >>>>> the meaning of the value >>>>> in the Node element is determined by the MsgDestination >>>>> element >>>>> >>>>> OTOH, I now don't see anything in RID that represents the identity >>>>> of the system sending >>>>> the RID message, and I don't think adding that is important enough >>>>> to make a change at >>>>> this juncture. I also don't see any point in trying to use the >>>>> enveloped IODEF document >>>>> to carry the identity of the sending RID system, as that document >>>>> could get forwarded >>>>> in a different RID message, for which it would contain the wrong >>>>> sending RID system >>>>> identity. >>>>> >>>>> If there's no instance of the sending RID system's identity in the >>>>> RID message, then I >>>>> suppose the client identity verification would have to be based on >>>>> the information used >>>>> to set up the trust relationships in the consortium. The 6046-bis >>>>> draft already has a >>>>> reference to the PKI discussion in 6045-bis. Would it make sense to >>>>> clarify 6046-bis >>>>> to indicate that RFC 6125 Section 6 applies only to server identity >>>>> verification and the >>>>> PKI material in 6045-bis applies to both server and client identity >>>>> verification? >>>>> >>>>> Thanks, >>>>> --David >>>>> >>>>>> -----Original Message----- >>>>>> From: Moriarty, Kathleen >>>>>> Sent: Wednesday, January 25, 2012 1:21 PM >>>>>> To: Black, David; mile@ietf.org >>>>>> Subject: RE: 6046-bis - Client certificate identity check >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thank you for the comments. If text is added, it will need to be >>>>>> specific to the instance of Node >>>> in >>>>>> RID or IODEF. This would mean the CN would be used for this >>>>>> purpose (if UTF-8 names are OKed for >>>> use >>>>>> in RID NodeNames with the internationalization discussions). RID >>>>>> uses Node in two places and it >>>> may >>>>>> make more sense to reference the one in the IODEF document or >>>>>> change something in RID. >>>>>> >>>>>> Instances of where 'Node' appears: >>>>>> 1) Node in SourceFound would not apply here. >>>>>> >>>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would be >>>>>> the receiving Node or the suspected >>>>>> source of an incident if a traceback were in play. >>>>>> >>>>>> 3) This means the connection would need to be to the IODEF >>>>>> document and would require the document >>>> to >>>>>> be decrypted to verify if this were necessary. Or adding a Node >>>>>> instance specific to the sending >>>> host >>>>>> information. >>>>>> >>>>>> 4) If it were tied to IODEF, the use of Node in the System class >>>>>> is specific to the source and >>>>>> destination addresses involved in an attack. The EventData where >>>>>> contact category is set to >>>>>> "infrastructure" is the place where systems involved in >>>>>> communicating IODEF documents are listed. >>>>>> This is the path information for incident data (lists all of the >>>>>> 'from' systems in RID >>>>>> communications). >>>>>> >>>>>> Thanks, >>>>>> Kathleen (as editor) >>>>>> >>>>>> -----Original Message----- >>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>>> Behalf Of david.black@emc.com >>>>>> Sent: Wednesday, January 25, 2012 12:39 PM >>>>>> To: mile@ietf.org >>>>>> Subject: [mile] 6046-bis - Client certificate identity check >>>>>> >>>>>> Brian and Kathleen, >>>>>> >>>>>> I think I found something in looking at the text related to the >>>>>> question about >>>>>> certificate identities, but some more input would be useful. >>>>>> >>>>>> The 6046-bis-08 draft says: >>>>>> >>>>>> RID systems MUST verify the identity of their peers against that >>>>>> stored in the certificate presented, as in section 6 of [RFC6125]. >>>>>> >>>>>> That covers verification of the identity of the receiving system >>>>>> (the identity >>>>>> in the TLS server certificate has to match host component of URI >>>>>> for HTTP), but >>>>>> I don't think it covers verification of the identity of the >>>>>> sending system, as >>>>>> Section 6 of RFC 6125 concerns only service identity. >>>>>> >>>>>> I'd suggest adding some text that requires that the identity of >>>>>> the sending >>>>>> system in the TLS client certificate match the NodeName in the >>>>>> Node element >>>>>> of the RIDPolicy class if the NodeName is present. That "is >>>>>> present" complication >>>>>> is courtesy of 6045-bis reusing the IODEF Node class from RFC >>>>>> 5070, because >>>>>> RFC 5070 does not require that NodeName be present. >>>>>> >>>>>> I'm not sure what to do if NodeName is absent - a possible >>>>>> approach would be to >>>>>> not go there, and instead add a requirement to 6045-bis that >>>>>> NodeName MUST be >>>>>> present in the Node element of the RIDPolicy class in order to >>>>>> facilitate >>>>>> this identity check. >>>>>> >>>>>> What do other people think? >>>>>> >>>>>> 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 >>>>>> ---------------------------------------------------- >>>>>> >>>>>> _______________________________________________ >>>>>> mile mailing list >>>>>> mile@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>> _______________________________________________ >>>>> mile mailing list >>>>> mile@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mile > -- Peter Saint-Andre https://stpeter.im/ From kathleen.moriarty@emc.com Thu Jan 26 11:42:01 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 D634521F8636 for ; Thu, 26 Jan 2012 11:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.061 X-Spam-Level: X-Spam-Status: No, score=-8.061 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_21=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=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 Goh0OsCq6uZe for ; Thu, 26 Jan 2012 11:42:00 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 430E121F8630 for ; Thu, 26 Jan 2012 11:42:00 -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 q0QJfwkZ001548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 14:41:58 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 26 Jan 2012 14:41:38 -0500 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0QJfbvZ001968; Thu, 26 Jan 2012 14:41:38 -0500 Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub36.corp.emc.com (10.254.93.84) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jan 2012 14:41:37 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Thu, 26 Jan 2012 14:41:37 -0500 From: To: , Date: Thu, 26 Jan 2012 14:41:28 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczcYaN1qyZ+5qbaRruAljWlnr4SsAAADP8A Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> In-Reply-To: <4F21AABD.9060603@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BQiG EHTa L6g2 QDOq QwrV WqvA hSFY ijif k59a mDUm oPER sTd3 t/QH wslG zTJ+ 1SGx; 5; YQBsAGUAeABlAHkALgBtAGUAbABuAGkAawBvAHYAQABpAHMAbwBkAGUALgBjAG8AbQA7AG0AaQBsAGUAQABpAGUAdABmAC4AbwByAGcAOwBzAHQAcABlAHQAZQByAEAAcwB0AHAAZQB0AGUAcgAuAGkAbQA7AHQAcgBhAG0AbQBlAGwAbABAAHQAaQBrAC4AZQBlAC4AZQB0AGgAegAuAGMAaAA7AHQAdQByAG4AZQByAHMAQABpAGUAYwBhAC4AYwBvAG0A; Sosha1_v1; 7; {5A8F17D3-98DA-4BB0-A757-20742CBB5AE0}; awBhAHQAaABsAGUAZQBuAC4AbQBvAHIAaQBhAHIAdAB5AEAAZQBtAGMALgBjAG8AbQA=; Thu, 26 Jan 2012 19:41:28 GMT; UgBFADoAIABbAG0AaQBsAGUAXQAgADYAMAA0ADYALQBiAGkAcwAgAC0AIABDAGwAaQBlAG4AdAAgAGMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGkAZABlAG4AdABpAHQAeQAgAGMAaABlAGMAawA= x-cr-puzzleid: {5A8F17D3-98DA-4BB0-A757-20742CBB5AE0} acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 26 Jan 2012 19:42:02 -0000 SSdsbCBsZWF2ZSB0aGUgcmVzdCB0byBCcmlhbiwgYnV0IGNvbmZpcm0gdGhlIGNvbnNvcnRpdW0g ZXhwZWN0YXRpb25zOg0KDQpJbiB0ZXJtcyBvZiBpbmNpZGVudCBzaGFyaW5nIGdyb3Vwcywgcmln aHQgbm93IHRoZXkgYXJlIGVpdGhlciBpbmR1c3RyeSBiYXNlZCBvciBzbWFsbCBncm91cHMuICBQ ZW9wbGUgd2FudCB0byBzaGFyZSB3aXRoIHBlb3BsZSB0aGF0IHRoZXkga25vdyBhbmQgaGVuY2Ug dGhpbmsgdGhleSBjYW4gdHJ1c3QuICBUaGUgQWR2YW5jZWQgQ3liZXIgU2VjdXJpdHkgQ2VudGVy IChBQ1NDKSBpcyBhbiBleGFtcGxlIGluIE5ldyBFbmdsYW5kIHRoYXQgaXMgY3Jvc3MgaW5kdXN0 cnkuICBUaGV5IGFyZSBzZXR0aW5nIGEgbW9kZWwgdGhhdCBvdGhlcnMgYXJlIHN0YXJ0aW5nIHRv IGZvbGxvdyB3aGVyZSBtZW1iZXJzaGlwIGlzIGxpbWl0ZWQgdG8gMzAgb3JnYW5pemF0aW9ucyBh bmQgdGhleSBtZWV0IHJlZ3VsYXJseSBpbiBwZXJzb24gKGluIGFkZGl0aW9uIHRvIGFueSBvbmxp bmUgc2hhcmluZykuICBUaGlzIGdyb3VwIHBsYW5zIHRvIHBlZXIgd2l0aCBvdGhlciBncm91cHMg YW5kIHRoZSBzaGFyaW5nIGFycmFuZ2VtZW50cyBjb3VsZCB2YXJ5IHdpdGhpbiB0aGUgY29uc29y dGl1bSBvciBiZXR3ZWVuIG90aGVyIGNvbnNvcnRpdW1zLiAgVGhlIGNvbnNvcnRpdW1zIHdvcmsg b3V0IGRldGFpbGVkIGFncmVlbWVudHMsIHNvIG1haW50YWluaW5nIHRoaXMgdHlwZSBvZiBpbmZv cm1hdGlvbiByZWFsbHkgc2hvdWxkIG5vdCBiZSBhbiBpc3N1ZSBpbiB0aG9zZSBtb2RlbHMuDQoN ClRoYW5rcywNCkthdGhsZWVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQ ZXRlciBTYWludC1BbmRyZSBbbWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0NClNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDI2LCAyMDEyIDI6MzQgUE0NClRvOiBBbGV4ZXkgTWVsbmlrb3YNCkNjOiBC cmlhbiBUcmFtbWVsbDsgQmxhY2ssIERhdmlkOyBNb3JpYXJ0eSwgS2F0aGxlZW47IFNlYW4gVHVy bmVyOyBtaWxlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21pbGVdIDYwNDYtYmlzIC0gQ2xpZW50 IGNlcnRpZmljYXRlIGlkZW50aXR5IGNoZWNrDQoNCk9uIDEvMjYvMTIgMTI6MjEgUE0sIEFsZXhl eSBNZWxuaWtvdiB3cm90ZToNCj4gT24gMjUvMDEvMjAxMiAyMToxNywgQnJpYW4gVHJhbW1lbGwg d3JvdGU6DQo+PiBIaSwgRGF2aWQsDQo+Pg0KPj4gVGhlIHJlZmVyZW5jZSBpZGVudGlmaWVyIChk ZWZpbmVkIGluIFJGQyA2MjE1IHNlY3Rpb24gMS44OyBleHBsYWluZWQNCj4+IGluIDYuMikgaW4g UklEIHRyYW5zcG9ydCBpcyAocHJlc3VtYWJseSkgdGhlIGlkZW50aXR5IG9uZSBzeXN0ZW0gdXNl cw0KPj4gdG8gY29ubmVjdCB0byBhbm90aGVyIChzZWUgcGFyYWdyYXBoIDEyIG9mIDYwNDYtYmlz LTA4IHNlY3Rpb24gMzoNCj4+ICIuLi50aGUgdXNlIG9mIHN0YWJsZSBETlMgbmFtZXMgdG8gYWRk cmVzcyBSSUQgU3lzdGVtcyBpcw0KPj4gUkVDT01NRU5ERUQiKS4gVGhpcyBjb3VsZCBwZXJoYXBz IGJlIG1hZGUgbW9yZSBleHBsaWNpdCBidXQgaXQgc2VlbWVkDQo+PiBvYnZpb3VzIGVub3VnaC4N Cj4+DQo+PiBGb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCB0aGlzIHdvdWxkIGhhdmUgdG8gYmUg ZGVyaXZlZCBmcm9tIGENCj4+IHJldmVyc2UgbWFwcGluZyBvZiB0aGUgbmV0d29yayBhZGRyZXNz IGJhY2sgdG8gYSBuYW1lIChlaXRoZXIgYnkgRE5TDQo+PiBQVFIgcmVjb3Jkcywgb3IgYSB3aGl0 ZWxpc3Qgb2YgY29uc29ydGl1bSBtZW1iZXJzKS4NCj4gRGF2aWQgaXMgY29ycmVjdCB0aGF0IFJG QyA2MTI1IGNhbiBvbmx5IGJlIHVzZWQgYnkgdGhlIGVudGl0eSB0aGF0DQo+IGFjdGl2ZWx5IGNv bm5lY3QgdG8gYW5vdGhlciBvbmUgKGkuZS4gYnkgdGhlIGNsaWVudCB0byB2ZXJpZnkgdGhlIHNl cnZlcikuDQoNCkVuZ2xpc2ggbml0OiBzL2kuZS4vZS5nLi8gKGJlY2F1c2UgaXQgY2FuIGJlIHVz ZWQgYnkgb25lIHNlcnZlcg0KY29ubmVjdGluZyB0byBhbm90aGVyIHNlcnZlciwgYXMgd2UncmUg c29ydCBvZiBkb2luZyBoZXJlKS4NCg0KPiBJZiB5b3UgZmluZCB0aGUgYnVyZGVuIG9mIG1haW50 YWluaW5nIHRoZSByZXZlcnNlIEROUyBtYXBwaW5nIHRvIGJlDQo+IGFjY2VwdGFibGUgZm9yIHlv dXIgcHJvdG9jb2wgKGZvciBkZXBsb3ltZW50cyBvZiBzb21lIG90aGVyIHByb3RvY29scywNCj4g bGlrZSBTTVRQIHRoYXQgYnVyZGVuIHdhcyBmb3VuZCB0byBiZSB1bmFjY2VwdGFibGUpLCB0aGVu IHlvdSBjYW4gdXNlDQo+IFJGQyA2MTI1IGZvciB2ZXJpZnlpbmcgY2xpZW50cyBieSBzZXJ2ZXJz Lg0KDQpNeSBzZW5zZSBpcyB0aGF0IGluIFJJRCBjb25zb3J0aWEsIHRoaXMgaXMgc2VlbiBhcyBh biBhY2NlcHRhYmxlIGJ1cmRlbg0KYmVjYXVzZSB0aGUgbnVtYmVyIG9mIG1lbWJlcnMgaW4gZWFj aCBjb25zb3J0aXVtIGlzIG1hbmFnZWFibGUuIEJ1dA0KdGhhdCdzIHNvbWV0aGluZyB0aGF0IFJJ RCBwYXJ0aWNpcGFudHMgcHJvYmFibHkgbmVlZCB0byB2ZXJpZnkuDQoNCj4gSWYgeW91IGFyZSBu b3QgY29uY2VybmVkIGFib3V0IG9uZSBSSUQgbWVtYmVyIG1hc3F1ZXJhZGluZyBhcyBhbm90aGVy LA0KPiBpdCBtaWdodCBiZSBzdWZmaWNpZW50IGZvciB5b3VyIHByb3RvY29sIHRvIGFsbG93IGNs aWVudCBjZXJ0aWZpY2F0ZXMgdG8NCj4gY29tZSBmcm9tIGEga25vd24gQ0EgKG9yIGEgc2V0IG9m IENBcyksIG9yIGJlIHdoaXRlbGlzdGVkLiAgU28gYmFzaWNhbGx5DQo+IHlvdSB3aWxsIHVzZSBt b3JlIHJlbGF4ZWQgdmVyaWZpY2F0aW9uIHJ1bGVzIGZyb20gUkZDIDUyODAuDQoNCldlbGwsIEkg dGhpbmsgeW91J2QgcHJvYmFibHkgc3RpbGwgd2FudCB0byBkbyB0aGUgZG9tYWluIGNoZWNrLCBu bz8NCg0KPj4gUGVyaGFwcyBzdGF0aW5nICJlYWNoIFJJRCBzeXN0ZW0gTVVTVCBtYWludGFpbiBh IEROUy1JRCByZWZlcmVuY2UNCj4+IGlkZW50aWZpZXIgZm9yIHRob3NlIFJJRCBzeXN0ZW1zIGl0 IHBhcnRpY2lwYXRlcyBpbiBhIGNvbnNvcnRpdW0gd2l0aCwNCj4+IGFuZCB1c2UgdGhpcyBmb3Ig Y29tcGFyaXNvbiB3aXRoIHRoZSBETlMtSUQgc3RvcmVkIGluIHRoZSBjZXJ0aWZpY2F0ZQ0KPj4g cHJlc2VudGVkIGJ5IFJJRCBzeXN0ZW0gcGVlcnMiIHdvdWxkIGFkZHJlc3MgdGhpcyBjb25jZXJu Pw0KPg0KPj4gUmVnYXJkcywNCj4+DQo+PiBCcmlhbg0KPj4NCj4+IE9uIEphbiAyNSwgMjAxMiwg YXQgOToyNCBQTSw8ZGF2aWQuYmxhY2tAZW1jLmNvbT4NCj4+IDxkYXZpZC5ibGFja0BlbWMuY29t PiAgd3JvdGU6DQo+Pg0KPj4+IEhpIEJyaWFuLA0KPj4+DQo+Pj4gS2F0aGxlZW4gcXVpY2tseSBk aXNwb3NlZCBvZiAjMSwgc28gcGxlYXNlIGlnbm9yZSB0aGF0LiAgU2hlJ2xsIGFkZA0KPj4+IHNv bWUgdGV4dCB0bw0KPj4+IDYwNDUtYmlzIHRvIGhlbHAgb3RoZXIgcmVhZGVycyBhdm9pZCB0aGUg bWlzdGFrZSB0aGF0IEkgbWFkZS4NCj4+Pg0KPj4+IEZvciAjMiwgdGhlIHNob3J0IHN1bW1hcnkg b2YgbXkgY29uY2VybiB3aXRoIHRoZSBjdXJyZW50IHRleHQNCj4+PiBpbnZvbHZlcyB0aGlzIHNl bnRlbmNlOg0KPj4+DQo+Pj4+ICAgICA8dD5SSUQgc3lzdGVtcyBNVVNUIHZlcmlmeSB0aGUgaWRl bnRpdHkgb2YgdGhlaXIgcGVlcnMgYWdhaW5zdA0KPj4+PiB0aGF0IHN0b3JlZA0KPj4+PiAgICAg aW4gdGhlIGNlcnRpZmljYXRlIHByZXNlbnRlZC4NCj4+PiBIb3cgZG9lcyBhIFJJRCBzeXN0ZW0g KGFzIFRMUyBjbGllbnQgb3Igc2VydmVyKSBkbyB0aGF0Pw0KPj4+DQo+Pj4gVGhlIG5leHQgc2Vu dGVuY2UgZXhwbGFpbnMgd2hhdCB0aGUgaWRlbnRpdHkgaXMsIGJ1dCBub3QgaG93IHRvDQo+Pj4g dmVyaWZ5IGl0Og0KPj4+DQo+Pj4+ICAgICBBbGwgUklEIHN5c3RlbXMgTVVTVCBiZSBpZGVudGlm aWVkIGJ5IGENCj4+Pj4gICAgIGNlcnRpZmljYXRlIGNvbnRhaW5pbmcgYTx4cmVmIHRhcmdldD0i UkZDNTI4MCI+RE5TLUlEDQo+Pj4+IGlkZW50aWZpZXI8L3hyZWY+DQo+Pj4+ICAgICBhcyBpbiBz ZWN0aW9uIDYuNCBvZjx4cmVmIHRhcmdldD0iUkZDNjEyNSIvPi4NCj4+PiBJbiBwYXJ0aWN1bGFy LCBzZWN0aW9uIDYuNCBvZiBSRkMgNjEyNSBkb2Vzbid0IHNwZWNpZnkgd2hhdCB0aGUNCj4+PiBj ZXJ0aWZpY2F0ZSBpZGVudGl0eQ0KPj4+IGlzIGNoZWNrZWQgYWdhaW5zdC4gIEl0IG1heSBldmVu IGJlIHRoYXQgc2VjdGlvbiA2LjQgb2YgUkZDIDYxMjUNCj4+PiBkb2Vzbid0IGFwcGx5IHRvDQo+ Pj4gY2xpZW50IGNlcnRpZmljYXRlcywgYmVjYXVzZSB0aGUgY2xpZW50IGlkZW50aXR5IGNoZWNr IG15IGJlIHN1YnN1bWVkDQo+Pj4gYnkgUEtJWCBwYXRoDQo+Pj4gdmFsaWRhdGlvbiBvZiB0aGUg Y2xpZW50IGNlcnRpZmljYXRlIGFnYWluc3QgdGhlIHNlcnZlcidzIHRydXN0DQo+Pj4gc3RvcmUs IHdoaWNoIGRvZXMNCj4+PiBuYW1lIGNvbXBhcmlzb24gYWNjb3JkaW5nIHRvIFJGQyA1MjgwLCBu b3QgUkZDIDYxMjUuDQo+Pj4NCj4+PiBBIHNlbnRlbmNlIG9yIHR3byBvbiBob3cgdG8gZG8gdGhh dCByZXF1aXJlZCAoTVVTVCkgaWRlbnRpdHkNCj4+PiB2ZXJpZmljYXRpb24gd291bGQgaGVscC4N Cj4+Pg0KPj4+IFRoYW5rcywNCj4+PiAtLURhdmlkDQo+Pj4NCj4+Pg0KPj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBNb3JpYXJ0eSwgS2F0aGxlZW4NCj4+Pj4gU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDEyIDI6NTUgUE0NCj4+Pj4gVG86IEJyaWFuIFRy YW1tZWxsOyBCbGFjaywgRGF2aWQNCj4+Pj4gQ2M6IG1pbGVAaWV0Zi5vcmcNCj4+Pj4gU3ViamVj dDogUkU6IFttaWxlXSA2MDQ2LWJpcyAtIENsaWVudCBjZXJ0aWZpY2F0ZSBpZGVudGl0eSBjaGVj aw0KPj4+Pg0KPj4+PiBIaSBCcmlhbiwNCj4+Pj4NCj4+Pj4gWW91IGNhbiBzYXZlIHlvdXIgdGlt ZSBvbiAjMSwgdGhlIHF1ZXN0aW9uL3JlcXVlc3Qgd2FzIHdpdGhkcmF3bi4NCj4+Pj4gVGhlIHNl bmRpbmcgUklEIHNlcnZlciBtYXkgb25seQ0KPj4+PiBhcHBlYXIgd2l0aGluIHRoZSBJT0RFRiBk b2N1bWVudCBhbmQgbm90IHRoZSBSSUQgWE1MIGRvY3VtZW50Lg0KPj4+Pg0KPj4+PiBUaGFuayB5 b3UsDQo+Pj4+IEthdGhsZWVuDQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+IEZyb206IEJyaWFuIFRyYW1tZWxsIFttYWlsdG86dHJhbW1lbGxAdGlrLmVlLmV0aHou Y2hdDQo+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAxMiAyOjUxIFBNDQo+Pj4+ IFRvOiBCbGFjaywgRGF2aWQNCj4+Pj4gQ2M6IE1vcmlhcnR5LCBLYXRobGVlbjsgbWlsZUBpZXRm Lm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW21pbGVdIDYwNDYtYmlzIC0gQ2xpZW50IGNlcnRpZmlj YXRlIGlkZW50aXR5IGNoZWNrDQo+Pj4+DQo+Pj4+IEhpLCBEYXZpZCwNCj4+Pj4NCj4+Pj4gVGhh bmtzIGZvciB0aGUgY29tbWVudHM7IEkndmUgYmVlbiBvdXQgb2YgY29udGFjdCBhbGwgZGF5IHNv IGFtDQo+Pj4+IGNhdGNoaW5nIHVwLiBJJ2xsIHRvcC1wb3N0IG15IHN1bW1hcnkNCj4+Pj4gcmVw bHkgYXQgZmlyc3Q7IEkgbWF5IGhhdmUgZnVydGhlciBkZXRhaWwgcmVwbGllcyBpbiBhIHN1YnNl cXVlbnQNCj4+Pj4gbWVzc2FnZS4NCj4+Pj4NCj4+Pj4gMS4gSSB3b3VsZCBuZWVkIHRvIHRoaW5r IG1vcmUgZGVlcGx5IGFib3V0IHRoZSBpbXBsaWNhdGlvbnMgb2YgYW55DQo+Pj4+IGF1dGhlbnRp Y2F0aW9uIGFsc28gY3Jvc3MtY2hlY2tpbmcNCj4+Pj4gdGhlIEROUy1JRCBhZ2FpbnN0IG5vdCBv bmx5IG5ldHdvcmstbGF5ZXIgYXZhaWxhYmxlIGlkZW50aWZpZXJzIGJ1dA0KPj4+PiBhbHNvIGFn YWluc3QgaW5mb3JtYXRpb24gc3RvcmVkDQo+Pj4+IHdpdGhpbiB0aGUgUklEIGRvY3VtZW50IGl0 c2VsZi4gVGhlcmUgc2VlbXMgdG8gYmUgYSBiaXQgb2YgYSBjaGlja2VuDQo+Pj4+IGFuZCBlZ2cg cHJvYmxlbSB0aGVyZSwgYW5kIGl0DQo+Pj4+IHNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgbWF5IGJl IHZhbGlkIGV4Y2VwdGlvbnMgdG8gYSBwb2xpY3kgdGhhdA0KPj4+PiB3b3VsZCBiZSBzaW1wbGUg ZW5vdWdoIHRvIGJlIChhKQ0KPj4+PiBpbXBsZW1lbnRhYmxlIGFuZCAoYikgdmVyaWZpYWJsZS4N Cj4+Pj4NCj4+Pj4gMi4gSXQgaXMgbm90IHRoZSBpbnRlbnQgdGhhdCA2MTI1IHNlY3Rpb24gNCBh cHBsaWVzIHNvbGVseSB0byB0aGUNCj4+Pj4gYXV0aGVudGljYXRpb24gb2YgdGhlIFRMUyBzZXJ2 ZXI7DQo+Pj4+IF9hbGxfIGF1dGhlbnRpY2F0aW9uIGluIFJJRCBvdmVyIEhUVFBTIG11c3QgYmUg bXV0dWFsLCBhbmQgSSBiZWxpZXZlDQo+Pj4+IHRoZSBjdXJyZW50IHByb3Bvc2VkIHRleHQgKGNv cGllZA0KPj4+PiBiZWxvdyBzdHJhaWdodCBmcm9tIHhtbCBzb3VyY2UpIHRvIGJlIGNsZWFyIG9u IHRoaXMgcG9pbnQsIGluDQo+Pj4+IGNvbnRleHQuIElmIHRoYXQncyBub3QgdGhlIGNhc2UsIHRo ZW4NCj4+Pj4gd2UnbGwgbmVlZCB0byBjaGFuZ2UgaXQuDQo+Pj4+DQo+Pj4+ICAgICA8dD5SSUQg c3lzdGVtcyBNVVNUIHVzZSBUTFMgdmVyc2lvbiAxLjE8eHJlZiB0YXJnZXQ9IlJGQzQzNDYiLz4N Cj4+Pj4gb3IgaGlnaGVyDQo+Pj4+ICAgICBmb3IgY29uZmlkZW50aWFsaXR5LCBpZGVudGlmaWNh dGlvbiwgYW5kIGF1dGhlbnRpY2F0aW9uLCB3aGVuDQo+Pj4+IHNlbmRpbmcgUklEDQo+Pj4+ICAg ICBtZXNzYWdlcyBvdmVyIEhUVFBTLiBIVFRQUyBpcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyIG9m PHhyZWYNCj4+Pj4gICAgIHRhcmdldD0iUkZDMjgxOCIvPi4gUklEIHN5c3RlbXMgTVVTVCB1c2Ug bXV0dWFsIGF1dGhlbnRpY2F0aW9uOw0KPj4+PiB0aGF0IGlzLA0KPj4+PiAgICAgYm90aCBSSUQg c3lzdGVtcyBhY3RpbmcgYXMgSFRUUFMgY2xpZW50cyBhbmQgUklEIHN5c3RlbXMgYWN0aW5nDQo+ Pj4+IGFzIEhUVFBTDQo+Pj4+ICAgICBzZXJ2ZXJzIE1VU1QgYmUgaWRlbnRpZmllZCBieSBhbjx4 cmVmIHRhcmdldD0iUkZDNTI4MCI+WC41MDkNCj4+Pj4gICAgIGNlcnRpZmljYXRlPC94cmVmPi4g TXV0dWFsIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVzIGZ1bGwgcGF0aA0KPj4+PiB2YWxpZGF0aW9u IG9uDQo+Pj4+ICAgICBlYWNoIGNlcnRpZmljYXRlLCBhcyBkZWZpbmVkIGluPHhyZWYgdGFyZ2V0 PSJSRkM1MjgwIi8+LjwvdD4NCj4+Pj4NCj4+Pj4gICAgIDx0PlRoZSBUTFMgc2Vzc2lvbiBNVVNU IHVzZSBub24tTlVMTCBjaXBoZXJzdWl0ZXMgZm9yDQo+Pj4+IGF1dGhlbnRpY2F0aW9uLA0KPj4+ PiAgICAgaW50ZWdyaXR5LCBhbmQgY29uZmlkZW50aWFsaXR5LiBTZXNzaW9ucyBNQVkgYmUgcmVu ZWdvdGlhdGVkDQo+Pj4+IHdpdGhpbiB0aGVzZQ0KPj4+PiAgICAgY29uc3RyYWludHMuPC90Pg0K Pj4+Pg0KPj4+PiAgICAgPHQ+UklEIHN5c3RlbXMgTVVTVCB2ZXJpZnkgdGhlIGlkZW50aXR5IG9m IHRoZWlyIHBlZXJzIGFnYWluc3QNCj4+Pj4gdGhhdCBzdG9yZWQNCj4+Pj4gICAgIGluIHRoZSBj ZXJ0aWZpY2F0ZSBwcmVzZW50ZWQuIEFsbCBSSUQgc3lzdGVtcyBNVVNUIGJlIGlkZW50aWZpZWQN Cj4+Pj4gYnkgYQ0KPj4+PiAgICAgY2VydGlmaWNhdGUgY29udGFpbmluZyBhPHhyZWYgdGFyZ2V0 PSJSRkM1MjgwIj5ETlMtSUQNCj4+Pj4gaWRlbnRpZmllcjwveHJlZj4NCj4+Pj4gICAgIGFzIGlu IHNlY3Rpb24gNi40IG9mPHhyZWYgdGFyZ2V0PSJSRkM2MTI1Ii8+LiBUaGUgaW5jbHVzaW9uIG9m DQo+Pj4+IENvbW1vbg0KPj4+PiAgICAgTmFtZXMgKENOLUlEcykgaW4gY2VydGlmaWNhdGVzIGlk ZW50aWZ5aW5nIFJJRCBzeXN0ZW1zIGlzIE5PVA0KPj4+PiBSRUNPTU1FTkRFRC4NCj4+Pj4gICAg IFdpbGRjYXJkcyBNVVNUIE5PVCBhcHBlYXIgaW4gdGhlIEROUy1JRCBvciBDTi1JRCBvZiBhIGNl cnRpZmljYXRlDQo+Pj4+ICAgICBpZGVudGlmeWluZyBhIFJJRCBzeXN0ZW0uIEFkZGl0aW9uYWwg Z2VuZXJhbCBpbmZvcm1hdGlvbiBvbiB0aGUNCj4+Pj4gdXNlIG9mIFBLSQ0KPj4+PiAgICAgd2l0 aCBSSUQgc3lzdGVtcyBpcyBkZXRhaWxlZCBpbiBTZWN0aW9uIDkuMyBvZjx4cmVmDQo+Pj4+ICAg ICB0YXJnZXQ9IkktRC5pZXRmLW1pbGUtcmZjNjA0NS1iaXMiLz4uPC90Pg0KPj4+Pg0KPj4+PiAg ICAgPHQ+UklEIHN5c3RlbXMgTVVTVCBzdXBwb3J0IFRMUyB2ZXJzaW9uIDEuMSBhbmQgU0hPVUxE IHN1cHBvcnQNCj4+Pj4gVExTIHZlcnNpb24NCj4+Pj4gICAgIDEuMjx4cmVmIHRhcmdldD0iUkZD NTI0NiIvPjsgUklEIHN5c3RlbXMgTVVTVCBOT1QgcmVxdWVzdCwNCj4+Pj4gb2ZmZXIsIG9yIHVz ZQ0KPj4+PiAgICAgYW55IHZlcnNpb24gb2YgU1NMLCBvciBhbnkgdmVyc2lvbiBvZiBUTFMgcHJp b3IgdG8gMS4xLCBkdWUgdG8NCj4+Pj4ga25vd24NCj4+Pj4gICAgIHNlY3VyaXR5IHZ1bG5lcmFi aWxpdGllcyBpbiBwcmlvciB2ZXJzaW9ucyBvZiB0aGUgcHJvdG9jb2w7IHNlZQ0KPj4+PiBBcHBl bmRpeCBFDQo+Pj4+ICAgICBvZjx4cmVmIHRhcmdldD0iUkZDNTI0NiIvPiAgZm9yIG1vcmUuPC90 Pg0KPj4+Pg0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IEJyaWFuDQo+Pj4+DQo+Pj4+ IE9uIEphbiAyNSwgMjAxMiwgYXQgODowMCBQTSw8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gIHdyb3Rl Og0KPj4+Pg0KPj4+Pj4gSGkgS2F0aGxlZW4sDQo+Pj4+Pg0KPj4+Pj4gSSBtaXNzZWQgdGhlIGNv bm5lY3Rpb24gYmV0d2VlbiBOb2RlIGFuZCBNc2dEZXN0aW5hdGlvbiBpbiA2MDQ1LWJpcw0KPj4+ Pj4gLSBteSBtaXN0YWtlLg0KPj4+Pj4NCj4+Pj4+IEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byByZXBl YXQgdGhlIGZvbGxvd2luZyB0ZXh0IGZyb20gdGhlDQo+Pj4+PiBzcGVjaWZpY2F0aW9uIG9mICJN c2dEZXN0aW5hdGlvbiINCj4+Pj4+IGluIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBOb2RlIGVs ZW1lbnQgaW4gUklEUG9saWN5LCBhcyB0aG9zZQ0KPj4+Pj4gc3BlY2lmaWNhdGlvbnMgYXJlIDUN Cj4+Pj4+IHBhZ2VzIGFwYXJ0LCBhbmQgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBvZiB0aGUg Tm9kZSBlbGVtZW50IGlzDQo+Pj4+PiBub3QgcHJlY2lzZSBhYm91dA0KPj4+Pj4gdXNhZ2U6DQo+ Pj4+Pg0KPj4+Pj4gICAgICAgICB0aGUgbWVhbmluZyBvZiB0aGUgdmFsdWUNCj4+Pj4+ICAgICAg ICAgaW4gdGhlIE5vZGUgZWxlbWVudCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBNc2dEZXN0aW5hdGlv bg0KPj4+Pj4gZWxlbWVudA0KPj4+Pj4NCj4+Pj4+IE9UT0gsIEkgbm93IGRvbid0IHNlZSBhbnl0 aGluZyBpbiBSSUQgdGhhdCByZXByZXNlbnRzIHRoZSBpZGVudGl0eQ0KPj4+Pj4gb2YgdGhlIHN5 c3RlbSBzZW5kaW5nDQo+Pj4+PiB0aGUgUklEIG1lc3NhZ2UsIGFuZCBJIGRvbid0IHRoaW5rIGFk ZGluZyB0aGF0IGlzIGltcG9ydGFudCBlbm91Z2gNCj4+Pj4+IHRvIG1ha2UgYSBjaGFuZ2UgYXQN Cj4+Pj4+IHRoaXMganVuY3R1cmUuICBJIGFsc28gZG9uJ3Qgc2VlIGFueSBwb2ludCBpbiB0cnlp bmcgdG8gdXNlIHRoZQ0KPj4+Pj4gZW52ZWxvcGVkIElPREVGIGRvY3VtZW50DQo+Pj4+PiB0byBj YXJyeSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNlbmRpbmcgUklEIHN5c3RlbSwgYXMgdGhhdCBkb2N1 bWVudA0KPj4+Pj4gY291bGQgZ2V0IGZvcndhcmRlZA0KPj4+Pj4gaW4gYSBkaWZmZXJlbnQgUklE IG1lc3NhZ2UsIGZvciB3aGljaCBpdCB3b3VsZCBjb250YWluIHRoZSB3cm9uZw0KPj4+Pj4gc2Vu ZGluZyBSSUQgc3lzdGVtDQo+Pj4+PiBpZGVudGl0eS4NCj4+Pj4+DQo+Pj4+PiBJZiB0aGVyZSdz IG5vIGluc3RhbmNlIG9mIHRoZSBzZW5kaW5nIFJJRCBzeXN0ZW0ncyBpZGVudGl0eSBpbiB0aGUN Cj4+Pj4+IFJJRCBtZXNzYWdlLCB0aGVuIEkNCj4+Pj4+IHN1cHBvc2UgdGhlIGNsaWVudCBpZGVu dGl0eSB2ZXJpZmljYXRpb24gd291bGQgaGF2ZSB0byBiZSBiYXNlZCBvbg0KPj4+Pj4gdGhlIGlu Zm9ybWF0aW9uIHVzZWQNCj4+Pj4+IHRvIHNldCB1cCB0aGUgdHJ1c3QgcmVsYXRpb25zaGlwcyBp biB0aGUgY29uc29ydGl1bS4gIFRoZSA2MDQ2LWJpcw0KPj4+Pj4gZHJhZnQgYWxyZWFkeSBoYXMg YQ0KPj4+Pj4gcmVmZXJlbmNlIHRvIHRoZSBQS0kgZGlzY3Vzc2lvbiBpbiA2MDQ1LWJpcy4gV291 bGQgaXQgbWFrZSBzZW5zZSB0bw0KPj4+Pj4gY2xhcmlmeSA2MDQ2LWJpcw0KPj4+Pj4gdG8gaW5k aWNhdGUgdGhhdCBSRkMgNjEyNSBTZWN0aW9uIDYgYXBwbGllcyBvbmx5IHRvIHNlcnZlciBpZGVu dGl0eQ0KPj4+Pj4gdmVyaWZpY2F0aW9uIGFuZCB0aGUNCj4+Pj4+IFBLSSBtYXRlcmlhbCBpbiA2 MDQ1LWJpcyBhcHBsaWVzIHRvIGJvdGggc2VydmVyIGFuZCBjbGllbnQgaWRlbnRpdHkNCj4+Pj4+ IHZlcmlmaWNhdGlvbj8NCj4+Pj4+DQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiAtLURhdmlkDQo+Pj4+ Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogTW9yaWFy dHksIEthdGhsZWVuDQo+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDEyIDE6 MjEgUE0NCj4+Pj4+PiBUbzogQmxhY2ssIERhdmlkOyBtaWxlQGlldGYub3JnDQo+Pj4+Pj4gU3Vi amVjdDogUkU6IDYwNDYtYmlzIC0gQ2xpZW50IGNlcnRpZmljYXRlIGlkZW50aXR5IGNoZWNrDQo+ Pj4+Pj4NCj4+Pj4+PiBIaSBEYXZpZCwNCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rIHlvdSBmb3IgdGhl IGNvbW1lbnRzLiAgSWYgdGV4dCBpcyBhZGRlZCwgaXQgd2lsbCBuZWVkIHRvIGJlDQo+Pj4+Pj4g c3BlY2lmaWMgdG8gdGhlIGluc3RhbmNlIG9mIE5vZGUNCj4+Pj4gaW4NCj4+Pj4+PiBSSUQgb3Ig SU9ERUYuICBUaGlzIHdvdWxkIG1lYW4gdGhlIENOIHdvdWxkIGJlIHVzZWQgZm9yIHRoaXMNCj4+ Pj4+PiBwdXJwb3NlIChpZiBVVEYtOCBuYW1lcyBhcmUgT0tlZCBmb3INCj4+Pj4gdXNlDQo+Pj4+ Pj4gaW4gUklEIE5vZGVOYW1lcyB3aXRoIHRoZSBpbnRlcm5hdGlvbmFsaXphdGlvbiBkaXNjdXNz aW9ucykuICBSSUQNCj4+Pj4+PiB1c2VzIE5vZGUgaW4gdHdvIHBsYWNlcyBhbmQgaXQNCj4+Pj4g bWF5DQo+Pj4+Pj4gbWFrZSBtb3JlIHNlbnNlIHRvIHJlZmVyZW5jZSB0aGUgb25lIGluIHRoZSBJ T0RFRiBkb2N1bWVudCBvcg0KPj4+Pj4+IGNoYW5nZSBzb21ldGhpbmcgaW4gUklELg0KPj4+Pj4+ DQo+Pj4+Pj4gSW5zdGFuY2VzIG9mIHdoZXJlICdOb2RlJyBhcHBlYXJzOg0KPj4+Pj4+IDEpIE5v ZGUgaW4gU291cmNlRm91bmQgd291bGQgbm90IGFwcGx5IGhlcmUuDQo+Pj4+Pj4NCj4+Pj4+PiAy KSBOb2RlIGluIFJJRCBSSURQb2xpY3kgaXMgdGllZCB0byBNc2dEZXN0aW5hdGlvbiBhbmQgd291 bGQgYmUNCj4+Pj4+PiB0aGUgcmVjZWl2aW5nIE5vZGUgb3IgdGhlIHN1c3BlY3RlZA0KPj4+Pj4+ IHNvdXJjZSBvZiBhbiBpbmNpZGVudCBpZiBhIHRyYWNlYmFjayB3ZXJlIGluIHBsYXkuDQo+Pj4+ Pj4NCj4+Pj4+PiAzKSBUaGlzIG1lYW5zIHRoZSBjb25uZWN0aW9uIHdvdWxkIG5lZWQgdG8gYmUg dG8gdGhlIElPREVGDQo+Pj4+Pj4gZG9jdW1lbnQgYW5kIHdvdWxkIHJlcXVpcmUgdGhlIGRvY3Vt ZW50DQo+Pj4+IHRvDQo+Pj4+Pj4gYmUgZGVjcnlwdGVkIHRvIHZlcmlmeSBpZiB0aGlzIHdlcmUg bmVjZXNzYXJ5LiAgT3IgYWRkaW5nIGEgTm9kZQ0KPj4+Pj4+IGluc3RhbmNlIHNwZWNpZmljIHRv IHRoZSBzZW5kaW5nDQo+Pj4+IGhvc3QNCj4+Pj4+PiBpbmZvcm1hdGlvbi4NCj4+Pj4+Pg0KPj4+ Pj4+IDQpIElmIGl0IHdlcmUgdGllZCB0byBJT0RFRiwgdGhlIHVzZSBvZiBOb2RlIGluIHRoZSBT eXN0ZW0gY2xhc3MNCj4+Pj4+PiBpcyBzcGVjaWZpYyB0byB0aGUgc291cmNlIGFuZA0KPj4+Pj4+ IGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBpbnZvbHZlZCBpbiBhbiBhdHRhY2suIFRoZSBFdmVudERh dGEgd2hlcmUNCj4+Pj4+PiBjb250YWN0IGNhdGVnb3J5IGlzIHNldCB0bw0KPj4+Pj4+ICJpbmZy YXN0cnVjdHVyZSIgaXMgdGhlIHBsYWNlIHdoZXJlIHN5c3RlbXMgaW52b2x2ZWQgaW4NCj4+Pj4+ PiBjb21tdW5pY2F0aW5nIElPREVGIGRvY3VtZW50cyBhcmUgbGlzdGVkLg0KPj4+Pj4+IFRoaXMg aXMgdGhlIHBhdGggaW5mb3JtYXRpb24gZm9yIGluY2lkZW50IGRhdGEgKGxpc3RzIGFsbCBvZiB0 aGUNCj4+Pj4+PiAnZnJvbScgc3lzdGVtcyBpbiBSSUQNCj4+Pj4+PiBjb21tdW5pY2F0aW9ucyku DQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4gS2F0aGxlZW4gKGFzIGVkaXRvcikNCj4+ Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogbWls ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+ Pj4+IEJlaGFsZiBPZiBkYXZpZC5ibGFja0BlbWMuY29tDQo+Pj4+Pj4gU2VudDogV2VkbmVzZGF5 LCBKYW51YXJ5IDI1LCAyMDEyIDEyOjM5IFBNDQo+Pj4+Pj4gVG86IG1pbGVAaWV0Zi5vcmcNCj4+ Pj4+PiBTdWJqZWN0OiBbbWlsZV0gNjA0Ni1iaXMgLSBDbGllbnQgY2VydGlmaWNhdGUgaWRlbnRp dHkgY2hlY2sNCj4+Pj4+Pg0KPj4+Pj4+IEJyaWFuIGFuZCBLYXRobGVlbiwNCj4+Pj4+Pg0KPj4+ Pj4+IEkgdGhpbmsgSSBmb3VuZCBzb21ldGhpbmcgaW4gbG9va2luZyBhdCB0aGUgdGV4dCByZWxh dGVkIHRvIHRoZQ0KPj4+Pj4+IHF1ZXN0aW9uIGFib3V0DQo+Pj4+Pj4gY2VydGlmaWNhdGUgaWRl bnRpdGllcywgYnV0IHNvbWUgbW9yZSBpbnB1dCB3b3VsZCBiZSB1c2VmdWwuDQo+Pj4+Pj4NCj4+ Pj4+PiBUaGUgNjA0Ni1iaXMtMDggZHJhZnQgc2F5czoNCj4+Pj4+Pg0KPj4+Pj4+ICAgUklEIHN5 c3RlbXMgTVVTVCB2ZXJpZnkgdGhlIGlkZW50aXR5IG9mIHRoZWlyIHBlZXJzIGFnYWluc3QgdGhh dA0KPj4+Pj4+ICAgc3RvcmVkIGluIHRoZSBjZXJ0aWZpY2F0ZSBwcmVzZW50ZWQsIGFzIGluIHNl Y3Rpb24gNiBvZiBbUkZDNjEyNV0uDQo+Pj4+Pj4NCj4+Pj4+PiBUaGF0IGNvdmVycyB2ZXJpZmlj YXRpb24gb2YgdGhlIGlkZW50aXR5IG9mIHRoZSByZWNlaXZpbmcgc3lzdGVtDQo+Pj4+Pj4gKHRo ZSBpZGVudGl0eQ0KPj4+Pj4+IGluIHRoZSBUTFMgc2VydmVyIGNlcnRpZmljYXRlIGhhcyB0byBt YXRjaCBob3N0IGNvbXBvbmVudCBvZiBVUkkNCj4+Pj4+PiBmb3IgSFRUUCksIGJ1dA0KPj4+Pj4+ IEkgZG9uJ3QgdGhpbmsgaXQgY292ZXJzIHZlcmlmaWNhdGlvbiBvZiB0aGUgaWRlbnRpdHkgb2Yg dGhlDQo+Pj4+Pj4gc2VuZGluZyBzeXN0ZW0sIGFzDQo+Pj4+Pj4gU2VjdGlvbiA2IG9mIFJGQyA2 MTI1IGNvbmNlcm5zIG9ubHkgc2VydmljZSBpZGVudGl0eS4NCj4+Pj4+Pg0KPj4+Pj4+IEknZCBz dWdnZXN0IGFkZGluZyBzb21lIHRleHQgdGhhdCByZXF1aXJlcyB0aGF0IHRoZSBpZGVudGl0eSBv Zg0KPj4+Pj4+IHRoZSBzZW5kaW5nDQo+Pj4+Pj4gc3lzdGVtIGluIHRoZSBUTFMgY2xpZW50IGNl cnRpZmljYXRlIG1hdGNoIHRoZSBOb2RlTmFtZSBpbiB0aGUNCj4+Pj4+PiBOb2RlIGVsZW1lbnQN Cj4+Pj4+PiBvZiB0aGUgUklEUG9saWN5IGNsYXNzIGlmIHRoZSBOb2RlTmFtZSBpcyBwcmVzZW50 LiBUaGF0ICJpcw0KPj4+Pj4+IHByZXNlbnQiIGNvbXBsaWNhdGlvbg0KPj4+Pj4+IGlzIGNvdXJ0 ZXN5IG9mIDYwNDUtYmlzIHJldXNpbmcgdGhlIElPREVGIE5vZGUgY2xhc3MgZnJvbSBSRkMNCj4+ Pj4+PiA1MDcwLCBiZWNhdXNlDQo+Pj4+Pj4gUkZDIDUwNzAgZG9lcyBub3QgcmVxdWlyZSB0aGF0 IE5vZGVOYW1lIGJlIHByZXNlbnQuDQo+Pj4+Pj4NCj4+Pj4+PiBJJ20gbm90IHN1cmUgd2hhdCB0 byBkbyBpZiBOb2RlTmFtZSBpcyBhYnNlbnQgLSBhIHBvc3NpYmxlDQo+Pj4+Pj4gYXBwcm9hY2gg d291bGQgYmUgdG8NCj4+Pj4+PiBub3QgZ28gdGhlcmUsIGFuZCBpbnN0ZWFkIGFkZCBhIHJlcXVp cmVtZW50IHRvIDYwNDUtYmlzIHRoYXQNCj4+Pj4+PiBOb2RlTmFtZSBNVVNUIGJlDQo+Pj4+Pj4g cHJlc2VudCBpbiB0aGUgTm9kZSBlbGVtZW50IG9mIHRoZSBSSURQb2xpY3kgY2xhc3MgaW4gb3Jk ZXIgdG8NCj4+Pj4+PiBmYWNpbGl0YXRlDQo+Pj4+Pj4gdGhpcyBpZGVudGl0eSBjaGVjay4NCj4+ Pj4+Pg0KPj4+Pj4+IFdoYXQgZG8gb3RoZXIgcGVvcGxlIHRoaW5rPw0KPj4+Pj4+DQo+Pj4+Pj4g VGhhbmtzLA0KPj4+Pj4+IC0tRGF2aWQNCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4gRGF2aWQgTC4gQmxhY2ssIERpc3Rp bmd1aXNoZWQgRW5naW5lZXINCj4+Pj4+PiBFTUMgQ29ycG9yYXRpb24sIDE3NiBTb3V0aCBTdC4s IEhvcGtpbnRvbiwgTUEgIDAxNzQ4DQo+Pj4+Pj4gKzEgKDUwOCkgMjkzLTc5NTMgICAgICAgICAg ICAgRkFYOiArMSAoNTA4KSAyOTMtNzc4Ng0KPj4+Pj4+IGRhdmlkLmJsYWNrQGVtYy5jb20gICAg ICAgIE1vYmlsZTogKzEgKDk3OCkgMzk0LTc3NTQNCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IG1pbGUgbWFp bGluZyBsaXN0DQo+Pj4+Pj4gbWlsZUBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG1pbGUgbWFpbGluZyBsaXN0DQo+Pj4+PiBt aWxlQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21pbGUNCj4NCg0KDQotLQ0KUGV0ZXIgU2FpbnQtQW5kcmUNCmh0dHBzOi8vc3RwZXRlci5pbS8N Cg0KDQoNCg== From stpeter@stpeter.im Thu Jan 26 12:04: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 8276921F8639 for ; Thu, 26 Jan 2012 12:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 NpCf+D573f83 for ; Thu, 26 Jan 2012 12:04:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 89C1121F85ED for ; Thu, 26 Jan 2012 12:04:55 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DB55B40058; Thu, 26 Jan 2012 13:14:42 -0700 (MST) Message-ID: <4F21B1E4.6060304@stpeter.im> Date: Thu, 26 Jan 2012 13:04:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: david.black@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mile@ietf.org, presnick@qualcomm.com Subject: Re: [mile] FW: IDN issue 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, 26 Jan 2012 20:04:56 -0000 Hi David, On 1/25/12 5:06 PM, david.black@emc.com wrote: > Hello Peter, > >> In short, there be dragons. > > Indeed (as I'm entirely too well-aware of from the précis WG), however, the goal > here is to find a suitable cave in which to confine the dragons :-). Nice way to put it. And yes, the PRECIS WG is a fun place to hang out. Speaking of which, how's that iSCSI profile of the precis framework coming along? ;-) > The place to start looking for that cave is an understanding of how NodeName is > used. The quick summary is that there are three cases: > > (1) RIDPolicy class, MsgDestination=RIDSystem. > > The NodeName is the destination of the RID message, so it can be required to work > in the DNS, which already has to deal with figuring out whether a U-Label is valid. > Text could be added to require that the NodeName either be used to send the RID > message via DNS lookup or that it has been looked up at some point in the past and > resolves to the IP address to which the RID message is sent. Both of these > approaches rely on the DNS implementation to validate the U-label. I think that might be fine. I see that version -09 says: 1. RIDSystem. The address listed in the Node element of the RIDPolicy class is the next upstream RID system that will receive the RID message. If NodeName element of the Node class is used, it contains a DNS domain name. The originating RID system is required to check that this domain name resolves to the IP address to which the RID message is sent. This check may be performed in advance of sending the message and the result saved for future use with additional RID messages. However, the spec right now says that the domain name MUST NOT contain A-labels: The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. A RID system can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. If the application is not checking this, how will it know whether any A-labels have snuck in? Will it depend on its DNS resolver to return the IDN in the appropriate format? The foregoing text implies that the RID system will do the conversion, so it's not clear to me where the responsibility lies (and if it's not clear to me, it might be clear to an implementer). And if only U-labels are permitted, then comparison proceeds using the U-labels as input. However, if so we might need to specify mappings of the kind discussed in RFC 5895 (e.g., mapping uppercase and titlecase to lowercase so that PRÉCIS.example.com is treated "the same" as précis.example.com). BUT... Will RID systems in fact be doing such comparisons? The text from the first paragraph quoted above indicates that RID systems will be checking the association between a DNS domain name and an IP address, not directly comparing DNS domain names (including IDNs). If that is true, then we probably *don't* need to care much about comparison and any talk of mappings is moot. Can you please verify that RID systems will be checking the association with the IP address, rather than directly comparing DNS domain names? > (2) RIDPolicy class, MsgDestination=SourceOfIncident, and also the IncidentSource > class. > > In both of these cases the IP address is the primary identifier (IncidentSource > needs additional text to state that the IP address is required - that appears to > have been overlooked). There are a couple of options here: > > a) The simplest is to prohibit NodeName usage. > b) NodeName could be required to correspond to the IP address via DNS lookup. In -09 that is: 2. SourceOfIncident. The Address element of the Node element contains the IP address of the incident source, and the NodeName element of the Node class is not used. The IP address is used to determine the path of systems accepting RID communications that will be used to find the closest RID system to the source of an attack in which the IP address used by the source is believed to be valid and a Request message with MsgDst set to InvestigationRequest is used. This is not to be confused with the IncidentSource class, as the defined value here is from an initial trace or investigation Request, not the source used in a Result message. I think it's fine to use IP address here. NOTE: you said that IncidentSource needs additional text to state that the IP address required, but I do not see that here: http://tools.ietf.org/rfcdiff?url1=draft-ietf-mile-rfc6045-bis-08&difftype=--html&submit=Go!&url2=draft-ietf-mile-rfc6045-bis-09 However, I think that can be added before sending this document to the RFC Editor, or during AUTH48. > (3) RIDPolicy class, MsgDestination=ext-value. This is an escape that allows > extensions to MsgDestination. The description of this should include a "there > be dragons" warning about IDNs in NodeName. In -09 that is: 3. ext-value. An escape value used to extend this attribute. All extensions shall specify the contents and meaning of the Node element of RIDPolicy. If the NodeName element of Node is used by an extension, NodeName may contain an Internationalized Domain Name (IDN) and that IDN is required to satisfy the requirements in [RFC5890]. It is strongly recommended that RID Systems satisfy those IDN requirements via appropriate use of the DNS as opposed to implementing their own checks for these requirements. For example, an extension could use both a NodeName and an IP address to which the NodeName resolves. See IODEF [RFC5070], Section 5.1 on extensibility. That seems slightly underspecified: what is meant by "to satisfy the requirements in [RFC5890]" and "appropriate use of the DNS"? Does that mean "ensuring that the IDN retrieved from the DNS consists only of U-labels and NR-LDH labels"? If so, is that done by asking the DNS resolver for U-labels, or is it done by actively performing a check in the RID system itself (see above about "MUST NOT be A-labels")? Is this something that is left for each extension to define? If so, we should come out and say precisely that. > So, the answer to the somewhat rhetorical question: > >> Do IODEF/RID implementations want to sign up for all that? > > Is approximately "Yes, by relying on the DNS implementation," with the addition > of a "there be dragons" warning to the MsgDestination ext-value extension text > to communicate that to designers of extensions, and a possible prohibition of > use of NodeName when the IP address is the primary identifier. I think we're getting close to reflecting that in text, but a few clarifications would help, as would validation from the WG that this direction is agreeable. I realize that these are thorny issues and that folks probably just want someone to come from on high and say "yea verily, here is the one true path to internationalization nirvana". Unfortunately, there is no such path, so the WG needs to weigh the costs and benefits, clearly understand what it's doing, and then make a decision one way or the other. We've had too many WGs (some of which I've been involved with) just take some i18n advice without knowledge, and the results have been less then positive. Thanks for your patience! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jan 26 12:09: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 80CD421F864B for ; Thu, 26 Jan 2012 12:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.022 X-Spam-Level: X-Spam-Status: No, score=-101.022 tagged_above=-999 required=5 tests=[AWL=-1.623, BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_21=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=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 53Dp9iRuX8WK for ; Thu, 26 Jan 2012 12:09:09 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9567F21F8665 for ; Thu, 26 Jan 2012 12:09:08 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4B28840058; Thu, 26 Jan 2012 13:18:56 -0700 (MST) Message-ID: <4F21B2E2.2040204@stpeter.im> Date: Thu, 26 Jan 2012 13:09:06 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mile@ietf.org, alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 26 Jan 2012 20:09:10 -0000 Thanks for the clarification. OT: I think the "meeting in person" part is important! On 1/26/12 12:41 PM, kathleen.moriarty@emc.com wrote: > I'll leave the rest to Brian, but confirm the consortium > expectations: > > In terms of incident sharing groups, right now they are either > industry based or small groups. People want to share with people > that they know and hence think they can trust. The Advanced Cyber > Security Center (ACSC) is an example in New England that is cross > industry. They are setting a model that others are starting to > follow where membership is limited to 30 organizations and they meet > regularly in person (in addition to any online sharing). This group > plans to peer with other groups and the sharing arrangements could > vary within the consortium or between other consortiums. The > consortiums work out detailed agreements, so maintaining this type of > information really should not be an issue in those models. > > Thanks, Kathleen > > -----Original Message----- From: Peter Saint-Andre > [mailto:stpeter@stpeter.im] Sent: Thursday, January 26, 2012 2:34 PM > To: Alexey Melnikov Cc: Brian Trammell; Black, David; Moriarty, > Kathleen; Sean Turner; mile@ietf.org Subject: Re: [mile] 6046-bis - > Client certificate identity check > > On 1/26/12 12:21 PM, Alexey Melnikov wrote: >> On 25/01/2012 21:17, Brian Trammell wrote: >>> Hi, David, >>> >>> The reference identifier (defined in RFC 6215 section 1.8; >>> explained in 6.2) in RID transport is (presumably) the identity >>> one system uses to connect to another (see paragraph 12 of >>> 6046-bis-08 section 3: "...the use of stable DNS names to address >>> RID Systems is RECOMMENDED"). This could perhaps be made more >>> explicit but it seemed obvious enough. >>> >>> For mutual authentication, this would have to be derived from a >>> reverse mapping of the network address back to a name (either by >>> DNS PTR records, or a whitelist of consortium members). >> David is correct that RFC 6125 can only be used by the entity that >> actively connect to another one (i.e. by the client to verify the >> server). > > English nit: s/i.e./e.g./ (because it can be used by one server > connecting to another server, as we're sort of doing here). > >> If you find the burden of maintaining the reverse DNS mapping to >> be acceptable for your protocol (for deployments of some other >> protocols, like SMTP that burden was found to be unacceptable), >> then you can use RFC 6125 for verifying clients by servers. > > My sense is that in RID consortia, this is seen as an acceptable > burden because the number of members in each consortium is > manageable. But that's something that RID participants probably need > to verify. > >> If you are not concerned about one RID member masquerading as >> another, it might be sufficient for your protocol to allow client >> certificates to come from a known CA (or a set of CAs), or be >> whitelisted. So basically you will use more relaxed verification >> rules from RFC 5280. > > Well, I think you'd probably still want to do the domain check, no? > >>> Perhaps stating "each RID system MUST maintain a DNS-ID >>> reference identifier for those RID systems it participates in a >>> consortium with, and use this for comparison with the DNS-ID >>> stored in the certificate presented by RID system peers" would >>> address this concern? >> >>> Regards, >>> >>> Brian >>> >>> On Jan 25, 2012, at 9:24 PM, >>> wrote: >>> >>>> Hi Brian, >>>> >>>> Kathleen quickly disposed of #1, so please ignore that. She'll >>>> add some text to 6045-bis to help other readers avoid the >>>> mistake that I made. >>>> >>>> For #2, the short summary of my concern with the current text >>>> involves this sentence: >>>> >>>>> RID systems MUST verify the identity of their peers >>>>> against that stored in the certificate presented. >>>> How does a RID system (as TLS client or server) do that? >>>> >>>> The next sentence explains what the identity is, but not how >>>> to verify it: >>>> >>>>> All RID systems MUST be identified by a certificate >>>>> containing aDNS-ID identifier >>>>> as in section 6.4 of. >>>> In particular, section 6.4 of RFC 6125 doesn't specify what >>>> the certificate identity is checked against. It may even be >>>> that section 6.4 of RFC 6125 doesn't apply to client >>>> certificates, because the client identity check my be subsumed >>>> by PKIX path validation of the client certificate against the >>>> server's trust store, which does name comparison according to >>>> RFC 5280, not RFC 6125. >>>> >>>> A sentence or two on how to do that required (MUST) identity >>>> verification would help. >>>> >>>> Thanks, --David >>>> >>>> >>>>> -----Original Message----- From: Moriarty, Kathleen Sent: >>>>> Wednesday, January 25, 2012 2:55 PM To: Brian Trammell; >>>>> Black, David Cc: mile@ietf.org Subject: RE: [mile] 6046-bis - >>>>> Client certificate identity check >>>>> >>>>> Hi Brian, >>>>> >>>>> You can save your time on #1, the question/request was >>>>> withdrawn. The sending RID server may only appear within the >>>>> IODEF document and not the RID XML document. >>>>> >>>>> Thank you, Kathleen >>>>> >>>>> -----Original Message----- From: Brian Trammell >>>>> [mailto:trammell@tik.ee.ethz.ch] Sent: Wednesday, January 25, >>>>> 2012 2:51 PM To: Black, David Cc: Moriarty, Kathleen; >>>>> mile@ietf.org Subject: Re: [mile] 6046-bis - Client >>>>> certificate identity check >>>>> >>>>> Hi, David, >>>>> >>>>> Thanks for the comments; I've been out of contact all day so >>>>> am catching up. I'll top-post my summary reply at first; I >>>>> may have further detail replies in a subsequent message. >>>>> >>>>> 1. I would need to think more deeply about the implications >>>>> of any authentication also cross-checking the DNS-ID against >>>>> not only network-layer available identifiers but also against >>>>> information stored within the RID document itself. There >>>>> seems to be a bit of a chicken and egg problem there, and it >>>>> seems to me that there may be valid exceptions to a policy >>>>> that would be simple enough to be (a) implementable and (b) >>>>> verifiable. >>>>> >>>>> 2. It is not the intent that 6125 section 4 applies solely to >>>>> the authentication of the TLS server; _all_ authentication in >>>>> RID over HTTPS must be mutual, and I believe the current >>>>> proposed text (copied below straight from xml source) to be >>>>> clear on this point, in context. If that's not the case, >>>>> then we'll need to change it. >>>>> >>>>> RID systems MUST use TLS version 1.1>>>> target="RFC4346"/> or higher for confidentiality, >>>>> identification, and authentication, when sending RID messages >>>>> over HTTPS. HTTPS is specified in Section 2 of>>>> target="RFC2818"/>. RID systems MUST use mutual >>>>> authentication; that is, both RID systems acting as HTTPS >>>>> clients and RID systems acting as HTTPS servers MUST be >>>>> identified by anX.509 >>>>> certificate. Mutual authentication requires full path >>>>> validation on each certificate, as defined in>>>> target="RFC5280"/>. >>>>> >>>>> The TLS session MUST use non-NULL ciphersuites for >>>>> authentication, integrity, and confidentiality. Sessions MAY >>>>> be renegotiated within these constraints. >>>>> >>>>> RID systems MUST verify the identity of their peers >>>>> against that stored in the certificate presented. All RID >>>>> systems MUST be identified by a certificate containing a>>>> target="RFC5280">DNS-ID identifier as in section 6.4 >>>>> of. The inclusion of Common Names >>>>> (CN-IDs) in certificates identifying RID systems is NOT >>>>> RECOMMENDED. Wildcards MUST NOT appear in the DNS-ID or CN-ID >>>>> of a certificate identifying a RID system. Additional general >>>>> information on the use of PKI with RID systems is detailed in >>>>> Section 9.3 of>>>> target="I-D.ietf-mile-rfc6045-bis"/>. >>>>> >>>>> RID systems MUST support TLS version 1.1 and SHOULD >>>>> support TLS version 1.2; RID systems >>>>> MUST NOT request, offer, or use any version of SSL, or any >>>>> version of TLS prior to 1.1, due to known security >>>>> vulnerabilities in prior versions of the protocol; see >>>>> Appendix E of for more. >>>>> >>>>> Best regards, >>>>> >>>>> Brian >>>>> >>>>> On Jan 25, 2012, at 8:00 PM, wrote: >>>>> >>>>>> Hi Kathleen, >>>>>> >>>>>> I missed the connection between Node and MsgDestination in >>>>>> 6045-bis - my mistake. >>>>>> >>>>>> It might be useful to repeat the following text from the >>>>>> specification of "MsgDestination" in the specification of >>>>>> the Node element in RIDPolicy, as those specifications are >>>>>> 5 pages apart, and the current specification of the Node >>>>>> element is not precise about usage: >>>>>> >>>>>> the meaning of the value in the Node element is determined >>>>>> by the MsgDestination element >>>>>> >>>>>> OTOH, I now don't see anything in RID that represents the >>>>>> identity of the system sending the RID message, and I don't >>>>>> think adding that is important enough to make a change at >>>>>> this juncture. I also don't see any point in trying to use >>>>>> the enveloped IODEF document to carry the identity of the >>>>>> sending RID system, as that document could get forwarded in >>>>>> a different RID message, for which it would contain the >>>>>> wrong sending RID system identity. >>>>>> >>>>>> If there's no instance of the sending RID system's identity >>>>>> in the RID message, then I suppose the client identity >>>>>> verification would have to be based on the information >>>>>> used to set up the trust relationships in the consortium. >>>>>> The 6046-bis draft already has a reference to the PKI >>>>>> discussion in 6045-bis. Would it make sense to clarify >>>>>> 6046-bis to indicate that RFC 6125 Section 6 applies only >>>>>> to server identity verification and the PKI material in >>>>>> 6045-bis applies to both server and client identity >>>>>> verification? >>>>>> >>>>>> Thanks, --David >>>>>> >>>>>>> -----Original Message----- From: Moriarty, Kathleen Sent: >>>>>>> Wednesday, January 25, 2012 1:21 PM To: Black, David; >>>>>>> mile@ietf.org Subject: RE: 6046-bis - Client certificate >>>>>>> identity check >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for the comments. If text is added, it will >>>>>>> need to be specific to the instance of Node >>>>> in >>>>>>> RID or IODEF. This would mean the CN would be used for >>>>>>> this purpose (if UTF-8 names are OKed for >>>>> use >>>>>>> in RID NodeNames with the internationalization >>>>>>> discussions). RID uses Node in two places and it >>>>> may >>>>>>> make more sense to reference the one in the IODEF >>>>>>> document or change something in RID. >>>>>>> >>>>>>> Instances of where 'Node' appears: 1) Node in SourceFound >>>>>>> would not apply here. >>>>>>> >>>>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and >>>>>>> would be the receiving Node or the suspected source of an >>>>>>> incident if a traceback were in play. >>>>>>> >>>>>>> 3) This means the connection would need to be to the >>>>>>> IODEF document and would require the document >>>>> to >>>>>>> be decrypted to verify if this were necessary. Or adding >>>>>>> a Node instance specific to the sending >>>>> host >>>>>>> information. >>>>>>> >>>>>>> 4) If it were tied to IODEF, the use of Node in the >>>>>>> System class is specific to the source and destination >>>>>>> addresses involved in an attack. The EventData where >>>>>>> contact category is set to "infrastructure" is the place >>>>>>> where systems involved in communicating IODEF documents >>>>>>> are listed. This is the path information for incident >>>>>>> data (lists all of the 'from' systems in RID >>>>>>> communications). >>>>>>> >>>>>>> Thanks, Kathleen (as editor) >>>>>>> >>>>>>> -----Original Message----- From: mile-bounces@ietf.org >>>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>>>> david.black@emc.com Sent: Wednesday, January 25, 2012 >>>>>>> 12:39 PM To: mile@ietf.org Subject: [mile] 6046-bis - >>>>>>> Client certificate identity check >>>>>>> >>>>>>> Brian and Kathleen, >>>>>>> >>>>>>> I think I found something in looking at the text related >>>>>>> to the question about certificate identities, but some >>>>>>> more input would be useful. >>>>>>> >>>>>>> The 6046-bis-08 draft says: >>>>>>> >>>>>>> RID systems MUST verify the identity of their peers >>>>>>> against that stored in the certificate presented, as in >>>>>>> section 6 of [RFC6125]. >>>>>>> >>>>>>> That covers verification of the identity of the receiving >>>>>>> system (the identity in the TLS server certificate has to >>>>>>> match host component of URI for HTTP), but I don't think >>>>>>> it covers verification of the identity of the sending >>>>>>> system, as Section 6 of RFC 6125 concerns only service >>>>>>> identity. >>>>>>> >>>>>>> I'd suggest adding some text that requires that the >>>>>>> identity of the sending system in the TLS client >>>>>>> certificate match the NodeName in the Node element of the >>>>>>> RIDPolicy class if the NodeName is present. That "is >>>>>>> present" complication is courtesy of 6045-bis reusing the >>>>>>> IODEF Node class from RFC 5070, because RFC 5070 does not >>>>>>> require that NodeName be present. >>>>>>> >>>>>>> I'm not sure what to do if NodeName is absent - a >>>>>>> possible approach would be to not go there, and instead >>>>>>> add a requirement to 6045-bis that NodeName MUST be >>>>>>> present in the Node element of the RIDPolicy class in >>>>>>> order to facilitate this identity check. >>>>>>> >>>>>>> What do other people think? >>>>>>> >>>>>>> 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 >>>>>>> ---------------------------------------------------- >>>>>>> >>>>>>> _______________________________________________ mile >>>>>>> mailing 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 Thu Jan 26 12:42:47 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 303B121F8649 for ; Thu, 26 Jan 2012 12:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.65 X-Spam-Level: X-Spam-Status: No, score=-9.65 tagged_above=-999 required=5 tests=[AWL=0.949, 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 DK4ax9YAROPG for ; Thu, 26 Jan 2012 12:42:45 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id BD2DC21F85F9 for ; Thu, 26 Jan 2012 12:42:44 -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 q0QKgewT004873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 15:42:42 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 26 Jan 2012 15:42:28 -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 q0QKgRSp016127; Thu, 26 Jan 2012 15:42:28 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Thu, 26 Jan 2012 15:42:27 -0500 From: To: , Date: Thu, 26 Jan 2012 15:42:26 -0500 Thread-Topic: [mile] FW: IDN issue Thread-Index: AczcZdyH6l9cq8a7QcWRsBkHcO/cpwAAQppg Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> In-Reply-To: <4F21B1E4.6060304@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, presnick@qualcomm.com Subject: Re: [mile] FW: IDN issue 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, 26 Jan 2012 20:42:47 -0000 SGkgUGV0ZXIsDQoNCkknbGwgdHJ5IHRvIHJlc3BvbmQgaW4gbGluZSBiZWxvdyBhbmQgbGV0IERh dmlkIGZpbGwgaW4gYW55IGdhcHMuDQoNClRoYW5rcywNCkthdGhsZWVuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptaWxl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlciBTYWludC1BbmRyZQ0KU2VudDog VGh1cnNkYXksIEphbnVhcnkgMjYsIDIwMTIgMzowNSBQTQ0KVG86IEJsYWNrLCBEYXZpZA0KQ2M6 IG1pbGVAaWV0Zi5vcmc7IHByZXNuaWNrQHF1YWxjb21tLmNvbQ0KU3ViamVjdDogUmU6IFttaWxl XSBGVzogSUROIGlzc3VlDQoNCkhpIERhdmlkLA0KDQpPbiAxLzI1LzEyIDU6MDYgUE0sIGRhdmlk LmJsYWNrQGVtYy5jb20gd3JvdGU6DQo+IEhlbGxvIFBldGVyLA0KPiANCj4+IEluIHNob3J0LCB0 aGVyZSBiZSBkcmFnb25zLg0KPiANCj4gSW5kZWVkIChhcyBJJ20gZW50aXJlbHkgdG9vIHdlbGwt YXdhcmUgb2YgZnJvbSB0aGUgcHLDqWNpcyBXRyksIGhvd2V2ZXIsIHRoZSBnb2FsDQo+IGhlcmUg aXMgdG8gZmluZCBhIHN1aXRhYmxlIGNhdmUgaW4gd2hpY2ggdG8gY29uZmluZSB0aGUgZHJhZ29u cyA6LSkuDQoNCk5pY2Ugd2F5IHRvIHB1dCBpdC4gQW5kIHllcywgdGhlIFBSRUNJUyBXRyBpcyBh IGZ1biBwbGFjZSB0byBoYW5nIG91dC4NClNwZWFraW5nIG9mIHdoaWNoLCBob3cncyB0aGF0IGlT Q1NJIHByb2ZpbGUgb2YgdGhlIHByZWNpcyBmcmFtZXdvcmsNCmNvbWluZyBhbG9uZz8gOy0pDQoN Cj4gVGhlIHBsYWNlIHRvIHN0YXJ0IGxvb2tpbmcgZm9yIHRoYXQgY2F2ZSBpcyBhbiB1bmRlcnN0 YW5kaW5nIG9mIGhvdyBOb2RlTmFtZSBpcw0KPiB1c2VkLiBUaGUgcXVpY2sgc3VtbWFyeSBpcyB0 aGF0IHRoZXJlIGFyZSB0aHJlZSBjYXNlczoNCj4gDQo+ICgxKSBSSURQb2xpY3kgY2xhc3MsIE1z Z0Rlc3RpbmF0aW9uPVJJRFN5c3RlbS4NCj4gDQo+IFRoZSBOb2RlTmFtZSBpcyB0aGUgZGVzdGlu YXRpb24gb2YgdGhlIFJJRCBtZXNzYWdlLCBzbyBpdCBjYW4gYmUgcmVxdWlyZWQgdG8gd29yaw0K PiBpbiB0aGUgRE5TLCB3aGljaCBhbHJlYWR5IGhhcyB0byBkZWFsIHdpdGggZmlndXJpbmcgb3V0 IHdoZXRoZXIgYSBVLUxhYmVsIGlzIHZhbGlkLg0KPiBUZXh0IGNvdWxkIGJlIGFkZGVkIHRvIHJl cXVpcmUgdGhhdCB0aGUgTm9kZU5hbWUgZWl0aGVyIGJlIHVzZWQgdG8gc2VuZCB0aGUgUklEDQo+ IG1lc3NhZ2UgdmlhIEROUyBsb29rdXAgb3IgdGhhdCBpdCBoYXMgYmVlbiBsb29rZWQgdXAgYXQg c29tZSBwb2ludCBpbiB0aGUgcGFzdCBhbmQNCj4gcmVzb2x2ZXMgdG8gdGhlIElQIGFkZHJlc3Mg dG8gd2hpY2ggdGhlIFJJRCBtZXNzYWdlIGlzIHNlbnQuICBCb3RoIG9mIHRoZXNlDQo+IGFwcHJv YWNoZXMgcmVseSBvbiB0aGUgRE5TIGltcGxlbWVudGF0aW9uIHRvIHZhbGlkYXRlIHRoZSBVLWxh YmVsLg0KDQpJIHRoaW5rIHRoYXQgbWlnaHQgYmUgZmluZS4gSSBzZWUgdGhhdCB2ZXJzaW9uIC0w OSBzYXlzOg0KDQogICAgICAgICAxLiAgUklEU3lzdGVtLiAgVGhlIGFkZHJlc3MgbGlzdGVkIGlu IHRoZSBOb2RlIGVsZW1lbnQgb2YgdGhlDQogICAgICAgICAgICAgUklEUG9saWN5IGNsYXNzIGlz IHRoZSBuZXh0IHVwc3RyZWFtIFJJRCBzeXN0ZW0gdGhhdCB3aWxsDQogICAgICAgICAgICAgcmVj ZWl2ZSB0aGUgUklEIG1lc3NhZ2UuICBJZiBOb2RlTmFtZSBlbGVtZW50IG9mIHRoZSBOb2RlDQog ICAgICAgICAgICAgY2xhc3MgaXMgdXNlZCwgaXQgY29udGFpbnMgYSBETlMgZG9tYWluIG5hbWUu ICBUaGUNCiAgICAgICAgICAgICBvcmlnaW5hdGluZyBSSUQgc3lzdGVtIGlzIHJlcXVpcmVkIHRv IGNoZWNrIHRoYXQgdGhpcw0KICAgICAgICAgICAgIGRvbWFpbiBuYW1lIHJlc29sdmVzIHRvIHRo ZSBJUCBhZGRyZXNzIHRvIHdoaWNoIHRoZSBSSUQNCiAgICAgICAgICAgICBtZXNzYWdlIGlzIHNl bnQuICBUaGlzIGNoZWNrIG1heSBiZSBwZXJmb3JtZWQgaW4gYWR2YW5jZSBvZg0KICAgICAgICAg ICAgIHNlbmRpbmcgdGhlIG1lc3NhZ2UgYW5kIHRoZSByZXN1bHQgc2F2ZWQgZm9yIGZ1dHVyZSB1 c2UNCiAgICAgICAgICAgICB3aXRoIGFkZGl0aW9uYWwgUklEIG1lc3NhZ2VzLg0KDQpIb3dldmVy LCB0aGUgc3BlYyByaWdodCBub3cgc2F5cyB0aGF0IHRoZSBkb21haW4gbmFtZSBNVVNUIE5PVCBj b250YWluDQpBLWxhYmVsczoNCg0KICAgVGhlIE5vZGUgY2xhc3MgaWRlbnRpZmllcyBhIGhvc3Qg b3IgbmV0d29yayBkZXZpY2UuICBUaGlzIGRvY3VtZW50DQogICByZS11c2VzIHRoZSBkZWZpbml0 aW9uIG9mIE5vZGUgZnJvbSB0aGUgSU9ERUYgc3BlY2lmaWNhdGlvbg0KICAgW1JGQzUwNzBdLCBT ZWN0aW9uIDMuMTYuICBIb3dldmVyLCB0aGF0IGRvY3VtZW50IGRpZCBub3QgY2xlYXJseQ0KICAg c3BlY2lmeSB3aGV0aGVyIGEgTm9kZU5hbWUgY291bGQgYmUgYW4gSW50ZXJuYXRpb25hbGl6ZWQg RG9tYWluIE5hbWUNCiAgIChJRE4pLiAgUklEIHN5c3RlbXMgTVVTVCB0cmVhdCB0aGUgTm9kZU5h bWUgY2xhc3MgYXMgYSBkb21haW4gbmFtZQ0KICAgc2xvdCBbUkZDNTg5MF0uICBSSUQgc3lzdGVt cyBTSE9VTEQgc3VwcG9ydCBJRE5zIGluIHRoZSBOb2RlTmFtZQ0KICAgY2xhc3M7IGlmIHRoZXkg ZG8gc28sIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiB0aGUgZG9tYWluIG5hbWUNCiAgIE1V U1QgYmUgdXNlZCwgaS5lLiwgYWxsIG9mIHRoZSBkb21haW4gbmFtZSdzIGxhYmVscyBNVVNUIGJl IFUtbGFiZWxzDQogICBleHByZXNzZWQgaW4gVVRGLTggb3IgTlItTERIIGxhYmVscyBbUkZDNTg5 MF07IEEtbGFiZWxzIE1VU1QgTk9UIGJlDQogICB1c2VkLiAgQSBSSUQgc3lzdGVtIGNhbiBjb252 ZXJ0IGJldHdlZW4gQS1sYWJlbHMgYW5kIFUtbGFiZWxzIGJ5DQogICB1c2luZyB0aGUgUHVueWNv ZGUgZW5jb2RpbmcgW1JGQzM0OTJdIGZvciBBLWxhYmVscyBhcyBkZXNjcmliZWQgaW4NCiAgIHRo ZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGZvciBJbnRlcm5hdGlvbmFsaXplZCBEb21haW4gTmFt ZXMgaW4NCiAgIEFwcGxpY2F0aW9ucyBbUkZDNTg5MV0uDQoNCklmIHRoZSBhcHBsaWNhdGlvbiBp cyBub3QgY2hlY2tpbmcgdGhpcywgaG93IHdpbGwgaXQga25vdyB3aGV0aGVyIGFueQ0KQS1sYWJl bHMgaGF2ZSBzbnVjayBpbj8gV2lsbCBpdCBkZXBlbmQgb24gaXRzIEROUyByZXNvbHZlciB0byBy ZXR1cm4gdGhlDQpJRE4gaW4gdGhlIGFwcHJvcHJpYXRlIGZvcm1hdD8gVGhlIGZvcmVnb2luZyB0 ZXh0IGltcGxpZXMgdGhhdCB0aGUgUklEDQpzeXN0ZW0gd2lsbCBkbyB0aGUgY29udmVyc2lvbiwg c28gaXQncyBub3QgY2xlYXIgdG8gbWUgd2hlcmUgdGhlDQpyZXNwb25zaWJpbGl0eSBsaWVzIChh bmQgaWYgaXQncyBub3QgY2xlYXIgdG8gbWUsIGl0IG1pZ2h0IGJlIGNsZWFyIHRvDQphbiBpbXBs ZW1lbnRlcikuDQpfX19fX19fX18NCktNTTogV2Ugc3RhdGUgdGhhdCB0aGUgZG9jdW1lbnQgbXVz dCBiZSBVVEYtOCBjb21wbGlhbnQoIlRoZSB1c2Ugb2YgVVRGLTggaXMgUkVRVUlSRUQiKS4gIERv ZXMgdGhhdCBjb3ZlciB0aGUgY2hlY2tpbmcgc2luY2UgQS1sYWJlbHMgYXJlIG5vdCBVVEYtOCBm b3JtYXR0ZWQ/ICBXb3VsZCB0aGUgcXVlc3Rpb24gYmUgcmVzb2x2ZWQgYnkgY2hhbmdpbmc6DQoi IEEgUklEIHN5c3RlbSBjYW4gY29udmVydCBiZXR3ZWVuIEEtbGFiZWxzIGFuZCBVLWxhYmVscyBi eSAiDQpUTzogIiBBIGFuIGFwcGxpY2F0aW9uIGNvbW11bmljYXRpbmcgdmlhIFJJRCBjYW4gY29u dmVydCBiZXR3ZWVuIEEtbGFiZWxzIGFuZCBVLWxhYmVscyBieSAiDQoNClRoaXMgd291bGQgcHV0 IHRoZSBidXJkZW4gd2l0aGluIGEgYXBwbGljYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBBUEkg dGhhdCBpcyBJT0RFRi9SSUQvUklEIFRyYW5zcG9ydC4NCldoYXQgd2UgY2FyZSBhYm91dCBpcyBj b25zaXN0ZW50IHRyYW5zcG9ydCBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gc2hhcmUgZGF0YS4g IEFzIGxvbmcgYXMgdGhlIGRhdGEgcmVjZWl2ZWQgaXMgdGhlIHNhbWUgZm9yIGV2ZXJ5IGltcGxl bWVudGF0aW9uLCB3ZSBzaG91bGRuJ3QgY2FyZSBob3cgdGhleSB1c2UgdGhlIGRvbWFpbiBuYW1l cyBpbiB0aGVpciBhcHBsaWNhdGlvbiwgcmlnaHQ/DQpfX19fX19fX19fDQpBbmQgaWYgb25seSBV LWxhYmVscyBhcmUgcGVybWl0dGVkLCB0aGVuIGNvbXBhcmlzb24gcHJvY2VlZHMgdXNpbmcgdGhl DQpVLWxhYmVscyBhcyBpbnB1dC4gSG93ZXZlciwgaWYgc28gd2UgbWlnaHQgbmVlZCB0byBzcGVj aWZ5IG1hcHBpbmdzIG9mDQp0aGUga2luZCBkaXNjdXNzZWQgaW4gUkZDIDU4OTUgKGUuZy4sIG1h cHBpbmcgdXBwZXJjYXNlIGFuZCB0aXRsZWNhc2UgdG8NCmxvd2VyY2FzZSBzbyB0aGF0IFBSw4lD SVMuZXhhbXBsZS5jb20gaXMgdHJlYXRlZCAidGhlIHNhbWUiIGFzDQpwcsOpY2lzLmV4YW1wbGUu Y29tKS4NCg0KQlVULi4uDQoNCldpbGwgUklEIHN5c3RlbXMgaW4gZmFjdCBiZSBkb2luZyBzdWNo IGNvbXBhcmlzb25zPyBUaGUgdGV4dCBmcm9tIHRoZQ0KZmlyc3QgcGFyYWdyYXBoIHF1b3RlZCBh Ym92ZSBpbmRpY2F0ZXMgdGhhdCBSSUQgc3lzdGVtcyB3aWxsIGJlIGNoZWNraW5nDQp0aGUgYXNz b2NpYXRpb24gYmV0d2VlbiBhIEROUyBkb21haW4gbmFtZSBhbmQgYW4gSVAgYWRkcmVzcywgbm90 DQpkaXJlY3RseSBjb21wYXJpbmcgRE5TIGRvbWFpbiBuYW1lcyAoaW5jbHVkaW5nIElETnMpLiBJ ZiB0aGF0IGlzIHRydWUsDQp0aGVuIHdlIHByb2JhYmx5ICpkb24ndCogbmVlZCB0byBjYXJlIG11 Y2ggYWJvdXQgY29tcGFyaXNvbiBhbmQgYW55IHRhbGsNCm9mIG1hcHBpbmdzIGlzIG1vb3QuIENh biB5b3UgcGxlYXNlIHZlcmlmeSB0aGF0IFJJRCBzeXN0ZW1zIHdpbGwgYmUNCmNoZWNraW5nIHRo ZSBhc3NvY2lhdGlvbiB3aXRoIHRoZSBJUCBhZGRyZXNzLCByYXRoZXIgdGhhbiBkaXJlY3RseQ0K Y29tcGFyaW5nIEROUyBkb21haW4gbmFtZXM/DQpfX19fX19fDQpLTU06IEkgc2VlIHlvdXIgcG9p bnQgaGVyZS4gIEhvdyBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQgdG8gbWFrZSBpdCBjbGVhciB0 aGF0IHRoZSBJUCBhZGRyZXNzIGlzIHJlcXVpcmVkIGFuZCB0aGUgRE5TIG5hbWUgaXMgZGVyaXZl ZCBmcm9tIHRoZSBJUCBhZGRyZXNzOg0KDQogICAgICAgICAxLiAgUklEU3lzdGVtLiAgVGhlIElQ IGFkZHJlc3Mgb2YgdGhlIG5leHQgdXBzdHJlYW0gc3lzdGVtIGFjY2VwdGluZyBSSUQgY29tbXVu aWNhdGlvbnMgaXMgUkVRVUlSRUQgYW5kIGlzIGxpc3RlZCBpbiB0aGUgTm9kZSBlbGVtZW50IG9m IHRoZQ0KICAgICAgICAgICAgIFJJRFBvbGljeSBjbGFzcy4gIElmIE5vZGVOYW1lIGVsZW1lbnQg b2YgdGhlIE5vZGUNCiAgICAgICAgICAgICBjbGFzcyBpcyB1c2VkLCBpdCBjb250YWlucyBhIERO UyBkb21haW4gbmFtZS4gIFRoZQ0KICAgICAgICAgICAgIG9yaWdpbmF0aW5nIFJJRCBzeXN0ZW0g aXMgcmVxdWlyZWQgdG8gY2hlY2sgdGhhdCB0aGlzDQogICAgICAgICAgICAgZG9tYWluIG5hbWUg cmVzb2x2ZXMgdG8gdGhlIElQIGFkZHJlc3MgdG8gd2hpY2ggdGhlIFJJRA0KICAgICAgICAgICAg IG1lc3NhZ2UgaXMgc2VudC4gIFRoaXMgY2hlY2sgbWF5IGJlIHBlcmZvcm1lZCBpbiBhZHZhbmNl IG9mDQogICAgICAgICAgICAgc2VuZGluZyB0aGUgbWVzc2FnZSBhbmQgdGhlIHJlc3VsdCBzYXZl ZCBmb3IgZnV0dXJlIHVzZQ0KICAgICAgICAgICAgIHdpdGggYWRkaXRpb25hbCBSSUQgbWVzc2Fn ZXMuIA0KX19fX19fDQo+ICgyKSBSSURQb2xpY3kgY2xhc3MsIE1zZ0Rlc3RpbmF0aW9uPVNvdXJj ZU9mSW5jaWRlbnQsIGFuZCBhbHNvIHRoZSBJbmNpZGVudFNvdXJjZQ0KPiBjbGFzcy4NCj4gDQo+ IEluIGJvdGggb2YgdGhlc2UgY2FzZXMgdGhlIElQIGFkZHJlc3MgaXMgdGhlIHByaW1hcnkgaWRl bnRpZmllciAoSW5jaWRlbnRTb3VyY2UNCj4gbmVlZHMgYWRkaXRpb25hbCB0ZXh0IHRvIHN0YXRl IHRoYXQgdGhlIElQIGFkZHJlc3MgaXMgcmVxdWlyZWQgLSB0aGF0IGFwcGVhcnMgdG8NCj4gaGF2 ZSBiZWVuIG92ZXJsb29rZWQpLiAgVGhlcmUgYXJlIGEgY291cGxlIG9mIG9wdGlvbnMgaGVyZToN Cj4gDQo+IGEpIFRoZSBzaW1wbGVzdCBpcyB0byBwcm9oaWJpdCBOb2RlTmFtZSB1c2FnZS4NCj4g YikgTm9kZU5hbWUgY291bGQgYmUgcmVxdWlyZWQgdG8gY29ycmVzcG9uZCB0byB0aGUgSVAgYWRk cmVzcyB2aWEgRE5TIGxvb2t1cC4NCg0KSW4gLTA5IHRoYXQgaXM6DQoNCiAgICAgICAgIDIuICBT b3VyY2VPZkluY2lkZW50LiAgVGhlIEFkZHJlc3MgZWxlbWVudCBvZiB0aGUgTm9kZSBlbGVtZW50 DQogICAgICAgICAgICAgY29udGFpbnMgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIGluY2lkZW50IHNv dXJjZSwgYW5kIHRoZQ0KICAgICAgICAgICAgIE5vZGVOYW1lIGVsZW1lbnQgb2YgdGhlIE5vZGUg Y2xhc3MgaXMgbm90IHVzZWQuICBUaGUgSVANCiAgICAgICAgICAgICBhZGRyZXNzIGlzIHVzZWQg dG8gZGV0ZXJtaW5lIHRoZSBwYXRoIG9mIHN5c3RlbXMgYWNjZXB0aW5nDQogICAgICAgICAgICAg UklEIGNvbW11bmljYXRpb25zIHRoYXQgd2lsbCBiZSB1c2VkIHRvIGZpbmQgdGhlIGNsb3Nlc3QN CiAgICAgICAgICAgICBSSUQgc3lzdGVtIHRvIHRoZSBzb3VyY2Ugb2YgYW4gYXR0YWNrIGluIHdo aWNoIHRoZSBJUA0KICAgICAgICAgICAgIGFkZHJlc3MgdXNlZCBieSB0aGUgc291cmNlIGlzIGJl bGlldmVkIHRvIGJlIHZhbGlkIGFuZCBhDQogICAgICAgICAgICAgUmVxdWVzdCBtZXNzYWdlIHdp dGggTXNnRHN0IHNldCB0byBJbnZlc3RpZ2F0aW9uUmVxdWVzdCBpcw0KICAgICAgICAgICAgIHVz ZWQuICBUaGlzIGlzIG5vdCB0byBiZSBjb25mdXNlZCB3aXRoIHRoZSBJbmNpZGVudFNvdXJjZQ0K ICAgICAgICAgICAgIGNsYXNzLCBhcyB0aGUgZGVmaW5lZCB2YWx1ZSBoZXJlIGlzIGZyb20gYW4g aW5pdGlhbCB0cmFjZQ0KICAgICAgICAgICAgIG9yIGludmVzdGlnYXRpb24gUmVxdWVzdCwgbm90 IHRoZSBzb3VyY2UgdXNlZCBpbiBhIFJlc3VsdA0KICAgICAgICAgICAgIG1lc3NhZ2UuDQoNCkkg dGhpbmsgaXQncyBmaW5lIHRvIHVzZSBJUCBhZGRyZXNzIGhlcmUuDQoNCk5PVEU6IHlvdSBzYWlk IHRoYXQgSW5jaWRlbnRTb3VyY2UgbmVlZHMgYWRkaXRpb25hbCB0ZXh0IHRvIHN0YXRlIHRoYXQN CnRoZSBJUCBhZGRyZXNzIHJlcXVpcmVkLCBidXQgSSBkbyBub3Qgc2VlIHRoYXQgaGVyZToNCl9f X19fDQpLTU06IFRoYW5rcywgaWYgd2UgYXJlIGZpeGluZyB0ZXh0LCBsZXQncyBqdXN0IGFkZCB0 aGF0IG5vdy4gIFRoaXMgb25lIHNob3VsZCBiZSBlYXN5Lg0KDQpQcm9wb3NlZDoNCiAgICAgICAg IDIuICBTb3VyY2VPZkluY2lkZW50LiAgVGhlIEFkZHJlc3MgZWxlbWVudCBvZiB0aGUgTm9kZSBl bGVtZW50DQogICAgICAgICAgICAgY29udGFpbnMgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIGluY2lk ZW50IHNvdXJjZSwgYW5kIHRoZQ0KICAgICAgICAgICAgIE5vZGVOYW1lIGVsZW1lbnQgb2YgdGhl IE5vZGUgY2xhc3MgaXMgbm90IHVzZWQuICBUaGUgSVANCiAgICAgICAgICAgICBhZGRyZXNzIGlz IFJFUVVJUkVEIHdoZW4gdGhpcyBvcHRpb24gaXMgc2VsZWN0ZWQuICBUaGUgSVAgYWRkcmVzcyBp cyB1c2VkIHRvIGRldGVybWluZSB0aGUgcGF0aCBvZiBzeXN0ZW1zIGFjY2VwdGluZw0KICAgICAg ICAgICAgIFJJRCBjb21tdW5pY2F0aW9ucyB0aGF0IHdpbGwgYmUgdXNlZCB0byBmaW5kIHRoZSBj bG9zZXN0DQogICAgICAgICAgICAgUklEIHN5c3RlbSB0byB0aGUgc291cmNlIG9mIGFuIGF0dGFj ayBpbiB3aGljaCB0aGUgSVANCiAgICAgICAgICAgICBhZGRyZXNzIHVzZWQgYnkgdGhlIHNvdXJj ZSBpcyBiZWxpZXZlZCB0byBiZSB2YWxpZCBhbmQgYQ0KICAgICAgICAgICAgIFJlcXVlc3QgbWVz c2FnZSB3aXRoIE1zZ0RzdCBzZXQgdG8gSW52ZXN0aWdhdGlvblJlcXVlc3QgaXMNCiAgICAgICAg ICAgICB1c2VkLiAgVGhpcyBpcyBub3QgdG8gYmUgY29uZnVzZWQgd2l0aCB0aGUgSW5jaWRlbnRT b3VyY2UNCiAgICAgICAgICAgICBjbGFzcywgYXMgdGhlIGRlZmluZWQgdmFsdWUgaGVyZSBpcyBm cm9tIGFuIGluaXRpYWwgdHJhY2UNCiAgICAgICAgICAgICBvciBpbnZlc3RpZ2F0aW9uIFJlcXVl c3QsIG5vdCB0aGUgc291cmNlIHVzZWQgaW4gYSBSZXN1bHQNCiAgICAgICAgICAgICBtZXNzYWdl Lg0KX19fX18NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1t aWxlLXJmYzYwNDUtYmlzLTA4JmRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28hJnVybDI9ZHJhZnQt aWV0Zi1taWxlLXJmYzYwNDUtYmlzLTA5DQoNCkhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBjYW4gYmUg YWRkZWQgYmVmb3JlIHNlbmRpbmcgdGhpcyBkb2N1bWVudCB0byB0aGUNClJGQyBFZGl0b3IsIG9y IGR1cmluZyBBVVRINDguDQoNCj4gKDMpIFJJRFBvbGljeSBjbGFzcywgTXNnRGVzdGluYXRpb249 ZXh0LXZhbHVlLiAgVGhpcyBpcyBhbiBlc2NhcGUgdGhhdCBhbGxvd3MNCj4gZXh0ZW5zaW9ucyB0 byBNc2dEZXN0aW5hdGlvbi4gIFRoZSBkZXNjcmlwdGlvbiBvZiB0aGlzIHNob3VsZCBpbmNsdWRl IGEgInRoZXJlDQo+IGJlIGRyYWdvbnMiIHdhcm5pbmcgYWJvdXQgSUROcyBpbiBOb2RlTmFtZS4N Cg0KSW4gLTA5IHRoYXQgaXM6DQoNCiAgICAgICAgIDMuICBleHQtdmFsdWUuICBBbiBlc2NhcGUg dmFsdWUgdXNlZCB0byBleHRlbmQgdGhpcyBhdHRyaWJ1dGUuDQogICAgICAgICAgICAgQWxsIGV4 dGVuc2lvbnMgc2hhbGwgc3BlY2lmeSB0aGUgY29udGVudHMgYW5kIG1lYW5pbmcgb2YNCiAgICAg ICAgICAgICB0aGUgTm9kZSBlbGVtZW50IG9mIFJJRFBvbGljeS4gIElmIHRoZSBOb2RlTmFtZSBl bGVtZW50IG9mDQogICAgICAgICAgICAgTm9kZSBpcyB1c2VkIGJ5IGFuIGV4dGVuc2lvbiwgTm9k ZU5hbWUgbWF5IGNvbnRhaW4gYW4NCiAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsaXplZCBEb21h aW4gTmFtZSAoSUROKSBhbmQgdGhhdCBJRE4gaXMNCiAgICAgICAgICAgICByZXF1aXJlZCB0byBz YXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgaW4gW1JGQzU4OTBdLiAgSXQgaXMNCiAgICAgICAgICAg ICBzdHJvbmdseSByZWNvbW1lbmRlZCB0aGF0IFJJRCBTeXN0ZW1zIHNhdGlzZnkgdGhvc2UgSURO DQogICAgICAgICAgICAgcmVxdWlyZW1lbnRzIHZpYSBhcHByb3ByaWF0ZSB1c2Ugb2YgdGhlIERO UyBhcyBvcHBvc2VkIHRvDQogICAgICAgICAgICAgaW1wbGVtZW50aW5nIHRoZWlyIG93biBjaGVj a3MgZm9yIHRoZXNlIHJlcXVpcmVtZW50cy4gIEZvcg0KICAgICAgICAgICAgIGV4YW1wbGUsIGFu IGV4dGVuc2lvbiBjb3VsZCB1c2UgYm90aCBhIE5vZGVOYW1lIGFuZCBhbiBJUA0KICAgICAgICAg ICAgIGFkZHJlc3MgdG8gd2hpY2ggdGhlIE5vZGVOYW1lIHJlc29sdmVzLiAgU2VlIElPREVGDQog ICAgICAgICAgICAgW1JGQzUwNzBdLCBTZWN0aW9uIDUuMSBvbiBleHRlbnNpYmlsaXR5Lg0KDQpU aGF0IHNlZW1zIHNsaWdodGx5IHVuZGVyc3BlY2lmaWVkOiB3aGF0IGlzIG1lYW50IGJ5ICJ0byBz YXRpc2Z5IHRoZQ0KcmVxdWlyZW1lbnRzIGluIFtSRkM1ODkwXSIgYW5kICJhcHByb3ByaWF0ZSB1 c2Ugb2YgdGhlIEROUyI/IERvZXMgdGhhdA0KbWVhbiAiZW5zdXJpbmcgdGhhdCB0aGUgSUROIHJl dHJpZXZlZCBmcm9tIHRoZSBETlMgY29uc2lzdHMgb25seSBvZg0KVS1sYWJlbHMgYW5kIE5SLUxE SCBsYWJlbHMiPyBJZiBzbywgaXMgdGhhdCBkb25lIGJ5IGFza2luZyB0aGUgRE5TDQpyZXNvbHZl ciBmb3IgVS1sYWJlbHMsIG9yIGlzIGl0IGRvbmUgYnkgYWN0aXZlbHkgcGVyZm9ybWluZyBhIGNo ZWNrIGluDQp0aGUgUklEIHN5c3RlbSBpdHNlbGYgKHNlZSBhYm92ZSBhYm91dCAiTVVTVCBOT1Qg YmUgQS1sYWJlbHMiKT8NCg0KSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyBsZWZ0IGZvciBlYWNo IGV4dGVuc2lvbiB0byBkZWZpbmU/IElmIHNvLCB3ZQ0Kc2hvdWxkIGNvbWUgb3V0IGFuZCBzYXkg cHJlY2lzZWx5IHRoYXQuDQpfX19fX19fDQpLTU06IFRoZSBpbXBvcnRhbnQgcGFydCBmb3IgUklE IGlzIHRoYXQgd2UgY29tbXVuaWNhdGUgYW5kIGV4Y2hhbmdlIG1lc3NhZ2VzIGluIGEgd2F5IHRo YXQgZXZlcnlvbmUgY2FuIGFjY2VwdCBhbmQgcHJvY2Vzcy4gIEFwcGxpY2F0aW9uIGhhbmRsaW5n IGZvciB0aGlzIHRyYW5zbGF0aW9uLCB3aGV0aGVyIGl0IGJlIGJ5IEROUyBvciBzb21lIG90aGVy IG1lY2hhbmlzbSwgcmVhbGx5IHNob3VsZG4ndCBtYXR0ZXIuICBBcyBsb25nIGFzIHRoZSBpbnRl cm5hdGlvbmFsaXphdGlvbiBpcyBoYW5kbGVkIGluIGEgd2F5IHRoYXQgbGV0cyB1cyBjb25zaXN0 ZW50bHkgZXhjaGFuZ2UgaW5mb3JtYXRpb24sIEkgdGhpbmsgdGhlIHJlYWwgaXNzdWVzIGFyZSBz b2x2ZWQsIG5vPw0KSWYgSSBhZGQgIlNlZSBTZWN0aW9uIDExIG9mIHRoaXMgZG9jdW1lbnQgZm9y DQogICAgICBJbnRlcm5hdGlvbmFsaXphdGlvbiBjb25zaWRlcmF0aW9ucy4iICBEb2VzIHRoYXQg cmVzb2x2ZSB0aGUgaXNzdWUgc2luY2UgaXQgcHJvdmlkZXMgY29uc2lzdGVudCBndWlkYW5jZSB0 aGF0IGVuYWJsZXMgdGhlIGV4Y2hhbmdlIG9mIGluZm9ybWF0aW9uPw0KX19fX19fXw0KPiBTbywg dGhlIGFuc3dlciB0byB0aGUgc29tZXdoYXQgcmhldG9yaWNhbCBxdWVzdGlvbjoNCj4gDQo+PiBE byBJT0RFRi9SSUQgaW1wbGVtZW50YXRpb25zIHdhbnQgdG8gc2lnbiB1cCBmb3IgYWxsIHRoYXQ/ DQo+IA0KPiBJcyBhcHByb3hpbWF0ZWx5ICJZZXMsIGJ5IHJlbHlpbmcgb24gdGhlIEROUyBpbXBs ZW1lbnRhdGlvbiwiIHdpdGggdGhlIGFkZGl0aW9uDQo+IG9mIGEgInRoZXJlIGJlIGRyYWdvbnMi IHdhcm5pbmcgdG8gdGhlIE1zZ0Rlc3RpbmF0aW9uIGV4dC12YWx1ZSBleHRlbnNpb24gdGV4dA0K PiB0byBjb21tdW5pY2F0ZSB0aGF0IHRvIGRlc2lnbmVycyBvZiBleHRlbnNpb25zLCBhbmQgYSBw b3NzaWJsZSBwcm9oaWJpdGlvbiBvZg0KPiB1c2Ugb2YgTm9kZU5hbWUgd2hlbiB0aGUgSVAgYWRk cmVzcyBpcyB0aGUgcHJpbWFyeSBpZGVudGlmaWVyLg0KDQpJIHRoaW5rIHdlJ3JlIGdldHRpbmcg Y2xvc2UgdG8gcmVmbGVjdGluZyB0aGF0IGluIHRleHQsIGJ1dCBhIGZldw0KY2xhcmlmaWNhdGlv bnMgd291bGQgaGVscCwgYXMgd291bGQgdmFsaWRhdGlvbiBmcm9tIHRoZSBXRyB0aGF0IHRoaXMN CmRpcmVjdGlvbiBpcyBhZ3JlZWFibGUuDQoNCkkgcmVhbGl6ZSB0aGF0IHRoZXNlIGFyZSB0aG9y bnkgaXNzdWVzIGFuZCB0aGF0IGZvbGtzIHByb2JhYmx5IGp1c3Qgd2FudA0Kc29tZW9uZSB0byBj b21lIGZyb20gb24gaGlnaCBhbmQgc2F5ICJ5ZWEgdmVyaWx5LCBoZXJlIGlzIHRoZSBvbmUgdHJ1 ZQ0KcGF0aCB0byBpbnRlcm5hdGlvbmFsaXphdGlvbiBuaXJ2YW5hIi4gVW5mb3J0dW5hdGVseSwg dGhlcmUgaXMgbm8gc3VjaA0KcGF0aCwgc28gdGhlIFdHIG5lZWRzIHRvIHdlaWdoIHRoZSBjb3N0 cyBhbmQgYmVuZWZpdHMsIGNsZWFybHkNCnVuZGVyc3RhbmQgd2hhdCBpdCdzIGRvaW5nLCBhbmQg dGhlbiBtYWtlIGEgZGVjaXNpb24gb25lIHdheSBvciB0aGUNCm90aGVyLiBXZSd2ZSBoYWQgdG9v IG1hbnkgV0dzIChzb21lIG9mIHdoaWNoIEkndmUgYmVlbiBpbnZvbHZlZCB3aXRoKQ0KanVzdCB0 YWtlIHNvbWUgaTE4biBhZHZpY2Ugd2l0aG91dCBrbm93bGVkZ2UsIGFuZCB0aGUgcmVzdWx0cyBo YXZlIGJlZW4NCmxlc3MgdGhlbiBwb3NpdGl2ZS4NCg0KVGhhbmtzIGZvciB5b3VyIHBhdGllbmNl IQ0KDQpQZXRlcg0KX19fX19fX19fDQpUaGFuayB5b3UgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3 cyENCkthdGhsZWVuDQoNCi0tIA0KUGV0ZXIgU2FpbnQtQW5kcmUNCmh0dHBzOi8vc3RwZXRlci5p bS8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bWlsZSBtYWlsaW5nIGxpc3QNCm1pbGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWlsZQ0K From david.black@emc.com Thu Jan 26 12:52: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 0C96221F85A7 for ; Thu, 26 Jan 2012 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.637 X-Spam-Level: X-Spam-Status: No, score=-107.637 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_21=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=0.6, 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 wtpvbtQR7dLj for ; Thu, 26 Jan 2012 12:52:14 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9581921F8545 for ; Thu, 26 Jan 2012 12:52:12 -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 q0QKqA2c008891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 15:52:11 -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, 26 Jan 2012 15:51:57 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0QKpu4E031386; Thu, 26 Jan 2012 15:51:56 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 26 Jan 2012 15:51:55 -0500 From: To: , Date: Thu, 26 Jan 2012 15:51:55 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczcaIef4xG/bLuNTjed/Nycym4xUQAAlWxg Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> In-Reply-To: <4F21B683.20604@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 26 Jan 2012 20:52:16 -0000 PiA+PiBJZiB5b3UgYXJlIG5vdCBjb25jZXJuZWQgYWJvdXQgb25lIFJJRCBtZW1iZXIgbWFzcXVl cmFkaW5nIGFzIGFub3RoZXIsDQo+ID4+IGl0IG1pZ2h0IGJlIHN1ZmZpY2llbnQgZm9yIHlvdXIg cHJvdG9jb2wgdG8gYWxsb3cgY2xpZW50IGNlcnRpZmljYXRlcyB0bw0KPiA+PiBjb21lIGZyb20g YSBrbm93biBDQSAob3IgYSBzZXQgb2YgQ0FzKSwgb3IgYmUgd2hpdGVsaXN0ZWQuICBTbyBiYXNp Y2FsbHkNCj4gPj4geW91IHdpbGwgdXNlIG1vcmUgcmVsYXhlZCB2ZXJpZmljYXRpb24gcnVsZXMg ZnJvbSBSRkMgNTI4MC4NCg0KPiA+IFdlbGwsIEkgdGhpbmsgeW91J2QgcHJvYmFibHkgc3RpbGwg d2FudCB0byBkbyB0aGUgZG9tYWluIGNoZWNrLCBubz8NCg0KPiBIb3cgd291bGQgeW91IGRlcml2 ZSBhIGRvbWFpbiBuYW1lIGZvciB0aGUgY29ubmVjdGluZyBlbnRyeSAod2hhdCBJDQo+IGNhbGxl ZCAiY2xpZW50Iik/IFRoZSBzZXJ2ZXIgb25seSBoYXMgYW4gSVAgYWRkcmVzcyBhbmQgcG9ydC4g U28gb3RoZXINCj4gdGhhbiBkb2luZyByZXZlcnNlIEROUyBtYXBwaW5nIG9yIHNpbWlsYXIsIEkg ZG9uJ3QgdGhpbmsgYW55dGhpbmcgd2lsbA0KPiByZXN1bHQgaW4gYSBkb21haW4uDQoNClRoZSBI VFRQL1RMUyBjbGllbnQgY2FuIGNoZWNrIHRoZSBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZSBhZ2FpbnN0 IHRoZSBkb21haW4NCmluIHRoZSBVUkwsIGFuZCBJIHJlYWQgUkZDIDYxMjUgYXMgcmVxdWlyaW5n IHRoaXMgY2hlY2suICBUaGUgSFRUUC9UTFMNCnNlcnZlciBuZWVkcyB0byBkbyBzb21ldGhpbmcg ZWxzZS4NCg0KVGhlIGN1cnJlbnQgLTA5IHZlcnNpb24gb2YgNjA0Ni1iaXMgcmVxdWlyZXMgdGhh dCBzdWZmaWNpZW50IGRvbWFpbiBuYW1lDQppbmZvcm1hdGlvbiBiZSBrZXB0IGJhc2VkIG9uIGNv bnNvcnRpdW0gc2V0dXAgc28gdGhhdCBib3RoIHRoZSBIVFRQL1RMUw0KY2xpZW50IGFuZCBzZXJ2 ZXIgY2FuIGJvdGggcGVyZm9ybSBhIGRvbWFpbiBuYW1lIHJlZmVyZW5jZSBpZGVudGlmaWVyDQpj aGVjayBhZ2FpbnN0IHRoZSBUTFMgY2VydGlmaWNhdGUgcHJlc2VudGVkIGJ5IHRoZSBvdGhlciBw YXJ0eToNCg0KICAgVGhlIHVzZSBvZiBzdGFibGUgRE5TIG5hbWVzIHRvIGFkZHJlc3MgUklEIHN5 c3RlbXMgaXMgUkVDT01NRU5ERUQ7IGluDQogICBhZGRpdGlvbiB0byBmYWNpbGl0YXRpbmcgY29u bmVjdGlvbiB0byBSSUQgc3lzdGVtcyB3aXRoaW4gYQ0KICAgY29uc29ydGl1bSwgdGhlc2UgYXJl IHRvIGJlIHVzZWQgYXMgcmVmZXJlbmNlIGlkZW50aWZpZXJzIGZvciBhIFJJRA0KICAgc3lzdGVt J3MgcGVlcnMuICBbLi4uIHVucmVsYXRlZCBzZW50ZW5jZSBzbmlwcGVkIC4uLl0NCiAgIFRoZSBw cm90b2NvbCBwcm92aWRlcyBubyBpbi1iYW5kIG1ldGhvZCBmb3IgaGFuZGxpbmcgYQ0KICAgY2hh bmdlIG9mIGFkZHJlc3Mgb2YgYSBSSUQgc3lzdGVtLg0KDQouLi4NCg0KICAgQWxsIFJJRCBzeXN0 ZW1zIE1VU1QgYmUgaWRlbnRpZmllZCBieSBhIGNlcnRpZmljYXRlIGNvbnRhaW5pbmcgYQ0KICAg RE5TLUlEIGlkZW50aWZpZXIgW1JGQzUyODBdIGFzIGluIHNlY3Rpb24gNi40IG9mIFtSRkM2MTI1 XTsgUklEDQogICBzeXN0ZW1zIE1VU1QgdmVyaWZ5IHRoZSByZWZlcmVuY2UgaWRlbnRpZmllcnMg b2YgdGhlaXIgcGVlcnMgYWdhaW5zdA0KICAgdGhvc2Ugc3RvcmVkIGluIHRoZSBjZXJ0aWZpY2F0 ZXMgcHJlc2VudGVkLg0KDQpUaGFua3MsDQotLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogQWxleGV5IE1lbG5pa292IFttYWlsdG86YWxleGV5Lm1lbG5pa292 QGlzb2RlLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjYsIDIwMTIgMzoyNSBQTQ0K PiBUbzogUGV0ZXIgU2FpbnQtQW5kcmUNCj4gQ2M6IEJyaWFuIFRyYW1tZWxsOyBCbGFjaywgRGF2 aWQ7IE1vcmlhcnR5LCBLYXRobGVlbjsgU2VhbiBUdXJuZXI7IG1pbGVAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFttaWxlXSA2MDQ2LWJpcyAtIENsaWVudCBjZXJ0aWZpY2F0ZSBpZGVudGl0eSBj aGVjaw0KPg0KPiBPbiAyNi8wMS8yMDEyIDE5OjM0LCBQZXRlciBTYWludC1BbmRyZSB3cm90ZToN Cj4gPiBPbiAxLzI2LzEyIDEyOjIxIFBNLCBBbGV4ZXkgTWVsbmlrb3Ygd3JvdGU6DQo+ID4+IE9u IDI1LzAxLzIwMTIgMjE6MTcsIEJyaWFuIFRyYW1tZWxsIHdyb3RlOg0KPiA+Pj4gSGksIERhdmlk LA0KPiA+Pj4NCj4gPj4+IFRoZSByZWZlcmVuY2UgaWRlbnRpZmllciAoZGVmaW5lZCBpbiBSRkMg NjIxNSBzZWN0aW9uIDEuODsgZXhwbGFpbmVkDQo+ID4+PiBpbiA2LjIpIGluIFJJRCB0cmFuc3Bv cnQgaXMgKHByZXN1bWFibHkpIHRoZSBpZGVudGl0eSBvbmUgc3lzdGVtIHVzZXMNCj4gPj4+IHRv IGNvbm5lY3QgdG8gYW5vdGhlciAoc2VlIHBhcmFncmFwaCAxMiBvZiA2MDQ2LWJpcy0wOCBzZWN0 aW9uIDM6DQo+ID4+PiAiLi4udGhlIHVzZSBvZiBzdGFibGUgRE5TIG5hbWVzIHRvIGFkZHJlc3Mg UklEIFN5c3RlbXMgaXMNCj4gPj4+IFJFQ09NTUVOREVEIikuIFRoaXMgY291bGQgcGVyaGFwcyBi ZSBtYWRlIG1vcmUgZXhwbGljaXQgYnV0IGl0IHNlZW1lZA0KPiA+Pj4gb2J2aW91cyBlbm91Z2gu DQo+ID4+Pg0KPiA+Pj4gRm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiwgdGhpcyB3b3VsZCBoYXZl IHRvIGJlIGRlcml2ZWQgZnJvbSBhDQo+ID4+PiByZXZlcnNlIG1hcHBpbmcgb2YgdGhlIG5ldHdv cmsgYWRkcmVzcyBiYWNrIHRvIGEgbmFtZSAoZWl0aGVyIGJ5IEROUw0KPiA+Pj4gUFRSIHJlY29y ZHMsIG9yIGEgd2hpdGVsaXN0IG9mIGNvbnNvcnRpdW0gbWVtYmVycykuDQo+ID4+IERhdmlkIGlz IGNvcnJlY3QgdGhhdCBSRkMgNjEyNSBjYW4gb25seSBiZSB1c2VkIGJ5IHRoZSBlbnRpdHkgdGhh dA0KPiA+PiBhY3RpdmVseSBjb25uZWN0IHRvIGFub3RoZXIgb25lIChpLmUuIGJ5IHRoZSBjbGll bnQgdG8gdmVyaWZ5IHRoZSBzZXJ2ZXIpLg0KPiA+IEVuZ2xpc2ggbml0OiBzL2kuZS4vZS5nLi8g KGJlY2F1c2UgaXQgY2FuIGJlIHVzZWQgYnkgb25lIHNlcnZlcg0KPiA+IGNvbm5lY3RpbmcgdG8g YW5vdGhlciBzZXJ2ZXIsIGFzIHdlJ3JlIHNvcnQgb2YgZG9pbmcgaGVyZSkuDQo+IEEgc2VydmVy IGNvbm5lY3RpbmcgdG8gYW5vdGhlciBpcyBhY3RpbmcgYXMgYSBjbGllbnQsIGJ1dCBuZXZlciBt aW5kIDstKS4NCj4gPj4gSWYgeW91IGZpbmQgdGhlIGJ1cmRlbiBvZiBtYWludGFpbmluZyB0aGUg cmV2ZXJzZSBETlMgbWFwcGluZyB0byBiZQ0KPiA+PiBhY2NlcHRhYmxlIGZvciB5b3VyIHByb3Rv Y29sIChmb3IgZGVwbG95bWVudHMgb2Ygc29tZSBvdGhlciBwcm90b2NvbHMsDQo+ID4+IGxpa2Ug U01UUCB0aGF0IGJ1cmRlbiB3YXMgZm91bmQgdG8gYmUgdW5hY2NlcHRhYmxlKSwgdGhlbiB5b3Ug Y2FuIHVzZQ0KPiA+PiBSRkMgNjEyNSBmb3IgdmVyaWZ5aW5nIGNsaWVudHMgYnkgc2VydmVycy4N Cj4gPiBNeSBzZW5zZSBpcyB0aGF0IGluIFJJRCBjb25zb3J0aWEsIHRoaXMgaXMgc2VlbiBhcyBh biBhY2NlcHRhYmxlIGJ1cmRlbg0KPiA+IGJlY2F1c2UgdGhlIG51bWJlciBvZiBtZW1iZXJzIGlu IGVhY2ggY29uc29ydGl1bSBpcyBtYW5hZ2VhYmxlLiBCdXQNCj4gPiB0aGF0J3Mgc29tZXRoaW5n IHRoYXQgUklEIHBhcnRpY2lwYW50cyBwcm9iYWJseSBuZWVkIHRvIHZlcmlmeS4NCj4gQWdyZWVk Lg0KPiA+PiBJZiB5b3UgYXJlIG5vdCBjb25jZXJuZWQgYWJvdXQgb25lIFJJRCBtZW1iZXIgbWFz cXVlcmFkaW5nIGFzIGFub3RoZXIsDQo+ID4+IGl0IG1pZ2h0IGJlIHN1ZmZpY2llbnQgZm9yIHlv dXIgcHJvdG9jb2wgdG8gYWxsb3cgY2xpZW50IGNlcnRpZmljYXRlcyB0bw0KPiA+PiBjb21lIGZy b20gYSBrbm93biBDQSAob3IgYSBzZXQgb2YgQ0FzKSwgb3IgYmUgd2hpdGVsaXN0ZWQuICBTbyBi YXNpY2FsbHkNCj4gPj4geW91IHdpbGwgdXNlIG1vcmUgcmVsYXhlZCB2ZXJpZmljYXRpb24gcnVs ZXMgZnJvbSBSRkMgNTI4MC4NCj4gPiBXZWxsLCBJIHRoaW5rIHlvdSdkIHByb2JhYmx5IHN0aWxs IHdhbnQgdG8gZG8gdGhlIGRvbWFpbiBjaGVjaywgbm8/DQo+IEhvdyB3b3VsZCB5b3UgZGVyaXZl IGEgZG9tYWluIG5hbWUgZm9yIHRoZSBjb25uZWN0aW5nIGVudHJ5ICh3aGF0IEkNCj4gY2FsbGVk ICJjbGllbnQiKT8gVGhlIHNlcnZlciBvbmx5IGhhcyBhbiBJUCBhZGRyZXNzIGFuZCBwb3J0LiBT byBvdGhlcg0KPiB0aGFuIGRvaW5nIHJldmVyc2UgRE5TIG1hcHBpbmcgb3Igc2ltaWxhciwgSSBk b24ndCB0aGluayBhbnl0aGluZyB3aWxsDQo+IHJlc3VsdCBpbiBhIGRvbWFpbi4NCj4gPj4+IFBl cmhhcHMgc3RhdGluZyAiZWFjaCBSSUQgc3lzdGVtIE1VU1QgbWFpbnRhaW4gYSBETlMtSUQgcmVm ZXJlbmNlDQo+ID4+PiBpZGVudGlmaWVyIGZvciB0aG9zZSBSSUQgc3lzdGVtcyBpdCBwYXJ0aWNp cGF0ZXMgaW4gYSBjb25zb3J0aXVtIHdpdGgsDQo+ID4+PiBhbmQgdXNlIHRoaXMgZm9yIGNvbXBh cmlzb24gd2l0aCB0aGUgRE5TLUlEIHN0b3JlZCBpbiB0aGUgY2VydGlmaWNhdGUNCj4gPj4+IHBy ZXNlbnRlZCBieSBSSUQgc3lzdGVtIHBlZXJzIiB3b3VsZCBhZGRyZXNzIHRoaXMgY29uY2Vybj8N Cj4gPj4+IFJlZ2FyZHMsDQo+ID4+Pg0KPiA+Pj4gQnJpYW4NCj4gPj4+DQo+ID4+PiBPbiBKYW4g MjUsIDIwMTIsIGF0IDk6MjQgUE0sPGRhdmlkLmJsYWNrQGVtYy5jb20+DQo+ID4+PiA8ZGF2aWQu YmxhY2tAZW1jLmNvbT4gICB3cm90ZToNCj4gPj4+DQo+ID4+Pj4gSGkgQnJpYW4sDQo+ID4+Pj4N Cj4gPj4+PiBLYXRobGVlbiBxdWlja2x5IGRpc3Bvc2VkIG9mICMxLCBzbyBwbGVhc2UgaWdub3Jl IHRoYXQuICBTaGUnbGwgYWRkDQo+ID4+Pj4gc29tZSB0ZXh0IHRvDQo+ID4+Pj4gNjA0NS1iaXMg dG8gaGVscCBvdGhlciByZWFkZXJzIGF2b2lkIHRoZSBtaXN0YWtlIHRoYXQgSSBtYWRlLg0KPiA+ Pj4+DQo+ID4+Pj4gRm9yICMyLCB0aGUgc2hvcnQgc3VtbWFyeSBvZiBteSBjb25jZXJuIHdpdGgg dGhlIGN1cnJlbnQgdGV4dA0KPiA+Pj4+IGludm9sdmVzIHRoaXMgc2VudGVuY2U6DQo+ID4+Pj4N Cj4gPj4+Pj4gICAgICA8dD5SSUQgc3lzdGVtcyBNVVNUIHZlcmlmeSB0aGUgaWRlbnRpdHkgb2Yg dGhlaXIgcGVlcnMgYWdhaW5zdA0KPiA+Pj4+PiB0aGF0IHN0b3JlZA0KPiA+Pj4+PiAgICAgIGlu IHRoZSBjZXJ0aWZpY2F0ZSBwcmVzZW50ZWQuDQo+ID4+Pj4gSG93IGRvZXMgYSBSSUQgc3lzdGVt IChhcyBUTFMgY2xpZW50IG9yIHNlcnZlcikgZG8gdGhhdD8NCj4gPj4+Pg0KPiA+Pj4+IFRoZSBu ZXh0IHNlbnRlbmNlIGV4cGxhaW5zIHdoYXQgdGhlIGlkZW50aXR5IGlzLCBidXQgbm90IGhvdyB0 bw0KPiA+Pj4+IHZlcmlmeSBpdDoNCj4gPj4+Pg0KPiA+Pj4+PiAgICAgIEFsbCBSSUQgc3lzdGVt cyBNVVNUIGJlIGlkZW50aWZpZWQgYnkgYQ0KPiA+Pj4+PiAgICAgIGNlcnRpZmljYXRlIGNvbnRh aW5pbmcgYTx4cmVmIHRhcmdldD0iUkZDNTI4MCI+RE5TLUlEDQo+ID4+Pj4+IGlkZW50aWZpZXI8 L3hyZWY+DQo+ID4+Pj4+ICAgICAgYXMgaW4gc2VjdGlvbiA2LjQgb2Y8eHJlZiB0YXJnZXQ9IlJG QzYxMjUiLz4uDQo+ID4+Pj4gSW4gcGFydGljdWxhciwgc2VjdGlvbiA2LjQgb2YgUkZDIDYxMjUg ZG9lc24ndCBzcGVjaWZ5IHdoYXQgdGhlDQo+ID4+Pj4gY2VydGlmaWNhdGUgaWRlbnRpdHkNCj4g Pj4+PiBpcyBjaGVja2VkIGFnYWluc3QuICBJdCBtYXkgZXZlbiBiZSB0aGF0IHNlY3Rpb24gNi40 IG9mIFJGQyA2MTI1DQo+ID4+Pj4gZG9lc24ndCBhcHBseSB0bw0KPiA+Pj4+IGNsaWVudCBjZXJ0 aWZpY2F0ZXMsIGJlY2F1c2UgdGhlIGNsaWVudCBpZGVudGl0eSBjaGVjayBteSBiZSBzdWJzdW1l ZA0KPiA+Pj4+IGJ5IFBLSVggcGF0aA0KPiA+Pj4+IHZhbGlkYXRpb24gb2YgdGhlIGNsaWVudCBj ZXJ0aWZpY2F0ZSBhZ2FpbnN0IHRoZSBzZXJ2ZXIncyB0cnVzdA0KPiA+Pj4+IHN0b3JlLCB3aGlj aCBkb2VzDQo+ID4+Pj4gbmFtZSBjb21wYXJpc29uIGFjY29yZGluZyB0byBSRkMgNTI4MCwgbm90 IFJGQyA2MTI1Lg0KPiA+Pj4+DQo+ID4+Pj4gQSBzZW50ZW5jZSBvciB0d28gb24gaG93IHRvIGRv IHRoYXQgcmVxdWlyZWQgKE1VU1QpIGlkZW50aXR5DQo+ID4+Pj4gdmVyaWZpY2F0aW9uIHdvdWxk IGhlbHAuDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MsDQo+ID4+Pj4gLS1EYXZpZA0KPiA+Pj4+DQo+ ID4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4gRnJvbTog TW9yaWFydHksIEthdGhsZWVuDQo+ID4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNSwg MjAxMiAyOjU1IFBNDQo+ID4+Pj4+IFRvOiBCcmlhbiBUcmFtbWVsbDsgQmxhY2ssIERhdmlkDQo+ ID4+Pj4+IENjOiBtaWxlQGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJFOiBbbWlsZV0gNjA0 Ni1iaXMgLSBDbGllbnQgY2VydGlmaWNhdGUgaWRlbnRpdHkgY2hlY2sNCj4gPj4+Pj4NCj4gPj4+ Pj4gSGkgQnJpYW4sDQo+ID4+Pj4+DQo+ID4+Pj4+IFlvdSBjYW4gc2F2ZSB5b3VyIHRpbWUgb24g IzEsIHRoZSBxdWVzdGlvbi9yZXF1ZXN0IHdhcyB3aXRoZHJhd24uDQo+ID4+Pj4+IFRoZSBzZW5k aW5nIFJJRCBzZXJ2ZXIgbWF5IG9ubHkNCj4gPj4+Pj4gYXBwZWFyIHdpdGhpbiB0aGUgSU9ERUYg ZG9jdW1lbnQgYW5kIG5vdCB0aGUgUklEIFhNTCBkb2N1bWVudC4NCj4gPj4+Pj4NCj4gPj4+Pj4g VGhhbmsgeW91LA0KPiA+Pj4+PiBLYXRobGVlbg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+PiBGcm9tOiBCcmlhbiBUcmFtbWVsbCBbbWFpbHRvOnRy YW1tZWxsQHRpay5lZS5ldGh6LmNoXQ0KPiA+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkg MjUsIDIwMTIgMjo1MSBQTQ0KPiA+Pj4+PiBUbzogQmxhY2ssIERhdmlkDQo+ID4+Pj4+IENjOiBN b3JpYXJ0eSwgS2F0aGxlZW47IG1pbGVAaWV0Zi5vcmcNCj4gPj4+Pj4gU3ViamVjdDogUmU6IFtt aWxlXSA2MDQ2LWJpcyAtIENsaWVudCBjZXJ0aWZpY2F0ZSBpZGVudGl0eSBjaGVjaw0KPiA+Pj4+ Pg0KPiA+Pj4+PiBIaSwgRGF2aWQsDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoYW5rcyBmb3IgdGhlIGNv bW1lbnRzOyBJJ3ZlIGJlZW4gb3V0IG9mIGNvbnRhY3QgYWxsIGRheSBzbyBhbQ0KPiA+Pj4+PiBj YXRjaGluZyB1cC4gSSdsbCB0b3AtcG9zdCBteSBzdW1tYXJ5DQo+ID4+Pj4+IHJlcGx5IGF0IGZp cnN0OyBJIG1heSBoYXZlIGZ1cnRoZXIgZGV0YWlsIHJlcGxpZXMgaW4gYSBzdWJzZXF1ZW50DQo+ ID4+Pj4+IG1lc3NhZ2UuDQo+ID4+Pj4+DQo+ID4+Pj4+IDEuIEkgd291bGQgbmVlZCB0byB0aGlu ayBtb3JlIGRlZXBseSBhYm91dCB0aGUgaW1wbGljYXRpb25zIG9mIGFueQ0KPiA+Pj4+PiBhdXRo ZW50aWNhdGlvbiBhbHNvIGNyb3NzLWNoZWNraW5nDQo+ID4+Pj4+IHRoZSBETlMtSUQgYWdhaW5z dCBub3Qgb25seSBuZXR3b3JrLWxheWVyIGF2YWlsYWJsZSBpZGVudGlmaWVycyBidXQNCj4gPj4+ Pj4gYWxzbyBhZ2FpbnN0IGluZm9ybWF0aW9uIHN0b3JlZA0KPiA+Pj4+PiB3aXRoaW4gdGhlIFJJ RCBkb2N1bWVudCBpdHNlbGYuIFRoZXJlIHNlZW1zIHRvIGJlIGEgYml0IG9mIGEgY2hpY2tlbg0K PiA+Pj4+PiBhbmQgZWdnIHByb2JsZW0gdGhlcmUsIGFuZCBpdA0KPiA+Pj4+PiBzZWVtcyB0byBt ZSB0aGF0IHRoZXJlIG1heSBiZSB2YWxpZCBleGNlcHRpb25zIHRvIGEgcG9saWN5IHRoYXQNCj4g Pj4+Pj4gd291bGQgYmUgc2ltcGxlIGVub3VnaCB0byBiZSAoYSkNCj4gPj4+Pj4gaW1wbGVtZW50 YWJsZSBhbmQgKGIpIHZlcmlmaWFibGUuDQo+ID4+Pj4+DQo+ID4+Pj4+IDIuIEl0IGlzIG5vdCB0 aGUgaW50ZW50IHRoYXQgNjEyNSBzZWN0aW9uIDQgYXBwbGllcyBzb2xlbHkgdG8gdGhlDQo+ID4+ Pj4+IGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBUTFMgc2VydmVyOw0KPiA+Pj4+PiBfYWxsXyBhdXRo ZW50aWNhdGlvbiBpbiBSSUQgb3ZlciBIVFRQUyBtdXN0IGJlIG11dHVhbCwgYW5kIEkgYmVsaWV2 ZQ0KPiA+Pj4+PiB0aGUgY3VycmVudCBwcm9wb3NlZCB0ZXh0IChjb3BpZWQNCj4gPj4+Pj4gYmVs b3cgc3RyYWlnaHQgZnJvbSB4bWwgc291cmNlKSB0byBiZSBjbGVhciBvbiB0aGlzIHBvaW50LCBp bg0KPiA+Pj4+PiBjb250ZXh0LiBJZiB0aGF0J3Mgbm90IHRoZSBjYXNlLCB0aGVuDQo+ID4+Pj4+ IHdlJ2xsIG5lZWQgdG8gY2hhbmdlIGl0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgIDx0PlJJRCBz eXN0ZW1zIE1VU1QgdXNlIFRMUyB2ZXJzaW9uIDEuMTx4cmVmIHRhcmdldD0iUkZDNDM0NiIvPg0K PiA+Pj4+PiBvciBoaWdoZXINCj4gPj4+Pj4gICAgICBmb3IgY29uZmlkZW50aWFsaXR5LCBpZGVu dGlmaWNhdGlvbiwgYW5kIGF1dGhlbnRpY2F0aW9uLCB3aGVuDQo+ID4+Pj4+IHNlbmRpbmcgUklE DQo+ID4+Pj4+ICAgICAgbWVzc2FnZXMgb3ZlciBIVFRQUy4gSFRUUFMgaXMgc3BlY2lmaWVkIGlu IFNlY3Rpb24gMiBvZjx4cmVmDQo+ID4+Pj4+ICAgICAgdGFyZ2V0PSJSRkMyODE4Ii8+LiBSSUQg c3lzdGVtcyBNVVNUIHVzZSBtdXR1YWwgYXV0aGVudGljYXRpb247DQo+ID4+Pj4+IHRoYXQgaXMs DQo+ID4+Pj4+ICAgICAgYm90aCBSSUQgc3lzdGVtcyBhY3RpbmcgYXMgSFRUUFMgY2xpZW50cyBh bmQgUklEIHN5c3RlbXMgYWN0aW5nDQo+ID4+Pj4+IGFzIEhUVFBTDQo+ID4+Pj4+ICAgICAgc2Vy dmVycyBNVVNUIGJlIGlkZW50aWZpZWQgYnkgYW48eHJlZiB0YXJnZXQ9IlJGQzUyODAiPlguNTA5 DQo+ID4+Pj4+ICAgICAgY2VydGlmaWNhdGU8L3hyZWY+LiBNdXR1YWwgYXV0aGVudGljYXRpb24g cmVxdWlyZXMgZnVsbCBwYXRoDQo+ID4+Pj4+IHZhbGlkYXRpb24gb24NCj4gPj4+Pj4gICAgICBl YWNoIGNlcnRpZmljYXRlLCBhcyBkZWZpbmVkIGluPHhyZWYgdGFyZ2V0PSJSRkM1MjgwIi8+Ljwv dD4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICA8dD5UaGUgVExTIHNlc3Npb24gTVVTVCB1c2Ugbm9u LU5VTEwgY2lwaGVyc3VpdGVzIGZvcg0KPiA+Pj4+PiBhdXRoZW50aWNhdGlvbiwNCj4gPj4+Pj4g ICAgICBpbnRlZ3JpdHksIGFuZCBjb25maWRlbnRpYWxpdHkuIFNlc3Npb25zIE1BWSBiZSByZW5l Z290aWF0ZWQNCj4gPj4+Pj4gd2l0aGluIHRoZXNlDQo+ID4+Pj4+ICAgICAgY29uc3RyYWludHMu PC90Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgIDx0PlJJRCBzeXN0ZW1zIE1VU1QgdmVyaWZ5IHRo ZSBpZGVudGl0eSBvZiB0aGVpciBwZWVycyBhZ2FpbnN0DQo+ID4+Pj4+IHRoYXQgc3RvcmVkDQo+ ID4+Pj4+ICAgICAgaW4gdGhlIGNlcnRpZmljYXRlIHByZXNlbnRlZC4gQWxsIFJJRCBzeXN0ZW1z IE1VU1QgYmUgaWRlbnRpZmllZA0KPiA+Pj4+PiBieSBhDQo+ID4+Pj4+ICAgICAgY2VydGlmaWNh dGUgY29udGFpbmluZyBhPHhyZWYgdGFyZ2V0PSJSRkM1MjgwIj5ETlMtSUQNCj4gPj4+Pj4gaWRl bnRpZmllcjwveHJlZj4NCj4gPj4+Pj4gICAgICBhcyBpbiBzZWN0aW9uIDYuNCBvZjx4cmVmIHRh cmdldD0iUkZDNjEyNSIvPi4gVGhlIGluY2x1c2lvbiBvZg0KPiA+Pj4+PiBDb21tb24NCj4gPj4+ Pj4gICAgICBOYW1lcyAoQ04tSURzKSBpbiBjZXJ0aWZpY2F0ZXMgaWRlbnRpZnlpbmcgUklEIHN5 c3RlbXMgaXMgTk9UDQo+ID4+Pj4+IFJFQ09NTUVOREVELg0KPiA+Pj4+PiAgICAgIFdpbGRjYXJk cyBNVVNUIE5PVCBhcHBlYXIgaW4gdGhlIEROUy1JRCBvciBDTi1JRCBvZiBhIGNlcnRpZmljYXRl DQo+ID4+Pj4+ICAgICAgaWRlbnRpZnlpbmcgYSBSSUQgc3lzdGVtLiBBZGRpdGlvbmFsIGdlbmVy YWwgaW5mb3JtYXRpb24gb24gdGhlDQo+ID4+Pj4+IHVzZSBvZiBQS0kNCj4gPj4+Pj4gICAgICB3 aXRoIFJJRCBzeXN0ZW1zIGlzIGRldGFpbGVkIGluIFNlY3Rpb24gOS4zIG9mPHhyZWYNCj4gPj4+ Pj4gICAgICB0YXJnZXQ9IkktRC5pZXRmLW1pbGUtcmZjNjA0NS1iaXMiLz4uPC90Pg0KPiA+Pj4+ Pg0KPiA+Pj4+PiAgICAgIDx0PlJJRCBzeXN0ZW1zIE1VU1Qgc3VwcG9ydCBUTFMgdmVyc2lvbiAx LjEgYW5kIFNIT1VMRCBzdXBwb3J0DQo+ID4+Pj4+IFRMUyB2ZXJzaW9uDQo+ID4+Pj4+ICAgICAg MS4yPHhyZWYgdGFyZ2V0PSJSRkM1MjQ2Ii8+OyBSSUQgc3lzdGVtcyBNVVNUIE5PVCByZXF1ZXN0 LA0KPiA+Pj4+PiBvZmZlciwgb3IgdXNlDQo+ID4+Pj4+ICAgICAgYW55IHZlcnNpb24gb2YgU1NM LCBvciBhbnkgdmVyc2lvbiBvZiBUTFMgcHJpb3IgdG8gMS4xLCBkdWUgdG8NCj4gPj4+Pj4ga25v d24NCj4gPj4+Pj4gICAgICBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMgaW4gcHJpb3IgdmVyc2lv bnMgb2YgdGhlIHByb3RvY29sOyBzZWUNCj4gPj4+Pj4gQXBwZW5kaXggRQ0KPiA+Pj4+PiAgICAg IG9mPHhyZWYgdGFyZ2V0PSJSRkM1MjQ2Ii8+ICAgZm9yIG1vcmUuPC90Pg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+DQo+ID4+Pj4+IEJyaWFuDQo+ID4+Pj4+DQo+ID4+ Pj4+IE9uIEphbiAyNSwgMjAxMiwgYXQgODowMCBQTSw8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gICB3 cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4+IEhpIEthdGhsZWVuLA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IEkgbWlzc2VkIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gTm9kZSBhbmQgTXNnRGVzdGluYXRpb24g aW4gNjA0NS1iaXMNCj4gPj4+Pj4+IC0gbXkgbWlzdGFrZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJ dCBtaWdodCBiZSB1c2VmdWwgdG8gcmVwZWF0IHRoZSBmb2xsb3dpbmcgdGV4dCBmcm9tIHRoZQ0K PiA+Pj4+Pj4gc3BlY2lmaWNhdGlvbiBvZiAiTXNnRGVzdGluYXRpb24iDQo+ID4+Pj4+PiBpbiB0 aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgTm9kZSBlbGVtZW50IGluIFJJRFBvbGljeSwgYXMgdGhv c2UNCj4gPj4+Pj4+IHNwZWNpZmljYXRpb25zIGFyZSA1DQo+ID4+Pj4+PiBwYWdlcyBhcGFydCwg YW5kIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gb2YgdGhlIE5vZGUgZWxlbWVudCBpcw0KPiA+ Pj4+Pj4gbm90IHByZWNpc2UgYWJvdXQNCj4gPj4+Pj4+IHVzYWdlOg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+ICAgICAgICAgIHRoZSBtZWFuaW5nIG9mIHRoZSB2YWx1ZQ0KPiA+Pj4+Pj4gICAgICAgICAg aW4gdGhlIE5vZGUgZWxlbWVudCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBNc2dEZXN0aW5hdGlvbg0K PiA+Pj4+Pj4gZWxlbWVudA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE9UT0gsIEkgbm93IGRvbid0IHNl ZSBhbnl0aGluZyBpbiBSSUQgdGhhdCByZXByZXNlbnRzIHRoZSBpZGVudGl0eQ0KPiA+Pj4+Pj4g b2YgdGhlIHN5c3RlbSBzZW5kaW5nDQo+ID4+Pj4+PiB0aGUgUklEIG1lc3NhZ2UsIGFuZCBJIGRv bid0IHRoaW5rIGFkZGluZyB0aGF0IGlzIGltcG9ydGFudCBlbm91Z2gNCj4gPj4+Pj4+IHRvIG1h a2UgYSBjaGFuZ2UgYXQNCj4gPj4+Pj4+IHRoaXMganVuY3R1cmUuICBJIGFsc28gZG9uJ3Qgc2Vl IGFueSBwb2ludCBpbiB0cnlpbmcgdG8gdXNlIHRoZQ0KPiA+Pj4+Pj4gZW52ZWxvcGVkIElPREVG IGRvY3VtZW50DQo+ID4+Pj4+PiB0byBjYXJyeSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNlbmRpbmcg UklEIHN5c3RlbSwgYXMgdGhhdCBkb2N1bWVudA0KPiA+Pj4+Pj4gY291bGQgZ2V0IGZvcndhcmRl ZA0KPiA+Pj4+Pj4gaW4gYSBkaWZmZXJlbnQgUklEIG1lc3NhZ2UsIGZvciB3aGljaCBpdCB3b3Vs ZCBjb250YWluIHRoZSB3cm9uZw0KPiA+Pj4+Pj4gc2VuZGluZyBSSUQgc3lzdGVtDQo+ID4+Pj4+ PiBpZGVudGl0eS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJZiB0aGVyZSdzIG5vIGluc3RhbmNlIG9m IHRoZSBzZW5kaW5nIFJJRCBzeXN0ZW0ncyBpZGVudGl0eSBpbiB0aGUNCj4gPj4+Pj4+IFJJRCBt ZXNzYWdlLCB0aGVuIEkNCj4gPj4+Pj4+IHN1cHBvc2UgdGhlIGNsaWVudCBpZGVudGl0eSB2ZXJp ZmljYXRpb24gd291bGQgaGF2ZSB0byBiZSBiYXNlZCBvbg0KPiA+Pj4+Pj4gdGhlIGluZm9ybWF0 aW9uIHVzZWQNCj4gPj4+Pj4+IHRvIHNldCB1cCB0aGUgdHJ1c3QgcmVsYXRpb25zaGlwcyBpbiB0 aGUgY29uc29ydGl1bS4gIFRoZSA2MDQ2LWJpcw0KPiA+Pj4+Pj4gZHJhZnQgYWxyZWFkeSBoYXMg YQ0KPiA+Pj4+Pj4gcmVmZXJlbmNlIHRvIHRoZSBQS0kgZGlzY3Vzc2lvbiBpbiA2MDQ1LWJpcy4g V291bGQgaXQgbWFrZSBzZW5zZSB0bw0KPiA+Pj4+Pj4gY2xhcmlmeSA2MDQ2LWJpcw0KPiA+Pj4+ Pj4gdG8gaW5kaWNhdGUgdGhhdCBSRkMgNjEyNSBTZWN0aW9uIDYgYXBwbGllcyBvbmx5IHRvIHNl cnZlciBpZGVudGl0eQ0KPiA+Pj4+Pj4gdmVyaWZpY2F0aW9uIGFuZCB0aGUNCj4gPj4+Pj4+IFBL SSBtYXRlcmlhbCBpbiA2MDQ1LWJpcyBhcHBsaWVzIHRvIGJvdGggc2VydmVyIGFuZCBjbGllbnQg aWRlbnRpdHkNCj4gPj4+Pj4+IHZlcmlmaWNhdGlvbj8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFu a3MsDQo+ID4+Pj4+PiAtLURhdmlkDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4gRnJvbTogTW9yaWFydHksIEthdGhsZWVuDQo+ID4+Pj4+ Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDEyIDE6MjEgUE0NCj4gPj4+Pj4+PiBU bzogQmxhY2ssIERhdmlkOyBtaWxlQGlldGYub3JnDQo+ID4+Pj4+Pj4gU3ViamVjdDogUkU6IDYw NDYtYmlzIC0gQ2xpZW50IGNlcnRpZmljYXRlIGlkZW50aXR5IGNoZWNrDQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+PiBIaSBEYXZpZCwNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoYW5rIHlvdSBmb3IgdGhl IGNvbW1lbnRzLiAgSWYgdGV4dCBpcyBhZGRlZCwgaXQgd2lsbCBuZWVkIHRvIGJlDQo+ID4+Pj4+ Pj4gc3BlY2lmaWMgdG8gdGhlIGluc3RhbmNlIG9mIE5vZGUNCj4gPj4+Pj4gaW4NCj4gPj4+Pj4+ PiBSSUQgb3IgSU9ERUYuICBUaGlzIHdvdWxkIG1lYW4gdGhlIENOIHdvdWxkIGJlIHVzZWQgZm9y IHRoaXMNCj4gPj4+Pj4+PiBwdXJwb3NlIChpZiBVVEYtOCBuYW1lcyBhcmUgT0tlZCBmb3INCj4g Pj4+Pj4gdXNlDQo+ID4+Pj4+Pj4gaW4gUklEIE5vZGVOYW1lcyB3aXRoIHRoZSBpbnRlcm5hdGlv bmFsaXphdGlvbiBkaXNjdXNzaW9ucykuICBSSUQNCj4gPj4+Pj4+PiB1c2VzIE5vZGUgaW4gdHdv IHBsYWNlcyBhbmQgaXQNCj4gPj4+Pj4gbWF5DQo+ID4+Pj4+Pj4gbWFrZSBtb3JlIHNlbnNlIHRv IHJlZmVyZW5jZSB0aGUgb25lIGluIHRoZSBJT0RFRiBkb2N1bWVudCBvcg0KPiA+Pj4+Pj4+IGNo YW5nZSBzb21ldGhpbmcgaW4gUklELg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSW5zdGFuY2VzIG9m IHdoZXJlICdOb2RlJyBhcHBlYXJzOg0KPiA+Pj4+Pj4+IDEpIE5vZGUgaW4gU291cmNlRm91bmQg d291bGQgbm90IGFwcGx5IGhlcmUuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAyKSBOb2RlIGluIFJJ RCBSSURQb2xpY3kgaXMgdGllZCB0byBNc2dEZXN0aW5hdGlvbiBhbmQgd291bGQgYmUNCj4gPj4+ Pj4+PiB0aGUgcmVjZWl2aW5nIE5vZGUgb3IgdGhlIHN1c3BlY3RlZA0KPiA+Pj4+Pj4+IHNvdXJj ZSBvZiBhbiBpbmNpZGVudCBpZiBhIHRyYWNlYmFjayB3ZXJlIGluIHBsYXkuDQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+PiAzKSBUaGlzIG1lYW5zIHRoZSBjb25uZWN0aW9uIHdvdWxkIG5lZWQgdG8gYmUg dG8gdGhlIElPREVGDQo+ID4+Pj4+Pj4gZG9jdW1lbnQgYW5kIHdvdWxkIHJlcXVpcmUgdGhlIGRv Y3VtZW50DQo+ID4+Pj4+IHRvDQo+ID4+Pj4+Pj4gYmUgZGVjcnlwdGVkIHRvIHZlcmlmeSBpZiB0 aGlzIHdlcmUgbmVjZXNzYXJ5LiAgT3IgYWRkaW5nIGEgTm9kZQ0KPiA+Pj4+Pj4+IGluc3RhbmNl IHNwZWNpZmljIHRvIHRoZSBzZW5kaW5nDQo+ID4+Pj4+IGhvc3QNCj4gPj4+Pj4+PiBpbmZvcm1h dGlvbi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IDQpIElmIGl0IHdlcmUgdGllZCB0byBJT0RFRiwg dGhlIHVzZSBvZiBOb2RlIGluIHRoZSBTeXN0ZW0gY2xhc3MNCj4gPj4+Pj4+PiBpcyBzcGVjaWZp YyB0byB0aGUgc291cmNlIGFuZA0KPiA+Pj4+Pj4+IGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBpbnZv bHZlZCBpbiBhbiBhdHRhY2suIFRoZSBFdmVudERhdGEgd2hlcmUNCj4gPj4+Pj4+PiBjb250YWN0 IGNhdGVnb3J5IGlzIHNldCB0bw0KPiA+Pj4+Pj4+ICJpbmZyYXN0cnVjdHVyZSIgaXMgdGhlIHBs YWNlIHdoZXJlIHN5c3RlbXMgaW52b2x2ZWQgaW4NCj4gPj4+Pj4+PiBjb21tdW5pY2F0aW5nIElP REVGIGRvY3VtZW50cyBhcmUgbGlzdGVkLg0KPiA+Pj4+Pj4+IFRoaXMgaXMgdGhlIHBhdGggaW5m b3JtYXRpb24gZm9yIGluY2lkZW50IGRhdGEgKGxpc3RzIGFsbCBvZiB0aGUNCj4gPj4+Pj4+PiAn ZnJvbScgc3lzdGVtcyBpbiBSSUQNCj4gPj4+Pj4+PiBjb21tdW5pY2F0aW9ucykuDQo+ID4+Pj4+ Pj4NCj4gPj4+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+Pj4gS2F0aGxlZW4gKGFzIGVkaXRvcikNCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4g RnJvbTogbWlsZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3Jn XSBPbg0KPiA+Pj4+Pj4+IEJlaGFsZiBPZiBkYXZpZC5ibGFja0BlbWMuY29tDQo+ID4+Pj4+Pj4g U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDEyIDEyOjM5IFBNDQo+ID4+Pj4+Pj4gVG86 IG1pbGVAaWV0Zi5vcmcNCj4gPj4+Pj4+PiBTdWJqZWN0OiBbbWlsZV0gNjA0Ni1iaXMgLSBDbGll bnQgY2VydGlmaWNhdGUgaWRlbnRpdHkgY2hlY2sNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEJyaWFu IGFuZCBLYXRobGVlbiwNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEkgdGhpbmsgSSBmb3VuZCBzb21l dGhpbmcgaW4gbG9va2luZyBhdCB0aGUgdGV4dCByZWxhdGVkIHRvIHRoZQ0KPiA+Pj4+Pj4+IHF1 ZXN0aW9uIGFib3V0DQo+ID4+Pj4+Pj4gY2VydGlmaWNhdGUgaWRlbnRpdGllcywgYnV0IHNvbWUg bW9yZSBpbnB1dCB3b3VsZCBiZSB1c2VmdWwuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGUgNjA0 Ni1iaXMtMDggZHJhZnQgc2F5czoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgIFJJRCBzeXN0ZW1z IE1VU1QgdmVyaWZ5IHRoZSBpZGVudGl0eSBvZiB0aGVpciBwZWVycyBhZ2FpbnN0IHRoYXQNCj4g Pj4+Pj4+PiAgICBzdG9yZWQgaW4gdGhlIGNlcnRpZmljYXRlIHByZXNlbnRlZCwgYXMgaW4gc2Vj dGlvbiA2IG9mIFtSRkM2MTI1XS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoYXQgY292ZXJzIHZl cmlmaWNhdGlvbiBvZiB0aGUgaWRlbnRpdHkgb2YgdGhlIHJlY2VpdmluZyBzeXN0ZW0NCj4gPj4+ Pj4+PiAodGhlIGlkZW50aXR5DQo+ID4+Pj4+Pj4gaW4gdGhlIFRMUyBzZXJ2ZXIgY2VydGlmaWNh dGUgaGFzIHRvIG1hdGNoIGhvc3QgY29tcG9uZW50IG9mIFVSSQ0KPiA+Pj4+Pj4+IGZvciBIVFRQ KSwgYnV0DQo+ID4+Pj4+Pj4gSSBkb24ndCB0aGluayBpdCBjb3ZlcnMgdmVyaWZpY2F0aW9uIG9m IHRoZSBpZGVudGl0eSBvZiB0aGUNCj4gPj4+Pj4+PiBzZW5kaW5nIHN5c3RlbSwgYXMNCj4gPj4+ Pj4+PiBTZWN0aW9uIDYgb2YgUkZDIDYxMjUgY29uY2VybnMgb25seSBzZXJ2aWNlIGlkZW50aXR5 Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSSdkIHN1Z2dlc3QgYWRkaW5nIHNvbWUgdGV4dCB0aGF0 IHJlcXVpcmVzIHRoYXQgdGhlIGlkZW50aXR5IG9mDQo+ID4+Pj4+Pj4gdGhlIHNlbmRpbmcNCj4g Pj4+Pj4+PiBzeXN0ZW0gaW4gdGhlIFRMUyBjbGllbnQgY2VydGlmaWNhdGUgbWF0Y2ggdGhlIE5v ZGVOYW1lIGluIHRoZQ0KPiA+Pj4+Pj4+IE5vZGUgZWxlbWVudA0KPiA+Pj4+Pj4+IG9mIHRoZSBS SURQb2xpY3kgY2xhc3MgaWYgdGhlIE5vZGVOYW1lIGlzIHByZXNlbnQuIFRoYXQgImlzDQo+ID4+ Pj4+Pj4gcHJlc2VudCIgY29tcGxpY2F0aW9uDQo+ID4+Pj4+Pj4gaXMgY291cnRlc3kgb2YgNjA0 NS1iaXMgcmV1c2luZyB0aGUgSU9ERUYgTm9kZSBjbGFzcyBmcm9tIFJGQw0KPiA+Pj4+Pj4+IDUw NzAsIGJlY2F1c2UNCj4gPj4+Pj4+PiBSRkMgNTA3MCBkb2VzIG5vdCByZXF1aXJlIHRoYXQgTm9k ZU5hbWUgYmUgcHJlc2VudC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEknbSBub3Qgc3VyZSB3aGF0 IHRvIGRvIGlmIE5vZGVOYW1lIGlzIGFic2VudCAtIGEgcG9zc2libGUNCj4gPj4+Pj4+PiBhcHBy b2FjaCB3b3VsZCBiZSB0bw0KPiA+Pj4+Pj4+IG5vdCBnbyB0aGVyZSwgYW5kIGluc3RlYWQgYWRk IGEgcmVxdWlyZW1lbnQgdG8gNjA0NS1iaXMgdGhhdA0KPiA+Pj4+Pj4+IE5vZGVOYW1lIE1VU1Qg YmUNCj4gPj4+Pj4+PiBwcmVzZW50IGluIHRoZSBOb2RlIGVsZW1lbnQgb2YgdGhlIFJJRFBvbGlj eSBjbGFzcyBpbiBvcmRlciB0bw0KPiA+Pj4+Pj4+IGZhY2lsaXRhdGUNCj4gPj4+Pj4+PiB0aGlz IGlkZW50aXR5IGNoZWNrLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gV2hhdCBkbyBvdGhlciBwZW9w bGUgdGhpbms/DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+Pj4gLS1EYXZp ZA0KPiA+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+Pj4+PiBEYXZpZCBMLiBCbGFjaywgRGlzdGluZ3Vpc2hlZCBFbmdpbmVl cg0KPiA+Pj4+Pj4+IEVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9wa2ludG9uLCBN QSAgMDE3NDgNCj4gPj4+Pj4+PiArMSAoNTA4KSAyOTMtNzk1MyAgICAgICAgICAgICBGQVg6ICsx ICg1MDgpIDI5My03Nzg2DQo+ID4+Pj4+Pj4gZGF2aWQuYmxhY2tAZW1jLmNvbSAgICAgICAgTW9i aWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KPiA+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4gbWls ZSBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+PiBtaWxlQGlldGYub3JnDQo+ID4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlDQo+ID4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gbWlsZSBtYWls aW5nIGxpc3QNCj4gPj4+Pj4+IG1pbGVAaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0KPiA+DQo+DQoNCg== From stpeter@stpeter.im Thu Jan 26 13:23:55 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 68E3321F8607 for ; Thu, 26 Jan 2012 13:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.6 X-Spam-Level: X-Spam-Status: No, score=-103.6 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, GB_I_LETTER=-2, 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 mdPDQOnVR21h for ; Thu, 26 Jan 2012 13:23:54 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5B821F85C3 for ; Thu, 26 Jan 2012 13:23:54 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 547D940058; Thu, 26 Jan 2012 14:33:42 -0700 (MST) Message-ID: <4F21C468.9030104@stpeter.im> Date: Thu, 26 Jan 2012 14:23:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mile@ietf.org, presnick@qualcomm.com Subject: Re: [mile] FW: IDN issue 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, 26 Jan 2012 21:23:55 -0000 On 1/26/12 1:42 PM, kathleen.moriarty@emc.com wrote: > Hi Peter, > > I'll try to respond in line below and let David fill in any gaps. > > Thanks, > Kathleen > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: Thursday, January 26, 2012 3:05 PM > To: Black, David > Cc: mile@ietf.org; presnick@qualcomm.com > Subject: Re: [mile] FW: IDN issue > > Hi David, > > On 1/25/12 5:06 PM, david.black@emc.com wrote: >> Hello Peter, >> >>> In short, there be dragons. >> >> Indeed (as I'm entirely too well-aware of from the précis WG), however, the goal >> here is to find a suitable cave in which to confine the dragons :-). > > Nice way to put it. And yes, the PRECIS WG is a fun place to hang out. > Speaking of which, how's that iSCSI profile of the precis framework > coming along? ;-) > >> The place to start looking for that cave is an understanding of how NodeName is >> used. The quick summary is that there are three cases: >> >> (1) RIDPolicy class, MsgDestination=RIDSystem. >> >> The NodeName is the destination of the RID message, so it can be required to work >> in the DNS, which already has to deal with figuring out whether a U-Label is valid. >> Text could be added to require that the NodeName either be used to send the RID >> message via DNS lookup or that it has been looked up at some point in the past and >> resolves to the IP address to which the RID message is sent. Both of these >> approaches rely on the DNS implementation to validate the U-label. > > I think that might be fine. I see that version -09 says: > > 1. RIDSystem. The address listed in the Node element of the > RIDPolicy class is the next upstream RID system that will > receive the RID message. If NodeName element of the Node > class is used, it contains a DNS domain name. The > originating RID system is required to check that this > domain name resolves to the IP address to which the RID > message is sent. This check may be performed in advance of > sending the message and the result saved for future use > with additional RID messages. > > However, the spec right now says that the domain name MUST NOT contain > A-labels: > > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name > MUST be used, i.e., all of the domain name's labels MUST be U-labels > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > used. A RID system can convert between A-labels and U-labels by > using the Punycode encoding [RFC3492] for A-labels as described in > the protocol specification for Internationalized Domain Names in > Applications [RFC5891]. > > If the application is not checking this, how will it know whether any > A-labels have snuck in? Will it depend on its DNS resolver to return the > IDN in the appropriate format? The foregoing text implies that the RID > system will do the conversion, so it's not clear to me where the > responsibility lies (and if it's not clear to me, it might be clear to > an implementer). > _________ > KMM: We state that the document must be UTF-8 compliant("The use of UTF-8 is REQUIRED"). Does that cover the checking since A-labels are not UTF-8 formatted? Not exactly. As I mentioned previously, the character encoding of the RID document (e.g., as UTF-8) is distinct from the character repertoire of information that goes in the domain name slot (here, the NodeName). A document that has an encoding of UTF-8 can include all sorts of data elements whose character repertoire is limited to the US-ASCII range (e.g., this is true of IP addresses). The relevant distinction between A-labels and U-labels is not the encoding of the RID document in which they are included (Network Virtual Terminal [RFC5198] vs. UTF-8) but the character repertoire (only characters in the US-ASCII range for A-labels because of the special features of Punycode vs. any Unicode letter, digit, or hyphen for U-labels). Naturally, in order to include a U-label directly in a document or protocol it will need to use an encoding that allows Unicode characters (such as UTF-8), but an A-label can be included in a UTF-8 document just fine -- the decisions are separate. > Would the question be resolved by changing: > " A RID system can convert between A-labels and U-labels by " > TO: " A an application communicating via RID can convert between A-labels and U-labels by " I think that might be a distinction without a difference. > This would put the burden within a application associated with the API that is IODEF/RID/RID Transport. I see that as an integral part of the RID system, but perhaps I'm missing something. > What we care about is consistent transport so that applications can share data. As long as the data received is the same for every implementation, we shouldn't care how they use the domain names in their application, right? Unless they are making access decisions (authentication, authorization, etc.) based on those domain names, because then they need to be compared correctly. But if RID systems are making those decisions based on IP address anyway, then I'm much less concerned -- perhaps even not concerned at all. > __________ > And if only U-labels are permitted, then comparison proceeds using the > U-labels as input. However, if so we might need to specify mappings of > the kind discussed in RFC 5895 (e.g., mapping uppercase and titlecase to > lowercase so that PRÉCIS.example.com is treated "the same" as > précis.example.com). > > BUT... > > Will RID systems in fact be doing such comparisons? The text from the > first paragraph quoted above indicates that RID systems will be checking > the association between a DNS domain name and an IP address, not > directly comparing DNS domain names (including IDNs). If that is true, > then we probably *don't* need to care much about comparison and any talk > of mappings is moot. Can you please verify that RID systems will be > checking the association with the IP address, rather than directly > comparing DNS domain names? > _______ > KMM: I see your point here. How about the following text to make it clear that the IP address is required and the DNS name is derived from the IP address: > > 1. RIDSystem. The IP address of the next upstream system accepting RID communications is REQUIRED and is listed in the Node element of the > RIDPolicy class. If NodeName element of the Node > class is used, it contains a DNS domain name. The > originating RID system is required to check that this > domain name resolves to the IP address to which the RID > message is sent. This check may be performed in advance of > sending the message and the result saved for future use > with additional RID messages. > ______ Sure, that's fine. Then my question becomes: how exactly is the NodeName actually used in RID systems? It's the use that drives the internationalization considerations. If the NodeName is merely epiphenomenal and it's the IP address that we use to get things done, then we don't particularly care about the NodeName. >> (2) RIDPolicy class, MsgDestination=SourceOfIncident, and also the IncidentSource >> class. >> >> In both of these cases the IP address is the primary identifier (IncidentSource >> needs additional text to state that the IP address is required - that appears to >> have been overlooked). There are a couple of options here: >> >> a) The simplest is to prohibit NodeName usage. >> b) NodeName could be required to correspond to the IP address via DNS lookup. > > In -09 that is: > > 2. SourceOfIncident. The Address element of the Node element > contains the IP address of the incident source, and the > NodeName element of the Node class is not used. The IP > address is used to determine the path of systems accepting > RID communications that will be used to find the closest > RID system to the source of an attack in which the IP > address used by the source is believed to be valid and a > Request message with MsgDst set to InvestigationRequest is > used. This is not to be confused with the IncidentSource > class, as the defined value here is from an initial trace > or investigation Request, not the source used in a Result > message. > > I think it's fine to use IP address here. > > NOTE: you said that IncidentSource needs additional text to state that > the IP address required, but I do not see that here: > _____ > KMM: Thanks, if we are fixing text, let's just add that now. This one should be easy. > > Proposed: > 2. SourceOfIncident. The Address element of the Node element > contains the IP address of the incident source, and the > NodeName element of the Node class is not used. The IP > address is REQUIRED when this option is selected. The IP address is used to determine the path of systems accepting > RID communications that will be used to find the closest > RID system to the source of an attack in which the IP > address used by the source is believed to be valid and a > Request message with MsgDst set to InvestigationRequest is > used. This is not to be confused with the IncidentSource > class, as the defined value here is from an initial trace > or investigation Request, not the source used in a Result > message. > _____ Looks good. > http://tools.ietf.org/rfcdiff?url1=draft-ietf-mile-rfc6045-bis-08&difftype=--html&submit=Go!&url2=draft-ietf-mile-rfc6045-bis-09 > > However, I think that can be added before sending this document to the > RFC Editor, or during AUTH48. > >> (3) RIDPolicy class, MsgDestination=ext-value. This is an escape that allows >> extensions to MsgDestination. The description of this should include a "there >> be dragons" warning about IDNs in NodeName. > > In -09 that is: > > 3. ext-value. An escape value used to extend this attribute. > All extensions shall specify the contents and meaning of > the Node element of RIDPolicy. If the NodeName element of > Node is used by an extension, NodeName may contain an > Internationalized Domain Name (IDN) and that IDN is > required to satisfy the requirements in [RFC5890]. It is > strongly recommended that RID Systems satisfy those IDN > requirements via appropriate use of the DNS as opposed to > implementing their own checks for these requirements. For > example, an extension could use both a NodeName and an IP > address to which the NodeName resolves. See IODEF > [RFC5070], Section 5.1 on extensibility. > > That seems slightly underspecified: what is meant by "to satisfy the > requirements in [RFC5890]" and "appropriate use of the DNS"? Does that > mean "ensuring that the IDN retrieved from the DNS consists only of > U-labels and NR-LDH labels"? If so, is that done by asking the DNS > resolver for U-labels, or is it done by actively performing a check in > the RID system itself (see above about "MUST NOT be A-labels")? > > Is this something that is left for each extension to define? If so, we > should come out and say precisely that. > _______ > KMM: The important part for RID is that we communicate and exchange messages in a way that everyone can accept and process. Application handling for this translation, whether it be by DNS or some other mechanism, really shouldn't matter. As long as the internationalization is handled in a way that lets us consistently exchange information, I think the real issues are solved, no? > If I add "See Section 11 of this document for > Internationalization considerations." Does that resolve the issue since it provides consistent guidance that enables the exchange of information? > _______ Yes, we want to make sure that appliations handle these matters consistently. Pointing to Section 11 would solve that issue, as long as we can agree on what goes in Section 11. :) >> So, the answer to the somewhat rhetorical question: >> >>> Do IODEF/RID implementations want to sign up for all that? >> >> Is approximately "Yes, by relying on the DNS implementation," with the addition >> of a "there be dragons" warning to the MsgDestination ext-value extension text >> to communicate that to designers of extensions, and a possible prohibition of >> use of NodeName when the IP address is the primary identifier. > > I think we're getting close to reflecting that in text, but a few > clarifications would help, as would validation from the WG that this > direction is agreeable. > > I realize that these are thorny issues and that folks probably just want > someone to come from on high and say "yea verily, here is the one true > path to internationalization nirvana". Unfortunately, there is no such > path, so the WG needs to weigh the costs and benefits, clearly > understand what it's doing, and then make a decision one way or the > other. We've had too many WGs (some of which I've been involved with) > just take some i18n advice without knowledge, and the results have been > less then positive. > > Thanks for your patience! > > Peter > _________ > Thank you for your detailed reviews! I'm here for you! ;-) Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Thu Jan 26 12:24: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 CD7BD21F8666 for ; Thu, 26 Jan 2012 12:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.55 X-Spam-Level: X-Spam-Status: No, score=-100.55 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, J_BACKHAIR_13=1, J_BACKHAIR_21=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_24=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 GjyWIFZJx5Qu for ; Thu, 26 Jan 2012 12:24:24 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 00BCF21F8663 for ; Thu, 26 Jan 2012 12:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327609463; d=isode.com; s=selector; i=@isode.com; bh=YJo6KAtZxo6R9OcxPQAMn+SlRt1ib4L4eRZbBnMe+BA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kNUE5E24D4WdkgDTYl341tZG37C0DUUyfFUIUGUafgGjWAp38EuyDsRU8QX654c4HGUXQr rPDPu8rUPAoaYAeEaL9vjzRLBYHvEpE93lb8kPD14yPyGMOZf9ccVVeE5SXpqu9PdaxkWg KOpHQGRlBwLHE9X08RlsqyIjMj/4OF8=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 26 Jan 2012 20:24:22 +0000 Message-ID: <4F21B683.20604@isode.com> Date: Thu, 26 Jan 2012 20:24:35 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Peter Saint-Andre References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> In-Reply-To: <4F21AABD.9060603@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 Jan 2012 13:24:19 -0800 Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 26 Jan 2012 20:24:25 -0000 On 26/01/2012 19:34, Peter Saint-Andre wrote: > On 1/26/12 12:21 PM, Alexey Melnikov wrote: >> On 25/01/2012 21:17, Brian Trammell wrote: >>> Hi, David, >>> >>> The reference identifier (defined in RFC 6215 section 1.8; explained >>> in 6.2) in RID transport is (presumably) the identity one system uses >>> to connect to another (see paragraph 12 of 6046-bis-08 section 3: >>> "...the use of stable DNS names to address RID Systems is >>> RECOMMENDED"). This could perhaps be made more explicit but it seemed >>> obvious enough. >>> >>> For mutual authentication, this would have to be derived from a >>> reverse mapping of the network address back to a name (either by DNS >>> PTR records, or a whitelist of consortium members). >> David is correct that RFC 6125 can only be used by the entity that >> actively connect to another one (i.e. by the client to verify the server). > English nit: s/i.e./e.g./ (because it can be used by one server > connecting to another server, as we're sort of doing here). A server connecting to another is acting as a client, but never mind ;-). >> If you find the burden of maintaining the reverse DNS mapping to be >> acceptable for your protocol (for deployments of some other protocols, >> like SMTP that burden was found to be unacceptable), then you can use >> RFC 6125 for verifying clients by servers. > My sense is that in RID consortia, this is seen as an acceptable burden > because the number of members in each consortium is manageable. But > that's something that RID participants probably need to verify. Agreed. >> If you are not concerned about one RID member masquerading as another, >> it might be sufficient for your protocol to allow client certificates to >> come from a known CA (or a set of CAs), or be whitelisted. So basically >> you will use more relaxed verification rules from RFC 5280. > Well, I think you'd probably still want to do the domain check, no? How would you derive a domain name for the connecting entry (what I called "client")? The server only has an IP address and port. So other than doing reverse DNS mapping or similar, I don't think anything will result in a domain. >>> Perhaps stating "each RID system MUST maintain a DNS-ID reference >>> identifier for those RID systems it participates in a consortium with, >>> and use this for comparison with the DNS-ID stored in the certificate >>> presented by RID system peers" would address this concern? >>> Regards, >>> >>> Brian >>> >>> On Jan 25, 2012, at 9:24 PM, >>> wrote: >>> >>>> Hi Brian, >>>> >>>> Kathleen quickly disposed of #1, so please ignore that. She'll add >>>> some text to >>>> 6045-bis to help other readers avoid the mistake that I made. >>>> >>>> For #2, the short summary of my concern with the current text >>>> involves this sentence: >>>> >>>>> RID systems MUST verify the identity of their peers against >>>>> that stored >>>>> in the certificate presented. >>>> How does a RID system (as TLS client or server) do that? >>>> >>>> The next sentence explains what the identity is, but not how to >>>> verify it: >>>> >>>>> All RID systems MUST be identified by a >>>>> certificate containing aDNS-ID >>>>> identifier >>>>> as in section 6.4 of. >>>> In particular, section 6.4 of RFC 6125 doesn't specify what the >>>> certificate identity >>>> is checked against. It may even be that section 6.4 of RFC 6125 >>>> doesn't apply to >>>> client certificates, because the client identity check my be subsumed >>>> by PKIX path >>>> validation of the client certificate against the server's trust >>>> store, which does >>>> name comparison according to RFC 5280, not RFC 6125. >>>> >>>> A sentence or two on how to do that required (MUST) identity >>>> verification would help. >>>> >>>> Thanks, >>>> --David >>>> >>>> >>>>> -----Original Message----- >>>>> From: Moriarty, Kathleen >>>>> Sent: Wednesday, January 25, 2012 2:55 PM >>>>> To: Brian Trammell; Black, David >>>>> Cc: mile@ietf.org >>>>> Subject: RE: [mile] 6046-bis - Client certificate identity check >>>>> >>>>> Hi Brian, >>>>> >>>>> You can save your time on #1, the question/request was withdrawn. >>>>> The sending RID server may only >>>>> appear within the IODEF document and not the RID XML document. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> -----Original Message----- >>>>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >>>>> Sent: Wednesday, January 25, 2012 2:51 PM >>>>> To: Black, David >>>>> Cc: Moriarty, Kathleen; mile@ietf.org >>>>> Subject: Re: [mile] 6046-bis - Client certificate identity check >>>>> >>>>> Hi, David, >>>>> >>>>> Thanks for the comments; I've been out of contact all day so am >>>>> catching up. I'll top-post my summary >>>>> reply at first; I may have further detail replies in a subsequent >>>>> message. >>>>> >>>>> 1. I would need to think more deeply about the implications of any >>>>> authentication also cross-checking >>>>> the DNS-ID against not only network-layer available identifiers but >>>>> also against information stored >>>>> within the RID document itself. There seems to be a bit of a chicken >>>>> and egg problem there, and it >>>>> seems to me that there may be valid exceptions to a policy that >>>>> would be simple enough to be (a) >>>>> implementable and (b) verifiable. >>>>> >>>>> 2. It is not the intent that 6125 section 4 applies solely to the >>>>> authentication of the TLS server; >>>>> _all_ authentication in RID over HTTPS must be mutual, and I believe >>>>> the current proposed text (copied >>>>> below straight from xml source) to be clear on this point, in >>>>> context. If that's not the case, then >>>>> we'll need to change it. >>>>> >>>>> RID systems MUST use TLS version 1.1 >>>>> or higher >>>>> for confidentiality, identification, and authentication, when >>>>> sending RID >>>>> messages over HTTPS. HTTPS is specified in Section 2 of>>>> target="RFC2818"/>. RID systems MUST use mutual authentication; >>>>> that is, >>>>> both RID systems acting as HTTPS clients and RID systems acting >>>>> as HTTPS >>>>> servers MUST be identified by anX.509 >>>>> certificate. Mutual authentication requires full path >>>>> validation on >>>>> each certificate, as defined in. >>>>> >>>>> The TLS session MUST use non-NULL ciphersuites for >>>>> authentication, >>>>> integrity, and confidentiality. Sessions MAY be renegotiated >>>>> within these >>>>> constraints. >>>>> >>>>> RID systems MUST verify the identity of their peers against >>>>> that stored >>>>> in the certificate presented. All RID systems MUST be identified >>>>> by a >>>>> certificate containing aDNS-ID >>>>> identifier >>>>> as in section 6.4 of. The inclusion of >>>>> Common >>>>> Names (CN-IDs) in certificates identifying RID systems is NOT >>>>> RECOMMENDED. >>>>> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate >>>>> identifying a RID system. Additional general information on the >>>>> use of PKI >>>>> with RID systems is detailed in Section 9.3 of>>>> target="I-D.ietf-mile-rfc6045-bis"/>. >>>>> >>>>> RID systems MUST support TLS version 1.1 and SHOULD support >>>>> TLS version >>>>> 1.2; RID systems MUST NOT request, >>>>> offer, or use >>>>> any version of SSL, or any version of TLS prior to 1.1, due to >>>>> known >>>>> security vulnerabilities in prior versions of the protocol; see >>>>> Appendix E >>>>> of for more. >>>>> >>>>> Best regards, >>>>> >>>>> Brian >>>>> >>>>> On Jan 25, 2012, at 8:00 PM, wrote: >>>>> >>>>>> Hi Kathleen, >>>>>> >>>>>> I missed the connection between Node and MsgDestination in 6045-bis >>>>>> - my mistake. >>>>>> >>>>>> It might be useful to repeat the following text from the >>>>>> specification of "MsgDestination" >>>>>> in the specification of the Node element in RIDPolicy, as those >>>>>> specifications are 5 >>>>>> pages apart, and the current specification of the Node element is >>>>>> not precise about >>>>>> usage: >>>>>> >>>>>> the meaning of the value >>>>>> in the Node element is determined by the MsgDestination >>>>>> element >>>>>> >>>>>> OTOH, I now don't see anything in RID that represents the identity >>>>>> of the system sending >>>>>> the RID message, and I don't think adding that is important enough >>>>>> to make a change at >>>>>> this juncture. I also don't see any point in trying to use the >>>>>> enveloped IODEF document >>>>>> to carry the identity of the sending RID system, as that document >>>>>> could get forwarded >>>>>> in a different RID message, for which it would contain the wrong >>>>>> sending RID system >>>>>> identity. >>>>>> >>>>>> If there's no instance of the sending RID system's identity in the >>>>>> RID message, then I >>>>>> suppose the client identity verification would have to be based on >>>>>> the information used >>>>>> to set up the trust relationships in the consortium. The 6046-bis >>>>>> draft already has a >>>>>> reference to the PKI discussion in 6045-bis. Would it make sense to >>>>>> clarify 6046-bis >>>>>> to indicate that RFC 6125 Section 6 applies only to server identity >>>>>> verification and the >>>>>> PKI material in 6045-bis applies to both server and client identity >>>>>> verification? >>>>>> >>>>>> Thanks, >>>>>> --David >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Moriarty, Kathleen >>>>>>> Sent: Wednesday, January 25, 2012 1:21 PM >>>>>>> To: Black, David; mile@ietf.org >>>>>>> Subject: RE: 6046-bis - Client certificate identity check >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for the comments. If text is added, it will need to be >>>>>>> specific to the instance of Node >>>>> in >>>>>>> RID or IODEF. This would mean the CN would be used for this >>>>>>> purpose (if UTF-8 names are OKed for >>>>> use >>>>>>> in RID NodeNames with the internationalization discussions). RID >>>>>>> uses Node in two places and it >>>>> may >>>>>>> make more sense to reference the one in the IODEF document or >>>>>>> change something in RID. >>>>>>> >>>>>>> Instances of where 'Node' appears: >>>>>>> 1) Node in SourceFound would not apply here. >>>>>>> >>>>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would be >>>>>>> the receiving Node or the suspected >>>>>>> source of an incident if a traceback were in play. >>>>>>> >>>>>>> 3) This means the connection would need to be to the IODEF >>>>>>> document and would require the document >>>>> to >>>>>>> be decrypted to verify if this were necessary. Or adding a Node >>>>>>> instance specific to the sending >>>>> host >>>>>>> information. >>>>>>> >>>>>>> 4) If it were tied to IODEF, the use of Node in the System class >>>>>>> is specific to the source and >>>>>>> destination addresses involved in an attack. The EventData where >>>>>>> contact category is set to >>>>>>> "infrastructure" is the place where systems involved in >>>>>>> communicating IODEF documents are listed. >>>>>>> This is the path information for incident data (lists all of the >>>>>>> 'from' systems in RID >>>>>>> communications). >>>>>>> >>>>>>> Thanks, >>>>>>> Kathleen (as editor) >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On >>>>>>> Behalf Of david.black@emc.com >>>>>>> Sent: Wednesday, January 25, 2012 12:39 PM >>>>>>> To: mile@ietf.org >>>>>>> Subject: [mile] 6046-bis - Client certificate identity check >>>>>>> >>>>>>> Brian and Kathleen, >>>>>>> >>>>>>> I think I found something in looking at the text related to the >>>>>>> question about >>>>>>> certificate identities, but some more input would be useful. >>>>>>> >>>>>>> The 6046-bis-08 draft says: >>>>>>> >>>>>>> RID systems MUST verify the identity of their peers against that >>>>>>> stored in the certificate presented, as in section 6 of [RFC6125]. >>>>>>> >>>>>>> That covers verification of the identity of the receiving system >>>>>>> (the identity >>>>>>> in the TLS server certificate has to match host component of URI >>>>>>> for HTTP), but >>>>>>> I don't think it covers verification of the identity of the >>>>>>> sending system, as >>>>>>> Section 6 of RFC 6125 concerns only service identity. >>>>>>> >>>>>>> I'd suggest adding some text that requires that the identity of >>>>>>> the sending >>>>>>> system in the TLS client certificate match the NodeName in the >>>>>>> Node element >>>>>>> of the RIDPolicy class if the NodeName is present. That "is >>>>>>> present" complication >>>>>>> is courtesy of 6045-bis reusing the IODEF Node class from RFC >>>>>>> 5070, because >>>>>>> RFC 5070 does not require that NodeName be present. >>>>>>> >>>>>>> I'm not sure what to do if NodeName is absent - a possible >>>>>>> approach would be to >>>>>>> not go there, and instead add a requirement to 6045-bis that >>>>>>> NodeName MUST be >>>>>>> present in the Node element of the RIDPolicy class in order to >>>>>>> facilitate >>>>>>> this identity check. >>>>>>> >>>>>>> What do other people think? >>>>>>> >>>>>>> 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 >>>>>>> ---------------------------------------------------- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mile mailing 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 Thu Jan 26 14:30: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 910CB21F872D for ; Thu, 26 Jan 2012 14:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.234 X-Spam-Level: X-Spam-Status: No, score=-110.234 tagged_above=-999 required=5 tests=[AWL=2.365, BAYES_00=-2.599, GB_I_LETTER=-2, 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 qN1-H6L+PD7z for ; Thu, 26 Jan 2012 14:30: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 6855D21F8725 for ; Thu, 26 Jan 2012 14:30: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 q0QMUYrA024736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 17:30:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 26 Jan 2012 17:30:14 -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 q0QMUBsV010420; Thu, 26 Jan 2012 17:30:14 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Thu, 26 Jan 2012 17:30:11 -0500 From: To: , Date: Thu, 26 Jan 2012 17:30:09 -0500 Thread-Topic: [mile] FW: IDN issue Thread-Index: AczccPEo8QTiRwmFQS2MYbKN0mz+PgAACJtw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> In-Reply-To: <4F21C468.9030104@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, presnick@qualcomm.com Subject: Re: [mile] FW: IDN issue 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, 26 Jan 2012 22:30:38 -0000 SGkgUGV0ZXIsDQoNCj4gPj4+IEluIHNob3J0LCB0aGVyZSBiZSBkcmFnb25zLg0KPiA+Pg0KPiA+ PiBJbmRlZWQgKGFzIEknbSBlbnRpcmVseSB0b28gd2VsbC1hd2FyZSBvZiBmcm9tIHRoZSBwcsOp Y2lzIFdHKSwgaG93ZXZlciwgdGhlIGdvYWwNCj4gPj4gaGVyZSBpcyB0byBmaW5kIGEgc3VpdGFi bGUgY2F2ZSBpbiB3aGljaCB0byBjb25maW5lIHRoZSBkcmFnb25zIDotKS4NCj4gPg0KPiA+IE5p Y2Ugd2F5IHRvIHB1dCBpdC4gQW5kIHllcywgdGhlIFBSRUNJUyBXRyBpcyBhIGZ1biBwbGFjZSB0 byBoYW5nIG91dC4NCj4gPiBTcGVha2luZyBvZiB3aGljaCwgaG93J3MgdGhhdCBpU0NTSSBwcm9m aWxlIG9mIHRoZSBwcmVjaXMgZnJhbWV3b3JrDQo+ID4gY29taW5nIGFsb25nPyA7LSkNCg0KSSdt IHdvcmtpbmcgb24gZ2V0dGluZyBhIHNldCBvZiBmb3VyIGlTQ1NJLXJlbGF0ZWQgZHJhZnRzIG91 dCBvZiB0aGUgc3Rvcm0gV0cgZmlyc3QuDQpTbyBmYXIsIGl0J3MgdGhyZWUgZG93biwgb25lIHRv IGdvLCBzZWUgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3N0b3JtLyAuICBCZQ0KY2Fy ZWZ1bCB3aGF0IHlvdSB3aXNoIGZvciBhcyBhbiBBRCA6LSkuDQoNCj4gPj4gKDEpIFJJRFBvbGlj eSBjbGFzcywgTXNnRGVzdGluYXRpb249UklEU3lzdGVtLg0KDQpTZWN0aW9uIDExIHRleHQ6DQoN Cj4gPiAgICBUaGUgTm9kZSBjbGFzcyBpZGVudGlmaWVzIGEgaG9zdCBvciBuZXR3b3JrIGRldmlj ZS4gIFRoaXMgZG9jdW1lbnQNCj4gPiAgICByZS11c2VzIHRoZSBkZWZpbml0aW9uIG9mIE5vZGUg ZnJvbSB0aGUgSU9ERUYgc3BlY2lmaWNhdGlvbg0KPiA+ICAgIFtSRkM1MDcwXSwgU2VjdGlvbiAz LjE2LiAgSG93ZXZlciwgdGhhdCBkb2N1bWVudCBkaWQgbm90IGNsZWFybHkNCj4gPiAgICBzcGVj aWZ5IHdoZXRoZXIgYSBOb2RlTmFtZSBjb3VsZCBiZSBhbiBJbnRlcm5hdGlvbmFsaXplZCBEb21h aW4gTmFtZQ0KPiA+ICAgIChJRE4pLiAgUklEIHN5c3RlbXMgTVVTVCB0cmVhdCB0aGUgTm9kZU5h bWUgY2xhc3MgYXMgYSBkb21haW4gbmFtZQ0KPiA+ICAgIHNsb3QgW1JGQzU4OTBdLiAgUklEIHN5 c3RlbXMgU0hPVUxEIHN1cHBvcnQgSUROcyBpbiB0aGUgTm9kZU5hbWUNCj4gPiAgICBjbGFzczsg aWYgdGhleSBkbyBzbywgdGhlIFVURi04IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBkb21haW4gbmFt ZQ0KPiA+ICAgIE1VU1QgYmUgdXNlZCwgaS5lLiwgYWxsIG9mIHRoZSBkb21haW4gbmFtZSdzIGxh YmVscyBNVVNUIGJlIFUtbGFiZWxzDQo+ID4gICAgZXhwcmVzc2VkIGluIFVURi04IG9yIE5SLUxE SCBsYWJlbHMgW1JGQzU4OTBdOyBBLWxhYmVscyBNVVNUIE5PVCBiZQ0KPiA+ICAgIHVzZWQuICBB IFJJRCBzeXN0ZW0gY2FuIGNvbnZlcnQgYmV0d2VlbiBBLWxhYmVscyBhbmQgVS1sYWJlbHMgYnkN Cj4gPiAgICB1c2luZyB0aGUgUHVueWNvZGUgZW5jb2RpbmcgW1JGQzM0OTJdIGZvciBBLWxhYmVs cyBhcyBkZXNjcmliZWQgaW4NCj4gPiAgICB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBmb3Ig SW50ZXJuYXRpb25hbGl6ZWQgRG9tYWluIE5hbWVzIGluDQo+ID4gICAgQXBwbGljYXRpb25zIFtS RkM1ODkxXS4NCj4gPg0KPiA+IElmIHRoZSBhcHBsaWNhdGlvbiBpcyBub3QgY2hlY2tpbmcgdGhp cywgaG93IHdpbGwgaXQga25vdyB3aGV0aGVyIGFueQ0KPiA+IEEtbGFiZWxzIGhhdmUgc251Y2sg aW4/IFdpbGwgaXQgZGVwZW5kIG9uIGl0cyBETlMgcmVzb2x2ZXIgdG8gcmV0dXJuIHRoZQ0KPiA+ IElETiBpbiB0aGUgYXBwcm9wcmlhdGUgZm9ybWF0PyBUaGUgZm9yZWdvaW5nIHRleHQgaW1wbGll cyB0aGF0IHRoZSBSSUQNCj4gPiBzeXN0ZW0gd2lsbCBkbyB0aGUgY29udmVyc2lvbiwgc28gaXQn cyBub3QgY2xlYXIgdG8gbWUgd2hlcmUgdGhlDQo+ID4gcmVzcG9uc2liaWxpdHkgbGllcyAoYW5k IGlmIGl0J3Mgbm90IGNsZWFyIHRvIG1lLCBpdCBtaWdodCBiZSBjbGVhciB0bw0KPiA+IGFuIGlt cGxlbWVudGVyKS4NCg0KQXQgdGhlIGVuZCBvZiB0aGUgZGF5IHRoZSBiZXR0ZXIgYW5zd2VyIChJ TUhPKSBpcyAiZGVwZW5kIG9uIGl0cyBETlMgcmVzb2x2ZXIiLg0KSWYgd2UgY2FuIGV4cGVjdCB0 aGUgRE5TIHJlc29sdmVyIHRvIGhhbmRsZSBjb252ZXJ0aW5nIEEtbGFiZWxzIHRvIFUtbGFiZWxz IGluDQphbiBJRE4gYW5kIHJldHVybmluZyB0aGUgcmVzdWx0LCB0aGUgbGFzdCBzZW50ZW5jZSBp biBTZWN0aW9uIDExIG9mIHRoZSBkcmFmdA0KY2FuIGJlIHJlcGxhY2VkIGJ5Og0KDQogICAgICAg IFJJRCBzeXN0ZW1zIGFyZSBleHBlY3RlZCB0byBvYnRhaW4gYW4gSUROIG1lZXRpbmcgdGhlc2Ug cmVxdWlyZW1lbnRzDQogICAgICAgIGJ5IGFza2luZyBhIEROUyByZXNvbHZlciB0byByZXR1cm4g YW4gSUROIHRoYXQgZG9lcyBub3QgY29udGFpbg0KICAgICAgICBBLWxhYmVscyAoZXZlbiBpZiB0 aGUgaW5wdXQgSUROIGNvbnRhaW5zIEEtbGFiZWxzKS4NCg0KKiogV2lsbCB0aGF0IHdvcms/DQoN Cj4gPiBXaGF0IHdlIGNhcmUgYWJvdXQgaXMgY29uc2lzdGVudCB0cmFuc3BvcnQgc28gdGhhdCBh cHBsaWNhdGlvbnMgY2FuDQo+ID4gc2hhcmUgZGF0YS4gIEFzIGxvbmcgYXMgdGhlIGRhdGEgcmVj ZWl2ZWQgaXMgdGhlIHNhbWUgZm9yIGV2ZXJ5DQo+ID4gaW1wbGVtZW50YXRpb24sIHdlIHNob3Vs ZG4ndCBjYXJlIGhvdyB0aGV5IHVzZSB0aGUgZG9tYWluIG5hbWVzIGluDQo+ID4gdGhlaXIgYXBw bGljYXRpb24sIHJpZ2h0Pw0KPg0KPiBVbmxlc3MgdGhleSBhcmUgbWFraW5nIGFjY2VzcyBkZWNp c2lvbnMgKGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uLA0KPiBldGMuKSBiYXNlZCBvbiB0 aG9zZSBkb21haW4gbmFtZXMsIGJlY2F1c2UgdGhlbiB0aGV5IG5lZWQgdG8gYmUgY29tcGFyZWQN Cj4gY29ycmVjdGx5LiBCdXQgaWYgUklEIHN5c3RlbXMgYXJlIG1ha2luZyB0aG9zZSBkZWNpc2lv bnMgYmFzZWQgb24gSVANCj4gYWRkcmVzcyBhbnl3YXksIHRoZW4gSSdtIG11Y2ggbGVzcyBjb25j ZXJuZWQgLS0gcGVyaGFwcyBldmVuIG5vdA0KPiBjb25jZXJuZWQgYXQgYWxsLg0KDQpUaGUgTm9k ZU5hbWUgaW4gNjA0NS1iaXMgaXMgbm90IHVzZWQgZm9yIGFjY2VzcyBkZWNpc2lvbnMuICBBY2Nl c3MgZGVjaXNpb25zDQphcmUgc3BlY2lmaWVkIGluIDYwNDYtYmlzIC0gc2VlIHRoZSBvdGhlciB0 aHJlYWQgZGlzY3Vzc2luZyBjZXJ0aWZpY2F0ZXMsDQpETlMtSURzIGFuZCByZWZlcmVuY2UgaWRl bnRpZmllcnMuDQoNCj4gPiBLTU06IEkgc2VlIHlvdXIgcG9pbnQgaGVyZS4gIEhvdyBhYm91dCB0 aGUgZm9sbG93aW5nIHRleHQgdG8gbWFrZSBpdCBjbGVhcg0KPiA+IHRoYXQgdGhlIElQIGFkZHJl c3MgaXMgcmVxdWlyZWQgYW5kIHRoZSBETlMgbmFtZSBpcyBkZXJpdmVkIGZyb20gdGhlIElQIGFk ZHJlc3M6DQoNClsuLi4gdGV4dCBtb2RpZmljYXRpb24gc25pcHBlZCAuLi5dDQoNCj4gU3VyZSwg dGhhdCdzIGZpbmUuIFRoZW4gbXkgcXVlc3Rpb24gYmVjb21lczogaG93IGV4YWN0bHkgaXMgdGhl IE5vZGVOYW1lDQo+IGFjdHVhbGx5IHVzZWQgaW4gUklEIHN5c3RlbXM/IEl0J3MgdGhlIHVzZSB0 aGF0IGRyaXZlcyB0aGUNCj4gaW50ZXJuYXRpb25hbGl6YXRpb24gY29uc2lkZXJhdGlvbnMuIElm IHRoZSBOb2RlTmFtZSBpcyBtZXJlbHkNCj4gZXBpcGhlbm9tZW5hbCBhbmQgaXQncyB0aGUgSVAg YWRkcmVzcyB0aGF0IHdlIHVzZSB0byBnZXQgdGhpbmdzIGRvbmUsDQo+IHRoZW4gd2UgZG9uJ3Qg cGFydGljdWxhcmx5IGNhcmUgYWJvdXQgdGhlIE5vZGVOYW1lLg0KDQpJJ2xsIGhhdmUgdG8gbGVh dmUgdGhhdCBvbmUgdG8gS2F0aGxlZW4gKGRyYWZ0IGF1dGhvcik7IHRoaXMgY29uY2VybiBhbHNv IGFwcGxpZXMNCnRvIEluY2lkZW50U291cmNlIChiZWxvdykuDQoNCj4gPj4gKDIpIFJJRFBvbGlj eSBjbGFzcywgTXNnRGVzdGluYXRpb249U291cmNlT2ZJbmNpZGVudCwgYW5kIGFsc28gdGhlIElu Y2lkZW50U291cmNlDQo+ID4+IGNsYXNzLg0KDQo+ID4gSSB0aGluayBpdCdzIGZpbmUgdG8gdXNl IElQIGFkZHJlc3MgaGVyZS4NCg0KVGhhdCdzIGdvb2QuDQoNCj4gPiBOT1RFOiB5b3Ugc2FpZCB0 aGF0IEluY2lkZW50U291cmNlIG5lZWRzIGFkZGl0aW9uYWwgdGV4dCB0byBzdGF0ZSB0aGF0DQo+ ID4gdGhlIElQIGFkZHJlc3MgcmVxdWlyZWQsIGJ1dCBJIGRvIG5vdCBzZWUgdGhhdCBoZXJlOg0K DQpUaGF0IHRleHQgd2FzIGFkZGVkLCBidXQgdGhlIGRpZmYgZG9lc27igJl0IHNob3cgZW5vdWdo IGNvbnRleHQgdG8gaW5kaWNhdGUgdGhhdCB0aGUNCnRleHQgaXMgaW4gSW5jaWRlbnRTb3VyY2Uu ICBJbiBhbnkgY2FzZSwgS2F0aGxlZW4ncyBzdWdnZXN0ZWQgYWRkaXRpb24gb2YgdGV4dCB0bw0K c2F5IHRoYXQgdGhlIElQIGFkZHJlc3MgaXMgUkVRVUlSRUQgaW4gYWxsIG9mIHRoZSBjYXNlcyBz aG91bGQgbWFrZSB0aGlzIGNyeXN0YWwgY2xlYXIuDQoNClRoZSBOb2RlIGluIEluY2lkZW50U291 cmNlIG1heSBjb250YWluIGJvdGggYSBkb21haW4gbmFtZSBhbmQgYW4gSVAgYWRkcmVzcy4NCg0K PiA+PiAoMykgUklEUG9saWN5IGNsYXNzLCBNc2dEZXN0aW5hdGlvbj1leHQtdmFsdWUuICBUaGlz IGlzIGFuIGVzY2FwZSB0aGF0IGFsbG93cw0KPiA+PiBleHRlbnNpb25zIHRvIE1zZ0Rlc3RpbmF0 aW9uLiAgVGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMgc2hvdWxkIGluY2x1ZGUgYSAidGhlcmUNCj4g Pj4gYmUgZHJhZ29ucyIgd2FybmluZyBhYm91dCBJRE5zIGluIE5vZGVOYW1lLg0KPiA+DQo+ID4g SW4gLTA5IHRoYXQgaXM6DQo+ID4NCj4gPiAgICAgICAgICAzLiAgZXh0LXZhbHVlLiAgQW4gZXNj YXBlIHZhbHVlIHVzZWQgdG8gZXh0ZW5kIHRoaXMgYXR0cmlidXRlLg0KPiA+ICAgICAgICAgICAg ICBBbGwgZXh0ZW5zaW9ucyBzaGFsbCBzcGVjaWZ5IHRoZSBjb250ZW50cyBhbmQgbWVhbmluZyBv Zg0KPiA+ICAgICAgICAgICAgICB0aGUgTm9kZSBlbGVtZW50IG9mIFJJRFBvbGljeS4gIElmIHRo ZSBOb2RlTmFtZSBlbGVtZW50IG9mDQo+ID4gICAgICAgICAgICAgIE5vZGUgaXMgdXNlZCBieSBh biBleHRlbnNpb24sIE5vZGVOYW1lIG1heSBjb250YWluIGFuDQo+ID4gICAgICAgICAgICAgIElu dGVybmF0aW9uYWxpemVkIERvbWFpbiBOYW1lIChJRE4pIGFuZCB0aGF0IElETiBpcw0KPiA+ICAg ICAgICAgICAgICByZXF1aXJlZCB0byBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgaW4gW1JGQzU4 OTBdLiAgSXQgaXMNCj4gPiAgICAgICAgICAgICAgc3Ryb25nbHkgcmVjb21tZW5kZWQgdGhhdCBS SUQgU3lzdGVtcyBzYXRpc2Z5IHRob3NlIElETg0KPiA+ICAgICAgICAgICAgICByZXF1aXJlbWVu dHMgdmlhIGFwcHJvcHJpYXRlIHVzZSBvZiB0aGUgRE5TIGFzIG9wcG9zZWQgdG8NCj4gPiAgICAg ICAgICAgICAgaW1wbGVtZW50aW5nIHRoZWlyIG93biBjaGVja3MgZm9yIHRoZXNlIHJlcXVpcmVt ZW50cy4gIEZvcg0KPiA+ICAgICAgICAgICAgICBleGFtcGxlLCBhbiBleHRlbnNpb24gY291bGQg dXNlIGJvdGggYSBOb2RlTmFtZSBhbmQgYW4gSVANCj4gPiAgICAgICAgICAgICAgYWRkcmVzcyB0 byB3aGljaCB0aGUgTm9kZU5hbWUgcmVzb2x2ZXMuICBTZWUgSU9ERUYNCj4gPiAgICAgICAgICAg ICAgW1JGQzUwNzBdLCBTZWN0aW9uIDUuMSBvbiBleHRlbnNpYmlsaXR5Lg0KPiA+DQo+ID4gVGhh dCBzZWVtcyBzbGlnaHRseSB1bmRlcnNwZWNpZmllZDogd2hhdCBpcyBtZWFudCBieSAidG8gc2F0 aXNmeSB0aGUNCj4gPiByZXF1aXJlbWVudHMgaW4gW1JGQzU4OTBdIiBhbmQgImFwcHJvcHJpYXRl IHVzZSBvZiB0aGUgRE5TIj8gRG9lcyB0aGF0DQo+ID4gbWVhbiAiZW5zdXJpbmcgdGhhdCB0aGUg SUROIHJldHJpZXZlZCBmcm9tIHRoZSBETlMgY29uc2lzdHMgb25seSBvZg0KPiA+IFUtbGFiZWxz IGFuZCBOUi1MREggbGFiZWxzIj8gSWYgc28sIGlzIHRoYXQgZG9uZSBieSBhc2tpbmcgdGhlIERO Uw0KPiA+IHJlc29sdmVyIGZvciBVLWxhYmVscywgb3IgaXMgaXQgZG9uZSBieSBhY3RpdmVseSBw ZXJmb3JtaW5nIGEgY2hlY2sgaW4NCj4gPiB0aGUgUklEIHN5c3RlbSBpdHNlbGYgKHNlZSBhYm92 ZSBhYm91dCAiTVVTVCBOT1QgYmUgQS1sYWJlbHMiKT8NCj4gPg0KPiA+IElzIHRoaXMgc29tZXRo aW5nIHRoYXQgaXMgbGVmdCBmb3IgZWFjaCBleHRlbnNpb24gdG8gZGVmaW5lPyBJZiBzbywgd2UN Cj4gPiBzaG91bGQgY29tZSBvdXQgYW5kIHNheSBwcmVjaXNlbHkgdGhhdC4NCj4gPiBfX19fX19f DQo+ID4gS01NOiBUaGUgaW1wb3J0YW50IHBhcnQgZm9yIFJJRCBpcyB0aGF0IHdlIGNvbW11bmlj YXRlIGFuZCBleGNoYW5nZSBtZXNzYWdlcyBpbiBhIHdheSB0aGF0IGV2ZXJ5b25lDQo+IGNhbiBh Y2NlcHQgYW5kIHByb2Nlc3MuICBBcHBsaWNhdGlvbiBoYW5kbGluZyBmb3IgdGhpcyB0cmFuc2xh dGlvbiwgd2hldGhlciBpdCBiZSBieSBETlMgb3Igc29tZSBvdGhlcg0KPiBtZWNoYW5pc20sIHJl YWxseSBzaG91bGRuJ3QgbWF0dGVyLiAgQXMgbG9uZyBhcyB0aGUgaW50ZXJuYXRpb25hbGl6YXRp b24gaXMgaGFuZGxlZCBpbiBhIHdheSB0aGF0IGxldHMNCj4gdXMgY29uc2lzdGVudGx5IGV4Y2hh bmdlIGluZm9ybWF0aW9uLCBJIHRoaW5rIHRoZSByZWFsIGlzc3VlcyBhcmUgc29sdmVkLCBubz8N Cj4gPiBJZiBJIGFkZCAiU2VlIFNlY3Rpb24gMTEgb2YgdGhpcyBkb2N1bWVudCBmb3INCj4gPiAg ICAgICBJbnRlcm5hdGlvbmFsaXphdGlvbiBjb25zaWRlcmF0aW9ucy4iICBEb2VzIHRoYXQgcmVz b2x2ZSB0aGUgaXNzdWUgc2luY2UgaXQgcHJvdmlkZXMNCj4gY29uc2lzdGVudCBndWlkYW5jZSB0 aGF0IGVuYWJsZXMgdGhlIGV4Y2hhbmdlIG9mIGluZm9ybWF0aW9uPw0KPiA+IF9fX19fX18NCj4N Cj4gWWVzLCB3ZSB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGFwcGxpY2F0aW9ucyBoYW5kbGUgdGhl c2UgbWF0dGVycw0KPiBjb25zaXN0ZW50bHkuIFBvaW50aW5nIHRvIFNlY3Rpb24gMTEgd291bGQg c29sdmUgdGhhdCBpc3N1ZSwgYXMgbG9uZyBhcw0KPiB3ZSBjYW4gYWdyZWUgb24gd2hhdCBnb2Vz IGluIFNlY3Rpb24gMTEuIDopDQoNCkFzc3VtaW5nIHRoYXQgdGhlIG5ldyBETlMgcmVzb2x2ZXIg dGV4dCBmb3Igc2VjdGlvbiAxMSBpcyBvaywgaGVyZSdzIGEgc3VnZ2VzdGVkDQooc2hvcnRlcikg cmV3cml0ZToNCg0KICAgICAgICAgIDMuICBleHQtdmFsdWUuICBBbiBlc2NhcGUgdmFsdWUgdXNl ZCB0byBleHRlbmQgdGhpcyBhdHRyaWJ1dGUuDQogICAgICAgICAgICAgIEFsbCBleHRlbnNpb25z IHNoYWxsIHNwZWNpZnkgdGhlIGNvbnRlbnRzIGFuZCBtZWFuaW5nIG9mDQogICAgICAgICAgICAg IHRoZSBOb2RlIGVsZW1lbnQgb2YgUklEUG9saWN5LiAgU2VlIElPREVGIFtSRkM1MDcwXSwNCiAg ICAgICAgICAgICAgU2VjdGlvbiA1LjEgb24gZXh0ZW5zaWJpbGl0eS4gSWYgdGhlIE5vZGVOYW1l IGVsZW1lbnQgb2YNCiAgICAgICAgICAgICAgTm9kZSBpcyB1c2VkIGJ5IGFuIGV4dGVuc2lvbiwg Tm9kZU5hbWUgbWF5IGNvbnRhaW4gYW4NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbGl6ZWQg RG9tYWluIE5hbWUgKElETik7IHNlZSBTZWN0aW9uIDExIGZvcg0KICAgICAgICAgICAgICBhcHBs aWNhYmxlIHJlcXVpcmVtZW50cy4gQWxsIGV4dGVuc2lvbnMgU0hPVUxEIHVzZSBhbiBJUCBBZGRy ZXNzDQogICAgICAgICAgICAgIGluIHRoZSBBZGRyZXNzIGVsZW1lbnQgb2YgdGhlIE5vZGUgY2xh c3MgYXMgdGhlIHByaW1hcnkgbWVhbnMNCiAgICAgICAgICAgICAgb2YgTm9kZSBpZGVudGlmaWNh dGlvbi4NCg0KKiogRG9lcyB0aGF0IGxvb2sgb2s/DQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBTYWludC1BbmRyZSBbbWFp bHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjYsIDIw MTIgNDoyNCBQTQ0KPiBUbzogTW9yaWFydHksIEthdGhsZWVuDQo+IENjOiBCbGFjaywgRGF2aWQ7 IG1pbGVAaWV0Zi5vcmc7IHByZXNuaWNrQHF1YWxjb21tLmNvbQ0KPiBTdWJqZWN0OiBSZTogW21p bGVdIEZXOiBJRE4gaXNzdWUNCj4NCj4gT24gMS8yNi8xMiAxOjQyIFBNLCBrYXRobGVlbi5tb3Jp YXJ0eUBlbWMuY29tIHdyb3RlOg0KPiA+IEhpIFBldGVyLA0KPiA+DQo+ID4gSSdsbCB0cnkgdG8g cmVzcG9uZCBpbiBsaW5lIGJlbG93IGFuZCBsZXQgRGF2aWQgZmlsbCBpbiBhbnkgZ2Fwcy4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPiBLYXRobGVlbg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptaWxlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlciBTYWludC1BbmRyZQ0KPiA+IFNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDI2LCAyMDEyIDM6MDUgUE0NCj4gPiBUbzogQmxhY2ssIERhdmlk DQo+ID4gQ2M6IG1pbGVAaWV0Zi5vcmc7IHByZXNuaWNrQHF1YWxjb21tLmNvbQ0KPiA+IFN1Ympl Y3Q6IFJlOiBbbWlsZV0gRlc6IElETiBpc3N1ZQ0KPiA+DQo+ID4gSGkgRGF2aWQsDQo+ID4NCj4g PiBPbiAxLzI1LzEyIDU6MDYgUE0sIGRhdmlkLmJsYWNrQGVtYy5jb20gd3JvdGU6DQo+ID4+IEhl bGxvIFBldGVyLA0KPiA+Pg0KPiA+Pj4gSW4gc2hvcnQsIHRoZXJlIGJlIGRyYWdvbnMuDQo+ID4+ DQo+ID4+IEluZGVlZCAoYXMgSSdtIGVudGlyZWx5IHRvbyB3ZWxsLWF3YXJlIG9mIGZyb20gdGhl IHByw6ljaXMgV0cpLCBob3dldmVyLCB0aGUgZ29hbA0KPiA+PiBoZXJlIGlzIHRvIGZpbmQgYSBz dWl0YWJsZSBjYXZlIGluIHdoaWNoIHRvIGNvbmZpbmUgdGhlIGRyYWdvbnMgOi0pLg0KPiA+DQo+ ID4gTmljZSB3YXkgdG8gcHV0IGl0LiBBbmQgeWVzLCB0aGUgUFJFQ0lTIFdHIGlzIGEgZnVuIHBs YWNlIHRvIGhhbmcgb3V0Lg0KPiA+IFNwZWFraW5nIG9mIHdoaWNoLCBob3cncyB0aGF0IGlTQ1NJ IHByb2ZpbGUgb2YgdGhlIHByZWNpcyBmcmFtZXdvcmsNCj4gPiBjb21pbmcgYWxvbmc/IDstKQ0K PiA+DQo+ID4+IFRoZSBwbGFjZSB0byBzdGFydCBsb29raW5nIGZvciB0aGF0IGNhdmUgaXMgYW4g dW5kZXJzdGFuZGluZyBvZiBob3cgTm9kZU5hbWUgaXMNCj4gPj4gdXNlZC4gVGhlIHF1aWNrIHN1 bW1hcnkgaXMgdGhhdCB0aGVyZSBhcmUgdGhyZWUgY2FzZXM6DQo+ID4+DQo+ID4+ICgxKSBSSURQ b2xpY3kgY2xhc3MsIE1zZ0Rlc3RpbmF0aW9uPVJJRFN5c3RlbS4NCj4gPj4NCj4gPj4gVGhlIE5v ZGVOYW1lIGlzIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgUklEIG1lc3NhZ2UsIHNvIGl0IGNhbiBi ZSByZXF1aXJlZCB0byB3b3JrDQo+ID4+IGluIHRoZSBETlMsIHdoaWNoIGFscmVhZHkgaGFzIHRv IGRlYWwgd2l0aCBmaWd1cmluZyBvdXQgd2hldGhlciBhIFUtTGFiZWwgaXMgdmFsaWQuDQo+ID4+ IFRleHQgY291bGQgYmUgYWRkZWQgdG8gcmVxdWlyZSB0aGF0IHRoZSBOb2RlTmFtZSBlaXRoZXIg YmUgdXNlZCB0byBzZW5kIHRoZSBSSUQNCj4gPj4gbWVzc2FnZSB2aWEgRE5TIGxvb2t1cCBvciB0 aGF0IGl0IGhhcyBiZWVuIGxvb2tlZCB1cCBhdCBzb21lIHBvaW50IGluIHRoZSBwYXN0IGFuZA0K PiA+PiByZXNvbHZlcyB0byB0aGUgSVAgYWRkcmVzcyB0byB3aGljaCB0aGUgUklEIG1lc3NhZ2Ug aXMgc2VudC4gIEJvdGggb2YgdGhlc2UNCj4gPj4gYXBwcm9hY2hlcyByZWx5IG9uIHRoZSBETlMg aW1wbGVtZW50YXRpb24gdG8gdmFsaWRhdGUgdGhlIFUtbGFiZWwuDQo+ID4NCj4gPiBJIHRoaW5r IHRoYXQgbWlnaHQgYmUgZmluZS4gSSBzZWUgdGhhdCB2ZXJzaW9uIC0wOSBzYXlzOg0KPiA+DQo+ ID4gICAgICAgICAgMS4gIFJJRFN5c3RlbS4gIFRoZSBhZGRyZXNzIGxpc3RlZCBpbiB0aGUgTm9k ZSBlbGVtZW50IG9mIHRoZQ0KPiA+ICAgICAgICAgICAgICBSSURQb2xpY3kgY2xhc3MgaXMgdGhl IG5leHQgdXBzdHJlYW0gUklEIHN5c3RlbSB0aGF0IHdpbGwNCj4gPiAgICAgICAgICAgICAgcmVj ZWl2ZSB0aGUgUklEIG1lc3NhZ2UuICBJZiBOb2RlTmFtZSBlbGVtZW50IG9mIHRoZSBOb2RlDQo+ ID4gICAgICAgICAgICAgIGNsYXNzIGlzIHVzZWQsIGl0IGNvbnRhaW5zIGEgRE5TIGRvbWFpbiBu YW1lLiAgVGhlDQo+ID4gICAgICAgICAgICAgIG9yaWdpbmF0aW5nIFJJRCBzeXN0ZW0gaXMgcmVx dWlyZWQgdG8gY2hlY2sgdGhhdCB0aGlzDQo+ID4gICAgICAgICAgICAgIGRvbWFpbiBuYW1lIHJl c29sdmVzIHRvIHRoZSBJUCBhZGRyZXNzIHRvIHdoaWNoIHRoZSBSSUQNCj4gPiAgICAgICAgICAg ICAgbWVzc2FnZSBpcyBzZW50LiAgVGhpcyBjaGVjayBtYXkgYmUgcGVyZm9ybWVkIGluIGFkdmFu Y2Ugb2YNCj4gPiAgICAgICAgICAgICAgc2VuZGluZyB0aGUgbWVzc2FnZSBhbmQgdGhlIHJlc3Vs dCBzYXZlZCBmb3IgZnV0dXJlIHVzZQ0KPiA+ICAgICAgICAgICAgICB3aXRoIGFkZGl0aW9uYWwg UklEIG1lc3NhZ2VzLg0KPiA+DQo+ID4gSG93ZXZlciwgdGhlIHNwZWMgcmlnaHQgbm93IHNheXMg dGhhdCB0aGUgZG9tYWluIG5hbWUgTVVTVCBOT1QgY29udGFpbg0KPiA+IEEtbGFiZWxzOg0KPiA+ DQo+ID4gICAgVGhlIE5vZGUgY2xhc3MgaWRlbnRpZmllcyBhIGhvc3Qgb3IgbmV0d29yayBkZXZp Y2UuICBUaGlzIGRvY3VtZW50DQo+ID4gICAgcmUtdXNlcyB0aGUgZGVmaW5pdGlvbiBvZiBOb2Rl IGZyb20gdGhlIElPREVGIHNwZWNpZmljYXRpb24NCj4gPiAgICBbUkZDNTA3MF0sIFNlY3Rpb24g My4xNi4gIEhvd2V2ZXIsIHRoYXQgZG9jdW1lbnQgZGlkIG5vdCBjbGVhcmx5DQo+ID4gICAgc3Bl Y2lmeSB3aGV0aGVyIGEgTm9kZU5hbWUgY291bGQgYmUgYW4gSW50ZXJuYXRpb25hbGl6ZWQgRG9t YWluIE5hbWUNCj4gPiAgICAoSUROKS4gIFJJRCBzeXN0ZW1zIE1VU1QgdHJlYXQgdGhlIE5vZGVO YW1lIGNsYXNzIGFzIGEgZG9tYWluIG5hbWUNCj4gPiAgICBzbG90IFtSRkM1ODkwXS4gIFJJRCBz eXN0ZW1zIFNIT1VMRCBzdXBwb3J0IElETnMgaW4gdGhlIE5vZGVOYW1lDQo+ID4gICAgY2xhc3M7 IGlmIHRoZXkgZG8gc28sIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiB0aGUgZG9tYWluIG5h bWUNCj4gPiAgICBNVVNUIGJlIHVzZWQsIGkuZS4sIGFsbCBvZiB0aGUgZG9tYWluIG5hbWUncyBs YWJlbHMgTVVTVCBiZSBVLWxhYmVscw0KPiA+ICAgIGV4cHJlc3NlZCBpbiBVVEYtOCBvciBOUi1M REggbGFiZWxzIFtSRkM1ODkwXTsgQS1sYWJlbHMgTVVTVCBOT1QgYmUNCj4gPiAgICB1c2VkLiAg QSBSSUQgc3lzdGVtIGNhbiBjb252ZXJ0IGJldHdlZW4gQS1sYWJlbHMgYW5kIFUtbGFiZWxzIGJ5 DQo+ID4gICAgdXNpbmcgdGhlIFB1bnljb2RlIGVuY29kaW5nIFtSRkMzNDkyXSBmb3IgQS1sYWJl bHMgYXMgZGVzY3JpYmVkIGluDQo+ID4gICAgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gZm9y IEludGVybmF0aW9uYWxpemVkIERvbWFpbiBOYW1lcyBpbg0KPiA+ICAgIEFwcGxpY2F0aW9ucyBb UkZDNTg5MV0uDQo+ID4NCj4gPiBJZiB0aGUgYXBwbGljYXRpb24gaXMgbm90IGNoZWNraW5nIHRo aXMsIGhvdyB3aWxsIGl0IGtub3cgd2hldGhlciBhbnkNCj4gPiBBLWxhYmVscyBoYXZlIHNudWNr IGluPyBXaWxsIGl0IGRlcGVuZCBvbiBpdHMgRE5TIHJlc29sdmVyIHRvIHJldHVybiB0aGUNCj4g PiBJRE4gaW4gdGhlIGFwcHJvcHJpYXRlIGZvcm1hdD8gVGhlIGZvcmVnb2luZyB0ZXh0IGltcGxp ZXMgdGhhdCB0aGUgUklEDQo+ID4gc3lzdGVtIHdpbGwgZG8gdGhlIGNvbnZlcnNpb24sIHNvIGl0 J3Mgbm90IGNsZWFyIHRvIG1lIHdoZXJlIHRoZQ0KPiA+IHJlc3BvbnNpYmlsaXR5IGxpZXMgKGFu ZCBpZiBpdCdzIG5vdCBjbGVhciB0byBtZSwgaXQgbWlnaHQgYmUgY2xlYXIgdG8NCj4gPiBhbiBp bXBsZW1lbnRlcikuDQo+ID4gX19fX19fX19fDQo+ID4gS01NOiBXZSBzdGF0ZSB0aGF0IHRoZSBk b2N1bWVudCBtdXN0IGJlIFVURi04IGNvbXBsaWFudCgiVGhlIHVzZSBvZiBVVEYtOCBpcyBSRVFV SVJFRCIpLiAgRG9lcyB0aGF0DQo+IGNvdmVyIHRoZSBjaGVja2luZyBzaW5jZSBBLWxhYmVscyBh cmUgbm90IFVURi04IGZvcm1hdHRlZD8NCj4NCj4gTm90IGV4YWN0bHkuIEFzIEkgbWVudGlvbmVk IHByZXZpb3VzbHksIHRoZSBjaGFyYWN0ZXIgZW5jb2Rpbmcgb2YgdGhlDQo+IFJJRCBkb2N1bWVu dCAoZS5nLiwgYXMgVVRGLTgpIGlzIGRpc3RpbmN0IGZyb20gdGhlIGNoYXJhY3RlciByZXBlcnRv aXJlDQo+IG9mIGluZm9ybWF0aW9uIHRoYXQgZ29lcyBpbiB0aGUgZG9tYWluIG5hbWUgc2xvdCAo aGVyZSwgdGhlIE5vZGVOYW1lKS4gQQ0KPiBkb2N1bWVudCB0aGF0IGhhcyBhbiBlbmNvZGluZyBv ZiBVVEYtOCBjYW4gaW5jbHVkZSBhbGwgc29ydHMgb2YgZGF0YQ0KPiBlbGVtZW50cyB3aG9zZSBj aGFyYWN0ZXIgcmVwZXJ0b2lyZSBpcyBsaW1pdGVkIHRvIHRoZSBVUy1BU0NJSSByYW5nZQ0KPiAo ZS5nLiwgdGhpcyBpcyB0cnVlIG9mIElQIGFkZHJlc3NlcykuIFRoZSByZWxldmFudCBkaXN0aW5j dGlvbiBiZXR3ZWVuDQo+IEEtbGFiZWxzIGFuZCBVLWxhYmVscyBpcyBub3QgdGhlIGVuY29kaW5n IG9mIHRoZSBSSUQgZG9jdW1lbnQgaW4gd2hpY2gNCj4gdGhleSBhcmUgaW5jbHVkZWQgKE5ldHdv cmsgVmlydHVhbCBUZXJtaW5hbCBbUkZDNTE5OF0gdnMuIFVURi04KSBidXQgdGhlDQo+IGNoYXJh Y3RlciByZXBlcnRvaXJlIChvbmx5IGNoYXJhY3RlcnMgaW4gdGhlIFVTLUFTQ0lJIHJhbmdlIGZv ciBBLWxhYmVscw0KPiBiZWNhdXNlIG9mIHRoZSBzcGVjaWFsIGZlYXR1cmVzIG9mIFB1bnljb2Rl IHZzLiBhbnkgVW5pY29kZSBsZXR0ZXIsDQo+IGRpZ2l0LCBvciBoeXBoZW4gZm9yIFUtbGFiZWxz KS4gTmF0dXJhbGx5LCBpbiBvcmRlciB0byBpbmNsdWRlIGEgVS1sYWJlbA0KPiBkaXJlY3RseSBp biBhIGRvY3VtZW50IG9yIHByb3RvY29sIGl0IHdpbGwgbmVlZCB0byB1c2UgYW4gZW5jb2Rpbmcg dGhhdA0KPiBhbGxvd3MgVW5pY29kZSBjaGFyYWN0ZXJzIChzdWNoIGFzIFVURi04KSwgYnV0IGFu IEEtbGFiZWwgY2FuIGJlDQo+IGluY2x1ZGVkIGluIGEgVVRGLTggZG9jdW1lbnQganVzdCBmaW5l IC0tIHRoZSBkZWNpc2lvbnMgYXJlIHNlcGFyYXRlLg0KPg0KPiA+IFdvdWxkIHRoZSBxdWVzdGlv biBiZSByZXNvbHZlZCBieSBjaGFuZ2luZzoNCj4gPiAiIEEgUklEIHN5c3RlbSBjYW4gY29udmVy dCBiZXR3ZWVuIEEtbGFiZWxzIGFuZCBVLWxhYmVscyBieSAiDQo+ID4gVE86ICIgQSBhbiBhcHBs aWNhdGlvbiBjb21tdW5pY2F0aW5nIHZpYSBSSUQgY2FuIGNvbnZlcnQgYmV0d2VlbiBBLWxhYmVs cyBhbmQgVS1sYWJlbHMgYnkgIg0KPg0KPiBJIHRoaW5rIHRoYXQgbWlnaHQgYmUgYSBkaXN0aW5j dGlvbiB3aXRob3V0IGEgZGlmZmVyZW5jZS4NCj4NCj4gPiBUaGlzIHdvdWxkIHB1dCB0aGUgYnVy ZGVuIHdpdGhpbiBhIGFwcGxpY2F0aW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgQVBJIHRoYXQgaXMg SU9ERUYvUklEL1JJRA0KPiBUcmFuc3BvcnQuDQo+DQo+IEkgc2VlIHRoYXQgYXMgYW4gaW50ZWdy YWwgcGFydCBvZiB0aGUgUklEIHN5c3RlbSwgYnV0IHBlcmhhcHMgSSdtDQo+IG1pc3Npbmcgc29t ZXRoaW5nLg0KPg0KPiA+IFdoYXQgd2UgY2FyZSBhYm91dCBpcyBjb25zaXN0ZW50IHRyYW5zcG9y dCBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gc2hhcmUgZGF0YS4gIEFzIGxvbmcgYXMgdGhlIGRh dGENCj4gcmVjZWl2ZWQgaXMgdGhlIHNhbWUgZm9yIGV2ZXJ5IGltcGxlbWVudGF0aW9uLCB3ZSBz aG91bGRuJ3QgY2FyZSBob3cgdGhleSB1c2UgdGhlIGRvbWFpbiBuYW1lcyBpbg0KPiB0aGVpciBh cHBsaWNhdGlvbiwgcmlnaHQ/DQo+DQo+IFVubGVzcyB0aGV5IGFyZSBtYWtpbmcgYWNjZXNzIGRl Y2lzaW9ucyAoYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24sDQo+IGV0Yy4pIGJhc2VkIG9u IHRob3NlIGRvbWFpbiBuYW1lcywgYmVjYXVzZSB0aGVuIHRoZXkgbmVlZCB0byBiZSBjb21wYXJl ZA0KPiBjb3JyZWN0bHkuIEJ1dCBpZiBSSUQgc3lzdGVtcyBhcmUgbWFraW5nIHRob3NlIGRlY2lz aW9ucyBiYXNlZCBvbiBJUA0KPiBhZGRyZXNzIGFueXdheSwgdGhlbiBJJ20gbXVjaCBsZXNzIGNv bmNlcm5lZCAtLSBwZXJoYXBzIGV2ZW4gbm90DQo+IGNvbmNlcm5lZCBhdCBhbGwuDQo+DQo+ID4g X19fX19fX19fXw0KPiA+IEFuZCBpZiBvbmx5IFUtbGFiZWxzIGFyZSBwZXJtaXR0ZWQsIHRoZW4g Y29tcGFyaXNvbiBwcm9jZWVkcyB1c2luZyB0aGUNCj4gPiBVLWxhYmVscyBhcyBpbnB1dC4gSG93 ZXZlciwgaWYgc28gd2UgbWlnaHQgbmVlZCB0byBzcGVjaWZ5IG1hcHBpbmdzIG9mDQo+ID4gdGhl IGtpbmQgZGlzY3Vzc2VkIGluIFJGQyA1ODk1IChlLmcuLCBtYXBwaW5nIHVwcGVyY2FzZSBhbmQg dGl0bGVjYXNlIHRvDQo+ID4gbG93ZXJjYXNlIHNvIHRoYXQgUFLDiUNJUy5leGFtcGxlLmNvbSBp cyB0cmVhdGVkICJ0aGUgc2FtZSIgYXMNCj4gPiBwcsOpY2lzLmV4YW1wbGUuY29tKS4NCj4gPg0K PiA+IEJVVC4uLg0KPiA+DQo+ID4gV2lsbCBSSUQgc3lzdGVtcyBpbiBmYWN0IGJlIGRvaW5nIHN1 Y2ggY29tcGFyaXNvbnM/IFRoZSB0ZXh0IGZyb20gdGhlDQo+ID4gZmlyc3QgcGFyYWdyYXBoIHF1 b3RlZCBhYm92ZSBpbmRpY2F0ZXMgdGhhdCBSSUQgc3lzdGVtcyB3aWxsIGJlIGNoZWNraW5nDQo+ ID4gdGhlIGFzc29jaWF0aW9uIGJldHdlZW4gYSBETlMgZG9tYWluIG5hbWUgYW5kIGFuIElQIGFk ZHJlc3MsIG5vdA0KPiA+IGRpcmVjdGx5IGNvbXBhcmluZyBETlMgZG9tYWluIG5hbWVzIChpbmNs dWRpbmcgSUROcykuIElmIHRoYXQgaXMgdHJ1ZSwNCj4gPiB0aGVuIHdlIHByb2JhYmx5ICpkb24n dCogbmVlZCB0byBjYXJlIG11Y2ggYWJvdXQgY29tcGFyaXNvbiBhbmQgYW55IHRhbGsNCj4gPiBv ZiBtYXBwaW5ncyBpcyBtb290LiBDYW4geW91IHBsZWFzZSB2ZXJpZnkgdGhhdCBSSUQgc3lzdGVt cyB3aWxsIGJlDQo+ID4gY2hlY2tpbmcgdGhlIGFzc29jaWF0aW9uIHdpdGggdGhlIElQIGFkZHJl c3MsIHJhdGhlciB0aGFuIGRpcmVjdGx5DQo+ID4gY29tcGFyaW5nIEROUyBkb21haW4gbmFtZXM/ DQo+ID4gX19fX19fXw0KPiA+IEtNTTogSSBzZWUgeW91ciBwb2ludCBoZXJlLiAgSG93IGFib3V0 IHRoZSBmb2xsb3dpbmcgdGV4dCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlIElQIGFkZHJlc3Mg aXMNCj4gcmVxdWlyZWQgYW5kIHRoZSBETlMgbmFtZSBpcyBkZXJpdmVkIGZyb20gdGhlIElQIGFk ZHJlc3M6DQo+ID4NCj4gPiAgICAgICAgICAxLiAgUklEU3lzdGVtLiAgVGhlIElQIGFkZHJlc3Mg b2YgdGhlIG5leHQgdXBzdHJlYW0gc3lzdGVtIGFjY2VwdGluZyBSSUQgY29tbXVuaWNhdGlvbnMg aXMNCj4gUkVRVUlSRUQgYW5kIGlzIGxpc3RlZCBpbiB0aGUgTm9kZSBlbGVtZW50IG9mIHRoZQ0K PiA+ICAgICAgICAgICAgICBSSURQb2xpY3kgY2xhc3MuICBJZiBOb2RlTmFtZSBlbGVtZW50IG9m IHRoZSBOb2RlDQo+ID4gICAgICAgICAgICAgIGNsYXNzIGlzIHVzZWQsIGl0IGNvbnRhaW5zIGEg RE5TIGRvbWFpbiBuYW1lLiAgVGhlDQo+ID4gICAgICAgICAgICAgIG9yaWdpbmF0aW5nIFJJRCBz eXN0ZW0gaXMgcmVxdWlyZWQgdG8gY2hlY2sgdGhhdCB0aGlzDQo+ID4gICAgICAgICAgICAgIGRv bWFpbiBuYW1lIHJlc29sdmVzIHRvIHRoZSBJUCBhZGRyZXNzIHRvIHdoaWNoIHRoZSBSSUQNCj4g PiAgICAgICAgICAgICAgbWVzc2FnZSBpcyBzZW50LiAgVGhpcyBjaGVjayBtYXkgYmUgcGVyZm9y bWVkIGluIGFkdmFuY2Ugb2YNCj4gPiAgICAgICAgICAgICAgc2VuZGluZyB0aGUgbWVzc2FnZSBh bmQgdGhlIHJlc3VsdCBzYXZlZCBmb3IgZnV0dXJlIHVzZQ0KPiA+ICAgICAgICAgICAgICB3aXRo IGFkZGl0aW9uYWwgUklEIG1lc3NhZ2VzLg0KPiA+IF9fX19fXw0KPg0KPiBTdXJlLCB0aGF0J3Mg ZmluZS4gVGhlbiBteSBxdWVzdGlvbiBiZWNvbWVzOiBob3cgZXhhY3RseSBpcyB0aGUgTm9kZU5h bWUNCj4gYWN0dWFsbHkgdXNlZCBpbiBSSUQgc3lzdGVtcz8gSXQncyB0aGUgdXNlIHRoYXQgZHJp dmVzIHRoZQ0KPiBpbnRlcm5hdGlvbmFsaXphdGlvbiBjb25zaWRlcmF0aW9ucy4gSWYgdGhlIE5v ZGVOYW1lIGlzIG1lcmVseQ0KPiBlcGlwaGVub21lbmFsIGFuZCBpdCdzIHRoZSBJUCBhZGRyZXNz IHRoYXQgd2UgdXNlIHRvIGdldCB0aGluZ3MgZG9uZSwNCj4gdGhlbiB3ZSBkb24ndCBwYXJ0aWN1 bGFybHkgY2FyZSBhYm91dCB0aGUgTm9kZU5hbWUuDQo+DQo+ID4+ICgyKSBSSURQb2xpY3kgY2xh c3MsIE1zZ0Rlc3RpbmF0aW9uPVNvdXJjZU9mSW5jaWRlbnQsIGFuZCBhbHNvIHRoZSBJbmNpZGVu dFNvdXJjZQ0KPiA+PiBjbGFzcy4NCj4gPj4NCj4gPj4gSW4gYm90aCBvZiB0aGVzZSBjYXNlcyB0 aGUgSVAgYWRkcmVzcyBpcyB0aGUgcHJpbWFyeSBpZGVudGlmaWVyIChJbmNpZGVudFNvdXJjZQ0K PiA+PiBuZWVkcyBhZGRpdGlvbmFsIHRleHQgdG8gc3RhdGUgdGhhdCB0aGUgSVAgYWRkcmVzcyBp cyByZXF1aXJlZCAtIHRoYXQgYXBwZWFycyB0bw0KPiA+PiBoYXZlIGJlZW4gb3Zlcmxvb2tlZCku ICBUaGVyZSBhcmUgYSBjb3VwbGUgb2Ygb3B0aW9ucyBoZXJlOg0KPiA+Pg0KPiA+PiBhKSBUaGUg c2ltcGxlc3QgaXMgdG8gcHJvaGliaXQgTm9kZU5hbWUgdXNhZ2UuDQo+ID4+IGIpIE5vZGVOYW1l IGNvdWxkIGJlIHJlcXVpcmVkIHRvIGNvcnJlc3BvbmQgdG8gdGhlIElQIGFkZHJlc3MgdmlhIERO UyBsb29rdXAuDQo+ID4NCj4gPiBJbiAtMDkgdGhhdCBpczoNCj4gPg0KPiA+ICAgICAgICAgIDIu ICBTb3VyY2VPZkluY2lkZW50LiAgVGhlIEFkZHJlc3MgZWxlbWVudCBvZiB0aGUgTm9kZSBlbGVt ZW50DQo+ID4gICAgICAgICAgICAgIGNvbnRhaW5zIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBpbmNp ZGVudCBzb3VyY2UsIGFuZCB0aGUNCj4gPiAgICAgICAgICAgICAgTm9kZU5hbWUgZWxlbWVudCBv ZiB0aGUgTm9kZSBjbGFzcyBpcyBub3QgdXNlZC4gIFRoZSBJUA0KPiA+ICAgICAgICAgICAgICBh ZGRyZXNzIGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBwYXRoIG9mIHN5c3RlbXMgYWNjZXB0aW5n DQo+ID4gICAgICAgICAgICAgIFJJRCBjb21tdW5pY2F0aW9ucyB0aGF0IHdpbGwgYmUgdXNlZCB0 byBmaW5kIHRoZSBjbG9zZXN0DQo+ID4gICAgICAgICAgICAgIFJJRCBzeXN0ZW0gdG8gdGhlIHNv dXJjZSBvZiBhbiBhdHRhY2sgaW4gd2hpY2ggdGhlIElQDQo+ID4gICAgICAgICAgICAgIGFkZHJl c3MgdXNlZCBieSB0aGUgc291cmNlIGlzIGJlbGlldmVkIHRvIGJlIHZhbGlkIGFuZCBhDQo+ID4g ICAgICAgICAgICAgIFJlcXVlc3QgbWVzc2FnZSB3aXRoIE1zZ0RzdCBzZXQgdG8gSW52ZXN0aWdh dGlvblJlcXVlc3QgaXMNCj4gPiAgICAgICAgICAgICAgdXNlZC4gIFRoaXMgaXMgbm90IHRvIGJl IGNvbmZ1c2VkIHdpdGggdGhlIEluY2lkZW50U291cmNlDQo+ID4gICAgICAgICAgICAgIGNsYXNz LCBhcyB0aGUgZGVmaW5lZCB2YWx1ZSBoZXJlIGlzIGZyb20gYW4gaW5pdGlhbCB0cmFjZQ0KPiA+ ICAgICAgICAgICAgICBvciBpbnZlc3RpZ2F0aW9uIFJlcXVlc3QsIG5vdCB0aGUgc291cmNlIHVz ZWQgaW4gYSBSZXN1bHQNCj4gPiAgICAgICAgICAgICAgbWVzc2FnZS4NCj4gPg0KPiA+IEkgdGhp bmsgaXQncyBmaW5lIHRvIHVzZSBJUCBhZGRyZXNzIGhlcmUuDQo+ID4NCj4gPiBOT1RFOiB5b3Ug c2FpZCB0aGF0IEluY2lkZW50U291cmNlIG5lZWRzIGFkZGl0aW9uYWwgdGV4dCB0byBzdGF0ZSB0 aGF0DQo+ID4gdGhlIElQIGFkZHJlc3MgcmVxdWlyZWQsIGJ1dCBJIGRvIG5vdCBzZWUgdGhhdCBo ZXJlOg0KPiA+IF9fX19fDQo+ID4gS01NOiBUaGFua3MsIGlmIHdlIGFyZSBmaXhpbmcgdGV4dCwg bGV0J3MganVzdCBhZGQgdGhhdCBub3cuICBUaGlzIG9uZSBzaG91bGQgYmUgZWFzeS4NCj4gPg0K PiA+IFByb3Bvc2VkOg0KPiA+ICAgICAgICAgIDIuICBTb3VyY2VPZkluY2lkZW50LiAgVGhlIEFk ZHJlc3MgZWxlbWVudCBvZiB0aGUgTm9kZSBlbGVtZW50DQo+ID4gICAgICAgICAgICAgIGNvbnRh aW5zIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBpbmNpZGVudCBzb3VyY2UsIGFuZCB0aGUNCj4gPiAg ICAgICAgICAgICAgTm9kZU5hbWUgZWxlbWVudCBvZiB0aGUgTm9kZSBjbGFzcyBpcyBub3QgdXNl ZC4gIFRoZSBJUA0KPiA+ICAgICAgICAgICAgICBhZGRyZXNzIGlzIFJFUVVJUkVEIHdoZW4gdGhp cyBvcHRpb24gaXMgc2VsZWN0ZWQuICBUaGUgSVAgYWRkcmVzcyBpcyB1c2VkIHRvIGRldGVybWlu ZQ0KPiB0aGUgcGF0aCBvZiBzeXN0ZW1zIGFjY2VwdGluZw0KPiA+ICAgICAgICAgICAgICBSSUQg Y29tbXVuaWNhdGlvbnMgdGhhdCB3aWxsIGJlIHVzZWQgdG8gZmluZCB0aGUgY2xvc2VzdA0KPiA+ ICAgICAgICAgICAgICBSSUQgc3lzdGVtIHRvIHRoZSBzb3VyY2Ugb2YgYW4gYXR0YWNrIGluIHdo aWNoIHRoZSBJUA0KPiA+ICAgICAgICAgICAgICBhZGRyZXNzIHVzZWQgYnkgdGhlIHNvdXJjZSBp cyBiZWxpZXZlZCB0byBiZSB2YWxpZCBhbmQgYQ0KPiA+ICAgICAgICAgICAgICBSZXF1ZXN0IG1l c3NhZ2Ugd2l0aCBNc2dEc3Qgc2V0IHRvIEludmVzdGlnYXRpb25SZXF1ZXN0IGlzDQo+ID4gICAg ICAgICAgICAgIHVzZWQuICBUaGlzIGlzIG5vdCB0byBiZSBjb25mdXNlZCB3aXRoIHRoZSBJbmNp ZGVudFNvdXJjZQ0KPiA+ICAgICAgICAgICAgICBjbGFzcywgYXMgdGhlIGRlZmluZWQgdmFsdWUg aGVyZSBpcyBmcm9tIGFuIGluaXRpYWwgdHJhY2UNCj4gPiAgICAgICAgICAgICAgb3IgaW52ZXN0 aWdhdGlvbiBSZXF1ZXN0LCBub3QgdGhlIHNvdXJjZSB1c2VkIGluIGEgUmVzdWx0DQo+ID4gICAg ICAgICAgICAgIG1lc3NhZ2UuDQo+ID4gX19fX18NCj4NCj4gTG9va3MgZ29vZC4NCj4NCj4gPiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtbWlsZS1yZmM2MDQ1 LWJpcy0wOCZkaWZmdHlwZT0tLQ0KPiBodG1sJnN1Ym1pdD1HbyEmdXJsMj1kcmFmdC1pZXRmLW1p bGUtcmZjNjA0NS1iaXMtMDkNCj4gPg0KPiA+IEhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBjYW4gYmUg YWRkZWQgYmVmb3JlIHNlbmRpbmcgdGhpcyBkb2N1bWVudCB0byB0aGUNCj4gPiBSRkMgRWRpdG9y LCBvciBkdXJpbmcgQVVUSDQ4Lg0KPiA+DQo+ID4+ICgzKSBSSURQb2xpY3kgY2xhc3MsIE1zZ0Rl c3RpbmF0aW9uPWV4dC12YWx1ZS4gIFRoaXMgaXMgYW4gZXNjYXBlIHRoYXQgYWxsb3dzDQo+ID4+ IGV4dGVuc2lvbnMgdG8gTXNnRGVzdGluYXRpb24uICBUaGUgZGVzY3JpcHRpb24gb2YgdGhpcyBz aG91bGQgaW5jbHVkZSBhICJ0aGVyZQ0KPiA+PiBiZSBkcmFnb25zIiB3YXJuaW5nIGFib3V0IElE TnMgaW4gTm9kZU5hbWUuDQo+ID4NCj4gPiBJbiAtMDkgdGhhdCBpczoNCj4gPg0KPiA+ICAgICAg ICAgIDMuICBleHQtdmFsdWUuICBBbiBlc2NhcGUgdmFsdWUgdXNlZCB0byBleHRlbmQgdGhpcyBh dHRyaWJ1dGUuDQo+ID4gICAgICAgICAgICAgIEFsbCBleHRlbnNpb25zIHNoYWxsIHNwZWNpZnkg dGhlIGNvbnRlbnRzIGFuZCBtZWFuaW5nIG9mDQo+ID4gICAgICAgICAgICAgIHRoZSBOb2RlIGVs ZW1lbnQgb2YgUklEUG9saWN5LiAgSWYgdGhlIE5vZGVOYW1lIGVsZW1lbnQgb2YNCj4gPiAgICAg ICAgICAgICAgTm9kZSBpcyB1c2VkIGJ5IGFuIGV4dGVuc2lvbiwgTm9kZU5hbWUgbWF5IGNvbnRh aW4gYW4NCj4gPiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbGl6ZWQgRG9tYWluIE5hbWUgKElE TikgYW5kIHRoYXQgSUROIGlzDQo+ID4gICAgICAgICAgICAgIHJlcXVpcmVkIHRvIHNhdGlzZnkg dGhlIHJlcXVpcmVtZW50cyBpbiBbUkZDNTg5MF0uICBJdCBpcw0KPiA+ICAgICAgICAgICAgICBz dHJvbmdseSByZWNvbW1lbmRlZCB0aGF0IFJJRCBTeXN0ZW1zIHNhdGlzZnkgdGhvc2UgSURODQo+ ID4gICAgICAgICAgICAgIHJlcXVpcmVtZW50cyB2aWEgYXBwcm9wcmlhdGUgdXNlIG9mIHRoZSBE TlMgYXMgb3Bwb3NlZCB0bw0KPiA+ICAgICAgICAgICAgICBpbXBsZW1lbnRpbmcgdGhlaXIgb3du IGNoZWNrcyBmb3IgdGhlc2UgcmVxdWlyZW1lbnRzLiAgRm9yDQo+ID4gICAgICAgICAgICAgIGV4 YW1wbGUsIGFuIGV4dGVuc2lvbiBjb3VsZCB1c2UgYm90aCBhIE5vZGVOYW1lIGFuZCBhbiBJUA0K PiA+ICAgICAgICAgICAgICBhZGRyZXNzIHRvIHdoaWNoIHRoZSBOb2RlTmFtZSByZXNvbHZlcy4g IFNlZSBJT0RFRg0KPiA+ICAgICAgICAgICAgICBbUkZDNTA3MF0sIFNlY3Rpb24gNS4xIG9uIGV4 dGVuc2liaWxpdHkuDQo+ID4NCj4gPiBUaGF0IHNlZW1zIHNsaWdodGx5IHVuZGVyc3BlY2lmaWVk OiB3aGF0IGlzIG1lYW50IGJ5ICJ0byBzYXRpc2Z5IHRoZQ0KPiA+IHJlcXVpcmVtZW50cyBpbiBb UkZDNTg5MF0iIGFuZCAiYXBwcm9wcmlhdGUgdXNlIG9mIHRoZSBETlMiPyBEb2VzIHRoYXQNCj4g PiBtZWFuICJlbnN1cmluZyB0aGF0IHRoZSBJRE4gcmV0cmlldmVkIGZyb20gdGhlIEROUyBjb25z aXN0cyBvbmx5IG9mDQo+ID4gVS1sYWJlbHMgYW5kIE5SLUxESCBsYWJlbHMiPyBJZiBzbywgaXMg dGhhdCBkb25lIGJ5IGFza2luZyB0aGUgRE5TDQo+ID4gcmVzb2x2ZXIgZm9yIFUtbGFiZWxzLCBv ciBpcyBpdCBkb25lIGJ5IGFjdGl2ZWx5IHBlcmZvcm1pbmcgYSBjaGVjayBpbg0KPiA+IHRoZSBS SUQgc3lzdGVtIGl0c2VsZiAoc2VlIGFib3ZlIGFib3V0ICJNVVNUIE5PVCBiZSBBLWxhYmVscyIp Pw0KPiA+DQo+ID4gSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyBsZWZ0IGZvciBlYWNoIGV4dGVu c2lvbiB0byBkZWZpbmU/IElmIHNvLCB3ZQ0KPiA+IHNob3VsZCBjb21lIG91dCBhbmQgc2F5IHBy ZWNpc2VseSB0aGF0Lg0KPiA+IF9fX19fX18NCj4gPiBLTU06IFRoZSBpbXBvcnRhbnQgcGFydCBm b3IgUklEIGlzIHRoYXQgd2UgY29tbXVuaWNhdGUgYW5kIGV4Y2hhbmdlIG1lc3NhZ2VzIGluIGEg d2F5IHRoYXQgZXZlcnlvbmUNCj4gY2FuIGFjY2VwdCBhbmQgcHJvY2Vzcy4gIEFwcGxpY2F0aW9u IGhhbmRsaW5nIGZvciB0aGlzIHRyYW5zbGF0aW9uLCB3aGV0aGVyIGl0IGJlIGJ5IEROUyBvciBz b21lIG90aGVyDQo+IG1lY2hhbmlzbSwgcmVhbGx5IHNob3VsZG4ndCBtYXR0ZXIuICBBcyBsb25n IGFzIHRoZSBpbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBoYW5kbGVkIGluIGEgd2F5IHRoYXQgbGV0 cw0KPiB1cyBjb25zaXN0ZW50bHkgZXhjaGFuZ2UgaW5mb3JtYXRpb24sIEkgdGhpbmsgdGhlIHJl YWwgaXNzdWVzIGFyZSBzb2x2ZWQsIG5vPw0KPiA+IElmIEkgYWRkICJTZWUgU2VjdGlvbiAxMSBv ZiB0aGlzIGRvY3VtZW50IGZvcg0KPiA+ICAgICAgIEludGVybmF0aW9uYWxpemF0aW9uIGNvbnNp ZGVyYXRpb25zLiIgIERvZXMgdGhhdCByZXNvbHZlIHRoZSBpc3N1ZSBzaW5jZSBpdCBwcm92aWRl cw0KPiBjb25zaXN0ZW50IGd1aWRhbmNlIHRoYXQgZW5hYmxlcyB0aGUgZXhjaGFuZ2Ugb2YgaW5m b3JtYXRpb24/DQo+ID4gX19fX19fXw0KPg0KPiBZZXMsIHdlIHdhbnQgdG8gbWFrZSBzdXJlIHRo YXQgYXBwbGlhdGlvbnMgaGFuZGxlIHRoZXNlIG1hdHRlcnMNCj4gY29uc2lzdGVudGx5LiBQb2lu dGluZyB0byBTZWN0aW9uIDExIHdvdWxkIHNvbHZlIHRoYXQgaXNzdWUsIGFzIGxvbmcgYXMNCj4g d2UgY2FuIGFncmVlIG9uIHdoYXQgZ29lcyBpbiBTZWN0aW9uIDExLiA6KQ0KPg0KPiA+PiBTbywg dGhlIGFuc3dlciB0byB0aGUgc29tZXdoYXQgcmhldG9yaWNhbCBxdWVzdGlvbjoNCj4gPj4NCj4g Pj4+IERvIElPREVGL1JJRCBpbXBsZW1lbnRhdGlvbnMgd2FudCB0byBzaWduIHVwIGZvciBhbGwg dGhhdD8NCj4gPj4NCj4gPj4gSXMgYXBwcm94aW1hdGVseSAiWWVzLCBieSByZWx5aW5nIG9uIHRo ZSBETlMgaW1wbGVtZW50YXRpb24sIiB3aXRoIHRoZSBhZGRpdGlvbg0KPiA+PiBvZiBhICJ0aGVy ZSBiZSBkcmFnb25zIiB3YXJuaW5nIHRvIHRoZSBNc2dEZXN0aW5hdGlvbiBleHQtdmFsdWUgZXh0 ZW5zaW9uIHRleHQNCj4gPj4gdG8gY29tbXVuaWNhdGUgdGhhdCB0byBkZXNpZ25lcnMgb2YgZXh0 ZW5zaW9ucywgYW5kIGEgcG9zc2libGUgcHJvaGliaXRpb24gb2YNCj4gPj4gdXNlIG9mIE5vZGVO YW1lIHdoZW4gdGhlIElQIGFkZHJlc3MgaXMgdGhlIHByaW1hcnkgaWRlbnRpZmllci4NCj4gPg0K PiA+IEkgdGhpbmsgd2UncmUgZ2V0dGluZyBjbG9zZSB0byByZWZsZWN0aW5nIHRoYXQgaW4gdGV4 dCwgYnV0IGEgZmV3DQo+ID4gY2xhcmlmaWNhdGlvbnMgd291bGQgaGVscCwgYXMgd291bGQgdmFs aWRhdGlvbiBmcm9tIHRoZSBXRyB0aGF0IHRoaXMNCj4gPiBkaXJlY3Rpb24gaXMgYWdyZWVhYmxl Lg0KPiA+DQo+ID4gSSByZWFsaXplIHRoYXQgdGhlc2UgYXJlIHRob3JueSBpc3N1ZXMgYW5kIHRo YXQgZm9sa3MgcHJvYmFibHkganVzdCB3YW50DQo+ID4gc29tZW9uZSB0byBjb21lIGZyb20gb24g aGlnaCBhbmQgc2F5ICJ5ZWEgdmVyaWx5LCBoZXJlIGlzIHRoZSBvbmUgdHJ1ZQ0KPiA+IHBhdGgg dG8gaW50ZXJuYXRpb25hbGl6YXRpb24gbmlydmFuYSIuIFVuZm9ydHVuYXRlbHksIHRoZXJlIGlz IG5vIHN1Y2gNCj4gPiBwYXRoLCBzbyB0aGUgV0cgbmVlZHMgdG8gd2VpZ2ggdGhlIGNvc3RzIGFu ZCBiZW5lZml0cywgY2xlYXJseQ0KPiA+IHVuZGVyc3RhbmQgd2hhdCBpdCdzIGRvaW5nLCBhbmQg dGhlbiBtYWtlIGEgZGVjaXNpb24gb25lIHdheSBvciB0aGUNCj4gPiBvdGhlci4gV2UndmUgaGFk IHRvbyBtYW55IFdHcyAoc29tZSBvZiB3aGljaCBJJ3ZlIGJlZW4gaW52b2x2ZWQgd2l0aCkNCj4g PiBqdXN0IHRha2Ugc29tZSBpMThuIGFkdmljZSB3aXRob3V0IGtub3dsZWRnZSwgYW5kIHRoZSBy ZXN1bHRzIGhhdmUgYmVlbg0KPiA+IGxlc3MgdGhlbiBwb3NpdGl2ZS4NCj4gPg0KPiA+IFRoYW5r cyBmb3IgeW91ciBwYXRpZW5jZSENCj4gPg0KPiA+IFBldGVyDQo+ID4gX19fX19fX19fDQo+ID4g VGhhbmsgeW91IGZvciB5b3VyIGRldGFpbGVkIHJldmlld3MhDQo+DQo+IEknbSBoZXJlIGZvciB5 b3UhIDstKQ0KPg0KPiBQZXRlcg0KPg0KPiAtLQ0KPiBQZXRlciBTYWludC1BbmRyZQ0KPiBodHRw czovL3N0cGV0ZXIuaW0vDQo+DQo+DQoNCg== From kathleen.moriarty@emc.com Thu Jan 26 14:50: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 5A5BB21F8623 for ; Thu, 26 Jan 2012 14:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.666 X-Spam-Level: X-Spam-Status: No, score=-10.666 tagged_above=-999 required=5 tests=[AWL=1.933, BAYES_00=-2.599, GB_I_LETTER=-2, 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 DeiMJkLokmxx for ; Thu, 26 Jan 2012 14:50:56 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8121F860E for ; Thu, 26 Jan 2012 14:50:53 -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 q0QMoogH009893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 17:50:52 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 26 Jan 2012 17:50:43 -0500 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0QMohJY023810; Thu, 26 Jan 2012 17:50:43 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub36.corp.emc.com ([::1]) with mapi; Thu, 26 Jan 2012 17:50:42 -0500 From: To: , Date: Thu, 26 Jan 2012 17:50:41 -0500 Thread-Topic: [mile] FW: IDN issue Thread-Index: AczccPEo8QTiRwmFQS2MYbKN0mz+PgAACJtwAAJ7Z1A= Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org, presnick@qualcomm.com Subject: Re: [mile] FW: IDN issue 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, 26 Jan 2012 22:50:58 -0000 SSBhZ3JlZSB3aXRoIERhdmlkIGFuZCB3aWxsIGp1c3QgYWRkIGEgY291cGxlIG9mIG5vdGVzIGZv ciBjbGFyaWZpY2F0aW9uLg0KDQpJZiB0aGlzIGhlbHBzIHRvIHNvbHZlIHRoZSBpc3N1ZXMsIEkn bGwgdXBkYXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4NCg0KVGhhbmsgeW91LA0KS2F0aGxlZW4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJsYWNrLCBEYXZpZA0KU2VudDog VGh1cnNkYXksIEphbnVhcnkgMjYsIDIwMTIgNTozMCBQTQ0KVG86IFBldGVyIFNhaW50LUFuZHJl OyBNb3JpYXJ0eSwgS2F0aGxlZW4NCkNjOiBtaWxlQGlldGYub3JnOyBwcmVzbmlja0BxdWFsY29t bS5jb20NClN1YmplY3Q6IFJFOiBbbWlsZV0gRlc6IElETiBpc3N1ZQ0KDQpIaSBQZXRlciwNCg0K PiA+Pj4gSW4gc2hvcnQsIHRoZXJlIGJlIGRyYWdvbnMuDQo+ID4+DQo+ID4+IEluZGVlZCAoYXMg SSdtIGVudGlyZWx5IHRvbyB3ZWxsLWF3YXJlIG9mIGZyb20gdGhlIHByw6ljaXMgV0cpLCBob3dl dmVyLCB0aGUgZ29hbA0KPiA+PiBoZXJlIGlzIHRvIGZpbmQgYSBzdWl0YWJsZSBjYXZlIGluIHdo aWNoIHRvIGNvbmZpbmUgdGhlIGRyYWdvbnMgOi0pLg0KPiA+DQo+ID4gTmljZSB3YXkgdG8gcHV0 IGl0LiBBbmQgeWVzLCB0aGUgUFJFQ0lTIFdHIGlzIGEgZnVuIHBsYWNlIHRvIGhhbmcgb3V0Lg0K PiA+IFNwZWFraW5nIG9mIHdoaWNoLCBob3cncyB0aGF0IGlTQ1NJIHByb2ZpbGUgb2YgdGhlIHBy ZWNpcyBmcmFtZXdvcmsNCj4gPiBjb21pbmcgYWxvbmc/IDstKQ0KDQpJJ20gd29ya2luZyBvbiBn ZXR0aW5nIGEgc2V0IG9mIGZvdXIgaVNDU0ktcmVsYXRlZCBkcmFmdHMgb3V0IG9mIHRoZSBzdG9y bSBXRyBmaXJzdC4NClNvIGZhciwgaXQncyB0aHJlZSBkb3duLCBvbmUgdG8gZ28sIHNlZSBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc3Rvcm0vIC4gIEJlDQpjYXJlZnVsIHdoYXQgeW91 IHdpc2ggZm9yIGFzIGFuIEFEIDotKS4NCg0KPiA+PiAoMSkgUklEUG9saWN5IGNsYXNzLCBNc2dE ZXN0aW5hdGlvbj1SSURTeXN0ZW0uDQoNClNlY3Rpb24gMTEgdGV4dDoNCg0KPiA+ICAgIFRoZSBO b2RlIGNsYXNzIGlkZW50aWZpZXMgYSBob3N0IG9yIG5ldHdvcmsgZGV2aWNlLiAgVGhpcyBkb2N1 bWVudA0KPiA+ICAgIHJlLXVzZXMgdGhlIGRlZmluaXRpb24gb2YgTm9kZSBmcm9tIHRoZSBJT0RF RiBzcGVjaWZpY2F0aW9uDQo+ID4gICAgW1JGQzUwNzBdLCBTZWN0aW9uIDMuMTYuICBIb3dldmVy LCB0aGF0IGRvY3VtZW50IGRpZCBub3QgY2xlYXJseQ0KPiA+ICAgIHNwZWNpZnkgd2hldGhlciBh IE5vZGVOYW1lIGNvdWxkIGJlIGFuIEludGVybmF0aW9uYWxpemVkIERvbWFpbiBOYW1lDQo+ID4g ICAgKElETikuICBSSUQgc3lzdGVtcyBNVVNUIHRyZWF0IHRoZSBOb2RlTmFtZSBjbGFzcyBhcyBh IGRvbWFpbiBuYW1lDQo+ID4gICAgc2xvdCBbUkZDNTg5MF0uICBSSUQgc3lzdGVtcyBTSE9VTEQg c3VwcG9ydCBJRE5zIGluIHRoZSBOb2RlTmFtZQ0KPiA+ICAgIGNsYXNzOyBpZiB0aGV5IGRvIHNv LCB0aGUgVVRGLTggcmVwcmVzZW50YXRpb24gb2YgdGhlIGRvbWFpbiBuYW1lDQo+ID4gICAgTVVT VCBiZSB1c2VkLCBpLmUuLCBhbGwgb2YgdGhlIGRvbWFpbiBuYW1lJ3MgbGFiZWxzIE1VU1QgYmUg VS1sYWJlbHMNCj4gPiAgICBleHByZXNzZWQgaW4gVVRGLTggb3IgTlItTERIIGxhYmVscyBbUkZD NTg5MF07IEEtbGFiZWxzIE1VU1QgTk9UIGJlDQo+ID4gICAgdXNlZC4gIEEgUklEIHN5c3RlbSBj YW4gY29udmVydCBiZXR3ZWVuIEEtbGFiZWxzIGFuZCBVLWxhYmVscyBieQ0KPiA+ICAgIHVzaW5n IHRoZSBQdW55Y29kZSBlbmNvZGluZyBbUkZDMzQ5Ml0gZm9yIEEtbGFiZWxzIGFzIGRlc2NyaWJl ZCBpbg0KPiA+ICAgIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGZvciBJbnRlcm5hdGlvbmFs aXplZCBEb21haW4gTmFtZXMgaW4NCj4gPiAgICBBcHBsaWNhdGlvbnMgW1JGQzU4OTFdLg0KPiA+ DQo+ID4gSWYgdGhlIGFwcGxpY2F0aW9uIGlzIG5vdCBjaGVja2luZyB0aGlzLCBob3cgd2lsbCBp dCBrbm93IHdoZXRoZXIgYW55DQo+ID4gQS1sYWJlbHMgaGF2ZSBzbnVjayBpbj8gV2lsbCBpdCBk ZXBlbmQgb24gaXRzIEROUyByZXNvbHZlciB0byByZXR1cm4gdGhlDQo+ID4gSUROIGluIHRoZSBh cHByb3ByaWF0ZSBmb3JtYXQ/IFRoZSBmb3JlZ29pbmcgdGV4dCBpbXBsaWVzIHRoYXQgdGhlIFJJ RA0KPiA+IHN5c3RlbSB3aWxsIGRvIHRoZSBjb252ZXJzaW9uLCBzbyBpdCdzIG5vdCBjbGVhciB0 byBtZSB3aGVyZSB0aGUNCj4gPiByZXNwb25zaWJpbGl0eSBsaWVzIChhbmQgaWYgaXQncyBub3Qg Y2xlYXIgdG8gbWUsIGl0IG1pZ2h0IGJlIGNsZWFyIHRvDQo+ID4gYW4gaW1wbGVtZW50ZXIpLg0K DQpBdCB0aGUgZW5kIG9mIHRoZSBkYXkgdGhlIGJldHRlciBhbnN3ZXIgKElNSE8pIGlzICJkZXBl bmQgb24gaXRzIEROUyByZXNvbHZlciIuDQpJZiB3ZSBjYW4gZXhwZWN0IHRoZSBETlMgcmVzb2x2 ZXIgdG8gaGFuZGxlIGNvbnZlcnRpbmcgQS1sYWJlbHMgdG8gVS1sYWJlbHMgaW4NCmFuIElETiBh bmQgcmV0dXJuaW5nIHRoZSByZXN1bHQsIHRoZSBsYXN0IHNlbnRlbmNlIGluIFNlY3Rpb24gMTEg b2YgdGhlIGRyYWZ0DQpjYW4gYmUgcmVwbGFjZWQgYnk6DQoNCiAgICAgICAgUklEIHN5c3RlbXMg YXJlIGV4cGVjdGVkIHRvIG9idGFpbiBhbiBJRE4gbWVldGluZyB0aGVzZSByZXF1aXJlbWVudHMN CiAgICAgICAgYnkgYXNraW5nIGEgRE5TIHJlc29sdmVyIHRvIHJldHVybiBhbiBJRE4gdGhhdCBk b2VzIG5vdCBjb250YWluDQogICAgICAgIEEtbGFiZWxzIChldmVuIGlmIHRoZSBpbnB1dCBJRE4g Y29udGFpbnMgQS1sYWJlbHMpLg0KDQoqKiBXaWxsIHRoYXQgd29yaz8NCg0KPiA+IFdoYXQgd2Ug Y2FyZSBhYm91dCBpcyBjb25zaXN0ZW50IHRyYW5zcG9ydCBzbyB0aGF0IGFwcGxpY2F0aW9ucyBj YW4NCj4gPiBzaGFyZSBkYXRhLiAgQXMgbG9uZyBhcyB0aGUgZGF0YSByZWNlaXZlZCBpcyB0aGUg c2FtZSBmb3IgZXZlcnkNCj4gPiBpbXBsZW1lbnRhdGlvbiwgd2Ugc2hvdWxkbid0IGNhcmUgaG93 IHRoZXkgdXNlIHRoZSBkb21haW4gbmFtZXMgaW4NCj4gPiB0aGVpciBhcHBsaWNhdGlvbiwgcmln aHQ/DQo+DQo+IFVubGVzcyB0aGV5IGFyZSBtYWtpbmcgYWNjZXNzIGRlY2lzaW9ucyAoYXV0aGVu dGljYXRpb24sIGF1dGhvcml6YXRpb24sDQo+IGV0Yy4pIGJhc2VkIG9uIHRob3NlIGRvbWFpbiBu YW1lcywgYmVjYXVzZSB0aGVuIHRoZXkgbmVlZCB0byBiZSBjb21wYXJlZA0KPiBjb3JyZWN0bHku IEJ1dCBpZiBSSUQgc3lzdGVtcyBhcmUgbWFraW5nIHRob3NlIGRlY2lzaW9ucyBiYXNlZCBvbiBJ UA0KPiBhZGRyZXNzIGFueXdheSwgdGhlbiBJJ20gbXVjaCBsZXNzIGNvbmNlcm5lZCAtLSBwZXJo YXBzIGV2ZW4gbm90DQo+IGNvbmNlcm5lZCBhdCBhbGwuDQoNClRoZSBOb2RlTmFtZSBpbiA2MDQ1 LWJpcyBpcyBub3QgdXNlZCBmb3IgYWNjZXNzIGRlY2lzaW9ucy4gIEFjY2VzcyBkZWNpc2lvbnMN CmFyZSBzcGVjaWZpZWQgaW4gNjA0Ni1iaXMgLSBzZWUgdGhlIG90aGVyIHRocmVhZCBkaXNjdXNz aW5nIGNlcnRpZmljYXRlcywNCkROUy1JRHMgYW5kIHJlZmVyZW5jZSBpZGVudGlmaWVycy4NCg0K S01NOiBUaGlzIGlzIHRydWUsIHdlIHVzZSBkaWdpdGFsIHNpZ25hdHVyZXMgd2l0aGluIFJJRCBm b3IgYW55IGlkZW50aWZpY2F0aW9uIG9mIHRoZSBzZW5kZXIuICBUaGlzIGlzIHRpZWQgdG8gcHJv ZmlsZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgb3RoZXIgZW50aXRpZXMgaW4gdGhlIGV4Y2hhbmdl Lg0KDQo+ID4gS01NOiBJIHNlZSB5b3VyIHBvaW50IGhlcmUuICBIb3cgYWJvdXQgdGhlIGZvbGxv d2luZyB0ZXh0IHRvIG1ha2UgaXQgY2xlYXINCj4gPiB0aGF0IHRoZSBJUCBhZGRyZXNzIGlzIHJl cXVpcmVkIGFuZCB0aGUgRE5TIG5hbWUgaXMgZGVyaXZlZCBmcm9tIHRoZSBJUCBhZGRyZXNzOg0K DQpbLi4uIHRleHQgbW9kaWZpY2F0aW9uIHNuaXBwZWQgLi4uXQ0KDQo+IFN1cmUsIHRoYXQncyBm aW5lLiBUaGVuIG15IHF1ZXN0aW9uIGJlY29tZXM6IGhvdyBleGFjdGx5IGlzIHRoZSBOb2RlTmFt ZQ0KPiBhY3R1YWxseSB1c2VkIGluIFJJRCBzeXN0ZW1zPyBJdCdzIHRoZSB1c2UgdGhhdCBkcml2 ZXMgdGhlDQo+IGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zLiBJZiB0aGUgTm9k ZU5hbWUgaXMgbWVyZWx5DQo+IGVwaXBoZW5vbWVuYWwgYW5kIGl0J3MgdGhlIElQIGFkZHJlc3Mg dGhhdCB3ZSB1c2UgdG8gZ2V0IHRoaW5ncyBkb25lLA0KPiB0aGVuIHdlIGRvbid0IHBhcnRpY3Vs YXJseSBjYXJlIGFib3V0IHRoZSBOb2RlTmFtZS4NCg0KSSdsbCBoYXZlIHRvIGxlYXZlIHRoYXQg b25lIHRvIEthdGhsZWVuIChkcmFmdCBhdXRob3IpOyB0aGlzIGNvbmNlcm4gYWxzbyBhcHBsaWVz DQp0byBJbmNpZGVudFNvdXJjZSAoYmVsb3cpLg0KDQpLTU06IFRoZSB1c2UgY2FzZXMgdGhhdCBz ZWVtIHRvIGJlIHRoZSBjb25jZXJuIGFyZSBhY3R1YWxseSBtb3JlIGFwcGxpY2FibGUgdG8gdGhl IElPREVGIGRvY3VtZW50LiAgVGhlIFJJRCBtZXNzYWdlIGNvdWxkIHVzZSBJUCBhZGRyZXNzZXMg Zm9yIGFueSByZWFsIGNoZWNraW5nIG5lZWRlZC4gIEhhdmluZyB0aGUgRE5TIGlzIGEgbmljZSB0 aGluZywgc28gd2UgY2FuIHJlbHkgb24gSVAgYW5kIGhhdmUgdGhlIEROUyBpbmNsdWRlZCBmb3Ig dXNlcnMgdG8gdmlldy4gICBUaGlzIGNvdWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgRE5TIGFzIGlz IGN1cnJlbnRseSBzdWdnZXN0ZWQsIHB1dCBpbiB0aGUgTm9kZSBlbGVtZW50IGZvciB0aGUgUklE IG1lc3NhZ2UgYW5kIHN0b3JlZCBsb2NhbGx5IChtYXliZSB2YWxpZGF0ZWQgb24gYSBwZXJpb2Rp YyBiYXNpcykuICBUaGUgRE5TIG5hbWVzIHdpbGwgY29tZSBtb3JlIGluIGhhbmR5IHdpdGggdGhl IE5vZGUgaW5zdGFuY2VzIHdpdGhpbiB0aGUgSU9ERUYgZG9jdW1lbnQsIHdoZXJlIHlvdSB3aWxs IHRyYWNrIHRoZSBoaXN0b3J5IG9mIGFuIGluY2lkZW50IGFuZCBzeXN0ZW1zIGludm9sdmVkIGlu IHRoZSBpbnZlc3RpZ2F0aW9uIG9yIHRoZSBpbmNpZGVudCAoYm90aCBhcmUgbWFpbnRhaW5lZCBp biB0aGUgSU9ERUYgZG9jdW1lbnQgc28gaXQgc3RheXMgd2l0aCB0aGUgaW5jaWRlbnQgZHVyaW5n IHRoZSBpbnZlc3RpZ2F0aW9uIGFzIG9wcG9zZWQgdG8gdGhlIG1lc3NhZ2luZykuICBBcyBCcmlh biBwb2ludGVkIG91dCwgd2Ugd2lsbCBuZWVkIHRvIGRlYWwgd2l0aCB0aGF0IGFzIHdlbGwgYXQg c29tZSBwb2ludCBhZnRlciB3ZSBmaW5pc2ggdGhpcyB1cC4NCg0KPiA+PiAoMikgUklEUG9saWN5 IGNsYXNzLCBNc2dEZXN0aW5hdGlvbj1Tb3VyY2VPZkluY2lkZW50LCBhbmQgYWxzbyB0aGUgSW5j aWRlbnRTb3VyY2UNCj4gPj4gY2xhc3MuDQoNCj4gPiBJIHRoaW5rIGl0J3MgZmluZSB0byB1c2Ug SVAgYWRkcmVzcyBoZXJlLg0KDQpUaGF0J3MgZ29vZC4NCg0KPiA+IE5PVEU6IHlvdSBzYWlkIHRo YXQgSW5jaWRlbnRTb3VyY2UgbmVlZHMgYWRkaXRpb25hbCB0ZXh0IHRvIHN0YXRlIHRoYXQNCj4g PiB0aGUgSVAgYWRkcmVzcyByZXF1aXJlZCwgYnV0IEkgZG8gbm90IHNlZSB0aGF0IGhlcmU6DQoN ClRoYXQgdGV4dCB3YXMgYWRkZWQsIGJ1dCB0aGUgZGlmZiBkb2VzbuKAmXQgc2hvdyBlbm91Z2gg Y29udGV4dCB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0KdGV4dCBpcyBpbiBJbmNpZGVudFNvdXJjZS4g IEluIGFueSBjYXNlLCBLYXRobGVlbidzIHN1Z2dlc3RlZCBhZGRpdGlvbiBvZiB0ZXh0IHRvDQpz YXkgdGhhdCB0aGUgSVAgYWRkcmVzcyBpcyBSRVFVSVJFRCBpbiBhbGwgb2YgdGhlIGNhc2VzIHNo b3VsZCBtYWtlIHRoaXMgY3J5c3RhbCBjbGVhci4NCg0KS01NOiBHcmVhdCwgdGhhdCBzb3VuZHMg bGlrZSBhbiBhZ3JlZW1lbnQgOi0pDQoNClRoZSBOb2RlIGluIEluY2lkZW50U291cmNlIG1heSBj b250YWluIGJvdGggYSBkb21haW4gbmFtZSBhbmQgYW4gSVAgYWRkcmVzcy4NCg0KPiA+PiAoMykg UklEUG9saWN5IGNsYXNzLCBNc2dEZXN0aW5hdGlvbj1leHQtdmFsdWUuICBUaGlzIGlzIGFuIGVz Y2FwZSB0aGF0IGFsbG93cw0KPiA+PiBleHRlbnNpb25zIHRvIE1zZ0Rlc3RpbmF0aW9uLiAgVGhl IGRlc2NyaXB0aW9uIG9mIHRoaXMgc2hvdWxkIGluY2x1ZGUgYSAidGhlcmUNCj4gPj4gYmUgZHJh Z29ucyIgd2FybmluZyBhYm91dCBJRE5zIGluIE5vZGVOYW1lLg0KPiA+DQo+ID4gSW4gLTA5IHRo YXQgaXM6DQo+ID4NCj4gPiAgICAgICAgICAzLiAgZXh0LXZhbHVlLiAgQW4gZXNjYXBlIHZhbHVl IHVzZWQgdG8gZXh0ZW5kIHRoaXMgYXR0cmlidXRlLg0KPiA+ICAgICAgICAgICAgICBBbGwgZXh0 ZW5zaW9ucyBzaGFsbCBzcGVjaWZ5IHRoZSBjb250ZW50cyBhbmQgbWVhbmluZyBvZg0KPiA+ICAg ICAgICAgICAgICB0aGUgTm9kZSBlbGVtZW50IG9mIFJJRFBvbGljeS4gIElmIHRoZSBOb2RlTmFt ZSBlbGVtZW50IG9mDQo+ID4gICAgICAgICAgICAgIE5vZGUgaXMgdXNlZCBieSBhbiBleHRlbnNp b24sIE5vZGVOYW1lIG1heSBjb250YWluIGFuDQo+ID4gICAgICAgICAgICAgIEludGVybmF0aW9u YWxpemVkIERvbWFpbiBOYW1lIChJRE4pIGFuZCB0aGF0IElETiBpcw0KPiA+ICAgICAgICAgICAg ICByZXF1aXJlZCB0byBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgaW4gW1JGQzU4OTBdLiAgSXQg aXMNCj4gPiAgICAgICAgICAgICAgc3Ryb25nbHkgcmVjb21tZW5kZWQgdGhhdCBSSUQgU3lzdGVt cyBzYXRpc2Z5IHRob3NlIElETg0KPiA+ICAgICAgICAgICAgICByZXF1aXJlbWVudHMgdmlhIGFw cHJvcHJpYXRlIHVzZSBvZiB0aGUgRE5TIGFzIG9wcG9zZWQgdG8NCj4gPiAgICAgICAgICAgICAg aW1wbGVtZW50aW5nIHRoZWlyIG93biBjaGVja3MgZm9yIHRoZXNlIHJlcXVpcmVtZW50cy4gIEZv cg0KPiA+ICAgICAgICAgICAgICBleGFtcGxlLCBhbiBleHRlbnNpb24gY291bGQgdXNlIGJvdGgg YSBOb2RlTmFtZSBhbmQgYW4gSVANCj4gPiAgICAgICAgICAgICAgYWRkcmVzcyB0byB3aGljaCB0 aGUgTm9kZU5hbWUgcmVzb2x2ZXMuICBTZWUgSU9ERUYNCj4gPiAgICAgICAgICAgICAgW1JGQzUw NzBdLCBTZWN0aW9uIDUuMSBvbiBleHRlbnNpYmlsaXR5Lg0KPiA+DQo+ID4gVGhhdCBzZWVtcyBz bGlnaHRseSB1bmRlcnNwZWNpZmllZDogd2hhdCBpcyBtZWFudCBieSAidG8gc2F0aXNmeSB0aGUN Cj4gPiByZXF1aXJlbWVudHMgaW4gW1JGQzU4OTBdIiBhbmQgImFwcHJvcHJpYXRlIHVzZSBvZiB0 aGUgRE5TIj8gRG9lcyB0aGF0DQo+ID4gbWVhbiAiZW5zdXJpbmcgdGhhdCB0aGUgSUROIHJldHJp ZXZlZCBmcm9tIHRoZSBETlMgY29uc2lzdHMgb25seSBvZg0KPiA+IFUtbGFiZWxzIGFuZCBOUi1M REggbGFiZWxzIj8gSWYgc28sIGlzIHRoYXQgZG9uZSBieSBhc2tpbmcgdGhlIEROUw0KPiA+IHJl c29sdmVyIGZvciBVLWxhYmVscywgb3IgaXMgaXQgZG9uZSBieSBhY3RpdmVseSBwZXJmb3JtaW5n IGEgY2hlY2sgaW4NCj4gPiB0aGUgUklEIHN5c3RlbSBpdHNlbGYgKHNlZSBhYm92ZSBhYm91dCAi TVVTVCBOT1QgYmUgQS1sYWJlbHMiKT8NCj4gPg0KPiA+IElzIHRoaXMgc29tZXRoaW5nIHRoYXQg aXMgbGVmdCBmb3IgZWFjaCBleHRlbnNpb24gdG8gZGVmaW5lPyBJZiBzbywgd2UNCj4gPiBzaG91 bGQgY29tZSBvdXQgYW5kIHNheSBwcmVjaXNlbHkgdGhhdC4NCj4gPiBfX19fX19fDQo+ID4gS01N OiBUaGUgaW1wb3J0YW50IHBhcnQgZm9yIFJJRCBpcyB0aGF0IHdlIGNvbW11bmljYXRlIGFuZCBl eGNoYW5nZSBtZXNzYWdlcyBpbiBhIHdheSB0aGF0IGV2ZXJ5b25lDQo+IGNhbiBhY2NlcHQgYW5k IHByb2Nlc3MuICBBcHBsaWNhdGlvbiBoYW5kbGluZyBmb3IgdGhpcyB0cmFuc2xhdGlvbiwgd2hl dGhlciBpdCBiZSBieSBETlMgb3Igc29tZSBvdGhlcg0KPiBtZWNoYW5pc20sIHJlYWxseSBzaG91 bGRuJ3QgbWF0dGVyLiAgQXMgbG9uZyBhcyB0aGUgaW50ZXJuYXRpb25hbGl6YXRpb24gaXMgaGFu ZGxlZCBpbiBhIHdheSB0aGF0IGxldHMNCj4gdXMgY29uc2lzdGVudGx5IGV4Y2hhbmdlIGluZm9y bWF0aW9uLCBJIHRoaW5rIHRoZSByZWFsIGlzc3VlcyBhcmUgc29sdmVkLCBubz8NCj4gPiBJZiBJ IGFkZCAiU2VlIFNlY3Rpb24gMTEgb2YgdGhpcyBkb2N1bWVudCBmb3INCj4gPiAgICAgICBJbnRl cm5hdGlvbmFsaXphdGlvbiBjb25zaWRlcmF0aW9ucy4iICBEb2VzIHRoYXQgcmVzb2x2ZSB0aGUg aXNzdWUgc2luY2UgaXQgcHJvdmlkZXMNCj4gY29uc2lzdGVudCBndWlkYW5jZSB0aGF0IGVuYWJs ZXMgdGhlIGV4Y2hhbmdlIG9mIGluZm9ybWF0aW9uPw0KPiA+IF9fX19fX18NCj4NCj4gWWVzLCB3 ZSB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGFwcGxpY2F0aW9ucyBoYW5kbGUgdGhlc2UgbWF0dGVy cw0KPiBjb25zaXN0ZW50bHkuIFBvaW50aW5nIHRvIFNlY3Rpb24gMTEgd291bGQgc29sdmUgdGhh dCBpc3N1ZSwgYXMgbG9uZyBhcw0KPiB3ZSBjYW4gYWdyZWUgb24gd2hhdCBnb2VzIGluIFNlY3Rp b24gMTEuIDopDQoNCkFzc3VtaW5nIHRoYXQgdGhlIG5ldyBETlMgcmVzb2x2ZXIgdGV4dCBmb3Ig c2VjdGlvbiAxMSBpcyBvaywgaGVyZSdzIGEgc3VnZ2VzdGVkDQooc2hvcnRlcikgcmV3cml0ZToN Cg0KICAgICAgICAgIDMuICBleHQtdmFsdWUuICBBbiBlc2NhcGUgdmFsdWUgdXNlZCB0byBleHRl bmQgdGhpcyBhdHRyaWJ1dGUuDQogICAgICAgICAgICAgIEFsbCBleHRlbnNpb25zIHNoYWxsIHNw ZWNpZnkgdGhlIGNvbnRlbnRzIGFuZCBtZWFuaW5nIG9mDQogICAgICAgICAgICAgIHRoZSBOb2Rl IGVsZW1lbnQgb2YgUklEUG9saWN5LiAgU2VlIElPREVGIFtSRkM1MDcwXSwNCiAgICAgICAgICAg ICAgU2VjdGlvbiA1LjEgb24gZXh0ZW5zaWJpbGl0eS4gSWYgdGhlIE5vZGVOYW1lIGVsZW1lbnQg b2YNCiAgICAgICAgICAgICAgTm9kZSBpcyB1c2VkIGJ5IGFuIGV4dGVuc2lvbiwgTm9kZU5hbWUg bWF5IGNvbnRhaW4gYW4NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbGl6ZWQgRG9tYWluIE5h bWUgKElETik7IHNlZSBTZWN0aW9uIDExIGZvcg0KICAgICAgICAgICAgICBhcHBsaWNhYmxlIHJl cXVpcmVtZW50cy4gQWxsIGV4dGVuc2lvbnMgU0hPVUxEIHVzZSBhbiBJUCBBZGRyZXNzDQogICAg ICAgICAgICAgIGluIHRoZSBBZGRyZXNzIGVsZW1lbnQgb2YgdGhlIE5vZGUgY2xhc3MgYXMgdGhl IHByaW1hcnkgbWVhbnMNCiAgICAgICAgICAgICAgb2YgTm9kZSBpZGVudGlmaWNhdGlvbi4NCg0K KiogRG9lcyB0aGF0IGxvb2sgb2s/DQoNCktNTTogSSB0aGluayBzbywgUGV0ZXI/DQoNClRoYW5r cywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRl ciBTYWludC1BbmRyZSBbbWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0NCj4gU2VudDogVGh1cnNk YXksIEphbnVhcnkgMjYsIDIwMTIgNDoyNCBQTQ0KPiBUbzogTW9yaWFydHksIEthdGhsZWVuDQo+ IENjOiBCbGFjaywgRGF2aWQ7IG1pbGVAaWV0Zi5vcmc7IHByZXNuaWNrQHF1YWxjb21tLmNvbQ0K PiBTdWJqZWN0OiBSZTogW21pbGVdIEZXOiBJRE4gaXNzdWUNCj4NCj4gT24gMS8yNi8xMiAxOjQy IFBNLCBrYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tIHdyb3RlOg0KPiA+IEhpIFBldGVyLA0KPiA+ DQo+ID4gSSdsbCB0cnkgdG8gcmVzcG9uZCBpbiBsaW5lIGJlbG93IGFuZCBsZXQgRGF2aWQgZmls bCBpbiBhbnkgZ2Fwcy4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBLYXRobGVlbg0KPiA+DQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBtaWxlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlciBTYWlu dC1BbmRyZQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI2LCAyMDEyIDM6MDUgUE0NCj4g PiBUbzogQmxhY2ssIERhdmlkDQo+ID4gQ2M6IG1pbGVAaWV0Zi5vcmc7IHByZXNuaWNrQHF1YWxj b21tLmNvbQ0KPiA+IFN1YmplY3Q6IFJlOiBbbWlsZV0gRlc6IElETiBpc3N1ZQ0KPiA+DQo+ID4g SGkgRGF2aWQsDQo+ID4NCj4gPiBPbiAxLzI1LzEyIDU6MDYgUE0sIGRhdmlkLmJsYWNrQGVtYy5j b20gd3JvdGU6DQo+ID4+IEhlbGxvIFBldGVyLA0KPiA+Pg0KPiA+Pj4gSW4gc2hvcnQsIHRoZXJl IGJlIGRyYWdvbnMuDQo+ID4+DQo+ID4+IEluZGVlZCAoYXMgSSdtIGVudGlyZWx5IHRvbyB3ZWxs LWF3YXJlIG9mIGZyb20gdGhlIHByw6ljaXMgV0cpLCBob3dldmVyLCB0aGUgZ29hbA0KPiA+PiBo ZXJlIGlzIHRvIGZpbmQgYSBzdWl0YWJsZSBjYXZlIGluIHdoaWNoIHRvIGNvbmZpbmUgdGhlIGRy YWdvbnMgOi0pLg0KPiA+DQo+ID4gTmljZSB3YXkgdG8gcHV0IGl0LiBBbmQgeWVzLCB0aGUgUFJF Q0lTIFdHIGlzIGEgZnVuIHBsYWNlIHRvIGhhbmcgb3V0Lg0KPiA+IFNwZWFraW5nIG9mIHdoaWNo LCBob3cncyB0aGF0IGlTQ1NJIHByb2ZpbGUgb2YgdGhlIHByZWNpcyBmcmFtZXdvcmsNCj4gPiBj b21pbmcgYWxvbmc/IDstKQ0KPiA+DQo+ID4+IFRoZSBwbGFjZSB0byBzdGFydCBsb29raW5nIGZv ciB0aGF0IGNhdmUgaXMgYW4gdW5kZXJzdGFuZGluZyBvZiBob3cgTm9kZU5hbWUgaXMNCj4gPj4g dXNlZC4gVGhlIHF1aWNrIHN1bW1hcnkgaXMgdGhhdCB0aGVyZSBhcmUgdGhyZWUgY2FzZXM6DQo+ ID4+DQo+ID4+ICgxKSBSSURQb2xpY3kgY2xhc3MsIE1zZ0Rlc3RpbmF0aW9uPVJJRFN5c3RlbS4N Cj4gPj4NCj4gPj4gVGhlIE5vZGVOYW1lIGlzIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgUklEIG1l c3NhZ2UsIHNvIGl0IGNhbiBiZSByZXF1aXJlZCB0byB3b3JrDQo+ID4+IGluIHRoZSBETlMsIHdo aWNoIGFscmVhZHkgaGFzIHRvIGRlYWwgd2l0aCBmaWd1cmluZyBvdXQgd2hldGhlciBhIFUtTGFi ZWwgaXMgdmFsaWQuDQo+ID4+IFRleHQgY291bGQgYmUgYWRkZWQgdG8gcmVxdWlyZSB0aGF0IHRo ZSBOb2RlTmFtZSBlaXRoZXIgYmUgdXNlZCB0byBzZW5kIHRoZSBSSUQNCj4gPj4gbWVzc2FnZSB2 aWEgRE5TIGxvb2t1cCBvciB0aGF0IGl0IGhhcyBiZWVuIGxvb2tlZCB1cCBhdCBzb21lIHBvaW50 IGluIHRoZSBwYXN0IGFuZA0KPiA+PiByZXNvbHZlcyB0byB0aGUgSVAgYWRkcmVzcyB0byB3aGlj aCB0aGUgUklEIG1lc3NhZ2UgaXMgc2VudC4gIEJvdGggb2YgdGhlc2UNCj4gPj4gYXBwcm9hY2hl cyByZWx5IG9uIHRoZSBETlMgaW1wbGVtZW50YXRpb24gdG8gdmFsaWRhdGUgdGhlIFUtbGFiZWwu DQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgbWlnaHQgYmUgZmluZS4gSSBzZWUgdGhhdCB2ZXJzaW9u IC0wOSBzYXlzOg0KPiA+DQo+ID4gICAgICAgICAgMS4gIFJJRFN5c3RlbS4gIFRoZSBhZGRyZXNz IGxpc3RlZCBpbiB0aGUgTm9kZSBlbGVtZW50IG9mIHRoZQ0KPiA+ICAgICAgICAgICAgICBSSURQ b2xpY3kgY2xhc3MgaXMgdGhlIG5leHQgdXBzdHJlYW0gUklEIHN5c3RlbSB0aGF0IHdpbGwNCj4g PiAgICAgICAgICAgICAgcmVjZWl2ZSB0aGUgUklEIG1lc3NhZ2UuICBJZiBOb2RlTmFtZSBlbGVt ZW50IG9mIHRoZSBOb2RlDQo+ID4gICAgICAgICAgICAgIGNsYXNzIGlzIHVzZWQsIGl0IGNvbnRh aW5zIGEgRE5TIGRvbWFpbiBuYW1lLiAgVGhlDQo+ID4gICAgICAgICAgICAgIG9yaWdpbmF0aW5n IFJJRCBzeXN0ZW0gaXMgcmVxdWlyZWQgdG8gY2hlY2sgdGhhdCB0aGlzDQo+ID4gICAgICAgICAg ICAgIGRvbWFpbiBuYW1lIHJlc29sdmVzIHRvIHRoZSBJUCBhZGRyZXNzIHRvIHdoaWNoIHRoZSBS SUQNCj4gPiAgICAgICAgICAgICAgbWVzc2FnZSBpcyBzZW50LiAgVGhpcyBjaGVjayBtYXkgYmUg cGVyZm9ybWVkIGluIGFkdmFuY2Ugb2YNCj4gPiAgICAgICAgICAgICAgc2VuZGluZyB0aGUgbWVz c2FnZSBhbmQgdGhlIHJlc3VsdCBzYXZlZCBmb3IgZnV0dXJlIHVzZQ0KPiA+ICAgICAgICAgICAg ICB3aXRoIGFkZGl0aW9uYWwgUklEIG1lc3NhZ2VzLg0KPiA+DQo+ID4gSG93ZXZlciwgdGhlIHNw ZWMgcmlnaHQgbm93IHNheXMgdGhhdCB0aGUgZG9tYWluIG5hbWUgTVVTVCBOT1QgY29udGFpbg0K PiA+IEEtbGFiZWxzOg0KPiA+DQo+ID4gICAgVGhlIE5vZGUgY2xhc3MgaWRlbnRpZmllcyBhIGhv c3Qgb3IgbmV0d29yayBkZXZpY2UuICBUaGlzIGRvY3VtZW50DQo+ID4gICAgcmUtdXNlcyB0aGUg ZGVmaW5pdGlvbiBvZiBOb2RlIGZyb20gdGhlIElPREVGIHNwZWNpZmljYXRpb24NCj4gPiAgICBb UkZDNTA3MF0sIFNlY3Rpb24gMy4xNi4gIEhvd2V2ZXIsIHRoYXQgZG9jdW1lbnQgZGlkIG5vdCBj bGVhcmx5DQo+ID4gICAgc3BlY2lmeSB3aGV0aGVyIGEgTm9kZU5hbWUgY291bGQgYmUgYW4gSW50 ZXJuYXRpb25hbGl6ZWQgRG9tYWluIE5hbWUNCj4gPiAgICAoSUROKS4gIFJJRCBzeXN0ZW1zIE1V U1QgdHJlYXQgdGhlIE5vZGVOYW1lIGNsYXNzIGFzIGEgZG9tYWluIG5hbWUNCj4gPiAgICBzbG90 IFtSRkM1ODkwXS4gIFJJRCBzeXN0ZW1zIFNIT1VMRCBzdXBwb3J0IElETnMgaW4gdGhlIE5vZGVO YW1lDQo+ID4gICAgY2xhc3M7IGlmIHRoZXkgZG8gc28sIHRoZSBVVEYtOCByZXByZXNlbnRhdGlv biBvZiB0aGUgZG9tYWluIG5hbWUNCj4gPiAgICBNVVNUIGJlIHVzZWQsIGkuZS4sIGFsbCBvZiB0 aGUgZG9tYWluIG5hbWUncyBsYWJlbHMgTVVTVCBiZSBVLWxhYmVscw0KPiA+ICAgIGV4cHJlc3Nl ZCBpbiBVVEYtOCBvciBOUi1MREggbGFiZWxzIFtSRkM1ODkwXTsgQS1sYWJlbHMgTVVTVCBOT1Qg YmUNCj4gPiAgICB1c2VkLiAgQSBSSUQgc3lzdGVtIGNhbiBjb252ZXJ0IGJldHdlZW4gQS1sYWJl bHMgYW5kIFUtbGFiZWxzIGJ5DQo+ID4gICAgdXNpbmcgdGhlIFB1bnljb2RlIGVuY29kaW5nIFtS RkMzNDkyXSBmb3IgQS1sYWJlbHMgYXMgZGVzY3JpYmVkIGluDQo+ID4gICAgdGhlIHByb3RvY29s IHNwZWNpZmljYXRpb24gZm9yIEludGVybmF0aW9uYWxpemVkIERvbWFpbiBOYW1lcyBpbg0KPiA+ ICAgIEFwcGxpY2F0aW9ucyBbUkZDNTg5MV0uDQo+ID4NCj4gPiBJZiB0aGUgYXBwbGljYXRpb24g aXMgbm90IGNoZWNraW5nIHRoaXMsIGhvdyB3aWxsIGl0IGtub3cgd2hldGhlciBhbnkNCj4gPiBB LWxhYmVscyBoYXZlIHNudWNrIGluPyBXaWxsIGl0IGRlcGVuZCBvbiBpdHMgRE5TIHJlc29sdmVy IHRvIHJldHVybiB0aGUNCj4gPiBJRE4gaW4gdGhlIGFwcHJvcHJpYXRlIGZvcm1hdD8gVGhlIGZv cmVnb2luZyB0ZXh0IGltcGxpZXMgdGhhdCB0aGUgUklEDQo+ID4gc3lzdGVtIHdpbGwgZG8gdGhl IGNvbnZlcnNpb24sIHNvIGl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoZXJlIHRoZQ0KPiA+IHJlc3Bv bnNpYmlsaXR5IGxpZXMgKGFuZCBpZiBpdCdzIG5vdCBjbGVhciB0byBtZSwgaXQgbWlnaHQgYmUg Y2xlYXIgdG8NCj4gPiBhbiBpbXBsZW1lbnRlcikuDQo+ID4gX19fX19fX19fDQo+ID4gS01NOiBX ZSBzdGF0ZSB0aGF0IHRoZSBkb2N1bWVudCBtdXN0IGJlIFVURi04IGNvbXBsaWFudCgiVGhlIHVz ZSBvZiBVVEYtOCBpcyBSRVFVSVJFRCIpLiAgRG9lcyB0aGF0DQo+IGNvdmVyIHRoZSBjaGVja2lu ZyBzaW5jZSBBLWxhYmVscyBhcmUgbm90IFVURi04IGZvcm1hdHRlZD8NCj4NCj4gTm90IGV4YWN0 bHkuIEFzIEkgbWVudGlvbmVkIHByZXZpb3VzbHksIHRoZSBjaGFyYWN0ZXIgZW5jb2Rpbmcgb2Yg dGhlDQo+IFJJRCBkb2N1bWVudCAoZS5nLiwgYXMgVVRGLTgpIGlzIGRpc3RpbmN0IGZyb20gdGhl IGNoYXJhY3RlciByZXBlcnRvaXJlDQo+IG9mIGluZm9ybWF0aW9uIHRoYXQgZ29lcyBpbiB0aGUg ZG9tYWluIG5hbWUgc2xvdCAoaGVyZSwgdGhlIE5vZGVOYW1lKS4gQQ0KPiBkb2N1bWVudCB0aGF0 IGhhcyBhbiBlbmNvZGluZyBvZiBVVEYtOCBjYW4gaW5jbHVkZSBhbGwgc29ydHMgb2YgZGF0YQ0K PiBlbGVtZW50cyB3aG9zZSBjaGFyYWN0ZXIgcmVwZXJ0b2lyZSBpcyBsaW1pdGVkIHRvIHRoZSBV Uy1BU0NJSSByYW5nZQ0KPiAoZS5nLiwgdGhpcyBpcyB0cnVlIG9mIElQIGFkZHJlc3NlcykuIFRo ZSByZWxldmFudCBkaXN0aW5jdGlvbiBiZXR3ZWVuDQo+IEEtbGFiZWxzIGFuZCBVLWxhYmVscyBp cyBub3QgdGhlIGVuY29kaW5nIG9mIHRoZSBSSUQgZG9jdW1lbnQgaW4gd2hpY2gNCj4gdGhleSBh cmUgaW5jbHVkZWQgKE5ldHdvcmsgVmlydHVhbCBUZXJtaW5hbCBbUkZDNTE5OF0gdnMuIFVURi04 KSBidXQgdGhlDQo+IGNoYXJhY3RlciByZXBlcnRvaXJlIChvbmx5IGNoYXJhY3RlcnMgaW4gdGhl IFVTLUFTQ0lJIHJhbmdlIGZvciBBLWxhYmVscw0KPiBiZWNhdXNlIG9mIHRoZSBzcGVjaWFsIGZl YXR1cmVzIG9mIFB1bnljb2RlIHZzLiBhbnkgVW5pY29kZSBsZXR0ZXIsDQo+IGRpZ2l0LCBvciBo eXBoZW4gZm9yIFUtbGFiZWxzKS4gTmF0dXJhbGx5LCBpbiBvcmRlciB0byBpbmNsdWRlIGEgVS1s YWJlbA0KPiBkaXJlY3RseSBpbiBhIGRvY3VtZW50IG9yIHByb3RvY29sIGl0IHdpbGwgbmVlZCB0 byB1c2UgYW4gZW5jb2RpbmcgdGhhdA0KPiBhbGxvd3MgVW5pY29kZSBjaGFyYWN0ZXJzIChzdWNo IGFzIFVURi04KSwgYnV0IGFuIEEtbGFiZWwgY2FuIGJlDQo+IGluY2x1ZGVkIGluIGEgVVRGLTgg ZG9jdW1lbnQganVzdCBmaW5lIC0tIHRoZSBkZWNpc2lvbnMgYXJlIHNlcGFyYXRlLg0KPg0KPiA+ IFdvdWxkIHRoZSBxdWVzdGlvbiBiZSByZXNvbHZlZCBieSBjaGFuZ2luZzoNCj4gPiAiIEEgUklE IHN5c3RlbSBjYW4gY29udmVydCBiZXR3ZWVuIEEtbGFiZWxzIGFuZCBVLWxhYmVscyBieSAiDQo+ ID4gVE86ICIgQSBhbiBhcHBsaWNhdGlvbiBjb21tdW5pY2F0aW5nIHZpYSBSSUQgY2FuIGNvbnZl cnQgYmV0d2VlbiBBLWxhYmVscyBhbmQgVS1sYWJlbHMgYnkgIg0KPg0KPiBJIHRoaW5rIHRoYXQg bWlnaHQgYmUgYSBkaXN0aW5jdGlvbiB3aXRob3V0IGEgZGlmZmVyZW5jZS4NCj4NCj4gPiBUaGlz IHdvdWxkIHB1dCB0aGUgYnVyZGVuIHdpdGhpbiBhIGFwcGxpY2F0aW9uIGFzc29jaWF0ZWQgd2l0 aCB0aGUgQVBJIHRoYXQgaXMgSU9ERUYvUklEL1JJRA0KPiBUcmFuc3BvcnQuDQo+DQo+IEkgc2Vl IHRoYXQgYXMgYW4gaW50ZWdyYWwgcGFydCBvZiB0aGUgUklEIHN5c3RlbSwgYnV0IHBlcmhhcHMg SSdtDQo+IG1pc3Npbmcgc29tZXRoaW5nLg0KPg0KPiA+IFdoYXQgd2UgY2FyZSBhYm91dCBpcyBj b25zaXN0ZW50IHRyYW5zcG9ydCBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gc2hhcmUgZGF0YS4g IEFzIGxvbmcgYXMgdGhlIGRhdGENCj4gcmVjZWl2ZWQgaXMgdGhlIHNhbWUgZm9yIGV2ZXJ5IGlt cGxlbWVudGF0aW9uLCB3ZSBzaG91bGRuJ3QgY2FyZSBob3cgdGhleSB1c2UgdGhlIGRvbWFpbiBu YW1lcyBpbg0KPiB0aGVpciBhcHBsaWNhdGlvbiwgcmlnaHQ/DQo+DQo+IFVubGVzcyB0aGV5IGFy ZSBtYWtpbmcgYWNjZXNzIGRlY2lzaW9ucyAoYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24s DQo+IGV0Yy4pIGJhc2VkIG9uIHRob3NlIGRvbWFpbiBuYW1lcywgYmVjYXVzZSB0aGVuIHRoZXkg bmVlZCB0byBiZSBjb21wYXJlZA0KPiBjb3JyZWN0bHkuIEJ1dCBpZiBSSUQgc3lzdGVtcyBhcmUg bWFraW5nIHRob3NlIGRlY2lzaW9ucyBiYXNlZCBvbiBJUA0KPiBhZGRyZXNzIGFueXdheSwgdGhl biBJJ20gbXVjaCBsZXNzIGNvbmNlcm5lZCAtLSBwZXJoYXBzIGV2ZW4gbm90DQo+IGNvbmNlcm5l ZCBhdCBhbGwuDQo+DQo+ID4gX19fX19fX19fXw0KPiA+IEFuZCBpZiBvbmx5IFUtbGFiZWxzIGFy ZSBwZXJtaXR0ZWQsIHRoZW4gY29tcGFyaXNvbiBwcm9jZWVkcyB1c2luZyB0aGUNCj4gPiBVLWxh YmVscyBhcyBpbnB1dC4gSG93ZXZlciwgaWYgc28gd2UgbWlnaHQgbmVlZCB0byBzcGVjaWZ5IG1h cHBpbmdzIG9mDQo+ID4gdGhlIGtpbmQgZGlzY3Vzc2VkIGluIFJGQyA1ODk1IChlLmcuLCBtYXBw aW5nIHVwcGVyY2FzZSBhbmQgdGl0bGVjYXNlIHRvDQo+ID4gbG93ZXJjYXNlIHNvIHRoYXQgUFLD iUNJUy5leGFtcGxlLmNvbSBpcyB0cmVhdGVkICJ0aGUgc2FtZSIgYXMNCj4gPiBwcsOpY2lzLmV4 YW1wbGUuY29tKS4NCj4gPg0KPiA+IEJVVC4uLg0KPiA+DQo+ID4gV2lsbCBSSUQgc3lzdGVtcyBp biBmYWN0IGJlIGRvaW5nIHN1Y2ggY29tcGFyaXNvbnM/IFRoZSB0ZXh0IGZyb20gdGhlDQo+ID4g Zmlyc3QgcGFyYWdyYXBoIHF1b3RlZCBhYm92ZSBpbmRpY2F0ZXMgdGhhdCBSSUQgc3lzdGVtcyB3 aWxsIGJlIGNoZWNraW5nDQo+ID4gdGhlIGFzc29jaWF0aW9uIGJldHdlZW4gYSBETlMgZG9tYWlu IG5hbWUgYW5kIGFuIElQIGFkZHJlc3MsIG5vdA0KPiA+IGRpcmVjdGx5IGNvbXBhcmluZyBETlMg ZG9tYWluIG5hbWVzIChpbmNsdWRpbmcgSUROcykuIElmIHRoYXQgaXMgdHJ1ZSwNCj4gPiB0aGVu IHdlIHByb2JhYmx5ICpkb24ndCogbmVlZCB0byBjYXJlIG11Y2ggYWJvdXQgY29tcGFyaXNvbiBh bmQgYW55IHRhbGsNCj4gPiBvZiBtYXBwaW5ncyBpcyBtb290LiBDYW4geW91IHBsZWFzZSB2ZXJp ZnkgdGhhdCBSSUQgc3lzdGVtcyB3aWxsIGJlDQo+ID4gY2hlY2tpbmcgdGhlIGFzc29jaWF0aW9u IHdpdGggdGhlIElQIGFkZHJlc3MsIHJhdGhlciB0aGFuIGRpcmVjdGx5DQo+ID4gY29tcGFyaW5n IEROUyBkb21haW4gbmFtZXM/DQo+ID4gX19fX19fXw0KPiA+IEtNTTogSSBzZWUgeW91ciBwb2lu dCBoZXJlLiAgSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgdGV4dCB0byBtYWtlIGl0IGNsZWFyIHRo YXQgdGhlIElQIGFkZHJlc3MgaXMNCj4gcmVxdWlyZWQgYW5kIHRoZSBETlMgbmFtZSBpcyBkZXJp dmVkIGZyb20gdGhlIElQIGFkZHJlc3M6DQo+ID4NCj4gPiAgICAgICAgICAxLiAgUklEU3lzdGVt LiAgVGhlIElQIGFkZHJlc3Mgb2YgdGhlIG5leHQgdXBzdHJlYW0gc3lzdGVtIGFjY2VwdGluZyBS SUQgY29tbXVuaWNhdGlvbnMgaXMNCj4gUkVRVUlSRUQgYW5kIGlzIGxpc3RlZCBpbiB0aGUgTm9k ZSBlbGVtZW50IG9mIHRoZQ0KPiA+ICAgICAgICAgICAgICBSSURQb2xpY3kgY2xhc3MuICBJZiBO b2RlTmFtZSBlbGVtZW50IG9mIHRoZSBOb2RlDQo+ID4gICAgICAgICAgICAgIGNsYXNzIGlzIHVz ZWQsIGl0IGNvbnRhaW5zIGEgRE5TIGRvbWFpbiBuYW1lLiAgVGhlDQo+ID4gICAgICAgICAgICAg IG9yaWdpbmF0aW5nIFJJRCBzeXN0ZW0gaXMgcmVxdWlyZWQgdG8gY2hlY2sgdGhhdCB0aGlzDQo+ ID4gICAgICAgICAgICAgIGRvbWFpbiBuYW1lIHJlc29sdmVzIHRvIHRoZSBJUCBhZGRyZXNzIHRv IHdoaWNoIHRoZSBSSUQNCj4gPiAgICAgICAgICAgICAgbWVzc2FnZSBpcyBzZW50LiAgVGhpcyBj aGVjayBtYXkgYmUgcGVyZm9ybWVkIGluIGFkdmFuY2Ugb2YNCj4gPiAgICAgICAgICAgICAgc2Vu ZGluZyB0aGUgbWVzc2FnZSBhbmQgdGhlIHJlc3VsdCBzYXZlZCBmb3IgZnV0dXJlIHVzZQ0KPiA+ ICAgICAgICAgICAgICB3aXRoIGFkZGl0aW9uYWwgUklEIG1lc3NhZ2VzLg0KPiA+IF9fX19fXw0K Pg0KPiBTdXJlLCB0aGF0J3MgZmluZS4gVGhlbiBteSBxdWVzdGlvbiBiZWNvbWVzOiBob3cgZXhh Y3RseSBpcyB0aGUgTm9kZU5hbWUNCj4gYWN0dWFsbHkgdXNlZCBpbiBSSUQgc3lzdGVtcz8gSXQn cyB0aGUgdXNlIHRoYXQgZHJpdmVzIHRoZQ0KPiBpbnRlcm5hdGlvbmFsaXphdGlvbiBjb25zaWRl cmF0aW9ucy4gSWYgdGhlIE5vZGVOYW1lIGlzIG1lcmVseQ0KPiBlcGlwaGVub21lbmFsIGFuZCBp dCdzIHRoZSBJUCBhZGRyZXNzIHRoYXQgd2UgdXNlIHRvIGdldCB0aGluZ3MgZG9uZSwNCj4gdGhl biB3ZSBkb24ndCBwYXJ0aWN1bGFybHkgY2FyZSBhYm91dCB0aGUgTm9kZU5hbWUuDQo+DQo+ID4+ ICgyKSBSSURQb2xpY3kgY2xhc3MsIE1zZ0Rlc3RpbmF0aW9uPVNvdXJjZU9mSW5jaWRlbnQsIGFu ZCBhbHNvIHRoZSBJbmNpZGVudFNvdXJjZQ0KPiA+PiBjbGFzcy4NCj4gPj4NCj4gPj4gSW4gYm90 aCBvZiB0aGVzZSBjYXNlcyB0aGUgSVAgYWRkcmVzcyBpcyB0aGUgcHJpbWFyeSBpZGVudGlmaWVy IChJbmNpZGVudFNvdXJjZQ0KPiA+PiBuZWVkcyBhZGRpdGlvbmFsIHRleHQgdG8gc3RhdGUgdGhh dCB0aGUgSVAgYWRkcmVzcyBpcyByZXF1aXJlZCAtIHRoYXQgYXBwZWFycyB0bw0KPiA+PiBoYXZl IGJlZW4gb3Zlcmxvb2tlZCkuICBUaGVyZSBhcmUgYSBjb3VwbGUgb2Ygb3B0aW9ucyBoZXJlOg0K PiA+Pg0KPiA+PiBhKSBUaGUgc2ltcGxlc3QgaXMgdG8gcHJvaGliaXQgTm9kZU5hbWUgdXNhZ2Uu DQo+ID4+IGIpIE5vZGVOYW1lIGNvdWxkIGJlIHJlcXVpcmVkIHRvIGNvcnJlc3BvbmQgdG8gdGhl IElQIGFkZHJlc3MgdmlhIEROUyBsb29rdXAuDQo+ID4NCj4gPiBJbiAtMDkgdGhhdCBpczoNCj4g Pg0KPiA+ICAgICAgICAgIDIuICBTb3VyY2VPZkluY2lkZW50LiAgVGhlIEFkZHJlc3MgZWxlbWVu dCBvZiB0aGUgTm9kZSBlbGVtZW50DQo+ID4gICAgICAgICAgICAgIGNvbnRhaW5zIHRoZSBJUCBh ZGRyZXNzIG9mIHRoZSBpbmNpZGVudCBzb3VyY2UsIGFuZCB0aGUNCj4gPiAgICAgICAgICAgICAg Tm9kZU5hbWUgZWxlbWVudCBvZiB0aGUgTm9kZSBjbGFzcyBpcyBub3QgdXNlZC4gIFRoZSBJUA0K PiA+ICAgICAgICAgICAgICBhZGRyZXNzIGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBwYXRoIG9m IHN5c3RlbXMgYWNjZXB0aW5nDQo+ID4gICAgICAgICAgICAgIFJJRCBjb21tdW5pY2F0aW9ucyB0 aGF0IHdpbGwgYmUgdXNlZCB0byBmaW5kIHRoZSBjbG9zZXN0DQo+ID4gICAgICAgICAgICAgIFJJ RCBzeXN0ZW0gdG8gdGhlIHNvdXJjZSBvZiBhbiBhdHRhY2sgaW4gd2hpY2ggdGhlIElQDQo+ID4g ICAgICAgICAgICAgIGFkZHJlc3MgdXNlZCBieSB0aGUgc291cmNlIGlzIGJlbGlldmVkIHRvIGJl IHZhbGlkIGFuZCBhDQo+ID4gICAgICAgICAgICAgIFJlcXVlc3QgbWVzc2FnZSB3aXRoIE1zZ0Rz dCBzZXQgdG8gSW52ZXN0aWdhdGlvblJlcXVlc3QgaXMNCj4gPiAgICAgICAgICAgICAgdXNlZC4g IFRoaXMgaXMgbm90IHRvIGJlIGNvbmZ1c2VkIHdpdGggdGhlIEluY2lkZW50U291cmNlDQo+ID4g ICAgICAgICAgICAgIGNsYXNzLCBhcyB0aGUgZGVmaW5lZCB2YWx1ZSBoZXJlIGlzIGZyb20gYW4g aW5pdGlhbCB0cmFjZQ0KPiA+ICAgICAgICAgICAgICBvciBpbnZlc3RpZ2F0aW9uIFJlcXVlc3Qs IG5vdCB0aGUgc291cmNlIHVzZWQgaW4gYSBSZXN1bHQNCj4gPiAgICAgICAgICAgICAgbWVzc2Fn ZS4NCj4gPg0KPiA+IEkgdGhpbmsgaXQncyBmaW5lIHRvIHVzZSBJUCBhZGRyZXNzIGhlcmUuDQo+ ID4NCj4gPiBOT1RFOiB5b3Ugc2FpZCB0aGF0IEluY2lkZW50U291cmNlIG5lZWRzIGFkZGl0aW9u YWwgdGV4dCB0byBzdGF0ZSB0aGF0DQo+ID4gdGhlIElQIGFkZHJlc3MgcmVxdWlyZWQsIGJ1dCBJ IGRvIG5vdCBzZWUgdGhhdCBoZXJlOg0KPiA+IF9fX19fDQo+ID4gS01NOiBUaGFua3MsIGlmIHdl IGFyZSBmaXhpbmcgdGV4dCwgbGV0J3MganVzdCBhZGQgdGhhdCBub3cuICBUaGlzIG9uZSBzaG91 bGQgYmUgZWFzeS4NCj4gPg0KPiA+IFByb3Bvc2VkOg0KPiA+ICAgICAgICAgIDIuICBTb3VyY2VP ZkluY2lkZW50LiAgVGhlIEFkZHJlc3MgZWxlbWVudCBvZiB0aGUgTm9kZSBlbGVtZW50DQo+ID4g ICAgICAgICAgICAgIGNvbnRhaW5zIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBpbmNpZGVudCBzb3Vy Y2UsIGFuZCB0aGUNCj4gPiAgICAgICAgICAgICAgTm9kZU5hbWUgZWxlbWVudCBvZiB0aGUgTm9k ZSBjbGFzcyBpcyBub3QgdXNlZC4gIFRoZSBJUA0KPiA+ICAgICAgICAgICAgICBhZGRyZXNzIGlz IFJFUVVJUkVEIHdoZW4gdGhpcyBvcHRpb24gaXMgc2VsZWN0ZWQuICBUaGUgSVAgYWRkcmVzcyBp cyB1c2VkIHRvIGRldGVybWluZQ0KPiB0aGUgcGF0aCBvZiBzeXN0ZW1zIGFjY2VwdGluZw0KPiA+ ICAgICAgICAgICAgICBSSUQgY29tbXVuaWNhdGlvbnMgdGhhdCB3aWxsIGJlIHVzZWQgdG8gZmlu ZCB0aGUgY2xvc2VzdA0KPiA+ICAgICAgICAgICAgICBSSUQgc3lzdGVtIHRvIHRoZSBzb3VyY2Ug b2YgYW4gYXR0YWNrIGluIHdoaWNoIHRoZSBJUA0KPiA+ICAgICAgICAgICAgICBhZGRyZXNzIHVz ZWQgYnkgdGhlIHNvdXJjZSBpcyBiZWxpZXZlZCB0byBiZSB2YWxpZCBhbmQgYQ0KPiA+ICAgICAg ICAgICAgICBSZXF1ZXN0IG1lc3NhZ2Ugd2l0aCBNc2dEc3Qgc2V0IHRvIEludmVzdGlnYXRpb25S ZXF1ZXN0IGlzDQo+ID4gICAgICAgICAgICAgIHVzZWQuICBUaGlzIGlzIG5vdCB0byBiZSBjb25m dXNlZCB3aXRoIHRoZSBJbmNpZGVudFNvdXJjZQ0KPiA+ICAgICAgICAgICAgICBjbGFzcywgYXMg dGhlIGRlZmluZWQgdmFsdWUgaGVyZSBpcyBmcm9tIGFuIGluaXRpYWwgdHJhY2UNCj4gPiAgICAg ICAgICAgICAgb3IgaW52ZXN0aWdhdGlvbiBSZXF1ZXN0LCBub3QgdGhlIHNvdXJjZSB1c2VkIGlu IGEgUmVzdWx0DQo+ID4gICAgICAgICAgICAgIG1lc3NhZ2UuDQo+ID4gX19fX18NCj4NCj4gTG9v a3MgZ29vZC4NCj4NCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0 LWlldGYtbWlsZS1yZmM2MDQ1LWJpcy0wOCZkaWZmdHlwZT0tLQ0KPiBodG1sJnN1Ym1pdD1HbyEm dXJsMj1kcmFmdC1pZXRmLW1pbGUtcmZjNjA0NS1iaXMtMDkNCj4gPg0KPiA+IEhvd2V2ZXIsIEkg dGhpbmsgdGhhdCBjYW4gYmUgYWRkZWQgYmVmb3JlIHNlbmRpbmcgdGhpcyBkb2N1bWVudCB0byB0 aGUNCj4gPiBSRkMgRWRpdG9yLCBvciBkdXJpbmcgQVVUSDQ4Lg0KPiA+DQo+ID4+ICgzKSBSSURQ b2xpY3kgY2xhc3MsIE1zZ0Rlc3RpbmF0aW9uPWV4dC12YWx1ZS4gIFRoaXMgaXMgYW4gZXNjYXBl IHRoYXQgYWxsb3dzDQo+ID4+IGV4dGVuc2lvbnMgdG8gTXNnRGVzdGluYXRpb24uICBUaGUgZGVz Y3JpcHRpb24gb2YgdGhpcyBzaG91bGQgaW5jbHVkZSBhICJ0aGVyZQ0KPiA+PiBiZSBkcmFnb25z IiB3YXJuaW5nIGFib3V0IElETnMgaW4gTm9kZU5hbWUuDQo+ID4NCj4gPiBJbiAtMDkgdGhhdCBp czoNCj4gPg0KPiA+ICAgICAgICAgIDMuICBleHQtdmFsdWUuICBBbiBlc2NhcGUgdmFsdWUgdXNl ZCB0byBleHRlbmQgdGhpcyBhdHRyaWJ1dGUuDQo+ID4gICAgICAgICAgICAgIEFsbCBleHRlbnNp b25zIHNoYWxsIHNwZWNpZnkgdGhlIGNvbnRlbnRzIGFuZCBtZWFuaW5nIG9mDQo+ID4gICAgICAg ICAgICAgIHRoZSBOb2RlIGVsZW1lbnQgb2YgUklEUG9saWN5LiAgSWYgdGhlIE5vZGVOYW1lIGVs ZW1lbnQgb2YNCj4gPiAgICAgICAgICAgICAgTm9kZSBpcyB1c2VkIGJ5IGFuIGV4dGVuc2lvbiwg Tm9kZU5hbWUgbWF5IGNvbnRhaW4gYW4NCj4gPiAgICAgICAgICAgICAgSW50ZXJuYXRpb25hbGl6 ZWQgRG9tYWluIE5hbWUgKElETikgYW5kIHRoYXQgSUROIGlzDQo+ID4gICAgICAgICAgICAgIHJl cXVpcmVkIHRvIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cyBpbiBbUkZDNTg5MF0uICBJdCBpcw0K PiA+ICAgICAgICAgICAgICBzdHJvbmdseSByZWNvbW1lbmRlZCB0aGF0IFJJRCBTeXN0ZW1zIHNh dGlzZnkgdGhvc2UgSURODQo+ID4gICAgICAgICAgICAgIHJlcXVpcmVtZW50cyB2aWEgYXBwcm9w cmlhdGUgdXNlIG9mIHRoZSBETlMgYXMgb3Bwb3NlZCB0bw0KPiA+ICAgICAgICAgICAgICBpbXBs ZW1lbnRpbmcgdGhlaXIgb3duIGNoZWNrcyBmb3IgdGhlc2UgcmVxdWlyZW1lbnRzLiAgRm9yDQo+ ID4gICAgICAgICAgICAgIGV4YW1wbGUsIGFuIGV4dGVuc2lvbiBjb3VsZCB1c2UgYm90aCBhIE5v ZGVOYW1lIGFuZCBhbiBJUA0KPiA+ICAgICAgICAgICAgICBhZGRyZXNzIHRvIHdoaWNoIHRoZSBO b2RlTmFtZSByZXNvbHZlcy4gIFNlZSBJT0RFRg0KPiA+ICAgICAgICAgICAgICBbUkZDNTA3MF0s IFNlY3Rpb24gNS4xIG9uIGV4dGVuc2liaWxpdHkuDQo+ID4NCj4gPiBUaGF0IHNlZW1zIHNsaWdo dGx5IHVuZGVyc3BlY2lmaWVkOiB3aGF0IGlzIG1lYW50IGJ5ICJ0byBzYXRpc2Z5IHRoZQ0KPiA+ IHJlcXVpcmVtZW50cyBpbiBbUkZDNTg5MF0iIGFuZCAiYXBwcm9wcmlhdGUgdXNlIG9mIHRoZSBE TlMiPyBEb2VzIHRoYXQNCj4gPiBtZWFuICJlbnN1cmluZyB0aGF0IHRoZSBJRE4gcmV0cmlldmVk IGZyb20gdGhlIEROUyBjb25zaXN0cyBvbmx5IG9mDQo+ID4gVS1sYWJlbHMgYW5kIE5SLUxESCBs YWJlbHMiPyBJZiBzbywgaXMgdGhhdCBkb25lIGJ5IGFza2luZyB0aGUgRE5TDQo+ID4gcmVzb2x2 ZXIgZm9yIFUtbGFiZWxzLCBvciBpcyBpdCBkb25lIGJ5IGFjdGl2ZWx5IHBlcmZvcm1pbmcgYSBj aGVjayBpbg0KPiA+IHRoZSBSSUQgc3lzdGVtIGl0c2VsZiAoc2VlIGFib3ZlIGFib3V0ICJNVVNU IE5PVCBiZSBBLWxhYmVscyIpPw0KPiA+DQo+ID4gSXMgdGhpcyBzb21ldGhpbmcgdGhhdCBpcyBs ZWZ0IGZvciBlYWNoIGV4dGVuc2lvbiB0byBkZWZpbmU/IElmIHNvLCB3ZQ0KPiA+IHNob3VsZCBj b21lIG91dCBhbmQgc2F5IHByZWNpc2VseSB0aGF0Lg0KPiA+IF9fX19fX18NCj4gPiBLTU06IFRo ZSBpbXBvcnRhbnQgcGFydCBmb3IgUklEIGlzIHRoYXQgd2UgY29tbXVuaWNhdGUgYW5kIGV4Y2hh bmdlIG1lc3NhZ2VzIGluIGEgd2F5IHRoYXQgZXZlcnlvbmUNCj4gY2FuIGFjY2VwdCBhbmQgcHJv Y2Vzcy4gIEFwcGxpY2F0aW9uIGhhbmRsaW5nIGZvciB0aGlzIHRyYW5zbGF0aW9uLCB3aGV0aGVy IGl0IGJlIGJ5IEROUyBvciBzb21lIG90aGVyDQo+IG1lY2hhbmlzbSwgcmVhbGx5IHNob3VsZG4n dCBtYXR0ZXIuICBBcyBsb25nIGFzIHRoZSBpbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBoYW5kbGVk IGluIGEgd2F5IHRoYXQgbGV0cw0KPiB1cyBjb25zaXN0ZW50bHkgZXhjaGFuZ2UgaW5mb3JtYXRp b24sIEkgdGhpbmsgdGhlIHJlYWwgaXNzdWVzIGFyZSBzb2x2ZWQsIG5vPw0KPiA+IElmIEkgYWRk ICJTZWUgU2VjdGlvbiAxMSBvZiB0aGlzIGRvY3VtZW50IGZvcg0KPiA+ICAgICAgIEludGVybmF0 aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zLiIgIERvZXMgdGhhdCByZXNvbHZlIHRoZSBpc3N1 ZSBzaW5jZSBpdCBwcm92aWRlcw0KPiBjb25zaXN0ZW50IGd1aWRhbmNlIHRoYXQgZW5hYmxlcyB0 aGUgZXhjaGFuZ2Ugb2YgaW5mb3JtYXRpb24/DQo+ID4gX19fX19fXw0KPg0KPiBZZXMsIHdlIHdh bnQgdG8gbWFrZSBzdXJlIHRoYXQgYXBwbGlhdGlvbnMgaGFuZGxlIHRoZXNlIG1hdHRlcnMNCj4g Y29uc2lzdGVudGx5LiBQb2ludGluZyB0byBTZWN0aW9uIDExIHdvdWxkIHNvbHZlIHRoYXQgaXNz dWUsIGFzIGxvbmcgYXMNCj4gd2UgY2FuIGFncmVlIG9uIHdoYXQgZ29lcyBpbiBTZWN0aW9uIDEx LiA6KQ0KPg0KPiA+PiBTbywgdGhlIGFuc3dlciB0byB0aGUgc29tZXdoYXQgcmhldG9yaWNhbCBx dWVzdGlvbjoNCj4gPj4NCj4gPj4+IERvIElPREVGL1JJRCBpbXBsZW1lbnRhdGlvbnMgd2FudCB0 byBzaWduIHVwIGZvciBhbGwgdGhhdD8NCj4gPj4NCj4gPj4gSXMgYXBwcm94aW1hdGVseSAiWWVz LCBieSByZWx5aW5nIG9uIHRoZSBETlMgaW1wbGVtZW50YXRpb24sIiB3aXRoIHRoZSBhZGRpdGlv bg0KPiA+PiBvZiBhICJ0aGVyZSBiZSBkcmFnb25zIiB3YXJuaW5nIHRvIHRoZSBNc2dEZXN0aW5h dGlvbiBleHQtdmFsdWUgZXh0ZW5zaW9uIHRleHQNCj4gPj4gdG8gY29tbXVuaWNhdGUgdGhhdCB0 byBkZXNpZ25lcnMgb2YgZXh0ZW5zaW9ucywgYW5kIGEgcG9zc2libGUgcHJvaGliaXRpb24gb2YN Cj4gPj4gdXNlIG9mIE5vZGVOYW1lIHdoZW4gdGhlIElQIGFkZHJlc3MgaXMgdGhlIHByaW1hcnkg aWRlbnRpZmllci4NCj4gPg0KPiA+IEkgdGhpbmsgd2UncmUgZ2V0dGluZyBjbG9zZSB0byByZWZs ZWN0aW5nIHRoYXQgaW4gdGV4dCwgYnV0IGEgZmV3DQo+ID4gY2xhcmlmaWNhdGlvbnMgd291bGQg aGVscCwgYXMgd291bGQgdmFsaWRhdGlvbiBmcm9tIHRoZSBXRyB0aGF0IHRoaXMNCj4gPiBkaXJl Y3Rpb24gaXMgYWdyZWVhYmxlLg0KPiA+DQo+ID4gSSByZWFsaXplIHRoYXQgdGhlc2UgYXJlIHRo b3JueSBpc3N1ZXMgYW5kIHRoYXQgZm9sa3MgcHJvYmFibHkganVzdCB3YW50DQo+ID4gc29tZW9u ZSB0byBjb21lIGZyb20gb24gaGlnaCBhbmQgc2F5ICJ5ZWEgdmVyaWx5LCBoZXJlIGlzIHRoZSBv bmUgdHJ1ZQ0KPiA+IHBhdGggdG8gaW50ZXJuYXRpb25hbGl6YXRpb24gbmlydmFuYSIuIFVuZm9y dHVuYXRlbHksIHRoZXJlIGlzIG5vIHN1Y2gNCj4gPiBwYXRoLCBzbyB0aGUgV0cgbmVlZHMgdG8g d2VpZ2ggdGhlIGNvc3RzIGFuZCBiZW5lZml0cywgY2xlYXJseQ0KPiA+IHVuZGVyc3RhbmQgd2hh dCBpdCdzIGRvaW5nLCBhbmQgdGhlbiBtYWtlIGEgZGVjaXNpb24gb25lIHdheSBvciB0aGUNCj4g PiBvdGhlci4gV2UndmUgaGFkIHRvbyBtYW55IFdHcyAoc29tZSBvZiB3aGljaCBJJ3ZlIGJlZW4g aW52b2x2ZWQgd2l0aCkNCj4gPiBqdXN0IHRha2Ugc29tZSBpMThuIGFkdmljZSB3aXRob3V0IGtu b3dsZWRnZSwgYW5kIHRoZSByZXN1bHRzIGhhdmUgYmVlbg0KPiA+IGxlc3MgdGhlbiBwb3NpdGl2 ZS4NCj4gPg0KPiA+IFRoYW5rcyBmb3IgeW91ciBwYXRpZW5jZSENCj4gPg0KPiA+IFBldGVyDQo+ ID4gX19fX19fX19fDQo+ID4gVGhhbmsgeW91IGZvciB5b3VyIGRldGFpbGVkIHJldmlld3MhDQo+ DQo+IEknbSBoZXJlIGZvciB5b3UhIDstKQ0KPg0KPiBQZXRlcg0KPg0KPiAtLQ0KPiBQZXRlciBT YWludC1BbmRyZQ0KPiBodHRwczovL3N0cGV0ZXIuaW0vDQo+DQo+DQoNCg== From stpeter@stpeter.im Thu Jan 26 16:00: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 92F1021F8607 for ; Thu, 26 Jan 2012 16:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 82TmkVQ2vvFY for ; Thu, 26 Jan 2012 16:00:54 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F413721F8603 for ; Thu, 26 Jan 2012 16:00:53 -0800 (PST) Received: from squire.local (unknown [216.17.251.49]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D1FA440058; Thu, 26 Jan 2012 17:10:42 -0700 (MST) Message-ID: <4F21DE17.10706@stpeter.im> Date: Thu, 26 Jan 2012 16:13:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: david.black@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mile@ietf.org, alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 27 Jan 2012 00:00:54 -0000 On 1/26/12 1:51 PM, david.black@emc.com wrote: >>>> If you are not concerned about one RID member masquerading as another, >>>> it might be sufficient for your protocol to allow client certificates to >>>> come from a known CA (or a set of CAs), or be whitelisted. So basically >>>> you will use more relaxed verification rules from RFC 5280. > >>> Well, I think you'd probably still want to do the domain check, no? > >> How would you derive a domain name for the connecting entry (what I >> called "client")? The server only has an IP address and port. So other >> than doing reverse DNS mapping or similar, I don't think anything will >> result in a domain. > > The HTTP/TLS client can check the server's certificate against the domain > in the URL, and I read RFC 6125 as requiring this check. The HTTP/TLS > server needs to do something else. Right, the identities need to be checked in both directions. That's why I likened it to the server-to-server case in SMTP or XMPP. > The current -09 version of 6046-bis requires that sufficient domain name > information be kept based on consortium setup so that both the HTTP/TLS > client and server can both perform a domain name reference identifier > check against the TLS certificate presented by the other party: > > The use of stable DNS names to address RID systems is RECOMMENDED; in > addition to facilitating connection to RID systems within a > consortium, these are to be used as reference identifiers for a RID > system's peers. [... unrelated sentence snipped ...] > The protocol provides no in-band method for handling a > change of address of a RID system. > > ... > > All RID systems MUST be identified by a certificate containing a > DNS-ID identifier [RFC5280] as in section 6.4 of [RFC6125]; RID > systems MUST verify the reference identifiers of their peers against > those stored in the certificates presented. Looks good to me. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jan 26 16:08: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 DBD1421F856C for ; Thu, 26 Jan 2012 16:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 w0t5K1oqsP-O for ; Thu, 26 Jan 2012 16:08:19 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E612821F856A for ; Thu, 26 Jan 2012 16:08:18 -0800 (PST) Received: from squire.local (unknown [216.17.251.49]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA28540058; Thu, 26 Jan 2012 17:10:46 -0700 (MST) Message-ID: <4F21DFF5.3070905@stpeter.im> Date: Thu, 26 Jan 2012 16:21:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: david.black@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mile@ietf.org, presnick@qualcomm.com Subject: Re: [mile] FW: IDN issue 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, 27 Jan 2012 00:08:20 -0000 [ Pete, question for you inline ] On 1/26/12 3:30 PM, david.black@emc.com wrote: > Hi Peter, > >>>>> In short, there be dragons. >>>> >>>> Indeed (as I'm entirely too well-aware of from the précis WG), however, the goal >>>> here is to find a suitable cave in which to confine the dragons :-). >>> >>> Nice way to put it. And yes, the PRECIS WG is a fun place to hang out. >>> Speaking of which, how's that iSCSI profile of the precis framework >>> coming along? ;-) > > I'm working on getting a set of four iSCSI-related drafts out of the storm WG first. > So far, it's three down, one to go, see http://datatracker.ietf.org/wg/storm/ . Be > careful what you wish for as an AD :-). > >>>> (1) RIDPolicy class, MsgDestination=RIDSystem. > > Section 11 text: > >>> The Node class identifies a host or network device. This document >>> re-uses the definition of Node from the IODEF specification >>> [RFC5070], Section 3.16. However, that document did not clearly >>> specify whether a NodeName could be an Internationalized Domain Name >>> (IDN). RID systems MUST treat the NodeName class as a domain name >>> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >>> class; if they do so, the UTF-8 representation of the domain name >>> MUST be used, i.e., all of the domain name's labels MUST be U-labels >>> expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be >>> used. A RID system can convert between A-labels and U-labels by >>> using the Punycode encoding [RFC3492] for A-labels as described in >>> the protocol specification for Internationalized Domain Names in >>> Applications [RFC5891]. >>> >>> If the application is not checking this, how will it know whether any >>> A-labels have snuck in? Will it depend on its DNS resolver to return the >>> IDN in the appropriate format? The foregoing text implies that the RID >>> system will do the conversion, so it's not clear to me where the >>> responsibility lies (and if it's not clear to me, it might be clear to >>> an implementer). > > At the end of the day the better answer (IMHO) is "depend on its DNS resolver". > If we can expect the DNS resolver to handle converting A-labels to U-labels in > an IDN and returning the result, the last sentence in Section 11 of the draft > can be replaced by: > > RID systems are expected to obtain an IDN meeting these requirements > by asking a DNS resolver to return an IDN that does not contain > A-labels (even if the input IDN contains A-labels). > > ** Will that work? I *think* so but I am going to complete a final sanity-check with my co-AD to be sure. Pete: does that work for you? >>> What we care about is consistent transport so that applications can >>> share data. As long as the data received is the same for every >>> implementation, we shouldn't care how they use the domain names in >>> their application, right? >> >> Unless they are making access decisions (authentication, authorization, >> etc.) based on those domain names, because then they need to be compared >> correctly. But if RID systems are making those decisions based on IP >> address anyway, then I'm much less concerned -- perhaps even not >> concerned at all. > > The NodeName in 6045-bis is not used for access decisions. Access decisions > are specified in 6046-bis - see the other thread discussing certificates, > DNS-IDs and reference identifiers. Right. Thus I am much less concerned about NodeNames here. >>> KMM: I see your point here. How about the following text to make it clear >>> that the IP address is required and the DNS name is derived from the IP address: > > [... text modification snipped ...] > >> Sure, that's fine. Then my question becomes: how exactly is the NodeName >> actually used in RID systems? It's the use that drives the >> internationalization considerations. If the NodeName is merely >> epiphenomenal and it's the IP address that we use to get things done, >> then we don't particularly care about the NodeName. > > I'll have to leave that one to Kathleen (draft author); this concern also applies > to IncidentSource (below). Based on Kathleen's answer, it's all about the certificate. So onward and upward. >>>> (2) RIDPolicy class, MsgDestination=SourceOfIncident, and also the IncidentSource >>>> class. > >>> I think it's fine to use IP address here. > > That's good. > >>> NOTE: you said that IncidentSource needs additional text to state that >>> the IP address required, but I do not see that here: > > That text was added, but the diff doesn’t show enough context to indicate that the > text is in IncidentSource. In any case, Kathleen's suggested addition of text to > say that the IP address is REQUIRED in all of the cases should make this crystal clear. Agreed. > The Node in IncidentSource may contain both a domain name and an IP address. Yes. >>>> (3) RIDPolicy class, MsgDestination=ext-value. This is an escape that allows >>>> extensions to MsgDestination. The description of this should include a "there >>>> be dragons" warning about IDNs in NodeName. >>> >>> In -09 that is: >>> >>> 3. ext-value. An escape value used to extend this attribute. >>> All extensions shall specify the contents and meaning of >>> the Node element of RIDPolicy. If the NodeName element of >>> Node is used by an extension, NodeName may contain an >>> Internationalized Domain Name (IDN) and that IDN is >>> required to satisfy the requirements in [RFC5890]. It is >>> strongly recommended that RID Systems satisfy those IDN >>> requirements via appropriate use of the DNS as opposed to >>> implementing their own checks for these requirements. For >>> example, an extension could use both a NodeName and an IP >>> address to which the NodeName resolves. See IODEF >>> [RFC5070], Section 5.1 on extensibility. >>> >>> That seems slightly underspecified: what is meant by "to satisfy the >>> requirements in [RFC5890]" and "appropriate use of the DNS"? Does that >>> mean "ensuring that the IDN retrieved from the DNS consists only of >>> U-labels and NR-LDH labels"? If so, is that done by asking the DNS >>> resolver for U-labels, or is it done by actively performing a check in >>> the RID system itself (see above about "MUST NOT be A-labels")? >>> >>> Is this something that is left for each extension to define? If so, we >>> should come out and say precisely that. >>> _______ >>> KMM: The important part for RID is that we communicate and exchange messages in a way that everyone >> can accept and process. Application handling for this translation, whether it be by DNS or some other >> mechanism, really shouldn't matter. As long as the internationalization is handled in a way that lets >> us consistently exchange information, I think the real issues are solved, no? >>> If I add "See Section 11 of this document for >>> Internationalization considerations." Does that resolve the issue since it provides >> consistent guidance that enables the exchange of information? >>> _______ >> >> Yes, we want to make sure that applications handle these matters >> consistently. Pointing to Section 11 would solve that issue, as long as >> we can agree on what goes in Section 11. :) > > Assuming that the new DNS resolver text for section 11 is ok, here's a suggested > (shorter) rewrite: > > 3. ext-value. An escape value used to extend this attribute. > All extensions shall specify the contents and meaning of > the Node element of RIDPolicy. See IODEF [RFC5070], > Section 5.1 on extensibility. If the NodeName element of > Node is used by an extension, NodeName may contain an > Internationalized Domain Name (IDN); see Section 11 for > applicable requirements. All extensions SHOULD use an IP Address > in the Address element of the Node class as the primary means > of Node identification. > > ** Does that look ok? Indeed it does. Peter -- Peter Saint-Andre https://stpeter.im/ From kathleen.moriarty@emc.com Fri Jan 27 06:50: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 0BC8621F85C3 for ; Fri, 27 Jan 2012 06:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.698 X-Spam-Level: X-Spam-Status: No, score=-9.698 tagged_above=-999 required=5 tests=[AWL=0.901, 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 kTrZjs+7ILmM for ; Fri, 27 Jan 2012 06:50:56 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0C121F85BD for ; Fri, 27 Jan 2012 06:50:55 -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 q0REorGl003271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 09:50:54 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 27 Jan 2012 09:50:27 -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 q0REoGXY020623; Fri, 27 Jan 2012 09:50:16 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Fri, 27 Jan 2012 09:50:25 -0500 From: To: , Date: Fri, 27 Jan 2012 09:50:25 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: Aczchs7eXF28mKNqQyO2yRMy7Az2DAAe/2HQ Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> In-Reply-To: <4F21DE17.10706@stpeter.im> 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] 6046-bis - Client certificate identity check 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, 27 Jan 2012 14:50:57 -0000 Alexey, It appears your questions for RFC6046-bis have been addressed, can you conf= irm? Thank you, Kathleen (as Chair) -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Pet= er Saint-Andre Sent: Thursday, January 26, 2012 6:13 PM To: Black, David Cc: mile@ietf.org; alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check On 1/26/12 1:51 PM, david.black@emc.com wrote: >>>> If you are not concerned about one RID member masquerading as another, >>>> it might be sufficient for your protocol to allow client certificates = to >>>> come from a known CA (or a set of CAs), or be whitelisted. So basical= ly >>>> you will use more relaxed verification rules from RFC 5280. >=20 >>> Well, I think you'd probably still want to do the domain check, no? >=20 >> How would you derive a domain name for the connecting entry (what I >> called "client")? The server only has an IP address and port. So other >> than doing reverse DNS mapping or similar, I don't think anything will >> result in a domain. >=20 > The HTTP/TLS client can check the server's certificate against the domain > in the URL, and I read RFC 6125 as requiring this check. The HTTP/TLS > server needs to do something else. Right, the identities need to be checked in both directions. That's why I likened it to the server-to-server case in SMTP or XMPP. > The current -09 version of 6046-bis requires that sufficient domain name > information be kept based on consortium setup so that both the HTTP/TLS > client and server can both perform a domain name reference identifier > check against the TLS certificate presented by the other party: >=20 > The use of stable DNS names to address RID systems is RECOMMENDED; in > addition to facilitating connection to RID systems within a > consortium, these are to be used as reference identifiers for a RID > system's peers. [... unrelated sentence snipped ...] > The protocol provides no in-band method for handling a > change of address of a RID system. >=20 > ... >=20 > All RID systems MUST be identified by a certificate containing a > DNS-ID identifier [RFC5280] as in section 6.4 of [RFC6125]; RID > systems MUST verify the reference identifiers of their peers against > those stored in the certificates presented. Looks good to me. Peter --=20 Peter Saint-Andre https://stpeter.im/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Jan 27 07:37:17 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 C8C5621F84CD for ; Fri, 27 Jan 2012 07:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.712 X-Spam-Level: X-Spam-Status: No, score=-9.712 tagged_above=-999 required=5 tests=[AWL=0.887, 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 y2mwS2+7wQRo for ; Fri, 27 Jan 2012 07:37:17 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 214CA21F8495 for ; Fri, 27 Jan 2012 07:37:16 -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 q0RFbF4C028122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2012 10:37:16 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Fri, 27 Jan 2012 10:37:00 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0RFUY56009902 for ; Fri, 27 Jan 2012 10:36:59 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Fri, 27 Jan 2012 10:35:25 -0500 From: To: Date: Fri, 27 Jan 2012 10:35:22 -0500 Thread-Topic: IDNs Thread-Index: AczdCUiLwkbW8HK9RVijgSaWA/7ctA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: e2c= A/SP CenK CkKW EMru EOCq Eap8 EeXB EjfA FWIZ GSAm IYtu J+WG KZpx K+Tx LBLt; 1; bQBpAGwAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {50E70699-D2C1-472F-B296-55D5677A2EEA}; awBhAHQAaABsAGUAZQBuAC4AbQBvAHIAaQBhAHIAdAB5AEAAZQBtAGMALgBjAG8AbQA=; Fri, 27 Jan 2012 15:35:22 GMT;SQBEAE4AcwA= x-cr-puzzleid: {50E70699-D2C1-472F-B296-55D5677A2EEA} 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] IDNs 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, 27 Jan 2012 15:37:17 -0000 Hi, This is a final check to make sure people are OK with the proposed approach= for IDNs in RID: Addresses in the Node element rely on IP addresses (they are required in ea= ch instance). A DNS name can be contained in the NodeName element of Node,= but is derived from the IP address. Authentication does not and never did= rely on DNS names as we use certificates at the RID layer for digital sign= atures and encryption, and certificates at the TLS layer. With this in min= d, the international considerations, as currently proposed is as follows: 11. Internationalization Issues The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. An application communicating via RID can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. RID systems are expected to obtain an IDN meeting these requirements by asking a DNS resolver to return an IDN that does not contain A-labels (even if the input contains A-labels). I am just waiting to hear from one of the ADs and will post the draft once = I get an OK from Pete. Thank you, Kathleen Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-58= 07 | Kathleen.Moriarty@emc.com | EMC Corporation From david.waltermire@nist.gov Fri Jan 27 07:59:01 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 34D3421F84F8 for ; Fri, 27 Jan 2012 07:59:01 -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 cxY8vYpIyeLO for ; Fri, 27 Jan 2012 07:59:00 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7890221F84F7 for ; Fri, 27 Jan 2012 07:58:59 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 10:58:50 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 27 Jan 2012 10:58:58 -0500 From: "Waltermire, David A." To: "kathleen.moriarty@emc.com" , "mile@ietf.org" Date: Fri, 27 Jan 2012 10:59:03 -0500 Thread-Topic: IDNs Thread-Index: AczdCUiLwkbW8HK9RVijgSaWA/7ctAAAYV5g 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: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [mile] IDNs 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, 27 Jan 2012 15:59:01 -0000 >From my perspective, internationalization concepts are important to support. I don't really have a dog in this fight as I am not a developer in this area. This being said, the wording below looks like a reasonable approach. Regards, Dave Waltermire -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Friday, January 27, 2012 10:35 AM To: mile@ietf.org Subject: [mile] IDNs Hi, This is a final check to make sure people are OK with the proposed approach for IDNs in RID: Addresses in the Node element rely on IP addresses (they are required in each instance). A DNS name can be contained in the NodeName element of Node, but is derived from the IP address. Authentication does not and never did rely on DNS names as we use certificates at the RID layer for digital signatures and encryption, and certificates at the TLS layer. With this in mind, the international considerations, as currently proposed is as follows: 11. Internationalization Issues The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. An application communicating via RID can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. RID systems are expected to obtain an IDN meeting these requirements by asking a DNS resolver to return an IDN that does not contain A-labels (even if the input contains A-labels). I am just waiting to hear from one of the ADs and will post the draft once I get an OK from Pete. Thank you, Kathleen Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-5807 | Kathleen.Moriarty@emc.com | EMC Corporation _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Fri Jan 27 09:30: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 0B66521F850C for ; Fri, 27 Jan 2012 09:30:05 -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 8rEkA-UItWZz for ; Fri, 27 Jan 2012 09:30:03 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 800F621F85CE for ; Fri, 27 Jan 2012 09:30:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 01F4ED930B; Fri, 27 Jan 2012 18:30:02 +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 LGdLg1iiY+AO; Fri, 27 Jan 2012 18:30:01 +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 5353DD9303; Fri, 27 Jan 2012 18:30:01 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Fri, 27 Jan 2012 18:30:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C02BE67-EF93-4B0D-92F4-EBA5895A4606@tik.ee.ethz.ch> References: To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] IDNs 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, 27 Jan 2012 17:30:05 -0000 Hi, Kathleen, Given the requirements, UTF8, free convertibility among the label forms, = and implementation support for this convertibility, this seems like a = good way to go. Best regards, Brian (as a random guy off the street) On Jan 27, 2012, at 4:35 PM, = wrote: > Hi, >=20 > This is a final check to make sure people are OK with the proposed = approach for IDNs in RID: >=20 > Addresses in the Node element rely on IP addresses (they are required = in each instance). A DNS name can be contained in the NodeName element = of Node, but is derived from the IP address. Authentication does not = and never did rely on DNS names as we use certificates at the RID layer = for digital signatures and encryption, and certificates at the TLS = layer. With this in mind, the international considerations, as = currently proposed is as follows: >=20 > 11. Internationalization Issues >=20 > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name > MUST be used, i.e., all of the domain name's labels MUST be U-labels > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > used. An application communicating via RID can convert between > A-labels and U-labels by using the Punycode encoding [RFC3492] for > A-labels as described in the protocol specification for > Internationalized Domain Names in Applications [RFC5891]. RID > systems are expected to obtain an IDN meeting these requirements by > asking a DNS resolver to return an IDN that does not contain = A-labels > (even if the input contains A-labels). >=20 > I am just waiting to hear from one of the ADs and will post the draft = once I get an OK from Pete. >=20 > Thank you, > Kathleen >=20 >=20 > Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | = 617-851-5807 | Kathleen.Moriarty@emc.com | EMC Corporation >=20 >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Thomas.Millar@us-cert.gov Fri Jan 27 09:49: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 F0BD821F8617 for ; Fri, 27 Jan 2012 09:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 cmlzGldyskdZ for ; Fri, 27 Jan 2012 09:49:35 -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 69F7721F860F for ; Fri, 27 Jan 2012 09:49:35 -0800 (PST) Received: from shaggy.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B8F84502CA for ; Fri, 27 Jan 2012 17:49:33 +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 A1CDF502C7 for ; Fri, 27 Jan 2012 17:49:33 +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 7543B6E45C for ; Fri, 27 Jan 2012 17:49:33 +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); Fri, 27 Jan 2012 11:49:33 -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: Fri, 27 Jan 2012 11:49:05 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MAEC in SCI Thread-Index: AczdG/WfbxSslx+pRm2MmJUNJy7mRg== From: To: X-OriginalArrivalTime: 27 Jan 2012 17:49:33.0336 (UTC) FILETIME=[0702F980:01CCDD1C] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18672.000 X-TM-AS-Result: No--11.173-5.0-31-1 X-imss-scan-details: No--11.173-5.0-31-1 Subject: [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: Fri, 27 Jan 2012 17:49:36 -0000 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=20 From turners@ieca.com Fri Jan 27 10:24:24 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 3E09221F864C for ; Fri, 27 Jan 2012 10:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=0.150, 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 jOTp6QoBKfHx for ; Fri, 27 Jan 2012 10:24:23 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.137.88]) by ietfa.amsl.com (Postfix) with ESMTP id 58D7721F8617 for ; Fri, 27 Jan 2012 10:24:23 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 926DD9E3272F3; Fri, 27 Jan 2012 12:24:22 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 856A19E3272D1 for ; Fri, 27 Jan 2012 12:24:22 -0600 (CST) Received: from [96.231.118.153] (port=46257 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqqTG-00083y-1W for mile@ietf.org; Fri, 27 Jan 2012 12:24:22 -0600 Message-ID: <4F22EBD5.2050406@ieca.com> Date: Fri, 27 Jan 2012 13:24:21 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mile@ietf.org References: <1C02BE67-EF93-4B0D-92F4-EBA5895A4606@tik.ee.ethz.ch> In-Reply-To: <1C02BE67-EF93-4B0D-92F4-EBA5895A4606@tik.ee.ethz.ch> 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-118-153.washdc.east.verizon.net (thunderfish.local) [96.231.118.153]:46257 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [mile] IDNs 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, 27 Jan 2012 18:24:24 -0000 Time to speak up if you've got a problem with this approach. spt On 1/27/12 12:30 PM, Brian Trammell wrote: > Hi, Kathleen, > > Given the requirements, UTF8, free convertibility among the label forms, and implementation support for this convertibility, this seems like a good way to go. > > Best regards, > > Brian (as a random guy off the street) > > On Jan 27, 2012, at 4:35 PM, wrote: > >> Hi, >> >> This is a final check to make sure people are OK with the proposed approach for IDNs in RID: >> >> Addresses in the Node element rely on IP addresses (they are required in each instance). A DNS name can be contained in the NodeName element of Node, but is derived from the IP address. Authentication does not and never did rely on DNS names as we use certificates at the RID layer for digital signatures and encryption, and certificates at the TLS layer. With this in mind, the international considerations, as currently proposed is as follows: >> >> 11. Internationalization Issues >> >> The Node class identifies a host or network device. This document >> re-uses the definition of Node from the IODEF specification >> [RFC5070], Section 3.16. However, that document did not clearly >> specify whether a NodeName could be an Internationalized Domain Name >> (IDN). RID systems MUST treat the NodeName class as a domain name >> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >> class; if they do so, the UTF-8 representation of the domain name >> MUST be used, i.e., all of the domain name's labels MUST be U-labels >> expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be >> used. An application communicating via RID can convert between >> A-labels and U-labels by using the Punycode encoding [RFC3492] for >> A-labels as described in the protocol specification for >> Internationalized Domain Names in Applications [RFC5891]. RID >> systems are expected to obtain an IDN meeting these requirements by >> asking a DNS resolver to return an IDN that does not contain A-labels >> (even if the input contains A-labels). >> >> I am just waiting to hear from one of the ADs and will post the draft once I get an OK from Pete. >> >> Thank you, >> Kathleen >> >> >> Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-5807 | Kathleen.Moriarty@emc.com | EMC Corporation >> >> >> >> _______________________________________________ >> mile mailing 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 Fri Jan 27 11:01: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 26B5E21F8684 for ; Fri, 27 Jan 2012 11:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.262 X-Spam-Level: X-Spam-Status: No, score=-109.262 tagged_above=-999 required=5 tests=[AWL=1.337, 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 ztpZsxAc74sS for ; Fri, 27 Jan 2012 11:01:14 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5648121F8683 for ; Fri, 27 Jan 2012 11:01:14 -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 q0RJ1Brr029911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 14:01:12 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 27 Jan 2012 14:00:56 -0500 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0RJ0uZs016475; Fri, 27 Jan 2012 14:00:56 -0500 Received: from mx14a.corp.emc.com ([169.254.2.3]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Fri, 27 Jan 2012 14:00:56 -0500 From: To: , Date: Fri, 27 Jan 2012 14:00:54 -0500 Thread-Topic: [mile] IDNs Thread-Index: AczdIPci2oIIeuzPS9CWuKu4C/YcuwABP4yw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A38A8@MX14A.corp.emc.com> References: <1C02BE67-EF93-4B0D-92F4-EBA5895A4606@tik.ee.ethz.ch> <4F22EBD5.2050406@ieca.com> In-Reply-To: <4F22EBD5.2050406@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] IDNs 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, 27 Jan 2012 19:01:15 -0000 Looks like a fine approach to me, Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of S= ean Turner > Sent: Friday, January 27, 2012 1:24 PM > To: mile@ietf.org > Subject: Re: [mile] IDNs >=20 > Time to speak up if you've got a problem with this approach. >=20 > spt >=20 > On 1/27/12 12:30 PM, Brian Trammell wrote: > > Hi, Kathleen, > > > > Given the requirements, UTF8, free convertibility among the label forms= , and implementation support > for this convertibility, this seems like a good way to go. > > > > Best regards, > > > > Brian (as a random guy off the street) > > > > On Jan 27, 2012, at 4:35 PM, wrote: > > > >> Hi, > >> > >> This is a final check to make sure people are OK with the proposed app= roach for IDNs in RID: > >> > >> Addresses in the Node element rely on IP addresses (they are required = in each instance). A DNS > name can be contained in the NodeName element of Node, but is derived fro= m the IP address. > Authentication does not and never did rely on DNS names as we use certifi= cates at the RID layer for > digital signatures and encryption, and certificates at the TLS layer. Wi= th this in mind, the > international considerations, as currently proposed is as follows: > >> > >> 11. Internationalization Issues > >> > >> The Node class identifies a host or network device. This document > >> re-uses the definition of Node from the IODEF specification > >> [RFC5070], Section 3.16. However, that document did not clearly > >> specify whether a NodeName could be an Internationalized Domain Nam= e > >> (IDN). RID systems MUST treat the NodeName class as a domain name > >> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > >> class; if they do so, the UTF-8 representation of the domain name > >> MUST be used, i.e., all of the domain name's labels MUST be U-label= s > >> expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > >> used. An application communicating via RID can convert between > >> A-labels and U-labels by using the Punycode encoding [RFC3492] for > >> A-labels as described in the protocol specification for > >> Internationalized Domain Names in Applications [RFC5891]. RID > >> systems are expected to obtain an IDN meeting these requirements by > >> asking a DNS resolver to return an IDN that does not contain A-labe= ls > >> (even if the input contains A-labels). > >> > >> I am just waiting to hear from one of the ADs and will post the draft = once I get an OK from Pete. > >> > >> Thank you, > >> Kathleen > >> > >> > >> Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-8= 51-5807 | > Kathleen.Moriarty@emc.com | EMC Corporation > >> > >> > >> > >> _______________________________________________ > >> mile mailing 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 Fri Jan 27 11:03: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 86C2F21F8589 for ; Fri, 27 Jan 2012 11:03:28 -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 kSK62dq-kh-f for ; Fri, 27 Jan 2012 11:03:28 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C9FEB21F8512 for ; Fri, 27 Jan 2012 11:03:27 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2F2F621B10E5; Fri, 27 Jan 2012 14:03:27 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EA81621B10C1; Fri, 27 Jan 2012 14:03:26 -0500 (EST) Received: from bvb-172-31-57-223.mitre.org (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server id 14.1.339.1; Fri, 27 Jan 2012 14:03:26 -0500 Message-ID: <4F22F4FD.2020501@mitre.org> Date: Fri, 27 Jan 2012 14:03:25 -0500 From: "Martin, Robert A." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: References: <1C02BE67-EF93-4B0D-92F4-EBA5895A4606@tik.ee.ethz.ch> <4F22EBD5.2050406@ieca.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A38A8@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A38A8@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] IDNs 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, 27 Jan 2012 19:03:28 -0000 Concur. On 1/27/12 2:00 PM, david.black@emc.com wrote: > Looks like a fine approach to me, Thanks, --David > >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sean Turner >> Sent: Friday, January 27, 2012 1:24 PM >> To: mile@ietf.org >> Subject: Re: [mile] IDNs >> >> Time to speak up if you've got a problem with this approach. >> >> spt >> >> On 1/27/12 12:30 PM, Brian Trammell wrote: >>> Hi, Kathleen, >>> >>> Given the requirements, UTF8, free convertibility among the label forms, and implementation support >> for this convertibility, this seems like a good way to go. >>> >>> Best regards, >>> >>> Brian (as a random guy off the street) >>> >>> On Jan 27, 2012, at 4:35 PM, wrote: >>> >>>> Hi, >>>> >>>> This is a final check to make sure people are OK with the proposed approach for IDNs in RID: >>>> >>>> Addresses in the Node element rely on IP addresses (they are required in each instance). A DNS >> name can be contained in the NodeName element of Node, but is derived from the IP address. >> Authentication does not and never did rely on DNS names as we use certificates at the RID layer for >> digital signatures and encryption, and certificates at the TLS layer. With this in mind, the >> international considerations, as currently proposed is as follows: >>>> >>>> 11. Internationalization Issues >>>> >>>> The Node class identifies a host or network device. This document >>>> re-uses the definition of Node from the IODEF specification >>>> [RFC5070], Section 3.16. However, that document did not clearly >>>> specify whether a NodeName could be an Internationalized Domain Name >>>> (IDN). RID systems MUST treat the NodeName class as a domain name >>>> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >>>> class; if they do so, the UTF-8 representation of the domain name >>>> MUST be used, i.e., all of the domain name's labels MUST be U-labels >>>> expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be >>>> used. An application communicating via RID can convert between >>>> A-labels and U-labels by using the Punycode encoding [RFC3492] for >>>> A-labels as described in the protocol specification for >>>> Internationalized Domain Names in Applications [RFC5891]. RID >>>> systems are expected to obtain an IDN meeting these requirements by >>>> asking a DNS resolver to return an IDN that does not contain A-labels >>>> (even if the input contains A-labels). >>>> >>>> I am just waiting to hear from one of the ADs and will post the draft once I get an OK from Pete. >>>> >>>> Thank you, >>>> Kathleen >>>> >>>> >>>> Kathleen M. Moriarty, CISSP | GRC Strategy | Office of the CTO | 617-851-5807 | >> Kathleen.Moriarty@emc.com | EMC Corporation >>>> >>>> >>>> >>>> _______________________________________________ >>>> mile mailing 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 stpeter@stpeter.im Fri Jan 27 12:41: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 E42E621F86C4 for ; Fri, 27 Jan 2012 12:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy31shJ-mLaq for ; Fri, 27 Jan 2012 12:41:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC3E21F86BE for ; Fri, 27 Jan 2012 12:41:34 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C1D904005A; Fri, 27 Jan 2012 13:51:25 -0700 (MST) Message-ID: <4F230BFB.1020403@stpeter.im> Date: Fri, 27 Jan 2012 13:41:31 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mile@ietf.org, Pete Resnick Subject: Re: [mile] IDNs 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, 27 Jan 2012 20:41:35 -0000 On 1/27/12 8:35 AM, kathleen.moriarty@emc.com wrote: > Hi, > > This is a final check to make sure people are OK with the proposed > approach for IDNs in RID: > > Addresses in the Node element rely on IP addresses (they are required > in each instance). A DNS name can be contained in the NodeName > element of Node, but is derived from the IP address. Authentication > does not and never did rely on DNS names as we use certificates at > the RID layer for digital signatures and encryption, and certificates > at the TLS layer. With this in mind, the international > considerations, as currently proposed is as follows: > > 11. Internationalization Issues > > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name > MUST be used, i.e., all of the domain name's labels MUST be U-labels > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > used. An application communicating via RID can convert between > A-labels and U-labels by using the Punycode encoding [RFC3492] for > A-labels as described in the protocol specification for > Internationalized Domain Names in Applications [RFC5891]. RID > systems are expected to obtain an IDN meeting these requirements by > asking a DNS resolver to return an IDN that does not contain > A-labels (even if the input contains A-labels). As long as the WG is fine with it, that works for me. One small clarifying question: I assume by the phrase "even if the input contains A-labels" you mean the RID system's input to the DNS resolver. Correct? Peter -- Peter Saint-Andre https://stpeter.im/ From david.black@emc.com Fri Jan 27 12:43: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 C3CAE21F861B for ; Fri, 27 Jan 2012 12:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.278 X-Spam-Level: X-Spam-Status: No, score=-109.278 tagged_above=-999 required=5 tests=[AWL=1.321, 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 dlinWy7KJDY4 for ; Fri, 27 Jan 2012 12:43: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 AF61A21F85EA for ; Fri, 27 Jan 2012 12:43:33 -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 q0RKhVXO007266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 15:43:31 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 27 Jan 2012 15:43:13 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0RKhCIj004992; Fri, 27 Jan 2012 15:43:12 -0500 Received: from mx14a.corp.emc.com ([169.254.2.3]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Fri, 27 Jan 2012 15:43:12 -0500 From: To: Date: Fri, 27 Jan 2012 15:43:11 -0500 Thread-Topic: [mile] IDNs Thread-Index: AczdNCPIFP236+t1QU+TDLLchCOPcgAAAfow Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3938@MX14A.corp.emc.com> References: <4F230BFB.1020403@stpeter.im> In-Reply-To: <4F230BFB.1020403@stpeter.im> 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, presnick@qualcomm.com Subject: Re: [mile] IDNs 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, 27 Jan 2012 20:43:34 -0000 > One small clarifying question: I assume by the phrase "even if the input > contains A-labels" you mean the RID system's input to the DNS resolver. > Correct? Correct, and a good clarification. Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of P= eter Saint-Andre > Sent: Friday, January 27, 2012 3:42 PM > To: Moriarty, Kathleen > Cc: mile@ietf.org; Pete Resnick > Subject: Re: [mile] IDNs >=20 > On 1/27/12 8:35 AM, kathleen.moriarty@emc.com wrote: > > Hi, > > > > This is a final check to make sure people are OK with the proposed > > approach for IDNs in RID: > > > > Addresses in the Node element rely on IP addresses (they are required > > in each instance). A DNS name can be contained in the NodeName > > element of Node, but is derived from the IP address. Authentication > > does not and never did rely on DNS names as we use certificates at > > the RID layer for digital signatures and encryption, and certificates > > at the TLS layer. With this in mind, the international > > considerations, as currently proposed is as follows: > > > > 11. Internationalization Issues > > > > The Node class identifies a host or network device. This document > > re-uses the definition of Node from the IODEF specification > > [RFC5070], Section 3.16. However, that document did not clearly > > specify whether a NodeName could be an Internationalized Domain Name > > (IDN). RID systems MUST treat the NodeName class as a domain name > > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > > class; if they do so, the UTF-8 representation of the domain name > > MUST be used, i.e., all of the domain name's labels MUST be U-labels > > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > > used. An application communicating via RID can convert between > > A-labels and U-labels by using the Punycode encoding [RFC3492] for > > A-labels as described in the protocol specification for > > Internationalized Domain Names in Applications [RFC5891]. RID > > systems are expected to obtain an IDN meeting these requirements by > > asking a DNS resolver to return an IDN that does not contain > > A-labels (even if the input contains A-labels). >=20 > As long as the WG is fine with it, that works for me. >=20 > One small clarifying question: I assume by the phrase "even if the input > contains A-labels" you mean the RID system's input to the DNS resolver. > Correct? >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Jan 27 13:23: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 8915421F865A for ; Fri, 27 Jan 2012 13:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.726 X-Spam-Level: X-Spam-Status: No, score=-9.726 tagged_above=-999 required=5 tests=[AWL=0.873, 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 DxkH6YdemTMd for ; Fri, 27 Jan 2012 13:23:59 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id C083D21F8618 for ; Fri, 27 Jan 2012 13:23:58 -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 q0RLNv0Q020745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 16:23:57 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 27 Jan 2012 16:23:32 -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 q0RLNVpU006122; Fri, 27 Jan 2012 16:23:31 -0500 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub04.corp.emc.com (10.254.141.106) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 27 Jan 2012 16:23:30 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Fri, 27 Jan 2012 16:23:30 -0500 From: To: Date: Fri, 27 Jan 2012 16:23:29 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczdOZ8K4wvkGCmXQwWWmukDM1czEAAACngA Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> In-Reply-To: <4F23153B.9060209@isode.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] 6046-bis - Client certificate identity check 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, 27 Jan 2012 21:23:59 -0000 Thank you. Can we handle this in Auth48 and progress this document? Yes, the discussions have been very good! Thanks, Kathleen -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 Sent: Friday, January 27, 2012 4:21 PM To: Moriarty, Kathleen Cc: stpeter@stpeter.im; mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check On 27/01/2012 14:50, kathleen.moriarty@emc.com wrote: > Alexey, Hi Kathleen, > It appears your questions for RFC6046-bis have been addressed, can you co= nfirm? draft-ietf-mile-rfc6046-bis-09 looks good to me. One thing that can be=20 improved is to say that the server that accepts a TCP connection would=20 use reverse DNS lookup to retrieve the identity of the connecting=20 server. "Stable DNS identity" doesn't quite say that to me. Best Regards, Alexey P.S. This discussion was very productive and enjoyable. Thank you to all=20 parties involved! > Thank you, > Kathleen (as Chair) > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of P= eter Saint-Andre > Sent: Thursday, January 26, 2012 6:13 PM > To: Black, David > Cc: mile@ietf.org; alexey.melnikov@isode.com > Subject: Re: [mile] 6046-bis - Client certificate identity check > > On 1/26/12 1:51 PM, david.black@emc.com wrote: >>>>> If you are not concerned about one RID member masquerading as another= , >>>>> it might be sufficient for your protocol to allow client certificates= to >>>>> come from a known CA (or a set of CAs), or be whitelisted. So basica= lly >>>>> you will use more relaxed verification rules from RFC 5280. >>>> Well, I think you'd probably still want to do the domain check, no? >>> How would you derive a domain name for the connecting entry (what I >>> called "client")? The server only has an IP address and port. So other >>> than doing reverse DNS mapping or similar, I don't think anything will >>> result in a domain. >> The HTTP/TLS client can check the server's certificate against the domai= n >> in the URL, and I read RFC 6125 as requiring this check. The HTTP/TLS >> server needs to do something else. > Right, the identities need to be checked in both directions. That's why > I likened it to the server-to-server case in SMTP or XMPP. > >> The current -09 version of 6046-bis requires that sufficient domain name >> information be kept based on consortium setup so that both the HTTP/TLS >> client and server can both perform a domain name reference identifier >> check against the TLS certificate presented by the other party: >> >> The use of stable DNS names to address RID systems is RECOMMENDED; i= n >> addition to facilitating connection to RID systems within a >> consortium, these are to be used as reference identifiers for a RID >> system's peers. [... unrelated sentence snipped ...] >> The protocol provides no in-band method for handling a >> change of address of a RID system. >> >> ... >> >> All RID systems MUST be identified by a certificate containing a >> DNS-ID identifier [RFC5280] as in section 6.4 of [RFC6125]; RID >> systems MUST verify the reference identifiers of their peers against >> those stored in the certificates presented. > Looks good to me. > > Peter > From stpeter@stpeter.im Fri Jan 27 13:24:12 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 C22ED21F865C for ; Fri, 27 Jan 2012 13:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 XA+9ka+ldRtb for ; Fri, 27 Jan 2012 13:24:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7721F8633 for ; Fri, 27 Jan 2012 13:24:12 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D64934009B; Fri, 27 Jan 2012 14:34:02 -0700 (MST) Message-ID: <4F2315F9.5080001@stpeter.im> Date: Fri, 27 Jan 2012 14:24:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> In-Reply-To: <4F23153B.9060209@isode.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 27 Jan 2012 21:24:12 -0000 On 1/27/12 2:20 PM, Alexey Melnikov wrote: > On 27/01/2012 14:50, kathleen.moriarty@emc.com wrote: >> Alexey, > Hi Kathleen, >> It appears your questions for RFC6046-bis have been addressed, can you >> confirm? > draft-ietf-mile-rfc6046-bis-09 looks good to me. One thing that can be > improved is to say that the server that accepts a TCP connection would > use reverse DNS lookup to retrieve the identity of the connecting > server. "Stable DNS identity" doesn't quite say that to me. I think that's a good improvement. > P.S. This discussion was very productive and enjoyable. Thank you to all > parties involved! Hear, hear! Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Fri Jan 27 13:23: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 DCE4F21F85BE for ; Fri, 27 Jan 2012 13:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.092 X-Spam-Level: X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=0.507, 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 H0bVTnJE7ccp for ; Fri, 27 Jan 2012 13:23:06 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D73B821F85AF for ; Fri, 27 Jan 2012 13:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327699243; d=isode.com; s=selector; i=@isode.com; bh=jcklbWmNA7mrHhWEs4Cj+t+a/eWPELewrf0rUllDhvY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eJ9qStAkn4ggbVKu7DYT8JgTPs1ogQ+URL6LBANPYN2btqS0BPtBI1XgdvSNBVhE+2BxCD LsLBpG/tlwzyhyXKdStGiRENf0vRyOtrNnLECwEnSMA0x70Fzzv4cQ7me5i85qXEA9/UWY EwYiNpf1LVPxodh+lxCqDfXs/vN1fIo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 27 Jan 2012 21:20:43 +0000 Message-ID: <4F23153B.9060209@isode.com> Date: Fri, 27 Jan 2012 21:20:59 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: kathleen.moriarty@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Jan 2012 13:25:39 -0800 Cc: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 27 Jan 2012 21:23:07 -0000 On 27/01/2012 14:50, kathleen.moriarty@emc.com wrote: > Alexey, Hi Kathleen, > It appears your questions for RFC6046-bis have been addressed, can you confirm? draft-ietf-mile-rfc6046-bis-09 looks good to me. One thing that can be improved is to say that the server that accepts a TCP connection would use reverse DNS lookup to retrieve the identity of the connecting server. "Stable DNS identity" doesn't quite say that to me. Best Regards, Alexey P.S. This discussion was very productive and enjoyable. Thank you to all parties involved! > Thank you, > Kathleen (as Chair) > > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: Thursday, January 26, 2012 6:13 PM > To: Black, David > Cc: mile@ietf.org; alexey.melnikov@isode.com > Subject: Re: [mile] 6046-bis - Client certificate identity check > > On 1/26/12 1:51 PM, david.black@emc.com wrote: >>>>> If you are not concerned about one RID member masquerading as another, >>>>> it might be sufficient for your protocol to allow client certificates to >>>>> come from a known CA (or a set of CAs), or be whitelisted. So basically >>>>> you will use more relaxed verification rules from RFC 5280. >>>> Well, I think you'd probably still want to do the domain check, no? >>> How would you derive a domain name for the connecting entry (what I >>> called "client")? The server only has an IP address and port. So other >>> than doing reverse DNS mapping or similar, I don't think anything will >>> result in a domain. >> The HTTP/TLS client can check the server's certificate against the domain >> in the URL, and I read RFC 6125 as requiring this check. The HTTP/TLS >> server needs to do something else. > Right, the identities need to be checked in both directions. That's why > I likened it to the server-to-server case in SMTP or XMPP. > >> The current -09 version of 6046-bis requires that sufficient domain name >> information be kept based on consortium setup so that both the HTTP/TLS >> client and server can both perform a domain name reference identifier >> check against the TLS certificate presented by the other party: >> >> The use of stable DNS names to address RID systems is RECOMMENDED; in >> addition to facilitating connection to RID systems within a >> consortium, these are to be used as reference identifiers for a RID >> system's peers. [... unrelated sentence snipped ...] >> The protocol provides no in-band method for handling a >> change of address of a RID system. >> >> ... >> >> All RID systems MUST be identified by a certificate containing a >> DNS-ID identifier [RFC5280] as in section 6.4 of [RFC6125]; RID >> systems MUST verify the reference identifiers of their peers against >> those stored in the certificates presented. > Looks good to me. > > Peter > From turners@ieca.com Fri Jan 27 13:25:53 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 CE1CF21F865C for ; Fri, 27 Jan 2012 13:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.142, 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 Iuk1XuWcpgGI for ; Fri, 27 Jan 2012 13:25:53 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.82.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5718621F860B for ; Fri, 27 Jan 2012 13:25:53 -0800 (PST) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 69FF6A86A44B7; Fri, 27 Jan 2012 15:25:45 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 3303EA86A341A for ; Fri, 27 Jan 2012 15:25:45 -0600 (CST) Received: from [96.231.127.203] (port=34287 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqtIm-0001s9-F6; Fri, 27 Jan 2012 15:25:44 -0600 Message-ID: <4F231657.2070809@ieca.com> Date: Fri, 27 Jan 2012 16:25:43 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Peter Saint-Andre , Pete Resnick References: <4F230BFB.1020403@stpeter.im> In-Reply-To: <4F230BFB.1020403@stpeter.im> 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-127-203.washdc.east.verizon.net (thunderfish.local) [96.231.127.203]:34287 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org Subject: Re: [mile] IDNs 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, 27 Jan 2012 21:25:53 -0000 On 1/27/12 3:41 PM, Peter Saint-Andre wrote: > On 1/27/12 8:35 AM, kathleen.moriarty@emc.com wrote: >> Hi, >> >> This is a final check to make sure people are OK with the proposed >> approach for IDNs in RID: >> >> Addresses in the Node element rely on IP addresses (they are required >> in each instance). A DNS name can be contained in the NodeName >> element of Node, but is derived from the IP address. Authentication >> does not and never did rely on DNS names as we use certificates at >> the RID layer for digital signatures and encryption, and certificates >> at the TLS layer. With this in mind, the international >> considerations, as currently proposed is as follows: >> >> 11. Internationalization Issues >> >> The Node class identifies a host or network device. This document >> re-uses the definition of Node from the IODEF specification >> [RFC5070], Section 3.16. However, that document did not clearly >> specify whether a NodeName could be an Internationalized Domain Name >> (IDN). RID systems MUST treat the NodeName class as a domain name >> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName >> class; if they do so, the UTF-8 representation of the domain name >> MUST be used, i.e., all of the domain name's labels MUST be U-labels >> expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be >> used. An application communicating via RID can convert between >> A-labels and U-labels by using the Punycode encoding [RFC3492] for >> A-labels as described in the protocol specification for >> Internationalized Domain Names in Applications [RFC5891]. RID >> systems are expected to obtain an IDN meeting these requirements by >> asking a DNS resolver to return an IDN that does not contain >> A-labels (even if the input contains A-labels). > > As long as the WG is fine with it, that works for me. At this point it's all thumbs up. Just waiting on Pete ;) spt > One small clarifying question: I assume by the phrase "even if the input > contains A-labels" you mean the RID system's input to the DNS resolver. > Correct? > > Peter > From stpeter@stpeter.im Fri Jan 27 13:27: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 2C0DD21F8681 for ; Fri, 27 Jan 2012 13:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 2Sjpglk54V8C for ; Fri, 27 Jan 2012 13:27:10 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9E59321F8677 for ; Fri, 27 Jan 2012 13:27:10 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7509A4009B; Fri, 27 Jan 2012 14:37:02 -0700 (MST) Message-ID: <4F2316AC.7000603@stpeter.im> Date: Fri, 27 Jan 2012 14:27:08 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mile@ietf.org, alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 27 Jan 2012 21:27:11 -0000 On 1/27/12 2:23 PM, kathleen.moriarty@emc.com wrote: > Thank you. Can we handle this in Auth48 and progress this document? It's up to your responsible AD, but I think that would be fine. Peter -- Peter Saint-Andre https://stpeter.im/ From turners@ieca.com Fri Jan 27 13: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 DAB0E21F86D0 for ; Fri, 27 Jan 2012 13:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.131 X-Spam-Level: X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=0.134, 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 WhY6c93WqVf7 for ; Fri, 27 Jan 2012 13:36:06 -0800 (PST) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.170.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7A06821F86C8 for ; Fri, 27 Jan 2012 13:36:06 -0800 (PST) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 14BC7A9E1015B; Fri, 27 Jan 2012 15:36:04 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 09681A9E10122 for ; Fri, 27 Jan 2012 15:36:04 -0600 (CST) Received: from [96.231.127.203] (port=36690 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqtSl-0005GN-CZ; Fri, 27 Jan 2012 15:36:03 -0600 Message-ID: <4F2318C2.8040507@ieca.com> Date: Fri, 27 Jan 2012 16:36:02 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: kathleen.moriarty@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> <4F2316AC.7000603@stpeter.im> In-Reply-To: <4F2316AC.7000603@stpeter.im> 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-127-203.washdc.east.verizon.net (thunderfish.local) [96.231.127.203]:36690 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: mile@ietf.org, alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 27 Jan 2012 21:36:07 -0000 On 1/27/12 4:27 PM, Peter Saint-Andre wrote: > On 1/27/12 2:23 PM, kathleen.moriarty@emc.com wrote: >> Thank you. Can we handle this in Auth48 and progress this document? > > It's up to your responsible AD, but I think that would be fine. I think we can handle this during AUTH48. spt From kathleen.moriarty@emc.com Fri Jan 27 13:45:49 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 858BB21F86BB for ; Fri, 27 Jan 2012 13:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.74 X-Spam-Level: X-Spam-Status: No, score=-9.74 tagged_above=-999 required=5 tests=[AWL=0.859, 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 FbfIMryJnVAc for ; Fri, 27 Jan 2012 13:45: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 8AF2321F86A0 for ; Fri, 27 Jan 2012 13:45: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 q0RLjjIO004799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 16:45:46 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 27 Jan 2012 16:45:29 -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 q0RLjSom025986; Fri, 27 Jan 2012 16:45:28 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Fri, 27 Jan 2012 16:45:28 -0500 From: To: Date: Fri, 27 Jan 2012 16:45:27 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczdO703S1qL0T9zR06zR+x+lx1GBwAASpOA Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> In-Reply-To: <4F2318C2.8040507@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, alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 27 Jan 2012 21:45:49 -0000 Thank you, that closes out all open issues for RFC6046-bis. Kathleen -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Friday, January 27, 2012 4:36 PM To: Moriarty, Kathleen Cc: Peter Saint-Andre; mile@ietf.org; alexey.melnikov@isode.com Subject: Re: [mile] 6046-bis - Client certificate identity check On 1/27/12 4:27 PM, Peter Saint-Andre wrote: > On 1/27/12 2:23 PM, kathleen.moriarty@emc.com wrote: >> Thank you. Can we handle this in Auth48 and progress this document? > > It's up to your responsible AD, but I think that would be fine. I think we can handle this during AUTH48. spt From iesg-secretary@ietf.org Fri Jan 27 14:54: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 177C721F8636; Fri, 27 Jan 2012 14:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3EDJxZ6HhHy; Fri, 27 Jan 2012 14:54:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6245A21F8637; Fri, 27 Jan 2012 14:54:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120127225402.10591.76089.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 14:54:02 -0800 Cc: mile mailing list , mile chair , RFC Editor Subject: [mile] Protocol Action: 'Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS' to Proposed Standard (draft-ietf-mile-rfc6046-bis-09.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, 27 Jan 2012 22:54:03 -0000 The IESG has approved the following document: - 'Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS' (draft-ietf-mile-rfc6046-bis-09.txt) as a Proposed Standard This document is the product of the Managed Incident Lightweight Exchange Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6046-bis/ Technical Summary This document provides the HTTP/TLS transport specification for Real-time Inter-network Defense (RID) messaging defined in RFC6045-bis. This document updates RFC6046. Working Group Summary The working group formally adopted this draft as a working group item in Taipei. There has been clear recognition that this document is needed to provide the transport for RFC6045-bis (also a WG item). Working group members showed their support for this document in the review process through reviews and comments sent to the mailing list. All suggested changes are included in the current version. Document Quality There are existing implementations and new ones in development based on the updated requirements. Increasing interest in this protocol has been demonstrated by computer security incident response teams (CSIRTs) and information sharing groups (industry and regionally focused) to automate the exchange of cyber security information exchange. The ITU-T also has interest in referencing this document in their suite of protocols in Study Group 17, question 4. Small changes were recommended and made during the working group last call. There are no outstanding technical concerns with this document. The technical reviews provided by David Black and SM@resistor.net provided small changes that are reflected in the current version. Personnel Kathleen Moriarty (kathleen.moriarty@emc.com) is the document shepherd. Sean Turner (turners@ieca.com) is the responsible Area Director. From internet-drafts@ietf.org Fri Jan 27 16:20: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 E2C6E21F85CE; Fri, 27 Jan 2012 16:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Coy9Q128J85p; Fri, 27 Jan 2012 16:20:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197621F8525; Fri, 27 Jan 2012 16:20:35 -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.64p1 Message-ID: <20120128002035.30849.26017.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 16:20:35 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-10.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: Sat, 28 Jan 2012 00:20:36 -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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-10.txt Pages : 84 Date : 2012-01-27 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-10.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-rfc6045-bis-10.txt From david.black@emc.com Fri Jan 27 16:39:17 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 8C5DA21F85FC for ; Fri, 27 Jan 2012 16:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.292 X-Spam-Level: X-Spam-Status: No, score=-109.292 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3rZ95+7ssJB4 for ; Fri, 27 Jan 2012 16:39:16 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2C71121F85FB for ; Fri, 27 Jan 2012 16:39:15 -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 q0S0dE60025188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 19:39:15 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 27 Jan 2012 19:39: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 q0S0d4Tt015589; Fri, 27 Jan 2012 19:39:04 -0500 Received: from mx14a.corp.emc.com ([169.254.2.3]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 27 Jan 2012 19:39:04 -0500 From: To: , Date: Fri, 27 Jan 2012 19:39:03 -0500 Thread-Topic: [mile] FW: IDN issue Thread-Index: AczdVP0pNnQRsX1CSG2sV4GmN+o5XwAACodw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> In-Reply-To: <4F2342E1.3010101@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994MX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] FW: IDN issue 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, 28 Jan 2012 00:39:17 -0000 --_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994MX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hmmmm....I'm not sure I even know what that means. As far as I know, DNS = resolvers deal in A-labels or NR-LDH labels, not U-labels. > Or do you mean by "resolver" the entire API which takes a name and resolv= es it? I think that is a novel use of the term. It's the entire client API. Thanks, --David From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Friday, January 27, 2012 7:36 PM To: Peter Saint-Andre Cc: Black, David; Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] FW: IDN issue On 1/26/12 5:21 PM, Peter Saint-Andre wrote: RID systems are expected to obtain an IDN meeting these requirement= s by asking a DNS resolver to return an IDN that does not contain A-labels (even if the input IDN contains A-labels). ** Will that work? I *think* so but I am going to complete a final sanity-check with my co-AD to be sure. Pete: does that work for you? Hmmmm....I'm not sure I even know what that means. As far as I know, DNS re= solvers deal in A-labels or NR-LDH labels, not U-labels. Or do you mean by = "resolver" the entire API which takes a name and resolves it? I think that = is a novel use of the term. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994MX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= > Hmmmm....I'm not sure I even know what that means. As far as I know, D= NS resolvers deal in A-labels or NR-LDH labels, not U-labels.

> Or do you mean by "resolver" the entir= e API which takes a name and resolves it? I think that is a novel use of th= e term.

 

It’s the entire client API.

 

Thanks,
--David

=  

From: Pete Resnick [mailto:presnick@qualcomm.com]
Sent: Friday, January 27, 2012 7:36 PM
To: Peter Saint-Andre
C= c: Black, David; Moriarty, Kathleen; mile@ietf.org
Subject: R= e: [mile] FW: IDN issue

 

On 1/26/12 5:21 PM, Peter Sain= t-Andre wrote: 

        RID syst=
ems are expected to obtain an IDN meeting these requirements
        by asking a DNS resolver =
to return an IDN that does not contain
  &nb=
sp;     A-labels (even if the input IDN contains A-labe=
ls).
 
 ** Will that work?<=
o:p>
    
=
I *think* so but I am going to complete a final sanity-check with my
co-AD to be sure.
 
Pete: does that work for you?
  =


Hmmmm....I'm not sure I even know what= that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH lab= els, not U-labels. Or do you mean by "resolver" the entire API wh= ich takes a name and resolves it? I think that is a novel use of the term.<= br>
pr

-- 
Pete Resnick =
<http://www.qualcomm.com/=
~presnick/>
Qualcomm Incorporated - Direct phon=
e: (858)651-4478, Fax: (858)651-1102
= --_000_7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994MX14Acorpemcc_-- From kathleen.moriarty@emc.com Fri Jan 27 17:53: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 CCF5321F8552 for ; Fri, 27 Jan 2012 17:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.753 X-Spam-Level: X-Spam-Status: No, score=-9.753 tagged_above=-999 required=5 tests=[AWL=0.845, 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 qHvcJ+gmkHvM for ; Fri, 27 Jan 2012 17:53:38 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 72DE021F852B for ; Fri, 27 Jan 2012 17:53:38 -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 q0S1raav014447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 20:53:37 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 27 Jan 2012 20:53:12 -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 q0S1rBCd031159; Fri, 27 Jan 2012 20:53:11 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Fri, 27 Jan 2012 20:53:11 -0500 From: To: , , Date: Fri, 27 Jan 2012 20:53:10 -0500 Thread-Topic: [mile] FW: IDN issue Thread-Index: AczdVP0pNnQRsX1CSG2sV4GmN+o5XwAACodwAAKLWfA= Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AE31510960917D478171C79369B660FA0E2C08786AMX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] FW: IDN issue 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, 28 Jan 2012 01:53:40 -0000 --_000_AE31510960917D478171C79369B660FA0E2C08786AMX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pete, Peter had suggested a tweak to the text that appears in -10, which should r= esolve the question. Here is the current text (see the last sentence): 11. Internationalization Issues The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. An application communicating via RID can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. RID systems are expected to obtain an IDN meeting these requirements by asking a DNS resolver to return an IDN that does not contain A-labels (even if the RID system's input to the DNS resolver contains A-labels). Let me know if that works. Thanks, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of dav= id.black@emc.com Sent: Friday, January 27, 2012 7:39 PM To: presnick@qualcomm.com; stpeter@stpeter.im Cc: mile@ietf.org Subject: Re: [mile] FW: IDN issue > Hmmmm....I'm not sure I even know what that means. As far as I know, DNS = resolvers deal in A-labels or NR-LDH labels, not U-labels. > Or do you mean by "resolver" the entire API which takes a name and resolv= es it? I think that is a novel use of the term. It's the entire client API. Thanks, --David From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Friday, January 27, 2012 7:36 PM To: Peter Saint-Andre Cc: Black, David; Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] FW: IDN issue On 1/26/12 5:21 PM, Peter Saint-Andre wrote: RID systems are expected to obtain an IDN meeting these requirement= s by asking a DNS resolver to return an IDN that does not contain A-labels (even if the input IDN contains A-labels). ** Will that work? I *think* so but I am going to complete a final sanity-check with my co-AD to be sure. Pete: does that work for you? Hmmmm....I'm not sure I even know what that means. As far as I know, DNS re= solvers deal in A-labels or NR-LDH labels, not U-labels. Or do you mean by = "resolver" the entire API which takes a name and resolves it? I think that = is a novel use of the term. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --_000_AE31510960917D478171C79369B660FA0E2C08786AMX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Pete,

 

Peter had suggested a tweak to t= he text that appears in -10, which should resolve the question.  Here = is the current text (see the last sentence):

 

11.&n= bsp; Internationalization Issues

=  

   The Node cl= ass identifies a host or network device.  This document

   re-uses the definition of Node fr= om the IODEF specification

 = ;  [RFC5070], Section 3.16.  However, that document did not clear= ly

   specify whether = a NodeName could be an Internationalized Domain Name

<= p class=3DMsoNormal>   (IDN).  RID systems MUST treat the N= odeName class as a domain name

&= nbsp;  slot [RFC5890].  RID systems SHOULD support IDNs in the No= deName

   class; if th= ey do so, the UTF-8 representation of the domain name

=

   MUST be used, i.e., all of the domain na= me's labels MUST be U-labels

&nb= sp;  expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT = be

   used.  An a= pplication communicating via RID can convert between

<= p class=3DMsoNormal>   A-labels and U-labels by using the Punyco= de encoding [RFC3492] for

 =   A-labels as described in the protocol specification for

   Internationalized Domain Names = in Applications [RFC5891].  RID

   systems are expected to obtain an IDN meeting these requi= rements by

   asking a= DNS resolver to return an IDN that does not contain A-labels

   (even if the RID system's input = to the DNS resolver contains

&nb= sp;  A-labels).

 

 

Let me know if that works.

 

Thanks,

Kat= hleen

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = david.black@emc.com
Sent: Friday, January 27, 2012 7:39 PMTo: presnick@qualcomm.com; stpeter@stpeter.im
Cc: mile@ie= tf.org
Subject: Re: [mile] FW: IDN issue

 

>= ; Hmmmm....I'm not sure I even know what that means. As far as I know, DNS = resolvers deal in A-labels or NR-LDH labels, not U-labels.

> Or do you mean by "resolver" the entire A= PI which takes a name and resolves it? I think that is a novel use of the t= erm.

 

It’s the entire client API.

 =

Thanks,
--David

 

From:= Pete Resnick [mailto:presnick@qualcomm.com]
Sent: = Friday, January 27, 2012 7:36 PM
To: Peter Saint-Andre
Cc:<= /b> Black, David; Moriarty, Kathleen; mile@ietf.org
Subject: Re: = [mile] FW: IDN issue

=  

On 1/26/12 5:21 PM, Peter Saint-A= ndre wrote: 

        RID systems=
 are expected to obtain an IDN meeting these requirements
<= pre>        by asking a DNS resolver to = return an IDN that does not contain
   =
     A-labels (even if the input IDN contains A-labels)=
.
 
 ** Will that work?
    
I <=
span class=3Dmoz-txt-tag>*think*=
 so but I am going to complete a final sanity-check with my=

co-AD to be sure.
 
Pete: does that work for you?
  

Hmmmm....I=
'm not sure I even know what that means. As far as I know, DNS resolvers de=
al in A-labels or NR-LDH labels, not U-labels. Or do you mean by "reso=
lver" the entire API which takes a name and resolves it? I think that =
is a novel use of the term.

pr
-- 
Pete Resnick <http=
://www.qualcomm.com/~presnick/>
Qualcomm Incorp=
orated - Direct phone: (858)651-4478, Fax: (858)651-1102
= --_000_AE31510960917D478171C79369B660FA0E2C08786AMX06Acorpemcc_-- From sm@resistor.net Fri Jan 27 22:16: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 AE24121F85EF for ; Fri, 27 Jan 2012 22:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 mRCziclY67eL for ; Fri, 27 Jan 2012 22:16:25 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00A21F84B3 for ; Fri, 27 Jan 2012 22:16:24 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0S6GIgl009620 for ; Fri, 27 Jan 2012 22:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327731383; i=@resistor.net; bh=/aXK5PzTrs7oWnR4PreiJTCXtkpo5jtMr8kO8UmYhZ0=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=RHMVnTEXpK77HFvd1kHXuUC2f0jNmDYhqoJU7aqkZGVPf+2/fa9WWBIfSRDlsQLz9 jv+gU5heHU/Pw7lSZmjNDL8QU1awRxPWhHC6WcvSKgSNSV//qHe0PiGcuQ5q2LC8A/ 1Jj9BWpMCJyKQmyjcZvK3FnOQj0rOFvvny2107Ag= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327731383; i=@resistor.net; bh=/aXK5PzTrs7oWnR4PreiJTCXtkpo5jtMr8kO8UmYhZ0=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=WQxZRUurw+gBBf+N0HYgXlcjPAjjXx51ZfZjcw615pJ5fSmYN0spSVMHMlVCAUKsM pubRfxVJZNhL+kGtd34GMRMf8aHzDftRAEhMyZTTCxJ2Q2qF443aIIqch0x7LGjWAv 8n80FCKXhh8TFvuoiXZcmkvpI0Fq84S39sdoIKcQ= Message-Id: <6.2.5.6.2.20120127215751.088caec0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Jan 2012 22:14:29 -0800 To: mile@ietf.org From: SM In-Reply-To: <4F23153B.9060209@isode.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 28 Jan 2012 06:16:27 -0000 At 13:20 27-01-2012, Alexey Melnikov wrote: >draft-ietf-mile-rfc6046-bis-09 looks good to me. One thing that can >be improved is to say that the server that accepts a TCP connection >would use reverse DNS lookup to retrieve the identity of the >connecting server. "Stable DNS identity" doesn't quite say that to me. DNS PTR is not that good as an identifier for security checks. These DNS records are not always well-maintained. There was a network in the Far East where the reverse DNS lookup was pointing to "localhost (this was not for .0.0.127.in-addr.arpa). Regards, -sm From msk@cloudmark.com Fri Jan 27 22:28: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 B541021F8508 for ; Fri, 27 Jan 2012 22:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 rRkJeHzZE9B4 for ; Fri, 27 Jan 2012 22:28:10 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B63321F8503 for ; Fri, 27 Jan 2012 22:28:10 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 22:28:09 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 27 Jan 2012 22:28:09 -0800 From: "Murray S. Kucherawy" To: "mile@ietf.org" Date: Fri, 27 Jan 2012 22:28:09 -0800 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczdhGNgFrGsS0tpQq+IDy3TYD4IrgAAW22g Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> <6.2.5.6.2.20120127215751.088caec0@resistor.net> In-Reply-To: <6.2.5.6.2.20120127215751.088caec0@resistor.net> 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 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 28 Jan 2012 06:28:10 -0000 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of S= M > Sent: Friday, January 27, 2012 10:14 PM > To: mile@ietf.org > Subject: Re: [mile] 6046-bis - Client certificate identity check >=20 > At 13:20 27-01-2012, Alexey Melnikov wrote: > >draft-ietf-mile-rfc6046-bis-09 looks good to me. One thing that can be > >improved is to say that the server that accepts a TCP connection would > >use reverse DNS lookup to retrieve the identity of the connecting > >server. "Stable DNS identity" doesn't quite say that to me. >=20 > DNS PTR is not that good as an identifier for security checks. These > DNS records are not always well-maintained. There was a network in the > Far East where the reverse DNS lookup was pointing to "localhost (this > was not for .0.0.127.in-addr.arpa). The dnsop WG had a draft some time ago, which they keep promising/threateni= ng to resurrect, that is basically a BCP against that practice. From sm@resistor.net Fri Jan 27 22:45: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 88E0D21F8542 for ; Fri, 27 Jan 2012 22:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 m8Q5iOJmaOCW for ; Fri, 27 Jan 2012 22:45:26 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8C421F852C for ; Fri, 27 Jan 2012 22:45:26 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0S6jKcJ004038 for ; Fri, 27 Jan 2012 22:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327733125; i=@resistor.net; bh=PB9MKGPCNHSOHwgmC1i5mjJz3xEjjJkOsxZkIVhhqqc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=dGetZggvn28CS+p2Cw9Ot7dJbqQ8YgsaMDDI1WK6Xi9+coGDfChToiBsNPGOT3vMA c2diXxKBa++frwPDX2oFQ88IEwWGbS86sScbo/3Qh2Dqt8Rm9aeI1DY2LUEfJzTblY gev6Ex63/NwW7U1lEFpWpDZe7uo/VDh4Jcyfecq4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327733125; i=@resistor.net; bh=PB9MKGPCNHSOHwgmC1i5mjJz3xEjjJkOsxZkIVhhqqc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=RbxpJQGFkl8g0msgKGZjOYLSbnLiC9N02uo5gSlfarvWQIQbUnF3lwJhawbBKhQFG aH3Ob645nyqUSqsUrOu5GUG4AYeXC2nb6ThEfgQSBLb1a5wOdkFWJoHVwVpnQDaqF3 rSXaGcN10HVhRDtjFa6+vCSW6VtNJSHRaW1uEVuk= Message-Id: <6.2.5.6.2.20120127224019.098d3e30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Jan 2012 22:44:33 -0800 To: mile@ietf.org From: SM In-Reply-To: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> <6.2.5.6.2.20120127215751.088caec0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 28 Jan 2012 06:45:27 -0000 At 22:28 27-01-2012, Murray S. Kucherawy wrote: >The dnsop WG had a draft some time ago, which they keep >promising/threatening to resurrect, that is basically a BCP against >that practice. I cannot recall whether it was that document or some RFC which has some material about the topic. BTW, there is a performance impact if the feature is enabled in a well-known web server implementation. Regards, -sm From msk@cloudmark.com Fri Jan 27 23:22: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 133F321F84B3 for ; Fri, 27 Jan 2012 23:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 3TOzvYAcmuSB for ; Fri, 27 Jan 2012 23:22:12 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5D121F8495 for ; Fri, 27 Jan 2012 23:22:12 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 23:22:11 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 27 Jan 2012 23:22:10 -0800 From: "Murray S. Kucherawy" To: "mile@ietf.org" Date: Fri, 27 Jan 2012 23:22:10 -0800 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczdiG080v3IyYmJTuGTvp82IXoRSQABQ9XQ Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> <6.2.5.6.2.20120127215751.088caec0@resistor.net> <6.2.5.6.2.20120127224019.098d3e30@resistor.net> In-Reply-To: <6.2.5.6.2.20120127224019.098d3e30@resistor.net> 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 Subject: Re: [mile] 6046-bis - Client certificate identity check 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, 28 Jan 2012 07:22:13 -0000 > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of S= M > Sent: Friday, January 27, 2012 10:45 PM > To: mile@ietf.org > Subject: Re: [mile] 6046-bis - Client certificate identity check >=20 > At 22:28 27-01-2012, Murray S. Kucherawy wrote: > >The dnsop WG had a draft some time ago, which they keep > >promising/threatening to resurrect, that is basically a BCP against > >that practice. >=20 > I cannot recall whether it was that document or some RFC which has some > material about the topic. You might be thinking about RFC5451, which did reference the dnsop draft. -MSK From presnick@qualcomm.com Fri Jan 27 16:35:52 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 85BC521F85A3 for ; Fri, 27 Jan 2012 16:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 SQUftKecRNKk for ; Fri, 27 Jan 2012 16:35:51 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C917021F85BE for ; Fri, 27 Jan 2012 16:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327710951; x=1359246951; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4F2342E1.3010101@qualcomm.com>|Date:=20Fr i,=2027=20Jan=202012=2018:35:45=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Peter=20Saint-Andre=20|CC:=20,=20,=20|Subject:=20Re:=20[mile] =20FW:=20=20IDN=20issue|References:=20<7C4DFCE962635144B8 FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com>=20<4F21B1E4. 6060304@stpeter.im>=20=20<4F21C468.9030104@stpeter. im>=20<7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.c orp.emc.com>=20<4F21DFF5.3070905@stpeter.im>|In-Reply-To: =20<4F21DFF5.3070905@stpeter.im>|Content-Type:=20multipar t/alternative=3B=0D=0A=09boundary=3D"------------06070605 0602090405010403"|X-Originating-IP:=20[172.30.39.5]; bh=FQWWlKqcMQ8kUoIPPB7D9CQnRUZmr09YmKW0Zt/tfvY=; b=cWtKBHA4SchJRveekCXDCaxcbwdZbkARZ3oqBFMY2hUCiOhqT5whVzqZ Sy9Ru9etn98SaJgIrjcwd9oJRTDlicUGAtn8w2qhb16Pf93BQddq7Fx10 yKnm0lhFwtqUklzgsqmzpzZ7rpVo9SnKIS9Dfv5IONFo/abHxRvaGcPf9 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6602"; a="156262461" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 27 Jan 2012 16:35:51 -0800 X-IronPort-AV: E=Sophos;i="4.71,580,1320652800"; d="scan'208,217";a="154326519" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 27 Jan 2012 16:35:51 -0800 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 27 Jan 2012 16:35:50 -0800 Message-ID: <4F2342E1.3010101@qualcomm.com> Date: Fri, 27 Jan 2012 18:35:45 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> In-Reply-To: <4F21DFF5.3070905@stpeter.im> Content-Type: multipart/alternative; boundary="------------060706050602090405010403" X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Sat, 28 Jan 2012 09:19:26 -0800 Cc: mile@ietf.org Subject: Re: [mile] FW: IDN issue 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, 28 Jan 2012 00:35:52 -0000 --------------060706050602090405010403 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 1/26/12 5:21 PM, Peter Saint-Andre wrote: >> RID systems are expected to obtain an IDN meeting these requirements >> by asking a DNS resolver to return an IDN that does not contain >> A-labels (even if the input IDN contains A-labels). >> >> ** Will that work? >> > I*think* so but I am going to complete a final sanity-check with my > co-AD to be sure. > > Pete: does that work for you? > Hmmmm....I'm not sure I even know what that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do you mean by "resolver" the entire API which takes a name and resolves it? I think that is a novel use of the term. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------060706050602090405010403 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 1/26/12 5:21 PM, Peter Saint-Andre wrote: 
        RID systems are expected to obtain an IDN meeting these requirements
        by asking a DNS resolver to return an IDN that does not contain
        A-labels (even if the input IDN contains A-labels).
 
 ** Will that work?
    
I *think* so but I am going to complete a final sanity-check with my
co-AD to be sure.

Pete: does that work for you?

Hmmmm....I'm not sure I even know what that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do you mean by "resolver" the entire API which takes a name and resolves it? I think that is a novel use of the term.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------060706050602090405010403-- From kathleen.moriarty@emc.com Sat Jan 28 10:02: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 3182821F84FD for ; Sat, 28 Jan 2012 10:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 dtZDfxm27GLT for ; Sat, 28 Jan 2012 10:02:42 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E823A21F84D2 for ; Sat, 28 Jan 2012 10:02:41 -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 q0SI2aM8011182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2012 13:02:37 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Sat, 28 Jan 2012 13:02:25 -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 q0SI2PNP003343; Sat, 28 Jan 2012 13:02:25 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Sat, 28 Jan 2012 13:02:25 -0500 From: To: , Date: Sat, 28 Jan 2012 13:02:23 -0500 Thread-Topic: [mile] 6046-bis - Client certificate identity check Thread-Index: AczdiG080v3IyYmJTuGTvp82IXoRSQABQ9XQABWdNtA= Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D917C2@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91813@MX14A.corp.emc.com> <35D05F86-6239-49C3-88AD-3237A144A6D3@tik.ee.ethz.ch> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D9186E@MX14A.corp.emc.com> <699A7BD6-15F4-46EE-84C7-64E6362E419F@tik.ee.ethz.ch> <4F21A7B6.9030603@isode.com> <4F21AABD.9060603@stpeter.im> <4F21B683.20604@isode.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91B8E@MX14A.corp.emc.com> <4F21DE17.10706@stpeter.im> <4F23153B.9060209@isode.com> <6.2.5.6.2.20120127215751.088caec0@resistor.net> <6.2.5.6.2.20120127224019.098d3e30@resistor.net> 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] 6046-bis - Client certificate identity check 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, 28 Jan 2012 18:02:48 -0000 I think we are good on this issue as going with a white list tied to the sh= aring profile for a peer or group (a cert for each peer in the group) is re= ally how the authentication will work. It is not that burdensome to mainta= in white lists for communities that go through legal processes to compare p= olicies and determine sharing arrangements in formal agreements to set up a= profile and tie certificates in a white list to the appropriate profile. = They will be worried about how markers trigger security protections for spe= cific profiles as well (even whether or not some data will get shared or wh= o it can be shared with). The DNS-ID is not where the authentication reall= y happens, this wouldn't match the security requirements for these systems. Brian proposed text to the document in Auth48, white list is the best optio= n to provide the security level needed for these highly sensitive systems. Thanks for the comments. =20 Thanks, Kathleen -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Saturday, January 28, 2012 2:22 AM To: mile@ietf.org Subject: Re: [mile] 6046-bis - Client certificate identity check > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of S= M > Sent: Friday, January 27, 2012 10:45 PM > To: mile@ietf.org > Subject: Re: [mile] 6046-bis - Client certificate identity check >=20 > At 22:28 27-01-2012, Murray S. Kucherawy wrote: > >The dnsop WG had a draft some time ago, which they keep > >promising/threatening to resurrect, that is basically a BCP against > >that practice. >=20 > I cannot recall whether it was that document or some RFC which has some > material about the topic. You might be thinking about RFC5451, which did reference the dnsop draft. -MSK _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Sat Jan 28 12:16:51 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 AB02C21F8591 for ; Sat, 28 Jan 2012 12:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.308 X-Spam-Level: X-Spam-Status: No, score=-109.308 tagged_above=-999 required=5 tests=[AWL=1.291, 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 RsIWKcs+TNMo for ; Sat, 28 Jan 2012 12:16:51 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1148C21F858E for ; Sat, 28 Jan 2012 12:16:49 -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 q0SKGmTO009637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2012 15:16:48 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 28 Jan 2012 15:16:37 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0SKGavI013845; Sat, 28 Jan 2012 15:16:37 -0500 Received: from mx14a.corp.emc.com ([169.254.1.94]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Sat, 28 Jan 2012 15:16:36 -0500 From: To: , Date: Sat, 28 Jan 2012 15:16:35 -0500 Thread-Topic: MAEC in SCI Thread-Index: AczdG/WfbxSslx+pRm2MmJUNJy7mRgA2c+jQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD13AA32@MX14A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 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: Sat, 28 Jan 2012 20:16:51 -0000 Tom, > Making any sense? Definitely - the Taipei meeting discussion of IANA considerations for the S= CI draft indicated that a single SCI specification could be appropriate to multiple = extension classes in, so it's great to have an actual example of that! =09 > 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, per= haps - MAEC in children of > EventData would be concerned with individual malware samples captured and= analyzed. Yes. If the MAEC usage explanation is put into the mile-sci draft, then th= e IANA registry entry for MAEC (in the new SCI registry to be created by the mile-= sci draft) would contain a reference to the mile-sci RFC, and that reference would ena= ble people to find the explanation of how to use MAEC with each applicable extension c= lass. For the future (RFCs can't be changed after publication), an informational = RFC could be used to contain such an explanation for an additional SCI specification (or= specifications), and that RFC would be referenced from the corresponding IANA registry entry= . It might be a good idea to add text to the mile-sci draft to suggest (or even require) = an informational RFC to explain usage distinctions when a single SCI specifica= tion is applicable to multiple extension classes. In contrast, putting that sort of explanation directly into an IANA registr= y is not a good idea. I just happen to be in the midst of working with IANA to clean s= ome other IANA registries; as part of that cleanup, IANA wants to take out an explana= tion of how something works. FWIW, IANA views their function as administrative, no= t technical. Does that sound reasonable? 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 ---------------------------------------------------- > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of T= homas.Millar@us-cert.gov > Sent: Friday, January 27, 2012 12:49 PM > To: mile@ietf.org > Subject: [mile] MAEC in SCI >=20 > I suggest we look at including MAEC in SCI. I believe the appropriate pla= ce 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 obs= ervables and such are better > reserved for EventData child classes. >=20 > 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, per= haps - MAEC in children of > EventData would be concerned with individual malware samples captured and= analyzed. >=20 > Making any sense? >=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 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Mon Jan 30 20:20: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 9A70A21F8753 for ; Mon, 30 Jan 2012 20:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.778 X-Spam-Level: X-Spam-Status: No, score=-9.778 tagged_above=-999 required=5 tests=[AWL=0.820, 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 dcaITh6LFUCe for ; Mon, 30 Jan 2012 20:20:19 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0C13921F8752 for ; Mon, 30 Jan 2012 20:20:18 -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 q0V4KAPQ026348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 23:20:15 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 30 Jan 2012 23:19:53 -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 q0V4JoWT025624; Mon, 30 Jan 2012 23:19:50 -0500 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub23.corp.emc.com (128.222.70.135) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 23:19:49 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Mon, 30 Jan 2012 23:19:49 -0500 From: To: Date: Mon, 30 Jan 2012 23:19:48 -0500 Thread-Topic: [mile] FW: IDN issue Thread-Index: Aczfx7fO00pMVvchS/qAXfu8QsDGnwABwzBw Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> <4F275E89.90209@qualcomm.com> In-Reply-To: <4F275E89.90209@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AE31510960917D478171C79369B660FA0E2C087B7FMX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] FW: IDN issue 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, 31 Jan 2012 04:20:22 -0000 --_000_AE31510960917D478171C79369B660FA0E2C087B7FMX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Pete. David Black had suggested that, so maybe he can help here. = I am just trying to make sure there is some way to address the concern. Th= e NodeName is only used since a DNS name looks nice, not for any type of ve= rification. They may be used in searches later if this data is stored with= the incident data. We of course want to handle internationalization. Thi= s will matter more if we go back and correct it with IODEF than in the docu= ment under review. Myself and others were confused on the use of a label that was not UTF-8 af= ter saying the XML schema must be represented in UTF-8. Apparently from on= e of Peter's messages, there is no need to be concerned there. I am not an= expert in this area and would like guidance so we can move beyond this iss= ue. Thanks, Kathleen From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Monday, January 30, 2012 10:23 PM To: Moriarty, Kathleen Cc: Black, David; stpeter@stpeter.im; mile@ietf.org; Sean Turner Subject: Re: [mile] FW: IDN issue So, I've never heard of a client API of this sort referred to as a "DNS res= olver", but maybe I'm just old and crusty. But I'm certainly not aware of s= uch client APIs that actually exist and are able to "return an IDN that doe= s not contain A-labels". If you all confirm that such APIs exist I'm fine w= ith it, but otherwise it is the equivalent of "magic IDN pixie dust gets sp= rinkled here". I'll leave it to Sean to decide whether you have appropriate= ly confirmed. (If there are APIs involved here, I'm not quite clear on why you care that = no A-labels appear in the Node class, since presumably those APIs are perfe= ctly capable of taking A-labels along with UTF-8 U-labels and NR-LDH labels= . But that seems to be what you decided on.) pr On 1/27/12 7:53 PM, kathleen.moriarty@emc.com wrote: Pete, Peter had suggested a tweak to the text that appears in -10, which should r= esolve the question. Here is the current text (see the last sentence): 11. Internationalization Issues The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. An application communicating via RID can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. RID systems are expected to obtain an IDN meeting these requirements by asking a DNS resolver to return an IDN that does not contain A-labels (even if the RID system's input to the DNS resolver contains A-labels). Let me know if that works. Thanks, Kathleen From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of david.black@emc.com Sent: Friday, January 27, 2012 7:39 PM To: presnick@qualcomm.com; stpeter@stpeter.im= Cc: mile@ietf.org Subject: Re: [mile] FW: IDN issue > Hmmmm....I'm not sure I even know what that means. As far as I know, DNS = resolvers deal in A-labels or NR-LDH labels, not U-labels. > Or do you mean by "resolver" the entire API which takes a name and resolv= es it? I think that is a novel use of the term. It's the entire client API. Thanks, --David From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Friday, January 27, 2012 7:36 PM To: Peter Saint-Andre Cc: Black, David; Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] FW: IDN issue On 1/26/12 5:21 PM, Peter Saint-Andre wrote: RID systems are expected to obtain an IDN meeting these requirement= s by asking a DNS resolver to return an IDN that does not contain A-labels (even if the input IDN contains A-labels). ** Will that work? I *think* so but I am going to complete a final sanity-check with my co-AD to be sure. Pete: does that work for you? Hmmmm....I'm not sure I even know what that means. As far as I know, DNS re= solvers deal in A-labels or NR-LDH labels, not U-labels. Or do you mean by = "resolver" the entire API which takes a name and resolves it? I think that = is a novel use of the term. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --_000_AE31510960917D478171C79369B660FA0E2C087B7FMX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Thanks, Pete.  David Black had suggested that, so maybe he can = help here.  I am just trying to make sure there is some way to address= the concern.  The NodeName is only used since a DNS name looks nice, = not for any type of verification.  They may be used in searches later = if this data is stored with the incident data.  We of course want to h= andle internationalization.  This will matter more if we go back and c= orrect it with IODEF than in the document under review.

 

Myself and others were confused on the use of a label that was n= ot UTF-8 after saying the XML schema must be represented in UTF-8.  Ap= parently from one of Peter’s messages, there is no need to be concern= ed there.  I am not an expert in this area and would like guidance so = we can move beyond this issue.

 

Thanks,

Kathleen

 

=  

From: Pete Resnick [mailto:presnick@qualcomm.com= ]
Sent: Monday, January 30, 2012 10:23 PM
To: Moriarty= , Kathleen
Cc: Black, David; stpeter@stpeter.im; mile@ietf.org; S= ean Turner
Subject: Re: [mile] FW: IDN issue

 

So, I've never heard of a client API of this sort referred to as a "D= NS resolver", but maybe I'm just old and crusty. But I'm certainly not= aware of such client APIs that actually exist and are able to "return= an IDN that does not contain A-labels". If you all confirm that such = APIs exist I'm fine with it, but otherwise it is the equivalent of "ma= gic IDN pixie dust gets sprinkled here". I'll leave it to Sean to deci= de whether you have appropriately confirmed.

(If there are APIs invo= lved here, I'm not quite clear on why you care that no A-labels appear in t= he Node class, since presumably those APIs are perfectly capable of taking = A-labels along with UTF-8 U-labels and NR-LDH labels. But that seems to be = what you decided on.)

pr

On 1/27/12 7:53 PM, kathleen.moriarty@emc.com wrote:

Pete,

 

Pete= r had suggested a tweak to the text that appears in -10, which should resol= ve the question.  Here is the current text (see the last sentence):

 

=

11.  Internationalization Issues

 

   The Node class identifies a host or network device.  T= his document

   re-use= s the definition of Node from the IODEF specification

=

   [RFC5070], Section 3.16.  However, = that document did not clearly

&n= bsp;  specify whether a NodeName could be an Internationalized Domain = Name

   (IDN).  R= ID systems MUST treat the NodeName class as a domain name=

   slot [RFC5890].  RID systems SH= OULD support IDNs in the NodeName

   MUST be used,= i.e., all of the domain name's labels MUST be U-labels

   expressed in UTF-8 or NR-LDH labels [R= FC5890]; A-labels MUST NOT be

&n= bsp;  used.  An application communicating via RID can convert bet= ween

   A-labels and U= -labels by using the Punycode encoding [RFC3492] for

<= p class=3DMsoNormal>   A-labels as described in the protocol spe= cification for

   Inte= rnationalized Domain Names in Applications [RFC5891].  RID=

   systems are expected to obtain= an IDN meeting these requirements by

   asking a DNS resolver to return an IDN that does not con= tain A-labels

   (even= if the RID system's input to the DNS resolver contains

   A-labels).

 

 

Let me know if t= hat works.

 

Thanks,

Kathleen

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From:<= /b> mile-bounces@ietf.org= [mailto:mile-bounces@ietf.org= ] On Behalf Of david.blac= k@emc.com
Sent: Friday, January 27, 2012 7:39 PM
To: presnick@qualcomm.com; stpeter@stpeter.im
Cc: mile@ietf.org
Subject: Re: [mile]= FW: IDN issue

 =

> Hmmmm....I'm not sure I even know = what that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH= labels, not U-labels.

> Or do you me= an by "resolver" the entire API which takes a name and resolves i= t? I think that is a novel use of the term.

 

It’s the entire client = API.

 

Thanks,
--= David

 

From: Pete Resnick [= mailto:presnick@qualcomm.com] =
Sent: Friday, January 27, 2012 7:36 PM
To: Peter Saint= -Andre
Cc: Black, David; Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] FW: IDN issue<= /span>

 

=

On 1/26/12 5:21 PM, Peter Saint-Andre wrote: 

 =
;       RID systems are expected to obta=
in an IDN meeting these requirements
   =
;     by asking a DNS resolver to return an IDN that do=
es not contain
      &nb=
sp; A-labels (even if the input IDN contains A-labels).
 ** Will that work?
&n=
bsp;   
I *think* so but I=
 am going to complete a final sanity-check with my
co-=
AD to be sure.
 
Pete: does =
that work for you?
 


Hmmmm....I'm not sure I even k= now what that means. As far as I know, DNS resolvers deal in A-labels or NR= -LDH labels, not U-labels. Or do you mean by "resolver" the entir= e API which takes a name and resolves it? I think that is a novel use of th= e term.

pr

-- 
Pete Resnick =
<http://www.qualcomm.co=
m/~presnick/>
Qualcomm Incorporated - Direct ph=
one: (858)651-4478, Fax: (858)651-1102



-- 
Pete Resnick <http://www.qualcomm.com/~p=
resnick/>
Qualcomm Incorporated - Direct phone:=
 (858)651-4478, Fax: (858)651-1102
= --_000_AE31510960917D478171C79369B660FA0E2C087B7FMX06Acorpemcc_-- From presnick@qualcomm.com Mon Jan 30 19:22: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 83D5E21F8763 for ; Mon, 30 Jan 2012 19:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 KsazzQmjQeEn for ; Mon, 30 Jan 2012 19:22:54 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4A321F8760 for ; Mon, 30 Jan 2012 19:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327980173; x=1359516173; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4F275E89.90209@qualcomm.com>|Date:=20Mon, =2030=20Jan=202012=2021:22:49=20-0600|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20 |CC:=20,=20,=20< mile@ietf.org>,=20Sean=20Turner=0D=0A=09|Subject:=20Re:=20[mile]=20FW:=20=20IDN=20issue |References:=20<7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918D C@MX14A.corp.emc.com>=09<4F21B1E4.6060304@stpeter.im>=09< AE31510960917D478171C79369B660FA0E2C087513@MX06A.corp.emc .com>=09<4F21C468.9030104@stpeter.im>=09<7C4DFCE962635144 B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com>=09<4F21DFF 5.3070905@stpeter.im>=20<4F2342E1.3010101@qualcomm.com> =20<7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp .emc.com>=20|In-Reply-To:=20|Content-Type:=20 multipart/alternative=3B=0D=0A=09boundary=3D"------------ 000409000701060202030603"|X-Originating-IP:=20[172.30.39. 5]; bh=VRBwMuFic9LksgAVaDTkzyLexD0QEX5AtpkFRkncvLk=; b=vlGBGKdvotZnebKkZ4WOR8Wg5tYuU40zz5he/xJp6uSlloEgizfVmf1V D39I9RV/cBK2h7lnaaS612IjmPE0t+nkcHW4xLhHsL2bigKP93w9Bj0mI knEGjDsEpIWaXzyyAlE2jSw19e14sGrEVY3Weu3w0hMpjjcVQTQdqHbRc I=; X-IronPort-AV: E=McAfee;i="5400,1158,6605"; a="156868809" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 30 Jan 2012 19:22:53 -0800 X-IronPort-AV: E=Sophos;i="4.71,592,1320652800"; d="scan'208,217";a="193220843" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 30 Jan 2012 19:22:53 -0800 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 30 Jan 2012 19:22:52 -0800 Message-ID: <4F275E89.90209@qualcomm.com> Date: Mon, 30 Jan 2012 21:22:49 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000409000701060202030603" X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Mon, 30 Jan 2012 23:40:28 -0800 Cc: mile@ietf.org Subject: Re: [mile] FW: IDN issue 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, 31 Jan 2012 03:22:58 -0000 --------------000409000701060202030603 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit So, I've never heard of a client API of this sort referred to as a "DNS resolver", but maybe I'm just old and crusty. But I'm certainly not aware of such client APIs that actually exist and are able to "return an IDN that does not contain A-labels". If you all confirm that such APIs exist I'm fine with it, but otherwise it is the equivalent of "magic IDN pixie dust gets sprinkled here". I'll leave it to Sean to decide whether you have appropriately confirmed. (If there are APIs involved here, I'm not quite clear on why you care that no A-labels appear in the Node class, since presumably those APIs are perfectly capable of taking A-labels along with UTF-8 U-labels and NR-LDH labels. But that seems to be what you decided on.) pr On 1/27/12 7:53 PM, kathleen.moriarty@emc.com wrote: > > Pete, > > Peter had suggested a tweak to the text that appears in -10, which > should resolve the question. Here is the current text (see the last > sentence): > > 11. Internationalization Issues > > The Node class identifies a host or network device. This document > > re-uses the definition of Node from the IODEF specification > > [RFC5070], Section 3.16. However, that document did not clearly > > specify whether a NodeName could be an Internationalized Domain Name > > (IDN). RID systems MUST treat the NodeName class as a domain name > > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > > class; if they do so, the UTF-8 representation of the domain name > > MUST be used, i.e., all of the domain name's labels MUST be U-labels > > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > > used. An application communicating via RID can convert between > > A-labels and U-labels by using the Punycode encoding [RFC3492] for > > A-labels as described in the protocol specification for > > Internationalized Domain Names in Applications [RFC5891]. RID > > systems are expected to obtain an IDN meeting these requirements by > > asking a DNS resolver to return an IDN that does not contain A-labels > > (even if the RID system's input to the DNS resolver contains > > A-labels). > > Let me know if that works. > > Thanks, > > Kathleen > > *From:* mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] *On > Behalf Of *david.black@emc.com > *Sent:* Friday, January 27, 2012 7:39 PM > *To:* presnick@qualcomm.com; stpeter@stpeter.im > *Cc:* mile@ietf.org > *Subject:* Re: [mile] FW: IDN issue > > > Hmmmm....I'm not sure I even know what that means. As far as I know, > DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. > > > Or do you mean by "resolver" the entire API which takes a name and > resolves it? I think that is a novel use of the term. > > It's the entire client API. > > Thanks, > --David > > *From:* Pete Resnick [mailto:presnick@qualcomm.com] > *Sent:* Friday, January 27, 2012 7:36 PM > *To:* Peter Saint-Andre > *Cc:* Black, David; Moriarty, Kathleen; mile@ietf.org > *Subject:* Re: [mile] FW: IDN issue > > On 1/26/12 5:21 PM, Peter Saint-Andre wrote: > > RID systems are expected to obtain an IDN meeting these requirements > > by asking a DNS resolver to return an IDN that does not contain > > A-labels (even if the input IDN contains A-labels). > > > > ** Will that work? > > > > I****think** so but I am going to complete a final sanity-check with my > co-AD to be sure. > > Pete: does that work for you? > > > > Hmmmm....I'm not sure I even know what that means. As far as I know, > DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do > you mean by "resolver" the entire API which takes a name and resolves > it? I think that is a novel use of the term. > > pr > > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------000409000701060202030603 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit So, I've never heard of a client API of this sort referred to as a "DNS resolver", but maybe I'm just old and crusty. But I'm certainly not aware of such client APIs that actually exist and are able to "return an IDN that does not contain A-labels". If you all confirm that such APIs exist I'm fine with it, but otherwise it is the equivalent of "magic IDN pixie dust gets sprinkled here". I'll leave it to Sean to decide whether you have appropriately confirmed.

(If there are APIs involved here, I'm not quite clear on why you care that no A-labels appear in the Node class, since presumably those APIs are perfectly capable of taking A-labels along with UTF-8 U-labels and NR-LDH labels. But that seems to be what you decided on.)

pr

On 1/27/12 7:53 PM, kathleen.moriarty@emc.com wrote:

Pete,

 

Peter had suggested a tweak to the text that appears in -10, which should resolve the question.  Here is the current text (see the last sentence):

 

11.  Internationalization Issues

 

   The Node class identifies a host or network device.  This document

   re-uses the definition of Node from the IODEF specification

   [RFC5070], Section 3.16.  However, that document did not clearly

   specify whether a NodeName could be an Internationalized Domain Name

   (IDN).  RID systems MUST treat the NodeName class as a domain name

   slot [RFC5890].  RID systems SHOULD support IDNs in the NodeName

   class; if they do so, the UTF-8 representation of the domain name

   MUST be used, i.e., all of the domain name's labels MUST be U-labels

   expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be

   used.  An application communicating via RID can convert between

   A-labels and U-labels by using the Punycode encoding [RFC3492] for

   A-labels as described in the protocol specification for

   Internationalized Domain Names in Applications [RFC5891].  RID

   systems are expected to obtain an IDN meeting these requirements by

   asking a DNS resolver to return an IDN that does not contain A-labels

   (even if the RID system's input to the DNS resolver contains

   A-labels).

 

 

Let me know if that works.

 

Thanks,

Kathleen

 

From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of david.black@emc.com
Sent: Friday, January 27, 2012 7:39 PM
To: presnick@qualcomm.com; stpeter@stpeter.im
Cc: mile@ietf.org
Subject: Re: [mile] FW: IDN issue

 

> Hmmmm....I'm not sure I even know what that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH labels, not U-labels.

> Or do you mean by "resolver" the entire API which takes a name and resolves it? I think that is a novel use of the term.

 

It’s the entire client API.

 

Thanks,
--David

 

From: Pete Resnick [mailto:presnick@qualcomm.com]
Sent: Friday, January 27, 2012 7:36 PM
To: Peter Saint-Andre
Cc: Black, David; Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] FW: IDN issue

 

On 1/26/12 5:21 PM, Peter Saint-Andre wrote: 

        RID systems are expected to obtain an IDN meeting these requirements
        by asking a DNS resolver to return an IDN that does not contain
        A-labels (even if the input IDN contains A-labels).
 
 ** Will that work?
    
I *think* so but I am going to complete a final sanity-check with my
co-AD to be sure.
 
Pete: does that work for you?
 


Hmmmm....I'm not sure I even know what that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do you mean by "resolver" the entire API which takes a name and resolves it? I think that is a novel use of the term.

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------000409000701060202030603-- From trammell@tik.ee.ethz.ch Tue Jan 31 00:26: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 038E621F873A for ; Tue, 31 Jan 2012 00:26:33 -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 Terw1OP-jC3M for ; Tue, 31 Jan 2012 00:26:31 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 965C221F872E for ; Tue, 31 Jan 2012 00:26:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 55FADD9305; Tue, 31 Jan 2012 09:26:29 +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 0AvzgpD11aMP; Tue, 31 Jan 2012 09:26:29 +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 E46BCD9304; Tue, 31 Jan 2012 09:26:28 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell In-Reply-To: Date: Tue, 31 Jan 2012 09:26:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5917806F-0F95-4C1D-9897-335F0BEF1E5A@tik.ee.ethz.ch> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> <4F275E89.90209@qualcomm.com> To: X-Mailer: Apple Mail (2.1084) Cc: presnick@qualcomm.com, mile@ietf.org Subject: Re: [mile] FW: IDN issue 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, 31 Jan 2012 08:26:33 -0000 Hi, Kathleen, Pete, all, Thought I'd jump in as a random guy off the street again. It seems to me that the concern here is the last sentence: =20 RID systems are expected to obtain an IDN meeting these requirements by asking a DNS resolver to return an IDN that does not contain A-labels (even if the RID system's input to the DNS resolver contains A-labels). which presupposes the existence of an API in the (stub?) resolver that 1. can be forced to return a U-label for a given query; or 2. that returns a U-label for a given A-label. I have done precisely zero work with IDN support as an implementor, so I = wouldn't even know where to start looking to verify that. It seems to me = to be reasonable to assume such a thing exists, but I'm teaching myself = C++ these days so am very, very wary of "reasonable assumption" and = "API" appearing in the same sentence. Also, if you've never heard of = such a thing, well, I consider that a data point right there. However, what's important is not the existence of an API, but the = existence of a clearly defined algorithm for the conversion between = A-labels and U-labels. That we _do_ have. So, how about just dropping = the last sentence? The relevant language is then: ... RID systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. An application communicating via RID can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891]. With respect to intent, it seems to me that NodeName (as well as Node) = should contain identifiers for nodes suitable for presentation; that is = (my reading of) the rationale behind the WG decision to deny the use of = Punycode labels in RID documents. Best regards, Brian On Jan 31, 2012, at 5:19 AM, = wrote: > Thanks, Pete. David Black had suggested that, so maybe he can help = here. I am just trying to make sure there is some way to address the = concern. The NodeName is only used since a DNS name looks nice, not for = any type of verification. They may be used in searches later if this = data is stored with the incident data. We of course want to handle = internationalization. This will matter more if we go back and correct = it with IODEF than in the document under review. > =20 > Myself and others were confused on the use of a label that was not = UTF-8 after saying the XML schema must be represented in UTF-8. = Apparently from one of Peter=92s messages, there is no need to be = concerned there. I am not an expert in this area and would like = guidance so we can move beyond this issue. > =20 > Thanks, > Kathleen > =20 > =20 > From: Pete Resnick [mailto:presnick@qualcomm.com]=20 > Sent: Monday, January 30, 2012 10:23 PM > To: Moriarty, Kathleen > Cc: Black, David; stpeter@stpeter.im; mile@ietf.org; Sean Turner > Subject: Re: [mile] FW: IDN issue > =20 > So, I've never heard of a client API of this sort referred to as a = "DNS resolver", but maybe I'm just old and crusty. But I'm certainly not = aware of such client APIs that actually exist and are able to "return an = IDN that does not contain A-labels". If you all confirm that such APIs = exist I'm fine with it, but otherwise it is the equivalent of "magic IDN = pixie dust gets sprinkled here". I'll leave it to Sean to decide whether = you have appropriately confirmed. >=20 > (If there are APIs involved here, I'm not quite clear on why you care = that no A-labels appear in the Node class, since presumably those APIs = are perfectly capable of taking A-labels along with UTF-8 U-labels and = NR-LDH labels. But that seems to be what you decided on.) >=20 > pr >=20 > On 1/27/12 7:53 PM, kathleen.moriarty@emc.com wrote: > Pete, > =20 > Peter had suggested a tweak to the text that appears in -10, which = should resolve the question. Here is the current text (see the last = sentence): > =20 > 11. Internationalization Issues > =20 > The Node class identifies a host or network device. This document > re-uses the definition of Node from the IODEF specification > [RFC5070], Section 3.16. However, that document did not clearly > specify whether a NodeName could be an Internationalized Domain = Name > (IDN). RID systems MUST treat the NodeName class as a domain name > slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name > MUST be used, i.e., all of the domain name's labels MUST be = U-labels > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > used. An application communicating via RID can convert between > A-labels and U-labels by using the Punycode encoding [RFC3492] for > A-labels as described in the protocol specification for > Internationalized Domain Names in Applications [RFC5891]. RID > systems are expected to obtain an IDN meeting these requirements by > asking a DNS resolver to return an IDN that does not contain = A-labels > (even if the RID system's input to the DNS resolver contains > A-labels). > =20 > =20 > Let me know if that works. > =20 > Thanks, > Kathleen > =20 > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of david.black@emc.com > Sent: Friday, January 27, 2012 7:39 PM > To: presnick@qualcomm.com; stpeter@stpeter.im > Cc: mile@ietf.org > Subject: Re: [mile] FW: IDN issue > =20 > > Hmmmm....I'm not sure I even know what that means. As far as I know, = DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. > > Or do you mean by "resolver" the entire API which takes a name and = resolves it? I think that is a novel use of the term. > =20 > It=92s the entire client API. > =20 > Thanks, > --David > =20 > From: Pete Resnick [mailto:presnick@qualcomm.com]=20 > Sent: Friday, January 27, 2012 7:36 PM > To: Peter Saint-Andre > Cc: Black, David; Moriarty, Kathleen; mile@ietf.org > Subject: Re: [mile] FW: IDN issue > =20 > On 1/26/12 5:21 PM, Peter Saint-Andre wrote: > RID systems are expected to obtain an IDN meeting these = requirements > by asking a DNS resolver to return an IDN that does not = contain > A-labels (even if the input IDN contains A-labels). > =20 > ** Will that work? > =20 > I *think* so but I am going to complete a final sanity-check with my > co-AD to be sure. > =20 > Pete: does that work for you? > =20 >=20 > Hmmmm....I'm not sure I even know what that means. As far as I know, = DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do you = mean by "resolver" the entire API which takes a name and resolves it? I = think that is a novel use of the term. >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: = (858)651-1102 >=20 >=20 > --=20 > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: = (858)651-1102 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From turners@ieca.com Tue Jan 31 08:29: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 1153F21F858A for ; Tue, 31 Jan 2012 08:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.894 X-Spam-Level: X-Spam-Status: No, score=-100.894 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 q+D067vJJ-qX for ; Tue, 31 Jan 2012 08:29:36 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [64.5.50.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCA21F8585 for ; Tue, 31 Jan 2012 08:29:36 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 2191A9EEFB6B0; Tue, 31 Jan 2012 10:29:35 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 15CB39EEFB674 for ; Tue, 31 Jan 2012 10:29:35 -0600 (CST) Received: from [166.137.14.138] (port=44942 helo=[10.129.224.77]) by gator1743.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RsGaK-0004t0-IV; Tue, 31 Jan 2012 10:29:33 -0600 References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> <4F275E89.90209@qualcomm.com> <5917806F-0F95-4C1D-9897-335F0BEF1E5A@tik.ee.ethz.ch> In-Reply-To: <5917806F-0F95-4C1D-9897-335F0BEF1E5A@tik.ee.ethz.ch> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-67FD73A8-AF06-4160-9F9B-96AA03B81D31; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPhone Mail (9A405) From: Sean Turner Date: Tue, 31 Jan 2012 10:29:27 -0600 To: Brian Trammell , kathleen.moriarty@emc.com 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: ([10.129.224.77]) [166.137.14.138]:44942 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: Pete Resnick , "mile@ietf.org" Subject: Re: [mile] FW: IDN issue 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, 31 Jan 2012 16:29:37 -0000 --Apple-Mail-67FD73A8-AF06-4160-9F9B-96AA03B81D31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To resolve this please delete the last sentence. Spt Sent from my iPhone On Jan 31, 2012, at 2:26 AM, Brian Trammell wrote:= > Hi, Kathleen, Pete, all, >=20 > Thought I'd jump in as a random guy off the street again. >=20 > It seems to me that the concern here is the last sentence: >=20 > RID > systems are expected to obtain an IDN meeting these requirements by > asking a DNS resolver to return an IDN that does not contain A-labels > (even if the RID system's input to the DNS resolver contains > A-labels). >=20 > which presupposes the existence of an API in the (stub?) resolver that >=20 > 1. can be forced to return a U-label for a given query; or > 2. that returns a U-label for a given A-label. >=20 > I have done precisely zero work with IDN support as an implementor, so I w= ouldn't even know where to start looking to verify that. It seems to me to b= e reasonable to assume such a thing exists, but I'm teaching myself C++ thes= e days so am very, very wary of "reasonable assumption" and "API" appearing i= n the same sentence. Also, if you've never heard of such a thing, well, I co= nsider that a data point right there. >=20 > However, what's important is not the existence of an API, but the existenc= e of a clearly defined algorithm for the conversion between A-labels and U-l= abels. That we _do_ have. So, how about just dropping the last sentence? The= relevant language is then: >=20 > .... RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name > MUST be used, i.e., all of the domain name's labels MUST be U-labels > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > used. An application communicating via RID can convert between > A-labels and U-labels by using the Punycode encoding [RFC3492] for > A-labels as described in the protocol specification for > Internationalized Domain Names in Applications [RFC5891]. >=20 > With respect to intent, it seems to me that NodeName (as well as Node) sho= u --Apple-Mail-67FD73A8-AF06-4160-9F9B-96AA03B81D31 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFZTCCBWEw ggRJoAMCAQICEE/FgaFyQdyPCzx4n2cZ9yAwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTQwMDAwMDBaFw0x MjEwMTMyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtTZWFuIFR1cm5lcjEfMB0GCSqGSIb3DQEJARYQdHVybmVyc0BpZWNhLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALxkpJ1QrW25eQA6B42YT2xlTZsiFKEo O5TK4fGwi8P/TeqVY1S0QJiOGKKxZMyifeT1P/wCh2bmULTnZDUWVEYMMwLC23T+udDEoxIg4ecd tC2R3JHU5juQHM6C4gBxrNyLVztSE66jOHC8O97/q48Iqxa8N7Zl88csmWqn1Cf1WfqsYxoZiflI oJX2bAdkRMJtS0XV/MwMx1Chl76Y1gC2Q2QDO9SnIBAZuYtkFT59Ck7RLvX3fW4G3ul/A+FPbzMK uiMYp1Agd6todXsi02W0iYMeya7l5p+EyF/QL73/aA9XL73gyNAmB+BUc507V/HBvi1TUIYea17Q GDKo3McCAwEAAaOB6DCB5TAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9uZTBQBgNVHR8E STBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRD MURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQADggEBACzRt5PT1zCgv4bii3a8Htl7GQ7N rIkQbEXTIB5Qsk5NQ78Nywtjx9tzTBvxZ36LJNMfgV55rLRalzo3nXzAe5JT63DfbU2gnsDGXSt4 EPPPaL6BmcxlJqdxWucIVeLvsKhzdij+DIwjm06ysGFtNXRv8DBQ6VATcAoB5E9x0LIuW+xde9XE 3rk9lVLpCkLxaciqm4ujNPmiciukR0IKZa6gGQqCKXp7gAa7d+mgXSdVqYAF52HqQxihvs7012ai TRiRICecM/LaBzvX5KQdNEmmKPxl9LxVksc+QkJ5IsSOAm84NUV44xTWXYzJtjuJPdQatdfrbnL9 /6yRz3FDv0ExggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEczAhBPxYGhckHcjws8eJ9nGfcgMAkGBSsOAwIaBQCgggJtMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEzMTE2MjkzMVowIwYJKoZI hvcNAQkEMRYEFLPK2S/vXre1TaUGliiW+VWDG7dLMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/FgaFyQdyP Czx4n2cZ9yAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPxYGhckHcjws8eJ9nGfcgMA0GCSqGSIb3DQEB AQUABIIBAD7dEX3mlzLaeHqNA5IVWaIePPeZT2vDPNW3Wz1xeopwilCowwkzQlGuCxmnQV6OaZV1 vsg/HYtOjcaZ5pB3KPqo2orcihR7IK9iVleNS/vvDhrT/x5sQ5MdT11VpeyoEwtYK+Y7OHQaa6dZ dvdwbdL6MIRwMOVqaS5uTSRGuLDq2vHu9TtaQB9/vtOFgY8jAujxq33E+fOsp9ro5WP8SE8isFGw JlJ3UaWC1WGVV2JdwHC7VR3xEzob2GXCcSKoIcxOlSBleXtgOP7RqudOVykK5Otx0k5qv7UPcBvL TbxQ+x6IlKMbbgMHc0EP1pJMXzGXwUPjrWOt9T8ETeFLfgoAAAAAAAA= --Apple-Mail-67FD73A8-AF06-4160-9F9B-96AA03B81D31-- From kathleen.moriarty@emc.com Tue Jan 31 08:33: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 A278A11E80BD for ; Tue, 31 Jan 2012 08:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.791 X-Spam-Level: X-Spam-Status: No, score=-9.791 tagged_above=-999 required=5 tests=[AWL=0.808, 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 JqFrm0FOHk6w for ; Tue, 31 Jan 2012 08:33:10 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id C9BE421F858D for ; Tue, 31 Jan 2012 08:33:09 -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 q0VGX2qY003594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 11:33:04 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 31 Jan 2012 11:32:42 -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 q0VGWgOj024771; Tue, 31 Jan 2012 11:32:42 -0500 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub01.corp.emc.com (10.254.141.103) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 31 Jan 2012 11:32:42 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Tue, 31 Jan 2012 11:32:41 -0500 From: To: , Date: Tue, 31 Jan 2012 11:32:39 -0500 Thread-Topic: [mile] FW: IDN issue Thread-Index: AczgNbPS9ZfvhM05RQicu8n1HQQ9+gAACo6w Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> <4F275E89.90209@qualcomm.com> <5917806F-0F95-4C1D-9897-335F0BEF1E5A@tik.ee.ethz.ch> 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/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0036_01CCE00C.09FEBAA0" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: presnick@qualcomm.com, mile@ietf.org Subject: Re: [mile] FW: IDN issue 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, 31 Jan 2012 16:33:10 -0000 ------=_NextPart_000_0036_01CCE00C.09FEBAA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you. Will this happen in Auth48 or should I post a new version? Best regards, Kathleen -----Original Message----- From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, January 31, 2012 11:29 AM To: Brian Trammell; Moriarty, Kathleen Cc: Pete Resnick; mile@ietf.org Subject: Re: [mile] FW: IDN issue To resolve this please delete the last sentence. Spt Sent from my iPhone On Jan 31, 2012, at 2:26 AM, Brian Trammell wrote: > Hi, Kathleen, Pete, all, > > Thought I'd jump in as a random guy off the street again. > > It seems to me that the concern here is the last sentence: > > RID > systems are expected to obtain an IDN meeting these requirements by > asking a DNS resolver to return an IDN that does not contain A-labels > (even if the RID system's input to the DNS resolver contains > A-labels). > > which presupposes the existence of an API in the (stub?) resolver that > > 1. can be forced to return a U-label for a given query; or > 2. that returns a U-label for a given A-label. > > I have done precisely zero work with IDN support as an implementor, so I > wouldn't even know where to start looking to verify that. It seems to me to > be reasonable to assume such a thing exists, but I'm teaching myself C++ > these days so am very, very wary of "reasonable assumption" and "API" > appearing in the same sentence. Also, if you've never heard of such a thing, > well, I consider that a data point right there. > > However, what's important is not the existence of an API, but the existence > of a clearly defined algorithm for the conversion between A-labels and > U-labels. That we _do_ have. So, how about just dropping the last sentence? > The relevant language is then: > > .... RID systems SHOULD support IDNs in the NodeName > class; if they do so, the UTF-8 representation of the domain name > MUST be used, i.e., all of the domain name's labels MUST be U-labels > expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be > used. An application communicating via RID can convert between > A-labels and U-labels by using the Punycode encoding [RFC3492] for > A-labels as described in the protocol specification for > Internationalized Domain Names in Applications [RFC5891]. > > With respect to intent, it seems to me that NodeName (as well as Node) shou ------=_NextPart_000_0036_01CCE00C.09FEBAA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXyDCCAucw ggJQAgEBMA0GCSqGSIb3DQEBBQUAMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5l dHdvcmsxFzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAz IFBvbGljeSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2Vy dC5jb20vMSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTAeFw05OTA2MjYwMDIyMzNa Fw0xOTA2MjYwMDIyMzNaMIG7MSQwIgYDVQQHExtWYWxpQ2VydCBWYWxpZGF0aW9uIE5ldHdvcmsx FzAVBgNVBAoTDlZhbGlDZXJ0LCBJbmMuMTUwMwYDVQQLEyxWYWxpQ2VydCBDbGFzcyAzIFBvbGlj eSBWYWxpZGF0aW9uIEF1dGhvcml0eTEhMB8GA1UEAxMYaHR0cDovL3d3dy52YWxpY2VydC5jb20v MSAwHgYJKoZIhvcNAQkBFhFpbmZvQHZhbGljZXJ0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA45hRlhzo1bEGgWpXw3J1k6vPnqb88xZS1i1NnzVEqC4ETQdJijgp9Xc357erXd82cRSZ j9zCkvHnYJKX7NhI3L/BAiDGJKQoTDBadm2xXPPd3p4QcaGIx1ubQW3KsLiOFe6tMyvPRwRcdXEK mCSYKadJWaXd+LdDYmHz0+LQVT8CAwEAATANBgkqhkiG9w0BAQUFAAOBgQBWuwJYhGcILN8f23tJ M/XTZ530tAoQs8nFLOKSanF4J/Jwg0LTPs+pVPTx2JIWjNEEy0uryZ9FrjyKqbBxM13IxVffr6g1 s3+Jh+noJZK4f4V6rta8HjdYKmfJkc8qgT7txjnfwD4ZnBnME02CQbWM3uA9YAggD0V+a6J/o4wV 7jCCA0owggKzoAMCAQICEQCF0rUegZb8S2Ojz7ayWLN8MA0GCSqGSIb3DQEBBQUAMGwxGjAYBgNV BAoTEVJTQSBTZWN1cml0eSBJbmMuMR4wHAYDVQQDExVSU0EgUHVibGljIFJvb3QgQ0EgdjExLjAs BgkqhkiG9w0BCQEWH3JzYWtlb25yb290c2lnbkByc2FzZWN1cml0eS5jb20wHhcNMDcwNDE5MTgw MjE5WhcNMTIwNDMwMDkyODA3WjCBgjEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNV BAsTDEtDQSBTZXJ2aWNlczEWMBQGA1UEAxMNUlNBIENvcnBvcmF0ZTEQMA4GA1UEBxMHQmVkZm9y ZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAKpzsPO+pT6TE5Eqq6s6RDjf+tPTwyxIZll+LZAtfQB53g2qHrS9u+xrWGFwQoID 9hPrOujDdXHFl8gKX1owmZCB3qTwtPDVSNSUXG1Ylt5MC8ww9sOU/UCXMi+VdaTfy0HcWoTOek4i 3l5T4iXpHZk3SaKPuT8OG0FPjMU6lEZPAgMBAAGjgdQwgdEwHwYDVR0jBBgwFoAU9UwxelEDPyzX i5eZb6hxkKt4PZswHQYDVR0OBBYEFO2RCGt0t1lKkvahHSJwJp8KrxaSMG4GA1UdHwRnMGUwY6Bh oF+GXWh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3Byb2R1Y3RzL2tlb24vcmVwb3NpdG9yeS9j ZXJ0aWZpY2F0ZV9zdGF0dXMvUlNBX1B1YmxpY19Sb290X0NBLmNybDAPBgNVHRMECDAGAQH/AgED MA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQUFAAOBgQB+pa6IMm7ZbLsWDOJnxH8zhiYsuITN QeLHF6M1D6PM5c41JAeYJhDoismCrFRUiyc/zexgtPolCH1MibV2ryotD6yRTn+EkyjnuTNDYNtO Sq5sLnJWXvAO9H1J2UQVGCSPlF1ohR0mcgizSnYyjWFtOQeG9W+j9u2qhu0Y2RkJdTCCA3QwggLd oAMCAQICECcs0ZC+gWpc+GPF94hcIhYwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlD ZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsT LFZhbGlDZXJ0IENsYXNzIDMgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExho dHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29t MB4XDTA1MDUwMjE3MzQ0OFoXDTE5MDQzMDA5MjQwMFowbDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5 IEluYy4xHjAcBgNVBAMTFVJTQSBQdWJsaWMgUm9vdCBDQSB2MTEuMCwGCSqGSIb3DQEJARYfcnNh a2VvbnJvb3RzaWduQHJzYXNlY3VyaXR5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA tHUlWthEO+NBsaoiCrBwE0+H/F2MFFNt6c0XuVuiFabeI5MA1pIJ703D+jPDw+DnyuiJmpeIQB/3 Nyv3VCB+2MkGURgBOWNuxuZJWWConXBZa32rrYFREte9DCyhZiaspthVgH1Tom12rUXMOwdEvpj/ eNOIyA/zGiKUV5B+SY8CAwEAAaOBxjCBwzAdBgNVHQ4EFgQU9UwxelEDPyzXi5eZb6hxkKt4PZsw bAYDVR0fBGUwYzBhoF+gXYZbaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9WYWxpY2VydF9Sb290X0NBLmNybDAMBgNV HRMEBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAWBgNVHSAEDzANMAsGCSqGSIb3DQUGATANBgkqhkiG 9w0BAQUFAAOBgQCbGVhgT1RpnMZsB+bzPcareq9Y40BOOMzhTYMJV6dGEetObLOUo5FZcseFrYys 0qyOITy4VSTeX+vRezcTUDH+ufDJJMd1b+vqKxLxxaiMPx8eLqpnQUaR8v3HJGgXBKoSX3sOyFBU vuCkawAhGRZwXmmUJUx/Ce1Kk04U+wctsTCCA9IwggM7oAMCAQICEDo2dj76iEMMSIgFq3bhuL4w DQYJKoZIhvcNAQEFBQAwgYIxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxL Q0EgU2VydmljZXMxFjAUBgNVBAMTDVJTQSBDb3Jwb3JhdGUxEDAOBgNVBAcTB0JlZGZvcmQxFjAU BgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTMB4XDTA3MDUxMDIxNDE1OVoXDTEyMDMz MDA5MzEwNFowgYwxGjAYBgNVBAoTEVJTQSBTZWN1cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2Vy dmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBlcnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3Jk MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApEfcomm8kaOvjcAt0pfMD7lIgQ96z7BDTY1780m0wMlwPKQw53Z5QGtZy1IUjIL5 /INbGDHdAafgtf5iOTxVGfI7pFCvecrfkytui4TPzOUVKvxCDXQw3Vs4PY3uPfCuqBn8lkehE0iW yKw3uakHCwgAbPRNoFSm+2fxcBaNwvUCAwEAAaOCATswggE3MA8GA1UdEwQIMAYBAf8CAQIwgZIG A1UdIASBijCBhzCBhAYJKoZIhvcNBQcCMHcwLgYIKwYBBQUHAgEWImh0dHA6Ly9jYS5yc2FzZWN1 cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFSU0EgU2VjdXJpdHkgSW5jLjADAgEB Gh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8v Y3JsLnJzYXNlY3VyaXR5LmNvbS9SU0ElMjBDb3Jwb3JhdGUuY3JsMA4GA1UdDwEB/wQEAwIBhjAf BgNVHSMEGDAWgBTtkQhrdLdZSpL2oR0icCafCq8WkjAdBgNVHQ4EFgQUxpPuxqX+41WOz4ojH+6Y 3iHyn6cwDQYJKoZIhvcNAQEFBQADgYEAS6M22xEMAVVTJGohLkpNL4IHsqtTS/dL1k8KpmYVsh13 qoxQR6yIDmdL/xIkeuJ74VesLS5A5Ytny1iGp9xB4BQ1xg+1dlrSl2EtOKJGGc6T7pYK/j++LXBt TPjkdQuPh1Z2Ysiiu5/Zudhu1vZUBqlH1yzGCklwzao0PNjD/9MwggUVMIIEfqADAgECAhEA9mbr yIMTrdGBl20UhDRzWjANBgkqhkiG9w0BAQUFADCBjDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IElu Yy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4GA1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwg Q0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVT MB4XDTExMDMyMjE5NDMyM1oXDTEzMDMyMjE5NDMyM1owgdkxEzARBgoJkiaJk/IsZAEZFgNjb20x EzARBgoJkiaJk/IsZAEZFgNlbWMxGDAWBgNVBAoTD0VNQyBDb3Jwb3JhdGlvbjERMA8GA1UECxMI QW1lcmljYXMxETAPBgNVBAsTCENvbnN1bWVyMQ8wDQYDVQQFEwYwODQxNTMxFjAUBgoJkiaJk/Is ZAEBEwZtb3JpYWsxGjAYBgNVBAMTEUthdGhsZWVuIE1vcmlhcnR5MSgwJgYJKoZIhvcNAQkBFhlr YXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tHrBqnjoi4QPHgDVJofjUF9Zb+vJSgvoxSPJDm4Zr1S5FNGPMk9+5IdmdCpuLDDBL860tdsX97FT uPto4ozn1rpGfTqbeJ2g2a5L6ehY2vj8Xs0KWkeGX2SNdjBr9wKmHdFnm1rJUpdVq/EYlj7grtnX gEfofqJJaloL/Y6yzrmdcHxJqcWGrMYwFQMPpJsUCAGTUwDIC5Lo+BDm9vCPKsE3LRfPfyoEV8gw dF70SrDgel++AY+3JpKKUaHeNHJYaQgCmlPsq7nQShaUrdZsjEu1FSYU0RED/IPvy6E/8IynLzUH j8kdEko8u4I5/rbrAfL2g84WKo2Y9yLdGKDVNwIDAQABo4IBojCCAZ4wHwYDVR0jBBgwFoAUxpPu xqX+41WOz4ojH+6Y3iHyn6cwgZIGA1UdIASBijCBhzCBhAYJKoZIhvcNBQcFMHcwLgYIKwYBBQUH AgEWImh0dHA6Ly9jYS5yc2FzZWN1cml0eS5jb20vQ1BTLmh0bWwwRQYIKwYBBQUHAgIwOTAYFhFS U0EgU2VjdXJpdHkgSW5jLjADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBGBgNV HR8EPzA9MDugOaA3hjVodHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbTo4MC9SU0FDbGFzczJQZXJz b25hbENBLmNybDApBgNVHSUEIjAgBgorBgEEAYI3FAICBggrBgEFBQcDAgYIKwYBBQUHAwQwRAYD VR0RBD0wO4EZa2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbaAeBgorBgEEAYI3FAIDoBAMDm1vcmlh a0BlbWMuY29tMA4GA1UdDwEB/wQEAwIHgDAdBgNVHQ4EFgQUKUBa3GNyqVM1YeYSbez3TLEE0zcw DQYJKoZIhvcNAQEFBQADgYEAb6nns3uZAgIEP/e5cGzr2WD8osshUxSdIXS60+dY1ByVk9WDPytL WaaWnX2RlCwuxmNHP7ydJ9k3j02SHQU6fd724Nu1pJ8WH+23OzvZb2GTPRWipJl79OC6HFpNeF9j fwZiQyUj9etjajSCTLj8Si74HJC93igfezFSXHWh3C8wggUkMIIEjaADAgECAhAJONDFRXHEN2t0 nmmT/hogMA0GCSqGSIb3DQEBBQUAMIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMG A1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4G A1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMwHhcNMTEw MzIyMTk0MzI3WhcNMTMwMzIyMTk0MjA5WjCB3TETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmS JomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0aW9uMREwDwYDVQQLEwhBbWVyaWNh czERMA8GA1UECxMIQ29uc3VtZXIxDzANBgNVBAUTBjA4NDE1MzEWMBQGCgmSJomT8ixkAQETBm1v cmlhazEeMBwGA1UEAxMVS2F0aGxlZW4gTW9yaWFydHktRW5jMSgwJgYJKoZIhvcNAQkBFhlrYXRo bGVlbi5tb3JpYXJ0eUBlbWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqw/ b05qkBBGA43d/U48kOXeHZXnF7VotXJLSxQh/i0T2J2+G8smUD+oMMiN6VxnkPlwzWUx0tvyKsjp RmKChFy19DPsVxYcDyUWN2bOvdGXebbYSrOwZXycViqrJbUEJyMqmvfnZHdZ4GmadM7H6cU/9USL 2zojXVuA1eGwG/MIyx6ISLNkBpyhOIhuOSCBUymyMA3m7dgfX/9Thk/2txZIq8KSh0Yk2nN9lpnP m5MN8huGEZi4JwvPffopf6Mdfk69e1YNjJkFHno/tvQM6IZV7UR0A5xbBudKJsIwcFMD1O7+6HOF +dKyQFMbKd28nNysl72vDPn+sKzbz5TE5wIDAQABo4IBrjCCAaowNQYDVR0lBC4wLAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMB8GA1UdIwQYMBaAFMaT7sal/uNV js+KIx/umN4h8p+nMIGSBgNVHSAEgYowgYcwgYQGCSqGSIb3DQUHBTB3MC4GCCsGAQUFBwIBFiJo dHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEUGCCsGAQUFBwICMDkwGBYRUlNBIFNl Y3VyaXR5IEluYy4wAwIBARodQ1BTIEluY29ycG9yYXRlZCBieSByZWZlcmVuY2UwRgYDVR0fBD8w PTA7oDmgN4Y1aHR0cDovL2NybC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxD QS5jcmwwRAYDVR0RBD0wO4EZa2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbaAeBgorBgEEAYI3FAID oBAMDm1vcmlha0BlbWMuY29tMB0GA1UdDgQWBBThlHj7NKWOWW27DdIjvZSr12lCvDAOBgNVHQ8B Af8EBAMCAzgwDQYJKoZIhvcNAQEFBQADgYEAlvYOozbiUn9bWwTcopPQ3WK45lyx1ub00TBR8Wjk a4b1F96KCx17JcdHQmTSbOqzY516SRY255TCYr19T6VvphzwHjGIr3RvhjnDeusJBgqTdikt1Xgg Cdgg8oj2DB6990BclcOhidYlK0taqHbhlxCNZk7/4U1kZQrKO4/DalkxggQAMIID/AIBATCBojCB jDEaMBgGA1UEChMRUlNBIFNlY3VyaXR5IEluYy4xFTATBgNVBAsTDEtDQSBTZXJ2aWNlczEgMB4G A1UEAxMXUlNBIENsYXNzIDIgUGVyc29uYWwgQ0ExEDAOBgNVBAcTB0JlZGZvcmQxFjAUBgNVBAgT DU1hc3NhY2h1c2V0dHMxCzAJBgNVBAYTAlVTAhEA9mbryIMTrdGBl20UhDRzWjAJBgUrDgMCGgUA oIICMjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAxMzExNjMy MzlaMCMGCSqGSIb3DQEJBDEWBBTLH+BZ9W8PkgGcozcmHnFqVZbQmjBnBgkqhkiG9w0BCQ8xWjBY MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBsgYJKwYBBAGCNxAEMYGkMIGhMIGMMRow GAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQD ExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFz c2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEAk40MVFccQ3a3SeaZP+GiAwgbQGCyqGSIb3DQEJEAIL MYGkoIGhMIGMMRowGAYDVQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZp Y2VzMSAwHgYDVQQDExdSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCEAk40MVFccQ3a3SeaZP+GiAwDQYJ KoZIhvcNAQEBBQAEggEAcAAr/L0gaNEdWBie5qU+XKCjDPh7aLhlv89ih8EepSljFY6oCEhh+rJk b//NHoBkNPTrOFMVMBWiJhHz3X6cJ1tnKB2yCWpjd7x13IllC3NP2XfHmXsSQih3Wcyh06UYOpd5 Ip5xbN/OIwY/ulzgKnqQqnZKUN5Mzlx2vbVMVMo0moFCzzCLtg1MwvlxAxbrMIAIjYv1ynL3GuHc XHc93ZvaqWy+wVyeyXx/ZSf6Tj3dM+CAffu+s/8qM6DR11xfb14s7RnN3Ak5RNRJJENsSauVodtL 3MBjRxhp3ew7IM9QOvr5AZ1HxACAaIXh1T56h50axzcfX2EV1yfmxdek1QAAAAAAAA== ------=_NextPart_000_0036_01CCE00C.09FEBAA0-- From turners@ieca.com Tue Jan 31 08:43: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 0CF2D21F85B5 for ; Tue, 31 Jan 2012 08:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.789 X-Spam-Level: X-Spam-Status: No, score=-100.789 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 ZoI34lvYZhav for ; Tue, 31 Jan 2012 08:43:06 -0800 (PST) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.93.243.9]) by ietfa.amsl.com (Postfix) with ESMTP id EAE8A21F84D8 for ; Tue, 31 Jan 2012 08:43:05 -0800 (PST) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id CAA20B299693D; Tue, 31 Jan 2012 10:43:04 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id BBC58B2996904 for ; Tue, 31 Jan 2012 10:43:04 -0600 (CST) Received: from [166.137.14.138] (port=15059 helo=[10.129.224.77]) by gator1743.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RsGnP-0007nc-Qn; Tue, 31 Jan 2012 10:43:04 -0600 References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D918DC@MX14A.corp.emc.com> <4F21B1E4.6060304@stpeter.im> <4F21C468.9030104@stpeter.im> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7D91BFA@MX14A.corp.emc.com> <4F21DFF5.3070905@stpeter.im> <4F2342E1.3010101@qualcomm.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AC3A3994@MX14A.corp.emc.com> <4F275E89.90209@qualcomm.com> <5917806F-0F95-4C1D-9897-335F0BEF1E5A@tik.ee.ethz.ch> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2000862E-5238-488C-9052-9905AEDE845B; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPhone Mail (9A405) From: Sean Turner Date: Tue, 31 Jan 2012 10:42:59 -0600 To: "" 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: ([10.129.224.77]) [166.137.14.138]:15059 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" , "" Subject: Re: [mile] FW: IDN issue 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, 31 Jan 2012 16:43:07 -0000 --Apple-Mail-2000862E-5238-488C-9052-9905AEDE845B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please post a new version. Sent from my iPhone On Jan 31, 2012, at 10:32 AM, wrote: > Thank you. Will this happen in Auth48 or should I post a new version? >=20 > Best regards, > Kathleen >=20 > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tuesday, January 31, 2012 11:29 AM > To: Brian Trammell; Moriarty, Kathleen > Cc: Pete Resnick; mile@ietf.org > Subject: Re: [mile] FW: IDN issue >=20 > To resolve this please delete the last sentence. >=20 > Spt >=20 > Sent from my iPhone >=20 > On Jan 31, 2012, at 2:26 AM, Brian Trammell wrot= e: >=20 >> Hi, Kathleen, Pete, all, >>=20 >> Thought I'd jump in as a random guy off the street again. >>=20 >> It seems to me that the concern here is the last sentence: >>=20 >> RID >> systems are expected to obtain an IDN meeting these requirements by >> asking a DNS resolver to return an IDN that does not contain A-labels >> (even if the RID system's input to the DNS resolver contains >> A-labels). >>=20 >> which presupposes the existence of an API in the (stub?) resolver that >>=20 >> 1. can be forced to return a U-label for a given query; or >> 2. that returns a U-label for a given A-label. >>=20 >> I have done precisely zero work with IDN support as an implementor, so I=20= >> wouldn't even know where to start looking to verify that. It seems to me t= o=20 >> be reasonable to assume such a thing exists, but I'm teaching myself C++=20= >> these days so am very, very wary of "reasonable assumption" and "API"=20 >> appearing in the same sentence. Also, if you've never heard of such a thi= ng,=20 >> well, I consider that a data point right there. >>=20 >> However, what's important is not the existence of an API, but the existen= ce=20 >> of a clearly defined algorithm for the conversion between A-labels and=20= >> U-labels. That we _do_ have. So, how about just dropping the last sentenc= e?=20 >> The relevant language is then: >=20 >>=20 >> .... RID systems SHOULD support IDNs in the NodeName >> class; if they do so, the UTF-8 representation of the domain name >> MUST be used, i.e., all of the domain name's labels MUST be U-labels >> expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be >> used. An application communicating via RID can convert between >> A-labels and U-labels by using the Punycode encoding [RFC3492] for >> A-labels as described in the protocol specification for >> Internationalized Domain Names in Applications [RFC5891]. >>=20 >> With respect to intent, it seems to me that NodeName (as well as Node) sh= ou --Apple-Mail-2000862E-5238-488C-9052-9905AEDE845B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFZTCCBWEw ggRJoAMCAQICEE/FgaFyQdyPCzx4n2cZ9yAwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTQwMDAwMDBaFw0x MjEwMTMyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtTZWFuIFR1cm5lcjEfMB0GCSqGSIb3DQEJARYQdHVybmVyc0BpZWNhLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALxkpJ1QrW25eQA6B42YT2xlTZsiFKEo O5TK4fGwi8P/TeqVY1S0QJiOGKKxZMyifeT1P/wCh2bmULTnZDUWVEYMMwLC23T+udDEoxIg4ecd tC2R3JHU5juQHM6C4gBxrNyLVztSE66jOHC8O97/q48Iqxa8N7Zl88csmWqn1Cf1WfqsYxoZiflI oJX2bAdkRMJtS0XV/MwMx1Chl76Y1gC2Q2QDO9SnIBAZuYtkFT59Ck7RLvX3fW4G3ul/A+FPbzMK uiMYp1Agd6todXsi02W0iYMeya7l5p+EyF/QL73/aA9XL73gyNAmB+BUc507V/HBvi1TUIYea17Q GDKo3McCAwEAAaOB6DCB5TAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9uZTBQBgNVHR8E STBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRD MURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQADggEBACzRt5PT1zCgv4bii3a8Htl7GQ7N rIkQbEXTIB5Qsk5NQ78Nywtjx9tzTBvxZ36LJNMfgV55rLRalzo3nXzAe5JT63DfbU2gnsDGXSt4 EPPPaL6BmcxlJqdxWucIVeLvsKhzdij+DIwjm06ysGFtNXRv8DBQ6VATcAoB5E9x0LIuW+xde9XE 3rk9lVLpCkLxaciqm4ujNPmiciukR0IKZa6gGQqCKXp7gAa7d+mgXSdVqYAF52HqQxihvs7012ai TRiRICecM/LaBzvX5KQdNEmmKPxl9LxVksc+QkJ5IsSOAm84NUV44xTWXYzJtjuJPdQatdfrbnL9 /6yRz3FDv0ExggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEczAhBPxYGhckHcjws8eJ9nGfcgMAkGBSsOAwIaBQCgggJtMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEzMTE2NDMwM1owIwYJKoZI hvcNAQkEMRYEFOKXrWY9DS6MZC3kQwu75CJU7oWkMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/FgaFyQdyP Czx4n2cZ9yAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPxYGhckHcjws8eJ9nGfcgMA0GCSqGSIb3DQEB AQUABIIBAA3DPfNxtSUHbZSE6uC9PoVkOLm494/XV0jRzTRUA9cfdpqi+e9DT5I3A5DBfjXggkVv nTkuT+LdZZ6KH/ALsdRKc24Slxqr90w02CkpAiWSKU0KIW160jO1NKMrh4LjVbI8DPKXmfJYTTtJ yP5e/hA0nX3wYa6b0R4/IKD77uwG1JLvdmnnIHo9ol5pX0Sc5PN0uVj8NNf3L6ZS0T0vRIO7AVOc ZRFov4migsAgdIQMaL4wzYId1OEMnDMzL/WmkyYWdW49X6ZE0adze7mOBrlJctm7k0PIJJ71/k1w ehgI6EAZwFaJoNvwKF1fRJT3pmH0S5/4xJh8G2nfH4NJH7QAAAAAAAA= --Apple-Mail-2000862E-5238-488C-9052-9905AEDE845B-- From internet-drafts@ietf.org Tue Jan 31 09:00: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 A793321F8546; Tue, 31 Jan 2012 09:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ILon7BOH8d5W; Tue, 31 Jan 2012 09:00:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B2011E80BD; Tue, 31 Jan 2012 09:00: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.64p1 Message-ID: <20120131170013.8853.39447.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 09:00:13 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-11.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: Tue, 31 Jan 2012 17:00:40 -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 : Real-time Inter-network Defense (RID) Author(s) : Kathleen M. Moriarty Filename : draft-ietf-mile-rfc6045-bis-11.txt Pages : 84 Date : 2012-01-31 Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-11.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-rfc6045-bis-11.txt From trammell@tik.ee.ethz.ch Tue Jan 31 12:32: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 2EABA11E8089 for ; Tue, 31 Jan 2012 12:32:11 -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 sV6XWuDWzhoe for ; Tue, 31 Jan 2012 12:32: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 8009A11E80E3 for ; Tue, 31 Jan 2012 12:32:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 16DF1D9323; Tue, 31 Jan 2012 21:32:07 +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 qBzXh+iSKarD; Tue, 31 Jan 2012 21:32:06 +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 85393D930A; Tue, 31 Jan 2012 21:32:06 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Brian Trammell Date: Tue, 31 Jan 2012 21:32:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <421D5779-D725-4AB3-9000-AB38CDCC0254@tik.ee.ethz.ch> References: <20120131170013.8853.39447.idtracker@ietfa.amsl.com> To: Sean Turner , Kathleen Moriarty X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: [mile] Fwd: I-D Action: draft-ietf-mile-rfc6045-bis-11.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: Tue, 31 Jan 2012 20:32:11 -0000 Hi, Sean, Kathleen, all, This revision of the document appears to address the last outstanding = issue re: IDNs. The discussion therefore appears complete, from where I = sit. Many thanks to all for the productive discussions on 6045-bis! Best regards, Brian (as chair and document shepherd, 6045-bis) Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 31, 2012 6:00:13 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-rfc6045-bis-11.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Managed Incident = Lightweight Exchange Working Group of the IETF. >=20 > Title : Real-time Inter-network Defense (RID) > Author(s) : Kathleen M. Moriarty > Filename : draft-ietf-mile-rfc6045-bis-11.txt > Pages : 84 > Date : 2012-01-31 >=20 > Security incidents, such as system compromises, worms, viruses, > phishing incidents, and denial of service, typically result in the > loss of service, data, and resources both human and system. Service > providers and Computer Security Incident Response Teams need to be > equipped and ready to assist in communicating and tracing security > incidents with tools and procedures in place before the occurrence = of > an attack. Real-time Inter-network Defense (RID) outlines a > proactive inter-network communication method to facilitate sharing > incident handling data while integrating existing detection, = tracing, > source identification, and mitigation mechanisms for a complete > incident handling solution. Combining these capabilities in a > communication system provides a way to achieve higher security = levels > on networks. Policy guidelines for handling incidents are > recommended and can be agreed upon by a consortium using the = security > recommendations and considerations. This document obsoletes = RFC6045. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-11.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6045-bis-11.txt >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From iesg-secretary@ietf.org Tue Jan 31 14:07:49 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 C224C11E807F; Tue, 31 Jan 2012 14:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 fWkhsPcbiVrQ; Tue, 31 Jan 2012 14:07:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90C011E8096; Tue, 31 Jan 2012 14:07:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120131220748.4711.51840.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 14:07:48 -0800 Cc: mile mailing list , mile chair , RFC Editor Subject: [mile] Protocol Action: 'Real-time Inter-network Defense (RID)' to Proposed Standard (draft-ietf-mile-rfc6045-bis-11.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: Tue, 31 Jan 2012 22:07:49 -0000 The IESG has approved the following document: - 'Real-time Inter-network Defense (RID)' (draft-ietf-mile-rfc6045-bis-11.txt) as a Proposed Standard This document is the product of the Managed Incident Lightweight Exchange Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ Technical Summary Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. The data in RID messages is represented in an XML document using IODEF [RFC5070] and the RID XML schema defined in this document. Working Group Summary There was extensive commentary on the pre-WG and WG mailing list on the document indicative of review, correction, and consensus. The working group process has been somewhat abbreviated, as the document is an update of an already-published RFC to change its intended status (Informational to Standards Track) and to apply minor updates. Consensus was reached without problems. Document Quality The document itself derived from the previously published (informational) RFC 6045. The XML schema was reviewed by two experts, one within the WG and one from outside. In addition to the review received within the MILE WG, much of the content within the document (both technical and editorial) has received extensive review prior to its initial publication as RFC6045 in November 2010. Personnel Brian Trammell (trammell@tik.ee.ethz.ch) is the document shepherd. Sean Turner is the responsible Area Director. From internet-drafts@ietf.org Tue Jan 31 20:45: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 5490711E80C7; Tue, 31 Jan 2012 20:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 yuMxFeVmsbMd; Tue, 31 Jan 2012 20:45:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB03811E8095; Tue, 31 Jan 2012 20:45:38 -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.64p1 Message-ID: <20120201044538.11982.34012.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 20:45:38 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-sci-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: Wed, 01 Feb 2012 04:45:39 -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 : IODEF-extension to support structured cybersecurity info= rmation Author(s) : Takeshi Takahashi Kent Landfield Thomas Millar Youki Kadobayashi Filename : draft-ietf-mile-sci-02.txt Pages : 35 Date : 2012-01-31 This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched cybersecurity information exchange among cybersecurity entities by embedding structured information formatted by specifications, including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-02.txt From takeshi_takahashi@nict.go.jp Tue Jan 31 21:02: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 D2B1E11E80C7 for ; Tue, 31 Jan 2012 21:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-0.590, 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 L3hjYjM7IEbT for ; Tue, 31 Jan 2012 21:02:15 -0800 (PST) Received: from mow.securemx.jp (mow300.securemx.jp [210.130.202.48]) by ietfa.amsl.com (Postfix) with ESMTP id 29D3911E8095 for ; Tue, 31 Jan 2012 21:02:14 -0800 (PST) Received: by mow.securemx.jp (mow300) id q115288l027959; Wed, 1 Feb 2012 14:02:08 +0900 X-MXL-Hash: 4f28c74f6c1f450a-b084733b72db2754ac53135ef68883bc8b81b107 Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by relay.securemx.jp (mx-mr302) id q11525bc006107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 14:02:05 +0900 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id q11525Wk024527; Wed, 1 Feb 2012 14:02:05 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id q11524R8000399; Wed, 1 Feb 2012 14:02:04 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id q115246q000396; Wed, 1 Feb 2012 14:02:04 +0900 (JST) From: "Takeshi Takahashi" To: References: <20120201044538.11982.34012.idtracker@ietfa.amsl.com> In-Reply-To: <20120201044538.11982.34012.idtracker@ietfa.amsl.com> Date: Wed, 1 Feb 2012 14:02:05 +0900 Message-ID: <006001cce09e$a4e075d0$eea16170$@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: AQDCFzXoHSR8LGk2ImztBGlImUsdOpg9C14Q Content-Language: ja Subject: Re: [mile] I-D Action: draft-ietf-mile-sci-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: Wed, 01 Feb 2012 05:02:15 -0000 Hello all, The new version of the -sci draft is uploaded. I hope I've reflected all the comments from the mailing list. Here are the major changes. 1. notional string ID is removed 2. namespace is used to identify specification 3. MAEC is included 4. multiple Specification URIs are allowed 5. Version attributes inside each extended class are deleted 6. field for IDs specifying data entry (e.g. CVE-ID) is prepared for each of the extended classes. 7. order of the chapter is changed 8. schema is changed accordingly I appreciate any comments on the draft. Thank you. Take > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, February 01, 2012 1:46 PM > To: i-d-announce@ietf.org > Cc: mile@ietf.org > Subject: [mile] I-D Action: draft-ietf-mile-sci-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Managed Incident Lightweight > Exchange Working Group of the IETF. > > Title : IODEF-extension to support structured > cybersecurity information > Author(s) : Takeshi Takahashi > Kent Landfield > Thomas Millar > Youki Kadobayashi > Filename : draft-ietf-mile-sci-02.txt > Pages : 35 > Date : 2012-01-31 > > This document extends the Incident Object Description Exchange Format > (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched > cybersecurity information exchange among cybersecurity entities by > embedding structured information formatted by specifications, > including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) > [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL > [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-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-sci-02.txt > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile