From takeshi_takahashi@nict.go.jp Fri Aug 5 03:20:15 2011 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 3D26821F8B83 for ; Fri, 5 Aug 2011 03:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, HELO_EQ_JP=1.244, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjzgnCV4D4cv for ; Fri, 5 Aug 2011 03:20:04 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E73421F8B80 for ; Fri, 5 Aug 2011 03:20:01 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id p75AKDIw001579; Fri, 5 Aug 2011 19:20:13 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id p75AKDWl023917; Fri, 5 Aug 2011 19:20:13 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id p75AKCoj023912; Fri, 5 Aug 2011 19:20:13 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id A118A2C1A6; Fri, 5 Aug 2011 19:20:12 +0900 (JST) Received: from tbntakahashi (unknown [133.243.119.200]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 97D7116133; Fri, 5 Aug 2011 19:20:12 +0900 (JST) From: "Takeshi Takahashi" To: , , , , , "'Youki Kadobayashi'" , "'Robert Martin'" Date: Fri, 5 Aug 2011 19:19:38 +0900 Message-ID: <00f501cc5359$2ea3e730$8bebb590$@go.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00F6_01CC53A4.9E8B8F30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxTWS5b5/8nc9AyTKOeo+Sqym4nqA== Content-Language: ja Subject: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 05 Aug 2011 10:20:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F6_01CC53A4.9E8B8F30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F7_01CC53A4.9E8B8F30" ------=_NextPart_001_00F7_01CC53A4.9E8B8F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, The attached is the tentative version of the draft prepared based on the comments I've received in this mailing list (Thanks a lot for that). It would be great if you could provide some comments on Clause 4, where the IODEF extension is defined. As you know, there are many ways to embed structured information (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very flexible. Thus, I would be happy to change and develop the draft further based on your comments. I would like to welcome any comments on that. By the way, I will be on vacation, thus my response might be slow, sorry for the inconvenience. Take PS: I've changed the title of the email. 2011/7/29 > > Thank you, the approach sounds good, especially since it is in use today > by at least the Research and Education ISAC. Do others have opinions on > the proposal here? > > Thanks for writing the first draft Take! > > Best regards, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Takeshi > Takahashi [takeshi_takahashi@nict.go.jp] > Sent: Friday, July 29, 2011 9:20 AM > To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > Cc: mile@ietf.org > Subject: Re: [mile] Updated presentation from Side meeting > > Thank you, Bob, for the email. > I also like Tom's suggestion very much. > Let me work on the "draft" of the draft for a while, then come back to you > later. > > Take > > -----Original Message----- > From: Martin, Robert A. [mailto:ramartin@mitre.org] > Sent: Friday, July 29, 2011 9:10 AM > To: Kent_Landfield@McAfee.com > Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > wes@ren-isac.net; mile@ietf.org > Subject: Re: [mile] Updated presentation from Side meeting > > I also like how this is evolving. > > I think, as Tom's suggestions pointed, that any and all of the useful > types > of information that can help with understanding, diagnosing, and getting > ahead of an incident should be added but for now we should focus on those > the most established and well articulated. > > This can be the compliance/patch/configuration/platform information > related > to the SCAP use case, or event signature/attack pattern/traffic > characteristics from events, or the vulnerability/threat characterization > space. > > I look forward to Taki's draft to see how he suggests positioning these > concepts. > > Bob > > On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > > I like where this is headed. > > > > Thanks Takeshi. I look forward to your draft. It will give us something > real to discuss. I appreciate you jumping in and getting this started. > > > > One question that I am not clear on. What do we envision as the actual > set > of deliverables? From and SCAP related perspective, are we looking at a > single draft covering all the extensions? > > > > Kent > > > > Kent Landfield > > Director Content Strategy, Architecture and Standards > > > > McAfee, Inc. > > 5000 Headquarters Dr. > > Plano, Texas 75024 > > > > Direct: +1.972.963.7096 > > Mobile: +1.817.637.8026 > > Web: www.mcafee.com > > > > From: Takeshi > > Takahashi > o.jp>> > > Date: Thu, 28 Jul 2011 18:21:56 -0500 > > To: > > "Thomas.Millar@us-cert.gov" > illar@us-cert.gov>, > > "wes@ren-isac.net" > s@ren-isac.net>>, > > "mile@ietf.org" > rg>> > > Subject: Re: [mile] Updated presentation from Side meeting > > > > Thank you for the email, Tom. > > > > So, here is what the draft needs to describe (if I understand Wes and > > Tom correctly). > > > > The draft should define ext-dtype (an attribute of AdditionalData > > Class) to identify the information type, rather than defining new > > class under AdditionalData. > > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec, > > ext-cvss, ext-cwss, In this way, we could keep the change minimal and > > could easily embed various structured information (CVE etc.) in the > > EventData.Record.RecordData.AdditionalData field. > > Then "should" statement should be carefully placed in the text of > > relevant class. > > > > I'll prepare some draft so that we could discuss and advance further. > > > > Take > > > > > > > > -----Original Message----- > > From: mile-bounces@ietf.org > > [mailto:mile-bounces@ietf.org] On Behalf Of > > Thomas.Millar@us-cert.gov > > Sent: Thursday, July 28, 2011 6:28 PM > > To: wes@ren-isac.net; > > mile@ietf.org > > Subject: Re: [mile] Updated presentation from Side meeting > > > > I think this approach makes more sense. One of the things I think > > could be helpful is to have a number of SHOULD statements further > > describing the possible types of other documents that would be > > expected to ride under the AdditionalData elements of each class (not > just > EventData). > > What I'm thinking of looks like this (very unpolished): > > > > "The Method Class:AdditionalData class SHOULD contain data elements > > that describe the methods, tools or techniques employed to cause the > > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the > > method such as CVSS, CWSS, or CCE." > > > > "The Expectation Class[...] SHOULD contain data elements which > > describe configuration changes, detection heuristics, or [* (legal > > authorization?)] to assist in executing or implementing the requested > > action, such as XCCDF, OCIL, OVAL, etc" > > > > This could go towards encouraging better or at least more consistent > > use of "boundary objects" in the substance of incident reports. I > > could also go on about greater automation and such but that's probably > > out of scope for this e-mail. > > > > > > - Tom Millar, US-CERT > > > > thomas.millar@us-cert.gov > > BB: thomas.millar@dhs.gov / > > 202-631-1915 > > 24x7: soc@us-cert.gov / 888-282-0870 > > -----Original Message----- > > From: mile-bounces@ietf.org > > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > > Sent: Thursday, July 28, 2011 11:08 AM > > To: mile@ietf.org > > Subject: Re: [mile] Updated presentation from Side meeting > > > > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > > > > http://tools.ietf.org/html/rfc5070#section-3.19 > > > > i've been sticking other "XML like" records under this (icsg1.1 data, > > etc...). > > > > pretty easy to do, just generate the "other standards" xml (or json or > > whatever), embed it there. turns iodef into a sharing platform for > > other data-types w/o having to extend it too much. > > > > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > > > > So, maybe we could extend the IODEF as described in Figure 1 of the > > attached txt file. (correct me if I'm wrong) We could define > > Incident.EventData.AdditionalData elements and describe them by using > > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > > Regarding OVAL, we might define Incident.AdditionalData element, but I > > > > am not sure at this moment, thus is not described in the figure yet. > > I would like to tackle CAPEC first since I believe Kent would like to > > tackle CVE and CAPEC. > > > > -- > > Wes > > claimid.com/wesyoung > > soc@ren-isac.net > > > > * Wes Young> > > * 0xDDB6E946 - Unverified(L) > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > . > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_00F7_01CC53A4.9E8B8F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

The attached is the tentative version of the draft = prepared based on the comments I’ve received in this mailing list = (Thanks a lot for that).

It would be = great if you could provide some comments on Clause 4, where the IODEF = extension is defined.

 

As you know, = there are many ways to embed structured information (e.g. CVE and CAPEC) = in IODEF since IODEF is designed to be very flexible.

Thus, I would be happy to change and develop the draft = further based on your comments.

 

I would like = to welcome any comments on that.

 

By the way, = I will be on vacation, thus my response might be slow, sorry for the = inconvenience.

 

Take

 

PS: = I’ve changed the title of the email.

 

 

2011/7/29 = <kathleen.moriarty@emc.com>

> 

> = Thank you, the approach sounds good, especially since it is in use = today

> by at least the Research = and Education ISAC.  Do others have opinions on

> the proposal here?

> 

> = Thanks for writing the first draft Take!

> 

> = Best regards,

> = Kathleen

> = ________________________________________

> From: mile-bounces@ietf.org = [mile-bounces@ietf.org] On Behalf Of Takeshi

> Takahashi = [takeshi_takahashi@nict.go.jp]

> = Sent: Friday, July 29, 2011 9:20 AM

> To: 'Martin, Robert A.'; = Kent_Landfield@McAfee.com

> Cc: = mile@ietf.org

> Subject: Re: = [mile] Updated presentation from Side meeting

> 

> = Thank you, Bob, for the email.

> I = also like Tom's suggestion very much.

> Let me work on the "draft" of the draft = for a while, then come back to you

> later.

> 

> = Take

> 

> -----Original Message-----

> From: Martin, Robert A. = [mailto:ramartin@mitre.org]

> = Sent: Friday, July 29, 2011 9:10 AM

> To: Kent_Landfield@McAfee.com

> Cc: takeshi_takahashi@nict.go.jp; = Thomas.Millar@us-cert.gov;

> = wes@ren-isac.net; mile@ietf.org

> = Subject: Re: [mile] Updated presentation from Side = meeting

> 

> I also like how this is = evolving.

> 

> I think, as Tom's suggestions pointed, that any = and all of the useful

> = types

> of information that can = help with understanding, diagnosing, and getting

> ahead of an incident should be added but for now = we should focus on those

> the = most established and well articulated.

> 

> = This can be the compliance/patch/configuration/platform = information

> = related

> to the SCAP use case, or = event signature/attack pattern/traffic

> characteristics from events, or the = vulnerability/threat characterization

> space.

> 

> I = look forward to Taki's draft to see how he suggests positioning = these

> concepts.

> 

> = Bob

> 

> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com = wrote:

> > I like where this is = headed.

> >

> > Thanks Takeshi.  I look forward to your = draft. It will give us something

> = real to discuss. I appreciate you jumping in and getting this = started.

> >

> > One question that I am not clear on. What do = we envision as the actual

> = set

> of deliverables?  From = and SCAP related perspective, are we looking at a

> single draft covering all the = extensions?

> = >

> > Kent

> >

> > = Kent Landfield

> > Director = Content Strategy, Architecture and Standards

> >

> > = McAfee, Inc.

> > 5000 = Headquarters Dr.

> > Plano, = Texas 75024

> = >

> > Direct: = +1.972.963.7096

> > Mobile: = +1.817.637.8026

> > Web: = www.mcafee.com<http://www.mcafee.com/>

> >

> > = From: Takeshi

> > = Takahashi<takeshi_takahashi@nict.go.jp<mailto:takeshi_takahashi@nic= t.g

> > = o.jp>>

> > Date: Thu, 28 = Jul 2011 18:21:56 -0500

> > = To:

> > = "Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>&q= uot;<Thomas.M

> > = illar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>>,=

> > = "wes@ren-isac.net<mailto:wes@ren-isac.net>"<wes@ren-is= ac.net<mailto:we

> > = s@ren-isac.net>>,

> > = "mile@ietf.org<mailto:mile@ietf.org>"<mile@ietf.org<= ;mailto:mile@ietf.o

> > = rg>>

> > Subject: Re: = [mile] Updated presentation from Side meeting

> >

> > = Thank you for the email, Tom.

> = >

> > So, here is what the = draft needs to describe (if I understand Wes and

> > Tom correctly).

> >

> > = The draft should define ext-dtype (an attribute of = AdditionalData

> > Class) to = identify the information type, rather than defining new

> > class under AdditionalData.

> > Ext-dtype: ext-cve, ext-cwe, ext-oval, = ext-xccdf, ext-cpe, ext-capec,

> = > ext-cvss, ext-cwss, In this way, we could keep the change minimal = and

> > could easily embed = various structured information (CVE etc.) in the

> > EventData.Record.RecordData.AdditionalData = field.

> > Then = "should" statement should be carefully placed in the text = of

> > relevant = class.

> >

> > I'll prepare some draft so that we could = discuss and advance further.

> = >

> > Take

> >

> = >

> >

> > -----Original Message-----

> > From: = mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>

<= p class=3DMsoNormal>> > [mailto:mile-bounces@ietf.org] On Behalf = Of

> > = Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>

> > Sent: Thursday, July 28, 2011 6:28 = PM

> > To: = wes@ren-isac.net<mailto:wes@ren-isac.net>;

> > = mile@ietf.org<mailto:mile@ietf.org>

> > Subject: Re: [mile] Updated presentation = from Side meeting

> = >

> > I think this approach = makes more sense. One of the things I think

> > could be helpful is to have a number of = SHOULD statements further

> > = describing the possible types of other documents that would = be

> > expected to ride under = the AdditionalData elements of each class (not

> just

> = EventData).

> > What I'm = thinking of looks like this (very unpolished):

> >

> > = "The Method Class:AdditionalData class SHOULD contain data = elements

> > that describe the = methods, tools or techniques employed to cause the

> > incident, such as CAPEC, CWE, CVE, CVRF, or = metadata concerning the

> > = method such as CVSS, CWSS, or CCE."

> >

> > = "The Expectation Class[...] SHOULD contain data elements = which

> > describe = configuration changes, detection heuristics, or [* = (legal

> > authorization?)] to = assist in executing or implementing the requested

> > action, such as XCCDF, OCIL, OVAL, = etc"

> >

> > This could go towards encouraging better or = at least more consistent

> > = use of "boundary objects" in the substance of incident = reports. I

> > could also go on = about greater automation and such but that's probably

> > out of scope for this = e-mail.

> >

> >

> > = - Tom Millar, US-CERT

> = >

> > = thomas.millar@us-cert.gov<mailto:thomas.millar@us-cert.gov>

> > BB: = thomas.millar@dhs.gov<mailto:thomas.millar@dhs.gov>  = /

> > = 202-631-1915

> > 24x7: = soc@us-cert.gov<mailto:soc@us-cert.gov>  / = 888-282-0870

> > -----Original = Message-----

> > From: = mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>

<= p class=3DMsoNormal>> > [mailto:mile-bounces@ietf.org] On Behalf = Of Wes Young

> > Sent: = Thursday, July 28, 2011 11:08 AM

> = > To: mile@ietf.org<mailto:mile@ietf.org>

> > Subject: Re: [mile] Updated presentation = from Side meeting

> = >

> > * PGP Signed by an = unverified key: 7/28/2011 at 11:08:06 AM

> >

> > = http://tools.ietf.org/html/rfc5070#section-3.19

> >

> > = i've been sticking other "XML like" records under this = (icsg1.1 data,

> > = etc...).

> >

> > pretty easy to do, just generate the = "other standards" xml (or json or

> > whatever), embed it there. turns iodef into = a sharing platform for

> > = other data-types w/o having to extend it too much.

> >

> > = On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote:

> >

> > = So, maybe we could extend the IODEF as described in Figure 1 of = the

> > attached txt file. = (correct me if I'm wrong) We could define

> > Incident.EventData.AdditionalData elements = and describe them by using

> > = CPE, CVE/CWE, CVSS/CWSS, and CAPEC.

> > Regarding OVAL, we might define = Incident.AdditionalData element, but I

> >

> > = am not sure at this moment, thus is not described in the figure = yet.

> > I would like to tackle = CAPEC first since I believe Kent would like to

> > tackle CVE and CAPEC.

> >

> > = --

> > Wes

> > claimid.com/wesyoung

> > = soc@ren-isac.net<mailto:soc@ren-isac.net>

> >

> > = * Wes = Young<wes@ren-isac.net<mailto:wes@ren-isac.net>>

> > * 0xDDB6E946 - = Unverified(L)

> > = _______________________________________________

> > mile mailing list

> > = mile@ietf.org<mailto:mile@ietf.org>

> > = https://www.ietf.org/mailman/listinfo/mile

> > = _______________________________________________

> > mile mailing list

> > = mile@ietf.org<mailto:mile@ietf.org>

> > = https://www.ietf.org/mailman/listinfo/mile

> >

> > = _______________________________________________

> > mile mailing list

> > = mile@ietf.org<mailto:mile@ietf.org>

> > = https://www.ietf.org/mailman/listinfo/mile

> >

> > = _______________________________________________

> > mile mailing list

> > mile@ietf.org

> > = https://www.ietf.org/mailman/listinfo/mile

> > .

> = >

> 

> = _______________________________________________

> mile mailing list

> mile@ietf.org

> = https://www.ietf.org/mailman/listinfo/mile

 

 

 

------=_NextPart_001_00F7_01CC53A4.9E8B8F30-- ------=_NextPart_000_00F6_01CC53A4.9E8B8F30 Content-Type: text/plain; name="draft-xxxx-mile-msmspecs-01_draft20110805take.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-xxxx-mile-msmspecs-01_draft20110805take.txt" =0A= =0A= =0A= Individual Submission X. XXXX=0A= Internet-Draft XXXX=0A= Intended status: Informational Aug 5, 2011=0A= Expires: February 6, 2012=0A= =0A= =0A= IODEF-extension to support structured cybersecurity information=0A= draft-xxxx-mile-msmspecs-01.txt=0A= =0A= Abstract=0A= =0A= This document extends the Incident Object Description Exchange Format=0A= (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched=0A= cybersecurity information exchange among cybersecurity entities by=0A= embedding structured information formatted by the following=0A= specifications: CAPEC, CEE, CPE, CVE, CVSS, CWE, CWSS, OVAL, and=0A= XCCDF.=0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on February 6, 2012.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2011 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 1]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= described in the Simplified BSD License.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4=0A= 4.1. Scoring . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 4.2. AttackPattern . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4.3. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 7=0A= 4.4. Weakness . . . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 4.5. PlatformID . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.6. EventReport . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.7. Remediation . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11=0A= 5.1. Reporting an attack . . . . . . . . . . . . . . . . . . . 11=0A= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13=0A= 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 14=0A= 6.2. Using the iodef:restriction Attribute . . . . . . . . . . 14=0A= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14=0A= 8. Appendix: XML Schema Definition for Extension . . . . . . . . 15=0A= 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17=0A= 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17=0A= 9.2. Informative References . . . . . . . . . . . . . . . . . . 17=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 2]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= 1. Introduction=0A= =0A= Cyber attacks are getting more sophisticated, and their numbers are=0A= increasing day by day. To cope with such situation, incident=0A= information needs to be reported, exchanged, and shared among=0A= organizations. IODEF is one of the tools enabling such exchange, and=0A= is already in use by various organizations.=0A= =0A= On the other hand, there exist various other activities facilitating=0A= detailed and structured description of cybersecurity information,=0A= major of which includes CAPEC, CEE, CPE, CVE, CVSS, CWE, CWSS, OVAL,=0A= and XCCDF. Since such structured description facilitates=0A= cybersecurity operations, it would be beneficial to embed and convey=0A= these information inside IODEF document.=0A= =0A= To enable that, this document extends the IODEF to embed and convey=0A= various structured cybersecurity information, with which=0A= cybersecurity operations can be facilitated. Since IODEF defines a=0A= flexible and extensible format and supports a granular level of=0A= specificity, this document defines an extension to IODEF instead of=0A= defining a new report format. It specifies several new data types=0A= and describes recommended usage of the extensions. For clarity, and=0A= to eliminate duplication, only the additional structures necessary=0A= for describing the exhange of such structured information are=0A= provided.=0A= =0A= =0A= 2. Terminology=0A= =0A= The terminology used in this document follows the one defined in=0A= [RFC5070].=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= =0A= 3. Applicability=0A= =0A= To maintain cybersecurity, organization needs to exchange=0A= cybersecurity information, which includes the following information:=0A= attack pattern, platform information, vulnerability and weakness,=0A= countermeasure instruction, computer event log, and the severity.=0A= =0A= IODEF provides a scheme to exchange such information among interested=0A= parties. However, the detailed common format to describe such=0A= information is not defined in the IODEF base document.=0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 3]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= On the other hand, to describe those information and to faciliate=0A= exchange, a structured format for that is already available. Major=0A= of them are CAPEC, CEE, CPE, CVE, CVSS, CWE, CWSS, OVAL, and XCCDF.=0A= By embedding them into the IODEF document, the documnt can convey=0A= more detailed contents to the receivers, and the document can be=0A= easily reused.=0A= =0A= These structured cybersecuriity information facilitates cybersecurity=0A= operation at the receiver side. Since the information is machine-=0A= readable, the data can be processed by computers. That expedites the=0A= automation of cybersecurity operations=0A= =0A= For instance, an organization wishing to report a security incident=0A= wants to describe what vulnerability was exploited. Then the sender=0A= can simply use IODEF, where an CAPEC record is embedded instead of=0A= describing everything in free format text. Receiver can also=0A= identify the needed details of the attack pattern by looking up some=0A= of the xml tags defined by CAPEC. Receiver can accummulate the=0A= attack pattern information (CAPEC record) in its database and could=0A= distribute it to the interested parties if needed, without needing=0A= human interventions.=0A= =0A= =0A= 4. Extension Definition=0A= =0A= This draft extends IODEF to embed structured cybersecurity=0A= information by introducing new classes, with which these information=0A= can be embedded inside IODEF document as element contents of=0A= AdditionalData and RecordItem classes.=0A= =0A= The IODEF Incident element ([RFC5070], Section 3.2) is summarized=0A= below. It is expressed in Unified Modeling Language (UML) syntax as=0A= used in the IODEF specification. The UML representation is for=0A= illustrative purposes only; elements are specified in XML as defined=0A= in Appendix A.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 4]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= +--------------------+=0A= | Incident |=0A= +--------------------+=0A= | ENUM purpose |<>----------[ IncidentID ]=0A= | STRING ext-purpose |<>--{0..1}--[ AlternativeID ]=0A= | ENUM lang |<>--{0..1}--[ RelatedActivity ]=0A= | ENUM restriction |<>--{0..1}--[ DetectTime ]=0A= | |<>--{0..1}--[ StartTime ]=0A= | |<>--{0..1}--[ EndTime ]=0A= | |<>----------[ ReportTime ]=0A= | |<>--{0..*}--[ Description ]=0A= | |<>--{1..*}--[ Assessment ]=0A= | | |<>--[ AdditionalData ]=0A= | | |<>--[ Scoring ]=0A= | |<>--{0..*}--[ Method ]=0A= | | |<>--[ AdditionalData ]=0A= | | |<>--[ AttackPattern ]=0A= | | |<>--[ Vulnerability ]=0A= | | |<>--[ Weakness ]=0A= | |<>--{1..*}--[ Contact ]=0A= | |<>--{0..*}--[ EventData ]=0A= | | |<>--[ Flow ]=0A= | | | |<>--[ System ]=0A= | | | |<>--[ AdditionalData ]=0A= | | | |<>--[ = PlatformID ]=0A= | | |<>--[ Expectation ]=0A= | | |<>--[ Record ]=0A= | | |<>--[ RecordData ]=0A= | | |<>--[ RecordItem ]=0A= | | |<>--[ = EventReport ]=0A= | |<>--{0..1}--[ History ]=0A= | |<>--{0..*}--[ AdditionalData ]=0A= | | |<>--[ Remediation ]=0A= +--------------------+=0A= =0A= This extension defines the following seven elements.=0A= =0A= 4.1. Scoring=0A= =0A= A Scoring consists of an extension to the=0A= Incident.Assessment.AdditionalData element with a dtype of "xml".=0A= Its elements describe the scoring of the severity of incidents or=0A= events.=0A= =0A= It is recommended that Assessment class SHOULD contain this element=0A= whenever available.=0A= =0A= A Scoring class is structured as follows.=0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 5]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= +--------------------+=0A= | Scoring |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(0..1)--[ Score ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cvss"=0A= and "cwss" could be specified here. Note that the specification=0A= name should be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Score: Zero or one. ML_STRING. Arbitrary information structured by=0A= the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.2. AttackPattern=0A= =0A= An AttackPattern consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". Its=0A= elements describe attack patterns of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain this element=0A= whenever available.=0A= =0A= An AttackPattern class is structured as follows.=0A= =0A= +--------------------+=0A= | AttackPattern |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 6]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= The AttackPattern class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "capec"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.3. Vulnerability=0A= =0A= A Vulnerability consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". Its=0A= elements describe the (candidate) vulnerabilities of incidents or=0A= events.=0A= =0A= It is recommended that Method class SHOULD contain this element=0A= whenever available.=0A= =0A= A Vulnerability element is structured as follows.=0A= =0A= +--------------------+=0A= | Vulnerability |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cve"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 7]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.4. Weakness=0A= =0A= A Weakness consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". Its=0A= elements describe the weakness types of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain this element=0A= whenever available.=0A= =0A= A Weakness element is structured as follows.=0A= =0A= +--------------------+=0A= | Weakness |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cwe"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 8]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= 4.5. PlatformID=0A= =0A= A PlatformID consists of an extension to the=0A= Incident.EventData.Flow.System.AdditionalData element with a dtype of=0A= "xml". Its elements identify a software platform.=0A= =0A= It is recommended that System class SHOULD contain this element=0A= whenever available.=0A= =0A= A PlatformID element is structured as follows.=0A= =0A= +--------------------+=0A= | PlatformID |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ ID ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cve"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= ID: One or more. ML_STRING. Arbitrary information structured by=0A= the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.6. EventReport=0A= =0A= An EventReport consists of an extension to the=0A= Incident.EventData.Record.RecordData.RecordItem element with a dtype=0A= of "xml". Its elements embed structured event reports.=0A= =0A= It is recommended that RecordItem class SHOULD contain this element=0A= whenever available.=0A= =0A= An EventReport element is structured as follows.=0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 9]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= +--------------------+=0A= | EventRecord |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cee"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.7. Remediation=0A= =0A= A Remediation consists of an extension to the Incident.AdditionalData=0A= element with a dtype of "xml". Its elements describe incident=0A= remediation infomration including instructions.=0A= =0A= It is recommended that Incident class SHOULD contain this element=0A= whenever available.=0A= =0A= A Remediation class is structured as follows.=0A= =0A= +--------------------+=0A= | Remediation |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 10]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "oval",=0A= "ocil", and "xccdf" could be specified here. Note that the=0A= specification name should be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= =0A= 5. Examples=0A= =0A= This section provides examples of an incident encoded in the IODEF.=0A= These examples do not necessarily represent the only way to encode a=0A= particular incident.=0A= =0A= 5.1. Reporting an attack=0A= =0A= An example of a CSIRT reporting an attack.=0A= =0A= =0A= =0A= xsi:schemaLocation=3D"urn:ietf:params:xml:schema:iodef-1.0">=0A= =0A= 189493=0A= 2001-09-13T23:19:24+00:00=0A= Incident report in company xx=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= capec=0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 11]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= 1.6=0A= [embed data in CAPEC format]=0A= =0A= =0A= cve=0A= [embed data in CVE format]=0A= =0A= =0A= cwe=0A= 5.0=0A= [embed data in CVE format]=0A= =0A= =0A= =0A= =0A= Example.com CSIRT=0A= example-com=0A= contact@csirt.example.com=0A= =0A= =0A= =0A= =0A= =0A=
192.0.2.200
=0A= 57=0A= =0A= =0A= =0A= =0A=
192.0.2.16/28
=0A= =0A= =0A= 80=0A= =0A= =0A= =0A= cpe=0A= 2.2=0A= [embed identifier in CPE format]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 12]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= 2001-09-13T18:11:21+02:00=0A= a Web-server event record=0A= =0A= =0A= cee=0A= 1.0=0A= [embed data in CEE format]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 2001-09-14T08:19:01+00:00=0A= Notification sent to=0A= constituency-contact@192.0.2.200=0A= =0A= =0A= =0A= =0A= oval=0A= 5.9=0A= [embed OVAL-structured information here]=0A= =0A= =0A= xccdf=0A= 1.2=0A= [embed XCCDF-structured information here]=0A= =0A= =0A= =0A= =0A= =0A= Figure 1: Example UML Element Diagram=0A= =0A= =0A= 6. Security Considerations=0A= =0A= [Note: the sentences below are from rfc5901. I'll review later when=0A= the draft becomes more mature]=0A= =0A= This document specifies a format for encoding a particular class of=0A= security incidents appropriate for exchange across organizations. As=0A= merely a data representation, it does not directly introduce security=0A= issues. However, it is guaranteed that parties exchanging instances=0A= of this specification will have certain concerns. For this reason,=0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 13]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= the underlying message format and transport protocol used MUST ensure=0A= the appropriate degree of confidentiality, integrity, and=0A= authenticity for the specific environment.=0A= =0A= Organizations that exchange data using this document are URGED to=0A= develop operating procedures that document the following areas of=0A= concern.=0A= =0A= 6.1. Transport-Specific Concerns=0A= =0A= The critical security concerns are that phishing activity reports may=0A= be falsified or the PhraudReport may become corrupt during transit.=0A= In areas where transmission security or secrecy is questionable, the=0A= application of a digital signature and/or message encryption on each=0A= report will counteract both of these concerns. We expect that each=0A= exchanging organization will determine the need, and mechanism, for=0A= transport protection.=0A= =0A= 6.2. Using the iodef:restriction Attribute=0A= =0A= In some instances, data values in particular elements may contain=0A= data deemed sensitive by the reporter. Although there are no=0A= general-purpose rules on when to mark certain values as "private" or=0A= "need-to-know" via the iodef:restriction attribute, the reporter is=0A= cautioned not to apply element-level sensitivity markings unless they=0A= believe the receiving party (i.e., the party they are exchanging the=0A= event report data with) has a mechanism to adequately safeguard and=0A= process the data as marked.=0A= =0A= =0A= 7. IANA Considerations=0A= =0A= This document uses URNs to describe XML namespaces and XML schemas=0A= conforming to a registry mechanism described in [RFC3688].=0A= =0A= Registration request for the IODEF My-Extension namespace:=0A= =0A= URI: urn:ietf:params:xml:ns:iodef-msmspecs-1.0=0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: None=0A= =0A= Registration request for the IODEF My-Extension XML schema:=0A= =0A= URI: urn:ietf:params:xml:schema:iodef-msmspecs-1.0=0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 14]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: Refer here to the XML Schema in the appendix of the document.=0A= =0A= =0A= 8. Appendix: XML Schema Definition for Extension=0A= =0A= The XML Schema describing the elements defined in the Extension=0A= Defintion section is given here. Each of the examples in section=0A= Section 5 should be verified to validate against this schema by=0A= automated tools.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 15]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 16]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Example Schema Diagram=0A= =0A= =0A= 9. References=0A= =0A= 9.1. Normative References=0A= =0A= [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident=0A= Object Description Exchange Format", RFC 5070,=0A= December 2007.=0A= =0A= [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",=0A= RFC 6045, November 2010.=0A= =0A= 9.2. Informative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing=0A= Architecture", RFC 2373, July 1998.=0A= =0A= [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform=0A= Resource Identifiers (URI): Generic Syntax", RFC 2396,=0A= August 1998.=0A= =0A= [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,=0A= April 2001.=0A= =0A= [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the=0A= Internet: Timestamps", RFC 3339, July 2002.=0A= =0A= [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC=0A= Text on Security Considerations", BCP 72, RFC 3552,=0A= July 2003.=0A= =0A= [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol=0A= (LDAP): Schema for User Applications", RFC 4519,=0A= June 2006.=0A= =0A= [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an=0A= IANA Considerations Section in RFCs", BCP 26, RFC 5226,=0A= May 2008.=0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 17]=0A= =0C=0A= Internet-Draft IODEF-ext-msmspecs Aug 2011=0A= =0A= =0A= [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to=0A= Uniform Resource Identifiers (URI) Dynamic Delegation=0A= Discovery System (DDDS) Application (ENUM)", RFC 6116,=0A= March 2011.=0A= =0A= =0A= Author's Address=0A= =0A= X XXXX=0A= XXXX=0A= xxx=0A= xxx=0A= xxx=0A= =0A= Phone: xxx=0A= Email: xxx=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= XXXX Expires February 6, 2012 [Page 18]=0A= =0C=0A= ------=_NextPart_000_00F6_01CC53A4.9E8B8F30-- From takeshi_takahashi@nict.go.jp Mon Aug 8 20:50:18 2011 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 4444B11E809F for ; Mon, 8 Aug 2011 20:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HELO_EQ_JP=1.244, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qac3miDs9cCD for ; Mon, 8 Aug 2011 20:50:04 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE32A11E8091 for ; Mon, 8 Aug 2011 20:50:03 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id p793oR2O011521; Tue, 9 Aug 2011 12:50:27 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id p793oQeP008521; Tue, 9 Aug 2011 12:50:27 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id p793oQ54008511; Tue, 9 Aug 2011 12:50:26 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 110A216212; Tue, 9 Aug 2011 12:50:26 +0900 (JST) Received: from tbntakahashi (unknown [133.243.119.200]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 0421716210; Tue, 9 Aug 2011 12:50:26 +0900 (JST) From: "Takeshi Takahashi" To: Date: Tue, 9 Aug 2011 12:49:48 +0900 Message-ID: <000d01cc5647$62c4c070$284e4150$@go.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01CC5692.D2AC6870" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcxWR2J9VNIFG703SAaz5tSdZ4c7Zg== Content-Language: ja Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 09 Aug 2011 03:50:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01CC5692.D2AC6870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01CC5692.D2AC8F80" ------=_NextPart_001_000F_01CC5692.D2AC8F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you for those of you who kindly gave me off-line messages . Let me share the draft with some minor modifications. Sincerely, Take 2011/8/5 Takeshi Takahashi : > Dear all, > > > > The attached is the tentative version of the draft prepared based on the > comments I've received in this mailing list (Thanks a lot for that). > > It would be great if you could provide some comments on Clause 4, where the > IODEF extension is defined. > > > > As you know, there are many ways to embed structured information (e.g. CVE > and CAPEC) in IODEF since IODEF is designed to be very flexible. > > Thus, I would be happy to change and develop the draft further based on your > comments. > > > > I would like to welcome any comments on that. > > > > By the way, I will be on vacation, thus my response might be slow, sorry for > the inconvenience. > > > > Take > > > > PS: I've changed the title of the email. > > > > > > 2011/7/29 > >> > >> Thank you, the approach sounds good, especially since it is in use today > >> by at least the Research and Education ISAC. Do others have opinions on > >> the proposal here? > >> > >> Thanks for writing the first draft Take! > >> > >> Best regards, > >> Kathleen > >> ________________________________________ > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Takeshi > >> Takahashi [takeshi_takahashi@nict.go.jp] > >> Sent: Friday, July 29, 2011 9:20 AM > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> Thank you, Bob, for the email. > >> I also like Tom's suggestion very much. > >> Let me work on the "draft" of the draft for a while, then come back to you > >> later. > >> > >> Take > >> > >> -----Original Message----- > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >> Sent: Friday, July 29, 2011 9:10 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >> wes@ren-isac.net; mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> I also like how this is evolving. > >> > >> I think, as Tom's suggestions pointed, that any and all of the useful > >> types > >> of information that can help with understanding, diagnosing, and getting > >> ahead of an incident should be added but for now we should focus on those > >> the most established and well articulated. > >> > >> This can be the compliance/patch/configuration/platform information > >> related > >> to the SCAP use case, or event signature/attack pattern/traffic > >> characteristics from events, or the vulnerability/threat characterization > >> space. > >> > >> I look forward to Taki's draft to see how he suggests positioning these > >> concepts. > >> > >> Bob > >> > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >> > I like where this is headed. > >> > > >> > Thanks Takeshi. I look forward to your draft. It will give us something > >> real to discuss. I appreciate you jumping in and getting this started. > >> > > >> > One question that I am not clear on. What do we envision as the actual > >> set > >> of deliverables? From and SCAP related perspective, are we looking at a > >> single draft covering all the extensions? > >> > > >> > Kent > >> > > >> > Kent Landfield > >> > Director Content Strategy, Architecture and Standards > >> > > >> > McAfee, Inc. > >> > 5000 Headquarters Dr. > >> > Plano, Texas 75024 > >> > > >> > Direct: +1.972.963.7096 > >> > Mobile: +1.817.637.8026 > >> > Web: www.mcafee.com > >> > > >> > From: Takeshi > >> > Takahashi >> > o.jp>> > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > >> > To: > >> > "Thomas.Millar@us-cert.gov" >> > illar@us-cert.gov>, > >> > "wes@ren-isac.net" >> > s@ren-isac.net>>, > >> > "mile@ietf.org" >> > rg>> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > Thank you for the email, Tom. > >> > > >> > So, here is what the draft needs to describe (if I understand Wes and > >> > Tom correctly). > >> > > >> > The draft should define ext-dtype (an attribute of AdditionalData > >> > Class) to identify the information type, rather than defining new > >> > class under AdditionalData. > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec, > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal and > >> > could easily embed various structured information (CVE etc.) in the > >> > EventData.Record.RecordData.AdditionalData field. > >> > Then "should" statement should be carefully placed in the text of > >> > relevant class. > >> > > >> > I'll prepare some draft so that we could discuss and advance further. > >> > > >> > Take > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > >> > Thomas.Millar@us-cert.gov > >> > Sent: Thursday, July 28, 2011 6:28 PM > >> > To: wes@ren-isac.net; > >> > mile@ietf.org > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > I think this approach makes more sense. One of the things I think > >> > could be helpful is to have a number of SHOULD statements further > >> > describing the possible types of other documents that would be > >> > expected to ride under the AdditionalData elements of each class (not > >> just > >> EventData). > >> > What I'm thinking of looks like this (very unpolished): > >> > > >> > "The Method Class:AdditionalData class SHOULD contain data elements > >> > that describe the methods, tools or techniques employed to cause the > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the > >> > method such as CVSS, CWSS, or CCE." > >> > > >> > "The Expectation Class[...] SHOULD contain data elements which > >> > describe configuration changes, detection heuristics, or [* (legal > >> > authorization?)] to assist in executing or implementing the requested > >> > action, such as XCCDF, OCIL, OVAL, etc" > >> > > >> > This could go towards encouraging better or at least more consistent > >> > use of "boundary objects" in the substance of incident reports. I > >> > could also go on about greater automation and such but that's probably > >> > out of scope for this e-mail. > >> > > >> > > >> > - Tom Millar, US-CERT > >> > > >> > thomas.millar@us-cert.gov > >> > BB: thomas.millar@dhs.gov / > >> > 202-631-1915 > >> > 24x7: soc@us-cert.gov / 888-282-0870 > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >> > Sent: Thursday, July 28, 2011 11:08 AM > >> > To: mile@ietf.org > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >> > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > >> > > >> > i've been sticking other "XML like" records under this (icsg1.1 data, > >> > etc...). > >> > > >> > pretty easy to do, just generate the "other standards" xml (or json or > >> > whatever), embed it there. turns iodef into a sharing platform for > >> > other data-types w/o having to extend it too much. > >> > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >> > > >> > So, maybe we could extend the IODEF as described in Figure 1 of the > >> > attached txt file. (correct me if I'm wrong) We could define > >> > Incident.EventData.AdditionalData elements and describe them by using > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >> > Regarding OVAL, we might define Incident.AdditionalData element, but I > >> > > >> > am not sure at this moment, thus is not described in the figure yet. > >> > I would like to tackle CAPEC first since I believe Kent would like to > >> > tackle CVE and CAPEC. > >> > > >> > -- > >> > Wes > >> > claimid.com/wesyoung > >> > soc@ren-isac.net > >> > > >> > * Wes Young> > >> > * 0xDDB6E946 - Unverified(L) > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > . > >> > > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > -- -- Takeshi Takahashi, Ph.D. +81 80 3490 2971 http://www.taketaka.com/ ------=_NextPart_001_000F_01CC5692.D2AC8F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you = for those of you who kindly gave me off-line messages .

 

Let me share = the draft with some minor modifications.

 

Sincerely,
Take

 

 

2011/8/5 = Takeshi Takahashi <takeshi_takahashi@nict.go.jp>:

> Dear all,

> 

> 

> 

> The = attached is the tentative version of the draft prepared based on = the

> comments I’ve received = in this mailing list (Thanks a lot for that).

> 

> It = would be great if you could provide some comments on Clause 4, where = the

> IODEF extension is = defined.

> 

> 

> 

> As = you know, there are many ways to embed structured information (e.g. = CVE

> and CAPEC) in IODEF since = IODEF is designed to be very flexible.

> 

> = Thus, I would be happy to change and develop the draft further based on = your

> comments.

> 

> 

> 

> I = would like to welcome any comments on that.

> 

> 

> 

> By = the way, I will be on vacation, thus my response might be slow, sorry = for

> the = inconvenience.

> 

> 

> 

> = Take

> 

> 

> 

> PS: = I’ve changed the title of the email.

> 

> 

> 

> 

> 

> = 2011/7/29 <kathleen.moriarty@emc.com>

> 

>> =

> 

>> Thank you, the approach sounds good, = especially since it is in use today

> 

>> = by at least the Research and Education ISAC.  Do others have = opinions on

> 

>> = the proposal here?

> 

>> =

> 

>> Thanks for writing the first draft = Take!

> 

>>

> 

>> = Best regards,

> 

>> = Kathleen

> 

>> = ________________________________________

> 

>> = From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Takeshi

> 

>> Takahashi = [takeshi_takahashi@nict.go.jp]

> 

>> = Sent: Friday, July 29, 2011 9:20 AM

> 

>> = To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com

> 

>> = Cc: mile@ietf.org

> 

>> = Subject: Re: [mile] Updated presentation from Side = meeting

> 

>>

> 

>> = Thank you, Bob, for the email.

> 

>> = I also like Tom's suggestion very much.

> 

>> = Let me work on the "draft" of the draft for a while, then come = back to you

> 

>> = later.

> 

>>

> 

>> = Take

> 

>>

> 

>> = -----Original Message-----

> 

>> = From: Martin, Robert A. [mailto:ramartin@mitre.org]

> 

>> = Sent: Friday, July 29, 2011 9:10 AM

> 

>> = To: Kent_Landfield@McAfee.com

> 

>> = Cc: takeshi_takahashi@nict.go.jp; = Thomas.Millar@us-cert.gov;

> 

>> = wes@ren-isac.net; mile@ietf.org

> 

>> = Subject: Re: [mile] Updated presentation from Side = meeting

> 

>>

> 

>> = I also like how this is evolving.

> 

>> =

> 

>> I think, as Tom's suggestions pointed, that = any and all of the useful

> 

>> = types

> 

>> of information that can help with = understanding, diagnosing, and getting

> 

>> = ahead of an incident should be added but for now we should focus on = those

> 

>> the most established and well = articulated.

> 

>> =

> 

>> This can be the = compliance/patch/configuration/platform information

> 

>> = related

> 

>> to the SCAP use case, or event = signature/attack pattern/traffic

> 

>> = characteristics from events, or the vulnerability/threat = characterization

> 

>> = space.

> 

>>

> 

>> = I look forward to Taki's draft to see how he suggests positioning = these

> 

>> concepts.

> 

>> =

> 

>> Bob

> 

>> =

> 

>> On 7/28/11 10:13 PM, = Kent_Landfield@McAfee.com wrote:

> 

>> = > I like where this is headed.

> 

>> = >

> 

>> > Thanks Takeshi.  I look forward to = your draft. It will give us something

> 

>> = real to discuss. I appreciate you jumping in and getting this = started.

> 

>> >

> 

>> = > One question that I am not clear on. What do we envision as the = actual

> 

>> set

> 

>> = of deliverables?  From and SCAP related perspective, are we looking = at a

> 

>> single draft covering all the = extensions?

> 

>> = >

> 

>> > Kent

> 

>> = >

> 

>> > Kent Landfield

> 

>> = > Director Content Strategy, Architecture and = Standards

> 

>> >

> 

>> = > McAfee, Inc.

> 

>> = > 5000 Headquarters Dr.

> 

>> = > Plano, Texas 75024

> 

>> = >

> 

>> > Direct: +1.972.963.7096

> 

>> = > Mobile: +1.817.637.8026

> 

>> = > Web: www.mcafee.com<http://www.mcafee.com/>

> 

>> = >

> 

>> > From: Takeshi

> 

>> = > = Takahashi<takeshi_takahashi@nict.go.jp<mailto:takeshi_takahashi@nic= t.g

> 

>> > o.jp>>

> 

>> = > Date: Thu, 28 Jul 2011 18:21:56 -0500

> 

>> = > To:

> 

>> > = "Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>&q= uot;<Thomas.M

> 

>> = > = illar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>>,=

> 

>> > = "wes@ren-isac.net<mailto:wes@ren-isac.net>"<wes@ren-is= ac.net<mailto:we

> 

>> = > s@ren-isac.net>>,

> 

>> = > = "mile@ietf.org<mailto:mile@ietf.org>"<mile@ietf.org<= ;mailto:mile@ietf.o

> 

>> = > rg>>

> 

>> = > Subject: Re: [mile] Updated presentation from Side = meeting

> 

>> >

> 

>> = > Thank you for the email, Tom.

> 

>> = >

> 

>> > So, here is what the draft needs to = describe (if I understand Wes and

> 

>> = > Tom correctly).

> 

>> = >

> 

>> > The draft should define ext-dtype (an = attribute of AdditionalData

> 

>> = > Class) to identify the information type, rather than defining = new

> 

>> > class under = AdditionalData.

> 

>> = > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, = ext-capec,

> 

>> = > ext-cvss, ext-cwss, In this way, we could keep the change minimal = and

> 

>> > could easily embed various structured = information (CVE etc.) in the

> 

>> = > EventData.Record.RecordData.AdditionalData field.

> 

>> = > Then "should" statement should be carefully placed in the = text of

> 

>> > relevant class.

> 

>> = >

> 

>> > I'll prepare some draft so that we could = discuss and advance further.

> 

>> = >

> 

>> > Take

> 

>> = >

> 

>> >

> 

>> = >

> 

>> > -----Original = Message-----

> 

>> = > From: = mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>

<= p class=3DMsoNormal>> 

>> > [mailto:mile-bounces@ietf.org] On Behalf = Of

> 

>> > = Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>

> 

>> > Sent: Thursday, July 28, 2011 6:28 = PM

> 

>> > To: = wes@ren-isac.net<mailto:wes@ren-isac.net>;

> 

>> = > mile@ietf.org<mailto:mile@ietf.org>

> 

>> = > Subject: Re: [mile] Updated presentation from Side = meeting

> 

>> >

> 

>> = > I think this approach makes more sense. One of the things I = think

> 

>> > could be helpful is to have a number of = SHOULD statements further

> 

>> = > describing the possible types of other documents that would = be

> 

>> > expected to ride under the = AdditionalData elements of each class (not

> 

>> = just

> 

>> EventData).

> 

>> = > What I'm thinking of looks like this (very = unpolished):

> 

>> = >

> 

>> > "The Method Class:AdditionalData = class SHOULD contain data elements

> 

>> = > that describe the methods, tools or techniques employed to cause = the

> 

>> > incident, such as CAPEC, CWE, CVE, CVRF, = or metadata concerning the

> 

>> = > method such as CVSS, CWSS, or CCE."

> 

>> = >

> 

>> > "The Expectation Class[...] SHOULD = contain data elements which

> 

>> = > describe configuration changes, detection heuristics, or [* = (legal

> 

>> > authorization?)] to assist in executing = or implementing the requested

> 

>> = > action, such as XCCDF, OCIL, OVAL, etc"

> 

>> = >

> 

>> > This could go towards encouraging better = or at least more consistent

> 

>> = > use of "boundary objects" in the substance of incident = reports. I

> 

>> = > could also go on about greater automation and such but that's = probably

> 

>> > out of scope for this = e-mail.

> 

>> >

> 

>> = >

> 

>> > - Tom Millar, US-CERT

> 

>> = >

> 

>> > = thomas.millar@us-cert.gov<mailto:thomas.millar@us-cert.gov>

> 

>> > BB: = thomas.millar@dhs.gov<mailto:thomas.millar@dhs.gov>  = /

> 

>> > 202-631-1915

> 

>> = > 24x7: soc@us-cert.gov<mailto:soc@us-cert.gov>  / = 888-282-0870

> 

>> = > -----Original Message-----

> 

>> = > From: = mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>

<= p class=3DMsoNormal>> 

>> > [mailto:mile-bounces@ietf.org] On Behalf = Of Wes Young

> 

>> = > Sent: Thursday, July 28, 2011 11:08 AM

> 

>> = > To: mile@ietf.org<mailto:mile@ietf.org>

> 

>> = > Subject: Re: [mile] Updated presentation from Side = meeting

> 

>> >

> 

>> = > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 = AM

> 

>> >

> 

>> = > http://tools.ietf.org/html/rfc5070#section-3.19

> 

>> = >

> 

>> > i've been sticking other "XML = like" records under this (icsg1.1 data,

> 

>> = > etc...).

> 

>> = >

> 

>> > pretty easy to do, just generate the = "other standards" xml (or json or

> 

>> = > whatever), embed it there. turns iodef into a sharing platform = for

> 

>> > other data-types w/o having to extend it = too much.

> 

>> >

> 

>> = > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi = wrote:

> 

>> >

> 

>> = > So, maybe we could extend the IODEF as described in Figure 1 of = the

> 

>> > attached txt file. (correct me if I'm = wrong) We could define

> 

>> = > Incident.EventData.AdditionalData elements and describe them by = using

> 

>> > CPE, CVE/CWE, CVSS/CWSS, and = CAPEC.

> 

>> > Regarding OVAL, we might define = Incident.AdditionalData element, but I

> 

>> = >

> 

>> > am not sure at this moment, thus is not = described in the figure yet.

> 

>> = > I would like to tackle CAPEC first since I believe Kent would like = to

> 

>> > tackle CVE and CAPEC.

> 

>> = >

> 

>> > --

> 

>> = > Wes

> 

>> > claimid.com/wesyoung

> 

>> = > soc@ren-isac.net<mailto:soc@ren-isac.net>

> 

>> = >

> 

>> > * Wes = Young<wes@ren-isac.net<mailto:wes@ren-isac.net>>

> 

>> > * 0xDDB6E946 - = Unverified(L)

> 

>> = > _______________________________________________

> 

>> = > mile mailing list

> 

>> = > mile@ietf.org<mailto:mile@ietf.org>

> 

>> = > https://www.ietf.org/mailman/listinfo/mile

> 

>> = > _______________________________________________

> 

>> = > mile mailing list

> 

>> = > mile@ietf.org<mailto:mile@ietf.org>

> 

>> = > https://www.ietf.org/mailman/listinfo/mile

> 

>> = >

> 

>> > = _______________________________________________

> 

>> = > mile mailing list

> 

>> = > mile@ietf.org<mailto:mile@ietf.org>

> 

>> = > https://www.ietf.org/mailman/listinfo/mile

> 

>> = >

> 

>> > = _______________________________________________

> 

>> = > mile mailing list

> 

>> = > mile@ietf.org

> 

>> = > https://www.ietf.org/mailman/listinfo/mile

> 

>> = > .

> 

>> >

> 

>> =

> 

>> = _______________________________________________

> 

>> = mile mailing list

> 

>> = mile@ietf.org

> 

>> = https://www.ietf.org/mailman/listinfo/mile

> 

> 

> 

> 

> 

> 

 

 

 

-- =

--

Takeshi Takahashi, Ph.D.

+81 80 3490 2971

http://www.taketaka.com/

 

------=_NextPart_001_000F_01CC5692.D2AC8F80-- ------=_NextPart_000_000E_01CC5692.D2AC6870 Content-Type: text/plain; name="draft-takahashi-mile-sci-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-takahashi-mile-sci-01.txt" =0A= =0A= =0A= Individual Submission T. Takahashi=0A= Internet-Draft NICT=0A= Intended status: Informational K. Landfield=0A= Expires: February 10, 2012 McAfee=0A= Y. Kadobayashi=0A= NICT=0A= Aug 9, 2011=0A= =0A= =0A= IODEF-extension to support structured cybersecurity information=0A= draft-takahashi-mile-sci-01.txt=0A= =0A= Abstract=0A= =0A= This document extends the Incident Object Description Exchange Format=0A= (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched=0A= cybersecurity information exchange among cybersecurity entities by=0A= embedding structured information formatted by the following=0A= specifications: CAPEC[TM], CEE[TM], CPE[TM], CVE(R), CVSS, CWE[TM],=0A= CWSS[TM], OVAL(R), and XCCDF.=0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on February 10, 2012.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2011 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 1]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4=0A= 4.1. Scoring . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 4.2. AttackPattern . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4.3. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 7=0A= 4.4. Weakness . . . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 4.5. PlatformID . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.6. EventReport . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.7. Remediation . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11=0A= 5.1. Reporting an attack . . . . . . . . . . . . . . . . . . . 11=0A= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13=0A= 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 14=0A= 6.2. Using the iodef:restriction Attribute . . . . . . . . . . 14=0A= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14=0A= 8. Appendix: XML Schema Definition for Extension . . . . . . . . 15=0A= 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17=0A= 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17=0A= 9.2. Informative References . . . . . . . . . . . . . . . . . . 17=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 2]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 1. Introduction=0A= =0A= Cyber attacks are getting more sophisticated, and their numbers are=0A= increasing day by day. To cope with such situation, incident=0A= information needs to be reported, exchanged, and shared among=0A= organizations. IODEF is one of the tools enabling such exchange, and=0A= is already in use by various organizations.=0A= =0A= On the other hand, there exist various other activities facilitating=0A= detailed and structured description of cybersecurity information,=0A= major of which includes CAPEC, CEE, CPE, CVE, CVSS, CWE, CWSS, OVAL,=0A= and XCCDF. Since such structured description facilitates=0A= cybersecurity operations, it would be beneficial to embed and convey=0A= these information inside IODEF document.=0A= =0A= To enable that, this document extends the IODEF to embed and convey=0A= various structured cybersecurity information, with which=0A= cybersecurity operations can be facilitated. Since IODEF defines a=0A= flexible and extensible format and supports a granular level of=0A= specificity, this document defines an extension to IODEF instead of=0A= defining a new report format. It specifies several new data types=0A= and describes recommended usage of the extensions. For clarity, and=0A= to eliminate duplication, only the additional structures necessary=0A= for describing the exhange of such structured information are=0A= provided.=0A= =0A= =0A= 2. Terminology=0A= =0A= The terminology used in this document follows the one defined in=0A= [RFC5070].=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= =0A= 3. Applicability=0A= =0A= To maintain cybersecurity, organization needs to exchange=0A= cybersecurity information, which includes the following information:=0A= attack pattern, platform information, vulnerability and weakness,=0A= countermeasure instruction, computer event log, and the severity.=0A= =0A= IODEF provides a scheme to exchange such information among interested=0A= parties. However, the detailed common format to describe such=0A= information is not defined in the IODEF base document.=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 3]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= On the other hand, to describe those information and to faciliate=0A= exchange, a structured format for that is already available. Major=0A= of them are CAPEC, CEE, CPE, CVE, CVSS, CWE, CWSS, OVAL, and XCCDF.=0A= By embedding them into the IODEF document, the documnt can convey=0A= more detailed contents to the receivers, and the document can be=0A= easily reused.=0A= =0A= These structured cybersecuriity information facilitates cybersecurity=0A= operation at the receiver side. Since the information is machine-=0A= readable, the data can be processed by computers. That expedites the=0A= automation of cybersecurity operations=0A= =0A= For instance, an organization wishing to report a security incident=0A= wants to describe what vulnerability was exploited. Then the sender=0A= can simply use IODEF, where an CAPEC record is embedded instead of=0A= describing everything in free format text. Receiver can also=0A= identify the needed details of the attack pattern by looking up some=0A= of the xml tags defined by CAPEC. Receiver can accummulate the=0A= attack pattern information (CAPEC record) in its database and could=0A= distribute it to the interested parties if needed, without needing=0A= human interventions.=0A= =0A= =0A= 4. Extension Definition=0A= =0A= This draft extends IODEF to embed structured cybersecurity=0A= information by introducing new classes, with which these information=0A= can be embedded inside IODEF document as element contents of=0A= AdditionalData and RecordItem classes.=0A= =0A= The IODEF Incident element ([RFC5070], Section 3.2) is summarized=0A= below. It is expressed in Unified Modeling Language (UML) syntax as=0A= used in the IODEF specification. The UML representation is for=0A= illustrative purposes only; elements are specified in XML as defined=0A= in Appendix A.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 4]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= +--------------------+=0A= | Incident |=0A= +--------------------+=0A= | ENUM purpose |<>----------[ IncidentID ]=0A= | STRING ext-purpose |<>--{0..1}--[ AlternativeID ]=0A= | ENUM lang |<>--{0..1}--[ RelatedActivity ]=0A= | ENUM restriction |<>--{0..1}--[ DetectTime ]=0A= | |<>--{0..1}--[ StartTime ]=0A= | |<>--{0..1}--[ EndTime ]=0A= | |<>----------[ ReportTime ]=0A= | |<>--{0..*}--[ Description ]=0A= | |<>--{1..*}--[ Assessment ]=0A= | | |<>--[ AdditionalData ]=0A= | | |<>--[ Scoring ]=0A= | |<>--{0..*}--[ Method ]=0A= | | |<>--[ AdditionalData ]=0A= | | |<>--[ AttackPattern ]=0A= | | |<>--[ Vulnerability ]=0A= | | |<>--[ Weakness ]=0A= | |<>--{1..*}--[ Contact ]=0A= | |<>--{0..*}--[ EventData ]=0A= | | |<>--[ Flow ]=0A= | | | |<>--[ System ]=0A= | | | |<>--[ AdditionalData ]=0A= | | | |<>--[ = PlatformID ]=0A= | | |<>--[ Expectation ]=0A= | | |<>--[ Record ]=0A= | | |<>--[ RecordData ]=0A= | | |<>--[ RecordItem ]=0A= | | |<>--[ = EventReport ]=0A= | |<>--{0..1}--[ History ]=0A= | |<>--{0..*}--[ AdditionalData ]=0A= | | |<>--[ Remediation ]=0A= +--------------------+=0A= =0A= This extension defines the following seven elements.=0A= =0A= 4.1. Scoring=0A= =0A= A Scoring consists of an extension to the=0A= Incident.Assessment.AdditionalData element with a dtype of "xml".=0A= Its elements describe the scoring of the severity of incidents or=0A= events.=0A= =0A= It is recommended that Assessment class SHOULD contain this element=0A= whenever available.=0A= =0A= A Scoring class is structured as follows.=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 5]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= +--------------------+=0A= | Scoring |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(0..1)--[ Score ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cvss"=0A= and "cwss" could be specified here. Note that the specification=0A= name should be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Score: Zero or one. ML_STRING. Arbitrary information structured by=0A= the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.2. AttackPattern=0A= =0A= An AttackPattern consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". Its=0A= elements describe attack patterns of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain this element=0A= whenever available.=0A= =0A= An AttackPattern class is structured as follows.=0A= =0A= +--------------------+=0A= | AttackPattern |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 6]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= The AttackPattern class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "capec"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.3. Vulnerability=0A= =0A= A Vulnerability consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". Its=0A= elements describe the (candidate) vulnerabilities of incidents or=0A= events.=0A= =0A= It is recommended that Method class SHOULD contain this element=0A= whenever available.=0A= =0A= A Vulnerability element is structured as follows.=0A= =0A= +--------------------+=0A= | Vulnerability |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cve"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 7]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.4. Weakness=0A= =0A= A Weakness consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". Its=0A= elements describe the weakness types of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain this element=0A= whenever available.=0A= =0A= A Weakness element is structured as follows.=0A= =0A= +--------------------+=0A= | Weakness |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cwe"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 8]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 4.5. PlatformID=0A= =0A= A PlatformID consists of an extension to the=0A= Incident.EventData.Flow.System.AdditionalData element with a dtype of=0A= "xml". Its elements identify a software platform.=0A= =0A= It is recommended that System class SHOULD contain this element=0A= whenever available.=0A= =0A= A PlatformID element is structured as follows.=0A= =0A= +--------------------+=0A= | PlatformID |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ ID ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cve"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= ID: One or more. ML_STRING. Arbitrary information structured by=0A= the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.6. EventReport=0A= =0A= An EventReport consists of an extension to the=0A= Incident.EventData.Record.RecordData.RecordItem element with a dtype=0A= of "xml". Its elements embed structured event reports.=0A= =0A= It is recommended that RecordItem class SHOULD contain this element=0A= whenever available.=0A= =0A= An EventReport element is structured as follows.=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 9]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= +--------------------+=0A= | EventRecord |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "cee"=0A= could be specified here. Note that the specification name should=0A= be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= 4.7. Remediation=0A= =0A= A Remediation consists of an extension to the Incident.AdditionalData=0A= element with a dtype of "xml". Its elements describe incident=0A= remediation infomration including instructions.=0A= =0A= It is recommended that Incident class SHOULD contain this element=0A= whenever available.=0A= =0A= A Remediation class is structured as follows.=0A= =0A= +--------------------+=0A= | Remediation |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ Version ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 10]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ML_STRING. The name of the specification=0A= specifying the format of the Score element. For instance, "oval",=0A= "ocil", and "xccdf" could be specified here. Note that the=0A= specification name should be written in lower case.=0A= =0A= Version: Zero or one. ML_STRING. The version of the specification=0A= specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. Arbitrary information structured=0A= by the specification identified by SpecificationName and Version=0A= elements.=0A= =0A= =0A= 5. Examples=0A= =0A= This section provides examples of an incident encoded in the IODEF.=0A= These examples do not necessarily represent the only way to encode a=0A= particular incident.=0A= =0A= 5.1. Reporting an attack=0A= =0A= An example of a CSIRT reporting an attack.=0A= =0A= =0A= =0A= xsi:schemaLocation=3D"urn:ietf:params:xml:schema:iodef-1.0">=0A= =0A= 189493=0A= 2001-09-13T23:19:24+00:00=0A= Incident report in company xx=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= capec=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 11]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 1.6=0A= [embed data in CAPEC format]=0A= =0A= =0A= cve=0A= [embed data in CVE format]=0A= =0A= =0A= cwe=0A= 5.0=0A= [embed data in CVE format]=0A= =0A= =0A= =0A= =0A= Example.com CSIRT=0A= example-com=0A= contact@csirt.example.com=0A= =0A= =0A= =0A= =0A= =0A=
192.0.2.200
=0A= 57=0A= =0A= =0A= =0A= =0A=
192.0.2.16/28
=0A= =0A= =0A= 80=0A= =0A= =0A= =0A= cpe=0A= 2.2=0A= [embed identifier in CPE format]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 12]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 2001-09-13T18:11:21+02:00=0A= a Web-server event record=0A= =0A= =0A= cee=0A= 1.0=0A= [embed data in CEE format]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 2001-09-14T08:19:01+00:00=0A= Notification sent to=0A= constituency-contact@192.0.2.200=0A= =0A= =0A= =0A= =0A= oval=0A= 5.9=0A= [embed OVAL-structured information here]=0A= =0A= =0A= xccdf=0A= 1.2=0A= [embed XCCDF-structured information here]=0A= =0A= =0A= =0A= =0A= =0A= Figure 1: Example UML Element Diagram=0A= =0A= =0A= 6. Security Considerations=0A= =0A= [Note: the sentences below are from rfc5901. I'll review later when=0A= the draft becomes more mature]=0A= =0A= This document specifies a format for encoding a particular class of=0A= security incidents appropriate for exchange across organizations. As=0A= merely a data representation, it does not directly introduce security=0A= issues. However, it is guaranteed that parties exchanging instances=0A= of this specification will have certain concerns. For this reason,=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 13]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= the underlying message format and transport protocol used MUST ensure=0A= the appropriate degree of confidentiality, integrity, and=0A= authenticity for the specific environment.=0A= =0A= Organizations that exchange data using this document are URGED to=0A= develop operating procedures that document the following areas of=0A= concern.=0A= =0A= 6.1. Transport-Specific Concerns=0A= =0A= The critical security concerns are that phishing activity reports may=0A= be falsified or the PhraudReport may become corrupt during transit.=0A= In areas where transmission security or secrecy is questionable, the=0A= application of a digital signature and/or message encryption on each=0A= report will counteract both of these concerns. We expect that each=0A= exchanging organization will determine the need, and mechanism, for=0A= transport protection.=0A= =0A= 6.2. Using the iodef:restriction Attribute=0A= =0A= In some instances, data values in particular elements may contain=0A= data deemed sensitive by the reporter. Although there are no=0A= general-purpose rules on when to mark certain values as "private" or=0A= "need-to-know" via the iodef:restriction attribute, the reporter is=0A= cautioned not to apply element-level sensitivity markings unless they=0A= believe the receiving party (i.e., the party they are exchanging the=0A= event report data with) has a mechanism to adequately safeguard and=0A= process the data as marked.=0A= =0A= =0A= 7. IANA Considerations=0A= =0A= This document uses URNs to describe XML namespaces and XML schemas=0A= conforming to a registry mechanism described in [RFC3688].=0A= =0A= Registration request for the IODEF My-Extension namespace:=0A= =0A= URI: urn:ietf:params:xml:ns:iodef-msmspecs-1.0=0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: None=0A= =0A= Registration request for the IODEF My-Extension XML schema:=0A= =0A= URI: urn:ietf:params:xml:schema:iodef-msmspecs-1.0=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 14]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: Refer here to the XML Schema in the appendix of the document.=0A= =0A= =0A= 8. Appendix: XML Schema Definition for Extension=0A= =0A= The XML Schema describing the elements defined in the Extension=0A= Defintion section is given here. Each of the examples in Section 5=0A= should be verified to validate against this schema by automated=0A= tools.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 15]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 16]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Example Schema Diagram=0A= =0A= =0A= 9. References=0A= =0A= 9.1. Normative References=0A= =0A= [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident=0A= Object Description Exchange Format", RFC 5070,=0A= December 2007.=0A= =0A= [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",=0A= RFC 6045, November 2010.=0A= =0A= 9.2. Informative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing=0A= Architecture", RFC 2373, July 1998.=0A= =0A= [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform=0A= Resource Identifiers (URI): Generic Syntax", RFC 2396,=0A= August 1998.=0A= =0A= [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,=0A= April 2001.=0A= =0A= [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the=0A= Internet: Timestamps", RFC 3339, July 2002.=0A= =0A= [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC=0A= Text on Security Considerations", BCP 72, RFC 3552,=0A= July 2003.=0A= =0A= [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol=0A= (LDAP): Schema for User Applications", RFC 4519,=0A= June 2006.=0A= =0A= [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an=0A= IANA Considerations Section in RFCs", BCP 26, RFC 5226,=0A= May 2008.=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 17]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to=0A= Uniform Resource Identifiers (URI) Dynamic Delegation=0A= Discovery System (DDDS) Application (ENUM)", RFC 6116,=0A= March 2011.=0A= =0A= =0A= Authors' Addresses=0A= =0A= Takeshi Takahashi=0A= National Institute of Information and Communications Technology=0A= 4-2-1 Nukui-Kitamachi Koganei=0A= 184-8795 Tokyo=0A= Japan=0A= =0A= Phone: +80 423 27 5862=0A= Email: takeshi_takahashi@nict.go.jp=0A= =0A= =0A= Kent Landfield=0A= McAfee=0A= xxx=0A= xxx=0A= xxx=0A= =0A= Phone: xxx=0A= Email: xxx=0A= =0A= =0A= Youki Kadobayashi=0A= National Institute of Information and Communications Technology=0A= 4-2-1 Nukui-Kitamachi Koganei=0A= 184-8795 Tokyo=0A= Japan=0A= =0A= Phone: +80 423 27 5862=0A= Email: youki-k@is.aist-nara.ac.jp=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 10, 2012 [Page 18]=0A= =0C=0A= ------=_NextPart_000_000E_01CC5692.D2AC6870-- From david.black@emc.com Tue Aug 9 16:44:29 2011 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 DF6C111E80DF for ; Tue, 9 Aug 2011 16:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.140, 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 rzk-Rgpy2BUa for ; Tue, 9 Aug 2011 16:44:25 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5F511E80D7 for ; Tue, 9 Aug 2011 16:44:24 -0700 (PDT) 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 p79NiqWd018717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2011 19:44:52 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 9 Aug 2011 19:44:40 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p79Nidd2012813; Tue, 9 Aug 2011 19:44:40 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Tue, 9 Aug 2011 19:44:39 -0400 From: To: , Date: Tue, 9 Aug 2011 19:44:36 -0400 Thread-Topic: [mile] draft on IODEF exstension to support structured cybersecurity information Thread-Index: AcxWR2J9VNIFG703SAaz5tSdZ4c7ZgApKezA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> References: <000d01cc5647$62c4c070$284e4150$@go.jp> In-Reply-To: <000d01cc5647$62c4c070$284e4150$@go.jp> 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_7C4DFCE962635144B8FAE8CA11D0BF1E058959E673MX14Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 09 Aug 2011 23:44:30 -0000 --_000_7C4DFCE962635144B8FAE8CA11D0BF1E058959E673MX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Take, For clarity I'd suggest not using "Version" as the name of both an extensio= n attribute and one of the classes in each extension. Renaming the class t= o SpecificationVersion would be clearer (so Version is the attribute with t= he version of the extension). I also have a few questions: (1) What strings are valid for SpecificationName? If the recipient doesn't= understand the SpecificationName, the information in the extension may be = unparseable, so this probably needs to be controlled. An IANA registry may be appropriate to list the valid strings and associate= each string with its corresponding specification. (2) How does one determine the format for information formatted according t= o an external specification? For example, I believe that the XSD schema for the CVE list defines a compl= ete XML document, but I suspect that less than a complete XML document is i= ntended to be embedded because the proposed extension is part of an IODEF X= ML document. (3) Why is the [Specification]Version limited to zero or one? For example, CAPEC is currently at Release 1.6. 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 ---------------------------------------------------- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Tak= eshi Takahashi Sent: Monday, August 08, 2011 11:50 PM To: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cyberse= curity information Thank you for those of you who kindly gave me off-line messages . Let me share the draft with some minor modifications. Sincerely, Take 2011/8/5 Takeshi Takahashi : > Dear all, > > > > The attached is the tentative version of the draft prepared based on the > comments I've received in this mailing list (Thanks a lot for that). > > It would be great if you could provide some comments on Clause 4, where t= he > IODEF extension is defined. > > > > As you know, there are many ways to embed structured information (e.g. CV= E > and CAPEC) in IODEF since IODEF is designed to be very flexible. > > Thus, I would be happy to change and develop the draft further based on y= our > comments. > > > > I would like to welcome any comments on that. > > > > By the way, I will be on vacation, thus my response might be slow, sorry = for > the inconvenience. > > > > Take > > > > PS: I've changed the title of the email. > > > > > > 2011/7/29 > >> > >> Thank you, the approach sounds good, especially since it is in use today > >> by at least the Research and Education ISAC. Do others have opinions on > >> the proposal here? > >> > >> Thanks for writing the first draft Take! > >> > >> Best regards, > >> Kathleen > >> ________________________________________ > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Takeshi > >> Takahashi [takeshi_takahashi@nict.go.jp] > >> Sent: Friday, July 29, 2011 9:20 AM > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> Thank you, Bob, for the email. > >> I also like Tom's suggestion very much. > >> Let me work on the "draft" of the draft for a while, then come back to y= ou > >> later. > >> > >> Take > >> > >> -----Original Message----- > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >> Sent: Friday, July 29, 2011 9:10 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >> wes@ren-isac.net; mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> I also like how this is evolving. > >> > >> I think, as Tom's suggestions pointed, that any and all of the useful > >> types > >> of information that can help with understanding, diagnosing, and getting > >> ahead of an incident should be added but for now we should focus on thos= e > >> the most established and well articulated. > >> > >> This can be the compliance/patch/configuration/platform information > >> related > >> to the SCAP use case, or event signature/attack pattern/traffic > >> characteristics from events, or the vulnerability/threat characterizatio= n > >> space. > >> > >> I look forward to Taki's draft to see how he suggests positioning these > >> concepts. > >> > >> Bob > >> > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >> > I like where this is headed. > >> > > >> > Thanks Takeshi. I look forward to your draft. It will give us somethi= ng > >> real to discuss. I appreciate you jumping in and getting this started. > >> > > >> > One question that I am not clear on. What do we envision as the actual > >> set > >> of deliverables? From and SCAP related perspective, are we looking at a > >> single draft covering all the extensions? > >> > > >> > Kent > >> > > >> > Kent Landfield > >> > Director Content Strategy, Architecture and Standards > >> > > >> > McAfee, Inc. > >> > 5000 Headquarters Dr. > >> > Plano, Texas 75024 > >> > > >> > Direct: +1.972.963.7096 > >> > Mobile: +1.817.637.8026 > >> > Web: www.mcafee.com > >> > > >> > From: Takeshi > >> > Takahashi >> > o.jp>> > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > >> > To: > >> > "Thomas.Millar@us-cert.gov" >> > illar@us-cert.gov>, > >> > "wes@ren-isac.net" >> > s@ren-isac.net>>, > >> > "mile@ietf.org" >> > rg>> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > Thank you for the email, Tom. > >> > > >> > So, here is what the draft needs to describe (if I understand Wes and > >> > Tom correctly). > >> > > >> > The draft should define ext-dtype (an attribute of AdditionalData > >> > Class) to identify the information type, rather than defining new > >> > class under AdditionalData. > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec, > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal and > >> > could easily embed various structured information (CVE etc.) in the > >> > EventData.Record.RecordData.AdditionalData field. > >> > Then "should" statement should be carefully placed in the text of > >> > relevant class. > >> > > >> > I'll prepare some draft so that we could discuss and advance further. > >> > > >> > Take > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > >> > Thomas.Millar@us-cert.gov > >> > Sent: Thursday, July 28, 2011 6:28 PM > >> > To: wes@ren-isac.net; > >> > mile@ietf.org > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > I think this approach makes more sense. One of the things I think > >> > could be helpful is to have a number of SHOULD statements further > >> > describing the possible types of other documents that would be > >> > expected to ride under the AdditionalData elements of each class (not > >> just > >> EventData). > >> > What I'm thinking of looks like this (very unpolished): > >> > > >> > "The Method Class:AdditionalData class SHOULD contain data elements > >> > that describe the methods, tools or techniques employed to cause the > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the > >> > method such as CVSS, CWSS, or CCE." > >> > > >> > "The Expectation Class[...] SHOULD contain data elements which > >> > describe configuration changes, detection heuristics, or [* (legal > >> > authorization?)] to assist in executing or implementing the requested > >> > action, such as XCCDF, OCIL, OVAL, etc" > >> > > >> > This could go towards encouraging better or at least more consistent > >> > use of "boundary objects" in the substance of incident reports. I > >> > could also go on about greater automation and such but that's probably > >> > out of scope for this e-mail. > >> > > >> > > >> > - Tom Millar, US-CERT > >> > > >> > thomas.millar@us-cert.gov > >> > BB: thomas.millar@dhs.gov / > >> > 202-631-1915 > >> > 24x7: soc@us-cert.gov / 888-282-0870 > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >> > Sent: Thursday, July 28, 2011 11:08 AM > >> > To: mile@ietf.org > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >> > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > >> > > >> > i've been sticking other "XML like" records under this (icsg1.1 data, > >> > etc...). > >> > > >> > pretty easy to do, just generate the "other standards" xml (or json or > >> > whatever), embed it there. turns iodef into a sharing platform for > >> > other data-types w/o having to extend it too much. > >> > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >> > > >> > So, maybe we could extend the IODEF as described in Figure 1 of the > >> > attached txt file. (correct me if I'm wrong) We could define > >> > Incident.EventData.AdditionalData elements and describe them by using > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >> > Regarding OVAL, we might define Incident.AdditionalData element, but I > >> > > >> > am not sure at this moment, thus is not described in the figure yet. > >> > I would like to tackle CAPEC first since I believe Kent would like to > >> > tackle CVE and CAPEC. > >> > > >> > -- > >> > Wes > >> > claimid.com/wesyoung > >> > soc@ren-isac.net > >> > > >> > * Wes Young> > >> > * 0xDDB6E946 - Unverified(L) > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > . > >> > > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > -- -- Takeshi Takahashi, Ph.D. +81 80 3490 2971 http://www.taketaka.com/ --_000_7C4DFCE962635144B8FAE8CA11D0BF1E058959E673MX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Take,<= /span>


For clarity I’d suggest not using R= 20;Version” as the name of both an extension attribute and one of the= classes in each extension.  Renaming the class to SpecificationVersio= n would be clearer (so Version is the attribute with the version of the ext= ension).

 

=

I also have a few questions:

 

(1) What strings are = valid for SpecificationName?  If the recipient doesn’t understan= d the SpecificationName, the information in the extension may be unparseabl= e, so this probably needs to be controlled.

 

An IANA registry may = be appropriate to list the valid strings and associate each string with its= corresponding specification.

&n= bsp;

(2) How does one determine the format= for information formatted according to an external specification?

 

= For example, I believe that the XSD schema for the CVE list defines a compl= ete XML document, but I suspect that less than a complete XML document is i= ntended to be embedded because the proposed extension is part of an IODEF X= ML document.

 =

(3) Why is the [Specification]Version limited to zero = or one?

 

<= p class=3DMsoNormal>For example, CAPEC is currently at Release 1.6.<= /span>

 

=

 

<= p class=3DMsoNormal>From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org= ] On Behalf Of Takeshi Takahashi
Sent: Monday, August 08, = 2011 11:50 PM
To: mile@ietf.org
Subject: Re: [mile] dra= ft on IODEF exstension to support structured cybersecurity information=

 

Thank you for those of you who kindly gave me off-line mes= sages .

 

Let me share the draft with some minor modifications.<= /p>

 

Sincerely= ,
Take

 

 

2011/8/5 Takeshi Tak= ahashi <takeshi_takahashi@nict.go.jp>:

> Dear all,

> 

> 

&g= t; 

> The attached is the tentat= ive version of the draft prepared based on the

> comments I’ve received in this mailing list (Thanks a lot= for that).

> 

> It would be great if you could provide some comments= on Clause 4, where the

> IODEF exten= sion is defined.

> 

> 

><= o:p> 

> As you know, there are many w= ays to embed structured information (e.g. CVE

> and CAPEC) in IODEF since IODEF is designed to be very flexible.=

> 

> Thus, I would be happy to change and develop the draft further = based on your

> comments.<= /p>

> 

>&= nbsp;

> 

> I would like to welcome any comments on that.<= /p>

> 

>&= nbsp;

> 

> By the way, I will be on vacation, thus my response might= be slow, sorry for

> the inconvenien= ce.

> 

> 

> 

> Take

&g= t; 

> 

> 

> PS: I= 217;ve changed the title of the email.

&= gt; 

> 

> 

>  <= o:p>

> 

> 2011/7/29 <kathleen.moriarty@emc.com>

> 

>> =

> 

>> Thank you, the approach sounds good, especially since it is in u= se today

> 

>> by at least the Research and Education ISAC.  = Do others have opinions on

>&nbs= p;

>> the proposal here?

=

> 

>>=

> 

>> Thanks for writing the first draft Take!

> 

>>

> 

>> Best regards,

>&nb= sp;

>> Kathleen

> 

>> _______= _________________________________

> 

>> From: mile-bounces@ietf.or= g [mile-bounces@ietf.org] On Behalf Of Takeshi

> 

>> Takahashi [ta= keshi_takahashi@nict.go.jp]

>&nb= sp;

>> Sent: Friday, July 29, 2011 9:20= AM

> 

>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com<= /o:p>

> 

>> Cc: mile@ietf.org

>&nb= sp;

>> Subject: Re: [mile] Updated pres= entation from Side meeting

>&nbs= p;

>>

> 

>> Thank you, Bob, f= or the email.

> 

<= p class=3DMsoNormal>>> I also like Tom's suggestion very much.

> 

= >> Let me work on the "draft" of the draft for a while, the= n come back to you

> =

>> later.

> 

>>

> 

>> Tak= e

> 

>>

> <= /p>

>> -----Original Message-----

<= p class=3DMsoNormal>> 

>> = From: Martin, Robert A. [mailto:ramartin@mitre.org]

> 

>> Sent: F= riday, July 29, 2011 9:10 AM

>&n= bsp;

>> To: Kent_Landfield@McAfee.com

> 

>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov;<= o:p>

> 

>> wes@ren-isac.net; mile@ietf.org

> 

>> Subject: Re: = [mile] Updated presentation from Side meeting

> 

>>

> 

>>= ; I also like how this is evolving.

>=  

>>

> 

>> I think= , as Tom's suggestions pointed, that any and all of the useful

> 

>&g= t; types

> 

>> of information that can help with understanding, di= agnosing, and getting

> 

>> ahead of an incident should be added b= ut for now we should focus on those

>=  

>> the most established and= well articulated.

> =

>>

><= o:p> 

>> This can be the complianc= e/patch/configuration/platform information

> 

>> related

> 

>= ;> to the SCAP use case, or event signature/attack pattern/traffic<= /o:p>

> 

>> characteristics from events, or the vulnerability/threat characte= rization

> 

>> space.

>=  

>>

> 

>> I look forwar= d to Taki's draft to see how he suggests positioning these

> 

>> c= oncepts.

> 

>>

> =

>> Bob

> 

>>

<= p class=3DMsoNormal>> 

>> = On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote:

> 

>> > I= like where this is headed.

>&nb= sp;

>> >

> 

>> > Thanks = Takeshi.  I look forward to your draft. It will give us something=

> 

>> real to discuss. I appreciate you jumping in and getting this st= arted.

> 

>> >

>&nbs= p;

>> > One question that I am not c= lear on. What do we envision as the actual

> 

>> set

> 

>>= ; of deliverables?  From and SCAP related perspective, are we looking = at a

> 

>> single draft covering all the extensions?<= /p>

> 

>&= gt; >

> 

>> > Kent

> 

>> >

> 

>> > K= ent Landfield

> 

<= p class=3DMsoNormal>>> > Director Content Strategy, Architecture a= nd Standards

> 

>> >

> 

>> > McAfee, Inc.

> 

>= ;> > 5000 Headquarters Dr.

> 

>> > Plano, Texas 75024

> 

>> >

> 

>> > Direct: +1.972.963.7096

=

> 

>>= > Mobile: +1.817.637.8026

>&= nbsp;

>> > Web: www.mcafee.com<ht= tp://www.mcafee.com/>

> =

>> >

> 

>> > From: Take= shi

> 

>> > Takahashi<takeshi_takahashi@nict.go.jp<mailto= :takeshi_takahashi@nict.g

> = ;

>> > o.jp>>

> 

>> &= gt; Date: Thu, 28 Jul 2011 18:21:56 -0500

> 

>> > To:

> 

>= ;> > "Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.= gov>"<Thomas.M

> = ;

>> > illar@us-cert.gov<mailto:T= homas.Millar@us-cert.gov>>,

> 

>> > "wes@ren-isac.ne= t<mailto:wes@ren-isac.net>"<wes@ren-isac.net<mailto:we

> 

>> > s@ren-isac.net>>,

> 

>> > "mile@iet= f.org<mailto:mile@ietf.org>"<mile@ietf.org<mailto:mile@iet= f.o

> 

>> > rg>>

><= o:p> 

>> > Subject: Re: [mile] = Updated presentation from Side meeting

&= gt; 

>> >

> 

>> &= gt; Thank you for the email, Tom.

> 

>> >

> 

>> > S= o, here is what the draft needs to describe (if I understand Wes and

> 

= >> > Tom correctly).

>&= nbsp;

>> >

> 

>> > The d= raft should define ext-dtype (an attribute of AdditionalData

=

> 

>>= > Class) to identify the information type, rather than defining new

> 

>> > class under AdditionalData.

> 

>> > Ext-dtype:= ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec,

<= p class=3DMsoNormal>> 

>> = > ext-cvss, ext-cwss, In this way, we could keep the change minimal and<= o:p>

> 

>> > could easily embed various structured information (CVE = etc.) in the

> 

>> > EventData.Record.RecordData.AdditionalData= field.

> 

>> > Then "should" statement should be car= efully placed in the text of

>&n= bsp;

>> > relevant class.=

> 

>= > >

> 

>> > I'll prepare some draft so that we could disc= uss and advance further.

> =

>> >

> 

>> > Take<= /o:p>

> 

>> >

> 

=

>> >

><= o:p> 

>> >

> 

>> > = -----Original Message-----

>&nbs= p;

>> > From: mile-bounces@ietf.org&= lt;mailto:mile-bounces@ietf.org>

>=  

>> > [mailto:mile-bounce= s@ietf.org] On Behalf Of

> =

>> > Thomas.Millar@us-cert.gov<m= ailto:Thomas.Millar@us-cert.gov>

>=  

>> > Sent: Thursday, Jul= y 28, 2011 6:28 PM

> =

>> > To: wes@ren-isac.net<mailto:wes@r= en-isac.net>;

> 

>> > mile@ietf.org<mailto:mile@ietf.org&= gt;

> 

>> > Subject: Re: [mile] Updated presentation from Side = meeting

> 

>> >

>&nb= sp;

>> > I think this approach makes= more sense. One of the things I think

&= gt; 

>> > could be helpful= is to have a number of SHOULD statements further

> 

>> > descr= ibing the possible types of other documents that would be

> 

>> &g= t; expected to ride under the AdditionalData elements of each class (not

> 

>> just

> <= /p>

>> EventData).

> 

>> > What I'm t= hinking of looks like this (very unpolished):

> 

>> >

> 

>= ;> > "The Method Class:AdditionalData class SHOULD contain data = elements

> 

>> > that describe the methods, tools or techniques= employed to cause the

> 

>> > incident, such as CAPEC, CWE, CV= E, CVRF, or metadata concerning the

>=  

>> > method such as CVSS= , CWSS, or CCE."

> 

>> >

> 

>> > "The Exp= ectation Class[...] SHOULD contain data elements which

> 

>> > = describe configuration changes, detection heuristics, or [* (legal

> 

&g= t;> > authorization?)] to assist in executing or implementing the req= uested

> 

>> > action, such as XCCDF, OCIL, OVAL, etc"

> 

>> >

> 

>> > This could go towards encouraging bett= er or at least more consistent

>=  

>> > use of "boundary ob= jects" in the substance of incident reports. I

> 

>> > co= uld also go on about greater automation and such but that's probably

> 

= >> > out of scope for this e-mail.

> 

>> ><= /p>

> 

>&= gt; >

> 

>> > - Tom Millar, US-CERT

> 

>> >

> 

>> > thomas.millar@us-cert.gov<mailto:thomas.millar@us-cert= .gov>

> 

>> > BB: thomas.millar@dhs.gov<mailto:thomas.mil= lar@dhs.gov>  /

> <= /o:p>

>> > 202-631-1915

> 

>> >= ; 24x7: soc@us-cert.gov<mailto:soc@us-cert.gov>  / 888-282-0870<= o:p>

> 

>> > -----Original Message-----

> 

>> > From: mi= le-bounces@ietf.org<mailto:mile-bounces@ietf.org>

> 

>> >= [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young

> 

>> > = Sent: Thursday, July 28, 2011 11:08 AM

&= gt; 

>> > To: mile@ietf.or= g<mailto:mile@ietf.org>

>&= nbsp;

>> > Subject: Re: [mile] Updat= ed presentation from Side meeting

> 

>> >

> 

>> > *= PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM

> 

>> &= gt;

> 

>> > http://tools.ietf.org/html/rfc5070#section-3.19

> 

>> >

> 

>> > i've been sticking other "XML lik= e" records under this (icsg1.1 data,

> 

>> > etc...).=

> 

>> >

> 

>> > pretty easy to do, just generate the &q= uot;other standards" xml (or json or

> 

>> > whatever), em= bed it there. turns iodef into a sharing platform for

> 

>> > o= ther data-types w/o having to extend it too much.

> 

>> ><= /o:p>

> 

>> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote:<= /o:p>

> 

>> >

> 

=

>> > So, maybe we could extend the IODEF as d= escribed in Figure 1 of the

>&nb= sp;

>> > attached txt file. (correct= me if I'm wrong) We could define

> 

>> > Incident.EventData.Ad= ditionalData elements and describe them by using

> 

>> > CPE, C= VE/CWE, CVSS/CWSS, and CAPEC.

>&= nbsp;

>> > Regarding OVAL, we might = define Incident.AdditionalData element, but I

> 

>> >

> 

>= ;> > am not sure at this moment, thus is not described in the figure = yet.

> 

>> > I would like to tackle CAPEC first since I belie= ve Kent would like to

> 

>> > tackle CVE and CAPEC.<= /p>

> 

>&= gt; >

> 

>> > --

> 

>> > Wes

> 

>> >= claimid.com/wesyoung

> 

>> > soc@ren-isac.net<mailto:soc@re= n-isac.net>

> 

=

>> >

><= o:p> 

>> > * Wes Young<wes@r= en-isac.net<mailto:wes@ren-isac.net>>

> 

>> > * 0xDDB6= E946 - Unverified(L)

> 

>> > __________________________________= _____________

> 

<= p class=3DMsoNormal>>> > mile mailing list

> 

>> > mi= le@ietf.org<mailto:mile@ietf.org>

= > 

>> > https://www.iet= f.org/mailman/listinfo/mile

>&nb= sp;

>> > ___________________________= ____________________

> 

>> > mile mailing list

> 

>> &= gt; mile@ietf.org<mailto:mile@ietf.org>

> 

>> > https://w= ww.ietf.org/mailman/listinfo/mile

> 

>> >

> 

>> > _= ______________________________________________

> 

>> > mile mai= ling list

> 

>> > mile@ietf.org<mailto:mile@ietf.org>

> 

>> > https://www.ietf.org/mailman/listinfo/mile

<= p class=3DMsoNormal>> 

>> = >

> 

>> > _______________________________________________<= o:p>

> 

>> > mile mailing list

&g= t; 

>> > mile@ietf.org

> 

>> > https://www.ietf.org/mailman/listinfo/mile

<= p class=3DMsoNormal>> 

>> = > .

> 

>> >

>&nbs= p;

>>

> 

>> _________________= ______________________________

>=  

>> mile mailing list<= /p>

> 

>&= gt; mile@ietf.org

> <= /p>

>> https://www.ietf.org/mailman/listinfo/mile=

> 

> 

> =

> 

>= ; 

> 

 

 <= /p>

 

-- <= /o:p>

--

Takeshi= Takahashi, Ph.D.

+81 80 3490 2971<= /o:p>

http://www.taketaka.com/

 

= --_000_7C4DFCE962635144B8FAE8CA11D0BF1E058959E673MX14Acorpemcc_-- From lnunez@cisco.com Wed Aug 10 13:22:33 2011 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 494AE228011 for ; Wed, 10 Aug 2011 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZORqe6QVFIW for ; Wed, 10 Aug 2011 13:22:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B80BC228010 for ; Wed, 10 Aug 2011 13:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lnunez@cisco.com; l=33021; q=dns/txt; s=iport; t=1313007781; x=1314217381; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=okHZKjCMQ1w1ritr+Rgt6vYPFpbbe/5Avhg+h+LxALU=; b=Bat7XXLZ1CDWvpq96MHurnEBd/iPfwIIl1HN6e1IJlkDxJp9uzDnn3JW BT0UYLqHFJnf3Orae8fz1q4mPNWncmyR5sgMrUrRlW+rTAi0wJAk5yBv9 NA1NUPcQ2Fn6v0OJpQFbYGAzvV/gbXcn5YWOnsZie/BSzpY8ktsf9WfMD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAJDnQk6tJV2d/2dsb2JhbAA3BwOCTZUmhzwBhyNnd4FAAQEBAQIBAQEBDwEHIwwlBQsHBgEIBwIIAQIBAQEBIAcuHwMGCAEBBAESCQ0Mh0wEoHsBnmCDJhqDBgSCUIRei1uFE4Rfhxc X-IronPort-AV: E=Sophos;i="4.67,352,1309737600"; d="scan'208,217";a="11902672" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 10 Aug 2011 20:23:00 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p7AKN0xI013256; Wed, 10 Aug 2011 20:23:00 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 15:23:00 -0500 Received: from 10.82.255.82 ([10.82.255.82]) by XMB-RCD-107.cisco.com ([72.163.62.149]) via Exchange Front-End Server email.cisco.com ([72.163.62.205]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Aug 2011 20:23:00 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Wed, 10 Aug 2011 16:22:58 -0400 From: lnunez To: Takeshi Takahashi , Message-ID: Thread-Topic: [mile] draft on IODEF exstension to support structured cybersecurity information Thread-Index: AcxWR2J9VNIFG703SAaz5tSdZ4c7ZgBU+i1y In-Reply-To: <000d01cc5647$62c4c070$284e4150$@go.jp> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395838178_4926809" X-OriginalArrivalTime: 10 Aug 2011 20:23:00.0087 (UTC) FILETIME=[4C703070:01CC579B] X-Mailman-Approved-At: Wed, 10 Aug 2011 14:31:20 -0700 Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 10 Aug 2011 20:22:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395838178_4926809 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I noticed CVRF mention briefly in this email thread (good I am thinking the same). Looking at the draft-takahash-mile-sci-01.txt I see potential synergies between the draft and CVRF.=A0 They both share some heritage.=A0 Major vendors have indicated that they will start publishing security advisories in the near future.=A0 I could see this IODEF-extension leveraging the CVRF content/components to provide additiona= l fidelity to the security incident exchange. =A0 CVRF link: http://www.icasi.org/cvrf Redhat CVRF sample: http://www.awe.com/mark/blog/20110518.html It would be interesting to see a CVRF advisory with OVAL checking content a= s a mitigation method in this draft. One thing to keep in mind is to realized how we can build and used the various emerging set of standards in a cohesive way. thanks. On 8/8/11 11:49 PM, "Takeshi Takahashi" wrote: > Thank you for those of you who kindly gave me off-line messages . > =20 > Let me share the draft with some minor modifications. > =20 > Sincerely, > Take > =20 > =20 > 2011/8/5 Takeshi Takahashi : >> > Dear all, >> >=20 >> > =20 >> >=20 >> > The attached is the tentative version of the draft prepared based on t= he >> > comments I=B9ve received in this mailing list (Thanks a lot for that). >> >=20 >> > It would be great if you could provide some comments on Clause 4, wher= e the >> > IODEF extension is defined. >> >=20 >> > =20 >> >=20 >> > As you know, there are many ways to embed structured information (e.g.= CVE >> > and CAPEC) in IODEF since IODEF is designed to be very flexible. >> >=20 >> > Thus, I would be happy to change and develop the draft further based o= n >> your >> > comments. >> >=20 >> > =20 >> >=20 >> > I would like to welcome any comments on that. >> >=20 >> > =20 >> >=20 >> > By the way, I will be on vacation, thus my response might be slow, sor= ry >> for >> > the inconvenience. >> >=20 >> > =20 >> >=20 >> > Take >> >=20 >> > =20 >> >=20 >> > PS: I=B9ve changed the title of the email. >> >=20 >> > =20 >> >=20 >> > =20 >> >=20 >> > 2011/7/29 >> >=20 >>> >>=20 >> >=20 >>> >> Thank you, the approach sounds good, especially since it is in use t= oday >> >=20 >>> >> by at least the Research and Education ISAC. Do others have opinion= s on >> >=20 >>> >> the proposal here? >> >=20 >>> >>=20 >> >=20 >>> >> Thanks for writing the first draft Take! >> >=20 >>> >>=20 >> >=20 >>> >> Best regards, >> >=20 >>> >> Kathleen >> >=20 >>> >> ________________________________________ >> >=20 >>> >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Tak= eshi >> >=20 >>> >> Takahashi [takeshi_takahashi@nict.go.jp] >> >=20 >>> >> Sent: Friday, July 29, 2011 9:20 AM >> >=20 >>> >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com >> >=20 >>> >> Cc: mile@ietf.org >> >=20 >>> >> Subject: Re: [mile] Updated presentation from Side meeting >> >=20 >>> >>=20 >> >=20 >>> >> Thank you, Bob, for the email. >> >=20 >>> >> I also like Tom's suggestion very much. >> >=20 >>> >> Let me work on the "draft" of the draft for a while, then come back = to >>> you >> >=20 >>> >> later. >> >=20 >>> >>=20 >> >=20 >>> >> Take >> >=20 >>> >>=20 >> >=20 >>> >> -----Original Message----- >> >=20 >>> >> From: Martin, Robert A. [mailto:ramartin@mitre.org] >> >=20 >>> >> Sent: Friday, July 29, 2011 9:10 AM >> >=20 >>> >> To: Kent_Landfield@McAfee.com >> >=20 >>> >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; >> >=20 >>> >> wes@ren-isac.net; mile@ietf.org >> >=20 >>> >> Subject: Re: [mile] Updated presentation from Side meeting >> >=20 >>> >>=20 >> >=20 >>> >> I also like how this is evolving. >> >=20 >>> >>=20 >> >=20 >>> >> I think, as Tom's suggestions pointed, that any and all of the usefu= l >> >=20 >>> >> types >> >=20 >>> >> of information that can help with understanding, diagnosing, and get= ting >> >=20 >>> >> ahead of an incident should be added but for now we should focus on = those >> >=20 >>> >> the most established and well articulated. >> >=20 >>> >>=20 >> >=20 >>> >> This can be the compliance/patch/configuration/platform information >> >=20 >>> >> related >> >=20 >>> >> to the SCAP use case, or event signature/attack pattern/traffic >> >=20 >>> >> characteristics from events, or the vulnerability/threat characteriz= ation >> >=20 >>> >> space. >> >=20 >>> >>=20 >> >=20 >>> >> I look forward to Taki's draft to see how he suggests positioning th= ese >> >=20 >>> >> concepts. >> >=20 >>> >>=20 >> >=20 >>> >> Bob >> >=20 >>> >>=20 >> >=20 >>> >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: >> >=20 >>>> >> > I like where this is headed. >> >=20 >>>> >> > >> >=20 >>>> >> > Thanks Takeshi. I look forward to your draft. It will give us >>>> something >> >=20 >>> >> real to discuss. I appreciate you jumping in and getting this starte= d. >> >=20 >>>> >> > >> >=20 >>>> >> > One question that I am not clear on. What do we envision as the a= ctual >> >=20 >>> >> set >> >=20 >>> >> of deliverables? From and SCAP related perspective, are we looking = at a >> >=20 >>> >> single draft covering all the extensions? >> >=20 >>>> >> > >> >=20 >>>> >> > Kent >> >=20 >>>> >> > >> >=20 >>>> >> > Kent Landfield >> >=20 >>>> >> > Director Content Strategy, Architecture and Standards >> >=20 >>>> >> > >> >=20 >>>> >> > McAfee, Inc. >> >=20 >>>> >> > 5000 Headquarters Dr. >> >=20 >>>> >> > Plano, Texas 75024 >> >=20 >>>> >> > >> >=20 >>>> >> > Direct: +1.972.963.7096 >> >=20 >>>> >> > Mobile: +1.817.637.8026 >> >=20 >>>> >> > Web: www.mcafee.com >> >=20 >>>> >> > >> >=20 >>>> >> > From: Takeshi >> >=20 >>>> >> > Takahashi> >=20 >>>> >> > o.jp>> >> >=20 >>>> >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 >> >=20 >>>> >> > To: >> >=20 >>>> >> > "Thomas.Millar@us-cert.gov"> >=20 >>>> >> > illar@us-cert.gov>, >> >=20 >>>> >> > "wes@ren-isac.net"> >=20 >>>> >> > s@ren-isac.net>>, >> >=20 >>>> >> > "mile@ietf.org"> >=20 >>>> >> > rg>> >> >=20 >>>> >> > Subject: Re: [mile] Updated presentation from Side meeting >> >=20 >>>> >> > >> >=20 >>>> >> > Thank you for the email, Tom. >> >=20 >>>> >> > >> >=20 >>>> >> > So, here is what the draft needs to describe (if I understand Wes= and >> >=20 >>>> >> > Tom correctly). >> >=20 >>>> >> > >> >=20 >>>> >> > The draft should define ext-dtype (an attribute of AdditionalData >> >=20 >>>> >> > Class) to identify the information type, rather than defining new >> >=20 >>>> >> > class under AdditionalData. >> >=20 >>>> >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-ca= pec, >> >=20 >>>> >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal= and >> >=20 >>>> >> > could easily embed various structured information (CVE etc.) in t= he >> >=20 >>>> >> > EventData.Record.RecordData.AdditionalData field. >> >=20 >>>> >> > Then "should" statement should be carefully placed in the text of >> >=20 >>>> >> > relevant class. >> >=20 >>>> >> > >> >=20 >>>> >> > I'll prepare some draft so that we could discuss and advance furt= her. >> >=20 >>>> >> > >> >=20 >>>> >> > Take >> >=20 >>>> >> > >> >=20 >>>> >> > >> >=20 >>>> >> > >> >=20 >>>> >> > -----Original Message----- >> >=20 >>>> >> > From: mile-bounces@ietf.org >> >=20 >>>> >> > [mailto:mile-bounces@ietf.org] On Behalf Of >> >=20 >>>> >> > Thomas.Millar@us-cert.gov >> >=20 >>>> >> > Sent: Thursday, July 28, 2011 6:28 PM >> >=20 >>>> >> > To: wes@ren-isac.net; >> >=20 >>>> >> > mile@ietf.org >> >=20 >>>> >> > Subject: Re: [mile] Updated presentation from Side meeting >> >=20 >>>> >> > >> >=20 >>>> >> > I think this approach makes more sense. One of the things I think >> >=20 >>>> >> > could be helpful is to have a number of SHOULD statements further >> >=20 >>>> >> > describing the possible types of other documents that would be >> >=20 >>>> >> > expected to ride under the AdditionalData elements of each class = (not >> >=20 >>> >> just >> >=20 >>> >> EventData). >> >=20 >>>> >> > What I'm thinking of looks like this (very unpolished): >> >=20 >>>> >> > >> >=20 >>>> >> > "The Method Class:AdditionalData class SHOULD contain data elemen= ts >> >=20 >>>> >> > that describe the methods, tools or techniques employed to cause = the >> >=20 >>>> >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning t= he >> >=20 >>>> >> > method such as CVSS, CWSS, or CCE." >> >=20 >>>> >> > >> >=20 >>>> >> > "The Expectation Class[...] SHOULD contain data elements which >> >=20 >>>> >> > describe configuration changes, detection heuristics, or [* (lega= l >> >=20 >>>> >> > authorization?)] to assist in executing or implementing the reque= sted >> >=20 >>>> >> > action, such as XCCDF, OCIL, OVAL, etc" >> >=20 >>>> >> > >> >=20 >>>> >> > This could go towards encouraging better or at least more consist= ent >> >=20 >>>> >> > use of "boundary objects" in the substance of incident reports. I >> >=20 >>>> >> > could also go on about greater automation and such but that's pro= bably >> >=20 >>>> >> > out of scope for this e-mail. >> >=20 >>>> >> > >> >=20 >>>> >> > >> >=20 >>>> >> > - Tom Millar, US-CERT >> >=20 >>>> >> > >> >=20 >>>> >> > thomas.millar@us-cert.gov >> >=20 >>>> >> > BB: thomas.millar@dhs.gov / >> >=20 >>>> >> > 202-631-1915 >> >=20 >>>> >> > 24x7: soc@us-cert.gov / 888-282-0870 >> >=20 >>>> >> > -----Original Message----- >> >=20 >>>> >> > From: mile-bounces@ietf.org >> >=20 >>>> >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young >> >=20 >>>> >> > Sent: Thursday, July 28, 2011 11:08 AM >> >=20 >>>> >> > To: mile@ietf.org >> >=20 >>>> >> > Subject: Re: [mile] Updated presentation from Side meeting >> >=20 >>>> >> > >> >=20 >>>> >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM >> >=20 >>>> >> > >> >=20 >>>> >> > http://tools.ietf.org/html/rfc5070#section-3.19 >> >=20 >>>> >> > >> >=20 >>>> >> > i've been sticking other "XML like" records under this (icsg1.1 d= ata, >> >=20 >>>> >> > etc...). >> >=20 >>>> >> > >> >=20 >>>> >> > pretty easy to do, just generate the "other standards" xml (or js= on or >> >=20 >>>> >> > whatever), embed it there. turns iodef into a sharing platform fo= r >> >=20 >>>> >> > other data-types w/o having to extend it too much. >> >=20 >>>> >> > >> >=20 >>>> >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: >> >=20 >>>> >> > >> >=20 >>>> >> > So, maybe we could extend the IODEF as described in Figure 1 of t= he >> >=20 >>>> >> > attached txt file. (correct me if I'm wrong) We could define >> >=20 >>>> >> > Incident.EventData.AdditionalData elements and describe them by u= sing >> >=20 >>>> >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. >> >=20 >>>> >> > Regarding OVAL, we might define Incident.AdditionalData element, = but I >> >=20 >>>> >> > >> >=20 >>>> >> > am not sure at this moment, thus is not described in the figure y= et. >> >=20 >>>> >> > I would like to tackle CAPEC first since I believe Kent would lik= e to >> >=20 >>>> >> > tackle CVE and CAPEC. >> >=20 >>>> >> > >> >=20 >>>> >> > -- >> >=20 >>>> >> > Wes >> >=20 >>>> >> > claimid.com/wesyoung >> >=20 >>>> >> > soc@ren-isac.net >> >=20 >>>> >> > >> >=20 >>>> >> > * Wes Young> >> >=20 >>>> >> > * 0xDDB6E946 - Unverified(L) >> >=20 >>>> >> > _______________________________________________ >> >=20 >>>> >> > mile mailing list >> >=20 >>>> >> > mile@ietf.org >> >=20 >>>> >> > https://www.ietf.org/mailman/listinfo/mile >> >=20 >>>> >> > _______________________________________________ >> >=20 >>>> >> > mile mailing list >> >=20 >>>> >> > mile@ietf.org >> >=20 >>>> >> > https://www.ietf.org/mailman/listinfo/mile >> >=20 >>>> >> > >> >=20 >>>> >> > _______________________________________________ >> >=20 >>>> >> > mile mailing list >> >=20 >>>> >> > mile@ietf.org >> >=20 >>>> >> > https://www.ietf.org/mailman/listinfo/mile >> >=20 >>>> >> > >> >=20 >>>> >> > _______________________________________________ >> >=20 >>>> >> > mile mailing list >> >=20 >>>> >> > mile@ietf.org >> >=20 >>>> >> > https://www.ietf.org/mailman/listinfo/mile >> >=20 >>>> >> > . >> >=20 >>>> >> > >> >=20 >>> >>=20 >> >=20 >>> >> _______________________________________________ >> >=20 >>> >> mile mailing list >> >=20 >>> >> mile@ietf.org >> >=20 >>> >> https://www.ietf.org/mailman/listinfo/mile >> >=20 >> > =20 >> >=20 >> > =20 >> >=20 >> > =20 > =20 > =20 > =20 --B_3395838178_4926809 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mile] draft on IODEF exstension to support structured cybersecu= rity information I noticed CVRF mention briefly in this email thread (good I am thinking = the same). Looking at the draft-takahash-mile-sci-01.txt I see potential syn= ergies between the draft and CVRF.=A0

They both share some heritage.=A0 Major vendors have indicated that they will= start publishing security advisories in the near future.=A0 I could see this = IODEF-extension leveraging the CVRF content/components to provide additional= fidelity to the security incident exchange. =A0

CVRF link:
http://www.icasi.org/cvrf
Redhat CVRF sample:
http://www.awe.com/mar= k/blog/20110518.html

It would be interesting to see a CVRF advisory with OVAL checking content a= s a mitigation method in this draft.

One thing to keep in mind is to realized how we can build and used the vari= ous emerging set of standards in a cohesive way.

thanks.


On 8/8/11 11:49 PM, "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> wrote:

<= SPAN STYLE=3D'font-size:10.5pt'>Thank you for those of you who kindly gave me = off-line messages .
 
Let me share the draft with some minor modifications.
 
Sincerely,
Take
 
 
2011/8/5 Takeshi Takahashi <takes= hi_takahashi@nict.go.jp>:
> Dear all,
>
>  
>
> The attached is the tentative version of the draft prepared based on t= he
> comments I’ve received in this mailing list (Thanks a lot for th= at).
>
> It would be great if you could provide some comments on Clause 4, wher= e the
> IODEF extension is defined.
>
>  
>
> As you know, there are many ways to embed structured information (e.g.= CVE
> and CAPEC) in IODEF since IODEF is designed to be very flexible.
>
> Thus, I would be happy to change and develop the draft further based o= n your
> comments.
>
>  
>
> I would like to welcome any comments on that.
>
>  
>
> By the way, I will be on vacation, thus my response might be slow, sor= ry for
> the inconvenience.
>
>  
>
> Take
>
>  
>
> PS: I’ve changed the title of the email.
>
>  
>
>  
>
> 2011/7/29 <kathleen.moriarty@em= c.com>
>
>>
>
>> Thank you, the approach sounds good, especially since it is in use= today
>
>> by at least the Research and Education ISAC.  Do others have = opinions on
>
>> the proposal here?
>
>>
>
>> Thanks for writing the first draft Take!
>
>>
>
>> Best regards,
>
>> Kathleen
>
>> ________________________________________
>
>> From: mile-bounces@ietf.org [<= a href=3D"mile-bounces@ietf.org">mile-bounces@ietf.org] On Behalf Of Takes= hi
>
>> Takahashi [takeshi_takahash= i@nict.go.jp]
>
>> Sent: Friday, July 29, 2011 9:20 AM
>
>> To: 'Martin, Robert A.'; Kent_= Landfield@McAfee.com
>
>> Cc: mile@ietf.org
>
>> Subject: Re: [mile] Updated presentation from Side meeting
>
>>
>
>> Thank you, Bob, for the email.
>
>> I also like Tom's suggestion very much.
>
>> Let me work on the "draft" of the draft for a while, the= n come back to you
>
>> later.
>
>>
>
>> Take
>
>>
>
>> -----Original Message-----
>
>> From: Martin, Robert A. [mailt= o:ramartin@mitre.org]
>
>> Sent: Friday, July 29, 2011 9:10 AM
>
>> To: Kent_Landfield@McAfee.com<= /a>
>
>> Cc: takeshi_takahashi@nict.= go.jp; Thomas.Millar@us-cert.gov= ;
>
>> wes@ren-isac.net; mile@ietf.org
>
>> Subject: Re: [mile] Updated presentation from Side meeting
>
>>
>
>> I also like how this is evolving.
>
>>
>
>> I think, as Tom's suggestions pointed, that any and all of the use= ful
>
>> types
>
>> of information that can help with understanding, diagnosing, and g= etting
>
>> ahead of an incident should be added but for now we should focus o= n those
>
>> the most established and well articulated.
>
>>
>
>> This can be the compliance/patch/configuration/platform informatio= n
>
>> related
>
>> to the SCAP use case, or event signature/attack pattern/traffic >
>> characteristics from events, or the vulnerability/threat character= ization
>
>> space.
>
>>
>
>> I look forward to Taki's draft to see how he suggests positioning = these
>
>> concepts.
>
>>
>
>> Bob
>
>>
>
>> On 7/28/11 10:13 PM, Kent_Land= field@McAfee.com wrote:
>
>> > I like where this is headed.
>
>> >
>
>> > Thanks Takeshi.  I look forward to your draft. It will g= ive us something
>
>> real to discuss. I appreciate you jumping in and getting this star= ted.
>
>> >
>
>> > One question that I am not clear on. What do we envision as t= he actual
>
>> set
>
>> of deliverables?  From and SCAP related perspective, are we l= ooking at a
>
>> single draft covering all the extensions?
>
>> >
>
>> > Kent
>
>> >
>
>> > Kent Landfield
>
>> > Director Content Strategy, Architecture and Standards
>
>> >
>
>> > McAfee, Inc.
>
>> > 5000 Headquarters Dr.
>
>> > Plano, Texas 75024
>
>> >
>
>> > Direct: +1.972.963.7096
>
>> > Mobile: +1.817.637.8026
>
>> > Web: www.mcafee.com<http:= //www.mcafee.com/>
>
>> >
>
>> > From: Takeshi
>
>> > Takahashi<takeshi_takahashi@nict.go.jp<mailto:takeshi_takahashi<= /a>@nict.g
>
>> > o.jp>>
>
>> > Date: Thu, 28 Jul 2011 18:21:56 -0500
>
>> > To:
>
>> > "Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>&q= uot;<Thomas.M
>
>> > illar@us-= cert.gov<mailto:Thomas.Millar@us-cert.gov>>,
>
>> > "wes@ren-isac.n= et<mailto:wes@ren-isac.net>"<wes@ren-isac.net<mailto:we
>
>> > s@ren-isac.net>>,
>
>> > "mile@ietf.org<= ;mailto:mile@ietf.org>"<mile@ietf.org<mailto:mile@ietf.o
>
>> > rg>>
>
>> > Subject: Re: [mile] Updated presentation from Side meeting >
>> >
>
>> > Thank you for the email, Tom.
>
>> >
>
>> > So, here is what the draft needs to describe (if I understand= Wes and
>
>> > Tom correctly).
>
>> >
>
>> > The draft should define ext-dtype (an attribute of Additional= Data
>
>> > Class) to identify the information type, rather than defining= new
>
>> > class under AdditionalData.
>
>> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ex= t-capec,
>
>> > ext-cvss, ext-cwss, In this way, we could keep the change min= imal and
>
>> > could easily embed various structured information (CVE etc.) = in the
>
>> > EventData.Record.RecordData.AdditionalData field.
>
>> > Then "should" statement should be carefully placed = in the text of
>
>> > relevant class.
>
>> >
>
>> > I'll prepare some draft so that we could discuss and advance = further.
>
>> >
>
>> > Take
>
>> >
>
>> >
>
>> >
>
>> > -----Original Message-----
>
>> > From: = mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>
>
>> > [mailto:mile-bounces@i= etf.org] On Behalf Of
>
>> > T= homas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>
>
>> > Sent: Thursday, July 28, 2011 6:28 PM
>
>> > To: wes@ren-isac.net= <mailto:wes@ren-isac.net>;
>
>> > mile@ietf.org<mailt= o:mile@ietf.org>
>
>> > Subject: Re: [mile] Updated presentation from Side meeting >
>> >
>
>> > I think this approach makes more sense. One of the things I t= hink
>
>> > could be helpful is to have a number of SHOULD statements fur= ther
>
>> > describing the possible types of other documents that would b= e
>
>> > expected to ride under the AdditionalData elements of each cl= ass (not
>
>> just
>
>> EventData).
>
>> > What I'm thinking of looks like this (very unpolished):
>
>> >
>
>> > "The Method Class:AdditionalData class SHOULD contain da= ta elements
>
>> > that describe the methods, tools or techniques employed to ca= use the
>
>> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerni= ng the
>
>> > method such as CVSS, CWSS, or CCE."
>
>> >
>
>> > "The Expectation Class[...] SHOULD contain data elements= which
>
>> > describe configuration changes, detection heuristics, or [* (= legal
>
>> > authorization?)] to assist in executing or implementing the r= equested
>
>> > action, such as XCCDF, OCIL, OVAL, etc"
>
>> >
>
>> > This could go towards encouraging better or at least more con= sistent
>
>> > use of "boundary objects" in the substance of incid= ent reports. I
>
>> > could also go on about greater automation and such but that's= probably
>
>> > out of scope for this e-mail.
>
>> >
>
>> >
>
>> > - Tom Millar, US-CERT
>
>> >
>
>> > t= homas.millar@us-cert.gov<mailto:thomas.millar@us-cert.gov>
>
>> > BB: t= homas.millar@dhs.gov<mailto:thomas.millar@dhs.gov>  /
>
>> > 202-631-1915
>
>> > 24x7: soc@us-cert.gov= <mailto:soc@us-cert.gov>  / 888-282-0870
>
>> > -----Original Message-----
>
>> > From: = mile-bounces@ietf.org<mailto:mile-bounces@ietf.org>
>
>> > [mailto:mile-bounces@i= etf.org] On Behalf Of Wes Young
>
>> > Sent: Thursday, July 28, 2011 11:08 AM
>
>> > To: mile@ietf.org<m= ailto:mile@ietf.org>
>
>> > Subject: Re: [mile] Updated presentation from Side meeting >
>> >
>
>> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM >
>> >
>
>> > htt= p://tools.ietf.org/html/rfc5070#section-3.19
>
>> >
>
>> > i've been sticking other "XML like" records under t= his (icsg1.1 data,
>
>> > etc...).
>
>> >
>
>> > pretty easy to do, just generate the "other standards&qu= ot; xml (or json or
>
>> > whatever), embed it there. turns iodef into a sharing platfor= m for
>
>> > other data-types w/o having to extend it too much.
>
>> >
>
>> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote:
>
>> >
>
>> > So, maybe we could extend the IODEF as described in Figure 1 = of the
>
>> > attached txt file. (correct me if I'm wrong) We could define<= BR> >
>> > Incident.EventData.AdditionalData elements and describe them = by using
>
>> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC.
>
>> > Regarding OVAL, we might define Incident.AdditionalData eleme= nt, but I
>
>> >
>
>> > am not sure at this moment, thus is not described in the figu= re yet.
>
>> > I would like to tackle CAPEC first since I believe Kent would= like to
>
>> > tackle CVE and CAPEC.
>
>> >
>
>> > --
>
>> > Wes
>
>> > claimid.com/wesyoung
>
>> > soc@ren-isac.net<= mailto:soc@ren-isac.net>
>
>> >
>
>> > * Wes Young<wes@r= en-isac.net<mailto:wes@ren-isac.net>>
>
>> > * 0xDDB6E946 - Unverified(L)
>
>> > _______________________________________________
>
>> > mile mailing list
>
>> > mile@ietf.org<mailt= o:mile@ietf.org>
>
>> > https://= www.ietf.org/mailman/listinfo/mile
>
>> > _______________________________________________
>
>> > mile mailing list
>
>> > mile@ietf.org<mailt= o:mile@ietf.org>
>
>> > https://= www.ietf.org/mailman/listinfo/mile
>
>> >
>
>> > _______________________________________________
>
>> > mile mailing list
>
>> > mile@ietf.org<mailt= o: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.i= etf.org/mailman/listinfo/mile
>
>  
>
>  
>
>  
 
 
 
--B_3395838178_4926809-- From tony@yaanatech.com Wed Aug 10 14:35:58 2011 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 8C74C11E8094 for ; Wed, 10 Aug 2011 14:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3RPEtmqLGkV for ; Wed, 10 Aug 2011 14:35:57 -0700 (PDT) Received: from webmail.yaanatech.com (server1.yaanatech.com [66.135.59.213]) by ietfa.amsl.com (Postfix) with ESMTP id E2E1811E80BF for ; Wed, 10 Aug 2011 14:35:55 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-136-146.clppva.fios.verizon.net [173.72.136.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by webmail.yaanatech.com (Postfix) with ESMTP id 1B4761C78292 for ; Wed, 10 Aug 2011 14:36:28 -0700 (PDT) Message-ID: <4E42F9DB.6070200@yaanatech.com> Date: Wed, 10 Aug 2011 17:36:27 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: mile@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040806090901090205060300" Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:35:58 -0000 This is a multi-part message in MIME format. --------------040806090901090205060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Inunez, In the Q4/17 workplan we have X.cvrm identified as a "CYBEX" work item. Do you think we can bring it into the upcoming meeting in two weeks? I'd be willing to work with the appropriate people to make that happen. --tony On 8/10/2011 4:22 PM, lnunez wrote: > I noticed CVRF mention briefly in this email thread (good I am > thinking the same). Looking at the draft-takahash-mile-sci-01.txt I > see potential synergies between the draft and CVRF. > > They both share some heritage. Major vendors have indicated that they > will start publishing security advisories in the near future. I could > see this IODEF-extension leveraging the CVRF content/components to > provide additional fidelity to the security incident exchange. > > CVRF link: > http://www.icasi.org/cvrf > Redhat CVRF sample: > http://www.awe.com/mark/blog/20110518.html > > It would be interesting to see a CVRF advisory with OVAL checking > content as a mitigation method in this draft. > --------------040806090901090205060300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Inunez,

In the Q4/17 workplan we have X.cvrm identified as a "CYBEX"
work item.  Do you think we can bring it into the upcoming meeting
in two weeks?  I'd be willing to work with the appropriate people
to make that happen.

--tony

On 8/10/2011 4:22 PM, lnunez wrote:
Re: [mile] draft on IODEF exstension to support structured cybersecurity information I noticed CVRF mention briefly in this email thread (good I am thinking the same). Looking at the draft-takahash-mile-sci-01.txt I see potential synergies between the draft and CVRF. 

They both share some heritage.  Major vendors have indicated that they will start publishing security advisories in the near future.  I could see this IODEF-extension leveraging the CVRF content/components to provide additional fidelity to the security incident exchange.  

CVRF link:
http://www.icasi.org/cvrf
Redhat CVRF sample:
http://www.awe.com/mark/blog/20110518.html

It would be interesting to see a CVRF advisory with OVAL checking content as a mitigation method in this draft.


--------------040806090901090205060300-- From kathleen.moriarty@emc.com Wed Aug 10 18:53:40 2011 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 CB46421F8B11 for ; Wed, 10 Aug 2011 18:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 Du1+2+7mYP7t for ; Wed, 10 Aug 2011 18:53:37 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF7321F8B0D for ; Wed, 10 Aug 2011 18:53:36 -0700 (PDT) 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 p7B1s5Eg005139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2011 21:54:05 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 10 Aug 2011 21:53:59 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.221.47.158]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7B1rwVV024947; Wed, 10 Aug 2011 21:53:58 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub29.corp.emc.com ([128.221.47.158]) with mapi; Wed, 10 Aug 2011 21:53:58 -0400 From: To: , , Date: Wed, 10 Aug 2011 21:53:56 -0400 Thread-Topic: [mile] draft on IODEF exstension to support structured cybersecurity information Thread-Index: AcxWR2J9VNIFG703SAaz5tSdZ4c7ZgBU+i1yAArgbiA= Message-ID: References: <000d01cc5647$62c4c070$284e4150$@go.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AE31510960917D478171C79369B660FA0E05486342MX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 11 Aug 2011 01:53:40 -0000 --_000_AE31510960917D478171C79369B660FA0E05486342MX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interesting questions, what do others think on this one? CVRF is a way of reporting out vulnerability information, tying together so= me of the SCAP standards for more complete information on a vulnerability. = It could be a very good thing to be able to include in the extension. Is = this something the community wants to see in the extension? Thanks, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of lnu= nez Sent: Wednesday, August 10, 2011 4:23 PM To: Takeshi Takahashi; mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cyberse= curity information I noticed CVRF mention briefly in this email thread (good I am thinking the= same). Looking at the draft-takahash-mile-sci-01.txt I see potential syner= gies between the draft and CVRF. They both share some heritage. Major vendors have indicated that they will= start publishing security advisories in the near future. I could see this= IODEF-extension leveraging the CVRF content/components to provide addition= al fidelity to the security incident exchange. CVRF link: http://www.icasi.org/cvrf Redhat CVRF sample: http://www.awe.com/mark/blog/20110518.html It would be interesting to see a CVRF advisory with OVAL checking content a= s a mitigation method in this draft. One thing to keep in mind is to realized how we can build and used the vari= ous emerging set of standards in a cohesive way. thanks. On 8/8/11 11:49 PM, "Takeshi Takahashi" wrot= e: Thank you for those of you who kindly gave me off-line messages . Let me share the draft with some minor modifications. Sincerely, Take 2011/8/5 Takeshi Takahashi : > Dear all, > > > > The attached is the tentative version of the draft prepared based on the > comments I've received in this mailing list (Thanks a lot for that). > > It would be great if you could provide some comments on Clause 4, where t= he > IODEF extension is defined. > > > > As you know, there are many ways to embed structured information (e.g. CV= E > and CAPEC) in IODEF since IODEF is designed to be very flexible. > > Thus, I would be happy to change and develop the draft further based on y= our > comments. > > > > I would like to welcome any comments on that. > > > > By the way, I will be on vacation, thus my response might be slow, sorry = for > the inconvenience. > > > > Take > > > > PS: I've changed the title of the email. > > > > > > 2011/7/29 > >> > >> Thank you, the approach sounds good, especially since it is in use today > >> by at least the Research and Education ISAC. Do others have opinions on > >> the proposal here? > >> > >> Thanks for writing the first draft Take! > >> > >> Best regards, > >> Kathleen > >> ________________________________________ > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Takeshi > >> Takahashi [takeshi_takahashi@nict.go.jp] > >> Sent: Friday, July 29, 2011 9:20 AM > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> Thank you, Bob, for the email. > >> I also like Tom's suggestion very much. > >> Let me work on the "draft" of the draft for a while, then come back to y= ou > >> later. > >> > >> Take > >> > >> -----Original Message----- > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >> Sent: Friday, July 29, 2011 9:10 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >> wes@ren-isac.net; mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> I also like how this is evolving. > >> > >> I think, as Tom's suggestions pointed, that any and all of the useful > >> types > >> of information that can help with understanding, diagnosing, and getting > >> ahead of an incident should be added but for now we should focus on thos= e > >> the most established and well articulated. > >> > >> This can be the compliance/patch/configuration/platform information > >> related > >> to the SCAP use case, or event signature/attack pattern/traffic > >> characteristics from events, or the vulnerability/threat characterizatio= n > >> space. > >> > >> I look forward to Taki's draft to see how he suggests positioning these > >> concepts. > >> > >> Bob > >> > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >> > I like where this is headed. > >> > > >> > Thanks Takeshi. I look forward to your draft. It will give us somethi= ng > >> real to discuss. I appreciate you jumping in and getting this started. > >> > > >> > One question that I am not clear on. What do we envision as the actual > >> set > >> of deliverables? From and SCAP related perspective, are we looking at a > >> single draft covering all the extensions? > >> > > >> > Kent > >> > > >> > Kent Landfield > >> > Director Content Strategy, Architecture and Standards > >> > > >> > McAfee, Inc. > >> > 5000 Headquarters Dr. > >> > Plano, Texas 75024 > >> > > >> > Direct: +1.972.963.7096 > >> > Mobile: +1.817.637.8026 > >> > Web: www.mcafee.com > >> > > >> > From: Takeshi > >> > Takahashi@nict.g > >> > o.jp>> > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > >> > To: > >> > "Thomas.Millar@us-cert.gov@us-cert.gov>" >> > illar@us-cert.gov@us-cert.gov>>, > >> > "wes@ren-isac.net@ren-isac.n= et>" > >> > s@ren-isac.net>>, > >> > "mile@ietf.org@ietf.org>"@ietf.o > >> > rg>> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > Thank you for the email, Tom. > >> > > >> > So, here is what the draft needs to describe (if I understand Wes and > >> > Tom correctly). > >> > > >> > The draft should define ext-dtype (an attribute of AdditionalData > >> > Class) to identify the information type, rather than defining new > >> > class under AdditionalData. > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec, > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal and > >> > could easily embed various structured information (CVE etc.) in the > >> > EventData.Record.RecordData.AdditionalData field. > >> > Then "should" statement should be carefully placed in the text of > >> > relevant class. > >> > > >> > I'll prepare some draft so that we could discuss and advance further. > >> > > >> > Take > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org@ietf.org> > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > >> > Thomas.Millar@us-cert.gov@us-cert.gov> > >> > Sent: Thursday, July 28, 2011 6:28 PM > >> > To: wes@ren-isac.net@ren-isa= c.net>; > >> > mile@ietf.org@ietf.org> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > I think this approach makes more sense. One of the things I think > >> > could be helpful is to have a number of SHOULD statements further > >> > describing the possible types of other documents that would be > >> > expected to ride under the AdditionalData elements of each class (not > >> just > >> EventData). > >> > What I'm thinking of looks like this (very unpolished): > >> > > >> > "The Method Class:AdditionalData class SHOULD contain data elements > >> > that describe the methods, tools or techniques employed to cause the > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the > >> > method such as CVSS, CWSS, or CCE." > >> > > >> > "The Expectation Class[...] SHOULD contain data elements which > >> > describe configuration changes, detection heuristics, or [* (legal > >> > authorization?)] to assist in executing or implementing the requested > >> > action, such as XCCDF, OCIL, OVAL, etc" > >> > > >> > This could go towards encouraging better or at least more consistent > >> > use of "boundary objects" in the substance of incident reports. I > >> > could also go on about greater automation and such but that's probably > >> > out of scope for this e-mail. > >> > > >> > > >> > - Tom Millar, US-CERT > >> > > >> > thomas.millar@us-cert.gov@us-cert.gov> > >> > BB: thomas.millar@dhs.gov@dhs.gov> / > >> > 202-631-1915 > >> > 24x7: soc@us-cert.gov@us-cert= .gov> / 888-282-0870 > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org@ietf.org> > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >> > Sent: Thursday, July 28, 2011 11:08 AM > >> > To: mile@ietf.org@ietf.org> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >> > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > >> > > >> > i've been sticking other "XML like" records under this (icsg1.1 data, > >> > etc...). > >> > > >> > pretty easy to do, just generate the "other standards" xml (or json or > >> > whatever), embed it there. turns iodef into a sharing platform for > >> > other data-types w/o having to extend it too much. > >> > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >> > > >> > So, maybe we could extend the IODEF as described in Figure 1 of the > >> > attached txt file. (correct me if I'm wrong) We could define > >> > Incident.EventData.AdditionalData elements and describe them by using > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >> > Regarding OVAL, we might define Incident.AdditionalData element, but I > >> > > >> > am not sure at this moment, thus is not described in the figure yet. > >> > I would like to tackle CAPEC first since I believe Kent would like to > >> > tackle CVE and CAPEC. > >> > > >> > -- > >> > Wes > >> > claimid.com/wesyoung > >> > soc@ren-isac.net@ren-isac.ne= t> > >> > > >> > * Wes Young= @ren-isac.net>> > >> > * 0xDDB6E946 - Unverified(L) > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org@ietf.org> > >> > https://www.ietf.org/mailman/listinfo/mile > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org@ietf.org> > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org@ietf.org> > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > . > >> > > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > --_000_AE31510960917D478171C79369B660FA0E05486342MX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mile] dr= aft on IODEF exstension to support structured cybersecurity information</ti= tle><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbs= p;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fon= t-family:"Calibri","sans-serif";color:#1F497D'>Interesting questions, what = do others think on this one?  <o:p></o:p></span></p><p class=3DMsoNorm= al><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color= :#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>CVRF is a= way of reporting out vulnerability information, tying together some of the= SCAP standards for more complete information on a vulnerability.  It = could be a very good thing to be able to include in the extension.  Is= this something the community wants to see in the extension?<o:p></o:p></sp= an></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DM= soNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"= ;color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=3DMsoNormal><span sty= le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Ka= thleen<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:1= 1.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></= span></p><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padd= ing:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.= 0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-= size:10.0pt;font-family:"Tahoma","sans-serif"'> mile-bounces@ietf.org [mail= to:mile-bounces@ietf.org] <b>On Behalf Of </b>lnunez<br><b>Sent:</b> Wednes= day, August 10, 2011 4:23 PM<br><b>To:</b> Takeshi Takahashi; mile@ietf.org= <br><b>Subject:</b> Re: [mile] draft on IODEF exstension to support structu= red cybersecurity information<o:p></o:p></span></p></div></div><p class=3DM= soNormal><o:p> </o:p></p><p class=3DMsoNormal style=3D'margin-bottom:1= 2.0pt'><span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'>= I noticed CVRF mention briefly in this email thread (good I am thinking the= same). Looking at the draft-takahash-mile-sci-01.txt I see potential syner= gies between the draft and CVRF.  <br><br>They both share some heritag= e.  Major vendors have indicated that they will start publishing secur= ity advisories in the near future.  I could see this IODEF-extension l= everaging the CVRF content/components to provide additional fidelity to the= security incident exchange.   <br><br>CVRF link:<br><a href=3D"http:/= /www.icasi.org/cvrf">http://www.icasi.org/cvrf</a><br>Redhat CVRF sample:<b= r><a href=3D"http://www.awe.com/mark/blog/20110518.html">http://www.awe.com= /mark/blog/20110518.html</a><br><br>It would be interesting to see a CVRF a= dvisory with OVAL checking content as a mitigation method in this draft.<br= ><br>One thing to keep in mind is to realized how we can build and used the= various emerging set of standards in a cohesive way. <br><br>thanks.<br><b= r><br>On 8/8/11 11:49 PM, "Takeshi Takahashi" <<a href=3D"take= shi_takahashi@nict.go.jp">takeshi_takahashi@nict.go.jp</a>> wrote:</span= ><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-f= amily:"Calibri","sans-serif"'>Thank you for those of you who kindly gave me= off-line messages .<br> <br>Let me share the draft with some minor mo= difications.<br> <br>Sincerely,<br>Take<br> <br> <br>2011/8/= 5 Takeshi Takahashi <<a href=3D"takeshi_takahashi@nict.go.jp">takeshi_ta= kahashi@nict.go.jp</a>>:<br>> Dear all,<br>> <br>>  <br>&g= t; <br>> The attached is the tentative version of the draft prepared bas= ed on the<br>> comments I’ve received in this mailing list (Thanks= a lot for that).<br>> <br>> It would be great if you could provide s= ome comments on Clause 4, where the<br>> IODEF extension is defined.<br>= > <br>>  <br>> <br>> As you know, there are many ways to e= mbed structured information (e.g. CVE<br>> and CAPEC) in IODEF since IOD= EF is designed to be very flexible.<br>> <br>> Thus, I would be happy= to change and develop the draft further based on your<br>> comments.<br= >> <br>>  <br>> <br>> I would like to welcome any comments= on that.<br>> <br>>  <br>> <br>> By the way, I will be on= vacation, thus my response might be slow, sorry for<br>> the inconvenie= nce.<br>> <br>>  <br>> <br>> Take<br>> <br>>  <= br>> <br>> PS: I’ve changed the title of the email.<br>> <br= >>  <br>> <br>>  <br>> <br>> 2011/7/29 <<a href= =3D"kathleen.moriarty@emc.com">kathleen.moriarty@emc.com</a>><br>> <b= r>>> <br>> <br>>> Thank you, the approach sounds good, espec= ially since it is in use today<br>> <br>>> by at least the Researc= h and Education ISAC.  Do others have opinions on<br>> <br>>>= the proposal here?<br>> <br>>> <br>> <br>>> Thanks for w= riting the first draft Take!<br>> <br>>> <br>> <br>>> Bes= t regards,<br>> <br>>> Kathleen<br>> <br>>> _____________= ___________________________<br>> <br>>> From: <a href=3D"mile-boun= ces@ietf.org">mile-bounces@ietf.org</a> [<a href=3D"mile-bounces@ietf.org">= mile-bounces@ietf.org</a>] On Behalf Of Takeshi<br>> <br>>> Takaha= shi [<a href=3D"takeshi_takahashi@nict.go.jp">takeshi_takahashi@nict.go.jp<= /a>]<br>> <br>>> Sent: Friday, July 29, 2011 9:20 AM<br>> <br>&= gt;> To: 'Martin, Robert A.'; <a href=3D"Kent_Landfield@McAfee.com">Kent= _Landfield@McAfee.com</a><br>> <br>>> Cc: <a href=3D"mile@ietf.org= ">mile@ietf.org</a><br>> <br>>> Subject: Re: [mile] Updated presen= tation from Side meeting<br>> <br>>> <br>> <br>>> Thank y= ou, Bob, for the email.<br>> <br>>> I also like Tom's suggestion v= ery much.<br>> <br>>> Let me work on the "draft" of the = draft for a while, then come back to you<br>> <br>>> later.<br>>= ; <br>>> <br>> <br>>> Take<br>> <br>>> <br>> <br= >>> -----Original Message-----<br>> <br>>> From: Martin, Rob= ert A. [<a href=3D"mailto:ramartin@mitre.org">mailto:ramartin@mitre.org</a>= ]<br>> <br>>> Sent: Friday, July 29, 2011 9:10 AM<br>> <br>>= > To: <a href=3D"Kent_Landfield@McAfee.com">Kent_Landfield@McAfee.com</a= ><br>> <br>>> Cc: <a href=3D"takeshi_takahashi@nict.go.jp">takeshi= _takahashi@nict.go.jp</a>; <a href=3D"Thomas.Millar@us-cert.gov">Thomas.Mil= lar@us-cert.gov</a>;<br>> <br>>> <a href=3D"wes@ren-isac.net">wes@= ren-isac.net</a>; <a href=3D"mile@ietf.org">mile@ietf.org</a><br>> <br>&= gt;> Subject: Re: [mile] Updated presentation from Side meeting<br>> = <br>>> <br>> <br>>> I also like how this is evolving.<br>>= ; <br>>> <br>> <br>>> I think, as Tom's suggestions pointed,= that any and all of the useful<br>> <br>>> types<br>> <br>>= > of information that can help with understanding, diagnosing, and getti= ng<br>> <br>>> ahead of an incident should be added but for now we= should focus on those<br>> <br>>> the most established and well a= rticulated.<br>> <br>>> <br>> <br>>> This can be the comp= liance/patch/configuration/platform information<br>> <br>>> relate= d<br>> <br>>> to the SCAP use case, or event signature/attack patt= ern/traffic<br>> <br>>> characteristics from events, or the vulner= ability/threat characterization<br>> <br>>> space.<br>> <br>>= ;> <br>> <br>>> I look forward to Taki's draft to see how he su= ggests positioning these<br>> <br>>> concepts.<br>> <br>>>= ; <br>> <br>>> Bob<br>> <br>>> <br>> <br>>> On 7= /28/11 10:13 PM, <a href=3D"Kent_Landfield@McAfee.com">Kent_Landfield@McAfe= e.com</a> wrote:<br>> <br>>> > I like where this is headed.<br>= > <br>>> ><br>> <br>>> > Thanks Takeshi.  I lo= ok forward to your draft. It will give us something<br>> <br>>> re= al to discuss. I appreciate you jumping in and getting this started.<br>>= ; <br>>> ><br>> <br>>> > One question that I am not cl= ear on. What do we envision as the actual<br>> <br>>> set<br>> = <br>>> of deliverables?  From and SCAP related perspective, are = we looking at a<br>> <br>>> single draft covering all the extensio= ns?<br>> <br>>> ><br>> <br>>> > Kent<br>> <br>&g= t;> ><br>> <br>>> > Kent Landfield<br>> <br>>> &= gt; Director Content Strategy, Architecture and Standards<br>> <br>>&= gt; ><br>> <br>>> > McAfee, Inc.<br>> <br>>> > 5= 000 Headquarters Dr.<br>> <br>>> > Plano, Texas 75024<br>> <= br>>> ><br>> <br>>> > Direct: +1.972.963.7096<br>> = <br>>> > Mobile: +1.817.637.8026<br>> <br>>> > Web: ww= w.mcafee.com<<a href=3D"http://www.mcafee.com/">http://www.mcafee.com/</= a>><br>> <br>>> ><br>> <br>>> > From: Takeshi<br= >> <br>>> > Takahashi<<a href=3D"takeshi_takahashi@nict.go.j= p%3cmailto:takeshi_takahashi">takeshi_takahashi@nict.go.jp<mailto:takesh= i_takahashi</a>@nict.g<br>> <br>>> > o.jp>><br>> <br>&= gt;> > Date: Thu, 28 Jul 2011 18:21:56 -0500<br>> <br>>> >= ; To:<br>> <br>>> > "<a href=3D"Thomas.Millar@us-cert.gov%= 3cmailto:Thomas.Millar">Thomas.Millar@us-cert.gov<mailto:Thomas.Millar</= a>@us-cert.gov>"<Thomas.M<br>> <br>>> > <a href=3D"i= llar@us-cert.gov%3cmailto:Thomas.Millar">illar@us-cert.gov<mailto:Thomas= .Millar</a>@us-cert.gov>>,<br>> <br>>> > "<a href=3D= "wes@ren-isac.net%3cmailto:wes">wes@ren-isac.net<mailto:wes</a>@ren-isac= .net>"<<a href=3D"wes@ren-isac.net%3cmailto:we">wes@ren-isac.net= <mailto:we</a><br>> <br>>> > <a href=3D"s@ren-isac.net%3e">s= @ren-isac.net></a>>,<br>> <br>>> > "<a href=3D"mile@= ietf.org%3cmailto:mile">mile@ietf.org<mailto:mile</a>@ietf.org>"= <<a href=3D"mile@ietf.org%3cmailto:mile">mile@ietf.org<mailto:mile</a= >@ietf.o<br>> <br>>> > rg>><br>> <br>>> > Sub= ject: Re: [mile] Updated presentation from Side meeting<br>> <br>>>= ; ><br>> <br>>> > Thank you for the email, Tom.<br>> <br>= >> ><br>> <br>>> > So, here is what the draft needs to= describe (if I understand Wes and<br>> <br>>> > Tom correctly)= .<br>> <br>>> ><br>> <br>>> > The draft should defi= ne ext-dtype (an attribute of AdditionalData<br>> <br>>> > Clas= s) to identify the information type, rather than defining new<br>> <br>&= gt;> > class under AdditionalData.<br>> <br>>> > Ext-dtyp= e: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec,<br>> <br>&= gt;> > ext-cvss, ext-cwss, In this way, we could keep the change mini= mal and<br>> <br>>> > could easily embed various structured inf= ormation (CVE etc.) in the<br>> <br>>> > EventData.Record.Recor= dData.AdditionalData field.<br>> <br>>> > Then "should&quo= t; statement should be carefully placed in the text of<br>> <br>>>= > relevant class.<br>> <br>>> ><br>> <br>>> > I= 'll prepare some draft so that we could discuss and advance further.<br>>= ; <br>>> ><br>> <br>>> > Take<br>> <br>>> >= ;<br>> <br>>> ><br>> <br>>> ><br>> <br>>> = > -----Original Message-----<br>> <br>>> > From: <a href=3D"= mile-bounces@ietf.org%3cmailto:mile-bounces">mile-bounces@ietf.org<mailt= o:mile-bounces</a>@ietf.org><br>> <br>>> > [<a href=3D"mailt= o:mile-bounces@ietf.org">mailto:mile-bounces@ietf.org</a>] On Behalf Of<br>= > <br>>> > <a href=3D"Thomas.Millar@us-cert.gov%3cmailto:Thomas= .Millar">Thomas.Millar@us-cert.gov<mailto:Thomas.Millar</a>@us-cert.gov&= gt;<br>> <br>>> > Sent: Thursday, July 28, 2011 6:28 PM<br>>= <br>>> > To: <a href=3D"wes@ren-isac.net%3cmailto:wes">wes@ren-is= ac.net<mailto:wes</a>@ren-isac.net>;<br>> <br>>> > <a hre= f=3D"mile@ietf.org%3cmailto:mile">mile@ietf.org<mailto:mile</a>@ietf.org= ><br>> <br>>> > Subject: Re: [mile] Updated presentation fro= m Side meeting<br>> <br>>> ><br>> <br>>> > I think = this approach makes more sense. One of the things I think<br>> <br>>&= gt; > could be helpful is to have a number of SHOULD statements further<= br>> <br>>> > describing the possible types of other documents = that would be<br>> <br>>> > expected to ride under the Addition= alData elements of each class (not<br>> <br>>> just<br>> <br>&g= t;> EventData).<br>> <br>>> > What I'm thinking of looks lik= e this (very unpolished):<br>> <br>>> ><br>> <br>>> &g= t; "The Method Class:AdditionalData class SHOULD contain data elements= <br>> <br>>> > that describe the methods, tools or techniques e= mployed to cause the<br>> <br>>> > incident, such as CAPEC, CWE= , CVE, CVRF, or metadata concerning the<br>> <br>>> > method su= ch as CVSS, CWSS, or CCE."<br>> <br>>> ><br>> <br>>&= gt; > "The Expectation Class[...] SHOULD contain data elements whic= h<br>> <br>>> > describe configuration changes, detection heuri= stics, or [* (legal<br>> <br>>> > authorization?)] to assist in= executing or implementing the requested<br>> <br>>> > action, = such as XCCDF, OCIL, OVAL, etc"<br>> <br>>> ><br>> <br>= >> > This could go towards encouraging better or at least more con= sistent<br>> <br>>> > use of "boundary objects" in th= e substance of incident reports. I<br>> <br>>> > could also go = on about greater automation and such but that's probably<br>> <br>>&g= t; > out of scope for this e-mail.<br>> <br>>> ><br>> <br= >>> ><br>> <br>>> > - Tom Millar, US-CERT<br>> <br>= >> ><br>> <br>>> > <a href=3D"thomas.millar@us-cert.go= v%3cmailto:thomas.millar">thomas.millar@us-cert.gov<mailto:thomas.millar= </a>@us-cert.gov><br>> <br>>> > BB: <a href=3D"thomas.millar= @dhs.gov%3cmailto:thomas.millar">thomas.millar@dhs.gov<mailto:thomas.mil= lar</a>@dhs.gov>  /<br>> <br>>> > 202-631-1915<br>> = <br>>> > 24x7: <a href=3D"soc@us-cert.gov%3cmailto:soc">soc@us-cer= t.gov<mailto:soc</a>@us-cert.gov>  / 888-282-0870<br>> <br>&g= t;> > -----Original Message-----<br>> <br>>> > From: <a h= ref=3D"mile-bounces@ietf.org%3cmailto:mile-bounces">mile-bounces@ietf.org&l= t;mailto:mile-bounces</a>@ietf.org><br>> <br>>> > [<a href= =3D"mailto:mile-bounces@ietf.org">mailto:mile-bounces@ietf.org</a>] On Beha= lf Of Wes Young<br>> <br>>> > Sent: Thursday, July 28, 2011 11:= 08 AM<br>> <br>>> > To: <a href=3D"mile@ietf.org%3cmailto:mile"= >mile@ietf.org<mailto:mile</a>@ietf.org><br>> <br>>> > Su= bject: Re: [mile] Updated presentation from Side meeting<br>> <br>>&g= t; ><br>> <br>>> > * PGP Signed by an unverified key: 7/28/2= 011 at 11:08:06 AM<br>> <br>>> ><br>> <br>>> > <a h= ref=3D"http://tools.ietf.org/html/rfc5070#section-3.19">http://tools.ietf.o= rg/html/rfc5070#section-3.19</a><br>> <br>>> ><br>> <br>>= > > i've been sticking other "XML like" records under this = (icsg1.1 data,<br>> <br>>> > etc...).<br>> <br>>> >= <br>> <br>>> > pretty easy to do, just generate the "other= standards" xml (or json or<br>> <br>>> > whatever), embed= it there. turns iodef into a sharing platform for<br>> <br>>> >= ; other data-types w/o having to extend it too much.<br>> <br>>> &= gt;<br>> <br>>> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahas= hi wrote:<br>> <br>>> ><br>> <br>>> > So, maybe we = could extend the IODEF as described in Figure 1 of the<br>> <br>>>= > attached txt file. (correct me if I'm wrong) We could define<br>> = <br>>> > Incident.EventData.AdditionalData elements and describe t= hem by using<br>> <br>>> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC.<= br>> <br>>> > Regarding OVAL, we might define Incident.Addition= alData element, but I<br>> <br>>> ><br>> <br>>> > a= m not sure at this moment, thus is not described in the figure yet.<br>>= <br>>> > I would like to tackle CAPEC first since I believe Kent = would like to<br>> <br>>> > tackle CVE and CAPEC.<br>> <br>&= gt;> ><br>> <br>>> > --<br>> <br>>> > Wes<br>= > <br>>> > claimid.com/wesyoung<br>> <br>>> > <a hr= ef=3D"soc@ren-isac.net%3cmailto:soc">soc@ren-isac.net<mailto:soc</a>@ren= -isac.net><br>> <br>>> ><br>> <br>>> > * Wes You= ng<<a href=3D"wes@ren-isac.net%3cmailto:wes">wes@ren-isac.net<mailto:= wes</a>@ren-isac.net>><br>> <br>>> > * 0xDDB6E946 - Unver= ified(L)<br>> <br>>> > ________________________________________= _______<br>> <br>>> > mile mailing list<br>> <br>>> &g= t; <a href=3D"mile@ietf.org%3cmailto:mile">mile@ietf.org<mailto:mile</a>= @ietf.org><br>> <br>>> > <a href=3D"https://www.ietf.org/mai= lman/listinfo/mile">https://www.ietf.org/mailman/listinfo/mile</a><br>> = <br>>> > _______________________________________________<br>> <= br>>> > mile mailing list<br>> <br>>> > <a href=3D"mil= e@ietf.org%3cmailto:mile">mile@ietf.org<mailto:mile</a>@ietf.org><br>= > <br>>> > <a href=3D"https://www.ietf.org/mailman/listinfo/mil= e">https://www.ietf.org/mailman/listinfo/mile</a><br>> <br>>> >= <br>> <br>>> > _______________________________________________<= br>> <br>>> > mile mailing list<br>> <br>>> > <a hr= ef=3D"mile@ietf.org%3cmailto:mile">mile@ietf.org<mailto:mile</a>@ietf.or= g><br>> <br>>> > <a href=3D"https://www.ietf.org/mailman/lis= tinfo/mile">https://www.ietf.org/mailman/listinfo/mile</a><br>> <br>>= > ><br>> <br>>> > _______________________________________= ________<br>> <br>>> > mile mailing list<br>> <br>>> &= gt; <a href=3D"mile@ietf.org">mile@ietf.org</a><br>> <br>>> > <= a href=3D"https://www.ietf.org/mailman/listinfo/mile">https://www.ietf.org/= mailman/listinfo/mile</a><br>> <br>>> > .<br>> <br>>> = ><br>> <br>>> <br>> <br>>> ___________________________= ____________________<br>> <br>>> mile mailing list<br>> <br>>= ;> <a href=3D"mile@ietf.org">mile@ietf.org</a><br>> <br>>> <a h= ref=3D"https://www.ietf.org/mailman/listinfo/mile">https://www.ietf.org/mai= lman/listinfo/mile</a><br>> <br>>  <br>> <br>>  <br>&= gt; <br>>  <br> <br> <br> </span><o:p></o:p></p></di= v></body></html>= --_000_AE31510960917D478171C79369B660FA0E05486342MX06Acorpemcc_-- From lnunez@c3isecurity.com Thu Aug 11 12:08:50 2011 Return-Path: <lnunez@c3isecurity.com> 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 07BDC21F8C29 for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 12:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y91Ox6G9bMoZ for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 12:08:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35B6C21F8C28 for <mile@ietf.org>; Thu, 11 Aug 2011 12:08:48 -0700 (PDT) Received: by ywm21 with SMTP id 21so1706030ywm.31 for <mile@ietf.org>; Thu, 11 Aug 2011 12:09:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.178.9 with SMTP id e9mr12803153yhm.185.1313089763783; Thu, 11 Aug 2011 12:09:23 -0700 (PDT) Received: by 10.236.47.199 with HTTP; Thu, 11 Aug 2011 12:09:23 -0700 (PDT) X-Originating-IP: [66.57.25.190] In-Reply-To: <4E42F9DB.6070200@yaanatech.com> References: <CA6860E2.1E4BC%lnunez@cisco.com> <4E42F9DB.6070200@yaanatech.com> Date: Thu, 11 Aug 2011 15:09:23 -0400 Message-ID: <CAFnG=rqKDFzjBzW9_=0GHL6p_NaRCsdkTV==MUYRE9E_mNgc1w@mail.gmail.com> From: luis nunez <lnunez@c3isecurity.com> To: tony@yaanatech.com Content-Type: multipart/alternative; boundary=20cf303f6c5cedb33404aa3f880d Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mile> List-Post: <mailto:mile@ietf.org> List-Help: <mailto:mile-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2011 19:08:50 -0000 --20cf303f6c5cedb33404aa3f880d Content-Type: text/plain; charset=ISO-8859-1 fyi > *Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting Framework *posted to ITU. http://www.itu.int/md/T09-SG17-C-0538/en -ln On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski <tony@yaanatech.com> wrote: > Hi Inunez, > > In the Q4/17 workplan we have X.cvrm identified as a "CYBEX" > work item. Do you think we can bring it into the upcoming meeting > in two weeks? I'd be willing to work with the appropriate people > to make that happen. > > --tony > > > On 8/10/2011 4:22 PM, lnunez wrote: > > I noticed CVRF mention briefly in this email thread (good I am thinking the > same). Looking at the draft-takahash-mile-sci-01.txt I see potential > synergies between the draft and CVRF. > > They both share some heritage. Major vendors have indicated that they will > start publishing security advisories in the near future. I could see this > IODEF-extension leveraging the CVRF content/components to provide additional > fidelity to the security incident exchange. > > CVRF link: > http://www.icasi.org/cvrf > Redhat CVRF sample: > http://www.awe.com/mark/blog/20110518.html > > It would be interesting to see a CVRF advisory with OVAL checking content > as a mitigation method in this draft. > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > --20cf303f6c5cedb33404aa3f880d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable fyi > <strong>Proposed new work item - ITU-T X.cvrf, Common Vulnerabilit= y Reporting Framework<br></strong>posted to ITU.<br><br><a href=3D"http://w= ww.itu.int/md/T09-SG17-C-0538/en">http://www.itu.int/md/T09-SG17-C-0538/en<= /a><br> <div class=3D"gmail_quote"><br>-ln<br><br>On Wed, Aug 10, 2011 at 5:36 PM, = Tony Rutkowski <span dir=3D"ltr"><<a href=3D"mailto:tony@yaanatech.com">= tony@yaanatech.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"= > =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"> Hi Inunez,<br> <br> In the Q4/17 workplan we have X.cvrm identified as a "CYBEX"<= br> work item.=A0 Do you think we can bring it into the upcoming meeting<br= > in two weeks?=A0 I'd be willing to work with the appropriate people= <br> to make that happen.<br><font color=3D"#888888"> <br> --tony</font><div class=3D"im"><br> <br> On 8/10/2011 4:22 PM, lnunez wrote: <blockquote type=3D"cite"> =20 <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font= -size:10.5pt">I noticed CVRF mention briefly in this email thread (good I am thinking the same). Looking at the draft-takahash-mile-sci-01.txt I see potential synergies between the draft and CVRF.=A0 <br> <br> They both share some heritage.=A0 Major vendors have indicated that they will start publishing security advisories in the near future.=A0 I could see this IODEF-extension leveraging the CVRF content/components to provide additional fidelity to the security incident exchange. =A0 <br> <br> CVRF link:<br> <a href=3D"http://www.icasi.org/cvrf" target=3D"_blank">http://ww= w.icasi.org/cvrf</a><br> Redhat CVRF sample:<br> <a href=3D"http://www.awe.com/mark/blog/20110518.html" target=3D"= _blank">http://www.awe.com/mark/blog/20110518.html</a><br> <br> It would be interesting to see a CVRF advisory with OVAL checking content as a mitigation method in this draft.<br> </span></font><br> </blockquote> <br> </div></div> <br>_______________________________________________<br> mile mailing list<br> <a href=3D"mailto:mile@ietf.org">mile@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/mile" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/mile</a><br> <br></blockquote></div><br> --20cf303f6c5cedb33404aa3f880d-- From tony@yaanatech.com Thu Aug 11 12:18:06 2011 Return-Path: <tony@yaanatech.com> 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 3854E21F8B82 for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 12:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebk-BLP4x5YM for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 12:18:05 -0700 (PDT) Received: from webmail.yaanatech.com (server1.yaanatech.com [66.135.59.213]) by ietfa.amsl.com (Postfix) with ESMTP id 363FF21F8B80 for <mile@ietf.org>; Thu, 11 Aug 2011 12:18:04 -0700 (PDT) Received: from [192.168.0.4] (pool-173-72-136-146.clppva.fios.verizon.net [173.72.136.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by webmail.yaanatech.com (Postfix) with ESMTP id 3B7791C78292; Thu, 11 Aug 2011 12:18:38 -0700 (PDT) Message-ID: <4E442B0D.4030704@yaanatech.com> Date: Thu, 11 Aug 2011 15:18:37 -0400 From: Tony Rutkowski <tony@yaanatech.com> Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: luis nunez <lnunez@c3isecurity.com> References: <CA6860E2.1E4BC%lnunez@cisco.com> <4E42F9DB.6070200@yaanatech.com> <CAFnG=rqKDFzjBzW9_=0GHL6p_NaRCsdkTV==MUYRE9E_mNgc1w@mail.gmail.com> In-Reply-To: <CAFnG=rqKDFzjBzW9_=0GHL6p_NaRCsdkTV==MUYRE9E_mNgc1w@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------070304040700070607020606" Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mile> List-Post: <mailto:mile@ietf.org> List-Help: <mailto:mile-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2011 19:18:06 -0000 This is a multi-part message in MIME format. --------------070304040700070607020606 Content-Type: multipart/alternative; boundary="------------050202050800090804080500" --------------050202050800090804080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For those who don't have a TIES account to get access, I've attached the document...although there's about to be a rev 1 with a slight tweak. (Accounts can be arranged if you don't have them.) The responsiveness here is pretty cool, and substantial cudos are due to Gregg Schudel and Cisco. It's about the nearest thing to "just in time" standards work as it gets. -tony On 8/11/2011 3:09 PM, luis nunez wrote: > fyi > *Proposed new work item - ITU-T X.cvrf, Common Vulnerability > Reporting Framework > *posted to ITU. > > http://www.itu.int/md/T09-SG17-C-0538/en > > -ln > > On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski <tony@yaanatech.com > <mailto:tony@yaanatech.com>> wrote: > > Hi Inunez, > > In the Q4/17 workplan we have X.cvrm identified as a "CYBEX" > work item. Do you think we can bring it into the upcoming meeting > in two weeks? I'd be willing to work with the appropriate people > to make that happen. > --------------050202050800090804080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> For those who don't have a TIES account to get access,<br> I've attached the document...although there's about to<br> be a rev 1 with a slight tweak.  (Accounts can be<br> arranged if you don't have them.)<br> <br> The responsiveness here is pretty cool, and substantial<br> cudos are due to Gregg Schudel and Cisco.  It's about the <br> nearest thing to "just in time" standards work as it gets.<br> <br> -tony<br> <br> On 8/11/2011 3:09 PM, luis nunez wrote: <blockquote cite="mid:CAFnG=rqKDFzjBzW9_=0GHL6p_NaRCsdkTV==MUYRE9E_mNgc1w@mail.gmail.com" type="cite">fyi > <strong>Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting Framework<br> </strong>posted to ITU.<br> <br> <a moz-do-not-send="true" href="http://www.itu.int/md/T09-SG17-C-0538/en">http://www.itu.int/md/T09-SG17-C-0538/en</a><br> <div class="gmail_quote"><br> -ln<br> <br> On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski <span dir="ltr"><<a moz-do-not-send="true" href="mailto:tony@yaanatech.com">tony@yaanatech.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div bgcolor="#FFFFFF" text="#000000"> Hi Inunez,<br> <br> In the Q4/17 workplan we have X.cvrm identified as a "CYBEX"<br> work item.  Do you think we can bring it into the upcoming meeting<br> in two weeks?  I'd be willing to work with the appropriate people<br> to make that happen.<font color="#888888"></font><br> </div> </blockquote> </div> </blockquote> <br> </body> </html> --------------050202050800090804080500-- --------------070304040700070607020606 Content-Type: application/msword; name="T09-SG17-C-0538!!MSW-E.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="T09-SG17-C-0538!!MSW-E.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAbQAAAAAA AAAAEAAAbwAAAAEAAAD+////AAAAAGwAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAgYEJBAAA+BK/AAAAAAABEQABAAEACAAA FRkAAA4AYmpiarXMtcwAAAAAAAAAAAAAAAAAAAAAAAAJBBYAK0YAANemAADXpgAAcw4AAAAA AAChAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAALcAAAAAAMAfAAAAAAAAwB8AAIEtAAAAAAAAgS0AAAAAAACBLQAA AAAAAIEtAAAAAAAAgS0AABQAAAAAAAAAAAAAAJUtAAAAAAAAlS0AAAAAAACVLQAAAAAAAJUt AAA4AAAAzS0AACQAAADxLQAATAAAAJUtAAAAAAAAHksAAHoBAAA9LgAAAAAAAD0uAAAWAAAA Uy4AAAAAAABTLgAAAAAAAFMuAAAAAAAAry8AAN4AAACNMAAAbAAAAPkwAAA4AAAAwUoAAAIA AADDSgAAAAAAAMNKAAAAAAAAw0oAAAAAAADDSgAAAAAAAMNKAAAAAAAAw0oAAAAAAACYTAAA ogIAADpPAAAkAgAAw0oAABUAAAAAAAAAAAAAAAAAAAAAAAAAgS0AAAAAAAAxMQAAAAAAAAAA AAAAAAAAAAAAAAAAAACvLwAAAAAAAK8vAAAAAAAAMTEAAAQAAAA1MQAABAAAAMNKAAAAAAAA eTIAAAAAAACBLQAAAAAAAIEtAAAAAAAAUy4AAAAAAAAAAAAAAAAAAFMuAABcAQAA2EoAABYA AAB5MgAAAAAAAHkyAAAAAAAAeTIAAAAAAAA5MQAA0AAAAIEtAAAAAAAAUy4AAAAAAACBLQAA AAAAAFMuAAAAAAAAwUoAAAAAAAAAAAAAAAAAAHkyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTEAAAAAAADBSgAAAAAAAAAAAAAAAAAA eTIAAAAAAAB5MgAA/gAAADFHAAAIAQAAgS0AAAAAAACBLQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZUkAABQAAAAAAAAA AAAAAAAAAAAAAAAAP4/PLjRYzAEAAAAAAAAAAJUtAAAAAAAACTIAAHAAAAA5SAAAGAAAAAAA AAAAAAAAlUkAACwBAADuSgAAMAAAAB5LAAAAAAAAUUgAABQBAABeUQAAAAAAAHkyAAAAAAAA XlEAADAAAAB5SQAAAAAAAHkyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBLQAA AAAAAHlJAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADExAAAAAAAAMTEAAAAAAAAxMQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// //8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADAHwAAhwwAAEcsAAA6AQAABwAMAQ8ADQEAAAkEAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEHSU5URVJOQVRJT05BTCBURUxFQ09NTVVOSUNBVElP TiBVTklPTgdDT00gMTcgliBDIDA1MziWIEUHBwdURUxFQ09NTVVOSUNBVElPTgtTVEFOREFS RElaQVRJT04gU0VDVE9SDVNUVURZIFBFUklPRCAyMDA5LTIwMTIHQXVndXN0IDIwMTEHBwcH RW5nbGlzaCBvbmx5DU9yaWdpbmFsOiBFbmdsaXNoBwdRdWVzdGlvbihzKToHNC8xNwcHB1NU VURZIEdST1VQIDE3IJYgQ09OVFJJQlVUSU9OIFhYWAcHU291cmNlOgdDaXNjbyBTeXN0ZW1z LCBJbmMuBwdUaXRsZToHUHJvcG9zZWQgbmV3IHdvcmsgaXRlbSAtIElUVS1UIFguY3ZyZiwg Q29tbW9uIFZ1bG5lcmFiaWxpdHkgUmVwb3J0aW5nIEZyYW1ld29yawcHSW50cm9kdWN0aW9u DUlUVS1UIFJlY29tbWVuZGF0aW9uIElUVS1UIFguMTUwMCAoWC5jeWJleCksIEN5YmVyc2Vj dXJpdHkgaW5mb3JtYXRpb24gZXhjaGFuZ2UgdGVjaG5pcXVlcywgaXMgaW50ZW5kZWQgdG8g YmUgYWRhcHRhYmxlLCBleHRlbnNpYmxlLCBhbmQgbm9uLXByZXNjcmlwdGl2ZSB0byBhbGxv dyBhIHdpZGUgcmFuZ2Ugb2YgdGVjaG5pcXVlcyB0byBiZSBhcHBsaWVkIGluIGRpZmZlcmVu dCBpbnN0YW50aWF0aW9ucyB0byBlbmhhbmNlIGN5YmVyc2VjdXJpdHkgaW5mb3JtYXRpb24g ZXhjaGFuZ2Ugb2YgdGVsZWNvbW11bmljYXRpb24vSUNUIGluZnJhc3RydWN0dXJlLCBkZXZp Y2VzLCBhbmQgc2VydmljZXMuIEFzIG5lZWRzIGFuZCB0ZWNobmlxdWVzIGV2b2x2ZSCWIHRo b3NlIHRoYXQgYXJlIGFwcHJvcHJpYXRlIGFyZSBpbnRlbmRlZCB0byBiZSBwcm9ncmVzc2Vk IGFuZCBwdWJsaXNoZWQgYXMgSVRVLVQgUmVjb21tZW5kYXRpb25zIGluIHRoZSBYLjE1MDAg c2VyaWVzDVRoZSBjb21wdXRlciBzZWN1cml0eSBjb21tdW5pdHkgaGFzIG1hZGUgc2lnbmlm aWNhbnQgcHJvZ3Jlc3MgaW4gc2V2ZXJhbCBvdGhlciBhcmVhcywgaW5jbHVkaW5nIGNhdGVn b3JpemluZyBhbmQgcmFua2luZyB0aGUgc2V2ZXJpdHkgb2YgdnVsbmVyYWJpbGl0aWVzIGlu IGluZm9ybWF0aW9uIHN5c3RlbXMgd2l0aCB0aGUgd2lkZXNwcmVhZCBhZG9wdGlvbiBvZiB0 aGUgQ29tbW9uIFZ1bG5lcmFiaWxpdGllcyBhbmQgRXhwb3N1cmVzIChDVkUpIGRpY3Rpb25h cnkgYW5kIHRoZSBDb21tb24gVnVsbmVyYWJpbGl0eSBTY29yaW5nIFN5c3RlbSAoQ1ZTUyku IER1ZSB0byB0aGVpciBzdGFuZGluZyBpbiB0aGUgaW50ZXJuYXRpb25hbCBjb21tdW5pdHks IElUVS1UIFJlY29tbWVuZGF0aW9uIElUVS1UIFguMTUwMCBpbmNsdWRlcyBib3RoIENWRSBh bmQgQ1ZTUyB3aXRoaW4gdGhlIFguMTUwMCBzZXJpZXMgYXMgWC4xNTIwIGFuZCBYLjE1MjEg cmVzcGVjdGl2ZWx5LiANVG8gZGF0ZSwgYSBtYWpvciBnYXAgZXhpc3RzIGluIHZ1bG5lcmFi aWxpdHkgcmVwb3J0IGRvY3VtZW50YXRpb24gdW5pZm9ybWl0eTogdGhlcmUgaXMgbm8gdW5p Zm9ybSBmcmFtZXdvcmsgZm9yIHRoZSBjcmVhdGlvbiBvZiB2dWxuZXJhYmlsaXR5IHJlcG9y dCBkb2N1bWVudGF0aW9uLiBUaGlzIGxhY2sgb2YgdW5pZm9ybWl0eSBpcyBldmlkZW50IGlu IGV2ZXJ5IHZ1bG5lcmFiaWxpdHkgcmVwb3J0LCBiZXN0IHByYWN0aWNlIGRvY3VtZW50LCBv ciBzZWN1cml0eSBidWxsZXRpbiByZWxlYXNlZCBieSBhbnkgdmVuZG9yIG9yIGNvb3JkaW5h dG9yLiBUaGUgaXNzdWUgaXMgdGhhdCB0aGVyZSBpcyBubyBjb21tb24gZm9ybWF0IG9yIG5v bWVuY2xhdHVyZSBhbW9uZyB0aGUgcmVwb3J0aW5nIGZvcm1hdHMuIFRvIHNwZWVkIHVwIHRo ZSBkb2N1bWVudCBwcm9kdWN0aW9uIGFuZCBjb25zdW1wdGlvbiwgYSBjb21tb24sIG1hY2hp bmUtcmVhZGFibGUgZm9ybWF0IGZvciBzZWN1cml0eSBpbmZvcm1hdGlvbiBleGNoYW5nZSBp cyByZXF1aXJlZC4NVGhlIENvbW1vbiBWdWxuZXJhYmlsaXR5IFJlcG9ydGluZyBGcmFtZXdv cmsgKENWUkYpIGlzIGFuIFhNTC1iYXNlZCBsYW5ndWFnZSB0aGF0IGVuYWJsZXMgY29uc2lz dGVudCBuYW1pbmcgYW5kIGRhdGEgdHlwZXMsIHNvIHRoYXQgYW55IG9yZ2FuaXphdGlvbiBh ZG9wdGluZyBDVlJGIGNhbiBwcm9kdWNlIG9yIHJlYWQgQ1ZSRiBkb2N1bWVudHMuIFRoaXMg ZW5hYmxlcyBkaWZmZXJlbnQgc3Rha2Vob2xkZXJzIGFjcm9zcyBkaWZmZXJlbnQgb3JnYW5p emF0aW9ucyB0byBzaGFyZSBjcml0aWNhbCBzZWN1cml0eS1yZWxhdGVkIGluZm9ybWF0aW9u IGluIGEgc2luZ2xlIGZvcm1hdCwgc3BlZWRpbmcgdXAgaW5mb3JtYXRpb24gZXhjaGFuZ2Ug YW5kIGRpZ2VzdGlvbi4NT3JpZ2luYWxseSBkZXJpdmVkIGZyb20gdGhlIEludGVybmV0IEVu Z2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpIGRyYWZ0IEluY2lkZW50IE9iamVjdCBEZXNj cmlwdGlvbiBFeGNoYW5nZSBGb3JtYXQgKElPREVGKSBbM10sIFRoZSBJbmR1c3RyeSBDb25z b3J0aXVtIGZvciB0aGUgQWR2YW5jZW1lbnQgb2YgU2VjdXJpdHkgb24gdGhlIEludGVybmV0 IChJQ0FTSSksIGEgdmVuZG9yLW5ldXRyYWwsIGluZHVzdHJ5LXdpZGUgb3JnYW5pemF0aW9u IGhhcyBwcm9ncmVzc2VkIENWUkYgdG8gaXRzIGN1cnJlbnQgYmVzdC1vZi1icmVlZCwgY29t bW9uIFhNTC1iYXNlZCBmcmFtZXdvcmsgdG8gY3JlYXRlIGFuIG9wZW4gdGVjaG5pcXVlIHRo YXQgYnJpbmdzIGNvbnNvbGlkYXRpb24gYW5kIGNvbnNpc3RlbmN5IHRvIHRoZSBzZWN1cml0 eSBkb2N1bWVudGF0aW9uIHNwYWNlLg1DVlJGIGlzIGFwcGxpY2FibGUgaW4gdHdvIGNvbnRl eHR1YWwgcm9sZXM7IHRoYXQgb2YgdGhlIGRvY3VtZW50IHByb2R1Y2VyLCBhbmQgdGhhdCBv ZiB0aGUgZG9jdW1lbnQgY29uc3VtZXIuIEFzIHByb2R1Y2VycywgdmVuZG9ycywgY29vcmRp bmF0b3JzLCBhbmQgcmVzZWFyY2hlcnMgdXNlIENWUkYgdG8gaGFuZGxlIGFsbCB0aGUgZGV0 YWlscyBvZiBwcm9kdWN0aW9uLCBpbmNsdWRpbmcgcmVzcG9uc2liaWxpdHkgZm9yIHRoZSB2 ZXJhY2l0eSBvZiB0aGUgaW5mb3JtYXRpb24gYXMgd2VsbCBhcyB0aGUgYWN0dWFsIGRpc3Ry aWJ1dGlvbiAodXNpbmcgc3VjaCBtZXRob2RzIGFzIEhUVFAsIFNPQVAsIG9yIGF1dG9tYXRl ZCBmZWVkcykuIEFzIGNvbnN1bWVycywgc2VjdXJpdHkgcHJhY3RpdGlvbmVycyBhbmQgYWRt aW5pc3RyYXRvcnMgdXNlIENWUkYgdG8gZXhhbWluZSBhbmQgYWN0IG9uIGluZm9ybWF0aW9u IGluIENWUkYgZG9jdW1lbnRzLg1DVlJGIGRyYXdzIG9uIGFkZGl0aW9uYWwsIGV4aXN0aW5n IGVsZW1lbnQgZGVmaW5pdGlvbnMgYWxyZWFkeSBkZWZpbmVkIGJ5IG90aGVyIG1hcmt1cCBs YW5ndWFnZXMsIHN1Y2ggYXMgU2VjdXJpdHkgQ29udGVudCBBdXRvbWF0aW9uIFByb3RvY29s IChTQ0FQKSwgYW5kIGluY2x1ZGUgdGhlIENvbW1vbiBQcm9kdWN0IEVudW1lcmF0aW9uIChD UEUpLCB0aGUgQ29tbW9uIFdlYWtuZXNzIEVudW1lcmF0aW9uIChDV0UpLCBhbmQgdGhlIE9w ZW4gVnVsbmVyYWJpbGl0eSBhbmQgQXNzZXNzbWVudCBMYW5ndWFnZSAoT1ZBTCkuDVByb3Bv c2FsDVE0LzE3IGFwcHJvdmVzIJNDb21tb24gVnVsbmVyYWJpbGl0eSBSZXBvcnRpbmcgRnJh bWV3b3JrIChDVlJGKZQgYXMgYSB3b3JrIGl0ZW0gdG8gYmUgdW5kZXJ0YWtlbiBhbmQgcHJv Z3Jlc3NlZC4NVGhlIHByb3BvbmVudHMgb2YgdGhpcyB3b3JrIHByb3ZpZGUgYW4gZWxhYm9y YXRlZCB2ZXJzaW9uIG9mIHRoZSBSZWNvbW1lbmRhdGlvbi4NDV9fX19fX19fX19fDQMNDQQN DQMNDQQNDS0gEyBQQUdFICBcKiBNRVJHRUZPUk1BVCAUMhUgLQ1DT00gMTcgliBDIDUzOCCW IEUNDUlUVS1UXENPTS1UXENPTTE3XENcNTM4RS5ET0MNDUNvbnRhY3Q6B01pa2UgU2NoaWZm bWFuDUNpc2NvIFN5c3RlbXMsIEluYy4NVVNBB1RlbDogKzEgNDA4IDg1MyAyMDU2DQ1FbWFp bDogbXNjaGlmZm1AY2lzY28uY29tBwdDb250YWN0OgdHcmVnZyBTY2h1ZGVsDUNpc2NvIFN5 c3RlbXMsIEluYy4NVVNBB1RlbDogKzEgNTcxIDMzMiAyMjIyDQ1FbWFpbDogZ3NjaHVkZWxA Y2lzY28uY29tBwdBdHRlbnRpb246IFRoaXMgaXMgbm90IGEgcHVibGljYXRpb24gbWFkZSBh dmFpbGFibGUgdG8gdGhlIHB1YmxpYywgYnV0IGFuIGludGVybmFsIElUVS1UIERvY3VtZW50 IGludGVuZGVkIG9ubHkgZm9yIHVzZSBieSB0aGUgTWVtYmVyIFN0YXRlcyBvZiBJVFUsIGJ5 IElUVS1UIFNlY3RvciBNZW1iZXJzIGFuZCBBc3NvY2lhdGVzLCBhbmQgdGhlaXIgcmVzcGVj dGl2ZSBzdGFmZiBhbmQgY29sbGFib3JhdG9ycyBpbiB0aGVpciBJVFUgcmVsYXRlZCB3b3Jr LiBJdCBzaGFsbCBub3QgYmUgbWFkZSBhdmFpbGFibGUgdG8sIGFuZCB1c2VkIGJ5LCBhbnkg b3RoZXIgcGVyc29ucyBvciBlbnRpdGllcyB3aXRob3V0IHRoZSBwcmlvciB3cml0dGVuIGNv bnNlbnQgb2YgSVRVLVQuBwcNDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIAAABCAAAAggAACgIAAAzCAAANwgAADoIAAA7CAAAPQgAAGYIAABzCAAAfAgAAH0I AACICAAAiQgAAIsIAACMCAAAqggAAKsIAACsCAAAuQgAAMAIAADiCAAA4wgAAOsIAAAACQAA BgkAACYJAABXCQAAWAkAAGQJAABlCQAAxAkAAOni2dLI0r7istmsopmN4rKZjeKDfIN8g3yD fHLiaWFWAAAAAAAAAAAUFWgpRccAFmgJVc0AbUgMEHNIDBAADhZoCVXNAG5IEQR0SBEEABEW aAlVzQBuSBEEbygBdEgRBBIVaJVoFwAWaAlVzQA2CIFdCIEADBVolWgXABZoCVXNAAASFWiV aBcAFmgJVc0ANQiBXAiBABYVaN0aPQAWaAlVzQA1CIFDShwAXAiBABAWaAlVzQA1CIFDShwA XAiBABMVaN0aPQAWaAlVzQA6CIFDShQAChZoCVXNAENKFAAAFhVo3Ro9ABZoCVXNADUIgUNK GgBcCIEAExVo3Ro9ABZoCVXNADUIgUNKHAATFWgEd3sAFmgJVc0ANQiBQ0ocAA0WaAlVzQA1 CIFDShwAEBVo3Ro9ABZoCVXNAENKFAAADBVo3Ro9ABZoCVXNAAArA2oAAAAAFWjySb4AFmgJ Vc0ANQiBQ0okAFUIAW1IAARuSAAEc0gJBHUIAQAgAAgAAAIIAAAoCAAAOwgAADwIAAA9CAAA ZggAAH0IAACJCAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAAhwAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOoAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIAAGtkYhgAABYkARckAUlmAQAAAAKW OQADNAEI1kYAA8f/UAV5GYomYAaJBQAAAAAAAAAAAAAAAAAAAAAABikUAAAAAAAAAAAAAAAA AAAAAAAGEQ0AAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABrWDAAAAP8AAAD/AAAA/xvWDAAA AP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgAB CgM5AGH2AwAAZjQBDAAAAyQCFiQBSWYBAAAAYSQCZ2QJVc0ACQAAFiQBSWYBAAAAZ2QJVc0A AAiJCAAAiggAAIsIAACMCAAAmQgAAKsIAACaAAAAAAAAAAAAAAAAkQAAAAAAAAAAAAAAAJEA AAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwA AAMkAhYkAUlmAQAAAGEkAmdkCVXNAAkAABYkAUlmAQAAAGdkCVXNAABkAABrZN0YAAAWJAEX JAFJZgEAAAACljkAAzQBB5RjAQjWRgADx/9QBRgViiYgBokFAAAAAAAAAAAAAAAAAAAAAGAG yA8AAAAAAAAAAAAAAAAAAAAAAAZyEQAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGtYMAAAA /wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/ NNYGAAEFAwAANNYGAAEKAzkAYfYDAABmNAEABasIAACsCAAAuQgAAL4IAAC/CAAAmgAAAAAA AAAAAAAAAJEAAAAAAAAAAAAAAACRAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAyQCFiQBSWYBAAAAYSQCZ2QJVc0ACQAAFiQB SWYBAAAAZ2QJVc0AAGQAAGtkYRkAABYkARckAUlmAQAAAAKWOQADNAEHlAwDCNZGAAPH/1AF GBWKJiAGiQUAAAAAAAAAAAwBAAAAAAAAIAbIDwAAAAAAAAAADAEAAAAAAACABnIRAAAAAAAA AAAMAQAAAAAAABT2A8MmF/YDAAAa1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwA AAD/AAAA/wAAAP8d1gwAAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AQAE vwgAAMAIAADiCAAA4wgAAOsIAAD/CAAAmgAAAAAAAAAAAAAAAI4AAAAAAAAAAAAAAABPAAAA AAAAAAAAAAAARgAAAAAAAAAAAAAAAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZAlVzQAAPgAA a2RzGgAAFiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1hoAAcf/iiYABsMmAAAAAAAAAAAAAAAA AAAAABT2A8MmF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/NNYGAAEFAwAANNYG AAEKAzkAYfYDAABmNAEMAAADJAEWJAFJZgEAAABhJAFnZAlVzQAAZAAAa2T5GQAAFiQBFyQB SWYBAAAAApY5AAM0AQeUZQEI1kYAA8f/GAY4E4omAAZRBgAAAAAAAAAAAAAAAAAAAAAABiAN AAAAAAAAAAAAAAAAAAAAAAAGUhMAAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABrWDAAAAP8A AAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTW BgABBQMAADTWBgABCgM5AGH2AwAAZjQBAAX/CAAAAAkAAAcJAABXCQAAWAkAAGUJAACtAAAA AAAAAAAAAAAAogAAAAAAAAAAAAAAAKIAAAAAAAAAAAAAAABQAAAAAAAAAAAAAAAARQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAALAQADJAMKJgALRgoAYSQDZ2QJVc0AAFEAAGtkJRsAABYkARckAUlmAQAAAAKWOQADNAEH lGUBCNYwAALH/xgGiiYABlEGAAAAAAAAAAAMAQAAAAAAAAAGciAAAAAAAAAAAAwBAAAAAAAA FPYDwyYX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/ NNYGAAEFAwAANNYGAAEKAzkAYfYDAABmNAELAAAUpHgAFiQBSWYBAAAAZ2QJVc0AAFEAAGtk wRoAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/xgGiiYABlEGAAAAAAAAAAAAAAAA AAAAAAAGciAAAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAA AP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKAzkAYfYDAABmNAEABcQJ AABQCwAAxQwAAAkNAAA+DQAAPw0AAFcPAABYDwAAqg8AALIPAADRDwAA0g8AANYPAADbDwAA 8g8AAPYPAAD7DwAA/w8AAAUQAAAHEAAADhAAAA8QAAAeEAAAJBAAACoQAAArEAAA1BAAANUQ AAAFEgAABhIAACESAAAiEgAANBIAAD0SAACLEgAAohIAALcSAAC4EgAAuRIAAMUSAADWEgAA 5xIAAPsSAAAJFAAAHhQAAE0UAABuFAAAfxQAAIgUAACLFAAApxQAAKgUAAAFFQAABhUAADcV AAA4FQAAXhUAAF8VAAB+FQAAmxUAAKMVAAD57uP54+7b7tvQ29Db0NvQ29Db0NvQ2+7b7tvF 28XbxdvF27rbutu627rbr9uv26/br9uv26/br9uv26MAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FxVodH6uABZoCVXNAG5IEQRvKAF0SBEEFBVoLSI2ABZoCVXNAG5IEQR0SBEEABQVaBJg1wAW aAlVzQBuSBEEdEgRBAAUFWg1GOIAFmgJVc0AbkgRBHRIEQQAFBVoplKkABZoCVXNAG5IEQR0 SBEEAA4WaAlVzQBuSBEEdEgRBAAUFWgpRccAFmgJVc0AbUgMEHNIDBAAFBVoKUXHABZoCVXN AG5IEQR0SBEEAAwVaClFxwAWaAlVzQA8ZQkAAFELAAA/DQAAWA8AANUQAACNEgAAcBQAAJsV AACkFQAAFRYAAGYWAABnFgAAcxYAAHUWAAB2FgAAeBYAAHkWAAB7FgAAfBYAAH4WAAB/FgAA nhYAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAA AADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA zAAAAAAAAAAAAAAAAMwAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAL4A AAAAAAAAAAAAAAC+AAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC+AAAA AAAAAAAAAAAAvgAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC+AAAAAAAAAAAAAAAAuQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEMABnZAlVzQAAAQAAAAsAAAMkAQ+EaAFehGgBYSQBZ2QJVc0A CwAAAyQDCiYAC0YMAGEkA2dkCVXNAAsBAAMkAwomAAtGCgBhJANnZAlVzQAdAAADJAMNxgoE GgOnBDQGwQcAE6RkABSkZAA1JAE3JAE4JAE5RAQASCQBWyQBXCQBYSQDZ2QJVc0AABWjFQAA ZxYAAHIWAABzFgAAdBYAAHYWAAB3FgAAeRYAAHoWAAB8FgAAfRYAAH8WAACBFgAAghYAAJgW AACZFgAAmhYAAJsWAACpFgAArBYAALEWAACyFgAAxhYAAMkWAADPFgAA0BYAANkWAADoFgAA /xYAADAXAAAxFwAAOhcAAEgXAABfFwAAYBcAAJAXAACRFwAA9ena0s7SztLO0s7H0s7SvtLH zsfOsaexzpuOh36Hm2yHX36HAAAAAAAAGBVolWgXABZoCVXNAENKFgBtSBUEc0gVBAAjFWiV aBcAFmgJVc0AQ0oWAFwIgW1IFQRuSBEEc0gVBHRIEQQQFWiVaBcAFmgJVc0AQ0oWAAAMFWiV aBcAFmgJVc0AABgVaJVoFwAWaAlVzQBDShYAbkgRBHRIEQQAFhVolWgXABZoCVXNADUIgUNK FgBcCIEAEhZoCVXNAG1IAARuSAAEc0gMEAAYFWjdGj0AFmgJVc0AbUgABG5IAARzSAwQABEW aAlVzQBtSAAEbkgABHUIAQwVaN0aPQAWaAlVzQAABhZoCVXNAAAPA2oAAAAAFmgJVc0AVQgB HBVoi1ElABZoCVXNAG1ICQRuSBEEc0gJBHRIEQQAFhZoCVXNAG1ICQRuSBEEc0gJBHRIEQQA FBVodH6uABZoCVXNAG5IEQR0SBEEJJ4WAACxFgAAshYAAM8WAADQFgAA2RYAAOgWAAD8FgAA ABcAABUXAAAWFwAAMBcAADEXAAA6FwAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADxAAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA3QAAAAAA AAAAAAAAAN0AAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAAB0AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAa2SXGwAAFiQBFyQB SWYBAAAAAFQBAAKWOQADNAEHlMwACNZGAAPH/xgGQheKJgAGUQYMAQAAAAAAAAAAAAAAAAAA AAYqEQwBAAAAAAAAAAAAAAAAAAAABkgPDAEAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAa1gwA AAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA/wAAAP8d1gwAAAD/AAAA/wAA AP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AYpUAQALAAATpAAAFiQBSWYBAAAAZ2QJVc0A CQAAFiQBSWYBAAAAZ2QJVc0AAAQpAGdkCVXNAAABAAAABjAAFKTwAGdkCVXNAAANOhcAAEgX AABcFwAAYBcAAHUXAAB2FwAAkBcAAJEXAAAQGQAA9gAAAAAAAAAAAAAAAOsAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA ggAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAa2QjHAAAFiQBFyQB SWYBAAAAAFQBAAKWOQADNAEHlMwACNZGAAPH/xgGQheKJgAGUQYMAQAAAAAAAAAAAAAAAAAA AAYqEQwBAAAAAAAAAAAAAAAAAAAABkgPDAEAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAa1gwA AAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA/wAAAP8d1gwAAAD/AAAA/wAA AP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0AYpUAQALAAATpAAAFiQBSWYBAAAAZ2QJVc0A CQAAFiQBSWYBAAAAZ2QJVc0AAAiRFwAAmxcAANgXAADyFwAADxkAABAZAAARGQAAEhkAABQZ AAAVGQAA9Ov06+Lb4tfIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBVoi1ElABZoCVXN AG1ICQRuSBEEc0gJBHRIEQQABhZoCVXNAAAMFWjdGj0AFmgJVc0AABAVaN0aPQAWaAlVzQBD ShIAABAVaJVoFwAWaAlVzQBDShIAABYVaJVoFwAWaAlVzQA1CIFDShIAXAiBCRAZAAARGQAA EhkAABMZAAAUGQAAFRkAALoAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAA ALEAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL AAADJAEPhGgBXoRoAWEkAWdkCVXNAAABAAAABgAAE6QAAGdkCVXNAEUAAGtkrxwAABYkARck AUlmAQAAAABUAQAClmwAAzQBCNYaAAHH/4omAAbDJgQBAAAEAQAABAEAAAQBAAAU9gPDJhf2 AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zLWBgABCgM5ADTWBgABBQMAADTWBgAB CgNsAGH2AwAAZjQBilQBAAAFKQAKMAExkEYBOnAJVc0AH7CDLiCwyEEhsG4EIrBuBCOQiQUk kIkFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiGAAARABkAAAA AAAAAAgAAAAAAAAAAAAAAAAAXAhgCTUCJQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA8ABPCOAAAAsgQK8AgAAAABBAAAAAoAAJMAC/BqAAAAvwAEAAQABEEBAAAABcEQAAAA PwEAAAYAvwEAABAA/wEAAAgAgMMUAAAAgcMQAAAAvwMAAAIAaQB0AHUALQBvAGwAZAAAAFAA aQBjAHQAdQByAGUAIAAxAAAAaQB0AHUALQBvAGwAZAAAAAAAEPAEAAAAAAAAgGIAB/CAFwAA BgYyBN8qLidsBJkXGiPkVhhM/wBcFwAAAQAAAEQAAAAAAAAAAG4e8FQXAAAyBN8qLidsBJkX GiPkVhhM/4lQTkcNChoKAAAADUlIRFIAAABrAAAAeAgDAAAAwiP8CwAAAwBQTFRFosTZh5XE 7PHyirbSxNbfvNPd3Obp1eHlmISnZI68rMrakbrVGzeP+vr6pbLP6meF8sXQKESWlqPJ5FR2 daXIsc3bd4m78fP4OFOeaXy09PX2xtngrWiOw8vih6PGzd3iapfB77HA0N7kncHZSmCnuNLj 6O3vWW6t5Ovs4Ojq7ZGnhLPP5O703ufq6+/ws73Y4ursVX605CZS8p+y2OPm09jpyypXyNrh 8/T1wNbfusza3Q0959fettDc7/Lz5uvtpLfQlr3X9vf45z9mpAxL4xBA++DmXXWvmq/LLkya XIW3Q1qhOV2is8bXytTf6n6XTnWv1uTqvkZwYxxo4uXxmb/YRGKm3+vyfpO+z5mvyKy9rMPW vMfaR26rxoCdy9zj4+btP2WnUWqpz+Dq2BhHkq/Nzt7mvTdlu8XV7+Pn2d/qssDVydzlyt7r qb3Snq3Mx9zpz9rj8fPzp8fa/fDz0dfnpbDT/e/yp8nd4+zvYFeY4QAzf7HODiuJ////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAzblzxAAAAIB0Uk5T//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wA4BUtnAAAAAWJLR0R/SL9x 5QAAAAxjbVBQSkNtcDA3MTIAAAADSABzvAAAE01JREFUaEO9mu1D2tgSxgMIVCBqEMOJyItA iYggKi5SCyK9NYZEKl213K2sK760V11tcdfKGsK/fuckARLEtveDd7BCA/LLMzNnzpyTEB3V tia0F8/4RGjfTa5sPSNF/eouq/P6HfncsB6r825WfmZYn7X15tv/jSW/m3xmL/Z1dSberjyv MB1LHn/7vLmoY3W+PTyvF/WszruHlefMRQNra/lZvWhgyfMPb/56vvwwsDpbpw/zz+dFIwsi 9vB8RXiA9W35O14kSW/K/MceWCrllUv/s7MHWPLKw8P4MC9ubPhvTAzLcizLNvBvmr7zX/xv uAFWB4Q9DBRhkrxYrEUFlja5i4ef/ZWvlcPPl2Numm4I0Zr/b/KnK9sgqzP78LCsLx+pCzfL s6bL1Y2Yudk0m82xWCyFf1rxTIVuCwJjupj+OX2PWN/ePOjKx94iy7voynSpAN8PtjEHlk7H wZI2WzzOsYeBRpQ7LPwM7RFLBmFa4pf2TFGqza42mypIpQFOgSXTrZjZJpgK9lfgYdPGj135 iNUhQdhbnPirpijDIHeptLbWXGs2m/DUbBYKqRSmtWIx/1jAFKi5XrVsSft2Q3Dv/UjbY1Zn Yh1C9i3lRkzlUhi7qNyYajQHBqlXc4/5v2bM082mPRBFcCoMS1EN+jK8kCk2kHv6+3VgCEse By9O1tlK7LOLYoUoy9SAUSwqTMi9BlsrFgV2LAPykvEwINGByZcMbgsN/3cdOYTV2XoLsJmP tOBquC8rf5AyPEokGLxoxiuf3bTQbtOX9rlUy2ZLbwv2EZOATMGqj0a17zlyGKuJhT38Y6KF ObI0DSECg1A1C/hlc7pUKgimQzoqcDfZ1Jwt06i1bMFtdHBdDX8UhMrT0oawyJrrX8Ba3qq7 S6mUWeGsKYZTo2BOTV8LG6lm7NDUQFzRZi6iSiYMoqja0clRjV98sng9ZsW4NvUeC/sUrTZV FGCmwbRENJM03YTUNzfjn2kkBL6yNVs4XG1di0wueDKGTN4nEvIR60JoMyNzkPcPD+9Js4Ka VkgKDSszy5y7iUd1Oj0Xs99EBQGFW8HL7QDXRmyjgdqN2PB8HGRVeOoa6s8s5P3D+koJUFhT STUNRtK1ZiymDOl0rDR3g9rRhqDkK08FzgLbrDC8jAywKlRjNTUXb5mV9FifKJl1qC6MdLPT SrmKmdM7Aa5xgNouzmoPnp9YBRqerJww1I1G1t88HW/F4+l0+jXO+4fl16SqCmc8SSqwtcLa KgqbUwXz3CUtINZ0/TUs0A0UOAlnz3eowFXOelUeqszAuuBrsXgSWHNz5nnMeniTKvVRGqxZ KLG0nDqkDwRmLJxMpW1zNFd1841Le/YkgKw5ay7HCrHHCaJnxQQmHbcprFZKTY+HcRwnVVVX WLNAVpCJRUwxbYbKYctkMn60kxxhqJovOCLUzq3WfJ5jH080OhbZQBmbTWXNbXgnFC8+vCtp NUNWWKXpNZK011xt90WzOQf13gYsu42lbfbqNhI+VgNCLgcsh2B6NKj7LJl2HcYBloRwzc21 FtT0gPlFUSSDqTD5gkbcIsuspTAKWACzjSFfOFjNMVTglXANrKl8hFoczPw+67BNp+GvNFYs NV3E1QNsRcciFZKfJDOISaV6rMxXYawazB6dBHhO2PYBayof4FcHQtZjXVBUBZ9h14epwlcX HmSQ+bNYkSJLLpgQVymRUKcqAptMKbrAh/YWw9mD2WzWvnPQPrvCLMdLBg1kfpdFMi4mbe+z YjHzRuO9GrLTCczBuEXU8Msl6DpSqUKSQ4fmOegEMCtZFLLA8vmCOy6q6Mvnpxz3DrFmFNZl FQU0ZuuyPpgXoIkhA0uTqhffKjD5Dw4VSXKtCeU3lYoVUjWetpvjCsseFophhbUtMNSZT2Gd uf42wDRWAZkOKnaN1Xq9MjHx+j//+fzPb9DBqcpA1B2iN2RoCHCpxw3IRvOwgUyZmA2zbBxT BR8Gc4g+qfG13JTj9vZ+NGqo+SpLrnHbDfgL7ENbMp1ZXj9dBls/VZ2IlS1w6LNMTsP0r7E2 5mB4jUVR7VUmHa/a3AfVc/vJtdDI+bIBV80KLIJAd3phKmuPtwaYMGYBLB5fUIuG3k7/oVOy VnwVF0LtheKbSo6xqFG72am84q9fbXMUk/PlrL4AFcoD6j5kKB8KS2aYFs2ALkUYjGWb5js9 bQX7T5stsQsBhZvEudgrNydEEXLx0JcWj0ZyVrAAFZgiwA7cOmEKa4/faTE0druWiAvQ1j+y d6WSMi9r0VK6RJyGybTtq/XzK4a15s6DI1A1oGxYa66Ag4gQHqRrQDBLhtJpY+gqOFGDfbCp 1dBo4wWYzzAKZEG01JEMbrdn7GE7BCx75PNprHx+lLfcRiL7x3f96oFZe+jyqFrj4A/6wpTJ ctAmX8NMraF6spSMDwftH9FOjwVDeWoX7RORSEjol0VgyXdsMFs1ceGwAlPKb3JBq4ZG3PIE dDtKvivRUlyosU5eoesjVRaUDYfDQaA6Edl3osVexIBljp6Fs3Z3Q2NhWDzeej0kPaBezZu9 C9r8b0AFj+yNQBCzcJUH1u29kxolNvfLjJ61ikZgEO4gqwJT0h7mlSF5r2icfG1Wlg8GVeFg 8KjKMMERNVzgQhhd9zVKijgl1CvBoKtG232+bFDYBrcrEVOLfUsrUINBW15ZWFAXKn0PhoNH WXuNVXRhWcCChL/fRZtOJ99zItEho9sQ0+wJFBmdF5PxDxOnQ9JDlaap6gYLo7LhwAEMLk0W ZkUiTn4JWFy33BMdv5CzQafi/XpYaja9sPrxxjMxL575J1aG2/wEWUolk2atP/UWml6z+SR7 jZTRlbcttFqtD4qNjFUJ0ZXSIkZ0ipxvAc+6fduwN40Hhvxv2mYrGQ5Xfa/QDtQna95rOO44 bnerPSFzgVxMduO1vfrwy2l7QX+g+0b/mXXLa5hVw/sC+MFW5OqIDxGYNVUie8cbF/J93dWd xoi9aHFkQWbbPbuR0+GC/kD/rd6rBrAy0zLqHVjELOEsi1uNEsn3jvvlgChyXR+uNqasCzIz yNIdGMpqZoAFyzDN7uRMbiTqzuKEL5H944dyw1VGWukg/AdWa0wv4+4ndLFyM2M36rKP+A7c 0NXkHSWyr9cvcy5J9KvCCBPjs7aMuuLBgswNUdM/JKgsvS471qWx9Lpol1S/0Vh0yJdvGXXF j8zyDcsyHDwYpu/8NmKUIxxzIxfsg7pyuWgANzX3Rl2NdrlMa6xGIAcsQ7wwC5bG+Af+mfpy TEpHqhxXWAZdVmDloGTc6uPll+m6WDZprOiZdWpAly04579LwToPmqmSTOtZa4UL902MNBfS 4bAxXicay3HrNcSL8PBLrJocBCrmgWXQZTs6QrQtiItjOCbX9Ky4/esNrPntNqidawZdJ1Yr 6MKV0JiHhCQeN5QqdUEgYuqRLrtJCMOX4VIcM+qK2+3psBtoIzb7mmF8neSBZYW2kDDGi5CW +KjSCCxiliNu1JUcQW57ELPC4ZRR1wfcAFXt7gPEfDTG6zxvPQhYYd4ivIbxRUghV0PZaFwF lgNYurpxJ5trgi8IBqjggK7Z6gk+A1sYWjW/Qdd5Po+28bwVMeqKSJJLUDc1CRRx3CaNurIo YM8eKTRgGeL1ZvxPgAWD59Xwq6QhXudTU3xx6hZY00ZdHgvFayzqzHE7oIsRRmA+yh4dHQWP NozxevMwWTkJwjvwAa8xXrkickBqPI5XQkQay1WbIgZ0RVEu6AMY4LKtAV2whP58gs8k6/Ma dF0HaP7sLOCpsXu644cy4UnUu6x2GbMM8YJFtxWmagWXHtQFmwO//YlXJL6CQRctUpQA2ypi fc84viRgqQ0pQR3fRgZ0XeYEAZRhmO+xLlhI/PvPK4WlrxtXU9xuxFncJ6BG6esh6FqKql0A Ibicg7qqvhFQhmE+3xBd0HGM+658I8Z4fclHRyFYRMQ5UDekRK9uMO0QUTXmod3qgw2Ka+iu MMuYh1q7M/n5C8zmUd38lSVQ4Baaz31gGXRJUt2k9tkE7apHqsZ4QWnzXXH8WHjEN2LURcI1 ENWWf/uin2FpeeFMbeCd9/KFq3cOF6RTSux26/wd4qUBXVDarCNXNBWAnjlu1JX5vQtb//2D bgpw7cmXx5uR/U3nvVcO9FBUrGSB3OjOXxficf2DUReUG7ArN0WP+JLGPLT7fu8tKsZlf78s cyXZfAINdlKWD/tHWfmDJElCd15ejYaol8Z4nU8pMN81OthZMOo6yX35rQs73dIld1s4VFu1 PVPfg223/FKSPLy2XUR4Gx7BbdR1NJWH1Vre6stz/KJR1zlsbHUX7A/vZLe+UxBo942JpXSH EElaJEu50e2j5NquZ2ygHkKtwbh8LlcLGHXBvpb1y7W2hFne+kFrtyh/kaSEqKUG3A+weOD8 06gre+vANEVdxqjrCJ+CdUdbVozLe3oZg+2QSTZDZnj6fS+sKj0DeegDlkqbmrIZdV1h1lTe MaOm44q813iq4XK5ZRImlMQx1V0yw5qILVdl3V/cyDkCpgaMA6sadWUxH84jr6bjOmwO3Oga LR2XWZVLBKBG20x3QwVYd+gE9vNclGZ3wCIw7V5lmXrvwJn6tFNw3P9bXTGNf5NLhwyvyz3g ueBCjizbNiHfJb69qKUGvn9jgX9pXIjkIioMxN1WB96CbSbHPZwHcX/ziwI7nd+Cj1zcwQXG KFiDo91+aPnkDw5MAg/2dx2AVeIC3gXz+aoX73hd7JnNLyMYhu2W+ALrMVhfwU/Sv9okc8op 4EUjcX+tXDGAsj85PzGwarK9hEgpKFSne5sOeM+hgqSEc5TybDo3nWKI2N+PgGk0VR+WSIzy Yi0yBaVcMfjEx5nusF5/+2Z8/k+8uqt+yTn2EwpISkjHvAdpRQPXXvjnFcqJhKXOS05nQgxF Njc391VeD6hodERonl86u72Hcq6ZpkzV98sLqBHw6JolxCOpfNDfalP2iK75hJRIiHwCs/ad Th3NwLuPeA6og5CFuCfgXLZffOoWYvV5/ZOpB5Is0q6rLiX4MeO+TaeERgEmiaIlgTALwzb3 QV1EldcziNJZGfHHocS+e2bI0n39fUD1XkJaoviQJVHWbduo9xHJd7ziXl6UxJDTYgGaysPO HLDIfUTi0K+/9Mq9UdvpTACiFapT/Ch8YQLqaTfju/cskRAxgHkQQpgFNB2vz1TYTvfMsI2x HvJ0hhOp4xDWZimL+k16bV90kYKzwG5sh5yQJ6op8gy26X7x/ilFfX3rv9Ysairyh31VvXux ZLZuUd1IgZd7tEHc5kx3U9bouYH/nb7AXwYTMjdkvxcWLFQInwqMc2oUTgrjuvIUjyoPQL94 ajNHJ+s9DhkuhbzxSml3z1wO4PSAyaZcpnaxPzFOJ1Bzq8V5ZhhTj+Wtv38BkVJ95DZe5ehd dyg1sBct9bozRIkKDH9cBapM5RmO9KrFED+uvzdpRQNc1Bi4etO/nrJHlWHC3j2GdBT5UcXh fVM5mpnUqvvYTmde9D5kKfPdfShdnddeyn4IGWQplrOEh7yRpgdLw6T98h5qVM8sIcqQg0ov 2k9K2c17oIZ5AGLx8CDtaZo0UJ7WP828MJxcwsMHHl2M1V/XK9EgilfzUdql6p4BRxqlGRLy xeCJUf2ppKfGcL3SyxxbxCUtL0IitfQ9RwYMCTljiK6EmCGX6g0s2GYWl0RNTSIxSqEy1Oun zPKPviZ+Uquumr5ir8cYUje6h7wsT/VmIFysYQZ4ImyWJWpUX+tPuzkIA4v+ievLHbnAtJec /Wzy7FJiGZfRQUskllyhRMKky8h11Y8JDzVUlSEPVW0lGipi3x0WzxJMxp7B0CcSuxTMeWCm 931P/gIDGTK59sSdDsZ4KbA7F7QEfR3gSQRzhG4sK50E1c3ShKmfJKcz0i7vfuoOjsesDlyp Pjaku0UKHVP8bkiCMqWcAx5+eBh2c0Gn7V//PBrCw3O+e/SCGUiJhMVTPubR7ijgIHqjA2Ul IQW0y6jQL7578kbQIbqwH8dAmjEjLIATeUrc9XjqVNmJJWrlXCnMUu2Tdjn6YXniCdpwFsxn NL87MLYSkDKhJbHtaqOl0VEPHhpQ/KFP84TKdVGkXL++0WbSyYmhd0w+xeqQfhZPZMZsT1hC x3y5vCtCY8KDiaIIvxEv1ndFnrsiZ8dV2vJQRz7J6sheuKS75MFqujmQ8BzjKonVeEBNaHRp qRwKgcLQrsguluQOSU68W1bGALT5+pKhvH6ahRviQ04QoffC6uAXZGM/ito8ikM1KoqMv1cp tmYnlbK8PDtI+y4LaH/DJujuKMTGA6OsDqNMN/AgJyTPaJ2Pmvb0o5f8tqWIe/tmljTMKz9g gTiyYooeiHwbogfdja4nkELlY/EgaroYcgsKiMNN5OSs/n7yH7MAZ14t0qzIi8e75fJoCOJU Xto9hoxg3TcXT91UtrU1r9wXN2u4NvoohsMOwM0ph3DHKM00otEDlmZMd4cX3pL8vXvlSHJr HkZBfwD8lK6fOpuhH9qCvHw7PqF68plZnc5ff82OL4/P/gVZ8uwsLAgyZR6y5P/CAnVbs7N/ /Re8cRV0pEeJrQAAAABJRU5ErkJggnkAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA4kF NdYFAQIDKRQ11gUCAwMRDSN2AAGJBSN2AQIpFCN2AgMRDTpWCwACljkAAzQBFPYDwyYr1gIA AzXWBQABA4kFNdYFAQIDKRQ11gUCAwMRDTTWBgABCgM5AGY0AYIAFiQBFyQBSWYBAAAAAZYA ACF2AANoATXWBQABA4kFNdYFAQIDyA811gUCAwNyESN2AAGJBSN2AQLIDyN2AgNyETpWCwAC ljkAAzQBB5RjART2A8MmK9YCAAEr1gIBAzXWBQABA4kFNdYFAQIDyA811gUCAwNyETTWBgAB CgM5AGY0AZYAFiQBFyQBSWYBAAAAAZYAACF2AANoATXWBQABA4kFNdYFAQIDyA811gUCAwNy ESN2AAGJBSN2AQLIDyN2AgNyETpWCwACljkAAzQBB5QMAxT2A8MmK9YCAAEr1gIBASzWAwID ATXWBQABA4kFNdYFAQIDyA811gUCAwNyES/WCwADBAAAAP8MAQAANNYGAAEKAzkAZjQBeAAW JAEXJAFJZgEAAAABlgAAIXYAA2gBNdYFAAEDUQY11gUBAgMgDTXWBQIDA1ITI3YAAVEGI3YB AiANI3YCA1ITOlYLAAKWOQADNAEHlGUBFPYDwyY11gUAAQNRBjXWBQECAyANNdYFAgMDUhM0 1gYAAQoDOQBmNAFMABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQPDJiN2AAHDJjpWCwAC ljkAAzQBB5RlART2A8MmNdYFAAEDwyY01gYAAQoDOQBmNAFiABYkARckAUlmAQAAAAGWAAAh dgACaAE11gUAAQNRBjXWBQECA3IgI3YAAVEGI3YBAnIgOlYLAAKWOQADNAEHlGUBFPYDwyY1 1gUAAQNRBjXWBQECA3IgNNYGAAEKAzkAZjQBcAAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYF AAEDUQY11gUBAgNyICN2AAFRBiN2AQJyIDpWCwACljkAAzQBB5RlART2A8MmNdYFAAEDUQY1 1gUBAgNyIC/WCwACBAAAAP8MAQAANNYGAAEKAzkAZjQBigAWJAEXJAFJZgEAAAABlgAAIXYA A2gBNdYFAAEDUQY11gUBAgMqETXWBQIDA0gPI3YAAVEGI3YBAioRI3YCA0gPOlYLAAKWOQAD NAEHlMwAFPYDwyY11gUAAQNRBjXWBQECAyoRNdYFAgMDSA8v1gsAAwEAAAD/DAEAADTWBgAB CgM5AGY0AYpUAQCKABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQNRBjXWBQECAyoRNdYF AgMDSA8jdgABUQYjdgECKhEjdgIDSA86VgsAApY5AAM0AQeUzAAU9gPDJjXWBQABA1EGNdYF AQIDKhE11gUCAwNIDy/WCwADAQAAAP8MAQAANNYGAAEKAzkAZjQBilQBAFoAFiQBFyQBSWYB AAAAAZYzACF2AAFoATXWBQABA8MmI3YAAcMmOlYLAAKWbAADNAEU9gPDJjXWBQABA8MmL9YL AAEPAAAA/wQBAAAy1gYAAQoDOQBmNAGKVAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACGBG4AEgABABQBDwACAAAAAwAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAA UEoDAF9IAQRtSAkEbkgJBHNICQR0SAkEAAAAAGYAAGDx/wIAZgAMEAAA0kAfAAAABgBOAG8A cgBtAGEAbAAAACcAAAANxg4ABBoDpwQ0BsEHAAAAABOkeAA1JAA3JAA4JAA5RAIASCQAABgA Q0oYAF9IAQRhShgAbUgJCHNICQh0SAkESAABQAEAAgBIAAwQbQDSQB8AAAAJAEgAZQBhAGQA aQBuAGcAIAAxAAAAFwABAAUkAQYkAROkaAFAJgBehBoDYITm/AADADUIAQA2AAIAEQACADYA DBAAANJAHwAAAAkASABlAGEAZABpAG4AZwAgADIAAAAJAAIAE6TwAEAmAQAAADYAAwARAAIA NgAMEAAA0kAfAAAACQBIAGUAYQBkAGkAbgBnACAAMwAAAAkAAwATpKAAQCYCAAAARgAEADEA AgBGAAwQAADSQB8AAAAJAEgAZQBhAGQAaQBuAGcAIAA0AAAAGQAEABXGCQEaAxkAAf0DAEAm A16E/QNghAP8AAAAMgAFAEEAAgAyAAwQAADSQB8AAAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAA BQAFAEAmBAAAAEYABgBBAAIARgAMEAAA0kAfAAAACQBIAGUAYQBkAGkAbgBnACAANgAAABoA BgAVxgoC/QOnBBkAGQAAQCYFXoQ0BmCEzPkAADIABwBhAAIAMgAMEAAA0kAfAAAACQBIAGUA YQBkAGkAbgBnACAANwAAAAUABwBAJgYAAAAyAAgAYQACADIADBAAANJAHwAAAAkASABlAGEA ZABpAG4AZwAgADgAAAAFAAgAQCYHAAAAMgAJAGEAAgAyAAwQAADSQB8AAAAJAEgAZQBhAGQA aQBuAGcAIAA5AAAABQAJAEAmCAAAAEQAQSDy/6EARAAMDQAAAAAAAAAAFgBEAGUAZgBhAHUA bAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABSAGlA8/+zAFIADL0AAAAA AAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEF AwAAYfYDAAACAAsAAAAoAGsg9P/BACgAAA0AAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIA DAAAAAAAUgD+DwEAAgBSAAwAAADSQB8AAAAQAEEAbgBuAGUAeABfAE4AbwAgACYAIAB0AGkA dABsAGUAAAAPAA8ABSQBBiQBE6TgAWEkAQAHADUIAUNKHAAAMgD+D6IAAQEyAAwAAADSQB8A AAAHAEEAcABwAF8AZABlAGYAAAALADUIgU9KAABRSgAAACYA/g+iABEBJgAMAAAA0kAfAAAA BwBBAHAAcABfAHIAZQBmAAAAAABCAP4P8QACAEIADAAAANJAHwAAABMAQQBwAHAAZQBuAGQA aQB4AF8ATgBvACAAJgAgAHQAaQB0AGwAZQAAAAIAEgAAADIA/g+iADEBMgAMAAAA0kAfAAAA BwBBAHIAdABfAGQAZQBmAAAACwA1CIFPSgAAUUoAAABCAP4PAQACAEIADAAAANJAHwAAAAsA QQByAHQAXwBoAGUAYQBkAGkAbgBnAAAACQAUABOk4AFhJAEABwA1CAFDShwAAD4A/g8BAAIA PgAMAAAA0kAfAAAABgBBAHIAdABfAE4AbwAAAA8AFQAFJAEGJAETpOABYSQBAAcAOwgBQ0oc AAAmAP4PogBhASYADAAAANJAHwAAAAcAQQByAHQAXwByAGUAZgAAAAAARAD+DwEAAgBEAAwA AADSQB8AAAAJAEEAcgB0AF8AdABpAHQAbABlAAAADwAXAAUkAQYkAROk8ABhJAEABwA1CAFD ShwAAHgA/g8BAIIBeAAEAAAA0kAfAAAABQBBAFMATgAuADEAAAA5ABgAE6QAABXGMAQaA6cE NAbBBxkAGQAZABkACjcCbgSlBtwIEwtKDYEPuBHvEyYWAAAAAAAAAAAAAAAaADUIAUNKFABP SgQAUUoEAG1IAARuSAAEdQgBNgD+DwEAAgA2AAwAAADSQB8AAAAEAEMAYQBsAGwAAAAQABkA BSQBBiQBE6SgAF6EGgMDADYIAQBCAP4PAQACAEIADAAAANJAHwAAAAcAQwBoAGEAcABfAE4A bwAAAA8AGgAFJAEGJAETpOABYSQBAAoANQgBOwgBQ0ocAEYA/g8BAAIARgAMAAAA0kAfAAAA CgBDAGgAYQBwAF8AdABpAHQAbABlAAAADwAbAAUkAQYkAROk8ABhJAEABwA1CAFDShwAAD4A KgCiAMEBPgAMAQAA0kAfAAAAEQBFAG4AZABuAG8AdABlACAAUgBlAGYAZQByAGUAbgBjAGUA AAADAEgqAQA4AP4PAQDSATgADAAAANJAHwAAAAgAZQBuAHUAbQBsAGUAdgAxAAAADgAdABOk UABehBoDYITm/AAANAD+D9EB4gE0AAwAAADSQB8AAAAIAGUAbgB1AG0AbABlAHYAMgAAAAoA HgBehKcEYIRz/gAAMAD+D+EB8gEwAAwAAADSQB8AAAAIAGUAbgB1AG0AbABlAHYAMwAAAAYA HwBehDQGAABEAP4PAQACAkQADAAAANJAHwAAAAgARQBxAHUAYQB0AGkAbwBuAAAAGQAgABXG FAOnBDQGwQcZABkAGQAC1BKnJQECAAAAWgD+DwEAEgJaAAwAAADSQB8AAAAPAEUAcQB1AGEA dABpAG8AbgBfAGwAZQBnAGUAbgBkAAAAIgAhABOkUAAVxhEDGgOnBDQGGQAZABkAARYHAl6E wQdghD/4AAA6AP4PAQACADoADAAAANJAHwAAAAYARgBpAGcAdQByAGUAAAATACIABSQBBiQB E6TwABSkeABhJAEAAABeAP4PAQAyAl4ADAAAANJAHwAAAA0ARgBpAGcAdQByAGUAXwBsAGUA ZwBlAG4AZAAAACUAIwAFJAEGJAETpBQAFKQUABXGEgQaA6cENAbBBxkAGQAZABkAAAAEAENK EgBQAP4PAQACAFAADAAAANJAHwAAABEARgBpAGcAdQByAGUAXwBOAG8AIAAmACAAdABpAHQA bABlAAAAEAAkAAUkAROk8AAUpHgAYSQBAwA1CAEASgD+DwEAAgBKAAwAAADSQB8AAAAMAEYA aQBnAHUAcgBlAF8ATgBvAF8AQgBSAAAAEwAlAAUkAQYkAROk4AEUpHgAYSQBAAMAOwgBAE4A /g8BAAIATgAMAAAA0kAfAAAADgBUAGEAYgBsAGUAXwB0AGkAdABsAGUAXwBCAFIAAAATACYA BSQBBiQBE6QAABSkeABhJAEAAwA1CAEAQgD+D2ECAgBCAAwAAADSQB8AAAAPAEYAaQBnAHUA cgBlAF8AdABpAHQAbABlAF8AQgBSAAAACQAnAAYkABSk4AEAAABSAP4PAQACAFIADAAAANJA HwAAABQARgBpAGcAdQByAGUAXwB3AGkAdABoAG8AdQB0AF8AdABpAHQAbABlAAAAEAAoAAUk AROk8AAUpHgAYSQBAABaACBAAQCSAloABAAAANJAHwAAAAYARgBvAG8AdABlAHIAAAAhACkA E6QAABXGGAQaA6cENAbBBxkAGQAZABkAAkIXpyUAAgASADsIAUNKEABtSAAEbkgABHUIAVoA /g+RAqICWgAMAAAA0kAfAAAACwBGAGkAcgBzAHQARgBvAG8AdABlAHIAAAAjACoAE6QoABXG CgJCF6clGQAZAAA1JAE3JAE4JAE5RAQASCQBAAYAOwgAdQgAWAD+DwEAsgJYAAwAAADSQB8A AAAJAEYAbwBvAHQAZQByAF8AUQBQAAAAJAArABOkAAAVxhsEGgOnBDQGwQcZABkAGQAZAAOL A1UipyUAAgIHADUIAUNKFgAARAAmAKIAwQJEAAwBAADSQB8AAAASAEYAbwBvAHQAbgBvAHQA ZQAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShIARUgGACgA/g8BANICKAAMAAAA0kAfAAAA BABOAG8AdABlAAAABgAtABOkUAAAAEoAHQDRAuICSgAMAQAA0kAfAAAADQBGAG8AbwB0AG4A bwB0AGUAIABUAGUAeAB0AAAAFQAuAAUkARXGBQAB/wAAXoT/AGCEAf8AAAAsAP4PgQHyAiwA BAAAANJAHwAAAAYARgBvAHIAbQBhAGwAAAACAC8AAwA1CAAASAAfQAEAAgNIAAwAAADSQB8A AAAGAEgAZQBhAGQAZQByAAAAHgAwABOkAAAVxhIEGgOnBDQGwQcZABkAGQAZAABhJAEEAENK EgA6AP4PAQACADoADAAAANJAHwAAAAkASABlAGEAZABpAG4AZwBfAGIAAAAJADEABiQBE6Sg AAADADUIAQA6AP4PAQACADoADAAAANJAHwAAAAkASABlAGEAZABpAG4AZwBfAGkAAAAJADIA BiQBE6SgAAADADYIAQAqAAoAAQACACoADAEAANJAHwAAAAcASQBuAGQAZQB4ACAAMQAAAAIA MwAAAC4ACwABAAIALgAMAQAA0kAfAAAABwBJAG4AZABlAHgAIAAyAAAABgA0AF6EGwEAAC4A DAABAAIALgAMAQAA0kAfAAAABwBJAG4AZABlAHgAIAAzAAAABgA1AF6ENgIAAEQA/g8BAAIA RAAMAAAA0kAfAAAAEgBOAG8AcgBtAGEAbABfAGEAZgB0AGUAcgBfAHQAaQB0AGwAZQAAAAYA NgATpGgBAAAuACkAogBxAy4ADAAAANJAHwAAAAsAUABhAGcAZQAgAE4AdQBtAGIAZQByAAAA AABEAP4PAQACAEQADAAAANJAHwAAAAcAUABhAHIAdABfAE4AbwAAABMAOAAFJAEGJAETpOAB FKRQAGEkAQAHADsIAUNKHAAAOgD+DwEAAgA6AAwAAADSQB8AAAAIAFAAYQByAHQAXwByAGUA ZgAAAA8AOQAFJAEGJAETpBgBYSQBAAAASgD+DwEAYgNKAAwAAADSQB8AAAAKAFAAYQByAHQA XwB0AGkAdABsAGUAAAATADoABSQBBiQBE6TwABSkGAFhJAEABwA1CAFDShwAAFIA/g8BAGID UgAMAAAA0kAfAAAACABSAGUAYwBfAGQAYQB0AGUAAAAgADsABSQBBiQBFcYSBBoDpwQ0BsEH GQAZABkAGQAAYSQCBwA2CAFDShYAADYA/g+xA2IDNgAMAAAA0kAfAAAADQBRAHUAZQBzAHQA aQBvAG4AXwBkAGEAdABlAAAAAgA8AAAAOgD+DwEAAgA6AAwAAADSQB8AAAAGAFIAZQBjAF8A TgBvAAAADAA9AAUkAQYkAROkAAAHADUIAUNKHAAAMgD+D9EDAgAyAAwAAADSQB8AAAALAFEA dQBlAHMAdABpAG8AbgBfAE4AbwAAAAIAPgAAAEQA/g8BAAIARAAMAAAA0kAfAAAACQBSAGUA YwBfAE4AbwBfAEIAUgAAAA8APwAFJAEGJAETpOABYSQBAAcAOwgBQ0ocAAA4AP4P8QMCADgA DAAAANJAHwAAAA4AUQB1AGUAcwB0AGkAbwBuAF8ATgBvAF8AQgBSAAAAAgBAAAAATAD+DwEA sgNMAAwAAADSQB8AAAAHAFIAZQBjAF8AcgBlAGYAAAAgAEEABSQBBiQBFcYSBBoDpwQ0BsEH GQAZABkAGQAAYSQBAwA2CAEANAD+DxEEwgM0AAwAAADSQB8AAAAMAFEAdQBlAHMAdABpAG8A bgBfAHIAZQBmAAAAAgBCAAAARAD+DwEAYgNEAAwAAADSQB8AAAAJAFIAZQBjAF8AdABpAHQA bABlAAAADwBDAAUkAQYkAROkaAFhJAEABwA1CAFDShwAADgA/g8xBCIEOAAMAAAA0kAfAAAA DgBRAHUAZQBzAHQAaQBvAG4AXwB0AGkAdABsAGUAAAACAEQAAAAqAP4PogBRBCoADAAAANJA HwAAAAcAUgBlAGMAXwBkAGUAZgAAAAMANQiBADQA/g8BAGIENAAMAAAA0kAfAAAACABSAGUA ZgBfAHQAZQB4AHQAAAAKAEYAXoQaA2CE5vwAADoA/g8BAGIEOgAMAAAA0kAfAAAACQBSAGUA ZgBfAHQAaQB0AGwAZQAAAAkARwATpOABYSQBAAMANQgBACwA/g+xA2IDLAAMAAAA0kAfAAAA CABSAGUAcABfAGQAYQB0AGUAAAACAEgAAAAoAP4P0QMCACgADAAAANJAHwAAAAYAUgBlAHAA XwBOAG8AAAACAEkAAAAuAP4P8QMCAC4ADAAAANJAHwAAAAkAUgBlAHAAXwBOAG8AXwBCAFIA AAACAEoAAAAqAP4PEQSCBCoADAAAANJAHwAAAAcAUgBlAHAAXwByAGUAZgAAAAIASwAAAC4A /g8xBLIELgAMAAAA0kAfAAAACQBSAGUAcABfAHQAaQB0AGwAZQAAAAIATAAAACwA/g+xA2ID LAAMAAAA0kAfAAAACABSAGUAcwBfAGQAYQB0AGUAAAACAE0AAAAyAP4PogDhBDIADAAAANJA HwAAAAcAUgBlAHMAXwBkAGUAZgAAAAsANQiBT0oAAFFKAAAAKAD+D9EDAgAoAAwAAADSQB8A AAAGAFIAZQBzAF8ATgBvAAAAAgBPAAAALgD+D/EDAgAuAAwAAADSQB8AAAAJAFIAZQBzAF8A TgBvAF8AQgBSAAAAAgBQAAAAKgD+DxEE0gQqAAwAAADSQB8AAAAHAFIAZQBzAF8AcgBlAGYA AAACAFEAAAAuAP4PMQQSBS4ADAAAANJAHwAAAAkAUgBlAHMAXwB0AGkAdABsAGUAAAACAFIA AABOAP4PAQACAE4ADAAAANJAHwAAAAkAUwBlAGMAdABpAG8AbgBfADEAAAAeAFMAE6RwAhXG EgQaA6cENAbBBxkAGQAZABkAAGEkAQMANQgBAE4A/g8BAAIATgAMAAAA0kAfAAAACQBTAGUA YwB0AGkAbwBuAF8AMgAAAB4AVAATpPAAFcYSBBoDpwQ0BsEHGQAZABkAGQAAYSQBAwA2CAEA SgD+DwEAAgBKAAwAAADSQB8AAAAKAFMAZQBjAHQAaQBvAG4AXwBOAG8AAAATAFUABSQBBiQB E6TgARSkUABhJAEABwA7CAFDShwAAFAA/g8BAGIDUAAMAAAA0kAfAAAADQBTAGUAYwB0AGkA bwBuAF8AdABpAHQAbABlAAAAEwBWAAUkAQYkAROk4AEUpBgBYSQBAAcANQgBQ0ocAAA8AP4P AQBiAzwADAAAANJAHwAAAAYAUwBvAHUAcgBjAGUAAAANAFcAE6RIAxSkyABhJAEABwA1CAFD ShwAAFYA/g+RAoIFVgAMAAAA0kAfAAAADgBTAHAAZQBjAGkAYQBsACAARgBvAG8AdABlAHIA AAAZAFgAFcYRAAU3Am4EpQbcCBMLAAAAAABhJAMABgA7CAB1CAA4AP4PogCRBTgADAAAANJA HwAAAAoAVABhAGIAbABlAF8AZgByAGUAcQAAAAwANQiBQioAcGgAAAD/fgD+DwEAAgB+AAwA AADSQB8AAAAKAFQAYQBiAGwAZQBfAGgAZQBhAGQAAABIAFoABiQBE6RQABSkUAAVxjUDGgOn BDQGGQAZABkADRwBNwJTA24EigWlBtwI+AkTCy8MSg1mDoEPAAAAAAAAAAAAAAAAAGEkAQcA NQgBQ0oWAAB0AP4PAQCyBXQADAAAANJAHwAAAAwAVABhAGIAbABlAF8AbABlAGcAZQBuAGQA AAA+AFsAFKQoABXGNQMaA6cENAYZABkAGQANHAE3AlMDbgSKBaUG3Aj4CRMLLwxKDWYOgQ8A AAAAAAAAAAAAAAAABABDShYAUgD+DwEAogVSAAwAAADSQB8AAAAQAFQAYQBiAGwAZQBfAE4A bwAgACYAIAB0AGkAdABsAGUAAAATAFwABSQBBiQBE6RoARSkeABhJAEAAwA1CAEARAD+DwEA YgJEAAwAAADSQB8AAAALAFQAYQBiAGwAZQBfAE4AbwBfAEIAUgAAABAAXQAGJAETpDACFKR4 AGEkAQMAOwgBADwA/g8BAGICPAAMAAAA0kAfAAAACQBUAGEAYgBsAGUAXwByAGUAZgAAABAA XgAGJAETpAAAFKR4AGEkAQAAdAD+DwEA8gV0AAwAAADSQB8AAAAKAFQAYQBiAGwAZQBfAHQA ZQB4AHQAAABCAF8AE6QoABSkKAAVxjUDGgOnBDQGGQAZABkADRwBNwJTA24EigWlBtwI+AkT Cy8MSg1mDoEPAAAAAAAAAAAAAAAAAAQAQ0oWAFwA/g9xBQIAXAAMAAAA0kAfAAAABwBUAGkA dABsAGUAIAAxAAAALgBgABOk8AAUpAAAFcYhBBoDpwQ0BsEHGQAZABkAGQAFNwJuBKUG3AgT CwAAAAAABgA1CAA7CAEqAP4PAQYCACoADAAAANJAHwAAAAcAVABpAHQAbABlACAAMgAAAAIA YQAAAC4A/g8RBgIALgAMAAAA0kAfAAAABwBUAGkAdABsAGUAIAAzAAAAAgBiAAMAOwgAAC4A /g8hBhIALgAMAAAA0kAfAAAABwBUAGkAdABsAGUAIAA0AAAAAgBjAAMANQgBAEIA/g8BAFIG QgAMAAAA0kAfAAAABQB0AG8AYwAgADAAAAAaAGQAFcYVBBoDpwQ0BsEHGQAZABkAGQABpyUC AwA1CAEAWAATAAEAUgZYAAwBAADSQB8AAAAFAFQATwBDACAAMQAAADMAZQAFJAETpPAAFcYb BBoDpwQ0BsEHGQAZABkAGQADxANVIqclAAgCXYRTA16EqAJghFj9AAAAMgAUAFEGYgYyAAwB AADSQB8AAAAFAFQATwBDACAAMgAAAA4AZgATpFAAXoT7BWCErfwAACYAFQBhBnIGJgAMAQAA 0kAfAAAABQBUAE8AQwAgADMAAAACAGcAAAAmABYAcQaCBiYADAEAANJAHwAAAAUAVABPAEMA IAA0AAAAAgBoAAAAJgAXAIEGkgYmAAwBAADSQB8AAAAFAFQATwBDACAANQAAAAIAaQAAACYA GACBBqIGJgAMAQAA0kAfAAAABQBUAE8AQwAgADYAAAACAGoAAAAmABkAgQayBiYADAEAANJA HwAAAAUAVABPAEMAIAA3AAAAAgBrAAAAJgAaAIEGwgYmAAwBAADSQB8AAAAFAFQATwBDACAA OAAAAAIAbAAAAEgA/g+iANEGSAAMAAEAOiMBAAAADgBIAGUAYQBkAGkAbgBnACAAMQAgAEMA aABhAHIAAAATADUIgUNKGABtSAkIc0gJCHRICQQAUEsDBBQABgAIAAAAIQAbiY4b/gAAABwC AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRz2rDMAzG74O9g/F1JE53GGMk6WHtbvtz6B5A OEpilsjGVkv79lPSFsYohcEuBlnS9/0klcv9OKgdxuQ8VXqRF1ohWd846ir9uXnJHrVKDNTA 4AkrfcCkl/XtTbk5BExKuilVumcOT8Yk2+MIKfcBSTKtjyOwhLEzAewXdGjui+LBWE+MxBlP GrouV9jCdmC13sv3kUTatXo+1k1WlYYQBmeBBdRMWVOX7wIeXYPqAyK/wShVhgUBf76L/LrW jppfwJlvW2ex8XY7CmY+S979xfMVSIaN/+N8EjsDXFhWxCFd2daFCU/nyKVz3mjqXUhnBzPf tv4GAAD//wMAUEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89q wzAMh++FvYPRfVHSwxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcg FpqqBsPiQz/LaOF2Pb9/gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk 0ckQ0kpF2zRiJH+nkXFf1x+YnhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnk YqGoL+NTvZCoZarUHtC1uPnW/QEAAP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwA AAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy667 9gBDnBpBx6DSn9vX5eODN87fFNWbSw1ZLJwHDYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJ tI0T30nIc1F9I9WQha213SDWtSvVIe8s3V65JGo9i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQ SwMEFAAGAAgAAAAhAJ1ci74QBwAAhx0AABYAAAB0aGVtZS90aGVtZS90aGVtZTEueG1s7FlP bxtFFL8j8R1Ge28TJ06aRHWq2LEJtGmj2C3qcbw79k4zu7OaGSfxDbVHJCREQRyoxI0DAiq1 EpfyaQJFUKR+Bd7M7K534nHjlAAVNIfWO/t7b977vT/zZ69eO04YOiRCUp42gtrlxQCRNOQR TYeN4Havc2ktQFLhNMKMp6QRjIkMrm2++85VvKFikhAE8qncwI0gVirbWFiQIQxjeZlnJIV3 Ay4SrOBRDBcigY9Ab8IWlhYXVxcSTNMApTgBtbcGAxoS1NMqg81CeZvBY6qkHgiZ6GrVxJEw 2OigphFyLFtMoEPMGgHME/GjHjlWAWJYKnjRCBbNX7CweXUBb+RCTM2Qrch1zF8ulwtEB0tm TjHsl5PWOvX1K9ulfgNgahrXbrdb7VqpzwBwGIKn1paqznpnrdYsdFZA9ue07tbiymLdxVf0 L0/ZvN5sNlfWc1usUgOyP+tT+LXF1frWkoM3IItfmcLXm1ut1qqDNyCLX53Cd66sr9ZdvAHF jKYHU2gd0E4n115CBpzteOFrAF9bzOETFGRDmV16igFP1axcS/A9LjoA0ECGFU2RGmdkgEPI 4hZmtC+ongBvEFx5Y4dCOTWk50IyFDRTjeCDDENFTPS9fPbdy2dP0Mn9pyf3fzx58ODk/g9W kSO1g9NhVerFN5/+8egj9PuTr188/NyPl1X8L99//PNPn/mBUD4Tc55/8fjXp4+ff/nJb98+ 9MC3BO5X4T2aEIlukiO0zxNwzLDiWk764nwSvRjTqsRWOpQ4xXoWj/62ih30zTFm2INrEpfB OwLahw/43uieY3A3FiOVx9vx7HqcOMBdzlmTCy8L1/VcFZp7o3Ton1yMqrh9jA99c7dw6sS3 Pcqgb1KfylZMHDP3GE4VHpKUKKTf8QNCPHzdpdThdZeGgks+UOguRU1MvZT0aN/JponQDk0g LmOfgRBvh5vdO6jJmc/rbXLoIqEqMPMY3yPMofE9PFI48ans4YRVCb+BVewzsjsWYRXXlgoi PSSMo3ZEpPTJ3BLgbyXo16F1+MO+y8aJixSKHvh03sCcV5Hb/KAV4yTzYbs0javY9+UBpChG e1z54LvcrRD9DHHA6cxw36HECffZ3eA2HTomTRJEvxkJHUto1U4HTmj6qnacQDfO3bm4dgwN 8PlXjzyZ9aY24i0gwVcJO6fa7yzc6abb4iKib37P3cajdI9Amk8vPG9b7tuWG/znW+6sep63 0U56K7Rdvb2xm2KzRU5m7pAHlLGuGjNyQ5pNsoR1IurAoJYzp0NSnpiyGH7mfd3BDQU2Mkhw 9SFVcTfGGWywa4FWMpS56qFEGZdwsDPDXt0aD5t0ZY+FK/rAYPuBxGqXR3Z4WQ8X54JSjVlt hubwWUy0rBXMO9nylVwpuP06k9W0UXPPVjOmmVbnzFa6DDGcdg0GSzZhA4Jg2wIsr8L5XE8N BxPMSKR5t2tvERYThb8nRLnX1pEYR8SGyBmusFkzsStSyFwQQEp5Qnc+NkvWgLSzjTBpMTt/ 5iS5UDAhWZfdqWpiabW2WIqOGsH6ytJKgEKcNYIBHEnhZ5JB0KTesmE2hHudUAmbtWfWoinS icfr/qyqwS3DjIJxyjgTUm1jGdsYmld5qFiqZ7L2L63UdbJdjAM2UV/DiuU1SJF/zQoItRta MhiQUFWDXRnR3NnHvBPykSKiG0dHqM9GYh9D+IFT7U9EJdwsmILWD3ANptk2r9zemnea6uWT wdlxzLIY591SX6MUFWfhpt5KG8xTxTzwzWu7ce78ruiKvyhXqmn8P3NFLwdw0F+OdARCuIUV GOl6bQRcqJhDF8piGnYErPumd0C2wFUqvAby4S7Y/C/Iof7f1pzVYcoazmtqnw6RoLCcqFgQ sgdtyWTfGcpq+dJjVbJckcmoirkys2b3ySFhPd0DV3UPDlAMqW66Sd4GDO50/rnPeQX1h3qP Uq03p4eUS6etgX9642KLGZw6tZfQ+VvwX5roWf2svBEv1siqI/rFZJdUL6rCWfzW1/OpXtOE eRbgylprO9aUx0srhXEQxWmPYbDcz2RwXYP0P7D+UREy+2FBL6g9vg+9FcF3Assfgqy+pLsa ZJBukPZXH/Y9dtAmk1Zlqc13Ppq1YrG+4I1qOe8psrVl88T7nGSXmyh3OqcWL5LsnGGHazs2 k2qI7OkShaFBcQ4xgTFfpKofjXj/HgR6G67nR8x+RpIZPJk6yPaEya4+j8b5TybtgmuzTp9h NJKl+2SAaHRcnD9KJmwJ2U8ZxRbZoLWYTrRScNl3aHAFc7wWtatlKbx0tnApYWaGll0Kmxsy nwL4kJU3bn20A7xtstZrXVwFUyz9K5TNYbyfMu/JZ17K7EHxlYF6DcrU8aspy5kC8qYTDz5F CgxHk67pv7Do2Ew3Kbv5JwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0 aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6 EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBS Fk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA //8DAFBLAQItABQABgAIAAAAIQAbiY4b/gAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29u dGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAA AAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAA AAAAAAAAGAIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEA nVyLvhAHAACHHQAAFgAAAAAAAAAAAAAAAADVAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBL AQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAABkKAAB0aGVtZS90aGVt ZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAFAsAAAAAPD94 bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K PGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9k cmF3aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9 ImRrMiIgYWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNj ZW50MyIgYWNjZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNj ZW50NiIgaGxpbms9ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAAAAFREAAAYAAEYA AAEA/////wAAAAADAAAABgAAAAYAAAAJAAAADAAAAAwAAAAMAAAAPwAAAD8AAABdAAAAXQAA AKACAACjAgAAAAgAAMQJAACjFQAAkRcAABUZAAAWAAAAHAAAAB4AAAAhAAAAAAgAAIkIAACr CAAAvwgAAP8IAABlCQAAnhYAADoXAAAQGQAAFRkAABcAAAAYAAAAGQAAABoAAAAbAAAAHQAA AB8AAAAgAAAAIgAAAA4AAAAlAAAAJwAAAKMCAAATIVT/lYAPAADwaAAAAAAABvAoAAAAAhAA AAQAAAACAAAAAgAAAAEAAAACAAAAAgAAAAEAAAAAAAAAAAAAAEMAC/AYAAAAgQA3IgEAggC6 IgAAgwA3IgEAhAC6IgAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAQ8AAvBIAAAAIAAI8AgA AAABAAAAAAgAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArw CAAAAAAIAAAFAAAAAA8AAvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAcAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAA AAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAA AAEAAAD//w0AAAAEAGQAbgB1AG0ACABkAHQAYQBiAGwAZQBhAHUABQBkAGQAYQB0AGUABwBk AG8AcgBsAGEAbgBnAAgAZABtAGUAZQB0AGkAbgBnAAkAZABiAGwAdQBlAHAAaQBuAGsABgBk AHQAaQB0AGwAZQAHAGQAcwBvAHUAcgBjAGUABwBkAHQAaQB0AGwAZQAxAAgAZABjAG8AbgB0 AGEAYwB0AAkAZABjAG8AbgB0AGUAbgB0ADEACABkAGMAbwBuAHQAZQBuAHQACQBkAGMAbwBu AHQAZQBuAHQAMgAAAAAAAAAAADwAAACKAAAArAAAAKwAAADAAAAA4wAAAAABAADQDgAA0A4A ADEPAAAxDwAAFhEAAAAAAoMHAAAAAQACgwIAAoMDAAKDBAABggUAAIEGAAGCCAABggkAAAAK AAGCCwABggwAAYI8AAAAigAAAKwAAADAAAAAwAAAAOMAAAAAAQAAWAEAAFgBAAAxDwAAMQ8A AJEPAACRDwAAFhEAAHUOAAB1DgAAAAAAAAEAAAAmAQAALAEAAC4BAAA0AQAANQEAAEIBAABY AgAAZQIAAGYCAABxAgAAcgIAAHoCAADADAAAxgwAAHMOAABzDgAAdQ4AAHUOAAB2DgAAdg4A AHgOAAB5DgAAew4AAHwOAAB+DgAAfw4AAIEOAACbDgAA3g4AAOcOAADoDgAAEhEAABYRAAAE AAcAAwAHAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAQABwAEAAIABAAHAAQABwAEAAcABAAC AAcAAgAEAAIABwACAAAAAAABAAAAtwoAALgKAABzDgAAcw4AAHUOAAB1DgAAdg4AAHYOAAB4 DgAAeQ4AAHsOAAB8DgAAfg4AAH8OAACBDgAAmw4AABYRAAAEAAcABAAHAAQAAgAEAAIABAAC AAQAAgAEAAIABAACAAcAAgAJAPv///8uwGzq/w//D/8P/w8FAAYABwAIAAkAAADDF7MZcAAm l/8P/w//D/8P/w//D/8P/w//DxAAdjZ9I6xXvkn/D/8P/w//D/8P/w//D/8P/w8QAGFA3iPS EF4g/w//D/8P/w//D/8P/w//D/8PEABrSJ4xKJfs6f8P/w//D/8P/w//D/8P/w//DxAAcXUX RGBo3KX/D/8P/w//D/8P/w//D/8P/w8QAEF0e1KGW7It/w//D/8P/w//D/8P/w//D/8PEABr AV9qxqXMAv8P/w//D/8P/w//D/8P/w//DxAAfh2pdZZ6OEH/D/8P/w//D/8P/w//D/8P/w8A AAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhLABEYRQ/hXGBQABsAEGXoSwAWCEUP5v KAABAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EQAIRhMD9FcYFAAFAAgZehEAC YITA/W8oAAMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhDD9FcYF AAHQAgZehNACYIQw/W8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMY AAAPhGADEYSg/BXGBQABYAMGXoRgA2CEoPxvKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMF BwkAAAAAAAAAAAAAAAAAAxgAAA+E8AMRhBD8FcYFAAHwAwZehPADYIQQ/G8oAAkAAAAuAAEA LgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAAxgAAA+EgAQRhID7FcYFAAGA BAZehIAEYISA+28oAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAA AAAAAAAAAAMYAAAPhBAFEYTw+hXGBQABEAUGXoQQBWCE8PpvKAANAAAALgABAC4AAgAuAAMA LgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGg BQZehKAFYIRg+m8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMF BwkLDQ8RAAAAAAAAAAAAAxgAAA+EMAYRhND5FcYFAAEwBgZehDAGYITQ+W8oABEAAAAuAAEA LgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAAPGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oEAFFKBABeShoAbygA AQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCE mP5PSgUAUUoFAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4V xgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA DxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBABRSgQAXkoaAG8oAAEAbwABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oFAFFKBQBv KAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLAT YISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhIAWEYSY /hXGBQABgBYGXoSAFmCEmP5PSgQAUUoEAF5KGgBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBQBRSgUAbygAAQCn8AYAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhCADEYTg/BXGBQABIAMGXoQgA2CE4PxvKAABAAAA AQAAABQAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+EwAMRhCD+FcYFAAHAAwZehMADYIQg/gMA KAABACkAAQAAABIAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoAURhCD+FcYFAAGgBQZehKAF YIQg/gEAAgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SABxGEIP4VxgUAAYAHBl6E gAdghCD+AgADAC4AAQAAABQAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+EYAkRhCD+FcYFAAFg CQZehGAJYIQg/gMAKAAEACkAAQAAABIAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EQAsRhCD+ FcYFAAFACwZehEALYIQg/gEABQABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QgDRGE IP4VxgUAASANBl6EIA1ghCD+AgAGAC4AAQAAABQAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+E AA8RhCD+FcYFAAEADwZehAAPYIQg/gMAKAAHACkAAQAAABIAAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+E4BARhCD+FcYFAAHgEAZehOAQYIQg/gEACAABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygAAgAAACkAAQAAABSAAgAAAAAAAAAA AAAAAAAAAAAAABgAAA+ESAMRhFz+FcYFAAFIAwZehEgDYIRc/gMAKAABACkAAQAAABKAAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+E7AQRhFz+FcYFAAHsBAZehOwEYIRc/gEAAgABAAAAAIAB AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SQBhGEXP4VxgUAAZAGBl6EkAZghFz+AgADAC4AAQAA ABSAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+ENAgRhFz+FcYFAAE0CAZehDQIYIRc/gMAKAAE ACkAAQAAABKAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E2AkRhFz+FcYFAAHYCQZehNgJYIRc /gEABQABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4R8CxGEXP4VxgUAAXwLBl6EfAtg hFz+AgAGAC4AAQAAABSAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+EIA0RhFz+FcYFAAEgDQZe hCANYIRc/gMAKAAHACkAAQAAABKAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+ExA4RhFz+FcYF AAHEDgZehMQOYIRc/gEACAABAAAADgABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4TgARGEIP5e hOABYIQg/m8oAQIAAAApAAEAAAAUgAIAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhMADEYQg/l6E wANghCD+AwAoAAEAKQABAAAAEoABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4SgBRGEIP5ehKAF YIQg/gEAAgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4SABxGEIP5ehIAHYIQg/gIA AwAuAAEAAAAUgAIAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGAJEYQg/l6EYAlghCD+AwAoAAQA KQABAAAAEoABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RACxGEIP5ehEALYIQg/gEABQABAAAA AIABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4QgDRGEIP5ehCANYIQg/gIABgAuAAEAAAAUgAIA AAAAAAAAAAAAAAAAAAAAAAAQAAAPhAAPEYQg/l6EAA9ghCD+AwAoAAcAKQABAAAAEoABAAAA AAAAAAAAAAAAAAAAAAAAEAAAD4TgEBGEIP5ehOAQYIQg/gEACAABAAAAAAABAAAAAAAAAAAA AAAAAAAAAAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygAAgAAAC4AAQAAAAAAAgAA AAAAAAAAAAAAAAAAAAAAAxgAAA+EzwMRhNX9FcYFAAHPAwZehM8DYITV/W8oAAMAKAABACkA AQAAABKAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E7AQRhFz+FcYFAAHsBAZehOwEYIRc/gEA AgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SQBhGEXP4VxgUAAZAGBl6EkAZghFz+ AgADAC4AAQAAABSAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+ENAgRhFz+FcYFAAE0CAZehDQI YIRc/gMAKAAEACkAAQAAABKAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E2AkRhFz+FcYFAAHY CQZehNgJYIRc/gEABQABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4R8CxGEXP4VxgUA AXwLBl6EfAtghFz+AgAGAC4AAQAAABSAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+EIA0RhFz+ FcYFAAEgDQZehCANYIRc/gMAKAAHACkAAQAAABKAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E xA4RhFz+FcYFAAHEDgZehMQOYIRc/gEACAABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAA D4TgARGEmP4VxgUAAeABBl6E4AFghJj+bygAAgAAACkAAQAAABSAAgAAAAAAAAAAAAAAAAAA AAAAABgAAA+EwAMRhFz+FcYFAAHAAwZehMADYIRc/gMAKAABACkAAQAAABKAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EZAURhFz+FcYFAAFkBQZehGQFYIRc/gEAAgABAAAAAIABAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4QIBxGEXP4VxgUAAQgHBl6ECAdghFz+AgADAC4AAQAAABSAAgAA AAAAAAAAAAAAAAAAAAAAABgAAA+ErAgRhFz+FcYFAAGsCAZehKwIYIRc/gMAKAAEACkAAQAA ABKAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUAoRhFz+FcYFAAFQCgZehFAKYIRc/gEABQAB AAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4T0CxGEXP4VxgUAAfQLBl6E9AtghFz+AgAG AC4AAQAAABSAAgAAAAAAAAAAAAAAAAAAAAAAABgAAA+EmA0RhFz+FcYFAAGYDQZehJgNYIRc /gMAKAAHACkAAQAAABKAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EPA8RhFz+FcYFAAE8DwZe hDwPYIRc/gEACAAKAAAAFwAAAAAAAAAAAAABAAAAAAAAAAATEAAAD4SsAxGEdP9ehKwDYIR0 /09KAABQSgMAUUoAAFJIAABvKAABAC0AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E 4AYRhCD+FcYFAAHgBgZehOAGYIQg/k9KBQBRSgUAbygAAQDY8AEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhMAIEYQg/hXGBQABwAgGXoTACGCEIP5PSgUAUUoFAG8oAAEAsvABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SgChGEIP4VxgUAAaAKBl6EoApghCD+T0oFAFFK BQBvKAABAGzwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgAwRhCD+FcYFAAGADAZe hIAMYIQg/k9KBQBRSgUAbygAAQDY8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGAO EYQg/hXGBQABYA4GXoRgDmCEIP5PSgUAUUoFAG8oAAEAsvABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4RAEBGEIP4VxgUAAUAQBl6EQBBghCD+T0oFAFFKBQBvKAABAGzwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EIBIRhCD+FcYFAAEgEgZehCASYIQg/k9KBQBRSgUA bygAAQDY8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhAAUEYQg/hXGBQABABQGXoQA FGCEIP5PSgUAUUoFAG8oAAEAsvAGAAAAAAABAAAAAAAAAAABAAAAAAAAAAADEAAAD4QsARGE 1P5ehCwBYITU/m8oAAEAAAABAAAAAAABAwAAAAAAAAABAAAAAAAAAAADEAAAD4QsARGE1P5e hCwBYITU/m8oAAMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAQAAAAAAAAAAAxAAAA+ELAERhNT+ XoQsAWCE1P5vKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAABAAAAAAAAAAADEAAAD4Qs ARGE1P5ehCwBYITU/m8oAAcAAAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAABAAAAAAAA AAADEAAAD4QsARGE1P5ehCwBYITU/m8oAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMF BwkLAAAAAQAAAAAAAAAAAxAAAA+ELAERhNT+XoQsAWCE1P5vKAALAAAALgABAC4AAgAuAAMA LgAEAC4ABQABAAAAAAABAwUHCQsNAAABAAAAAAAAAAADEAAAD4QsARGE1P5ehCwBYITU/m8o AA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwABAAAAAAAAAAAD EAAAD4QsARGE1P5ehCwBYITU/m8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcA AQAAAAAAAQMFBwkLDQ8RAQAAAAAAAAAAAxAAAA+ELAERhNT+XoQsAWCE1P5vKAARAAAALgAB AC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAANAAAA+////wAAAAAAAAAAAAAAAPv///8A AAAAAAAAAAAAAAD7////AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAPv///8AAAAAAAAA AAAAAADDF7MZAAAAAAAAAAAAAAAAawFfagAAAAAAAAAAAAAAAHY2fSMAAAAAAAAAAAAAAAB+ Hal1AAAAAAAAAAAAAAAAcXUXRAAAAAAAAAAAAAAAAEF0e1IAAAAAAAAAAAAAAABhQN4jAAAA AAAAAAAAAAAAa0ieMQAAAAAAAAAAAAAAAP////////////////////////////////////// /////////////////////////////////wkAAAAAAAAAAAAAAAAAAAAAAAAAAAD//wkAAAAA ABIAkuGQ6QMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgDqV4RICQQXAAkEEQAJ BA8ACQQXAAkEEQAJBA8ACQQXAAkEEQASAO6+FuEXAAkEEQAJBA8ACQQXAAkEEQAJBA8ACQQX AAkEEQAJBBIA8oMyMxcACQQRAAkEDwAJBBcACQQRAAkEDwAJBBcACQQRAAkEEgCUEWRBEGrg WREACQQPAAkEFwAJBBEACQQPAAkEFwAJBBEACQQSAL6VFt4XAAkEEQAJBA8ACQQXAAkEEQAJ BA8ACQQXAAkEEQAJBBIAvOsqKgkECwAJBA0ACQQBAAkECwAJBA0ACQQBAAkECwAJBA0AAAAC AAAAAAAHBAACCQABAAwEAgJBAAEAAAAEAAAACAAAAOUAAAAAAAAAAAAAAAlVzQAAAAAAAgAA ACgAAAA7AAAAPAAAAD0AAAB9AAAAiQAAAIoAAACLAAAAjAAAAKsAAACsAAAAuQAAAL4AAAC/ AAAAwAAAAOIAAADjAAAA6wAAAP8AAAAAAQAABwEAAFcBAABYAQAAcw4AANAOAADZDgAAAA8A ADAPAAAxDwAAOg8AAGAPAACQDwAAkQ8AABARAAAREQAAFhEAAAAAAAACAQAAAgEAAAIBAAAe AQAEAgEAAAIBAAACAQAAHgEABAIBAAACAQAAAgEAAB4BAAQCAQAAAgEAAAIBAAAeAQAEAgEA AB4BAAQCAQAAAgEAAB4BAAQCAQAAAgEAABYBAAQAAAAACAAAAAIBAAACAQAAAgEAAB4BAAQC AQAAAgEAAAIBAAAeAQAEAgEAABYBAAT/QAIQAAAAAAAAABURAABgAAAQAEAAAP//AQAAAAcA VQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAA AgD//wAAAAAGAAAARwaQAQAAAgIGAwUEBQIDBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAFQA aQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANQaQAQIAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQAQAAAgsGBAICAgICBAMAAAAAAAAA AAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAAEc1AACACgICBgkEAgUIAwT/AgDg+/3HahIA AAAAAAAAnwACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAAAC3/M/8gAA5mHWcAAD8GkAEAAAIH AwkCAgUCBAQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcA AAA7BpABAgAFAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkA bgBnAHMAAAAgAAQAMwCMGADwNwIAAKkBAAAAAOVZ+IblWfiGWzXrxgIAAAAAABcCAADqCwAA AgAGAAAABAADABkAAAAAAAAAAAAAAAIAAQAAAAEAAAAAAAAAESQA8BAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbgSJBXgAtACAgBI0AAAAAAAAAAAAAAAA AAChDgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAADxAgAAAAAEQoMRAPAQAAgA/P0BAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAkhQAAAAAAnx/w8AAAE/AAAQJwAA////f////3////9/////f////3////9/ ////f5hmKwAABAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA EBwAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAUAAP//EgAAAAAAOQBDADoAXABUAHIA YQB2AGEAaQBsAFwAVwBvAHIAZABcAFMAYQB1AHYAZQBHAGEAcgBkAGUAXABBAG4AZwBsAGEA aQBzAFwASQB0AHUAdABCAGEAcwBpAGMALQBUAGUAbQBwAGwAYQB0AGUALgBkAG8AdABcAFAA cgBvAHAAbwBzAGEAbAAgAG8AZgAgAHQAaABlACAAYwByAGUAYQB0AGkAbwBuACAAbwBmACAA YQAgAG4AZQB3ACAAdwBvAHIAawAgAGkAdABlAG0AIAAcIHQAZQBjAGgAbgBpAGMAYQBsACAA cwBlAGMAdQByAGkAdAB5ACAAZwB1AGkAZABlAGwAaQBuAGUAIABvAG4AIABkAGUAcABsAG8A eQBpAG4AZwAgAEkAUAB2ADYAHSAAAAEAMgAAAF8ATgBhAHQAaQBvAG4AYQBsACAASQBuAHMA dABpAHQAdQB0AGUAIABvAGYAIABJAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABhAG4AZAAgAEMA bwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AcwAgAFQAZQBjAGgAbgBvAGwAbwBnAHkALAAgAEoA YQBwAGEAbgAgACgATgBJAEMAVAApACwAIABLAEQARABJACAAQwBvAHIAcABvAHIAYQB0AGkA bwBuAAgAZwBzAGMAaAB1AGQAZQBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAYAAAAJAAAA AAAMAAEADAACAAwAAwAMAAQADAAFAAwABgAMAAcADAAIAAwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAMKAQAAAAAA AAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAyAIAABIAAAABAAAAmAAAAAIA AACgAAAAAwAAAAgBAAAEAAAAFAEAAAUAAAB8AQAABgAAAIgBAAAHAAAA9AEAAAgAAAA0AgAA CQAAAEgCAAASAAAAVAIAAAoAAAB4AgAACwAAAIQCAAAMAAAAkAIAAA0AAACcAgAADgAAAKgC AAAPAAAAsAIAABAAAAC4AgAAEwAAAMACAAACAAAAECcAAB4AAABgAAAAUHJvcG9zYWwgb2Yg dGhlIGNyZWF0aW9uIG9mIGEgbmV3IHdvcmsgaXRlbSDSdGVjaG5pY2FsIHNlY3VyaXR5IGd1 aWRlbGluZSBvbiBkZXBsb3lpbmcgSVB2NtMAAAAAHgAAAAQAAAAAAAAAHgAAAGAAAABOYXRp b25hbCBJbnN0aXR1dGUgb2YgSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIFRlY2hu b2xvZ3ksIEphcGFuIChOSUNUKSwgS0RESSBDb3Jwb3JhdGlvbgAeAAAABAAAADIAAAAeAAAA ZAAAAENPTSAxNyDQIEMgNDU0INAgRSAgRm9yOiANRG9jdW1lbnQgZGF0ZTogTWFyY2ggMjAx MQ1TYXZlZCBieSBFTlYxMDY4ODcgYXQgMTY6MDI6NDUgb24gMzAvMDMvMjAxMQAAAAAeAAAA OAAAAFxUcmF2YWlsXFdvcmRcU2F1dmVHYXJkZVxBbmdsYWlzXEl0dXRCYXNpYy1UZW1wbGF0 ZS5kb3QAHgAAAAwAAABnc2NodWRlbAAAAAAeAAAABAAAADIAAAAeAAAAHAAAAE1pY3Jvc29m dCBNYWNpbnRvc2ggV29yZAAAAABAAAAAAAAAAAAAAABAAAAAAIImBTR+ywFAAAAAAA7gIDRY zAFAAAAAAA7gIDRYzAEDAAAAAgAAAAMAAAAXAgAAAwAAAOoLAAADAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAADCgEAAAAAAAAAAAAAAAAA AAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a7IAQAAhAEAAA0A AAABAAAAcAAAAA4AAAB4AAAADwAAAIgAAAAFAAAAvAAAAAYAAADEAAAAEQAAAMwAAAAXAAAA 1AAAAAsAAADcAAAAEAAAAOQAAAATAAAA7AAAABYAAAD0AAAADQAAAPwAAAAMAAAAZQEAAAIA AAAQJwAAHgAAAAgAAABJVFUtVAAAAB4AAAAsAAAASW50ZXJuYXRpb25hbCBUZWxlY29tbXVu aWNhdGlvbiBVbmlvbiAoSVRVKQADAAAAGQAAAAMAAAAGAAAAAwAAAKEOAAADAAAAAAAMAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAABdAAAAUHJvcG9zYWwgb2Yg dGhlIGNyZWF0aW9uIG9mIGEgbmV3IHdvcmsgaXRlbSDSdGVjaG5pY2FsIHNlY3VyaXR5IGd1 aWRlbGluZSBvbiBkZXBsb3lpbmcgSVB2NtMADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAAB AAAAAJQBAAAIAAAAAAAAAEgAAAABAAAAswAAAAIAAAC7AAAAAwAAANcAAAAEAAAA6wAAAAUA AAATAQAABgAAAB8BAAAHAAAAKwEAAAYAAAACAAAABwAAAERvY251bQADAAAACAAAAERvY2Rh dGUABAAAAAoAAABEb2NvcmxhbmcABQAAAAwAAABEb2NibHVlcGluawAGAAAACAAAAERvY2Rl c3QABwAAAAoAAABEb2NhdXRob3IAAgAAABAnAAAeAAAAFAAAAENPTSAxNyDQIEMgNDU0INAg RQAAHgAAAAwAAABNYXJjaCAyMDExAAAeAAAAIAAAAEVuZ2xpc2ggb25seSBPcmlnaW5hbDog RW5nbGlzaAAAHgAAAAQAAAAyAAAAHgAAAAQAAAAAAAAAHgAAAGAAAABOYXRpb25hbCBJbnN0 aXR1dGUgb2YgSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIFRlY2hub2xvZ3ksIEph cGFuIChOSUNUKSwgS0RESSBDb3Jwb3JhdGlvbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAAP7///8lAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAA AAAxAAAAMgAAAP7///80AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA PgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAA WQAAAFoAAABbAAAA/v///10AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAAD+////ZQAAAGYA AABnAAAAaAAAAGkAAABqAAAAawAAAP7////9////bgAAAP7////+/////v////////////// /////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAD1g 0y40WMwBcAAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAACx0AAAAAAAAxAFQAYQBiAGwAZQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAAEA AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMAAACOUQAA AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAaAAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACtGAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAAAABAAAAAAAAAFAEQAbwBjAHUA bQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA OAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQA AAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAgAAAAcAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAIlf0y40WMwBiV/TLjRYzAEAAAAAAAAAAAAAAAABAAAA /v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////wEA/v8CAAEA/////wYJAgAAAAAAwAAAAAAAAEYgAAAA TWljcm9zb2Z0IFdvcmQgOTctMjAwNCBEb2N1bWVudAD+////TkI2VxAAAABXb3JkLkRvY3Vt ZW50LjgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --------------070304040700070607020606-- From kathleen.moriarty@emc.com Thu Aug 11 12:57:23 2011 Return-Path: <kathleen.moriarty@emc.com> 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 21F0121F8AFA for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 12:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNdHoTnYZVCS for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 12:57:22 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE8821F8ABC for <mile@ietf.org>; Thu, 11 Aug 2011 12:57:21 -0700 (PDT) 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 p7BJvrid001550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2011 15:57:53 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 11 Aug 2011 15:57:40 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.221.56.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7BJvdvf001674; Thu, 11 Aug 2011 15:57:39 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub15.corp.emc.com ([128.221.56.104]) with mapi; Thu, 11 Aug 2011 15:57:38 -0400 From: <kathleen.moriarty@emc.com> To: <lnunez@c3isecurity.com>, <tony@yaanatech.com> Date: Thu, 11 Aug 2011 15:57:37 -0400 Thread-Topic: [mile] draft on IODEF exstension to support structured cybersecurity information Thread-Index: AcxYWkhC5mm3sz5WTZCRBFpAZjZEdwABit8A Message-ID: <AE31510960917D478171C79369B660FA0E0552D3BF@MX06A.corp.emc.com> References: <CA6860E2.1E4BC%lnunez@cisco.com> <4E42F9DB.6070200@yaanatech.com> <CAFnG=rqKDFzjBzW9_=0GHL6p_NaRCsdkTV==MUYRE9E_mNgc1w@mail.gmail.com> In-Reply-To: <CAFnG=rqKDFzjBzW9_=0GHL6p_NaRCsdkTV==MUYRE9E_mNgc1w@mail.gmail.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_AE31510960917D478171C79369B660FA0E0552D3BFMX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mile> List-Post: <mailto:mile@ietf.org> List-Help: <mailto:mile-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2011 19:57:23 -0000 --_000_AE31510960917D478171C79369B660FA0E0552D3BFMX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It looks like the ITU CYBEX model will incorporate CVRF from the vendors th= at manage the standard. This is a big indication that the SCAP extension t= o IODEF should include CVRF. Do folks agree or disagree with including this work as a reference? I thin= k it makes a lot of sense as vendors in the US are moving to support this m= odel. Best regards, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of lui= s nunez Sent: Thursday, August 11, 2011 3:09 PM To: tony@yaanatech.com Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cyberse= curity information fyi > Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting= Framework posted to ITU. http://www.itu.int/md/T09-SG17-C-0538/en -ln On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski <tony@yaanatech.com<mailto:= tony@yaanatech.com>> wrote: Hi Inunez, In the Q4/17 workplan we have X.cvrm identified as a "CYBEX" work item. Do you think we can bring it into the upcoming meeting in two weeks? I'd be willing to work with the appropriate people to make that happen. --tony On 8/10/2011 4:22 PM, lnunez wrote: I noticed CVRF mention briefly in this email thread (good I am thinking the= same). Looking at the draft-takahash-mile-sci-01.txt I see potential syner= gies between the draft and CVRF. They both share some heritage. Major vendors have indicated that they will= start publishing security advisories in the near future. I could see this= IODEF-extension leveraging the CVRF content/components to provide addition= al fidelity to the security incident exchange. CVRF link: http://www.icasi.org/cvrf Redhat CVRF sample: http://www.awe.com/mark/blog/20110518.html It would be interesting to see a CVRF advisory with OVAL checking content a= s a mitigation method in this draft. _______________________________________________ mile mailing list mile@ietf.org<mailto:mile@ietf.org> https://www.ietf.org/mailman/listinfo/mile --_000_AE31510960917D478171C79369B660FA0E0552D3BFMX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 12 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It looks = like the ITU CYBEX model will incorporate CVRF from the vendors that manage= the standard.  This is a big indication that the SCAP extension to IO= DEF should include CVRF.<o:p></o:p></span></p><p class=3DMsoNormal><span st= yle=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><= o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11= .0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Do folks agree or di= sagree with including this work as a reference?  I think it makes a lo= t of sense as vendors in the US are moving to support this model.<o:p></o:p= ></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-famil= y:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p clas= s=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D'>Best regards,<o:p></o:p></span></p><p class=3DMsoNorma= l><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:= #1F497D'>Kathleen<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'= font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nb= sp;</o:p></span></p><div style=3D'border:none;border-top:solid #B5C4DF 1.0p= t;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-si= ze:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D= 'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mile-bounces@ietf.org= [mailto:mile-bounces@ietf.org] <b>On Behalf Of </b>luis nunez<br><b>Sent:<= /b> Thursday, August 11, 2011 3:09 PM<br><b>To:</b> tony@yaanatech.com<br><= b>Cc:</b> mile@ietf.org<br><b>Subject:</b> Re: [mile] draft on IODEF exsten= sion to support structured cybersecurity information<o:p></o:p></span></p><= /div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>fyi >= ; <strong>Proposed new work item - ITU-T X.cvrf, Common Vulnerability Repor= ting Framework</strong><b><br></b>posted to ITU.<br><br><a href=3D"http://w= ww.itu.int/md/T09-SG17-C-0538/en">http://www.itu.int/md/T09-SG17-C-0538/en<= /a><o:p></o:p></p><div><p class=3DMsoNormal><br>-ln<br><br>On Wed, Aug 10, = 2011 at 5:36 PM, Tony Rutkowski <<a href=3D"mailto:tony@yaanatech.com">t= ony@yaanatech.com</a>> wrote:<o:p></o:p></p><div><p class=3DMsoNormal>Hi= Inunez,<br><br>In the Q4/17 workplan we have X.cvrm identified as a "= CYBEX"<br>work item.  Do you think we can bring it into the upcom= ing meeting<br>in two weeks?  I'd be willing to work with the appropri= ate people<br>to make that happen.<br><span style=3D'color:#888888'><br>--t= ony</span><o:p></o:p></p><div><p class=3DMsoNormal><br><br>On 8/10/2011 4:2= 2 PM, lnunez wrote: <o:p></o:p></p><p class=3DMsoNormal style=3D'margin-bot= tom:12.0pt'><span style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if"'>I noticed CVRF mention briefly in this email thread (good I am thinkin= g the same). Looking at the draft-takahash-mile-sci-01.txt I see potential = synergies between the draft and CVRF.  <br><br>They both share some he= ritage.  Major vendors have indicated that they will start publishing = security advisories in the near future.  I could see this IODEF-extens= ion leveraging the CVRF content/components to provide additional fidelity t= o the security incident exchange.   <br><br>CVRF link:<br><a href=3D"h= ttp://www.icasi.org/cvrf" target=3D"_blank">http://www.icasi.org/cvrf</a><b= r>Redhat CVRF sample:<br><a href=3D"http://www.awe.com/mark/blog/20110518.h= tml" target=3D"_blank">http://www.awe.com/mark/blog/20110518.html</a><br><b= r>It would be interesting to see a CVRF advisory with OVAL checking content= as a mitigation method in this draft.</span><o:p></o:p></p><p class=3DMsoN= ormal><o:p> </o:p></p></div></div><p class=3DMsoNormal style=3D'margin= -bottom:12.0pt'><br>_______________________________________________<br>mile= mailing list<br><a href=3D"mailto:mile@ietf.org">mile@ietf.org</a><br><a h= ref=3D"https://www.ietf.org/mailman/listinfo/mile" target=3D"_blank">https:= //www.ietf.org/mailman/listinfo/mile</a><o:p></o:p></p></div><p class=3DMso= Normal><o:p> </o:p></p></div></body></html>= --_000_AE31510960917D478171C79369B660FA0E0552D3BFMX06Acorpemcc_-- From Kent_Landfield@mcafee.com Thu Aug 11 14:27:46 2011 Return-Path: <Kent_Landfield@mcafee.com> 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 61D3021F8B33 for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 14:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcTlUfjP+Qdc for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 14:27:45 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 7E83C21F8B0E for <mile@ietf.org>; Thu, 11 Aug 2011 14:27:45 -0700 (PDT) Received: from (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 6b48_7b31_d27e9666_c460_11e0_b5ca_00219b929abd; Thu, 11 Aug 2011 16:28:14 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Thu, 11 Aug 2011 16:26:39 -0500 From: <Kent_Landfield@McAfee.com> To: <kathleen.moriarty@emc.com>, <lnunez@c3isecurity.com>, <tony@yaanatech.com> Date: Thu, 11 Aug 2011 16:26:36 -0500 Thread-Topic: [mile] draft on IODEF exstension to support structured cybersecurity information Thread-Index: AcxYbVtFzhOAmjniRgWuNrLMdzq3cA== Message-ID: <CA69B2E0.1E2AF%kent_landfield@mcafee.com> In-Reply-To: <AE31510960917D478171C79369B660FA0E0552D3BF@MX06A.corp.emc.com> 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mile> List-Post: <mailto:mile@ietf.org> List-Help: <mailto:mile-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 11 Aug 2011 21:27:46 -0000 We are planning on supporting it for the publication of product vulnerabili= ties. I think this makes a lot of sense. Kent Landfield Director Content Strategy, Architecture and Standards McAfee, Inc. 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com<http://www.mcafee.com/> From: "kathleen.moriarty@emc.com<mailto:kathleen.moriarty@emc.com>" <kathle= en.moriarty@emc.com<mailto:kathleen.moriarty@emc.com>> Date: Thu, 11 Aug 2011 14:57:37 -0500 To: "lnunez@c3isecurity.com<mailto:lnunez@c3isecurity.com>" <lnunez@c3isecu= rity.com<mailto:lnunez@c3isecurity.com>>, "tony@yaanatech.com<mailto:tony@y= aanatech.com>" <tony@yaanatech.com<mailto:tony@yaanatech.com>> Cc: "mile@ietf.org<mailto:mile@ietf.org>" <mile@ietf.org<mailto:mile@ietf.o= rg>> Subject: Re: [mile] draft on IODEF exstension to support structured cyberse= curity information It looks like the ITU CYBEX model will incorporate CVRF from the vendors th= at manage the standard. This is a big indication that the SCAP extension t= o IODEF should include CVRF. Do folks agree or disagree with including this work as a reference? I thin= k it makes a lot of sense as vendors in the US are moving to support this m= odel. Best regards, Kathleen From: mile-bounces@ietf.org<mailto:mile-bounces@ietf.org> [mailto:mile-boun= ces@ietf.org] On Behalf Of luis nunez Sent: Thursday, August 11, 2011 3:09 PM To: tony@yaanatech.com<mailto:tony@yaanatech.com> Cc: mile@ietf.org<mailto:mile@ietf.org> Subject: Re: [mile] draft on IODEF exstension to support structured cyberse= curity information fyi > Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting= Framework posted to ITU. http://www.itu.int/md/T09-SG17-C-0538/en -ln On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski <tony@yaanatech.com<mailto:= tony@yaanatech.com>> wrote: Hi Inunez, In the Q4/17 workplan we have X.cvrm identified as a "CYBEX" work item. Do you think we can bring it into the upcoming meeting in two weeks? I'd be willing to work with the appropriate people to make that happen. --tony On 8/10/2011 4:22 PM, lnunez wrote: I noticed CVRF mention briefly in this email thread (good I am thinking the= same). Looking at the draft-takahash-mile-sci-01.txt I see potential syner= gies between the draft and CVRF. They both share some heritage. Major vendors have indicated that they will= start publishing security advisories in the near future. I could see this= IODEF-extension leveraging the CVRF content/components to provide addition= al fidelity to the security incident exchange. CVRF link: http://www.icasi.org/cvrf Redhat CVRF sample: http://www.awe.com/mark/blog/20110518.html It would be interesting to see a CVRF advisory with OVAL checking content a= s a mitigation method in this draft. _______________________________________________ mile mailing list mile@ietf.org<mailto:mile@ietf.org> https://www.ietf.org/mailman/listinfo/mile From ramartin@mitre.org Thu Aug 11 17:58:15 2011 Return-Path: <ramartin@mitre.org> 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 93C3A21F8B58 for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 17:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvGf1GD0G2fk for <mile@ietfa.amsl.com>; Thu, 11 Aug 2011 17:58:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 993E521F8B20 for <mile@ietf.org>; Thu, 11 Aug 2011 17:58:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E84421B1C78 for <mile@ietf.org>; Thu, 11 Aug 2011 20:58:50 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0A20D21B1C6F for <mile@ietf.org>; Thu, 11 Aug 2011 20:58:50 -0400 (EDT) Received: from bvb-172-31-36-81.mitre.org (172.31.36.81) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.192.1; Thu, 11 Aug 2011 20:58:49 -0400 Message-ID: <4E447ABE.6040508@mitre.org> Date: Thu, 11 Aug 2011 20:58:38 -0400 From: "Martin, Robert A." <ramartin@mitre.org> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mile@ietf.org References: <CA69B2E0.1E2AF%kent_landfield@mcafee.com> In-Reply-To: <CA69B2E0.1E2AF%kent_landfield@mcafee.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mile> List-Post: <mailto:mile@ietf.org> List-Help: <mailto:mile-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2011 00:58:15 -0000 As an organization that deals with lots of public vulnerability disclosures, MITRE's CVE team looks forward to more and more advisories taking up and utilizing the structured informatin that is covered in CVRF. We especially look forward to the CVRF advisories that will utilize as many of the structured fields as possible - especially CWE and CPE - where this refined insight on what the root cause of the vulnerability being reported is with CWE Ids and what versions are impacted by listing CPEs - both will help a great deal. We also look forward to the incorporation of OVAL into a future version of CVRF so that organizations will be able to quickly use the included OVAL definitions to review their deployed systems and immediately identify those that the advisory applies to. Regards, Bob On 8/11/11 5:26 PM, Kent_Landfield@McAfee.com wrote: > We are planning on supporting it for the publication of product vulnerabilities. I think this makes a lot of sense. > > Kent Landfield > Director Content Strategy, Architecture and Standards > > McAfee, Inc. > 5000 Headquarters Dr. > Plano, Texas 75024 > > Direct: +1.972.963.7096 > Mobile: +1.817.637.8026 > Web: www.mcafee.com<http://www.mcafee.com/> > > From: "kathleen.moriarty@emc.com<mailto:kathleen.moriarty@emc.com>"<kathleen.moriarty@emc.com<mailto:kathleen.moriarty@emc.com>> > Date: Thu, 11 Aug 2011 14:57:37 -0500 > To: "lnunez@c3isecurity.com<mailto:lnunez@c3isecurity.com>"<lnunez@c3isecurity.com<mailto:lnunez@c3isecurity.com>>, "tony@yaanatech.com<mailto:tony@yaanatech.com>"<tony@yaanatech.com<mailto:tony@yaanatech.com>> > Cc: "mile@ietf.org<mailto:mile@ietf.org>"<mile@ietf.org<mailto:mile@ietf.org>> > Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information > > It looks like the ITU CYBEX model will incorporate CVRF from the vendors that manage the standard. This is a big indication that the SCAP extension to IODEF should include CVRF. > > Do folks agree or disagree with including this work as a reference? I think it makes a lot of sense as vendors in the US are moving to support this model. > > Best regards, > Kathleen > > From: mile-bounces@ietf.org<mailto:mile-bounces@ietf.org> [mailto:mile-bounces@ietf.org] On Behalf Of luis nunez > Sent: Thursday, August 11, 2011 3:09 PM > To: tony@yaanatech.com<mailto:tony@yaanatech.com> > Cc: mile@ietf.org<mailto:mile@ietf.org> > Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information > > fyi> Proposed new work item - ITU-T X.cvrf, Common Vulnerability Reporting Framework > posted to ITU. > > http://www.itu.int/md/T09-SG17-C-0538/en > > -ln > > On Wed, Aug 10, 2011 at 5:36 PM, Tony Rutkowski<tony@yaanatech.com<mailto:tony@yaanatech.com>> wrote: > Hi Inunez, > > In the Q4/17 workplan we have X.cvrm identified as a "CYBEX" > work item. Do you think we can bring it into the upcoming meeting > in two weeks? I'd be willing to work with the appropriate people > to make that happen. > > --tony > > > On 8/10/2011 4:22 PM, lnunez wrote: > I noticed CVRF mention briefly in this email thread (good I am thinking the same). Looking at the draft-takahash-mile-sci-01.txt I see potential synergies between the draft and CVRF. > > They both share some heritage. Major vendors have indicated that they will start publishing security advisories in the near future. I could see this IODEF-extension leveraging the CVRF content/components to provide additional fidelity to the security incident exchange. > > CVRF link: > http://www.icasi.org/cvrf > Redhat CVRF sample: > http://www.awe.com/mark/blog/20110518.html > > It would be interesting to see a CVRF advisory with OVAL checking content as a mitigation method in this draft. > > > _______________________________________________ > mile mailing list > mile@ietf.org<mailto:mile@ietf.org> > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > . > From mark.menkhus@hp.com Fri Aug 12 05:20:04 2011 Return-Path: <mark.menkhus@hp.com> 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 B5DCF21F874A for <mile@ietfa.amsl.com>; Fri, 12 Aug 2011 05:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 H8VYQUSrq3Yu for <mile@ietfa.amsl.com>; Fri, 12 Aug 2011 05:19:59 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by ietfa.amsl.com (Postfix) with ESMTP id B717D21F8593 for <mile@ietf.org>; Fri, 12 Aug 2011 05:19:58 -0700 (PDT) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id E660A14080; Fri, 12 Aug 2011 12:20:34 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 12 Aug 2011 12:19:37 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Fri, 12 Aug 2011 13:19:37 +0100 From: "Menkhus, Mark (HAS GSE SSRT)" <mark.menkhus@hp.com> To: "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com>, "lnunez@cisco.com" <lnunez@cisco.com>, "takeshi_takahashi@nict.go.jp" <takeshi_takahashi@nict.go.jp>, "mile@ietf.org" <mile@ietf.org> Date: Fri, 12 Aug 2011 13:15:50 +0100 Thread-Topic: [mile] draft on IODEF exstension to support structured cybersecurity information Thread-Index: AcxWR2J9VNIFG703SAaz5tSdZ4c7ZgBU+i1yAArgbiAASIl8gA== Message-ID: <DDFFF4D8159CAA4881A60FDDAEA4E5482B5452F1EF@GVW0671EXC.americas.hpqcorp.net> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <CA6860E2.1E4BC%lnunez@cisco.com> <AE31510960917D478171C79369B660FA0E05486342@MX06A.corp.emc.com> In-Reply-To: <AE31510960917D478171C79369B660FA0E05486342@MX06A.corp.emc.com> 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_0751_01CC58B7.4824C310" MIME-Version: 1.0 Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mile> List-Post: <mailto:mile@ietf.org> List-Help: <mailto:mile-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 12 Aug 2011 12:20:04 -0000 ------=_NextPart_000_0751_01CC58B7.4824C310 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0752_01CC58B7.4824C310" ------=_NextPart_001_0752_01CC58B7.4824C310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, HP's security advisory team is not using CVRF, but I have followed CVRF for a while, and advocate it's use when we have an opportunity. I have not contributed other comments to mile, yet, but CVRF does bear consideration into the extension. Regards, Mark Menkhus CSSLP, ITIL v3 expert Hewlett Packard Software Security Response Team Team email: security-alert@hp.com From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Wednesday, August 10, 2011 7:54 PM To: lnunez@cisco.com; takeshi_takahashi@nict.go.jp; mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information Interesting questions, what do others think on this one? CVRF is a way of reporting out vulnerability information, tying together some of the SCAP standards for more complete information on a vulnerability. It could be a very good thing to be able to include in the extension. Is this something the community wants to see in the extension? Thanks, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of lnunez Sent: Wednesday, August 10, 2011 4:23 PM To: Takeshi Takahashi; mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information I noticed CVRF mention briefly in this email thread (good I am thinking the same). Looking at the draft-takahash-mile-sci-01.txt I see potential synergies between the draft and CVRF. They both share some heritage. Major vendors have indicated that they will start publishing security advisories in the near future. I could see this IODEF-extension leveraging the CVRF content/components to provide additional fidelity to the security incident exchange. CVRF link: http://www.icasi.org/cvrf Redhat CVRF sample: http://www.awe.com/mark/blog/20110518.html It would be interesting to see a CVRF advisory with OVAL checking content as a mitigation method in this draft. One thing to keep in mind is to realized how we can build and used the various emerging set of standards in a cohesive way. thanks. On 8/8/11 11:49 PM, "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> wrote: Thank you for those of you who kindly gave me off-line messages . Let me share the draft with some minor modifications. Sincerely, Take 2011/8/5 Takeshi Takahashi <takeshi_takahashi@nict.go.jp>: > Dear all, > > > > The attached is the tentative version of the draft prepared based on the > comments I've received in this mailing list (Thanks a lot for that). > > It would be great if you could provide some comments on Clause 4, where the > IODEF extension is defined. > > > > As you know, there are many ways to embed structured information (e.g. CVE > and CAPEC) in IODEF since IODEF is designed to be very flexible. > > Thus, I would be happy to change and develop the draft further based on your > comments. > > > > I would like to welcome any comments on that. > > > > By the way, I will be on vacation, thus my response might be slow, sorry for > the inconvenience. > > > > Take > > > > PS: I've changed the title of the email. > > > > > > 2011/7/29 <kathleen.moriarty@emc.com> > >> > >> Thank you, the approach sounds good, especially since it is in use today > >> by at least the Research and Education ISAC. Do others have opinions on > >> the proposal here? > >> > >> Thanks for writing the first draft Take! > >> > >> Best regards, > >> Kathleen > >> ________________________________________ > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Takeshi > >> Takahashi [takeshi_takahashi@nict.go.jp] > >> Sent: Friday, July 29, 2011 9:20 AM > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> Thank you, Bob, for the email. > >> I also like Tom's suggestion very much. > >> Let me work on the "draft" of the draft for a while, then come back to you > >> later. > >> > >> Take > >> > >> -----Original Message----- > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >> Sent: Friday, July 29, 2011 9:10 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >> wes@ren-isac.net; mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >> > >> I also like how this is evolving. > >> > >> I think, as Tom's suggestions pointed, that any and all of the useful > >> types > >> of information that can help with understanding, diagnosing, and getting > >> ahead of an incident should be added but for now we should focus on those > >> the most established and well articulated. > >> > >> This can be the compliance/patch/configuration/platform information > >> related > >> to the SCAP use case, or event signature/attack pattern/traffic > >> characteristics from events, or the vulnerability/threat characterization > >> space. > >> > >> I look forward to Taki's draft to see how he suggests positioning these > >> concepts. > >> > >> Bob > >> > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >> > I like where this is headed. > >> > > >> > Thanks Takeshi. I look forward to your draft. It will give us something > >> real to discuss. I appreciate you jumping in and getting this started. > >> > > >> > One question that I am not clear on. What do we envision as the actual > >> set > >> of deliverables? From and SCAP related perspective, are we looking at a > >> single draft covering all the extensions? > >> > > >> > Kent > >> > > >> > Kent Landfield > >> > Director Content Strategy, Architecture and Standards > >> > > >> > McAfee, Inc. > >> > 5000 Headquarters Dr. > >> > Plano, Texas 75024 > >> > > >> > Direct: +1.972.963.7096 > >> > Mobile: +1.817.637.8026 > >> > Web: www.mcafee.com<http://www.mcafee.com/> > >> > > >> > From: Takeshi > >> > Takahashi<takeshi_takahashi@nict.go.jp<mailto:takeshi_takahashi@nict.g > >> > o.jp>> > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > >> > To: > >> > "Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>"<Thomas.M > >> > illar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov>>, > >> > "wes@ren-isac.net<mailto:wes@ren-isac.net>"<wes@ren-isac.net<mailto:we > >> > s@ren-isac.net>>, > >> > "mile@ietf.org<mailto:mile@ietf.org>"<mile@ietf.org<mailto:mile@ietf.o > >> > rg>> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > Thank you for the email, Tom. > >> > > >> > So, here is what the draft needs to describe (if I understand Wes and > >> > Tom correctly). > >> > > >> > The draft should define ext-dtype (an attribute of AdditionalData > >> > Class) to identify the information type, rather than defining new > >> > class under AdditionalData. > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec, > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal and > >> > could easily embed various structured information (CVE etc.) in the > >> > EventData.Record.RecordData.AdditionalData field. > >> > Then "should" statement should be carefully placed in the text of > >> > relevant class. > >> > > >> > I'll prepare some draft so that we could discuss and advance further. > >> > > >> > Take > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org<mailto:mile-bounces@ietf.org> > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > >> > Thomas.Millar@us-cert.gov<mailto:Thomas.Millar@us-cert.gov> > >> > Sent: Thursday, July 28, 2011 6:28 PM > >> > To: wes@ren-isac.net<mailto:wes@ren-isac.net>; > >> > mile@ietf.org<mailto:mile@ietf.org> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > I think this approach makes more sense. One of the things I think > >> > could be helpful is to have a number of SHOULD statements further > >> > describing the possible types of other documents that would be > >> > expected to ride under the AdditionalData elements of each class (not > >> just > >> EventData). > >> > What I'm thinking of looks like this (very unpolished): > >> > > >> > "The Method Class:AdditionalData class SHOULD contain data elements > >> > that describe the methods, tools or techniques employed to cause the > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the > >> > method such as CVSS, CWSS, or CCE." > >> > > >> > "The Expectation Class[...] SHOULD contain data elements which > >> > describe configuration changes, detection heuristics, or [* (legal > >> > authorization?)] to assist in executing or implementing the requested > >> > action, such as XCCDF, OCIL, OVAL, etc" > >> > > >> > This could go towards encouraging better or at least more consistent > >> > use of "boundary objects" in the substance of incident reports. I > >> > could also go on about greater automation and such but that's probably > >> > out of scope for this e-mail. > >> > > >> > > >> > - Tom Millar, US-CERT > >> > > >> > thomas.millar@us-cert.gov<mailto:thomas.millar@us-cert.gov> > >> > BB: thomas.millar@dhs.gov<mailto:thomas.millar@dhs.gov> / > >> > 202-631-1915 > >> > 24x7: soc@us-cert.gov<mailto:soc@us-cert.gov> / 888-282-0870 > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org<mailto:mile-bounces@ietf.org> > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >> > Sent: Thursday, July 28, 2011 11:08 AM > >> > To: mile@ietf.org<mailto:mile@ietf.org> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >> > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > >> > > >> > i've been sticking other "XML like" records under this (icsg1.1 data, > >> > etc...). > >> > > >> > pretty easy to do, just generate the "other standards" xml (or json or > >> > whatever), embed it there. turns iodef into a sharing platform for > >> > other data-types w/o having to extend it too much. > >> > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >> > > >> > So, maybe we could extend the IODEF as described in Figure 1 of the > >> > attached txt file. (correct me if I'm wrong) We could define > >> > Incident.EventData.AdditionalData elements and describe them by using > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >> > Regarding OVAL, we might define Incident.AdditionalData element, but I > >> > > >> > am not sure at this moment, thus is not described in the figure yet. > >> > I would like to tackle CAPEC first since I believe Kent would like to > >> > tackle CVE and CAPEC. > >> > > >> > -- > >> > Wes > >> > claimid.com/wesyoung > >> > soc@ren-isac.net<mailto:soc@ren-isac.net> > >> > > >> > * Wes Young<wes@ren-isac.net<mailto:wes@ren-isac.net>> > >> > * 0xDDB6E946 - Unverified(L) > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org<mailto:mile@ietf.org> > >> > https://www.ietf.org/mailman/listinfo/mile > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org<mailto:mile@ietf.org> > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org<mailto:mile@ietf.org> > >> > https://www.ietf.org/mailman/listinfo/mile > >> > > >> > _______________________________________________ > >> > mile mailing list > >> > mile@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mile > >> > . > >> > > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > ------=_NextPart_001_0752_01CC58B7.4824C310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" = xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" = xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" = xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" = xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"= xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" = xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" = xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" = xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig= nature" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi= ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= = xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag= es" = xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/= " = xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub= lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" = xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 = (filtered medium)"><title>Re: [mile] draft on IODEF exstension to = support structured cybersecurity information

Hi,

 

HP’s security advisory team is not using CVRF, but I have = followed CVRF for a while, and advocate it’s use when we have an = opportunity.

 

I have not contributed other comments to mile, yet, but CVRF does = bear consideration into the extension.

 

Regards,

Mark Menkhus CSSLP, ITIL v3 expert

Hewlett Packard Software Security Response Team
Team email: = security-alert@hp.com

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = kathleen.moriarty@emc.com
Sent: Wednesday, August 10, 2011 = 7:54 PM
To: lnunez@cisco.com; takeshi_takahashi@nict.go.jp; = mile@ietf.org
Subject: Re: [mile] draft on IODEF exstension to = support structured cybersecurity = information

 

 

Interesting questions, what do others think on this one?  =

 

CVRF is a way of reporting out vulnerability information, tying = together some of the SCAP standards for more complete information on a = vulnerability.  It could be a very good thing to be able to include = in the extension.  Is this something the community wants to see in = the extension?

 

Thanks,

Kathleen

 

From:= = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = lnunez
Sent: Wednesday, August 10, 2011 4:23 = PM
To: Takeshi Takahashi; mile@ietf.org
Subject: Re: = [mile] draft on IODEF exstension to support structured cybersecurity = information

 

I noticed = CVRF mention briefly in this email thread (good I am thinking the same). = Looking at the draft-takahash-mile-sci-01.txt I see potential synergies = between the draft and CVRF. 

They both share some = heritage.  Major vendors have indicated that they will start = publishing security advisories in the near future.  I could see = this IODEF-extension leveraging the CVRF content/components to provide = additional fidelity to the security incident exchange.   =

CVRF link:
http://www.icasi.org/cvrf
Redha= t CVRF sample:
http://www.awe.com/ma= rk/blog/20110518.html

It would be interesting to see a CVRF = advisory with OVAL checking content as a mitigation method in this = draft.

One thing to keep in mind is to realized how we can build = and used the various emerging set of standards in a cohesive way. =

thanks.


On 8/8/11 11:49 PM, "Takeshi = Takahashi" <takeshi_takahashi@nict.go.jp>= ; wrote:

Thank you = for those of you who kindly gave me off-line messages .
 
Let = me share the draft with some minor = modifications.
 
Sincerely,
Take
 
 
201= 1/8/5 Takeshi Takahashi <takeshi_takahashi@nict.go.jp>= ;:
> Dear all,
>
>  
>
> The = attached is the tentative version of the draft prepared based on = the
> comments I’ve received in this mailing list (Thanks a = lot for that).
>
> It would be great if you could provide = some comments on Clause 4, where the
> IODEF extension is = defined.
>
>  
>
> As you know, there are = many ways to embed structured information (e.g. CVE
> and CAPEC) = in IODEF since IODEF is designed to be very flexible.
>
> = Thus, I would be happy to change and develop the draft further based on = your
> comments.
>
>  
>
> I would = like to welcome any comments on that.
>
>  
> =
> By the way, I will be on vacation, thus my response might be = slow, sorry for
> the inconvenience.
>
> =  
>
> Take
>
>  
>
> = PS: I’ve changed the title of the email.
>
> =  
>
>  
>
> 2011/7/29 <kathleen.moriarty@emc.com>
&= gt;
>>
>
>> Thank you, the approach sounds = good, especially since it is in use today
>
>> by at = least the Research and Education ISAC.  Do others have opinions = on
>
>> the proposal here?
>
>>
> =
>> Thanks for writing the first draft Take!
> =
>>
>
>> Best regards,
>
>> = Kathleen
>
>> = ________________________________________
>
>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Takeshi
>
>> Takahashi [takeshi_takahashi@nict.go.jp]>
>> Sent: Friday, July 29, 2011 9:20 AM
> =
>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com
> =
>> Cc: mile@ietf.org
> =
>> Subject: Re: [mile] Updated presentation from Side = meeting
>
>>
>
>> Thank you, Bob, for = the email.
>
>> I also like Tom's suggestion very = much.
>
>> Let me work on the "draft" of the = draft for a while, then come back to you
>
>> = later.
>
>>
>
>> Take
> =
>>
>
>> -----Original Message-----
> =
>> From: Martin, Robert A. [mailto:ramartin@mitre.org]
>=
>> Sent: Friday, July 29, 2011 9:10 AM
>
>> = To: Kent_Landfield@McAfee.com
> =
>> Cc: takeshi_takahashi@nict.go.jp; = Thomas.Millar@us-cert.gov;
>=
>> wes@ren-isac.net; mile@ietf.org
>
>> Subject: = Re: [mile] Updated presentation from Side meeting
>
>> =
>
>> I also like how this is evolving.
> =
>>
>
>> I think, as Tom's suggestions = pointed, that any and all of the useful
>
>> = types
>
>> of information that can help with = understanding, diagnosing, and getting
>
>> ahead of an = incident should be added but for now we should focus on those
> =
>> the most established and well articulated.
> =
>>
>
>> This can be the = compliance/patch/configuration/platform information
>
>> = related
>
>> to the SCAP use case, or event = signature/attack pattern/traffic
>
>> characteristics = from events, or the vulnerability/threat characterization
> =
>> space.
>
>>
>
>> I look = forward to Taki's draft to see how he suggests positioning these
> =
>> concepts.
>
>>
>
>> = Bob
>
>>
>
>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com = wrote:
>
>> > I like where this is headed.
> =
>> >
>
>> > Thanks Takeshi.  I look = forward to your draft. It will give us something
>
>> = real to discuss. I appreciate you jumping in and getting this = started.
>
>> >
>
>> > One = question that I am not clear on. What do we envision as the = actual
>
>> set
>
>> of deliverables? =  From and SCAP related perspective, are we looking at a
> =
>> single draft covering all the extensions?
> =
>> >
>
>> > Kent
>
>> = >
>
>> > Kent Landfield
>
>> > = Director Content Strategy, Architecture and Standards
> =
>> >
>
>> > McAfee, Inc.
> =
>> > 5000 Headquarters Dr.
>
>> > Plano, = Texas 75024
>
>> >
>
>> > Direct: = +1.972.963.7096
>
>> > Mobile: = +1.817.637.8026
>
>> > Web: www.mcafee.com<http://www.mcafee.com/>
> =
>> >
>
>> > From: Takeshi
> =
>> > Takahashi<takeshi_= takahashi@nict.go.jp<mailto:takeshi_takahashi@nict.g
> =
>> > o.jp>>
>
>> > Date: Thu, 28 = Jul 2011 18:21:56 -0500
>
>> > To:
> =
>> > "Thomas.Millar@u= s-cert.gov<mailto:Thomas.Millar@us-cert.gov>"<Thomas.M<= br>>
>> > illar@us-cert.gov<ma= ilto:Thomas.Millar@us-cert.gov>>,
>
>> > = "wes@ren-isac.net<mailto:wes= @ren-isac.net>"<wes@ren-isac.net<mailto:we>
>> > s@ren-isac.net>>,
> =
>> > "mile@ietf.org<mailto:mile@iet= f.org>"<mile@ietf.org<mailto:mile@iet= f.o
>
>> > rg>>
>
>> > = Subject: Re: [mile] Updated presentation from Side meeting
> =
>> >
>
>> > Thank you for the email, = Tom.
>
>> >
>
>> > So, here is = what the draft needs to describe (if I understand Wes and
> =
>> > Tom correctly).
>
>> >
> =
>> > The draft should define ext-dtype (an attribute of = AdditionalData
>
>> > Class) to identify the = information type, rather than defining new
>
>> > = class under AdditionalData.
>
>> > Ext-dtype: = ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec,
> =
>> > ext-cvss, ext-cwss, In this way, we could keep the = change minimal and
>
>> > could easily embed various = structured information (CVE etc.) in the
>
>> > = EventData.Record.RecordData.AdditionalData field.
>
>> = > Then "should" statement should be carefully placed in the = text of
>
>> > relevant class.
>
>> = >
>
>> > I'll prepare some draft so that we could = discuss and advance further.
>
>> >
> =
>> > Take
>
>> >
>
>> = >
>
>> >
>
>> > -----Original = Message-----
>
>> > From: mile-bounces@ietf.or= g<mailto:mile-bounces@ietf.org>
>
>> > [mailto:mile-bounces@ietf.org] = On Behalf Of
>
>> > Thomas.Millar@u= s-cert.gov<mailto:Thomas.Millar@us-cert.gov>
> =
>> > Sent: Thursday, July 28, 2011 6:28 PM
> =
>> > To: wes@ren-isac.net<mailto:wes= @ren-isac.net>;
>
>> > mile@ietf.org<mailto:mile@iet= f.org>
>
>> > Subject: Re: [mile] Updated = presentation from Side meeting
>
>> >
> =
>> > I think this approach makes more sense. One of the = things I think
>
>> > could be helpful is to have a = number of SHOULD statements further
>
>> > describing = the possible types of other documents that would be
>
>> = > expected to ride under the AdditionalData elements of each class = (not
>
>> just
>
>> EventData).
> =
>> > What I'm thinking of looks like this (very = unpolished):
>
>> >
>
>> > = "The Method Class:AdditionalData class SHOULD contain data = elements
>
>> > that describe the methods, tools or = techniques employed to cause the
>
>> > incident, = such as CAPEC, CWE, CVE, CVRF, or metadata concerning the
> =
>> > method such as CVSS, CWSS, or CCE."
> =
>> >
>
>> > "The Expectation = Class[...] SHOULD contain data elements which
>
>> > = describe configuration changes, detection heuristics, or [* = (legal
>
>> > authorization?)] to assist in executing = or implementing the requested
>
>> > action, such as = XCCDF, OCIL, OVAL, etc"
>
>> >
> =
>> > This could go towards encouraging better or at least = more consistent
>
>> > use of "boundary = objects" in the substance of incident reports. I
> =
>> > could also go on about greater automation and such but = that's probably
>
>> > out of scope for this = e-mail.
>
>> >
>
>> >
> =
>> > - Tom Millar, US-CERT
>
>> = >
>
>> > thomas.millar@u= s-cert.gov<mailto:thomas.millar@us-cert.gov>
> =
>> > BB: thomas.millar@dhs.g= ov<mailto:thomas.millar@dhs.gov>  /
>
>> = > 202-631-1915
>
>> > 24x7: soc@us-cert.gov<mailto:soc@u= s-cert.gov>  / 888-282-0870
>
>> > = -----Original Message-----
>
>> > From: mile-bounces@ietf.or= g<mailto:mile-bounces@ietf.org>
>
>> > [mailto:mile-bounces@ietf.org] = On Behalf Of Wes Young
>
>> > Sent: Thursday, July = 28, 2011 11:08 AM
>
>> > To: mile@ietf.org<mailto:mile@iet= f.org>
>
>> > Subject: Re: [mile] Updated = presentation from Side meeting
>
>> >
> =
>> > * PGP Signed by an unverified key: 7/28/2011 at = 11:08:06 AM
>
>> >
>
>> > http://tools.iet= f.org/html/rfc5070#section-3.19
>
>> >
> =
>> > i've been sticking other "XML like" records = under this (icsg1.1 data,
>
>> > etc...).
> =
>> >
>
>> > pretty easy to do, just = generate the "other standards" xml (or json or
> =
>> > whatever), embed it there. turns iodef into a sharing = platform for
>
>> > other data-types w/o having to = extend it too much.
>
>> >
>
>> > = On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote:
> =
>> >
>
>> > So, maybe we could extend = the IODEF as described in Figure 1 of the
>
>> > = attached txt file. (correct me if I'm wrong) We could define
> =
>> > Incident.EventData.AdditionalData elements and = describe them by using
>
>> > CPE, CVE/CWE, = CVSS/CWSS, and CAPEC.
>
>> > Regarding OVAL, we might = define Incident.AdditionalData element, but I
>
>> = >
>
>> > am not sure at this moment, thus is not = described in the figure yet.
>
>> > I would like to = tackle CAPEC first since I believe Kent would like to
> =
>> > tackle CVE and CAPEC.
>
>> = >
>
>> > --
>
>> > Wes
> =
>> > claimid.com/wesyoung
>
>> > soc@ren-isac.net<mailto:soc= @ren-isac.net>
>
>> >
>
>> > * = Wes Young<wes@ren-isac.net<mailto:wes= @ren-isac.net>>
>
>> > * 0xDDB6E946 - = Unverified(L)
>
>> > = _______________________________________________
>
>> = > mile mailing list
>
>> > mile@ietf.org<mailto:mile@iet= f.org>
>
>> > https://www.ietf.org/= mailman/listinfo/mile
>
>> > = _______________________________________________
>
>> = > mile mailing list
>
>> > mile@ietf.org<mailto:mile@iet= f.org>
>
>> > https://www.ietf.org/= mailman/listinfo/mile
>
>> >
>
>> = > _______________________________________________
> =
>> > mile mailing list
>
>> > mile@ietf.org<mailto:mile@iet= f.org>
>
>> > https://www.ietf.org/= mailman/listinfo/mile
>
>> >
>
>> = > _______________________________________________
> =
>> > mile mailing list
>
>> > mile@ietf.org
>
>> > https://www.ietf.org/= mailman/listinfo/mile
>
>> > .
> =
>> >
>
>>
>
>> = _______________________________________________
>
>> = mile mailing list
>
>> mile@ietf.org
>
>> https://www.ietf.org/= mailman/listinfo/mile
>
>  
>
> =  
>
> =  
 
 
 

------=_NextPart_001_0752_01CC58B7.4824C310-- ------=_NextPart_000_0751_01CC58B7.4824C310 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOIzCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBvQqB17HZvz9ukd2Bg kNv5MA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0xNDA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAZF1+ k3S4yRGkCOopCB1hFViFZVGqmE+OiuRqKmBqQK/UnsMYFY2lhLQLlnd+VnzBK2+GE9OusVJxpBGc stm44i+bgPVkxbcg7Ho14wrIF+qx2m3M5beSveZewzAZZCvp4hjqenpDzef9qDDCl/e+sFeEPRzr phlEpxYBWYTxH7swggbvMIIGWKADAgECAhBgn50iI46lPPZ6vaW/Z0EoMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xMDA2MDQwMDAwMDBaFw0xMjA2MDMyMzU5NTlaMIGWMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEVMBMGA1UEAxMMTWFyayBNZW5raHVzMSIwIAYJKoZIhvcNAQkBFhNtYXJr Lm1lbmtodXNAaHAuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAEUGtRL07V5oUoxm+ Vc8Q1MoiyHohmgH68o/mGR3wwBbWPl3ZuKrfNRW/eQtOdAKKLBEaf1jGlF4wgPYwU9VtDFHtzsHE t5AEHjXz8uv+sg3jah+3XQW4EFeSOFaNAyv/WiOYqgybDaSAujxrj45ulkwdM0qGUABdXkIqljmq sQIDAQABo4ID7jCCA+owUwYDVR0RBEwwSoETbWFyay5tZW5raHVzQGhwLmNvbYEObWVua2h1c0Bo cC5jb22BCm1kbUBocC5jb22BF21lbmtodXNAb3NuLmN4by5kZWMuY29tMAwGA1UdEwEB/wQCMAAw DgYDVR0PAQH/BAQDAgWgMB8GA1UdIwQYMBaAFO/tIM1DRR+DR2AVlkNySuTGzOc9MB0GA1UdDgQW BBTN/cXHtRGssP0QNkodehuoxOPQOzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vb25zaXRlY3Js LnZlcmlzaWduLmNvbS9IZXdsZXR0UGFja2FyZENvbXBhbnlTTUlNRS9MYXRlc3RDUkwuY3JsMBYG A1UdJQEB/wQMMAoGCCsGAQUFBwMEMIIBPgYDVR0gBIIBNTCCATAwggEsBgtghkgBhvhFAQcXAjCC ARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwIC MIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBI UCBkb2VzIG5vdCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0 aWZpY2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJp U2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu CjCCATMGCCsGAQUFBwEBBIIBJTCCASEwKwYIKwYBBQUHMAGGH2h0dHA6Ly9vbnNpdGUtb2NzcC52 ZXJpc2lnbi5jb20wgfEGCCsGAQUFBzACpIHkMIHhMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhKGMpMDExHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNV BAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcN AQEFBQADgYEAUxB702W/AUXYo8gRXkbMzkloRzA+jWK3g7HIO2KQB/TosjxySnthDg2fcSaCY/GY QUe8/pjBfGiFxlrKWY7X47GZHMJRiYMUGBUAkAVpeHF8UJhCIg8Azy27YxpeXAqDKYaXQzWIvq4S P+yLM5Ue9bEy+RIC8zOPystYornKi2cxggTTMIIEzwIBATCB9zCB4jEgMB4GA1UEChMXSGV3bGV0 dC1QYWNrYXJkIENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNV BAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAxMTAw LgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExLjAsBgNVBAMT JUNvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEGCfnSIjjqU89nq9pb9nQSgw CQYFKw4DAhoFAKCCAzEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwODEyMTIxNTQ5WjAjBgkqhkiG9w0BCQQxFgQU4OrGwYkFM0d706j7MpuMtgjEa4cwgbcGCSqG SIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCG SAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYI KoZIhvcNAgUwggEIBgkrBgEEAYI3EAQxgfowgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2Fy ZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMn Q2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AhBgn50iI46lPPZ6vaW/Z0EoMIIBCgYLKoZI hvcNAQkQAgsxgfqggfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUg SW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5AhBgn50iI46lPPZ6vaW/Z0EoMA0GCSqGSIb3DQEBAQUABIGAS9AXY/bb eo6Q8SYwW0/A1I5+nwtyz1R7vl5IePrA/aBNoqFvos9jcjsINhlqiQeziVE7zds1j99qgTWVv2Kh 2SEdDsjPvqF8v0nwlcCrQuY0aPquRCvRxEIBM7KvCG+TGXMOiak3zIgJQ4UQC6GbXfdmjp7Js/CY /fKM3Zf3ANYAAAAAAAA= ------=_NextPart_000_0751_01CC58B7.4824C310-- From takeshi_takahashi@nict.go.jp Sun Aug 14 06:24:17 2011 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 DE1D621F89BA for ; Sun, 14 Aug 2011 06:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=0.423, 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 6wqbGWqIIPVT for ; Sun, 14 Aug 2011 06:24:16 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 583B921F87C9 for ; Sun, 14 Aug 2011 06:24:15 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id p7EDOr8V005776; Sun, 14 Aug 2011 22:24:53 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id p7EDOrSG009268; Sun, 14 Aug 2011 22:24:53 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id p7EDOh8U009265; Sun, 14 Aug 2011 22:24:44 +0900 (JST) From: "Takeshi Takahashi" To: , References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> Date: Sun, 14 Aug 2011 22:25:00 +0900 Message-ID: <006501cc5a85$920bd160$b6237420$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHZoScn83GYsZh9CRcfWQQM2pwT0QIjvf2BlPAdjlA= Content-Language: ja Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 14 Aug 2011 13:24:18 -0000 Hi David, Thank you for your kind comments. I agree, I'll change the element class name. Regarding the issues you kindly raised in the email, let me describe my understanding. 1) My assumption was, when parsing the xml data, the parser anyway reads = the namespace described in the embedded xml data and parse the data. But I agree, it would be better to limit the description of SpecificationName. Maybe we could use ENUM (instead of ML_STRING), and enumerate possible specifications. For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use ENUM = for dtype and FraudType description. Like the same way, the SpecificationName could use ENUM for describing specifications, though we do not have that much specifications to = enumerate at this moment. 2) I am not sure whether it is easier for information sender and receiver = to send/receive partial CVE data. Maybe it would be easier for them to embed/receive/parse a complete CVE data? If we send a partial CVE or the other structured data, receiver may = suffer from some parsing problem, as you mentioned. So, my assumption here is that a complete CVE (compatible with its = schema) will be embedded here. 3) Maybe some text in the draft has caused mis-understanding. Yes, the latest version of the XCCDF schema is 1.6. I intended to say that the number of the version element is zero or one. Most of specifications such as XCCDF etc. have versions while CVE does = not. Thus the number of this element class is ZERO or ONE. Above are my viewpoint, but I might be wrong. Let me develop the draft based on your kind comments after my vacation. Please correct me if I am wrong, I would like to welcome feedbacks. Thank you. Take From: david.black@emc.com [mailto:david.black@emc.com]=20 Sent: Wednesday, August 10, 2011 8:45 AM To: takeshi_takahashi@nict.go.jp; mile@ietf.org Cc: david.black@emc.com Subject: RE: [mile] draft on IODEF exstension to support structured cybersecurity information Hi Take, For clarity I=92d suggest not using =93Version=94 as the name of both an = extension attribute and one of the classes in each extension.=A0 Renaming the = class to SpecificationVersion would be clearer (so Version is the attribute with = the version of the extension). I also have a few questions: (1) What strings are valid for SpecificationName?=A0 If the recipient = doesn=92t understand the SpecificationName, the information in the extension may = be unparseable, so this probably needs to be controlled. An IANA registry may be appropriate to list the valid strings and = associate each string with its corresponding specification. (2) How does one determine the format for information formatted = according to an external specification? For example, I believe that the XSD schema for the CVE list defines a complete XML document, but I suspect that less than a complete XML = document is intended to be embedded because the proposed extension is part of an IODEF XML document. (3) Why is the [Specification]Version limited to zero or one? For example, CAPEC is currently at Release 1.6. 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 ---------------------------------------------------- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Takeshi Takahashi Sent: Monday, August 08, 2011 11:50 PM To: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information Thank you for those of you who kindly gave me off-line messages . Let me share the draft with some minor modifications. Sincerely, Take 2011/8/5 Takeshi Takahashi : > Dear all, > >=A0=20 > > The attached is the tentative version of the draft prepared based on = the > comments I=92ve received in this mailing list (Thanks a lot for that). > > It would be great if you could provide some comments on Clause 4, = where the > IODEF extension is defined. > >=A0=20 > > As you know, there are many ways to embed structured information (e.g. = CVE > and CAPEC) in IODEF since IODEF is designed to be very flexible. > > Thus, I would be happy to change and develop the draft further based = on your > comments. > >=A0=20 > > I would like to welcome any comments on that. > >=A0=20 > > By the way, I will be on vacation, thus my response might be slow, = sorry for > the inconvenience. > >=A0=20 > > Take > >=A0=20 > > PS: I=92ve changed the title of the email. > >=A0=20 > >=A0=20 > > 2011/7/29 > >>=20 > >> Thank you, the approach sounds good, especially since it is in use = today > >> by at least the Research and Education ISAC.=A0 Do others have = opinions on > >> the proposal here? > >>=20 > >> Thanks for writing the first draft Take! > >>=20 > >> Best regards, > >> Kathleen > >> ________________________________________ > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Takeshi > >> Takahashi [takeshi_takahashi@nict.go.jp] > >> Sent: Friday, July 29, 2011 9:20 AM > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >> Cc: mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >>=20 > >> Thank you, Bob, for the email. > >> I also like Tom's suggestion very much. > >> Let me work on the "draft" of the draft for a while, then come back = to you > >> later. > >>=20 > >> Take > >>=20 > >> -----Original Message----- > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >> Sent: Friday, July 29, 2011 9:10 AM > >> To: Kent_Landfield@McAfee.com > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >> wes@ren-isac.net; mile@ietf.org > >> Subject: Re: [mile] Updated presentation from Side meeting > >>=20 > >> I also like how this is evolving. > >>=20 > >> I think, as Tom's suggestions pointed, that any and all of the useful > >> types > >> of information that can help with understanding, diagnosing, and = getting > >> ahead of an incident should be added but for now we should focus on = those > >> the most established and well articulated. > >>=20 > >> This can be the compliance/patch/configuration/platform information > >> related > >> to the SCAP use case, or event signature/attack pattern/traffic > >> characteristics from events, or the vulnerability/threat = characterization > >> space. > >>=20 > >> I look forward to Taki's draft to see how he suggests positioning = these > >> concepts. > >>=20 > >> Bob > >>=20 > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >> > I like where this is headed. > >> > > >> > Thanks Takeshi.=A0 I look forward to your draft. It will give us something > >> real to discuss. I appreciate you jumping in and getting this = started. > >> > > >> > One question that I am not clear on. What do we envision as the = actual > >> set > >> of deliverables?=A0 From and SCAP related perspective, are we looking = at a > >> single draft covering all the extensions? > >> > > >> > Kent > >> > > >> > Kent Landfield > >> > Director Content Strategy, Architecture and Standards > >> > > >> > McAfee, Inc. > >> > 5000 Headquarters Dr. > >> > Plano, Texas 75024 > >> > > >> > Direct: +1.972.963.7096 > >> > Mobile: +1.817.637.8026 > >> > Web: www.mcafee.com > >> > > >> > From: Takeshi > >> > = Takahashi >> > o.jp>> > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > >> > To: > >> > = "Thomas.Millar@us-cert.gov" >> > illar@us-cert.gov>, > >> > = "wes@ren-isac.net" >> > s@ren-isac.net>>, > >> > = "mile@ietf.org" >> > rg>> > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > Thank you for the email, Tom. > >> > > >> > So, here is what the draft needs to describe (if I understand Wes = and > >> > Tom correctly). > >> > > >> > The draft should define ext-dtype (an attribute of AdditionalData > >> > Class) to identify the information type, rather than defining new > >> > class under AdditionalData. > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, = ext-capec, > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal = and > >> > could easily embed various structured information (CVE etc.) in the > >> > EventData.Record.RecordData.AdditionalData field. > >> > Then "should" statement should be carefully placed in the text of > >> > relevant class. > >> > > >> > I'll prepare some draft so that we could discuss and advance = further. > >> > > >> > Take > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > >> > Thomas.Millar@us-cert.gov > >> > Sent: Thursday, July 28, 2011 6:28 PM > >> > To: wes@ren-isac.net; > >> > mile@ietf.org > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > I think this approach makes more sense. One of the things I think > >> > could be helpful is to have a number of SHOULD statements further > >> > describing the possible types of other documents that would be > >> > expected to ride under the AdditionalData elements of each class = (not > >> just > >> EventData). > >> > What I'm thinking of looks like this (very unpolished): > >> > > >> > "The Method Class:AdditionalData class SHOULD contain data elements > >> > that describe the methods, tools or techniques employed to cause = the > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the > >> > method such as CVSS, CWSS, or CCE." > >> > > >> > "The Expectation Class[...] SHOULD contain data elements which > >> > describe configuration changes, detection heuristics, or [* (legal > >> > authorization?)] to assist in executing or implementing the = requested > >> > action, such as XCCDF, OCIL, OVAL, etc" > >> > > >> > This could go towards encouraging better or at least more = consistent > >> > use of "boundary objects" in the substance of incident reports. I > >> > could also go on about greater automation and such but that's = probably > >> > out of scope for this e-mail. > >> > > >> > > >> > - Tom Millar, US-CERT > >> > > >> > thomas.millar@us-cert.gov > >> > BB: thomas.millar@dhs.gov=A0 / > >> > 202-631-1915 > >> > 24x7: soc@us-cert.gov=A0 / 888-282-0870 > >> > -----Original Message----- > >> > From: mile-bounces@ietf.org > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >> > Sent: Thursday, July 28, 2011 11:08 AM > >> > To: mile@ietf.org > >> > Subject: Re: [mile] Updated presentation from Side meeting > >> > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >> > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > >> > > >> > i've been sticking other "XML like" records under this (icsg1.1 = data, > >> > etc...). > >> > > >> > pretty easy to do, just generate the "other standards" xml (or json = or > >> > whatever), embed it there. turns iodef into a sharing platform for > >> > other data-types w/o having to extend it too much. > >> > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >> > > >> > So, maybe we could extend the IODEF as described in Figure 1 of the > >> > attached txt file. (correct me if I'm wrong) We could define > >> > Incident.EventData.AdditionalData elements and describe them by = using > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >> > Regarding OVAL, we might define Incident.AdditionalData element, = but I > >> > > >> > am not sure at this moment, thus is not described in the figure = yet. > >> > I would like to tackle CAPEC first since I believe Kent would like = to > >> > tackle CVE and CAPEC. > >> > > >> > -- > >> > Wes > >> > claimid.com/wesyoung > >> > soc@ren-isac.net > >> > > >> > * Wes Young> > >> > * 0xDDB6E946 - Unverified(L) > >> > _______________________________________________ > >> > mile mailing 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 > >> > . > >> > > >>=20 > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > >=A0=20 > >=A0=20 > >=A0=20 --=20 -- Takeshi Takahashi, Ph.D. +81 80 3490 2971 http://www.taketaka.com/ From takeshi_takahashi@nict.go.jp Sun Aug 14 06:27:41 2011 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 ACC9C21F87C2 for ; Sun, 14 Aug 2011 06:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=0.381, 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 Z4EbfqT0NITL for ; Sun, 14 Aug 2011 06:27:40 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3496E21F87D6 for ; Sun, 14 Aug 2011 06:27:40 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id p7EDSFmf005880; Sun, 14 Aug 2011 22:28:15 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id p7EDSEn8009594; Sun, 14 Aug 2011 22:28:14 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id p7EDSD5e009591; Sun, 14 Aug 2011 22:28:13 +0900 (JST) From: "Takeshi Takahashi" To: "'Menkhus, Mark \(HAS GSE SSRT\)'" , , , , References: <000d01cc5647$62c4c070$284e4150$@go.jp> In-Reply-To: Date: Sun, 14 Aug 2011 22:28:30 +0900 Message-ID: <006d01cc5a86$0ef0c780$2cd25680$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHZoScn83GYsZh9CRcfWQQM2pwT0QFeuLRUAupoFywBox2O55TSIvMw Content-Language: ja Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 14 Aug 2011 13:27:41 -0000 Thank you for the emails. I like CVRF's approach. I believe supporting those industry-oriented specification is very important, and this IODEF extension should be designed to be a container = for any evolving specifications. (this is my motivation) The "Method.AdditionalData.Vulnerability" element described in the draft = can be used to embed CVRF report with the "cvrf" SpecificationName. I'll put reference to CVRF specification in the draft. Having said that, I am not sure Method.AdditionalData.Vulnerability is = the right place to embed CVRF report. Correct me if I'm wrong, but according to the CVRF schema 1.0, it = defines abstract-level information. Though current focus of CVRF is on vulnerability (in my understanding), = this schema is flexible enough to convey not only vulnerability information = but also various incident-related information. Anyway, at this stage, let me add text on and reference to CVRF in the = draft as one specification describing vulnerability, after I come back from my vacation. Take From: Menkhus, Mark (HAS GSE SSRT) [mailto:mark.menkhus@hp.com]=20 Sent: Friday, August 12, 2011 9:16 PM To: kathleen.moriarty@emc.com; lnunez@cisco.com; takeshi_takahashi@nict.go.jp; mile@ietf.org Subject: RE: [mile] draft on IODEF exstension to support structured cybersecurity information Hi, HP=92s security advisory team is not using CVRF, but I have followed = CVRF for a while, and advocate it=92s use when we have an opportunity. I have not contributed other comments to mile, yet, but CVRF does bear consideration into the extension. Regards,=20 Mark Menkhus CSSLP, ITIL v3 expert Hewlett Packard Software Security Response Team Team email: security-alert@hp.com From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Wednesday, August 10, 2011 7:54 PM To: lnunez@cisco.com; takeshi_takahashi@nict.go.jp; mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information Interesting questions, what do others think on this one?=A0=20 CVRF is a way of reporting out vulnerability information, tying together some of the SCAP standards for more complete information on a = vulnerability. =A0It could be a very good thing to be able to include in the = extension.=A0 Is this something the community wants to see in the extension? Thanks, Kathleen From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of lnunez Sent: Wednesday, August 10, 2011 4:23 PM To: Takeshi Takahashi; mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information I noticed CVRF mention briefly in this email thread (good I am thinking = the same). Looking at the draft-takahash-mile-sci-01.txt I see potential synergies between the draft and CVRF.=A0=20 They both share some heritage.=A0 Major vendors have indicated that they = will start publishing security advisories in the near future.=A0 I could see = this IODEF-extension leveraging the CVRF content/components to provide = additional fidelity to the security incident exchange. =A0=20 CVRF link: http://www.icasi.org/cvrf Redhat CVRF sample: http://www.awe.com/mark/blog/20110518.html It would be interesting to see a CVRF advisory with OVAL checking = content as a mitigation method in this draft. One thing to keep in mind is to realized how we can build and used the various emerging set of standards in a cohesive way.=20 thanks. On 8/8/11 11:49 PM, "Takeshi Takahashi" wrote: Thank you for those of you who kindly gave me off-line messages . =A0 Let me share the draft with some minor modifications. =A0 Sincerely, Take =A0 =A0 2011/8/5 Takeshi Takahashi : > Dear all, >=20 > =A0 >=20 > The attached is the tentative version of the draft prepared based on = the > comments I=92ve received in this mailing list (Thanks a lot for that). >=20 > It would be great if you could provide some comments on Clause 4, = where the > IODEF extension is defined. >=20 > =A0 >=20 > As you know, there are many ways to embed structured information (e.g. = CVE > and CAPEC) in IODEF since IODEF is designed to be very flexible. >=20 > Thus, I would be happy to change and develop the draft further based = on your > comments. >=20 > =A0 >=20 > I would like to welcome any comments on that. >=20 > =A0 >=20 > By the way, I will be on vacation, thus my response might be slow, = sorry for > the inconvenience. >=20 > =A0 >=20 > Take >=20 > =A0 >=20 > PS: I=92ve changed the title of the email. >=20 > =A0 >=20 > =A0 >=20 > 2011/7/29 >=20 >>=20 >=20 >> Thank you, the approach sounds good, especially since it is in use = today >=20 >> by at least the Research and Education ISAC. =A0Do others have = opinions on >=20 >> the proposal here? >=20 >>=20 >=20 >> Thanks for writing the first draft Take! >=20 >>=20 >=20 >> Best regards, >=20 >> Kathleen >=20 >> ________________________________________ >=20 >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Takeshi >=20 >> Takahashi [takeshi_takahashi@nict.go.jp] >=20 >> Sent: Friday, July 29, 2011 9:20 AM >=20 >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com >=20 >> Cc: mile@ietf.org >=20 >> Subject: Re: [mile] Updated presentation from Side meeting >=20 >>=20 >=20 >> Thank you, Bob, for the email. >=20 >> I also like Tom's suggestion very much. >=20 >> Let me work on the "draft" of the draft for a while, then come back = to you >=20 >> later. >=20 >>=20 >=20 >> Take >=20 >>=20 >=20 >> -----Original Message----- >=20 >> From: Martin, Robert A. [mailto:ramartin@mitre.org] >=20 >> Sent: Friday, July 29, 2011 9:10 AM >=20 >> To: Kent_Landfield@McAfee.com >=20 >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; >=20 >> wes@ren-isac.net; mile@ietf.org >=20 >> Subject: Re: [mile] Updated presentation from Side meeting >=20 >>=20 >=20 >> I also like how this is evolving. >=20 >>=20 >=20 >> I think, as Tom's suggestions pointed, that any and all of the useful >=20 >> types >=20 >> of information that can help with understanding, diagnosing, and = getting >=20 >> ahead of an incident should be added but for now we should focus on = those >=20 >> the most established and well articulated. >=20 >>=20 >=20 >> This can be the compliance/patch/configuration/platform information >=20 >> related >=20 >> to the SCAP use case, or event signature/attack pattern/traffic >=20 >> characteristics from events, or the vulnerability/threat = characterization >=20 >> space. >=20 >>=20 >=20 >> I look forward to Taki's draft to see how he suggests positioning = these >=20 >> concepts. >=20 >>=20 >=20 >> Bob >=20 >>=20 >=20 >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: >=20 >> > I like where this is headed. >=20 >> > >=20 >> > Thanks Takeshi. =A0I look forward to your draft. It will give us something >=20 >> real to discuss. I appreciate you jumping in and getting this = started. >=20 >> > >=20 >> > One question that I am not clear on. What do we envision as the = actual >=20 >> set >=20 >> of deliverables? =A0From and SCAP related perspective, are we looking = at a >=20 >> single draft covering all the extensions? >=20 >> > >=20 >> > Kent >=20 >> > >=20 >> > Kent Landfield >=20 >> > Director Content Strategy, Architecture and Standards >=20 >> > >=20 >> > McAfee, Inc. >=20 >> > 5000 Headquarters Dr. >=20 >> > Plano, Texas 75024 >=20 >> > >=20 >> > Direct: +1.972.963.7096 >=20 >> > Mobile: +1.817.637.8026 >=20 >> > Web: www.mcafee.com >=20 >> > >=20 >> > From: Takeshi >=20 >> > = Takahashi=20 >> > o.jp>> >=20 >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 >=20 >> > To: >=20 >> > = "Thomas.Millar@us-cert.gov"=20 >> > illar@us-cert.gov>, >=20 >> > = "wes@ren-isac.net"=20 >> > s@ren-isac.net>>, >=20 >> > = "mile@ietf.org"=20 >> > rg>> >=20 >> > Subject: Re: [mile] Updated presentation from Side meeting >=20 >> > >=20 >> > Thank you for the email, Tom. >=20 >> > >=20 >> > So, here is what the draft needs to describe (if I understand Wes = and >=20 >> > Tom correctly). >=20 >> > >=20 >> > The draft should define ext-dtype (an attribute of AdditionalData >=20 >> > Class) to identify the information type, rather than defining new >=20 >> > class under AdditionalData. >=20 >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, = ext-capec, >=20 >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal = and >=20 >> > could easily embed various structured information (CVE etc.) in the >=20 >> > EventData.Record.RecordData.AdditionalData field. >=20 >> > Then "should" statement should be carefully placed in the text of >=20 >> > relevant class. >=20 >> > >=20 >> > I'll prepare some draft so that we could discuss and advance = further. >=20 >> > >=20 >> > Take >=20 >> > >=20 >> > >=20 >> > >=20 >> > -----Original Message----- >=20 >> > From: mile-bounces@ietf.org >=20 >> > [mailto:mile-bounces@ietf.org] On Behalf Of >=20 >> > Thomas.Millar@us-cert.gov >=20 >> > Sent: Thursday, July 28, 2011 6:28 PM >=20 >> > To: wes@ren-isac.net; >=20 >> > mile@ietf.org >=20 >> > Subject: Re: [mile] Updated presentation from Side meeting >=20 >> > >=20 >> > I think this approach makes more sense. One of the things I think >=20 >> > could be helpful is to have a number of SHOULD statements further >=20 >> > describing the possible types of other documents that would be >=20 >> > expected to ride under the AdditionalData elements of each class = (not >=20 >> just >=20 >> EventData). >=20 >> > What I'm thinking of looks like this (very unpolished): >=20 >> > >=20 >> > "The Method Class:AdditionalData class SHOULD contain data elements >=20 >> > that describe the methods, tools or techniques employed to cause = the >=20 >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the >=20 >> > method such as CVSS, CWSS, or CCE." >=20 >> > >=20 >> > "The Expectation Class[...] SHOULD contain data elements which >=20 >> > describe configuration changes, detection heuristics, or [* (legal >=20 >> > authorization?)] to assist in executing or implementing the = requested >=20 >> > action, such as XCCDF, OCIL, OVAL, etc" >=20 >> > >=20 >> > This could go towards encouraging better or at least more = consistent >=20 >> > use of "boundary objects" in the substance of incident reports. I >=20 >> > could also go on about greater automation and such but that's = probably >=20 >> > out of scope for this e-mail. >=20 >> > >=20 >> > >=20 >> > - Tom Millar, US-CERT >=20 >> > >=20 >> > thomas.millar@us-cert.gov >=20 >> > BB: thomas.millar@dhs.gov =A0/ >=20 >> > 202-631-1915 >=20 >> > 24x7: soc@us-cert.gov =A0/ 888-282-0870 >=20 >> > -----Original Message----- >=20 >> > From: mile-bounces@ietf.org >=20 >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young >=20 >> > Sent: Thursday, July 28, 2011 11:08 AM >=20 >> > To: mile@ietf.org >=20 >> > Subject: Re: [mile] Updated presentation from Side meeting >=20 >> > >=20 >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM >=20 >> > >=20 >> > http://tools.ietf.org/html/rfc5070#section-3.19 >=20 >> > >=20 >> > i've been sticking other "XML like" records under this (icsg1.1 = data, >=20 >> > etc...). >=20 >> > >=20 >> > pretty easy to do, just generate the "other standards" xml (or json = or >=20 >> > whatever), embed it there. turns iodef into a sharing platform for >=20 >> > other data-types w/o having to extend it too much. >=20 >> > >=20 >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: >=20 >> > >=20 >> > So, maybe we could extend the IODEF as described in Figure 1 of the >=20 >> > attached txt file. (correct me if I'm wrong) We could define >=20 >> > Incident.EventData.AdditionalData elements and describe them by = using >=20 >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. >=20 >> > Regarding OVAL, we might define Incident.AdditionalData element, = but I >=20 >> > >=20 >> > am not sure at this moment, thus is not described in the figure = yet. >=20 >> > I would like to tackle CAPEC first since I believe Kent would like = to >=20 >> > tackle CVE and CAPEC. >=20 >> > >=20 >> > -- >=20 >> > Wes >=20 >> > claimid.com/wesyoung >=20 >> > soc@ren-isac.net >=20 >> > >=20 >> > * Wes Young> >=20 >> > * 0xDDB6E946 - Unverified(L) >=20 >> > _______________________________________________ >=20 >> > mile mailing list >=20 >> > mile@ietf.org >=20 >> > https://www.ietf.org/mailman/listinfo/mile >=20 >> > _______________________________________________ >=20 >> > mile mailing list >=20 >> > mile@ietf.org >=20 >> > https://www.ietf.org/mailman/listinfo/mile >=20 >> > >=20 >> > _______________________________________________ >=20 >> > mile mailing list >=20 >> > mile@ietf.org >=20 >> > https://www.ietf.org/mailman/listinfo/mile >=20 >> > >=20 >> > _______________________________________________ >=20 >> > mile mailing list >=20 >> > mile@ietf.org >=20 >> > https://www.ietf.org/mailman/listinfo/mile >=20 >> > . >=20 >> > >=20 >>=20 >=20 >> _______________________________________________ >=20 >> mile mailing list >=20 >> mile@ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/mile >=20 > =A0 >=20 > =A0 >=20 > =A0 =A0 =A0 =A0 From david.black@emc.com Mon Aug 15 18:14:22 2011 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 1768721F8D09 for ; Mon, 15 Aug 2011 18:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.859 X-Spam-Level: X-Spam-Status: No, score=-105.859 tagged_above=-999 required=5 tests=[AWL=0.740, 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 sVUZcZ6afb2r for ; Mon, 15 Aug 2011 18:14:20 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3ED21F8D07 for ; Mon, 15 Aug 2011 18:14:19 -0700 (PDT) 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 p7G1F5n6016471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Aug 2011 21:15:05 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 15 Aug 2011 21:14:51 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.221.56.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7G1EnWa002208; Mon, 15 Aug 2011 21:14:49 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub14.corp.emc.com ([128.221.56.103]) with mapi; Mon, 15 Aug 2011 21:14:49 -0400 From: To: , Date: Mon, 15 Aug 2011 21:14:46 -0400 Thread-Topic: [mile] draft on IODEF extension to support structured cybersecurity information Thread-Index: AQHZoScn83GYsZh9CRcfWQQM2pwT0QIjvf2BlPAdjlCAAt7UQA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> In-Reply-To: <006501cc5a85$920bd160$b6237420$@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information 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, 16 Aug 2011 01:14:22 -0000 Hi Take, Enjoy your vacation, here are some comments to look at when you return: 1) > Maybe we could use ENUM (instead of ML_STRING), and enumerate possible sp= ecifications. > For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use ENUM f= or > dtype and FraudType description. That sounds like a good approach - each RFC that registers a value for the = ENUM should include a pointer to the XML Schema for that specification as p= art of making the registration with IANA (the IANA registry entry will refe= rence the RFC for the details). This may help recipients ensure that they = have local copies of the XML schemas necessary to parse expected content. 2) > So, my assumption here is that a complete CVE (compatible with its schema= ) > will be embedded here. I don't have a problem with that assumption, but think it should be stated = because that conclusion is not obvious [well, at least not to me ;-) ]. It= should be sufficient to state that the embedded element is a complete XML = document that is formatted according to the schema referenced by the IANA r= egistration of the ENUM value used for SpecificationName (see item 1). > 3) > Maybe some text in the draft has caused mis-understanding. > Yes, the latest version of the XCCDF schema is 1.6. > I intended to say that the number of the version element is zero or one. > Most of specifications such as XCCDF etc. have versions while CVE does no= t. > Thus the number of this element class is ZERO or ONE. I misread what you wrote, sorry about that. I was looking for the syntax o= f the contents of the [Specification]Version element, and looked in the wro= ng place. My concern is similar to item 1) - how does the recipient parse and check t= he version number? The rules for this need to be precise, otherwise there may be unexpected st= ring compare results. It'd be good if the version number could be extracte= d from the XML Schema for the embedded content (and hence take advantage of= the rules in the referenced specification for the syntax of [Specification= ]Version). A simple (silly) example of what can go wrong is that OVAL is currently at = version 5.10 - that's not the same as 5.1, but if it's converted to a numbe= r, the result is easy to misparse it as being equivalent to 5.1 ;-). Conti= nuing with that example, is it ok to use 5-10 or 5_10, e.g., if the '.' cau= ses problems in some tooling? All of these are easy for a human to sort ou= t, but potential causes of problems in automated tools. Thanks, --David > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Sunday, August 14, 2011 9:25 AM > To: Black, David; mile@ietf.org > Subject: RE: [mile] draft on IODEF exstension to support structured cyber= security information > > Hi David, > > Thank you for your kind comments. > I agree, I'll change the element class name. > > Regarding the issues you kindly raised in the email, let me describe my > understanding. > > 1) > My assumption was, when parsing the xml data, the parser anyway reads the > namespace described in the embedded xml data and parse the data. > But I agree, it would be better to limit the description of > SpecificationName. > Maybe we could use ENUM (instead of ML_STRING), and enumerate possible > specifications. > For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use ENUM f= or > dtype and FraudType description. > Like the same way, the SpecificationName could use ENUM for describing > specifications, though we do not have that much specifications to enumera= te > at this moment. > > 2) > I am not sure whether it is easier for information sender and receiver to > send/receive partial CVE data. > Maybe it would be easier for them to embed/receive/parse a complete CVE > data? > If we send a partial CVE or the other structured data, receiver may suffe= r > from some parsing problem, as you mentioned. > So, my assumption here is that a complete CVE (compatible with its schema= ) > will be embedded here. > > 3) > Maybe some text in the draft has caused mis-understanding. > Yes, the latest version of the XCCDF schema is 1.6. > I intended to say that the number of the version element is zero or one. > Most of specifications such as XCCDF etc. have versions while CVE does no= t. > Thus the number of this element class is ZERO or ONE. > > Above are my viewpoint, but I might be wrong. > Let me develop the draft based on your kind comments after my vacation. > Please correct me if I am wrong, I would like to welcome feedbacks. > > Thank you. > > Take > > > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Wednesday, August 10, 2011 8:45 AM > To: takeshi_takahashi@nict.go.jp; mile@ietf.org > Cc: david.black@emc.com > Subject: RE: [mile] draft on IODEF exstension to support structured > cybersecurity information > > Hi Take, > > For clarity I'd suggest not using "Version" as the name of both an extens= ion > attribute and one of the classes in each extension. Renaming the class t= o > SpecificationVersion would be clearer (so Version is the attribute with t= he > version of the extension). > > I also have a few questions: > > (1) What strings are valid for SpecificationName? If the recipient doesn= 't > understand the SpecificationName, the information in the extension may be > unparseable, so this probably needs to be controlled. > > An IANA registry may be appropriate to list the valid strings and associa= te > each string with its corresponding specification. > > (2) How does one determine the format for information formatted according= to > an external specification? > > For example, I believe that the XSD schema for the CVE list defines a > complete XML document, but I suspect that less than a complete XML docume= nt > is intended to be embedded because the proposed extension is part of an > IODEF XML document. > > (3) Why is the [Specification]Version limited to zero or one? > > For example, CAPEC is currently at Release 1.6. > > 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 > ---------------------------------------------------- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Takeshi Takahashi > Sent: Monday, August 08, 2011 11:50 PM > To: mile@ietf.org > Subject: Re: [mile] draft on IODEF exstension to support structured > cybersecurity information > > Thank you for those of you who kindly gave me off-line messages . > > Let me share the draft with some minor modifications. > > Sincerely, > Take > > > 2011/8/5 Takeshi Takahashi : > > Dear all, > > > > > > > > The attached is the tentative version of the draft prepared based on th= e > > comments I've received in this mailing list (Thanks a lot for that). > > > > It would be great if you could provide some comments on Clause 4, where > the > > IODEF extension is defined. > > > > > > > > As you know, there are many ways to embed structured information (e.g. = CVE > > and CAPEC) in IODEF since IODEF is designed to be very flexible. > > > > Thus, I would be happy to change and develop the draft further based on > your > > comments. > > > > > > > > I would like to welcome any comments on that. > > > > > > > > By the way, I will be on vacation, thus my response might be slow, sorr= y > for > > the inconvenience. > > > > > > > > Take > > > > > > > > PS: I've changed the title of the email. > > > > > > > > > > > > 2011/7/29 > > > >> > > > >> Thank you, the approach sounds good, especially since it is in use tod= ay > > > >> by at least the Research and Education ISAC. Do others have opinions = on > > > >> the proposal here? > > > >> > > > >> Thanks for writing the first draft Take! > > > >> > > > >> Best regards, > > > >> Kathleen > > > >> ________________________________________ > > > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Takes= hi > > > >> Takahashi [takeshi_takahashi@nict.go.jp] > > > >> Sent: Friday, July 29, 2011 9:20 AM > > > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > > > >> Cc: mile@ietf.org > > > >> Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > >> Thank you, Bob, for the email. > > > >> I also like Tom's suggestion very much. > > > >> Let me work on the "draft" of the draft for a while, then come back to > you > > > >> later. > > > >> > > > >> Take > > > >> > > > >> -----Original Message----- > > > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > > > >> Sent: Friday, July 29, 2011 9:10 AM > > > >> To: Kent_Landfield@McAfee.com > > > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > > > >> wes@ren-isac.net; mile@ietf.org > > > >> Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > >> I also like how this is evolving. > > > >> > > > >> I think, as Tom's suggestions pointed, that any and all of the useful > > > >> types > > > >> of information that can help with understanding, diagnosing, and getti= ng > > > >> ahead of an incident should be added but for now we should focus on th= ose > > > >> the most established and well articulated. > > > >> > > > >> This can be the compliance/patch/configuration/platform information > > > >> related > > > >> to the SCAP use case, or event signature/attack pattern/traffic > > > >> characteristics from events, or the vulnerability/threat characterizat= ion > > > >> space. > > > >> > > > >> I look forward to Taki's draft to see how he suggests positioning thes= e > > > >> concepts. > > > >> > > > >> Bob > > > >> > > > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > > > >> > I like where this is headed. > > > >> > > > > >> > Thanks Takeshi. I look forward to your draft. It will give us > something > > > >> real to discuss. I appreciate you jumping in and getting this started. > > > >> > > > > >> > One question that I am not clear on. What do we envision as the actu= al > > > >> set > > > >> of deliverables? From and SCAP related perspective, are we looking at= a > > > >> single draft covering all the extensions? > > > >> > > > > >> > Kent > > > >> > > > > >> > Kent Landfield > > > >> > Director Content Strategy, Architecture and Standards > > > >> > > > > >> > McAfee, Inc. > > > >> > 5000 Headquarters Dr. > > > >> > Plano, Texas 75024 > > > >> > > > > >> > Direct: +1.972.963.7096 > > > >> > Mobile: +1.817.637.8026 > > > >> > Web: www.mcafee.com > > > >> > > > > >> > From: Takeshi > > > >> > Takahashi > > >> > o.jp>> > > > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > > > >> > To: > > > >> > "Thomas.Millar@us-cert.gov" > > >> > illar@us-cert.gov>, > > > >> > "wes@ren-isac.net" > > >> > s@ren-isac.net>>, > > > >> > "mile@ietf.org" > > >> > rg>> > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > Thank you for the email, Tom. > > > >> > > > > >> > So, here is what the draft needs to describe (if I understand Wes an= d > > > >> > Tom correctly). > > > >> > > > > >> > The draft should define ext-dtype (an attribute of AdditionalData > > > >> > Class) to identify the information type, rather than defining new > > > >> > class under AdditionalData. > > > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, ext-capec= , > > > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal an= d > > > >> > could easily embed various structured information (CVE etc.) in the > > > >> > EventData.Record.RecordData.AdditionalData field. > > > >> > Then "should" statement should be carefully placed in the text of > > > >> > relevant class. > > > >> > > > > >> > I'll prepare some draft so that we could discuss and advance further= . > > > >> > > > > >> > Take > > > >> > > > > >> > > > > >> > > > > >> > -----Original Message----- > > > >> > From: mile-bounces@ietf.org > > > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > > > >> > Thomas.Millar@us-cert.gov > > > >> > Sent: Thursday, July 28, 2011 6:28 PM > > > >> > To: wes@ren-isac.net; > > > >> > mile@ietf.org > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > I think this approach makes more sense. One of the things I think > > > >> > could be helpful is to have a number of SHOULD statements further > > > >> > describing the possible types of other documents that would be > > > >> > expected to ride under the AdditionalData elements of each class (no= t > > > >> just > > > >> EventData). > > > >> > What I'm thinking of looks like this (very unpolished): > > > >> > > > > >> > "The Method Class:AdditionalData class SHOULD contain data elements > > > >> > that describe the methods, tools or techniques employed to cause the > > > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning the > > > >> > method such as CVSS, CWSS, or CCE." > > > >> > > > > >> > "The Expectation Class[...] SHOULD contain data elements which > > > >> > describe configuration changes, detection heuristics, or [* (legal > > > >> > authorization?)] to assist in executing or implementing the requeste= d > > > >> > action, such as XCCDF, OCIL, OVAL, etc" > > > >> > > > > >> > This could go towards encouraging better or at least more consistent > > > >> > use of "boundary objects" in the substance of incident reports. I > > > >> > could also go on about greater automation and such but that's probab= ly > > > >> > out of scope for this e-mail. > > > >> > > > > >> > > > > >> > - Tom Millar, US-CERT > > > >> > > > > >> > thomas.millar@us-cert.gov > > > >> > BB: thomas.millar@dhs.gov / > > > >> > 202-631-1915 > > > >> > 24x7: soc@us-cert.gov / 888-282-0870 > > > >> > -----Original Message----- > > > >> > From: mile-bounces@ietf.org > > > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > > > >> > Sent: Thursday, July 28, 2011 11:08 AM > > > >> > To: mile@ietf.org > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > > > >> > > > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > > > >> > > > > >> > i've been sticking other "XML like" records under this (icsg1.1 data= , > > > >> > etc...). > > > >> > > > > >> > pretty easy to do, just generate the "other standards" xml (or json = or > > > >> > whatever), embed it there. turns iodef into a sharing platform for > > > >> > other data-types w/o having to extend it too much. > > > >> > > > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > > > >> > > > > >> > So, maybe we could extend the IODEF as described in Figure 1 of the > > > >> > attached txt file. (correct me if I'm wrong) We could define > > > >> > Incident.EventData.AdditionalData elements and describe them by usin= g > > > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > > > >> > Regarding OVAL, we might define Incident.AdditionalData element, but= I > > > >> > > > > >> > am not sure at this moment, thus is not described in the figure yet. > > > >> > I would like to tackle CAPEC first since I believe Kent would like t= o > > > >> > tackle CVE and CAPEC. > > > >> > > > > >> > -- > > > >> > Wes > > > >> > claimid.com/wesyoung > > > >> > soc@ren-isac.net > > > >> > > > > >> > * Wes Young> > > > >> > * 0xDDB6E946 - Unverified(L) > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > . > > > >> > > > > >> > > > >> _______________________________________________ > > > >> mile mailing list > > > >> mile@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > > > > -- > -- > Takeshi Takahashi, Ph.D. > +81 80 3490 2971 > http://www.taketaka.com/ > > From trammell@tik.ee.ethz.ch Tue Aug 16 01:09:15 2011 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 F3D8F21F8B75 for ; Tue, 16 Aug 2011 01:09:14 -0700 (PDT) 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 hb0A4kt4i4UI for ; Tue, 16 Aug 2011 01:09:13 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A9FDC21F8B64 for ; Tue, 16 Aug 2011 01:09:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 24602D9303; Tue, 16 Aug 2011 10:09:57 +0200 (MEST) 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 ui+KHtKa2aXz; Tue, 16 Aug 2011 10:09:56 +0200 (MEST) 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 94772D9302; Tue, 16 Aug 2011 10:09:56 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> Date: Tue, 16 Aug 2011 10:09:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <809F17A3-A382-477E-A608-271A1D42D6C6@tik.ee.ethz.ch> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> To: X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information 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, 16 Aug 2011 08:09:15 -0000 Greetings, all, I'm just back from vacation and catching up on things, and still need to = review the document completely, so expect more from me on this thread, = soon. However, I did want to point one thing out here... In general, I agree: representing embedded information by ENUM as = opposed to by freeform string is much preferable. However, if the = embedded information is itself described by an XML Schema, then it may = make sense to differentiate the embedded AdditionalData content not with = a new ENUM, but rather by the namespace used by that schema. You still = run into the subordinate namespace versioning problem, but this is now = the job of the creator of the subordinate namespace to do correctly, = which I would assume is the case for the SCAP use case. Regards, Brian On Aug 16, 2011, at 3:14 AM, = wrote: > Hi Take, >=20 > Enjoy your vacation, here are some comments to look at when you = return: >=20 > 1) >> Maybe we could use ENUM (instead of ML_STRING), and enumerate = possible specifications. >> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use = ENUM for >> dtype and FraudType description. >=20 > That sounds like a good approach - each RFC that registers a value for = the ENUM should include a pointer to the XML Schema for that = specification as part of making the registration with IANA (the IANA = registry entry will reference the RFC for the details). This may help = recipients ensure that they have local copies of the XML schemas = necessary to parse expected content. >=20 > 2) >> So, my assumption here is that a complete CVE (compatible with its = schema) >> will be embedded here. >=20 > I don't have a problem with that assumption, but think it should be = stated because that conclusion is not obvious [well, at least not to me = ;-) ]. It should be sufficient to state that the embedded element is a = complete XML document that is formatted according to the schema = referenced by the IANA registration of the ENUM value used for = SpecificationName (see item 1). >=20 >> 3) >> Maybe some text in the draft has caused mis-understanding. >> Yes, the latest version of the XCCDF schema is 1.6. >> I intended to say that the number of the version element is zero or = one. >> Most of specifications such as XCCDF etc. have versions while CVE = does not. >> Thus the number of this element class is ZERO or ONE. >=20 > I misread what you wrote, sorry about that. I was looking for the = syntax of the contents of the [Specification]Version element, and looked = in the wrong place. >=20 > My concern is similar to item 1) - how does the recipient parse and = check the version number? > The rules for this need to be precise, otherwise there may be = unexpected string compare results. It'd be good if the version number = could be extracted from the XML Schema for the embedded content (and = hence take advantage of the rules in the referenced specification for = the syntax of [Specification]Version). >=20 > A simple (silly) example of what can go wrong is that OVAL is = currently at version 5.10 - that's not the same as 5.1, but if it's = converted to a number, the result is easy to misparse it as being = equivalent to 5.1 ;-). Continuing with that example, is it ok to use = 5-10 or 5_10, e.g., if the '.' causes problems in some tooling? All of = these are easy for a human to sort out, but potential causes of problems = in automated tools. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Sunday, August 14, 2011 9:25 AM >> To: Black, David; mile@ietf.org >> Subject: RE: [mile] draft on IODEF exstension to support structured = cybersecurity information >>=20 >> Hi David, >>=20 >> Thank you for your kind comments. >> I agree, I'll change the element class name. >>=20 >> Regarding the issues you kindly raised in the email, let me describe = my >> understanding. >>=20 >> 1) >> My assumption was, when parsing the xml data, the parser anyway reads = the >> namespace described in the embedded xml data and parse the data. >> But I agree, it would be better to limit the description of >> SpecificationName. >> Maybe we could use ENUM (instead of ML_STRING), and enumerate = possible >> specifications. >> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use = ENUM for >> dtype and FraudType description. >> Like the same way, the SpecificationName could use ENUM for = describing >> specifications, though we do not have that much specifications to = enumerate >> at this moment. >>=20 >> 2) >> I am not sure whether it is easier for information sender and = receiver to >> send/receive partial CVE data. >> Maybe it would be easier for them to embed/receive/parse a complete = CVE >> data? >> If we send a partial CVE or the other structured data, receiver may = suffer >> from some parsing problem, as you mentioned. >> So, my assumption here is that a complete CVE (compatible with its = schema) >> will be embedded here. >>=20 >> 3) >> Maybe some text in the draft has caused mis-understanding. >> Yes, the latest version of the XCCDF schema is 1.6. >> I intended to say that the number of the version element is zero or = one. >> Most of specifications such as XCCDF etc. have versions while CVE = does not. >> Thus the number of this element class is ZERO or ONE. >>=20 >> Above are my viewpoint, but I might be wrong. >> Let me develop the draft based on your kind comments after my = vacation. >> Please correct me if I am wrong, I would like to welcome feedbacks. >>=20 >> Thank you. >>=20 >> Take >>=20 >>=20 >> From: david.black@emc.com [mailto:david.black@emc.com] >> Sent: Wednesday, August 10, 2011 8:45 AM >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org >> Cc: david.black@emc.com >> Subject: RE: [mile] draft on IODEF exstension to support structured >> cybersecurity information >>=20 >> Hi Take, >>=20 >> For clarity I'd suggest not using "Version" as the name of both an = extension >> attribute and one of the classes in each extension. Renaming the = class to >> SpecificationVersion would be clearer (so Version is the attribute = with the >> version of the extension). >>=20 >> I also have a few questions: >>=20 >> (1) What strings are valid for SpecificationName? If the recipient = doesn't >> understand the SpecificationName, the information in the extension = may be >> unparseable, so this probably needs to be controlled. >>=20 >> An IANA registry may be appropriate to list the valid strings and = associate >> each string with its corresponding specification. >>=20 >> (2) How does one determine the format for information formatted = according to >> an external specification? >>=20 >> For example, I believe that the XSD schema for the CVE list defines a >> complete XML document, but I suspect that less than a complete XML = document >> is intended to be embedded because the proposed extension is part of = an >> IODEF XML document. >>=20 >> (3) Why is the [Specification]Version limited to zero or one? >>=20 >> For example, CAPEC is currently at Release 1.6. >>=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: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of >> Takeshi Takahashi >> Sent: Monday, August 08, 2011 11:50 PM >> To: mile@ietf.org >> Subject: Re: [mile] draft on IODEF exstension to support structured >> cybersecurity information >>=20 >> Thank you for those of you who kindly gave me off-line messages . >>=20 >> Let me share the draft with some minor modifications. >>=20 >> Sincerely, >> Take >>=20 >>=20 >> 2011/8/5 Takeshi Takahashi : >>> Dear all, >>>=20 >>>=20 >>>=20 >>> The attached is the tentative version of the draft prepared based on = the >>> comments I've received in this mailing list (Thanks a lot for that). >>>=20 >>> It would be great if you could provide some comments on Clause 4, = where >> the >>> IODEF extension is defined. >>>=20 >>>=20 >>>=20 >>> As you know, there are many ways to embed structured information = (e.g. CVE >>> and CAPEC) in IODEF since IODEF is designed to be very flexible. >>>=20 >>> Thus, I would be happy to change and develop the draft further based = on >> your >>> comments. >>>=20 >>>=20 >>>=20 >>> I would like to welcome any comments on that. >>>=20 >>>=20 >>>=20 >>> By the way, I will be on vacation, thus my response might be slow, = sorry >> for >>> the inconvenience. >>>=20 >>>=20 >>>=20 >>> Take >>>=20 >>>=20 >>>=20 >>> PS: I've changed the title of the email. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> 2011/7/29 >>>=20 >>>>=20 >>>=20 >>>> Thank you, the approach sounds good, especially since it is in use = today >>>=20 >>>> by at least the Research and Education ISAC. Do others have = opinions on >>>=20 >>>> the proposal here? >>>=20 >>>>=20 >>>=20 >>>> Thanks for writing the first draft Take! >>>=20 >>>>=20 >>>=20 >>>> Best regards, >>>=20 >>>> Kathleen >>>=20 >>>> ________________________________________ >>>=20 >>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Takeshi >>>=20 >>>> Takahashi [takeshi_takahashi@nict.go.jp] >>>=20 >>>> Sent: Friday, July 29, 2011 9:20 AM >>>=20 >>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com >>>=20 >>>> Cc: mile@ietf.org >>>=20 >>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>=20 >>>=20 >>>> Thank you, Bob, for the email. >>>=20 >>>> I also like Tom's suggestion very much. >>>=20 >>>> Let me work on the "draft" of the draft for a while, then come back = to >> you >>>=20 >>>> later. >>>=20 >>>>=20 >>>=20 >>>> Take >>>=20 >>>>=20 >>>=20 >>>> -----Original Message----- >>>=20 >>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] >>>=20 >>>> Sent: Friday, July 29, 2011 9:10 AM >>>=20 >>>> To: Kent_Landfield@McAfee.com >>>=20 >>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; >>>=20 >>>> wes@ren-isac.net; mile@ietf.org >>>=20 >>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>=20 >>>=20 >>>> I also like how this is evolving. >>>=20 >>>>=20 >>>=20 >>>> I think, as Tom's suggestions pointed, that any and all of the = useful >>>=20 >>>> types >>>=20 >>>> of information that can help with understanding, diagnosing, and = getting >>>=20 >>>> ahead of an incident should be added but for now we should focus on = those >>>=20 >>>> the most established and well articulated. >>>=20 >>>>=20 >>>=20 >>>> This can be the compliance/patch/configuration/platform information >>>=20 >>>> related >>>=20 >>>> to the SCAP use case, or event signature/attack pattern/traffic >>>=20 >>>> characteristics from events, or the vulnerability/threat = characterization >>>=20 >>>> space. >>>=20 >>>>=20 >>>=20 >>>> I look forward to Taki's draft to see how he suggests positioning = these >>>=20 >>>> concepts. >>>=20 >>>>=20 >>>=20 >>>> Bob >>>=20 >>>>=20 >>>=20 >>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: >>>=20 >>>>> I like where this is headed. >>>=20 >>>>>=20 >>>=20 >>>>> Thanks Takeshi. I look forward to your draft. It will give us >> something >>>=20 >>>> real to discuss. I appreciate you jumping in and getting this = started. >>>=20 >>>>>=20 >>>=20 >>>>> One question that I am not clear on. What do we envision as the = actual >>>=20 >>>> set >>>=20 >>>> of deliverables? =46rom and SCAP related perspective, are we = looking at a >>>=20 >>>> single draft covering all the extensions? >>>=20 >>>>>=20 >>>=20 >>>>> Kent >>>=20 >>>>>=20 >>>=20 >>>>> Kent Landfield >>>=20 >>>>> Director Content Strategy, Architecture and Standards >>>=20 >>>>>=20 >>>=20 >>>>> McAfee, Inc. >>>=20 >>>>> 5000 Headquarters Dr. >>>=20 >>>>> Plano, Texas 75024 >>>=20 >>>>>=20 >>>=20 >>>>> Direct: +1.972.963.7096 >>>=20 >>>>> Mobile: +1.817.637.8026 >>>=20 >>>>> Web: www.mcafee.com >>>=20 >>>>>=20 >>>=20 >>>>> From: Takeshi >>>=20 >>>>> = Takahashi>>=20 >>>>> o.jp>> >>>=20 >>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 >>>=20 >>>>> To: >>>=20 >>>>> = "Thomas.Millar@us-cert.gov">>=20 >>>>> illar@us-cert.gov>, >>>=20 >>>>> = "wes@ren-isac.net">>=20 >>>>> s@ren-isac.net>>, >>>=20 >>>>> = "mile@ietf.org">>=20 >>>>> rg>> >>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>>=20 >>>=20 >>>>> Thank you for the email, Tom. >>>=20 >>>>>=20 >>>=20 >>>>> So, here is what the draft needs to describe (if I understand Wes = and >>>=20 >>>>> Tom correctly). >>>=20 >>>>>=20 >>>=20 >>>>> The draft should define ext-dtype (an attribute of AdditionalData >>>=20 >>>>> Class) to identify the information type, rather than defining new >>>=20 >>>>> class under AdditionalData. >>>=20 >>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, = ext-capec, >>>=20 >>>>> ext-cvss, ext-cwss, In this way, we could keep the change minimal = and >>>=20 >>>>> could easily embed various structured information (CVE etc.) in = the >>>=20 >>>>> EventData.Record.RecordData.AdditionalData field. >>>=20 >>>>> Then "should" statement should be carefully placed in the text of >>>=20 >>>>> relevant class. >>>=20 >>>>>=20 >>>=20 >>>>> I'll prepare some draft so that we could discuss and advance = further. >>>=20 >>>>>=20 >>>=20 >>>>> Take >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>> -----Original Message----- >>>=20 >>>>> From: mile-bounces@ietf.org >>>=20 >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>=20 >>>>> Thomas.Millar@us-cert.gov >>>=20 >>>>> Sent: Thursday, July 28, 2011 6:28 PM >>>=20 >>>>> To: wes@ren-isac.net; >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>>=20 >>>=20 >>>>> I think this approach makes more sense. One of the things I think >>>=20 >>>>> could be helpful is to have a number of SHOULD statements further >>>=20 >>>>> describing the possible types of other documents that would be >>>=20 >>>>> expected to ride under the AdditionalData elements of each class = (not >>>=20 >>>> just >>>=20 >>>> EventData). >>>=20 >>>>> What I'm thinking of looks like this (very unpolished): >>>=20 >>>>>=20 >>>=20 >>>>> "The Method Class:AdditionalData class SHOULD contain data = elements >>>=20 >>>>> that describe the methods, tools or techniques employed to cause = the >>>=20 >>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning = the >>>=20 >>>>> method such as CVSS, CWSS, or CCE." >>>=20 >>>>>=20 >>>=20 >>>>> "The Expectation Class[...] SHOULD contain data elements which >>>=20 >>>>> describe configuration changes, detection heuristics, or [* (legal >>>=20 >>>>> authorization?)] to assist in executing or implementing the = requested >>>=20 >>>>> action, such as XCCDF, OCIL, OVAL, etc" >>>=20 >>>>>=20 >>>=20 >>>>> This could go towards encouraging better or at least more = consistent >>>=20 >>>>> use of "boundary objects" in the substance of incident reports. I >>>=20 >>>>> could also go on about greater automation and such but that's = probably >>>=20 >>>>> out of scope for this e-mail. >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>> - Tom Millar, US-CERT >>>=20 >>>>>=20 >>>=20 >>>>> thomas.millar@us-cert.gov >>>=20 >>>>> BB: thomas.millar@dhs.gov / >>>=20 >>>>> 202-631-1915 >>>=20 >>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>=20 >>>>> -----Original Message----- >>>=20 >>>>> From: mile-bounces@ietf.org >>>=20 >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young >>>=20 >>>>> Sent: Thursday, July 28, 2011 11:08 AM >>>=20 >>>>> To: mile@ietf.org >>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>>=20 >>>=20 >>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM >>>=20 >>>>>=20 >>>=20 >>>>> http://tools.ietf.org/html/rfc5070#section-3.19 >>>=20 >>>>>=20 >>>=20 >>>>> i've been sticking other "XML like" records under this (icsg1.1 = data, >>>=20 >>>>> etc...). >>>=20 >>>>>=20 >>>=20 >>>>> pretty easy to do, just generate the "other standards" xml (or = json or >>>=20 >>>>> whatever), embed it there. turns iodef into a sharing platform for >>>=20 >>>>> other data-types w/o having to extend it too much. >>>=20 >>>>>=20 >>>=20 >>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: >>>=20 >>>>>=20 >>>=20 >>>>> So, maybe we could extend the IODEF as described in Figure 1 of = the >>>=20 >>>>> attached txt file. (correct me if I'm wrong) We could define >>>=20 >>>>> Incident.EventData.AdditionalData elements and describe them by = using >>>=20 >>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. >>>=20 >>>>> Regarding OVAL, we might define Incident.AdditionalData element, = but I >>>=20 >>>>>=20 >>>=20 >>>>> am not sure at this moment, thus is not described in the figure = yet. >>>=20 >>>>> I would like to tackle CAPEC first since I believe Kent would like = to >>>=20 >>>>> tackle CVE and CAPEC. >>>=20 >>>>>=20 >>>=20 >>>>> -- >>>=20 >>>>> Wes >>>=20 >>>>> claimid.com/wesyoung >>>=20 >>>>> soc@ren-isac.net >>>=20 >>>>>=20 >>>=20 >>>>> * Wes Young> >>>=20 >>>>> * 0xDDB6E946 - Unverified(L) >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>>=20 >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>>=20 >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>> . >>>=20 >>>>>=20 >>>=20 >>>>=20 >>>=20 >>>> _______________________________________________ >>>=20 >>>> mile mailing list >>>=20 >>>> mile@ietf.org >>>=20 >>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> -- >> Takeshi Takahashi, Ph.D. >> +81 80 3490 2971 >> http://www.taketaka.com/ >>=20 >>=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Thu Aug 18 07:13:19 2011 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 A03AC21F8AC3 for ; Thu, 18 Aug 2011 07:13:19 -0700 (PDT) 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 MY1wtqvZlxDE for ; Thu, 18 Aug 2011 07:13:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D790421F8B1B for ; Thu, 18 Aug 2011 07:13:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4F675D9313; Thu, 18 Aug 2011 16:14:11 +0200 (MEST) 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 8KE+tIuaNL7y; Thu, 18 Aug 2011 16:14:11 +0200 (MEST) Received: from etx-public-dock-143-dhcp.ethz.ch (etx-public-dock-143-dhcp.ethz.ch [82.130.81.143]) (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 00E4BD930B; Thu, 18 Aug 2011 16:14:10 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Brian Trammell In-Reply-To: <000d01cc5647$62c4c070$284e4150$@go.jp> Date: Thu, 18 Aug 2011 16:14:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44318F0F-7B19-4457-B09B-468CEB9EA0C7@tik.ee.ethz.ch> References: <000d01cc5647$62c4c070$284e4150$@go.jp> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 18 Aug 2011 14:13:19 -0000 Hi, Take, all,=20 One point that came up here when we were discussing the draft at ETH = follows... It appears that the AttackPattern, Vulnerability, and Weakness classes = should probably have a multiplicity of 0..n -- 0 to support cases where = these are not known, or n for cases where multiple external references = are necessary. Thoughts? Cheers, Brian On Aug 9, 2011, at 5:49 AM, Takeshi Takahashi wrote: > Thank you for those of you who kindly gave me off-line messages . > =20 > Let me share the draft with some minor modifications. > =20 > Sincerely, > Take > =20 > =20 > 2011/8/5 Takeshi Takahashi : > > Dear all, > >=20 > >=20 > >=20 > > The attached is the tentative version of the draft prepared based on = the > > comments I=92ve received in this mailing list (Thanks a lot for = that). > >=20 > > It would be great if you could provide some comments on Clause 4, = where the > > IODEF extension is defined. > >=20 > >=20 > >=20 > > As you know, there are many ways to embed structured information = (e.g. CVE > > and CAPEC) in IODEF since IODEF is designed to be very flexible. > >=20 > > Thus, I would be happy to change and develop the draft further based = on your > > comments. > >=20 > >=20 > >=20 > > I would like to welcome any comments on that. > >=20 > >=20 > >=20 > > By the way, I will be on vacation, thus my response might be slow, = sorry for > > the inconvenience. > >=20 > >=20 > >=20 > > Take > >=20 > >=20 > >=20 > > PS: I=92ve changed the title of the email. > >=20 > >=20 > >=20 > >=20 > >=20 > > 2011/7/29 > >=20 > >> > >=20 > >> Thank you, the approach sounds good, especially since it is in use = today > >=20 > >> by at least the Research and Education ISAC. Do others have = opinions on > >=20 > >> the proposal here? > >=20 > >> > >=20 > >> Thanks for writing the first draft Take! > >=20 > >> > >=20 > >> Best regards, > >=20 > >> Kathleen > >=20 > >> ________________________________________ > >=20 > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of = Takeshi > >=20 > >> Takahashi [takeshi_takahashi@nict.go.jp] > >=20 > >> Sent: Friday, July 29, 2011 9:20 AM > >=20 > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >=20 > >> Cc: mile@ietf.org > >=20 > >> Subject: Re: [mile] Updated presentation from Side meeting > >=20 > >> > >=20 > >> Thank you, Bob, for the email. > >=20 > >> I also like Tom's suggestion very much. > >=20 > >> Let me work on the "draft" of the draft for a while, then come back = to you > >=20 > >> later. > >=20 > >> > >=20 > >> Take > >=20 > >> > >=20 > >> -----Original Message----- > >=20 > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >=20 > >> Sent: Friday, July 29, 2011 9:10 AM > >=20 > >> To: Kent_Landfield@McAfee.com > >=20 > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >=20 > >> wes@ren-isac.net; mile@ietf.org > >=20 > >> Subject: Re: [mile] Updated presentation from Side meeting > >=20 > >> > >=20 > >> I also like how this is evolving. > >=20 > >> > >=20 > >> I think, as Tom's suggestions pointed, that any and all of the = useful > >=20 > >> types > >=20 > >> of information that can help with understanding, diagnosing, and = getting > >=20 > >> ahead of an incident should be added but for now we should focus on = those > >=20 > >> the most established and well articulated. > >=20 > >> > >=20 > >> This can be the compliance/patch/configuration/platform information > >=20 > >> related > >=20 > >> to the SCAP use case, or event signature/attack pattern/traffic > >=20 > >> characteristics from events, or the vulnerability/threat = characterization > >=20 > >> space. > >=20 > >> > >=20 > >> I look forward to Taki's draft to see how he suggests positioning = these > >=20 > >> concepts. > >=20 > >> > >=20 > >> Bob > >=20 > >> > >=20 > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >=20 > >> > I like where this is headed. > >=20 > >> > > >=20 > >> > Thanks Takeshi. I look forward to your draft. It will give us = something > >=20 > >> real to discuss. I appreciate you jumping in and getting this = started. > >=20 > >> > > >=20 > >> > One question that I am not clear on. What do we envision as the = actual > >=20 > >> set > >=20 > >> of deliverables? =46rom and SCAP related perspective, are we = looking at a > >=20 > >> single draft covering all the extensions? > >=20 > >> > > >=20 > >> > Kent > >=20 > >> > > >=20 > >> > Kent Landfield > >=20 > >> > Director Content Strategy, Architecture and Standards > >=20 > >> > > >=20 > >> > McAfee, Inc. > >=20 > >> > 5000 Headquarters Dr. > >=20 > >> > Plano, Texas 75024 > >=20 > >> > > >=20 > >> > Direct: +1.972.963.7096 > >=20 > >> > Mobile: +1.817.637.8026 > >=20 > >> > Web: www.mcafee.com > >=20 > >> > > >=20 > >> > From: Takeshi > >=20 > >> > = Takahashi >=20 > >> > o.jp>> > >=20 > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > >=20 > >> > To: > >=20 > >> > = "Thomas.Millar@us-cert.gov" >=20 > >> > illar@us-cert.gov>, > >=20 > >> > = "wes@ren-isac.net" >=20 > >> > s@ren-isac.net>>, > >=20 > >> > = "mile@ietf.org" >=20 > >> > rg>> > >=20 > >> > Subject: Re: [mile] Updated presentation from Side meeting > >=20 > >> > > >=20 > >> > Thank you for the email, Tom. > >=20 > >> > > >=20 > >> > So, here is what the draft needs to describe (if I understand Wes = and > >=20 > >> > Tom correctly). > >=20 > >> > > >=20 > >> > The draft should define ext-dtype (an attribute of AdditionalData > >=20 > >> > Class) to identify the information type, rather than defining new > >=20 > >> > class under AdditionalData. > >=20 > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, = ext-capec, > >=20 > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal = and > >=20 > >> > could easily embed various structured information (CVE etc.) in = the > >=20 > >> > EventData.Record.RecordData.AdditionalData field. > >=20 > >> > Then "should" statement should be carefully placed in the text of > >=20 > >> > relevant class. > >=20 > >> > > >=20 > >> > I'll prepare some draft so that we could discuss and advance = further. > >=20 > >> > > >=20 > >> > Take > >=20 > >> > > >=20 > >> > > >=20 > >> > > >=20 > >> > -----Original Message----- > >=20 > >> > From: mile-bounces@ietf.org > >=20 > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > >=20 > >> > Thomas.Millar@us-cert.gov > >=20 > >> > Sent: Thursday, July 28, 2011 6:28 PM > >=20 > >> > To: wes@ren-isac.net; > >=20 > >> > mile@ietf.org > >=20 > >> > Subject: Re: [mile] Updated presentation from Side meeting > >=20 > >> > > >=20 > >> > I think this approach makes more sense. One of the things I think > >=20 > >> > could be helpful is to have a number of SHOULD statements further > >=20 > >> > describing the possible types of other documents that would be > >=20 > >> > expected to ride under the AdditionalData elements of each class = (not > >=20 > >> just > >=20 > >> EventData). > >=20 > >> > What I'm thinking of looks like this (very unpolished): > >=20 > >> > > >=20 > >> > "The Method Class:AdditionalData class SHOULD contain data = elements > >=20 > >> > that describe the methods, tools or techniques employed to cause = the > >=20 > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning = the > >=20 > >> > method such as CVSS, CWSS, or CCE." > >=20 > >> > > >=20 > >> > "The Expectation Class[...] SHOULD contain data elements which > >=20 > >> > describe configuration changes, detection heuristics, or [* = (legal > >=20 > >> > authorization?)] to assist in executing or implementing the = requested > >=20 > >> > action, such as XCCDF, OCIL, OVAL, etc" > >=20 > >> > > >=20 > >> > This could go towards encouraging better or at least more = consistent > >=20 > >> > use of "boundary objects" in the substance of incident reports. I > >=20 > >> > could also go on about greater automation and such but that's = probably > >=20 > >> > out of scope for this e-mail. > >=20 > >> > > >=20 > >> > > >=20 > >> > - Tom Millar, US-CERT > >=20 > >> > > >=20 > >> > thomas.millar@us-cert.gov > >=20 > >> > BB: thomas.millar@dhs.gov / > >=20 > >> > 202-631-1915 > >=20 > >> > 24x7: soc@us-cert.gov / 888-282-0870 > >=20 > >> > -----Original Message----- > >=20 > >> > From: mile-bounces@ietf.org > >=20 > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >=20 > >> > Sent: Thursday, July 28, 2011 11:08 AM > >=20 > >> > To: mile@ietf.org > >=20 > >> > Subject: Re: [mile] Updated presentation from Side meeting > >=20 > >> > > >=20 > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >=20 > >> > > >=20 > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > >=20 > >> > > >=20 > >> > i've been sticking other "XML like" records under this (icsg1.1 = data, > >=20 > >> > etc...). > >=20 > >> > > >=20 > >> > pretty easy to do, just generate the "other standards" xml (or = json or > >=20 > >> > whatever), embed it there. turns iodef into a sharing platform = for > >=20 > >> > other data-types w/o having to extend it too much. > >=20 > >> > > >=20 > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >=20 > >> > > >=20 > >> > So, maybe we could extend the IODEF as described in Figure 1 of = the > >=20 > >> > attached txt file. (correct me if I'm wrong) We could define > >=20 > >> > Incident.EventData.AdditionalData elements and describe them by = using > >=20 > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >=20 > >> > Regarding OVAL, we might define Incident.AdditionalData element, = but I > >=20 > >> > > >=20 > >> > am not sure at this moment, thus is not described in the figure = yet. > >=20 > >> > I would like to tackle CAPEC first since I believe Kent would = like to > >=20 > >> > tackle CVE and CAPEC. > >=20 > >> > > >=20 > >> > -- > >=20 > >> > Wes > >=20 > >> > claimid.com/wesyoung > >=20 > >> > soc@ren-isac.net > >=20 > >> > > >=20 > >> > * Wes Young> > >=20 > >> > * 0xDDB6E946 - Unverified(L) > >=20 > >> > _______________________________________________ > >=20 > >> > mile mailing list > >=20 > >> > mile@ietf.org > >=20 > >> > https://www.ietf.org/mailman/listinfo/mile > >=20 > >> > _______________________________________________ > >=20 > >> > mile mailing list > >=20 > >> > mile@ietf.org > >=20 > >> > https://www.ietf.org/mailman/listinfo/mile > >=20 > >> > > >=20 > >> > _______________________________________________ > >=20 > >> > mile mailing list > >=20 > >> > mile@ietf.org > >=20 > >> > https://www.ietf.org/mailman/listinfo/mile > >=20 > >> > > >=20 > >> > _______________________________________________ > >=20 > >> > mile mailing list > >=20 > >> > mile@ietf.org > >=20 > >> > https://www.ietf.org/mailman/listinfo/mile > >=20 > >> > . > >=20 > >> > > >=20 > >> > >=20 > >> _______________________________________________ > >=20 > >> mile mailing list > >=20 > >> mile@ietf.org > >=20 > >> https://www.ietf.org/mailman/listinfo/mile > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > =20 > =20 > =20 > -- > -- > Takeshi Takahashi, Ph.D. > +81 80 3490 2971 > http://www.taketaka.com/ > =20 > = _________________________________________= ______ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Aug 19 09:37:48 2011 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 EF08C21F8B31 for ; Fri, 19 Aug 2011 09:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAiS3efowDlQ for ; Fri, 19 Aug 2011 09:37:36 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7C421F8B18 for ; Fri, 19 Aug 2011 09:37:32 -0700 (PDT) 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 p7JGcSJY006966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Aug 2011 12:38:28 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Fri, 19 Aug 2011 12:38:19 -0400 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 p7JGcJXA018623 for ; Fri, 19 Aug 2011 12:38:19 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Fri, 19 Aug 2011 12:38:18 -0400 From: To: Date: Fri, 19 Aug 2011 12:38:18 -0400 Thread-Topic: RFC6045-bis, update per ITU comments and list discussions Thread-Index: AQHMXo5mIaSIRvdFOEiwAnJNhOiIGw== 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="_002_AE31510960917D478171C79369B660FA0E051CE7F2MX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] RFC6045-bis, update per ITU comments and list discussions 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, 19 Aug 2011 16:37:49 -0000 --_002_AE31510960917D478171C79369B660FA0E051CE7F2MX06Acorpemcc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, The attached is an updated version of RFC6045 (RFC6045-bis) which is up for= determination in the ITU-T in two weeks. As a result, of the ITU-T determ= ination, the document needs to move to standards track and a -bis version i= s required. The ITU has requested text changes since the document will be = translated into a number of other languages, those changes are reflected in= this version. Additional textual changes may be made over the next two we= eks through their review process. A few changes to RID have been made per comments on this list and I would l= ike to get opinions on how they are addressed in the attached, specifically= on the changes outlined below: "LawEnforcement" was added as a RIDPolicy option in text and in schema. Th= is was added as a result of some on and off-list discussions as the option = is relevant today for Law enforcement that already accepts incidents in an = IODEF format. IODEF is required in Japan when sending incidents to law enf= orcement. Through Dr. Katherine Goodier and Gaus (Damir Rajnovic) work on the privacy= and data marking extension, they determined stricter guidance was needed f= or encryption options. Guidance has been added to the Security section for= XML encryption using the already defined IODEF:restriction attribute. The= text is as follows for ease of review: ________ Security, XML encryption section: o The iodef:restriction attribute sets expectations for the privacy of an incident and is defined in section 3.2 of RFC5070. The restriction attribute can be set in any of the RID classes to define restrictions for the complete exchange of an IODEF document (including any extensions) or within specific classes of IODEF or IODEF extensions where more limited restrictions are desired. The restriction attribute is contained in each of the RID classes and MUST be used in accordance with privacy expectations for either sections of the IODEF document or the complete IODEF document. Consortiums and organizations should consider this guidance when creating exchange policies. o Expectations based on restriction setting: * If restriction is set to "private", the class or document MUST be encrypted for the recipient using XML encryption and the public key of the recipient. * If restriction is set to "need-to-know", the class or document MUST be encrypted to ensure only those with need-to-know access can decrypt the data. The document can either be encrypted for each individual for which access is intended or a single group key may be used. A group key in this instance refers to a single key (symmetric) that is used to encrypt the block of data. The users with need-to-know access privileges may be given access to the shared key by distributing or providing access to it encrypted with each of their public keys. * If restriction is set to "public", the class or document MUST be sent in clear text. This setting can be critical if certain sections of a document or an entire document are to be shared without restrictions. This provides flexibility within an incident to share out certain information freely where appropriate. * If restriction is set to "default", The information can be shared according to an information disclosure policy pre- arranged by the communicating parties. o Expectations based on placement of the restriction setting: * If restriction is set within one of the RID classes, the restriction applies to the entire IODEF document. * If restriction is set within individual IODEF classes, the restriction applies to the specific IODEF class and the children of that class. _________ Since incidents may not be network-centric and may still have a use case wh= ere the information received is not directly from the originator, the digit= al signature on the IP packet may need an alternate option for verifying th= e source. I am proposing the use of EventData where each party that adds t= o the event data would provide a detached digital signature. Another optio= n (not in the document) would be to include a default IP packet, bit I thin= k that could be confusing. The text is as follows: ________ Security, XML Digital Signature Section: o If an Investigation request does not include an IP packet, the EventData class instance from each the parties involved in the investigation MUST be signed using a detached signature. The EventData class can be used to extend information about an incident by each CSIRT or SP involved in the investigation. Using this class for the digital signature when an IP Packet is not included provides a method to verify each party contributing to the details of the incident. _________ Sections removed: 1.3, Attack Types and RID Messaging, Section 2, RID Integration with Network Provider Technologies 3 Characteristics of an Attack and subsections - should this be in an appen= dix or where it was in the document? Section on RID Communication flow removed text as it was not relevant to th= e heading, may need to be moved to subsections if content is not addressed already Some sections were re-ordered, I will go back to update section references = in the next version. Thank you in advance! Kathleen --_002_AE31510960917D478171C79369B660FA0E051CE7F2MX06Acorpemcc_ Content-Type: text/rtf; name="draft-Moriarty-mile-RFC6045-bis-00-done.rtf" Content-Description: draft-Moriarty-mile-RFC6045-bis-00-done.rtf Content-Disposition: attachment; filename="draft-Moriarty-mile-RFC6045-bis-00-done.rtf"; size=161650; creation-date="Fri, 19 Aug 2011 12:08:35 GMT"; modification-date="Fri, 19 Aug 2011 12:08:35 GMT" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcY29jb2FydGYxMTM4XGNvY29hc3VicnRmMTAwCntcZm9u dHRibFxmMFxmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyO30Ke1xjb2xvcnRibDtccmVkMjU1XGdy ZWVuMjU1XGJsdWUyNTU7fQpcdmlld3cxMDgwMFx2aWV3aDg0MDBcdmlld2tpbmQwClxkZWZ0YWI3 MjAKXHBhcmRccGFyZGVmdGFiNzIwCgpcZjBcZnMyNCBcY2YwIFwKSW5kaXZpZHVhbCBTdWJtaXNz aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEsuIE1vcmlhcnR5XApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBFTUNcCkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAg ICAgICAgICAgICAgICAgIEF1Z3VzdCAxOSwgMjAxMVwKRXhwaXJlczogRmVicnVhcnkgMjAsIDIw MTJcClwKXAogICAgICAgICAgICAgICAgIFJlYWwtdGltZSBJbnRlci1uZXR3b3JrIERlZmVuc2Ug KFJJRClcCiAgICAgICAgICAgICAgICAgIGRyYWZ0LU1vcmlhcnR5LW1pbGUtUkZDNjA0NS1iaXMu dHh0XApcCkFic3RyYWN0XApcCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgbWlub3IgdXBkYXRl cyB0byBSZWFsLXRpbWUgSW50ZXItbmV0d29ya1wKICAgRGVmZW5zZSAoUklEKSBbUkZDNjA0NV0u ICBOZXR3b3JrIHNlY3VyaXR5IGluY2lkZW50cywgc3VjaCBhcyBzeXN0ZW1cCiAgIGNvbXByb21p c2VzLCB3b3JtcywgdmlydXNlcywgcGhpc2hpbmcgaW5jaWRlbnRzLCBhbmQgZGVuaWFsIG9mXAog ICBzZXJ2aWNlLCB0eXBpY2FsbHkgcmVzdWx0IGluIHRoZSBsb3NzIG9mIHNlcnZpY2UsIGRhdGEs IGFuZCByZXNvdXJjZXNcCiAgIGJvdGggaHVtYW4gYW5kIHN5c3RlbS4gIE5ldHdvcmsgcHJvdmlk ZXJzIGFuZCBDb21wdXRlciBTZWN1cml0eVwKICAgSW5jaWRlbnQgUmVzcG9uc2UgVGVhbXMgbmVl ZCB0byBiZSBlcXVpcHBlZCBhbmQgcmVhZHkgdG8gYXNzaXN0IGluXAogICBjb21tdW5pY2F0aW5n IGFuZCB0cmFjaW5nIHNlY3VyaXR5IGluY2lkZW50cyB3aXRoIHRvb2xzIGFuZFwKICAgcHJvY2Vk dXJlcyBpbiBwbGFjZSBiZWZvcmUgdGhlIG9jY3VycmVuY2Ugb2YgYW4gYXR0YWNrLiAgUmVhbC10 aW1lXAogICBJbnRlci1uZXR3b3JrIERlZmVuc2UgKFJJRCkgb3V0bGluZXMgYSBwcm9hY3RpdmUg aW50ZXItbmV0d29ya1wKICAgY29tbXVuaWNhdGlvbiBtZXRob2QgdG8gZmFjaWxpdGF0ZSBzaGFy aW5nIGluY2lkZW50IGhhbmRsaW5nIGRhdGFcCiAgIHdoaWxlIGludGVncmF0aW5nIGV4aXN0aW5n IGRldGVjdGlvbiwgdHJhY2luZywgc291cmNlIGlkZW50aWZpY2F0aW9uLFwKICAgYW5kIG1pdGln YXRpb24gbWVjaGFuaXNtcyBmb3IgYSBjb21wbGV0ZSBpbmNpZGVudCBoYW5kbGluZyBzb2x1dGlv bi5cCiAgIENvbWJpbmluZyB0aGVzZSBjYXBhYmlsaXRpZXMgaW4gYSBjb21tdW5pY2F0aW9uIHN5 c3RlbSBwcm92aWRlcyBhIHdheVwKICAgdG8gYWNoaWV2ZSBoaWdoZXIgc2VjdXJpdHkgbGV2ZWxz IG9uIG5ldHdvcmtzLiAgUG9saWN5IGd1aWRlbGluZXMgZm9yXAogICBoYW5kbGluZyBpbmNpZGVu dHMgYXJlIHJlY29tbWVuZGVkIGFuZCBjYW4gYmUgYWdyZWVkIHVwb24gYnkgYVwKICAgY29uc29y dGl1bSB1c2luZyB0aGUgc2VjdXJpdHkgcmVjb21tZW5kYXRpb25zIGFuZCBjb25zaWRlcmF0aW9u cy5cClwKU3RhdHVzIG9mIHRoaXMgTWVtb1wKXAogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1 Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlXAogICBwcm92aXNpb25zIG9mIEJD UCA3OCBhbmQgQkNQIDc5LlwKXAogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZ1wKICAgVGFzayBGb3JjZSAoSUVURikuICBO b3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGVcCiAgIHdvcmtpbmcgZG9j dW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt XAogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJy ZW50Ly5cClwKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9y IGEgbWF4aW11bSBvZiBzaXggbW9udGhzXAogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueVwKICAgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2VcCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiJc ClwKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBGZWJydWFyeSAyMCwgMjAx Mi5cClwKQ29weXJpZ2h0IE5vdGljZVwKXAogICBDb3B5cmlnaHQgKGMpIDIwMTEgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGVcClwKXApcCk1vcmlhcnR5ICAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAx XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAg ICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0 cyByZXNlcnZlZC5cClwKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbFwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv Y3VtZW50c1wKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mXAogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxl YXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHNcCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmli ZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdFwKICAgdG8gdGhpcyBk b2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11 c3RcCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuZSBvZlwKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBw cm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzXAogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZp ZWQgQlNEIExpY2Vuc2UuXApcClwKVGFibGUgb2YgQ29udGVudHNcClwKICAgMS4gIEludHJvZHVj dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0 XAogICAgIDEuMS4gIE5vcm1hdGl2ZSBhbmQgSW5mb3JtYXRpdmUgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDVcCiAgICAgMS4yLiAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNlwKICAgMi4gIENvbW11bmljYXRpb24g YmV0d2VlbiBDU0lSVHMgYW5kIFNlcnZpY2UgUHJvdmlkZXJzIC4gLiAuIC4gLiAuICA2XAogICAg IDIuMS4gIEludGVyLW5ldHdvcmsgUHJvdmlkZXIgUklEIE1lc3NhZ2luZyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDhcCiAgICAgMi4yLiAgUklEIENvbW11bmljYXRpb24gVG9wb2xvZ3kgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMFwKICAgICAyLjMuICBNZXNzYWdlIEZvcm1hdHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExXAogICAgIDIuNC4g IFJJRCBEYXRhIFR5cGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTFcCiAgICAgICAyLjQuMS4gIEJvb2xlYW4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMVwKICAgICAyLjUuICBSSUQgTWVzc2FnZSBUeXBlcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExXAogICAzLiAgSU9ERUYtUklE IFNjaGVtYSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTJc CiAgICAgMy4xLiAgUklEUG9saWN5IENsYXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNFwKICAgICAzLjIuICBSZXF1ZXN0U3RhdHVzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5XAogICAgIDMuMy4gIEluY2lkZW50U291 cmNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjFcCiAgICAg My40LiAgUklEIE5hbWUgU3BhY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyMlwKICAgNC4gIFJJRCBNZXNzYWdlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyXAogICAgIDQuMS4gIFRyYWNlUmVxdWVzdCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjJcCiAgICAgNC4yLiAg UmVxdWVzdEF1dGhvcml6YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyNFwKICAgICA0LjMuICBSZXN1bHQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDI0XAogICAgIDQuNC4gIEludmVzdGlnYXRpb24gUmVxdWVzdCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjZcCiAgICAgNC41LiAgUmVwb3J0 IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOFwK ICAgICA0LjYuICBJbmNpZGVudFF1ZXJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDI5XAogICA1LiAgUklEIENvbW11bmljYXRpb24gRXhjaGFuZ2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzBcCiAgICAgNS4xLiAgVXBzdHJlYW0gVHJh Y2UgQ29tbXVuaWNhdGlvbiBGbG93ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMVwKICAgICAg IDUuMS4xLiAgUklEIFRyYWNlUmVxdWVzdCBFeGFtcGxlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDMyXAogICAgICAgNS4xLjIuICBSZXF1ZXN0QXV0aG9yaXphdGlvbiBNZXNzYWdlIEV4 YW1wbGUgLiAuIC4gLiAuIC4gLiAuIC4gMzVcCiAgICAgICA1LjEuMy4gIFJlc3VsdCBNZXNzYWdl IEV4YW1wbGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNlwKICAgICA1LjIuICBJ bnZlc3RpZ2F0aW9uIFJlcXVlc3QgQ29tbXVuaWNhdGlvbiBGbG93IC4gLiAuIC4gLiAuIC4gLiAu IDM5XAogICAgICAgNS4yLjEuICBJbnZlc3RpZ2F0aW9uIFJlcXVlc3QgRXhhbXBsZSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDBcCiAgICAgICA1LjIuMi4gIFJlcXVlc3RBdXRob3JpemF0aW9u IE1lc3NhZ2UgRXhhbXBsZSAuIC4gLiAuIC4gLiAuIC4gLiA0MVwKICAgICA1LjMuICBSZXBvcnQg Q29tbXVuaWNhdGlvbiBGbG93ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQyXAog ICAgICAgNS4zLjEuICBSZXBvcnQgRXhhbXBsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDNcCiAgICAgNS40LiAgSW5jaWRlbnRRdWVyeSBDb21tdW5pY2F0aW9uIEZs b3cgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NFwKXApcClwKTW9yaWFydHkgICAgICAgICAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDJdXApc CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAg ICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgICA1LjQuMS4gIEluY2lkZW50UXVlcnkgRXhhbXBs ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NVwKICAgNi4gIFJJRCBTY2hlbWEg RGVmaW5pdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ2XAog ICA3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNTBcCiAgICAgNy4xLiAgTWVzc2FnZSBUcmFuc3BvcnQgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1M1wKICAgICA3LjIuICBNZXNzYWdlIERlbGl2 ZXJ5IFByb3RvY29sIC0gSW50ZWdyaXR5IGFuZFwKICAgICAgICAgICBBdXRoZW50aWNhdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU0XAogICAgIDcuMy4g IFRyYW5zcG9ydCBDb21tdW5pY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNTRcCiAgICAgNy40LiAgQXV0aGVudGljYXRpb24gb2YgUklEIFByb3RvY29sIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1NVwKICAgICAgIDcuNC4xLiAgTXVsdGktSG9wIFRyYWNlUmVx dWVzdCBBdXRoZW50aWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIDU2XAogICAgIDcuNS4gIENvbnNv cnRpdW1zIGFuZCBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlcyAuIC4gLiAuIC4gLiAuIC4gNTdc CiAgICAgNy42LiAgUHJpdmFjeSBDb25jZXJucyBhbmQgU3lzdGVtIFVzZSBHdWlkZWxpbmVzIC4g LiAuIC4gLiAuIC4gLiA1OFwKICAgOC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYzXAogICA5LiAgU3VtbWFyeSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjNcCiAgIDEw LiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA2NFwKICAgICAxMC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY0XAogICAgIDEwLjIuIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjVcCiAgIEF1dGhvcidz IEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA2NVwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApc ClwKXApcClwKXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDIwLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgM11cClwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwK MS4gIEludHJvZHVjdGlvblwKXAogICBTaW5jZSB0aGUgc3BlY2lmaWNhdGlvbiBvZiBSSUQgW1JG QzYwNDVdLCB0aGUgSW50ZXJuYXRpb25hbFwKICAgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uIChJ VFUpIGhhcyBpbmNvcnBvcmF0ZWQgUkZDNjA0NSBpbiB0aGUgc2V0IG9mXAogICBwcm90b2NvbHMg Zm9yIEN5YmVyc2VjdXJpdHkgRXhjaGFuZ2UgKENZQkVYKSBpbiBTdHVkeSBHcm91cCAxN1wKICAg ZXhwYW5kaW5nIHRoZSB1c2UgYW5kIGludGVyZXN0IGluIHRoaXMgd29yay4gIEVkaXRzIHJlZmxl Y3RlZCBpbiB0aGlzXAogICB1cGRhdGVkIHZlcnNpb24gb2YgUkZDNjA0NSBhcmUgYSByZWZsZWN0 aW9uIG9mIHRoZSBJVFUtVCByZXZpZXcgYW5kXAogICBmdXJ0aGVyIHJlY29tbWVuZGF0aW9ucyBm cm9tIElURUYgcGFydGljaXBhbnRzLiAgVGhlIHNjaGVtYSByZW1haW5zXAogICB0aGUgc2FtZSB3 aXRoIHRoZSBleGNlcHRpb24gb2YgYW4gdXBkYXRlIGZvciBhIHByZXZpb3VzbHkgcmVwb3J0ZWRc CiAgIGVycmF0YS4gIEd1aWRhbmNlIGhhcyBpbXByb3ZlZCBmb3IgdGhlIGhhbmRsaW5nIG9mIHBy aXZhY3kgYW5kIG90aGVyXAogICBkYXRhIG1hcmtlcnMgdG8gZW5zdXJlIHRoZSBjb25zaXN0ZW50 IGFwcGxpY2F0aW9uIG9mIHNlY3VyaXR5XAogICBjb250cm9scyBpbiBkaWZmZXJlbnQgaW1wbGVt ZW50YXRpb25zLlwKXAogICBPcmdhbml6YXRpb25zIHJlcXVpcmUgaGVscCBmcm9tIG90aGVyIHBh cnRpZXMgdG8gaWRlbnRpZnkgaW5jaWRlbnRzLFwKICAgbWl0aWdhdGUgbWFsaWNpb3VzIGFjdGl2 aXR5IHRhcmdldGluZyB0aGVpciBjb21wdXRpbmcgcmVzb3VyY2VzLCBhbmRcCiAgIHRvIGdhaW4g aW5zaWdodCBpbnRvIHBvdGVudGlhbCB0aHJlYXRzIHRocm91Z2ggdGhlIHNoYXJpbmcgb2ZcCiAg IGluZm9ybWF0aW9uLiAgVGhpcyBjb29yZGluYXRpb24gbWlnaHQgZW50YWlsIHdvcmtpbmcgd2l0 aCBhIHNlcnZpY2VcCiAgIHByb3ZpZGVyIChTUCkgdG8gZmlsdGVyIGF0dGFjayB0cmFmZmljLCB3 b3JraW5nIHdpdGggYSBTUCB0byByZXNvbHZlXAogICBhIGNvbmZpZ3VyYXRpb24gaXNzdWUgdW5p bnRlbnRpb25hbGx5IGNhdXNpbmcgcHJvYmxlbXMsIGNvbnRhY3RpbmcgYVwKICAgcmVtb3RlIHNp dGUgdG8gdGFrZSBkb3duIGEgYm90LSBuZXR3b3JrLCBvciBzaGFyaW5nIHdhdGNoLWxpc3RzIG9m XAogICBrbm93biBtYWxpY2lvdXMgSVAgYWRkcmVzc2VzIGluIGEgY29uc29ydGl1bS5cClwKICAg SW5jaWRlbnQgaGFuZGxpbmcgaW52b2x2ZXMgdGhlIGRldGVjdGlvbiwgcmVwb3J0aW5nLCBpZGVu dGlmaWNhdGlvbixcCiAgIGFuZCBtaXRpZ2F0aW9uIG9mIGFuIGluY2lkZW50LCB3aGV0aGVyIGl0 IGJlIGEgYmVuaWduIGNvbmZpZ3VyYXRpb25cCiAgIGlzc3VlLCBJVCBpbmNpZGVudCwgYW4gaW5m cmFjdGlvbiB0byBhIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IChTTEEpLFwKICAgc3lzdGVtIGNv bXByb21pc2UsIHNvY2lhbGx5IGVuZ2luZWVyZWQgcGhpc2hpbmcgYXR0YWNrLCBvciBhIGRlbmlh bC1cCiAgIG9mLXNlcnZpY2UgKERvUykgYXR0YWNrLCBldGMuLiAgV2hlbiBhbiBpbmNpZGVudCBp cyBkZXRlY3RlZCwgdGhlXAogICByZXNwb25zZSBtYXkgaW5jbHVkZSBzaW1wbHkgZmlsaW5nIGEg cmVwb3J0LCBub3RpZmljYXRpb24gdG8gdGhlXAogICBzb3VyY2Ugb2YgdGhlIGluY2lkZW50LCBh IHJlcXVlc3QgdG8gYSBTUCBmb3IgcmVzb2x1dGlvbi9taXRpZ2F0aW9uLFwKICAgb3IgYSByZXF1 ZXN0IHRvIGxvY2F0ZSB0aGUgc291cmNlLiAgT25lIG9mIHRoZSBtb3JlIGRpZmZpY3VsdCBjYXNl c1wKICAgaXMgdGhhdCBpbiB3aGljaCB0aGUgc291cmNlIG9mIGFuIGF0dGFjayBpcyB1bmtub3du LCByZXF1aXJpbmcgdGhlXAogICBhYmlsaXR5IHRvIHRyYWNlIHRoZSBhdHRhY2sgdHJhZmZpYyBp dGVyYXRpdmVseSB1cHN0cmVhbSB0aHJvdWdoIHRoZVwKICAgbmV0d29yayBmb3IgdGhlIHBvc3Np YmlsaXR5IG9mIGFueSBmdXJ0aGVyIGFjdGlvbnMgdG8gdGFrZSBwbGFjZS4gIEluXAogICBjYXNl cyB3aGVuIGFjY3VyYXRlIHJlY29yZHMgb2YgYW4gYWN0aXZlIHNlc3Npb24gYmV0d2VlbiB0aGUg dGFyZ2V0XAogICBvciB2aWN0aW0gc3lzdGVtIGFuZCB0aGUgc291cmNlIG9yIGF0dGFja2luZyBz eXN0ZW0gYXJlIGF2YWlsYWJsZSxcCiAgIHRoZSBzb3VyY2UgaXMgZWFzeSB0byBpZGVudGlmeS5c ClwKICAgUmVhbC10aW1lIGludGVyLW5ldHdvcmsgZGVmZW5zZSAoUklEKSBvdXRsaW5lcyBhIHBy b2FjdGl2ZSBpbnRlci1cCiAgIG5ldHdvcmsgY29tbXVuaWNhdGlvbiBtZXRob2QgdG8gZmFjaWxp dGF0ZSBzaGFyaW5nIGluY2lkZW50IGhhbmRsaW5nXAogICBkYXRhIHdoaWxlIGludGVncmF0aW5n IGV4aXN0aW5nIGRldGVjdGlvbiwgdHJhY2luZywgc291cmNlXAogICBpZGVudGlmaWNhdGlvbiwg YW5kIG1pdGlnYXRpb24gbWVjaGFuaXNtcyBmb3IgYSBjb21wbGV0ZSBpbmNpZGVudFwKICAgaGFu ZGxpbmcgc29sdXRpb24uICBSSUQgcHJvdmlkZXMgYSBzZWN1cmUgbWV0aG9kIHRvIGNvbW11bmlj YXRlXAogICBpbmNpZGVudCBpbmZvcm1hdGlvbiwgZW5hYmxpbmcgdGhlIGV4Y2hhbmdlIG9mIGlu Y2lkZW50IG9iamVjdFwKICAgZGVzY3JpcHRpb24gYW5kIGV4Y2hhbmdlIGZvcm1hdCAoSU9ERUYp IFtSRkM1MDcwXSBleHRlbnNpYmxlIG1hcmt1cFwKICAgbGFuZ3VhZ2UgKFhNTCkgZG9jdW1lbnRz LiAgUklEIGNvbnNpZGVycyBzZWN1cml0eSwgcG9saWN5LCBhbmRcCiAgIHByaXZhY3kgaXNzdWVz IHJlbGF0ZWQgdG8gdGhlIGV4Y2hhbmdlIG9mIHBvdGVudGlhbGx5IHNlbnNpdGl2ZVwKICAgaW5m b3JtYXRpb24sIGVuYWJsaW5nIHNlcnZpY2UgcHJvdmlkZXJzIG9yIG9yZ2FuaXphdGlvbnMgdGhl IG9wdGlvbnNcCiAgIHRvIG1ha2UgYXBwcm9wcmlhdGUgZGVjaXNpb25zIGFjY29yZGluZyB0byB0 aGVpciBwb2xpY2llcy4gIFJJRFwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDRdXApcCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3Qg MjAxMVwKXApcCiAgIGluY2x1ZGVzIHByb3Zpc2lvbnMgZm9yIGNvbmZpZGVudGlhbGl0eSwgaW50 ZWdyaXR5LCBhbmRcCiAgIGF1dGhlbnRpY2F0aW9uLlwKXAogICBUaGUgZGF0YSBpbiBSSUQgbWVz c2FnZXMgaXMgcmVwcmVzZW50ZWQgaW4gYW4gWE1MIFtYTUwxLjBdIGRvY3VtZW50XAogICB1c2lu ZyB0aGUgSU9ERUYgYW5kIFJJRC4gIEJ5IGZvbGxvd2luZyB0aGlzIG1vZGVsLCBpbnRlZ3JhdGlv biB3aXRoXAogICBvdGhlciBhc3BlY3RzIGZvciBpbmNpZGVudCBoYW5kbGluZyBpcyBzaW1wbGlm aWVkLiAgTWV0aG9kcyBhcmVcCiAgIGluY29ycG9yYXRlZCBpbnRvIHRoZSBjb21tdW5pY2F0aW9u IHN5c3RlbSB0byBpbmRpY2F0ZSB3aGF0IGFjdGlvbnNcCiAgIG5lZWQgdG8gYmUgdGFrZW4gY2xv c2VzdCB0byB0aGUgc291cmNlIGluIG9yZGVyIHRvIGhhbHQgb3IgbWl0aWdhdGVcCiAgIHRoZSBl ZmZlY3RzIG9mIHRoZSBpbmNpZGVudCBvciBhdHRhY2sgYXQgaGFuZC4gIFJJRCBpcyBpbnRlbmRl ZCB0b1wKICAgcHJvdmlkZSBhIG1ldGhvZCB0byBjb21tdW5pY2F0ZSB0aGUgcmVsZXZhbnQgaW5m b3JtYXRpb24gYmV0d2VlblwKICAgY29tcHV0ZXIgc2VjdXJpdHkgaW5jaWRlbnQgcmVzcG9uc2Ug dGVhbXMgKENTSVJUcykgd2hpbGUgYmVpbmdcCiAgIGNvbXBhdGlibGUgd2l0aCBhIHZhcmlldHkg b2YgZXhpc3RpbmcgYW5kIHBvc3NpYmxlIGZ1dHVyZSBkZXRlY3Rpb25cCiAgIHRyYWNpbmcgYW5k IHJlc3BvbnNlIGFwcHJvYWNoZXMuICBJbmNpZGVudHMgbWF5IGJlIGV4dGVuZGVkIHRvXAogICBp bmNsdWRlIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kgKElUKSBpbmNpZGVudHMsIHdoZXJlIFJJRCBl bmFibGVzIHRoZVwKICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIG9yIHdpdGhpbiBwcm92aWRlcnMg Zm9yIG5vbi1zZWN1cml0eSBJVFwKICAgaW5jaWRlbnRzLlwKXAogICBTZWN1cml0eSBhbmQgcHJp dmFjeSBjb25zaWRlcmF0aW9ucyBhcmUgb2YgaGlnaCBjb25jZXJuIHNpbmNlXAogICBwb3RlbnRp YWxseSBzZW5zaXRpdmUgaW5mb3JtYXRpb24gbWF5IGJlIHBhc3NlZCB0aHJvdWdoIFJJRCBtZXNz YWdlcy5cCiAgIFJJRCBtZXNzYWdpbmcgdGFrZXMgYWR2YW50YWdlIG9mIFhNTCBzZWN1cml0eSBh bmQgcHJpdmFjeSBwb2xpY3lcCiAgIGluZm9ybWF0aW9uIHNldCBpbiB0aGUgUklEIHNjaGVtYS4g IFRoZSBSSUQgc2NoZW1hIGFjdHMgYXMgYW4gWE1MXAogICBlbnZlbG9wZSB0byBzdXBwb3J0IHRo ZSBjb21tdW5pY2F0aW9uIG9mIElPREVGIGRvY3VtZW50cyBmb3JcCiAgIGV4Y2hhbmdpbmcgb3Ig dHJhY2luZyBpbmZvcm1hdGlvbiByZWdhcmRpbmcgaW5jaWRlbnRzLiAgUklEIG1lc3NhZ2VzXAog ICBhcmUgZW5jYXBzdWxhdGVkIGZvciB0cmFuc3BvcnQsIHdoaWNoIGlzIGRlZmluZWQgaW4gYSBz ZXBhcmF0ZVwKICAgZG9jdW1lbnQgW1JGQzYwNDZdIFtSRkM2MDQ2XS4gIFRoZSBhdXRoZW50aWNh dGlvbiwgaW50ZWdyaXR5LCBhbmRcCiAgIGF1dGhvcml6YXRpb24gZmVhdHVyZXMgUklEIGFuZCBS SUQgdHJhbnNwb3J0IG9mZmVyIGFyZSB1c2VkIHRvXAogICBhY2hpZXZlIGEgbmVjZXNzYXJ5IGxl dmVsIG9mIHNlY3VyaXR5LlwKXAogICBDb29yZGluYXRpbmcgd2l0aCBvdGhlciBDU0lSVHMgaXMg bm90IHN0cmljdGx5IGEgdGVjaG5pY2FsIHByb2JsZW0uXAogICBUaGVyZSBhcmUgbnVtZXJvdXMg cHJvY2VkdXJhbCwgdHJ1c3QsIGFuZCBsZWdhbCBjb25zaWRlcmF0aW9ucyB0aGF0XAogICBtaWdo dCBwcmV2ZW50IGFuIG9yZ2FuaXphdGlvbiBmcm9tIHNoYXJpbmcgaW5mb3JtYXRpb24uICBSSUQg cHJvdmlkZXNcCiAgIGluZm9ybWF0aW9uIGFuZCBvcHRpb25zIHRoYXQgY2FuIGJlIHVzZWQgYnkg b3JnYW5pemF0aW9ucyB3aG8gbXVzdFwKICAgdGhlbiBhcHBseSB0aGVpciBvd24gcG9saWNpZXMg Zm9yIHNoYXJpbmcgaW5mb3JtYXRpb24uICBPcmdhbml6YXRpb25zXAogICBtdXN0IGRldmVsb3Ag cG9saWNpZXMgYW5kIHByb2NlZHVyZXMgZm9yIHRoZSB1c2Ugb2YgdGhlIFJJRCBwcm90b2NvbFwK ICAgYW5kIElPREVGLlwKXAoxLjEuICBOb3JtYXRpdmUgYW5kIEluZm9ybWF0aXZlXApcCiAgIFRo ZSBYTUwgc2NoZW1hIFtYTUxzY2hlbWFdIGFuZCB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGNvbnRh aW5lZCBpblwKICAgdGhpcyBkb2N1bWVudCBhcmUgbm9ybWF0aXZlOyBhbGwgb3RoZXIgaW5mb3Jt YXRpb24gcHJvdmlkZWQgaXNcCiAgIGludGVuZGVkIGFzIGluZm9ybWF0aXZlLiAgTW9yZSBzcGVj aWZpY2FsbHksIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnNcCiAgIG9mIHRoaXMgZG9jdW1lbnQgYXJl IGludGVuZGVkIGFzIGluZm9ybWF0aXZlOiBTZWN0aW9ucyAxLCAyLCBhbmQgMztcCiAgIGFuZCB0 aGUgc3ViLXNlY3Rpb25zIG9mIDQgaW5jbHVkaW5nIHRoZSBpbnRyb2R1Y3Rpb24gdG8gNCwgNC4x LCBhbmRcCiAgIDQuMi4gIFRoZSBmb2xsb3dpbmcgc2VjdGlvbnMgb2YgdGhpcyBkb2N1bWVudCBh cmUgbm9ybWF0aXZlOiBUaGUgc3ViLVwKICAgc2VjdGlvbnMgb2YgNCBpbmNsdWRpbmcgNC4zLCA0 LjQsIGFuZCA0LjU7IFNlY3Rpb24gNTsgYW5kIFNlY3Rpb24gNi5cClwKXApcClwKXApcCk1vcmlh cnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAg ICBbUGFnZSA1XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMg ICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAoxLjIuICBUZXJtaW5vbG9neVwKXAog ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsXAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpc1wKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uXApcClwKMi4gIENvbW11bmljYXRpb24g YmV0d2VlbiBDU0lSVHMgYW5kIFNlcnZpY2UgUHJvdmlkZXJzXApcCiAgIE5vdGU6IFRoZSBJbnRy b2R1Y3Rpb24sIGFuZCBTdWItc2VjdGlvbnMgNC4xIGFuZCA0LjIsIGFyZVwKICAgaW5mb3JtYXRp dmUsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiByZWZlcmVuY2VzIHRvIElPREVGL1JJRCBUcmFuc3Bv cnRcCiAgIFJGQzYwNDYgW1JGQzYwNDZdLiAgU3ViLXNlY3Rpb25zIDQuMywgNC40LCBhbmQgNC41 IGFyZSBub3JtYXRpdmUuXApcCiAgIEV4cGVkaXRpbmcgdGhlIGNvbW11bmljYXRpb24gYmV0d2Vl biBDU0lSVHMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzXAogICAoU1ApIGlzIGVzc2VudGlhbCB3aGVu IHJlc3BvbmRpbmcgdG8gYSBzZWN1cml0eS1yZWxhdGVkIGluY2lkZW50LFwKICAgd2hpY2ggbWF5 IGNyb3NzIG5ldHdvcmsgYWNjZXNzIHBvaW50cyAoSW50ZXJuZXQgYmFja2JvbmVzIG9yIGNsb3Vk XAogICBpbmZyYXN0cnVjdHVyZXMpIGJldHdlZW4gc2VydmljZSBvciBuZXR3b3JrIHByb3ZpZGVy cy4gIEFzIGEgcmVzdWx0XAogICBvZiB0aGUgdXJnZW5jeSBpbnZvbHZlZCBpbiB0aGlzIGludGVy LXNlcnZpY2UgcHJvdmlkZXIgc2VjdXJpdHlcCiAgIGluY2lkZW50IGNvbW11bmljYXRpb24sIHRo ZXJlIG11c3QgYmUgYW4gZWZmZWN0aXZlIHN5c3RlbSBpbiBwbGFjZSB0b1wKICAgZmFjaWxpdGF0 ZSB0aGUgaW50ZXJhY3Rpb24uICBUaGlzIGNvbW11bmljYXRpb24gcG9saWN5IG9yIG1ldGhvZFwK ICAgc2hvdWxkIGludm9sdmUgbXVsdGlwbGUgbWVhbnMgb2YgY29tbXVuaWNhdGlvbiB0byBhdm9p ZCBhIHNpbmdsZVwKICAgcG9pbnQgb2YgZmFpbHVyZS4gIEVtYWlsIGlzIG9uZSB3YXkgdG8gdHJh bnNmZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlXAogICBpbmNpZGVudCwgcGFja2V0IHRyYWNlcywg ZXRjLiAgSG93ZXZlciwgZW1haWwgbWF5IG5vdCBiZSByZWNlaXZlZCBpblwKICAgYSB0aW1lbHkg ZmFzaGlvbiBvciBiZSBhY3RlZCB1cG9uIHdpdGggdGhlIHNhbWUgdXJnZW5jeSBhcyBhIHBob25l XAogICBjYWxsIG9yIG90aGVyIGNvbW11bmljYXRpb24gbWVjaGFuaXNtIGxpa2UgUklELlwKXAog ICBBIHRlY2huaWNhbCBzb2x1dGlvbiB0byB0cmFjZSB0cmFmZmljIGFjcm9zcyBhIHNpbmdsZSBz ZXJ2aWNlIG9yXAogICBuZXR3b3JrIHByb3ZpZGVyIG1heSBpbmNsdWRlIGhvbWVncm93biBvciBj b21tZXJjaWFsIHN5c3RlbXMgZm9yXAogICB3aGljaCBSSUQgbWVzc2FnaW5nIG11c3QgYWNjb21t b2RhdGUgdGhlIGlucHV0IHJlcXVpcmVtZW50cy4gIFRoZVwKICAgaW5jaWRlbnQgaGFuZGxpbmcg c3lzdGVtIHVzZWQgb24gdGhlIHNlcnZpY2Ugb3IgbmV0d29yayBwcm92aWRlcidzXAogICBiYWNr Ym9uZSBieSB0aGUgQ1NJUlQgdG8gY29vcmRpbmF0ZSB0aGUgdHJhY2UgYWNyb3NzIHRoZSBzaW5n bGVcCiAgIG5ldHdvcmsgcmVxdWlyZXMgYSBtZXRob2QgdG8gYWNjZXB0IGFuZCBwcm9jZXNzIGFu ZCByZWxheSBSSURcCiAgIG1lc3NhZ2VzIHRvIHRoZSBzeXN0ZW0sIGFzIHdlbGwgYXMgdG8gd2Fp dCBmb3IgcmVzcG9uc2VzIGZyb20gdGhlXAogICBzeXN0ZW0gdG8gY29udGludWUgdGhlIFJJRCBy ZXF1ZXN0IHByb2Nlc3MgYXMgYXBwcm9wcmlhdGUuICBJbiB0aGlzXAogICBzY2VuYXJpbywgZWFj aCBzZXJ2aWNlIG9yIG5ldHdvcmsgcHJvdmlkZXIgd291bGQgbWFpbnRhaW4gaXRzIG93blwKICAg c3lzdGVtIGNhcGFibGUgb2YgY29tbXVuaWNhdGluZyB2aWEgUklEIGFuZCBpbnRlZ3JhdGUgd2l0 aCBhXAogICBtYW5hZ2VtZW50IHN0YXRpb24gdXNlZCBmb3IgbW9uaXRvcmluZyBhbmQgYW5hbHlz aXMuICBBbiBhbHRlcm5hdGl2ZVwKICAgZm9yIHByb3ZpZGVycyBsYWNraW5nIHN1ZmZpY2llbnQg cmVzb3VyY2VzIG1heSBiZSB0byBoYXZlIGEgbmV1dHJhbFwKICAgdGhpcmQgcGFydHkgd2l0aCBh Y2Nlc3MgdG8gdGhlIHByb3ZpZGVyJ3MgbmV0d29yayByZXNvdXJjZXMgd2hvIGNvdWxkXAogICBi ZSB1c2VkIHRvIHBlcmZvcm0gdGhlIGluY2lkZW50IGhhbmRsaW5nIGZ1bmN0aW9ucy4gIFRoaXMg Y291bGQgYmUgYVwKICAgZnVuY3Rpb24gb2YgYSBjZW50cmFsIG9yZ2FuaXphdGlvbiBvcGVyYXRp bmcgYXMgYSBDU0lSVCBmb3IgY291bnRyaWVzXAogICBhcyBhIHdob2xlIG9yIHdpdGhpbiBhIGNv bnNvcnRpdW0gdGhhdCBtYXkgYmUgYWJsZSB0byBwcm92aWRlXAogICBjZW50cmFsaXplZCByZXNv dXJjZXMuICBBbiBleGFtcGxlIG9mIGEgY29uc29ydGl1bSBtaWdodCBpbmNsdWRlIHRoZVwKICAg Y2xvdWQgc2VydmljZSBwcm92aWRlcnMuXApcCiAgIENvbnNvcnRpdW1zIHdvdWxkIGNvbnNpc3Qg b2YgYSBncm91cCBvZiBzZXJ2aWNlIChuZXR3b3JrLCBjbG91ZCxcCiAgIGV0Yy4pIHByb3ZpZGVy cyBhbmQvb3IgQ1NJUlRzIHRoYXQgYWdyZWUgdG8gcGFydGljaXBhdGUgaW4gdGhlIFJJRFwKICAg Y29tbXVuaWNhdGlvbiBwcm90b2NvbCB3aXRoIGFuIGFncmVlZC11cG9uIHBvbGljeSBhbmQgY29t bXVuaWNhdGlvblwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAyMCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDZdXApcCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApc CiAgIHByb3RvY29sIGZhY2lsaXRhdGluZyB0aGUgc2VjdXJlIHRyYW5zcG9ydCBvZiBJT0RFRi9S SUQgWE1MXAogICBkb2N1bWVudHMuICBUcmFuc3BvcnQgZm9yIFJJRCBtZXNzYWdlcyBpcyBzcGVj aWZpZWQgaW4gdGhlIElPREVGL1JJRFwKICAgVHJhbnNwb3J0IFtYLnJpZGRdIFJlY29tbWVuZGF0 aW9uLlwKXAogICBPbmUgZ29hbCBvZiBSSUQgaXMgdG8gcHJldmVudCB0aGUgbmVlZCB0byBwZXJt aXQgYWNjZXNzIHRvIG90aGVyXAogICBuZXR3b3JrcycgZXF1aXBtZW50IHRocm91Z2ggdGhlIHVz ZSBvZiBhIHN0YW5kYXJkIG1lc3NhZ2luZyBtZWNoYW5pc21cCiAgIHRvIGVuYWJsZSB0aGUgY29t bXVuaWNhdGlvbiBvZiBpbmNpZGVudCBoYW5kbGluZyBpbmZvcm1hdGlvbiB0byBvdGhlclwKICAg cHJvdmlkZXJzIGluIGEgY29uc29ydGl1bSBvciBpbiBuZWlnaGJvcmluZyBuZXR3b3Jrcy4gIFRo ZSB0aGlyZFwKICAgcGFydHkgbWVudGlvbmVkIGFib3ZlIG1heSBiZSB1c2VkIGluIHRoaXMgdGVj aG5pY2FsIHNvbHV0aW9uIHRvXAogICBhc3Npc3QgaW4gZmFjaWxpdGF0aW5nIGluY2lkZW50IGhh bmRsaW5nIGFuZCBwb3NzaWJseSB0cmFjZWJhY2tcCiAgIHRocm91Z2ggc21hbGxlciBwcm92aWRl cnMuICBUaGUgUklEIG1lc3NhZ2luZyBtZWNoYW5pc20gbWF5IGJlIGFcCiAgIGxvZ2ljYWwgb3Ig cGh5c2ljYWwgb3V0LW9mLWJhbmQgbmV0d29yayB0byBlbnN1cmUgdGhhdCB0aGVcCiAgIGNvbW11 bmljYXRpb24gaXMgc2VjdXJlIGFuZCB1bmFmZmVjdGVkIGJ5IHRoZSBzdGF0ZSBvZiB0aGUgbmV0 d29ya1wKICAgdW5kZXIgYXR0YWNrLiAgVGhlIHR3byBtYW5hZ2VtZW50IG1ldGhvZHMgd291bGQg YWNjb21tb2RhdGUgdGhlIG5lZWRzXAogICBvZiBsYXJnZXIgcHJvdmlkZXJzIHRvIG1haW50YWlu IGZ1bGwgbWFuYWdlbWVudCBvZiB0aGVpciBuZXR3b3JrLCBhbmRcCiAgIHRoZSB0aGlyZC1wYXJ0 eSBvcHRpb24gY291bGQgYmUgYXZhaWxhYmxlIHRvIHNtYWxsZXIgcHJvdmlkZXJzIHdob1wKICAg bGFjayB0aGUgbmVjZXNzYXJ5IGh1bWFuIHJlc291cmNlcyB0byBwZXJmb3JtIGluY2lkZW50IGhh bmRsaW5nXAogICBvcGVyYXRpb25zLiAgVGhlIGZpcnN0IG1ldGhvZCBlbmFibGVzIHRoZSBpbmRp dmlkdWFsIHByb3ZpZGVycyB0b1wKICAgaW52b2x2ZSB0aGVpciBuZXR3b3JrIG9wZXJhdGlvbnMg c3RhZmYgdG8gYXV0aG9yaXplIHRoZSBjb250aW51YW5jZVwKICAgb2YgYSB0cmFjZSBvciBvdGhl ciBuZWNlc3NhcnkgcmVzcG9uc2UgdG8gYSBSSUQgY29tbXVuaWNhdGlvbiByZXF1ZXN0XAogICB0 aHJvdWdoIHRoZWlyIG5ldHdvcmsgdmlhIGEgbm90aWZpY2F0aW9uIGFuZCBhbGVydGluZyBzeXN0 ZW0uXApcCiAgIFRoZSBuZXR3b3JrIHVzZWQgZm9yIHRoZSBjb21tdW5pY2F0aW9uIHNob3VsZCBj b25zaXN0IG9mIG91dC1vZi1iYW5kXAogICBvciBwcm90ZWN0ZWQgY2hhbm5lbHMgKGRpcmVjdCBj b21tdW5pY2F0aW9uIGxpbmtzKSBvciBlbmNyeXB0ZWRcCiAgIGNoYW5uZWxzIGRlZGljYXRlZCB0 byB0aGUgdHJhbnNwb3J0IG9mIFJJRCBtZXNzYWdlcy4gIFRoZVwKICAgY29tbXVuaWNhdGlvbiBs aW5rcyB3b3VsZCBiZSBkaXJlY3QgY29ubmVjdGlvbnMgYmV0d2VlbiBwZWVycyB3aG9cCiAgIGhh dmUgYWdyZWVkLXVwb24gdXNlIGFuZCBhYnVzZSBwb2xpY2llcyB0aHJvdWdoIGEgY29uc29ydGl1 bS5cCiAgIENvbnNvcnRpdW1zIG1pZ2h0IGJlIGxpbmtlZCB0aHJvdWdoIHBvbGljeSBjb21wYXJp c29ucyBhbmQgYWRkaXRpb25hbFwKICAgYWdyZWVtZW50cyB0byBmb3JtIGEgbGFyZ2VyIHdlYiBv ciBpdGVyYXRpdmUgbmV0d29yayBvZiBwZWVycyB0aGF0XAogICBjb3JyZWxhdGVzIHRvIHRoZSB0 cmFmZmljIHBhdGhzIGF2YWlsYWJsZSBvdmVyIHRoZSBsYXJnZXIgd2ViIG9mXAogICBuZXR3b3Jr cyBvciBiYXNlZCBvbiByZWdpb25zIGFuZCBsb2dpY2FsIGdyb3Vwcy4gIENvbnRhY3RcCiAgIGlu Zm9ybWF0aW9uLCBJUCBhZGRyZXNzZXMgb2YgUklEIHN5c3RlbXMsIGFuZCBvdGhlciBpbmZvcm1h dGlvbiBtdXN0XAogICBiZSBjb29yZGluYXRlZCBiZXR3ZWVuIGJpbGF0ZXJhbCBwZWVycyBieSBh IGNvbnNvcnRpdW0gYW5kIG1heSB1c2VcCiAgIGV4aXN0aW5nIGRhdGFiYXNlcywgc3VjaCBhcyB0 aGUgcm91dGluZyBhcmJpdGVyLiAgVGhlIHNlY3VyaXR5LFwKICAgY29uZmlndXJhdGlvbiwgYW5k IGNvbmZpZGVuY2UgcmF0aW5nIHNjaGVtZXMgb2YgdGhlIFJJRCBtZXNzYWdpbmdcCiAgIHBlZXJz IG11c3QgYmUgbmVnb3RpYXRlZCBieSBwZWVycyBhbmQgbXVzdCBtZWV0IGNlcnRhaW4gb3ZlcmFs bFwKICAgcmVxdWlyZW1lbnRzIG9mIHRoZSBmdWxseSBjb25uZWN0ZWQgbmV0d29yayAoSW50ZXJu ZXQsIGdvdmVybm1lbnQsXAogICBlZHVjYXRpb24sIGV0Yy4pIHRocm91Z2ggdGhlIHBlZXJpbmcg YW5kL29yIGEgY29uc29ydGl1bS1iYXNlZFwKICAgYWdyZWVtZW50LlwKXAogICBSSUQgbWVzc2Fn aW5nIGVzdGFibGlzaGVkIHdpdGggY2xpZW50cyBvZiBhbiBwcm92aWRlciBtYXkgYmVcCiAgIG5l Z290aWF0ZWQgaW4gYSBjb250cmFjdCBhcyBwYXJ0IG9mIGEgdmFsdWUtYWRkZWQgc2VydmljZSBv ciB0aHJvdWdoXAogICBhIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IChTTEEpLiAgRnVydGhlciBk aXNjdXNzaW9uIGlzIGJleW9uZCB0aGVcCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgYW5kIG1h eSBiZSBtb3JlIGFwcHJvcHJpYXRlbHkgaGFuZGxlZCBpblwKICAgcGVlcmluZyBvciBzZXJ2aWNl IGxldmVsIGFncmVlbWVudHMuXApcCiAgIFByb2NlZHVyZXMgZm9yIGluY2lkZW50IGhhbmRsaW5n IG5lZWQgdG8gYmUgZXN0YWJsaXNoZWQgYW5kIHdlbGxcCiAgIGtub3duIGJ5IGFueW9uZSB0aGF0 IG1heSBiZSBpbnZvbHZlZCBpbiBpbmNpZGVudCByZXNwb25zZS4gIFRoZVwKXApcClwKTW9yaWFy dHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAg IFtQYWdlIDddXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAg ICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIHByb2NlZHVyZXMgc2hvdWxkIGFs c28gY29udGFpbiBjb250YWN0IGluZm9ybWF0aW9uIGZvciBpbnRlcm5hbFwKICAgZXNjYWxhdGlv biBwcm9jZWR1cmVzLCBhcyB3ZWxsIGFzIGZvciBleHRlcm5hbCBhc3Npc3RhbmNlIGdyb3VwcyBz dWNoXAogICBhcyBhIENTSVJULCBDRVJUIENvb3JkaW5hdGlvbiBDZW50ZXIgKENFUlQvQ0MpLCBH bG9iYWwgSW5mb3JtYXRpb25cCiAgIEFzc3VyYW5jZSBDZXJ0aWZpY2F0aW9uIChHSUFDKSwgYW5k IHRoZSBGQkkgb3Igb3RoZXIgYXNzaXN0aW5nXAogICBnb3Zlcm5tZW50IG9yZ2FuaXphdGlvbiBp biB0aGUgY291bnRyeSBvZiB0aGUgaW52ZXN0aWdhdGlvbi5cClwKMi4xLiAgSW50ZXItbmV0d29y ayBQcm92aWRlciBSSUQgTWVzc2FnaW5nXApcCiAgIFJJRCBwcm92aWRlcyBhIHN0YW5kYXJkIHBy b3RvY29sIGFuZCBmb3JtYXQgaXMgcmVxdWlyZWQgdG8gZW5zdXJlXAogICBpbnRlci1vcGVyYWJp bGl0eSBiZXR3ZWVuIHZlbmRvcnMgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBhblwKICAgaW5j aWRlbnQgbWVzc2FnaW5nIG1lY2hhbmlzbS4gIFRoZSBtZXNzYWdlcyB3b3VsZCBoYXZlIHRvIG1l ZXRcCiAgIHNldmVyYWwgcmVxdWlyZW1lbnRzIGluIG9yZGVyIHRvIGJlIG1lYW5pbmdmdWwgYXMg dGhleSB0cmF2ZXJzZVwKICAgbXVsdGlwbGUgbmV0d29ya3MuICBSSUQgcHJvdmlkZXMgdGhlIGZy YW1ld29yayBuZWNlc3NhcnkgZm9yXAogICBjb21tdW5pY2F0aW9uIGJldHdlZW4gbmV0d29ya3Mg aW52b2x2ZWQgaW4gdGhlIGluY2lkZW50IGhhbmRsaW5nLFwKICAgcG9zc2libGUgdHJhY2ViYWNr LCBhbmQgbWl0aWdhdGlvbiBvZiBhIHNlY3VyaXR5IGluY2lkZW50LiAgU2V2ZXJhbFwKICAgbWVz c2FnZSB0eXBlcyBkZXNjcmliZWQgaW4gY2xhdXNlIDkuMiBhcmUgbmVjZXNzYXJ5IHRvIGZhY2ls aXRhdGUgdGhlXAogICBoYW5kbGluZyBvZiBhIHNlY3VyaXR5IGluY2lkZW50LiAgVGhlIG1lc3Nh Z2UgdHlwZXMgaW5jbHVkZSB0aGVcCiAgIFJlcG9ydCwgSW5jaWRlbnRRdWVyeSwgVHJhY2VSZXF1 ZXN0LCBSZXF1ZXN0QXV0aG9yaXphdGlvbiwgUmVzdWx0LFwKICAgYW5kIHRoZSBJbnZlc3RpZ2F0 aW9uIHJlcXVlc3QgbWVzc2FnZS5cClwKICAgVGhlIFJlcG9ydCBtZXNzYWdlIGlzIHVzZWQgd2hl biBhbiBpbmNpZGVudCBpcyB0byBiZSBmaWxlZCBvbiBhIFJJRFwKICAgc3lzdGVtIG9yIGFzc29j aWF0ZWQgZGF0YWJhc2UsIHdoZXJlIG5vIGZ1cnRoZXIgYWN0aW9uIGlzIHJlcXVpcmVkLlwKICAg QW4gSW5jaWRlbnRRdWVyeSBtZXNzYWdlIGlzIHVzZWQgdG8gcmVxdWVzdCBpbmZvcm1hdGlvbiBv biBhXAogICBwYXJ0aWN1bGFyIGluY2lkZW50LiAgQSBUcmFjZVJlcXVlc3QgbWVzc2FnZSBpcyB1 c2VkIHdoZW4gdGhlIHNvdXJjZVwKICAgb2YgdGhlIHRyYWZmaWMgbWF5IGhhdmUgYmVlbiBzcG9v ZmVkLiAgSW4gdGhhdCBjYXNlLCBlYWNoIG5ldHdvcmtcCiAgIHByb3ZpZGVyIGluIHRoZSB1cHN0 cmVhbSBwYXRoIHdobyByZWNlaXZlcyBhIFRyYWNlUmVxdWVzdCB3aWxsIGlzc3VlXAogICBhIHRy YWNlIGFjcm9zcyB0aGUgbmV0d29yayB0byBkZXRlcm1pbmUgdGhlIHVwc3RyZWFtIHNvdXJjZSBv ZiB0aGVcCiAgIHRyYWZmaWMuICBUaGUgUmVxdWVzdEF1dGhvcml6YXRpb24gYW5kIFJlc3VsdCBt ZXNzYWdlcyBhcmUgdXNlZCB0b1wKICAgY29tbXVuaWNhdGUgdGhlIHN0YXR1cyBhbmQgcmVzdWx0 IG9mIGEgVHJhY2VSZXF1ZXN0IG9yIEludmVzdGlnYXRpb25cCiAgIHJlcXVlc3QuICBUaGUgSW52 ZXN0aWdhdGlvbiByZXF1ZXN0IG1lc3NhZ2Ugd291bGQgb25seSBpbnZvbHZlIHRoZVwKICAgc3lz dGVtcyBhY2NlcHRpbmcgUklEIGNvbW11bmljYXRpb24gYWxvbmcgdGhlIHBhdGggdG8gdGhlIHNv dXJjZSBvZlwKICAgdGhlIHRyYWZmaWMgYW5kIG5vdCB0aGUgdXNlIG9mIG5ldHdvcmsgdHJhY2Ug c3lzdGVtcy4gIFRoZVwKICAgSW52ZXN0aWdhdGlvbiByZXF1ZXN0IGxldmVyYWdlcyB0aGUgYmls YXRlcmFsIHJlbGF0aW9uc2hpcHMgb3IgYVwKICAgY29uc29ydGl1bSdzIGludGVyY29ubmVjdGlv bnMgdG8gbWl0aWdhdGUgb3Igc3RvcCBwcm9ibGVtYXRpYyB0cmFmZmljXAogICBjbG9zZSB0byB0 aGUgc291cmNlLiAgUm91dGVzIGNvdWxkIGRldGVybWluZSB0aGUgZmFzdGVzdCBwYXRoIHRvIGFc CiAgIGtub3duIHNvdXJjZSBJUCBhZGRyZXNzIGluIHRoZSBjYXNlIG9mIGFuIEludmVzdGlnYXRp b24gcmVxdWVzdC4gIEFcCiAgIG1lc3NhZ2Ugc2VudCBiZXR3ZWVuIFJJRCBzeXN0ZW1zIGZvciBh IFRyYWNlUmVxdWVzdCBvciBhblwKICAgSW52ZXN0aWdhdGlvbiByZXF1ZXN0IHRvIHN0b3AgdHJh ZmZpYyBhdCB0aGUgc291cmNlIHRocm91Z2ggYVwKICAgYm9yZGVyaW5nIG5ldHdvcmsgd291bGQg cmVxdWlyZSB0aGUgaW5mb3JtYXRpb24gZW51bWVyYXRlZCBiZWxvdzpcClwKICAgMS4gIEVub3Vn aCBpbmZvcm1hdGlvbiB0byBlbmFibGUgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgdG8gbWFr ZSBhXAogICAgICAgZGVjaXNpb24gYWJvdXQgdGhlIGltcG9ydGFuY2Ugb2YgY29udGludWluZyB0 aGUgdHJhY2UuXApcCiAgIDIuICBUaGUgaW5jaWRlbnQgb3IgSVAgcGFja2V0IGluZm9ybWF0aW9u IG5lZWRlZCB0byBjYXJyeSBvdXQgdGhlXAogICAgICAgdHJhY2Ugb3IgaW52ZXN0aWdhdGlvbi5c ClwKICAgMy4gIENvbnRhY3QgaW5mb3JtYXRpb24gb2YgdGhlIG9yaWdpbiBvZiB0aGUgUklEIGNv bW11bmljYXRpb24uICBUaGVcCiAgICAgICBjb250YWN0IGluZm9ybWF0aW9uIGNvdWxkIGJlIHBy b3ZpZGVkIHRocm91Z2ggdGhlIEF1dG9ub21vdXNcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA4XVwKXApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAg ICAgQXVndXN0IDIwMTFcClwKXAogICAgICAgU3lzdGVtIE51bWJlciAoQVNOKSBbUkZDMTkzMF0g b3IgTmV0d29yayBJbmZvcm1hdGlvbiBDZW50ZXIgKE5JQylcCiAgICAgICBoYW5kbGUgaW5mb3Jt YXRpb24gbGlzdGVkIGluIHRoZSBSZWdpc3RyeSBmb3IgSW50ZXJuZXQgTnVtYmVycyBvclwKICAg ICAgIG90aGVyIEludGVybmV0IGRhdGFiYXNlcy5cClwKICAgNC4gIE5ldHdvcmsgcGF0aCBpbmZv cm1hdGlvbiB0byBoZWxwIHByZXZlbnQgYW55IHJvdXRpbmcgbG9vcHNcCiAgICAgICB0aHJvdWdo IHRoZSBuZXR3b3JrIGZyb20gcGVycGV0dWF0aW5nIGEgdHJhY2UuICBJZiBhIFJJRCBzeXN0ZW1c CiAgICAgICByZWNlaXZlcyBhIFRyYWNlUmVxdWVzdCBjb250YWluaW5nIGl0cyBvd24gaW5mb3Jt YXRpb24gaW4gdGhlXAogICAgICAgcGF0aCwgdGhlIHRyYWNlIG11c3QgY2Vhc2UgYW5kIHRoZSBS SUQgc3lzdGVtIHNob3VsZCBnZW5lcmF0ZSBhblwKICAgICAgIGFsZXJ0IHRvIGluZm9ybSB0aGUg bmV0d29yayBvcGVyYXRpb25zIHN0YWZmIHRoYXQgYSB0cmFjaW5nIGxvb3BcCiAgICAgICBleGlz dHMuXApcCiAgIDUuICBBIHVuaXF1ZSBpZGVudGlmaWVyIGZvciBhIHNpbmdsZSBhdHRhY2suICBU aGlzIGlkZW50aWZpZXIgc2hvdWxkXAogICAgICAgYmUgdXNlZCB0byBjb3JyZWxhdGUgdHJhY2Vz IHRvIG11bHRpcGxlIHNvdXJjZXMgaW4gYSBERG9TIGF0dGFjay5cClwKICAgVXNlIG9mIHRoZSBj b21tdW5pY2F0aW9uIG5ldHdvcmsgYW5kIHRoZSBSSUQgcHJvdG9jb2wgbXVzdCBiZSBmb3JcCiAg IHByZS1hcHByb3ZlZCwgYXV0aG9yaXplZCBwdXJwb3NlcyBvbmx5LiAgSXQgaXMgdGhlIHJlc3Bv bnNpYmlsaXR5IG9mXAogICBlYWNoIHBhcnRpY2lwYXRpbmcgcGFydHkgdG8gYWRoZXJlIHRvIGd1 aWRlbGluZXMgc2V0IGZvcnRoIGluIGJvdGggYVwKICAgZ2xvYmFsIHVzZSBwb2xpY3kgZXN0YWJs aXNoZWQgdGhyb3VnaCB0aGUgcGVlcmluZyBhZ3JlZW1lbnRzIGZvciBlYWNoXAogICBiaWxhdGVy YWwgcGVlciBvciBhZ3JlZWQtdXBvbiBjb25zb3J0aXVtIGd1aWRlbGluZXMuICBUaGUgcHVycG9z ZSBvZlwKICAgc3VjaCBwb2xpY2llcyBpcyB0byBhdm9pZCBhYnVzZSBvZiB0aGUgc3lzdGVtOyB0 aGUgcG9saWNpZXMgc2hhbGwgYmVcCiAgIGRldmVsb3BlZCBieSBhIGNvbnNvcnRpdW0gb2YgcGFy dGljaXBhdGluZyBlbnRpdGllcy4gIFRoZSBnbG9iYWxcCiAgIHBvbGljeSBtYXkgYmUgZGVwZW5k ZW50IG9uIHRoZSBkb21haW4gaXQgb3BlcmF0ZXMgdW5kZXI7IGZvciBleGFtcGxlLFwKICAgYSBn b3Zlcm5tZW50IG5ldHdvcmsgb3IgYSBjb21tZXJjaWFsIG5ldHdvcmsgc3VjaCBhcyB0aGUgSW50 ZXJuZXRcCiAgIHdvdWxkIGFkaGVyZSB0byBkaWZmZXJlbnQgZ3VpZGVsaW5lcyB0byBhZGRyZXNz IHRoZSBpbmRpdmlkdWFsXAogICBjb25jZXJucy4gIFByaXZhY3kgaXNzdWVzIG11c3QgYmUgY29u c2lkZXJlZCBpbiBwdWJsaWMgbmV0d29ya3Mgc3VjaFwKICAgYXMgdGhlIEludGVybmV0LiAgUHJp dmFjeSBpc3N1ZXMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHlcCiAgIGNvbnNpZGVyYXRp b25zIGNsYXVzZSwgYWxvbmcgd2l0aCBvdGhlciByZXF1aXJlbWVudHMgdGhhdCBtdXN0IGJlXAog ICBhZ3JlZWQgdXBvbiBieSBwYXJ0aWNpcGF0aW5nIGVudGl0aWVzLlwKXAogICBSSUQgcmVxdWVz dHMgc2hhbGwgYmUgbGVnaXRpbWF0ZSBpbmNpZGVudHMgYW5kIG5vdCB1c2VkIGZvciBwdXJwb3Nl c1wKICAgc3VjaCBhcyBzYWJvdGFnZSBvciBjZW5zb3JzaGlwLiAgQW4gZXhhbXBsZSBvZiBzdWNo IGFidXNlIG9mIHRoZVwKICAgc3lzdGVtIHdvdWxkIGluY2x1ZGUgYSByZXF1ZXN0IHRvIHJhdGUt bGltaXQgbGVnaXRpbWF0ZSB0cmFmZmljIHRvXAogICBwcmV2ZW50IGluZm9ybWF0aW9uIGZyb20g YmVpbmcgc2hhcmVkIGJldHdlZW4gdXNlcnMgb24gdGhlIEludGVybmV0XAogICAocmVzdHJpY3Rp bmcgYWNjZXNzIHRvIG9ubGluZSB2ZXJzaW9ucyBvZiBwYXBlcnMpIG9yIHJlc3RyaWN0aW5nXAog ICBhY2Nlc3MgZnJvbSBhIGNvbXBldGl0b3IncyBwcm9kdWN0IGluIG9yZGVyIHRvIHNhYm90YWdl IGEgYnVzaW5lc3MuXApcCiAgIFRoZSBSSUQgc3lzdGVtIHNob3VsZCBiZSBjb25maWd1cmFibGUg dG8gZWl0aGVyIHJlcXVpcmUgdXNlciBpbnB1dCBvclwKICAgYXV0b21hdGljYWxseSBjb250aW51 ZSB0cmFjZXMuICBUaGlzIGZlYXR1cmUgd291bGQgZW5hYmxlIGEgbmV0d29ya1wKICAgbWFuYWdl ciB0byBhc3Nlc3MgdGhlIGF2YWlsYWJsZSByZXNvdXJjZXMgYmVmb3JlIGNvbnRpbnVpbmcgYW5c CiAgIGludmVzdGlnYXRpb24gb3IgdHJhY2UuICBJZiB0aGUgQ29uZmlkZW5jZSByYXRpbmcgKHBy b3ZpZGVkIGluIElPREVGKVwKICAgaXMgbG93LCBpdCBtYXkgbm90IGJlIGluIHRoZSBwcm92aWRl cidzIGJlc3QgaW50ZXJlc3QgdG8gY29udGludWUgdGhlXAogICBpbnZlc3RpZ2F0aW9uIG9yIHRy YWNlLiAgVGhlIENvbmZpZGVuY2UgcmF0aW5ncyBtdXN0IGFkaGVyZSB0byB0aGVcCiAgIHNwZWNp ZmljYXRpb25zIGZvciBzZWxlY3RpbmcgdGhlIHBlcmNlbnRhZ2UgdXNlZCB0byBhdm9pZCBhYnVz ZSBvZlwKICAgdGhlIHN5c3RlbS4gIFRyYWNlUmVxdWVzdHMgbXVzdCBiZSBpc3N1ZWQgYnkgYXV0 aG9yaXplZCBpbmRpdmlkdWFsc1wKICAgZnJvbSB0aGUgaW5pdGlhdGluZyBDU0lSVCwgc2V0IGZv cnRoIGluIHBvbGljeSBndWlkZWxpbmVzIGVzdGFibGlzaGVkXAogICB0aHJvdWdoIHBlZXJpbmcg b3IgYSBTTEEuXApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDldXApcCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwK XApcCjIuMi4gIFJJRCBDb21tdW5pY2F0aW9uIFRvcG9sb2d5XApcCiAgIFRoZSBtb3N0IGJhc2lj IHRvcG9sb2d5IGZvciBjb21tdW5pY2F0aW5nIFJJRCBzeXN0ZW1zIHdvdWxkIGJlIGFcCiAgIGRp cmVjdCBjb25uZWN0aW9uIG9yIGEgYmlsYXRlcmFsIHJlbGF0aW9uc2hpcCBhcyBpbGx1c3RyYXRl ZCBiZWxvdy5cClwKICAgICAgICAgICAgX19fX19fX19fX18gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgX19fX19fX19fX1wKICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfFwKICAgICAgICAgICAgfCAgUklEICAg IHxfX19fX19fX19fLS0tLS0tLS0tLS0tLV9fX19fX19fX19ffCAgUklEICAgfFwKICAgICAgICAg ICAgfF9fX19fX19fX3wgICAgICAgICAgfCBTUCBCb3JkZXIgfCAgICAgICAgICAgfF9fX19fX19f fFwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLVwKXAogICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IERpcmVjdCBQZWVyIFRvcG9sb2d5XApcCiAgIFdp dGhpbiB0aGUgY29uc29ydGl1bSBtb2RlbCwgc2V2ZXJhbCB0b3BvbG9naWVzIG1pZ2h0IGJlIGFn cmVlZCB1cG9uXAogICBhbmQgdXNlZC4gIE9uZSB3b3VsZCBsZXZlcmFnZSBiaWxhdGVyYWwgbmV0 d29yayBwZWVyaW5nIHJlbGF0aW9uc2hpcHNcCiAgIG9mIHRoZSBtZW1iZXJzIG9mIHRoZSBjb25z b3J0aXVtLiAgVGhlIHBlZXJzIGZvciBSSUQgd291bGQgbWF0Y2ggdGhhdFwKICAgb2Ygcm91dGlu ZyBwZWVycywgYW5kIHRoZSBsb2dpY2FsIG5ldHdvcmsgYm9yZGVycyB3b3VsZCBiZSB1c2VkLlwK ICAgVGhpcyBhcHByb2FjaCBtYXkgYmUgbmVjZXNzYXJ5IGZvciBhbiBpdGVyYXRpdmUgdHJhY2Ug d2hlcmUgdGhlXAogICBzb3VyY2UgaXMgdW5rbm93bi4gIFRoZSBtb2RlbCB3b3VsZCBsb29rIGxp a2UgdGhlIGFib3ZlIGRpYWdyYW07XAogICBob3dldmVyLCB0aGVyZSBtYXkgYmUgYW4gZXh0ZW5z aXZlIG51bWJlciBvZiBpbnRlcmNvbm5lY3Rpb25zIG9mXAogICBiaWxhdGVyYWwgcmVsYXRpb25z aGlwcyBmb3JtZWQuICBBbHNvIHdpdGhpbiBhIGNvbnNvcnRpdW0gbW9kZWwsIGl0XAogICBtYXkg YmUgdXNlZnVsIHRvIGVzdGFibGlzaCBhbiBpbnRlZ3JhdGVkIG1lc2ggb2YgbmV0d29ya3MgdG8g cGFzcyBSSURcCiAgIG1lc3NhZ2VzLiAgVGhpcyBtYXkgYmUgYmVuZWZpY2lhbCB3aGVuIHRoZSBz b3VyY2UgYWRkcmVzcyBpcyBrbm93bixcCiAgIGFuZCBhbiBpbnRlcmNvbm5lY3Rpb24gbWF5IHBy b3ZpZGUgYSBmYXN0ZXIgcm91dGUgdG8gcmVhY2ggdGhlXAogICBjbG9zZXN0IHVwc3RyZWFtIHBl ZXIgdG8gdGhlIHNvdXJjZSBvZiB0aGUgYXR0YWNrIHRyYWZmaWMgaWYgZGlyZWN0XAogICBjb21t dW5pY2F0aW9uIGJldHdlZW4gU1BzIGlzIG5vdCBwb3NzaWJsZS4gIEFuIGV4YW1wbGUgaXMgaWxs dXN0cmF0ZWRcCiAgIGJlbG93LlwKXAogICAgICAgX19fX19fXyAgICAgICAgICAgICAgICAgICAg IF9fX19fX18gICAgICAgICAgICAgICAgICAgICBfX19fX19fXAogICAgICAgfCAgICAgfCAgICAg ICAgICAgICAgICAgICAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICB8XAogICAg IF9ffCBSSUQgfF9fX18tLS0tLS0tLS0tLS0tX19fX3wgUklEIHxfX19fLS0tLS0tLS0tLS0tLV9f X198IFJJRCB8X19cCiAgICAgICB8X19fX198ICAgIHwgU1AgQm9yZGVyIHwgICAgfF9fX19ffCAg ICB8IFNQIEJvcmRlciB8ICAgIHxfX19fX3xcCiAgICAgICAgICB8ICAgICAgIC0tLS0tLS0tLS0t LS0gICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tICAgICAgIHxcCiAgICAgICAgICB8X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX3xcClwKICAg ICAgRGlyZWN0IGNvbm5lY3Rpb24gdG8gbmV0d29yayB0aGF0IGlzIG5vdCBhbiBpbW1lZGlhdGUg bmV0d29yayBwZWVyXApcCiAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDI6IE1lc2ggUGVl ciBUb3BvbG9neVwKXAogICBCeSB1c2luZyBhIGZ1bGx5IG1lc2hlZCBtb2RlbCBpbiBhIGNvbnNv cnRpdW0sIGJyb2FkY2FzdGluZyBSSURcCiAgIHJlcXVlc3RzIHdvdWxkIGJlIHBvc3NpYmxlLCBi dXQgbm90IGFkdmlzYWJsZS4gIEJ5IGJyb2FkY2FzdGluZyBhXAogICByZXF1ZXN0LCBSSUQgcGVl cnMgdGhhdCBtYXkgbm90IGhhdmUgY2FycmllZCB0aGUgYXR0YWNrIHRyYWZmaWMgb25cCiAgIHRo ZWlyIG5ldHdvcmsgd291bGQgYmUgYXNrZWQgdG8gcGVyZm9ybSBhIHRyYWNlIGZvciB0aGUgcG90 ZW50aWFsIG9mXAogICBkZWNyZWFzaW5nIHRoZSB0aW1lIGluIHdoaWNoIHRoZSB0cnVlIHNvdXJj ZSB3YXMgaWRlbnRpZmllZC4gIEFzIGFcCiAgIHJlc3VsdCwgbWFueSBuZXR3b3JrcyB3b3VsZCBo YXZlIHV0aWxpemVkIHVubmVjZXNzYXJ5IHJlc291cmNlcyBmb3IgYVwKICAgVHJhY2VSZXF1ZXN0 IHRoYXQgbWF5IGhhdmUgYWxzbyBiZWVuIHVubmVjZXNzYXJ5LlwKXAogICBBIHN0YXIgdG9wb2xv Z3kgbWF5IGJlIGRlc2lyYWJsZSBpbiBpbnN0YW5jZXMgd2hlcmUgYSBwZWVyIG1heSBiZSBhXApc ClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAg ICAgICAgICAgICBbUGFnZSAxMF1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJG QzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgcHJvdmlkZXIg b2YgaW5jaWRlbnQgaW5mb3JtYXRpb24uICBUaGlzIHdvdWxkIHJlcXVpcmUgdHJ1c3RcCiAgIHJl bGF0aW9uc2hpcHMgdG8gYmUgZXN0YWJsaXNoZWQgYmV0d2VlbiB0aGUgcHJvdmlkZXIgb2YgaW5m b3JtYXRpb25cCiAgIGFuZCBlYWNoIG9mIHRoZSBjb25zdW1lcnMgb2YgdGhhdCBpbmZvcm1hdGlv bi4gIEV4YW1wbGVzIG1heSBpbmNsdWRlXAogICBjb3VudHJ5IGxldmVsIENTSVJUcyBvciBzZXJ2 aWNlIHByb3ZpZGVycyBkaXN0cmlidXRpbmcgaW5jaWRlbnRcCiAgIGluZm9ybWF0aW9uIHRvIG9y Z2FuaXphdGlvbnMuXApcCjIuMy4gIE1lc3NhZ2UgRm9ybWF0c1wKXAogICBTZWN0aW9uIDQuMy4y IGRlc2NyaWJlcyB0aGUgc2l4IFJJRCBtZXNzYWdlIHR5cGVzLCB3aGljaCBsZXZlcmFnZSB0aGVc CiAgIElPREVGIG1vZGVsIFtSRkM1MDcwXS4gIFRoZSBtZXNzYWdlcyBhcmUgZ2VuZXJhdGVkIGFu ZCByZWNlaXZlZCBvblwKICAgZGVzaWduYXRlZCBzeXN0ZW1zIGZvciBSSUQgY29tbXVuaWNhdGlv biBvbiB0aGUgcHJvdmlkZXIncyBuZXR3b3JrLlwKICAgVGhlIG1lc3NhZ2VzIG1heSBvcmlnaW5h dGUgZnJvbSBJT0RFRiBkb2N1bWVudHMgZnJvbSBpbnRydXNpb25cCiAgIGRldGVjdGlvbiBzZXJ2 ZXJzLCBDU0lSVHMsIGFuYWx5c3RzLCBldGMuICBBIFJJRCBtZXNzYWdlIHVzZXMgdGhlXAogICBJ T0RFRiBkb2N1bWVudCB3aXRoIHRoZSBSSUQgZXh0ZW5zaW9uLCB3aGljaCBpcyBlbmNhcHN1bGF0 ZWQgZm9yXAogICB0cmFuc3BvcnQgW1JGQzYwNDZdLiAgRWFjaCBSSUQgbWVzc2FnZSB0eXBlLCBh bG9uZyB3aXRoIGFuIGV4YW1wbGUsXAogICBpcyBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBz ZWN0aW9ucy4gIFRoZSBJT0RFRi1SSUQgc2NoZW1hIGlzXAogICBpbnRyb2R1Y2VkIGluIFNlY3Rp b24gOSB0byBzdXBwb3J0IHRoZSBSSUQgbWVzc2FnZSB0eXBlcyBpbiBjbGF1c2VcCiAgIDguMi4g IFRoZSB0ZXJtIHNlcnZpY2UgcHJvdmlkZXIgKFNQKSwgdXNlZCBpbiB0aGUgZm9sbG93aW5nIHNl Y3Rpb25zXAogICBzaG91bGQgYmUgaW50ZXJwcmV0ZWQgYXMgYW55IHR5cGUgb2Ygc2VydmljZSBw cm92aWRlciBvciBDU0lSVCB0aGF0XAogICBtYXkgYmUgaW52b2x2ZWQgaW4gUklEIGNvbW11bmlj YXRpb25zLlwKXAoyLjQuICBSSUQgRGF0YSBUeXBlc1wKXAogICBSSUQgaXMgZGVyaXZlZCBmcm9t IHRoZSBJT0RFRiBkYXRhIG1vZGVsIGFuZCBpbmhlcml0cyBhbGwgb2YgdGhlIGRhdGFcCiAgIHR5 cGVzIGRlZmluZWQgaW4gdGhlIElPREVGIG1vZGVsLiAgT25lIGRhdGEgdHlwZSBpcyBhZGRlZCBi eSBSSUQ6XAogICBCT09MRUFOLlwKXAoyLjQuMS4gIEJvb2xlYW5cClwKICAgQSBib29sZWFuIHZh bHVlIGlzIHJlcHJlc2VudGVkIGJ5IHRoZSBCT09MRUFOIGRhdGEgdHlwZS5cClwKICAgVGhlIEJP T0xFQU4gZGF0YSB0eXBlIGlzIGltcGxlbWVudGVkIGFzICJ4czpib29sZWFuIiBbWE1Mc2NoZW1h XSBpblwKICAgdGhlIHNjaGVtYS5cClwKMi41LiAgUklEIE1lc3NhZ2UgVHlwZXNcClwKICAgVGhl IHNpeCBSSUQgbWVzc2FnZSB0eXBlcyBhcmUgYXMgZm9sbG93czpcClwKICAgMS4gIFRyYWNlUmVx dWVzdC4gIFRoaXMgbWVzc2FnZSBpcyBzZW50IHRvIHRoZSBuZXh0IHByb3ZpZGVyIGluIHRoZVwK ICAgICAgIHVwc3RyZWFtIHRyYWNlLiAgSXQgaXMgdXNlZCB0byBpbml0aWF0ZSBhIFRyYWNlUmVx dWVzdCBvciB0b1wKICAgICAgIGNvbnRpbnVlIGEgVHJhY2VSZXF1ZXN0IHRvIGFuIHVwc3RyZWFt IHByb3ZpZGVyIGNsb3NlciB0byB0aGVcCiAgICAgICBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgb3Jp Z2luIG9mIHRoZSBzZWN1cml0eSBpbmNpZGVudC4gIFRoZVwKICAgICAgIFRyYWNlUmVxdWVzdCB3 b3VsZCB0cmlnZ2VyIGEgdHJhY2ViYWNrIG9uIHRoZSBuZXR3b3JrIHRvIGxvY2F0ZVwKICAgICAg IHRoZSBzb3VyY2Ugb2YgdGhlIGF0dGFjayB0cmFmZmljLlwKXAogICAyLiAgUmVxdWVzdEF1dGhv cml6YXRpb24uICBUaGlzIG1lc3NhZ2UgaXMgc2VudCB0byB0aGUgaW5pdGlhdGluZyBSSURcCiAg ICAgICBzeXN0ZW0gZnJvbSBlYWNoIG9mIHRoZSB1cHN0cmVhbSBwcm92aWRlcnMnIFJJRCBzeXN0 ZW1zIHRvXAogICAgICAgcHJvdmlkZSBpbmZvcm1hdGlvbiBvbiB0aGUgcmVxdWVzdCBzdGF0dXMg aW4gdGhlIGN1cnJlbnQgbmV0d29yay5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDExXVwKXApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVn dXN0IDIwMTFcClwKXAogICAzLiAgUmVzdWx0LiAgVGhpcyBtZXNzYWdlIGlzIHNlbnQgdG8gdGhl IGluaXRpYXRpbmcgQ1NJUlQgdGhyb3VnaCB0aGVcCiAgICAgICBuZXR3b3JrIG9mIFJJRCBzeXN0 ZW1zIGluIHRoZSBwYXRoIG9mIHRoZSB0cmFjZSBhcyBub3RpZmljYXRpb25cCiAgICAgICB0aGF0 IHRoZSBzb3VyY2Ugb2YgdGhlIGF0dGFjayB3YXMgbG9jYXRlZC4gIFRoZSBSZXN1bHQgbWVzc2Fn ZSBpc1wKICAgICAgIGFsc28gdXNlZCB0byBwcm92aWRlIHRoZSBub3RpZmljYXRpb24gb2YgYWN0 aW9ucyB0YWtlbiBmb3IgYW5cCiAgICAgICBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QuXApcCiAgIDQu ICBJbnZlc3RpZ2F0aW9uLiAgVGhpcyBtZXNzYWdlIHR5cGUgaXMgdXNlZCB3aGVuIHRoZSBzb3Vy Y2Ugb2YgdGhlXAogICAgICAgdHJhZmZpYyBpcyBiZWxpZXZlZCBub3QgdG8gYmUgc3Bvb2ZlZC4g IFRoZSBwdXJwb3NlIG9mIHRoZVwKICAgICAgIEludmVzdGlnYXRpb24gcmVxdWVzdCBtZXNzYWdl IGlzIHRvIGxldmVyYWdlIHRoZSBleGlzdGluZyBwZWVyXAogICAgICAgcmVsYXRpb25zaGlwcyBp biBvcmRlciB0byBub3RpZnkgdGhlIG5ldHdvcmsgcHJvdmlkZXIgY2xvc2VzdCB0b1wKICAgICAg IHRoZSBzb3VyY2Ugb2YgdGhlIHZhbGlkIHRyYWZmaWMgb2YgYSBzZWN1cml0eS1yZWxhdGVkIGlu Y2lkZW50XAogICAgICAgZm9yIGFueSBuZWNlc3NhcnkgYWN0aW9ucyB0byBiZSB0YWtlbi5cClwK ICAgNS4gIFJlcG9ydC4gIFRoaXMgbWVzc2FnZSBpcyB1c2VkIHRvIHJlcG9ydCBhIHNlY3VyaXR5 IGluY2lkZW50LCBmb3JcCiAgICAgICB3aGljaCBubyBhY3Rpb24gaXMgcmVxdWVzdGVkLiAgVGhp cyBtYXkgYmUgdXNlZCBmb3IgdGhlIHB1cnBvc2VcCiAgICAgICBvZiBjb3JyZWxhdGluZyBhdHRh Y2sgaW5mb3JtYXRpb24gYnkgQ1NJUlRzLCBzaGFyaW5nIGluY2lkZW50XAogICAgICAgaW5mb3Jt YXRpb24sIHN0YXRpc3RpY3MgYW5kIHRyZW5kaW5nIGluZm9ybWF0aW9uLCBldGMuXApcCiAgIDYu ICBJbmNpZGVudFF1ZXJ5LiAgVGhpcyBtZXNzYWdlIGlzIHVzZWQgdG8gcmVxdWVzdCBpbmZvcm1h dGlvbiBhYm91dFwKICAgICAgIGFuIGluY2lkZW50IG9yIGluY2lkZW50IHR5cGUgZnJvbSBhIHRy dXN0ZWQgc3lzdGVtIGNvbW11bmljYXRpbmdcCiAgICAgICB2aWEgUklELiAgVGhlIHJlc3BvbnNl IGlzIHByb3ZpZGVkIHRocm91Z2ggdGhlIFJlcG9ydCBtZXNzYWdlLlwKXAogICBXaGVuIGFuIGFw cGxpY2F0aW9uIHJlY2VpdmVzIGEgUklEIG1lc3NhZ2UsIGl0IG11c3QgYmUgYWJsZSB0b1wKICAg ZGV0ZXJtaW5lIHRoZSB0eXBlIG9mIG1lc3NhZ2UgYW5kIHBhcnNlIGl0IGFjY29yZGluZ2x5LiAg VGhlIG1lc3NhZ2VcCiAgIHR5cGUgaXMgc3BlY2lmaWVkIGluIHRoZSBSSURQb2xpY3kgY2xhc3Mu ICBUaGUgUklEUG9saWN5IGNsYXNzIG1heVwKICAgYWxzbyBiZSB1c2VkIGJ5IHRoZSB0cmFuc3Bv cnQgcHJvdG9jb2wgdG8gZmFjaWxpdGF0ZSB0aGVcCiAgIGNvbW11bmljYXRpb24gb2Ygc2VjdXJp dHkgaW5jaWRlbnQgZGF0YSB0byB0cmFjZSwgaW52ZXN0aWdhdGUsIHF1ZXJ5LFwKICAgb3IgcmVw b3J0IGluZm9ybWF0aW9uIHJlZ2FyZGluZyBzZWN1cml0eSBpbmNpZGVudHMuXApcClwKMy4gIElP REVGLVJJRCBTY2hlbWFcClwKICAgVGhlcmUgYXJlIHRocmVlIGNsYXNzZXMgaW5jbHVkZWQgaW4g dGhlIFJJRCBleHRlbnNpb24gcmVxdWlyZWQgdG9cCiAgIGZhY2lsaXRhdGUgUklEIGNvbW11bmlj YXRpb25zLiAgVGhlIFJlcXVlc3RTdGF0dXMgY2xhc3MgaXMgdXNlZCB0b1wKICAgaW5kaWNhdGUg dGhlIGFwcHJvdmFsIHN0YXR1cyBvZiBhIFRyYWNlUmVxdWVzdCBvciBJbnZlc3RpZ2F0aW9uXAog ICByZXF1ZXN0OyB0aGUgSW5jaWRlbnRTb3VyY2UgY2xhc3MgaXMgdXNlZCB0byByZXBvcnQgd2hl dGhlciBvciBub3QgYVwKICAgc291cmNlIHdhcyBmb3VuZCBhbmQgdG8gaWRlbnRpZnkgdGhlIHNv dXJjZSBob3N0KHMpIG9yIG5ldHdvcmsocyk7XAogICBhbmQgdGhlIFJJRFBvbGljeSBjbGFzcyBw cm92aWRlcyBpbmZvcm1hdGlvbiBvbiB0aGUgYWdyZWVkLXVwb25cCiAgIHBvbGljaWVzIGFuZCBz cGVjaWZpZXMgdGhlIHR5cGUgb2YgY29tbXVuaWNhdGlvbiBtZXNzYWdlIGJlaW5nIHVzZWQuXApc CiAgIFRoZSBSSUQgc2NoZW1hIGFjdHMgYXMgYW4gZW52ZWxvcGUgZm9yIHRoZSBJT0RFRiBzY2hl bWEgdG8gZmFjaWxpdGF0ZVwKICAgUklEIGNvbW11bmljYXRpb25zLiAgVGhlIGludGVudCBpbiBt YWludGFpbmluZyBhIHNlcGFyYXRlIHNjaGVtYSBhbmRcCiAgIG5vdCB1c2luZyB0aGUgQWRkaXRp b25hbERhdGEgZXh0ZW5zaW9uIG9mIElPREVGIGlzIHRoZSBmbGV4aWJpbGl0eSBvZlwKICAgc2Vu ZGluZyBtZXNzYWdlcyBiZXR3ZWVuIFJJRCBob3N0cy4gIFNpbmNlIFJJRCBpcyBhIHNlcGFyYXRl IHNjaGVtYVwKICAgdGhhdCBpbmNsdWRlcyB0aGUgSU9ERUYgc2NoZW1hLCB0aGUgUklEIGluZm9y bWF0aW9uIGFjdHMgYXMgYW5cCiAgIGVudmVsb3BlLCBhbmQgdGhlbiB0aGUgUklEUG9saWN5IGNs YXNzIGNhbiBiZSBlYXNpbHkgZXh0cmFjdGVkIGZvclwKICAgdXNlIGJ5IHRoZSB0cmFuc3BvcnQg cHJvdG9jb2wuXApcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDEyXVwKXApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwK XAogICBUaGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHNlbmRpbmcgaW5jaWRlbnQgaW5mb3Jt YXRpb24gYWNyb3NzIHRoZVwKICAgbmV0d29yayBpbmNsdWRlIHRoZSB1c2Ugb2YgZW5jcnlwdGlv bi4gIFRoZSBSSURQb2xpY3kgaW5mb3JtYXRpb24gaXNcCiAgIG5vdCByZXF1aXJlZCB0byBiZSBl bmNyeXB0ZWQsIHNvIHNlcGFyYXRpbmcgb3V0IHRoaXMgZGF0YSBmcm9tIHRoZVwKICAgSU9ERUYg ZXh0ZW5zaW9uIHJlbW92ZXMgdGhlIG5lZWQgZm9yIGRlY3J5cHRpbmcgYW5kIHBhcnNpbmcgdGhl XAogICBlbnRpcmUgSU9ERUYgYW5kIFJJRCBkb2N1bWVudCB0byBkZXRlcm1pbmUgaG93IGl0IHNo b3VsZCBiZSBoYW5kbGVkXAogICBhdCBlYWNoIFJJRCBob3N0LlwKXAogICBUaGUgcHVycG9zZSBv ZiB0aGUgUklEUG9saWN5IGNsYXNzIGlzIHRvIHNwZWNpZnkgdGhlIG1lc3NhZ2UgdHlwZSBmb3Jc CiAgIHRoZSByZWNlaXZpbmcgaG9zdCwgZmFjaWxpdGF0ZSB0aGUgcG9saWN5IG5lZWRzIG9mIFJJ RCwgYW5kIHByb3ZpZGVcCiAgIHJvdXRpbmcgaW5mb3JtYXRpb24gaW4gdGhlIGZvcm0gb2YgYW4g SVAgYWRkcmVzcyBvZiB0aGUgZGVzdGluYXRpb25cCiAgIFJJRCBzeXN0ZW0uXApcCiAgIFRoZSBw b2xpY3kgaW5mb3JtYXRpb24gYW5kIGd1aWRlbGluZXMgYXJlIGRpc2N1c3NlZCBpbiBTZWN0aW9u IDYuNi5cCiAgIFRoZSBwb2xpY3kgaXMgZGVmaW5lZCBiZXR3ZWVuIFJJRCBwZWVycyBhbmQgd2l0 aGluIG9yIGJldHdlZW5cCiAgIGNvbnNvcnRpdW1zLiAgVGhlIFJJRFBvbGljeSBpcyBtZWFudCB0 byBiZSBhIHRvb2wgdG8gZmFjaWxpdGF0ZSB0aGVcCiAgIGRlZmluZWQgcG9saWNpZXMuICBUaGlz IE1VU1QgYmUgdXNlZCBpbiBhY2NvcmRhbmNlIHdpdGggcG9saWN5IHNldFwKICAgYmV0d2VlbiBj bGllbnRzLCBwZWVycywgY29uc29ydGl1bXMsIGFuZC9vciByZWdpb25zLiAgU2VjdXJpdHksXAog ICBwcml2YWN5LCBhbmQgY29uZmlkZW50aWFsaXR5IE1VU1QgYmUgY29uc2lkZXJlZCBhcyBzcGVj aWZpZWQgaW4gdGhpc1wKICAgZG9jdW1lbnQuXApcCiAgIFRoZSBSSUQgc2NoZW1hIGlzIGRlZmlu ZWQgYXMgZm9sbG93czpcClwKICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tK1wKICAgICAg ICAgICB8ICAgICAgICBSSUQgICAgICAgfFwKICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t K1wKICAgICAgICAgICB8IEFOWSAgICAgICAgICAgICAgfFwKICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgfCZsdDsmZ3Q7LS0tXHswLi4xXH0tLS0tWyBSSURQb2xpY3kgICAgICBdXAogICAg ICAgICAgIHwgRU5VTSByZXN0cmljdGlvbiB8XAogICAgICAgICAgIHwgRU5VTSB0eXBlICAgICAg ICB8Jmx0OyZndDstLS1cezAuLjFcfS0tLS1bIFJlcXVlc3RTdGF0dXMgIF1cCiAgICAgICAgICAg fCBTVFJJTkcgbWVhbmluZyAgIHxcCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwmbHQ7 Jmd0Oy0tLVx7MC4uMVx9LS0tLVsgSW5jaWRlbnRTb3VyY2UgXVwKICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tK1wKXAogICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IFRoZSBS SUQgU2NoZW1hXApcCiAgIFRoZSBhZ2dyZWdhdGUgY2xhc3NlcyB0aGF0IGNvbnN0aXR1dGUgdGhl IFJJRCBzY2hlbWEgaW4gdGhlIGlvZGVmLXJpZFwKICAgbmFtZXNwYWNlIGFyZSBhcyBmb2xsb3dz OlwKXAogICBSSURQb2xpY3lcClwKICAgICAgWmVybyBvciBPbmUuIFRoZSBSSURQb2xpY3kgY2xh c3MgaXMgdXNlZCBieSBhbGwgbWVzc2FnZSB0eXBlcyB0b1wKICAgICAgZmFjaWxpdGF0ZSBwb2xp Y3kgYWdyZWVtZW50cyBiZXR3ZWVuIHBlZXJzLCBjb25zb3J0aXVtcywgb3JcCiAgICAgIGZlZGVy YXRpb25zLCBhcyB3ZWxsIGFzIHRvIHByb3Blcmx5IHJvdXRlIG1lc3NhZ2VzLlwKXAogICBSZXF1 ZXN0U3RhdHVzXApcCiAgICAgIFplcm8gb3IgT25lLiBUaGUgUmVxdWVzdFN0YXR1cyBjbGFzcyBp cyB1c2VkIG9ubHkgaW5cCiAgICAgIFJlcXVlc3RBdXRob3JpemF0aW9uIG1lc3NhZ2VzIHRvIHJl cG9ydCBiYWNrIHRvIHRoZSBDU0lSVCBvciBTUFwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTNdXApcCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAg ICBBdWd1c3QgMjAxMVwKXApcCiAgICAgIG9yaWdpbmF0aW5nIHRoZSBSSUQgdHJhY2Ugd2lsbCBi ZSBjb250aW51ZWQgYnkgZWFjaCBSSUQgc3lzdGVtXAogICAgICB0aGF0IHJlY2VpdmVkIGEgVHJh Y2VSZXF1ZXN0IGluIHRoZSBwYXRoIHRvIHRoZSBzb3VyY2Ugb2YgdGhlXAogICAgICB0cmFmZmlj LlwKXAogICBJbmNpZGVudFNvdXJjZVwKXAogICAgICBaZXJvIG9yIE9uZS4gVGhlIEluY2lkZW50 U291cmNlIGNsYXNzIGlzIHVzZWQgaW4gdGhlIFJlc3VsdFwKICAgICAgbWVzc2FnZSBvbmx5LiAg VGhlIEluY2lkZW50U291cmNlIHByb3ZpZGVzIHRoZSBpbmZvcm1hdGlvbiBvbiB0aGVcCiAgICAg IGlkZW50aWZpZWQgc291cmNlIGhvc3Qgb3IgbmV0d29yayBvZiBhbiBhdHRhY2sgdHJhY2Ugb3Jc CiAgICAgIGludmVzdGlnYXRpb24uXApcCiAgIEVhY2ggb2YgdGhlIHRocmVlIGxpc3RlZCBjbGFz c2VzIG1heSBiZSB0aGUgb25seSBjbGFzcyBpbmNsdWRlZCBpblwKICAgdGhlIFJJRCBjbGFzcywg aGVuY2UgdGhlIG9wdGlvbiBmb3IgemVybyBvciBvbmUuICBJbiBzb21lIGNhc2VzLFwKICAgUklE UG9saWN5IE1BWSBiZSB0aGUgb25seSBjbGFzcyBpbiB0aGUgUklEIGRlZmluaXRpb24gd2hlbiB1 c2VkIGJ5XAogICB0aGUgdHJhbnNwb3J0IHByb3RvY29sIFtSRkM2MDQ2XSwgYXMgdGhhdCBpbmZv cm1hdGlvbiBzaG91bGQgYmUgYXNcCiAgIHNtYWxsIGFzIHBvc3NpYmxlIGFuZCBtYXkgbm90IGJl IGVuY3J5cHRlZC4gIFRoZSBSZXF1ZXN0U3RhdHVzXAogICBtZXNzYWdlIE1VU1QgYmUgYWJsZSB0 byBzdGFuZCBhbG9uZSB3aXRob3V0IHRoZSBuZWVkIGZvciBhbiBJT0RFRlwKICAgZG9jdW1lbnQg dG8gZmFjaWxpdGF0ZSB0aGUgY29tbXVuaWNhdGlvbiwgbGltaXRpbmcgdGhlIGRhdGFcCiAgIHRy YW5zcG9ydGVkIHRvIHRoZSByZXF1aXJlZCBlbGVtZW50cyBwZXIgW1JGQzYwNDZdLlwKXAozLjEu ICBSSURQb2xpY3kgQ2xhc3NcClwKICAgVGhlIFJJRFBvbGljeSBjbGFzcyBmYWNpbGl0YXRlcyB0 aGUgZGVsaXZlcnkgb2YgUklEIG1lc3NhZ2VzIGFuZCBpc1wKICAgYWxzbyByZWZlcmVuY2VkIGZv ciB0cmFuc3BvcnQgaW4gdGhlIHRyYW5zcG9ydCBkb2N1bWVudCBbUkZDNjA0Nl0uXApcCiAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tK1wKICAgICAgICAgIHwgUklEUG9saWN5ICAg ICAgICAgICAgICB8XAogICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLStcCiAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfFwKICAgICAgICAgIHwgRU5VTSByZXN0cmlj dGlvbiAgICAgICB8Jmx0OyZndDstLS0tLS0tLS0tLS0tWyBOb2RlICAgICAgICAgXVwKICAgICAg ICAgIHwgRU5VTSBNc2dUeXBlICAgICAgICAgICB8XAogICAgICAgICAgfCBFTlVNIE1zZ0Rlc3Rp bmF0aW9uICAgIHwmbHQ7Jmd0Oy0tLVx7MC4uMVx9LS0tLVsgSW5jaWRlbnRJRCAgIF1cCiAgICAg ICAgICB8IEVOVU0gZXh0LU1zZ1R5cGUgICAgICAgfFwKICAgICAgICAgIHwgRU5VTSBleHQtTXNn RGVzdGluYXRpb258Jmx0OyZndDstLS1cezEuLipcfS0tLS1bIFBvbGljeVJlZ2lvbiBdXAogICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxcCiAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgfCZsdDsmZ3Q7LS0tXHsxLi4qXH0tLS0tWyBUcmFmZmljVHlwZSAgXVwKICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8XAogICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLStcClwKICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNDogVGhlIFJJ RFBvbGljeSBDbGFzc1wKXAogICBUaGUgYWdncmVnYXRlIGVsZW1lbnRzIHRoYXQgY29uc3RpdHV0 ZSB0aGUgUklEUG9saWN5IGNsYXNzIGFyZSBhc1wKICAgZm9sbG93czpcClwKICAgTm9kZVwKXAog ICAgICBPbmUuIFRoZSBOb2RlIGNsYXNzIGlzIHVzZWQgdG8gaWRlbnRpZnkgYSBob3N0IG9yIG5l dHdvcmsgZGV2aWNlLFwKICAgICAgaW4gdGhpcyBjYXNlIHRvIGlkZW50aWZ5IHRoZSBzeXN0ZW0g Y29tbXVuaWNhdGluZyBSSUQgbWVzc2FnZXMuXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxNF1cClwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDExXApcClwKICAgICAgVGhlIGJhc2UgZGVmaW5pdGlvbiBvZiB0aGlzIGNsYXNz IGlzIHJldXNlZCBmcm9tIHRoZSBJT0RFRlwKICAgICAgc3BlY2lmaWNhdGlvbiBbUkZDNTA3MF0s IFNlY3Rpb24gMy4xNi5cClwKICAgSW5jaWRlbnRJRFwKXAogICAgICBaZXJvIG9yIG9uZS4gIEds b2JhbCByZWZlcmVuY2UgcG9pbnRpbmcgYmFjayB0byB0aGUgSW5jaWRlbnRJRFwKICAgICAgZGVm aW5lZCBpbiB0aGUgSU9ERUYgZGF0YSBtb2RlbC4gIFRoZSBJbmNpZGVudElEIGluY2x1ZGVzIHRo ZSBuYW1lXAogICAgICBvZiB0aGUgQ1NJUlQsIGFuIGluY2lkZW50IG51bWJlciwgYW5kIGFuIGlu c3RhbmNlIG9mIHRoYXRcCiAgICAgIGluY2lkZW50LiAgVGhlIGluc3RhbmNlIG51bWJlciBpcyBh cHBlbmRlZCB3aXRoIGEgZGFzaCBzZXBhcmF0aW5nXAogICAgICB0aGUgdmFsdWVzIGFuZCBpcyB1 c2VkIGluIGNhc2VzIGZvciB3aGljaCBpdCBtYXkgYmUgZGVzaXJhYmxlIHRvXAogICAgICBncm91 cCBpbmNpZGVudHMuICBFeGFtcGxlcyBvZiBpbmNpZGVudHMgdGhhdCBtYXkgYmUgZ3JvdXBlZCB3 b3VsZFwKICAgICAgYmUgYm90bmV0cywgcG9seW1vcnBoaWMgYXR0YWNrcywgRERvUyBhdHRhY2tz LCBtdWx0aXBsZSBob3BzIG9mXAogICAgICBjb21wcm9taXNlZCBzeXN0ZW1zIGZvdW5kIGR1cmlu ZyBhbiBpbnZlc3RpZ2F0aW9uLCBldGMuXApcCiAgIFBvbGljeVJlZ2lvblwKXAogICAgICBPbmUg b3IgbWFueS4gIFJFUVVJUkVELiAgVGhlIHZhbHVlcyBmb3IgdGhlIGF0dHJpYnV0ZSAicmVnaW9u IiBhcmVcCiAgICAgIHVzZWQgdG8gZGV0ZXJtaW5lIHdoYXQgcG9saWN5IGFyZWEgbWF5IHJlcXVp cmUgY29uc2lkZXJhdGlvblwKICAgICAgYmVmb3JlIGEgdHJhY2UgY2FuIGJlIGFwcHJvdmVkLiAg VGhlIFBvbGljeVJlZ2lvbiBtYXkgaW5jbHVkZVwKICAgICAgbXVsdGlwbGUgc2VsZWN0aW9ucyBm cm9tIHRoZSBhdHRyaWJ1dGUgbGlzdCBpbiBvcmRlciB0byBmaXQgYWxsXAogICAgICBwb3NzaWJs ZSBwb2xpY3kgY29uc2lkZXJhdGlvbnMgd2hlbiBjcm9zc2luZyByZWdpb25zLCBjb25zb3J0aXVt cyxcCiAgICAgIG9yIG5ldHdvcmtzLlwKXAogICByZWdpb25cClwKICAgICAgT25lLiBFTlVNLlwK XAogICAgICAxLiAgQ2xpZW50VG9TUC4gIEFuIGVudGVycHJpc2UgaW5pdGlhdGVkIHRoZSByZXF1 ZXN0IHRvIHRoZWlyXAogICAgICAgICAgc2VydmljZSBwcm92aWRlci5cClwKICAgICAgMi4gIFNQ VG9DbGllbnQuICBBbiBzZXJ2aWNlIHByb3ZpZGVyIHBhc3NlZCBhIFJJRCByZXF1ZXN0IG9yXAog ICAgICAgICAgcmVwb3J0IHRvIGEgY2xpZW50IG9yIGFuIGVudGVycHJpc2UgYmFzZWQgb24gcmVx dWVzdGVkXAogICAgICAgICAgc2VydmljZXMgb3Igc2VydmljZSBsZXZlbCBhZ3JlZW1lbnRzLlwK XAogICAgICAzLiAgSW50cmFDb25zb3J0aXVtLiAgSW5jaWRlbnQgaW5mb3JtYXRpb24gdGhhdCBz aG91bGQgaGF2ZSBub1wKICAgICAgICAgIHJlc3RyaWN0aW9ucyB3aXRoaW4gdGhlIGJvdW5kYXJp ZXMgb2YgYSBjb25zb3J0aXVtIHdpdGggdGhlXAogICAgICAgICAgYWdyZWVkLXVwb24gdXNlIGFu ZCBhYnVzZSBndWlkZWxpbmVzLlwKXAogICAgICA0LiAgUGVlclRvUGVlci4gIEluY2lkZW50IGlu Zm9ybWF0aW9uIHRoYXQgc2hvdWxkIGhhdmUgbm9cCiAgICAgICAgICByZXN0cmljdGlvbnMgYmV0 d2VlbiB0d28gcGVlcnMgYnV0IG1heSByZXF1aXJlIGZ1cnRoZXJcCiAgICAgICAgICBldmFsdWF0 aW9uIGJlZm9yZSBjb250aW51YW5jZSBiZXlvbmQgdGhhdCBwb2ludCB3aXRoIHRoZVwKICAgICAg ICAgIGFncmVlZC11cG9uIHVzZSBhbmQgYWJ1c2UgZ3VpZGVsaW5lcy5cClwKICAgICAgNS4gIEJl dHdlZW5Db25zb3J0aXVtcy4gIEluY2lkZW50IGluZm9ybWF0aW9uIHRoYXQgc2hvdWxkIGhhdmUg bm9cCiAgICAgICAgICByZXN0cmljdGlvbnMgYmV0d2VlbiBjb25zb3J0aXVtcyB0aGF0IGhhdmUg ZXN0YWJsaXNoZWQgYWdyZWVkLVwKICAgICAgICAgIHVwb24gdXNlIGFuZCBhYnVzZSBndWlkZWxp bmVzLlwKXApcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg MjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDE1XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAog ICAgICA2LiAgQWNyb3NzTmF0aW9uYWxCb3VuZGFyaWVzLiAgVGhpcyBzZWxlY3Rpb24gbXVzdCBi ZSBzZXQgaWYgdGhlXAogICAgICAgICAgbWVzc2FnZSB0eXBlIHdpbGwgY3Jvc3MgbmF0aW9uYWwg Ym91bmRhcmllcy4gIFRoZXJlIGNvdWxkIGJlXAogICAgICAgICAgaW5zdGFuY2VzIG9mIFRyYWNl UmVxdWVzdCBtZXNzYWdlcyB3aGVyZSB0aGF0IG1heSBub3QgYmUga25vd25cCiAgICAgICAgICBp biBhZHZhbmNlLCBidXQgc2hvdWxkIGJlIGtub3duIGF0IHRoZSBpbnN0YW5jZSB3aGVyZVwKICAg ICAgICAgIGJvdW5kYXJpZXMgYXJlIGNyb3NzZWQgZHVyaW5nIHRoZSBpbnZlc3RpZ2F0aW9uLiAg VGhpcyBtdXN0XAogICAgICAgICAgYWxzbyBiZSBzZXQgaWYgdGhlIHNlY3VyaXR5IHJlcXVpcmVt ZW50cyBvZiB0aGUgcmVxdWVzdCBpc1wKICAgICAgICAgIGJhc2VkIHVwb24gcmVndWxhdGlvbnMg b2YgYSBzcGVjaWZpYyBuYXRpb24gdGhhdCBtYXkgbm90IGFwcGx5XAogICAgICAgICAgdG8gYWxs IG5hdGlvbnMuICBUaGUgc3RyaWN0ZXIgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSB1cGhlbGQuXAog ICAgICAgICAgVGhpcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgIkJldHdlZW5Db25zb3J0aXVtcyIg c2V0dGluZyBzaW5jZVwKICAgICAgICAgIGl0IG1heSBiZSBwb3NzaWJsZSB0byBoYXZlIG11bHRp cGxlIG5hdGlvbnMgYXMgbWVtYmVycyBvZiB0aGVcCiAgICAgICAgICBzYW1lIGNvbnNvcnRpdW0s IGFuZCB0aGlzIG9wdGlvbiBtdXN0IGJlIHNlbGVjdGVkIGlmIHRoZVwKICAgICAgICAgIHRyYWZm aWMgaXMgb2YgYSB0eXBlIHRoYXQgbWF5IGhhdmUgZGlmZmVyZW50IHJlc3RyaWN0aW9ucyBpblwK ICAgICAgICAgIG90aGVyIG5hdGlvbnMuXApcCiAgICAgIDcuICBMYXdFbmZvcmNlbWVudC4gIFRo aXMgb3B0aW9uIGlzIHVzZWQgd2hlbiBpbmNpZGVudCBpbmZvcm1hdGlvblwKICAgICAgICAgIGlz IGV4Y2hhbmdlZCB3aXRoIExhd0VuZm9yY2VtZW50LCBsb2NhbCBnb3Zlcm5tZW50LCBvciBvdGhl clwKICAgICAgICAgIGF1dGhvcml0aWVzIGFzc2lzdGluZyB3aXRoIGFuIGludmVzdGlnYXRpb24u XApcCiAgICAgIDguICBleHQtdmFsdWUuICBBbiBlc2NhcGUgdmFsdWUgdXNlZCB0byBleHRlbmQg dGhpcyBhdHRyaWJ1dGUuXAogICAgICAgICAgU2VlIElPREVGIFtSRkM1MDcwXSwgU2VjdGlvbiA1 LjEuXApcCiAgIFRyYWZmaWNUeXBlXApcCiAgICAgIE9uZSBvciBtYW55LiAgUkVRVUlSRUQuICBU aGUgdmFsdWVzIGZvciB0aGUgYXR0cmlidXRlICJ0eXBlIiBhcmVcCiAgICAgIG1lYW50IHRvIGFz c2lzdCBpbiBkZXRlcm1pbmluZyBpZiBhIHRyYWNlIGlzIGFwcHJvcHJpYXRlIGZvciB0aGVcCiAg ICAgIFNQIChwcm92aWRlcikgcmVjZWl2aW5nIHRoZSByZXF1ZXN0IHRvIGNvbnRpbnVlIHRoZSB0 cmFjZS5cCiAgICAgIE11bHRpcGxlIHZhbHVlcyBtYXkgYmUgc2VsZWN0ZWQgZm9yIHRoaXMgZWxl bWVudDsgaG93ZXZlciwgd2hlcmVcCiAgICAgIHBvc3NpYmxlLCBpdCBzaG91bGQgYmUgcmVzdHJp Y3RlZCB0byBvbmUgdmFsdWUgdGhhdCB3b3VsZCBtb3N0XAogICAgICBhY2N1cmF0ZWx5IGRlc2Ny aWJlIHRoZSB0cmFmZmljIHR5cGUuXApcCiAgIHR5cGVcClwKICAgICAgT25lLiBFTlVNLlwKXAog ICAgICAxLiAgQXR0YWNrLiAgVGhpcyBvcHRpb24gc2hvdWxkIG9ubHkgYmUgc2VsZWN0ZWQgaWYg dGhlIHRyYWZmaWMgaXNcCiAgICAgICAgICByZWxhdGVkIHRvIGEgbmV0d29yay1iYXNlZCBhdHRh Y2suICBUaGUgdHlwZSBvZiBhdHRhY2sgTVVTVFwKICAgICAgICAgIGFsc28gYmUgbGlzdGVkIGlu IG1vcmUgZGV0YWlsIGluIHRoZSBJT0RFRiBNZXRob2QgYW5kIEltcGFjdFwKICAgICAgICAgIGNs YXNzZXMgZm9yIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiB0byBhc3Npc3QgaW4gZGV0ZXJtaW5pbmcg aWZcCiAgICAgICAgICB0aGUgdHJhY2UgY2FuIGJlIGNvbnRpbnVlZCAoW1JGQzUwNzBdLCBTZWN0 aW9ucyAzLjkgYW5kXAogICAgICAgICAgMy4xMC4xKS5cClwKICAgICAgMi4gIE5ldHdvcmsuICBU aGlzIG9wdGlvbiBNVVNUIG9ubHkgYmUgc2VsZWN0ZWQgd2hlbiB0aGUgdHJhY2UgaXNcCiAgICAg ICAgICByZWxhdGVkIHRvIG5ldHdvcmsgdHJhZmZpYyBvciByb3V0aW5nIGlzc3Vlcy5cClwKICAg ICAgMy4gIENvbnRlbnQuICBUaGlzIGNhdGVnb3J5IE1VU1QgYmUgdXNlZCBvbmx5IGluIHRoZSBj YXNlIGluIHdoaWNoXAogICAgICAgICAgdGhlIHJlcXVlc3QgaXMgcmVsYXRlZCB0byB0aGUgY29u dGVudCBhbmQgcmVnaW9uYWxcCiAgICAgICAgICByZXN0cmljdGlvbnMgb24gYWNjZXNzaW5nIHRo YXQgdHlwZSBvZiBjb250ZW50IGV4aXN0LiAgVGhpcyBpc1wKICAgICAgICAgIG5vdCBtYWxpY2lv dXMgdHJhZmZpYyBidXQgbWF5IGluY2x1ZGUgZGV0ZXJtaW5pbmcgd2hhdCBzb3VyY2VzXApcClwK XApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAg ICAgICAgICBbUGFnZSAxNl1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYw NDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgICAgIG9yIGRl c3RpbmF0aW9ucyBhY2Nlc3NlZCBjZXJ0YWluIG1hdGVyaWFscyBhdmFpbGFibGUgb24gdGhlXAog ICAgICAgICAgSW50ZXJuZXQsIGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCBuZXdzLCB0 ZWNobm9sb2d5LCBvclwKICAgICAgICAgIGluYXBwcm9wcmlhdGUgY29udGVudC5cClwKICAgICAg NC4gIE9mZmljaWFsQnVzaW5lc3MuICBUaGlzIG9wdGlvbiBNVVNUIGJlIHVzZWQgaWYgdGhlIGlu Y2lkZW50XAogICAgICAgICAgaW5mb3JtYXRpb24gcmVxdWVzdGVkIGJ5IG9yIGFmZmlsaWF0ZWQg d2l0aCBhbnkgZ292ZXJubWVudCBvclwKICAgICAgICAgIG90aGVyIG9mZmljaWFsIGJ1c2luZXNz IHJlcXVlc3QuICBUaGlzIHdvdWxkIGJlIHVzZWQgZHVyaW5nIGFuXAogICAgICAgICAgaW52ZXN0 aWdhdGlvbiBieSBnb3Zlcm5tZW50IGF1dGhvcml0aWVzIG9yIG90aGVyIGdvdmVybm1lbnRcCiAg ICAgICAgICBpbmNpZGVudCBpbnZlc3RpZ2F0aW9ucyB0byB0cmFjayBzdXNwZWN0ZWQgY3JpbWlu YWwgb3Igb3RoZXJcCiAgICAgICAgICBhY3Rpdml0aWVzLlwKXAogICAgICA1LiAgT3RoZXIuICBJ ZiB0aGlzIG9wdGlvbiBpcyBzZWxlY3RlZCwgYSBkZXNjcmlwdGlvbiBvZiB0aGVcCiAgICAgICAg ICB0cmFmZmljIHR5cGUgTVVTVCBiZSBwcm92aWRlZCBzbyB0aGF0IHBvbGljeSBkZWNpc2lvbnMg Y2FuIGJlXAogICAgICAgICAgbWFkZSB0byBjb250aW51ZSBvciBzdG9wIHRoZSBpbnZlc3RpZ2F0 aW9uLiAgVGhlIGluZm9ybWF0aW9uXAogICAgICAgICAgc2hvdWxkIGJlIHByb3ZpZGVkIGluIHRo ZSBJT0RFRiBtZXNzYWdlIGluIHRoZSBFeHBlY3RhdGlvblwKICAgICAgICAgIGNsYXNzIG9yIGlu IHRoZSBIaXN0b3J5IGNsYXNzIHVzaW5nIGEgSGlzdG9yeUl0ZW0gbG9nLlwKXAogICAgICA2LiAg ZXh0LXZhbHVlLiAgQW4gZXNjYXBlIHZhbHVlIHVzZWQgdG8gZXh0ZW5kIHRoaXMgYXR0cmlidXRl LlwKICAgICAgICAgIFNlZSBJT0RFRiBbUkZDNTA3MF0sIFNlY3Rpb24gNS4xLlwKXAogICBUaGUg UklEUG9saWN5IGNsYXNzIGhhcyBmaXZlIGF0dHJpYnV0ZXM6XApcCiAgICAgIHJlc3RyaWN0aW9u XApcCiAgICAgICAgIE9QVElPTkFMLiAgRU5VTS4gIFRoaXMgYXR0cmlidXRlIGluZGljYXRlcyB0 aGUgZGlzY2xvc3VyZVwKICAgICAgICAgZ3VpZGVsaW5lcyB0byB3aGljaCB0aGUgc2VuZGVyIGV4 cGVjdHMgdGhlIHJlY2lwaWVudCB0byBhZGhlcmUuXAogICAgICAgICBUaGlzIGd1aWRlbGluZSBw cm92aWRlcyBubyByZWFsIHNlY3VyaXR5IHNpbmNlIGl0IGlzIHRoZSBjaG9pY2VcCiAgICAgICAg IG9mIHRoZSByZWNpcGllbnQgb2YgdGhlIGRvY3VtZW50IHRvIGhvbm9yIGl0LiAgVGhpcyBhdHRy aWJ1dGVcCiAgICAgICAgIGZvbGxvd3MgdGhlIHNhbWUgZ3VpZGVsaW5lcyBhcyAicmVzdHJpY3Rp b24iIHVzZWQgaW4gSU9ERUYuXApcCiAgICAgIE1zZ1R5cGVcClwKICAgICAgICAgUkVRVUlSRUQu ICBFTlVNLiAgVGhlIHR5cGUgb2YgUklEIG1lc3NhZ2Ugc2VudC4gIFRoZSBzaXggdHlwZXNcCiAg ICAgICAgIG9mIG1lc3NhZ2VzIGFyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjMuMiBhbmQgY2Fu IGJlIG5vdGVkIGFzXAogICAgICAgICBvbmUgb2YgdGhlIHNpeCBzZWxlY3Rpb25zIGJlbG93LlwK XAogICAgICBUSEVSRSBJUyBBIE1JU1RBS0UgSEVSRSAtIFNUQVJUUyBXSVRIICMyXApcCiAgICAg IDEuICBUcmFjZVJlcXVlc3QuICBUaGlzIG1lc3NhZ2UgbWF5IGJlIHVzZWQgdG8gaW5pdGlhdGUg YVwKICAgICAgICAgIFRyYWNlUmVxdWVzdCBvciB0byBjb250aW51ZSBhIFRyYWNlUmVxdWVzdCB0 byBhbiB1cHN0cmVhbVwKICAgICAgICAgIG5ldHdvcmsgY2xvc2VyIHRvIHRoZSBzb3VyY2UgYWRk cmVzcyBvZiB0aGUgb3JpZ2luIG9mIHRoZVwKICAgICAgICAgIHNlY3VyaXR5IGluY2lkZW50LlwK XAogICAgICAyLiAgUmVxdWVzdEF1dGhvcml6YXRpb24uICBUaGlzIG1lc3NhZ2UgaXMgc2VudCB0 byB0aGUgaW5pdGlhdGluZ1wKICAgICAgICAgIFJJRCBzeXN0ZW0gZnJvbSBlYWNoIG9mIHRoZSB1 cHN0cmVhbSBSSUQgc3lzdGVtcyB0byBwcm92aWRlXAogICAgICAgICAgaW5mb3JtYXRpb24gb24g dGhlIHJlcXVlc3Qgc3RhdHVzIGluIHRoZSBjdXJyZW50IG5ldHdvcmsuXApcClwKXApcClwKTW9y aWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAg ICAgW1BhZ2UgMTddXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJp cyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgIDMuICBSZXN1bHQuICBU aGlzIG1lc3NhZ2UgaW5kaWNhdGVzIHRoYXQgdGhlIHNvdXJjZSBvZiB0aGUgYXR0YWNrXAogICAg ICAgICAgd2FzIGxvY2F0ZWQgYW5kIHRoZSBtZXNzYWdlIGlzIHNlbnQgdG8gdGhlIGluaXRpYXRp bmcgUklEXAogICAgICAgICAgc3lzdGVtIHRocm91Z2ggdGhlIFJJRCBzeXN0ZW1zIGluIHRoZSBw YXRoIG9mIHRoZSB0cmFjZS5cClwKICAgICAgNC4gIEludmVzdGlnYXRpb24uICBUaGlzIG1lc3Nh Z2UgdHlwZSBpcyB1c2VkIHdoZW4gdGhlIHNvdXJjZSBvZlwKICAgICAgICAgIHRoZSB0cmFmZmlj IGlzIGJlbGlldmVkIHRvIGJlIHZhbGlkLiAgVGhlIHB1cnBvc2Ugb2YgdGhlXAogICAgICAgICAg SW52ZXN0aWdhdGlvbiByZXF1ZXN0IGlzIHRvIGxldmVyYWdlIHRoZSBleGlzdGluZyBwZWVyIG9y XAogICAgICAgICAgY29uc29ydGl1bSByZWxhdGlvbnNoaXBzIGluIG9yZGVyIHRvIG5vdGlmeSB0 aGUgbmV0d29yayBvclwKICAgICAgICAgIHNlcnZpY2UgcHJvdmlkZXIgY2xvc2VzdCB0byB0aGUg c291cmNlIG9mIHRoZSB2YWxpZCB0cmFmZmljXAogICAgICAgICAgdGhhdCBzb21lIGV2ZW50IG9j Y3VycmVkLCB3aGljaCBtYXkgYmUgYSBzZWN1cml0eS1yZWxhdGVkXAogICAgICAgICAgaW5jaWRl bnQuXApcCiAgICAgIDUuICBSZXBvcnQuICBUaGlzIG1lc3NhZ2UgaXMgdXNlZCB0byByZXBvcnQg YSBzZWN1cml0eSBpbmNpZGVudCxcCiAgICAgICAgICBmb3Igd2hpY2ggbm8gYWN0aW9uIGlzIHJl cXVlc3RlZCBpbiB0aGUgSU9ERUYgRXhwZWN0YXRpb25cCiAgICAgICAgICBjbGFzcy4gIFRoaXMg bWF5IGJlIHVzZWQgZm9yIHRoZSBwdXJwb3NlIG9mIGNvcnJlbGF0aW5nIGF0dGFja1wKICAgICAg ICAgIGluZm9ybWF0aW9uIGJ5IENTSVJUcywgc3RhdGlzdGljcyBhbmQgdHJlbmRpbmcgaW5mb3Jt YXRpb24sXAogICAgICAgICAgZXRjLlwKXAogICAgICA2LiAgSW5jaWRlbnRRdWVyeS4gIFRoaXMg bWVzc2FnZSBpcyB1c2VkIHRvIHJlcXVlc3QgaW5mb3JtYXRpb25cCiAgICAgICAgICBmcm9tIGEg dHJ1c3RlZCBSSUQgc3lzdGVtIGFib3V0IGFuIGluY2lkZW50IG9yIGluY2lkZW50IHR5cGUuXApc CiAgICAgIEFkZGl0aW9uYWxseSwgdGhlcmUgaXMgYW4gZXh0ZW5zaW9uIGF0dHJpYnV0ZSB0byBh ZGQgbmV3XAogICAgICBlbnVtZXJhdGVkIHZhbHVlczpcClwKICAgICAgICAgZXh0LXZhbHVlLiAg QW4gZXNjYXBlIHZhbHVlIHVzZWQgdG8gZXh0ZW5kIHRoaXMgYXR0cmlidXRlLiAgU2VlXAogICAg ICAgICBJT0RFRiBbUkZDNTA3MF0sIFNlY3Rpb24gNS4xLlwKXAogICAgICBNc2dEZXN0aW5hdGlv blwKXAogICAgICAgICBSRVFVSVJFRC4gIEVOVU0uICBUaGUgZGVzdGluYXRpb24gcmVxdWlyZWQg YXQgdGhpcyBsZXZlbCBtYXlcCiAgICAgICAgIGVpdGhlciBiZSB0aGUgUklEIG1lc3NhZ2luZyBz eXN0ZW0gaW50ZW5kZWQgdG8gcmVjZWl2ZSB0aGVcCiAgICAgICAgIHJlcXVlc3QsIG9yLCBpbiB0 aGUgY2FzZSBvZiBhbiBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QsIHRoZVwKICAgICAgICAgc291cmNl IG9mIHRoZSBpbmNpZGVudC4gIEluIHRoZSBjYXNlIG9mIGFuIEludmVzdGlnYXRpb25cCiAgICAg ICAgIHJlcXVlc3QsIHRoZSBSSUQgc3lzdGVtIHRoYXQgY2FuIGhlbHAgc3RvcCBvciBtaXRpZ2F0 ZSB0aGVcCiAgICAgICAgIHRyYWZmaWMgbWF5IG5vdCBiZSBrbm93biwgYW5kIHRoZSBtZXNzYWdl IG1heSBoYXZlIHRvIHRyYXZlcnNlXAogICAgICAgICBSSUQgbWVzc2FnaW5nIHN5c3RlbXMgYnkg Zm9sbG93aW5nIHRoZSByb3V0aW5nIHBhdGggdG8gdGhlIFJJRFwKICAgICAgICAgc3lzdGVtIGNs b3Nlc3QgdG8gdGhlIHNvdXJjZSBvZiB0aGUgYXR0YWNrIHRyYWZmaWMuICBUaGUgTm9kZVwKICAg ICAgICAgZWxlbWVudCBsaXN0cyBlaXRoZXIgdGhlIFJJRCBzeXN0ZW0gb3IgdGhlIElQIGFkZHJl c3Mgb2YgdGhlXAogICAgICAgICBzb3VyY2UsIGFuZCB0aGUgbWVhbmluZyBvZiB0aGUgdmFsdWUg aW4gdGhlIE5vZGUgZWxlbWVudCBpc1wKICAgICAgICAgZGV0ZXJtaW5lZCBieSB0aGUgTXNnRGVz dGluYXRpb24gZWxlbWVudC5cClwKICAgICAgICAgMS4gIFJJRFN5c3RlbS4gIFRoZSBhZGRyZXNz IGxpc3RlZCBpbiB0aGUgTm9kZSBlbGVtZW50IG9mIHRoZVwKICAgICAgICAgICAgIFJJRFBvbGlj eSBjbGFzcyBpcyB0aGUgbmV4dCB1cHN0cmVhbSBSSUQgc3lzdGVtIHRoYXQgd2lsbFwKICAgICAg ICAgICAgIHJlY2VpdmUgdGhlIFJJRCBtZXNzYWdlLlwKXAogICAgICAgICAyLiAgU291cmNlT2ZJ bmNpZGVudC4gIFRoZSBhZGRyZXNzIGxpc3RlZCBpbiB0aGUgTm9kZSBlbGVtZW50XAogICAgICAg ICAgICAgb2YgdGhlIFJJRFBvbGljeSBjbGFzcyBpcyB0aGUgaW5jaWRlbnQgc291cmNlLiAgVGhl IElQXAogICAgICAgICAgICAgYWRkcmVzcyBpcyB1c2VkIHRvIGRldGVybWluZSB0aGUgcGF0aCBv ZiBzeXN0ZW1zIGFjY2VwdGluZ1wKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMThdXApcCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3Qg MjAxMVwKXApcCiAgICAgICAgICAgICBSSUQgY29tbXVuaWNhdGlvbnMgdGhhdCB3aWxsIGJlIHVz ZWQgdG8gZmluZCB0aGUgY2xvc2VzdFwKICAgICAgICAgICAgIFJJRCBzeXN0ZW0gdG8gdGhlIHNv dXJjZSBvZiBhbiBhdHRhY2sgaW4gd2hpY2ggdGhlIElQXAogICAgICAgICAgICAgYWRkcmVzcyB1 c2VkIGJ5IHRoZSBzb3VyY2UgaXMgYmVsaWV2ZWQgdG8gYmUgdmFsaWQgYW5kIGFuXAogICAgICAg ICAgICAgSW52ZXN0aWdhdGlvbiByZXF1ZXN0IG1lc3NhZ2UgaXMgdXNlZC4gIFRoaXMgaXMgbm90 IHRvIGJlXAogICAgICAgICAgICAgY29uZnVzZWQgd2l0aCB0aGUgSW5jaWRlbnRTb3VyY2UgY2xh c3MsIGFzIHRoZSBkZWZpbmVkXAogICAgICAgICAgICAgdmFsdWUgaGVyZSBpcyBmcm9tIGFuIGlu aXRpYWwgdHJhY2Ugb3IgSW52ZXN0aWdhdGlvblwKICAgICAgICAgICAgIHJlcXVlc3QsIG5vdCB0 aGUgc291cmNlIHVzZWQgaW4gYSBSZXN1bHQgbWVzc2FnZS5cClwKICAgICAgICAgMy4gIGV4dC12 YWx1ZS4gIEFuIGVzY2FwZSB2YWx1ZSB1c2VkIHRvIGV4dGVuZCB0aGlzIGF0dHJpYnV0ZS5cCiAg ICAgICAgICAgICBTZWUgSU9ERUYgW1JGQzUwNzBdLCBTZWN0aW9uIDUuMS5cClwKICAgICAgTXNn VHlwZS1leHRcClwKICAgICAgICAgT1BUSU9OQUwuICBTVFJJTkcuICBBIG1lYW5zIGJ5IHdoaWNo IHRvIGV4dGVuZCB0aGUgTXNnVHlwZVwKICAgICAgICAgYXR0cmlidXRlLiAgU2VlIElPREVGIFtS RkM1MDcwXSwgU2VjdGlvbiA1LjEuXApcCiAgICAgIE1zZ0Rlc3RpbmF0aW9uLWV4dFwKXAogICAg ICAgICBPUFRJT05BTC4gIFNUUklORy4gIEEgbWVhbnMgYnkgd2hpY2ggdG8gZXh0ZW5kIHRoZVwK ICAgICAgICAgTXNnRGVzdGluYXRpb24gYXR0cmlidXRlLiAgU2VlIElPREVGIFtSRkM1MDcwXSwg U2VjdGlvbiA1LjFcClwKMy4yLiAgUmVxdWVzdFN0YXR1c1wKXAogICBUaGUgUmVxdWVzdFN0YXR1 cyBjbGFzcyBpcyBhbiBhZ2dyZWdhdGUgY2xhc3MgaW4gdGhlIFJJRCBjbGFzcy5cClwKICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rXAogICAg ICAgICAgICAgICAgICAgICAgIHwgUmVxdWVzdFN0YXR1cyAgICAgICAgICAgICAgICAgIHxcCiAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tK1wK ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 XAogICAgICAgICAgICAgICAgICAgICAgIHwgRU5VTSByZXN0cmljdGlvbiAgICAgICAgICAgICAg IHxcCiAgICAgICAgICAgICAgICAgICAgICAgfCBFTlVNIEF1dGhvcml6YXRpb25TdGF0dXMgICAg ICAgfFwKICAgICAgICAgICAgICAgICAgICAgICB8IEVOVU0gSnVzdGlmaWNhdGlvbiAgICAgICAg ICAgICB8XAogICAgICAgICAgICAgICAgICAgICAgIHwgU1RSSU5HIGV4dC1BdXRob3JpemF0aW9u U3RhdHVzIHxcCiAgICAgICAgICAgICAgICAgICAgICAgfCBTVFJJTkcgZXh0LUp1c3RpZmljYXRp b24gICAgICAgfFwKICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8XAogICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLStcClwKICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDU6IFRoZSBSZXF1 ZXN0U3RhdHVzIENsYXNzXApcCiAgIFRoZSBSZXF1ZXN0U3RhdHVzIGNsYXNzIGhhcyBmaXZlIGF0 dHJpYnV0ZXM6XApcCiAgICAgIHJlc3RyaWN0aW9uXApcCiAgICAgICAgIE9QVElPTkFMLiAgRU5V TS4gIFRoaXMgYXR0cmlidXRlIGluZGljYXRlcyB0aGUgZGlzY2xvc3VyZVwKICAgICAgICAgZ3Vp ZGVsaW5lcyB0byB3aGljaCB0aGUgc2VuZGVyIGV4cGVjdHMgdGhlIHJlY2lwaWVudCB0byBhZGhl cmUuXAogICAgICAgICBUaGlzIGd1aWRlbGluZSBwcm92aWRlcyBubyByZWFsIHNlY3VyaXR5IHNp bmNlIGl0IGlzIHRoZSBjaG9pY2VcCiAgICAgICAgIG9mIHRoZSByZWNpcGllbnQgb2YgdGhlIGRv Y3VtZW50IHRvIGhvbm9yIGl0LiAgVGhpcyBhdHRyaWJ1dGVcCiAgICAgICAgIGZvbGxvd3MgdGhl IHNhbWUgZ3VpZGVsaW5lcyBhcyAicmVzdHJpY3Rpb24iIHVzZWQgaW4gSU9ERUYuXApcClwKXApN b3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAg ICAgICBbUGFnZSAxOV1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUt YmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgQXV0aG9yaXphdGlv blN0YXR1c1wKXAogICAgICAgICBSRVFVSVJFRC4gIEVOVU0uICBUaGUgbGlzdGVkIHZhbHVlcyBh cmUgdXNlZCB0byBwcm92aWRlIGFcCiAgICAgICAgIHJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0aW5n IENTSVJUIG9mIHRoZSBzdGF0dXMgb2YgYVwKICAgICAgICAgVHJhY2VSZXF1ZXN0IGluIHRoZSBj dXJyZW50IG5ldHdvcmsuXApcCiAgICAgICAgIDEuICBBcHByb3ZlZC4gIFRoZSB0cmFjZSB3YXMg YXBwcm92ZWQgYW5kIHdpbGwgYmVnaW4gaW4gdGhlXAogICAgICAgICAgICAgY3VycmVudCBTUC5c ClwKICAgICAgICAgMi4gIERlbmllZC4gIFRoZSB0cmFjZSB3YXMgZGVuaWVkIGluIHRoZSBjdXJy ZW50IFNQLiAgVGhlIG5leHRcCiAgICAgICAgICAgICBjbG9zZXN0IFNQIGNhbiB1c2UgdGhpcyBt ZXNzYWdlIHRvIGZpbHRlciB0cmFmZmljIGZyb20gdGhlXAogICAgICAgICAgICAgdXBzdHJlYW0g U1AgdXNpbmcgdGhlIGV4YW1wbGUgcGFja2V0IHRvIGhlbHAgbWl0aWdhdGUgdGhlXAogICAgICAg ICAgICAgZWZmZWN0cyBvZiB0aGUgYXR0YWNrIGFzIGNsb3NlIHRvIHRoZSBzb3VyY2UgYXMgcG9z c2libGUuXAogICAgICAgICAgICAgVGhlIFJlcXVlc3RBdXRob3JpemF0aW9uIG1lc3NhZ2UgbXVz dCBiZSBwYXNzZWQgYmFjayB0byB0aGVcCiAgICAgICAgICAgICBvcmlnaW5hdG9yIGFuZCBhIFJl c3VsdCBtZXNzYWdlIHVzZWQgZnJvbSB0aGUgY2xvc2VzdCBTUCB0b1wKICAgICAgICAgICAgIHRo ZSBzb3VyY2UgdG8gaW5kaWNhdGUgYWN0aW9ucyB0YWtlbiBpbiB0aGUgSU9ERUYgSGlzdG9yeVwK ICAgICAgICAgICAgIGNsYXNzLlwKXAogICAgICAgICAzLiAgUGVuZGluZy4gIEF3YWl0aW5nIGFw cHJvdmFsOyBhIHRpbWVvdXQgcGVyaW9kIGhhcyBiZWVuXAogICAgICAgICAgICAgcmVhY2hlZCwg d2hpY2ggcmVzdWx0ZWQgaW4gdGhpcyBQZW5kaW5nIHN0YXR1cyBhbmRcCiAgICAgICAgICAgICBS ZXF1ZXN0QXV0aG9yaXphdGlvbiBtZXNzYWdlIGJlaW5nIGdlbmVyYXRlZC5cClwKICAgICAgICAg NC4gIGV4dC12YWx1ZS4gIEFuIGVzY2FwZSB2YWx1ZSB1c2VkIHRvIGV4dGVuZCB0aGlzIGF0dHJp YnV0ZS5cCiAgICAgICAgICAgICBTZWUgSU9ERUYgW1JGQzUwNzBdLCBTZWN0aW9uIDUuMS5cClwK ICAgICAgICAgSnVzdGlmaWNhdGlvblwKXAogICAgICAgICAgICBPUFRJT05BTC4gIEVOVU0uICBQ cm92aWRlcyBhIHJlYXNvbiBmb3IgYSBEZW5pZWQgb3IgUGVuZGluZ1wKICAgICAgICAgICAgbWVz c2FnZS5cClwKICAgICAgICAgRVJST1IgSEVSRSBGT1IgTlVNQkVSUyAtIFNUQVJUIFdJVEggMiBJ TlNURUFEIE9GIDFcClwKICAgICAgICAgMS4gIFN5c3RlbVJlc291cmNlLiAgQSByZXNvdXJjZSBp c3N1ZSBleGlzdHMgb24gdGhlIHN5c3RlbXNcCiAgICAgICAgICAgICB0aGF0IHdvdWxkIGJlIGlu dm9sdmVkIGluIHRoZSByZXF1ZXN0LlwKXAogICAgICAgICAyLiAgQXV0aGVudGljYXRpb24uICBU aGUgZW52ZWxvcGVkIGRpZ2l0YWwgc2lnbmF0dXJlIFtSRkMzMjc1XVwKICAgICAgICAgICAgIGZh aWxlZCB0byB2YWxpZGF0ZS5cClwKICAgICAgICAgMy4gIEF1dGhlbnRpY2F0aW9uT3JpZ2luLiAg VGhlIGRldGFjaGVkIGRpZ2l0YWwgc2lnbmF0dXJlIGZvclwKICAgICAgICAgICAgIHRoZSBvcmln aW5hbCByZXF1ZXN0b3Igb24gdGhlIElQIHBhY2tldCBmYWlsZWQgdG8gdmFsaWRhdGUuXApcCiAg ICAgICAgIDQuICBFbmNyeXB0aW9uLiAgVW5hYmxlIHRvIGRlY3J5cHQgdGhlIHJlcXVlc3QuXApc CiAgICAgICAgIDUuICBPdGhlci4gIFRoZXJlIHdlcmUgb3RoZXIgcmVhc29ucyB0aGlzIHJlcXVl c3QgY291bGQgbm90IGJlXAogICAgICAgICAgICAgcHJvY2Vzc2VkLlwKXAogICAgICAgICA2LiAg ZXh0LXZhbHVlLiAgQW4gZXNjYXBlIHZhbHVlIHVzZWQgdG8gZXh0ZW5kIHRoaXMgYXR0cmlidXRl LlwKICAgICAgICAgICAgIFNlZSBJT0RFRiBbUkZDNTA3MF0sIFNlY3Rpb24gNS4xLlwKXApcClwK TW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAg ICAgICAgW1BhZ2UgMjBdXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1 LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgICAgIEF1dGhvcml6 YXRpb25TdGF0dXMtZXh0XApcCiAgICAgICAgICAgIE9QVElPTkFMLiAgU1RSSU5HLiAgQSBtZWFu cyBieSB3aGljaCB0byBleHRlbmQgdGhlXAogICAgICAgICAgICBBdXRob3JpemF0aW9uU3RhdHVz IGF0dHJpYnV0ZS4gIFNlZSBJT0RFRiBbUkZDNTA3MF0sIFNlY3Rpb25cCiAgICAgICAgICAgIDUu MS5cClwKICAgICAgICAgSnVzdGlmaWNhdGlvbi1leHRcClwKICAgICAgICAgICAgT1BUSU9OQUwu ICBTVFJJTkcuICBBIG1lYW5zIGJ5IHdoaWNoIHRvIGV4dGVuZCB0aGVcCiAgICAgICAgICAgIEp1 c3RpZmljYXRpb24gYXR0cmlidXRlLiAgU2VlIElPREVGIFtSRkM1MDcwXSwgU2VjdGlvbiA1LjEu XApcCjMuMy4gIEluY2lkZW50U291cmNlXApcCiAgIFRoZSBJbmNpZGVudFNvdXJjZSBjbGFzcyBp cyBhbiBhZ2dyZWdhdGUgY2xhc3MgaW4gdGhlIFJJRCBjbGFzcy5cClwKICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tK1wKICAgICAgICAgIHwgSW5jaWRlbnRTb3VyY2UgICAgfFwKICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tK1wKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg fFwKICAgICAgICAgIHwgRU5VTSByZXN0cmljdGlvbiAgfFwKICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgfCZsdDsmZ3Q7LS0tLS0tLS0tLS0tLVsgU291cmNlRm91bmQgICAgXVwKICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgfFwKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg fCZsdDsmZ3Q7LS0tXHswLi4qXH0tLS0tWyBOb2RlICAgICAgICAgICBdXAogICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICB8XAogICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rXApcCiAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDY6IFRoZSBJbmNpZGVudFNvdXJjZSBDbGFzc1wKXAog ICBUaGUgZWxlbWVudHMgdGhhdCBjb25zdGl0dXRlIHRoZSBJbmNpZGVudFNvdXJjZSBjbGFzcyBm b2xsb3c6XApcCiAgICAgIFNvdXJjZUZvdW5kXApcCiAgICAgICAgIE9uZS4gQk9PTEVBTi4gIFRo ZSBTb3VyY2UgY2xhc3MgaW5kaWNhdGVzIGlmIGEgc291cmNlIHdhc1wKICAgICAgICAgaWRlbnRp ZmllZC4gIElmIHRoZSBzb3VyY2Ugd2FzIGlkZW50aWZpZWQsIGl0IGlzIGxpc3RlZCBpbiB0aGVc CiAgICAgICAgIE5vZGUgZWxlbWVudCBvZiB0aGlzIGNsYXNzLlwKXAogICAgICAgICBUcnVlLiAg U291cmNlIG9mIGluY2lkZW50IHdhcyBpZGVudGlmaWVkLlwKXAogICAgICAgICBGYWxzZS4gIFNv dXJjZSBvZiBpbmNpZGVudCB3YXMgbm90IGlkZW50aWZpZWQuXApcCiAgICAgIE5vZGVcClwKICAg ICAgICAgT25lLiBUaGUgTm9kZSBjbGFzcyBpcyB1c2VkIHRvIGlkZW50aWZ5IGEgaG9zdCBvciBu ZXR3b3JrXAogICAgICAgICBkZXZpY2UsIGluIHRoaXMgY2FzZSB0byBpZGVudGlmeSB0aGUgc3lz dGVtIGNvbW11bmljYXRpbmcgUklEXAogICAgICAgICBtZXNzYWdlcy5cClwKICAgICAgICAgVGhl IGJhc2UgZGVmaW5pdGlvbiBvZiB0aGlzIGNsYXNzIGlzIHJldXNlZCBmcm9tIHRoZSBJT0RFRlwK ICAgICAgICAgc3BlY2lmaWNhdGlvbiBbUkZDNTA3MF0sIFNlY3Rpb24gMy4xNi5cClwKXApcCk1v cmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAg ICAgIFtQYWdlIDIxXVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1i aXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICBUaGUgSW5jaWRlbnRT b3VyY2UgY2xhc3MgaGFzIG9uZSBhdHRyaWJ1dGU6XApcCiAgICAgIHJlc3RyaWN0aW9uXApcCiAg ICAgICAgIE9QVElPTkFMLiAgRU5VTS4gIFRoaXMgYXR0cmlidXRlIGluZGljYXRlcyB0aGUgZGlz Y2xvc3VyZVwKICAgICAgICAgZ3VpZGVsaW5lcyB0byB3aGljaCB0aGUgc2VuZGVyIGV4cGVjdHMg dGhlIHJlY2lwaWVudCB0byBhZGhlcmUuXAogICAgICAgICBUaGlzIGd1aWRlbGluZSBwcm92aWRl cyBubyByZWFsIHNlY3VyaXR5IHNpbmNlIGl0IGlzIHRoZSBjaG9pY2VcCiAgICAgICAgIG9mIHRo ZSByZWNpcGllbnQgb2YgdGhlIGRvY3VtZW50IHRvIGhvbm9yIGl0LiAgVGhpcyBhdHRyaWJ1dGVc CiAgICAgICAgIGZvbGxvd3MgdGhlIHNhbWUgZ3VpZGVsaW5lcyBhcyAicmVzdHJpY3Rpb24iIHVz ZWQgaW4gSU9ERUYuXApcCjMuNC4gIFJJRCBOYW1lIFNwYWNlc1wKXAogICBUaGUgUklEIHNjaGVt YSBkZWNsYXJlcyBhIG5hbWVzcGFjZSBvZiAiaW9kZWYtcmlkLTEuMCIgYW5kIHJlZ2lzdGVyc1wK ICAgaXQgcGVyIFtYTUxuYW1lc10uICBFYWNoIElPREVGLVJJRCBkb2N1bWVudCBNVVNUIHVzZSB0 aGVcCiAgICJpb2RlZi1yaWQtMS4wIiBuYW1lc3BhY2UgaW4gdGhlIHRvcC1sZXZlbCBlbGVtZW50 IFJJRC1Eb2N1bWVudC4gIEl0XAogICBjYW4gYmUgcmVmZXJlbmNlZCBhcyBmb2xsb3dzOlwKXAog ICAmbHQ7UklELURvY3VtZW50IHZlcnNpb249IjEuMDAiIGxhbmc9ImVuLVVTIlwKICAgICAgeG1s bnM6aW9kZWYtcmlkPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0xLjAiXAogICAg ICB4c2k6c2NoZW1hTG9jYXRpb249aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy94bWwt cmVnaXN0cnkvXAogICAgICBzY2hlbWEvaW9kZWYtcmlkLTEuMC54c2QiJmd0O1wKXApcCjQuICBS SUQgTWVzc2FnZXNcClwKICAgVGhlIElPREVGIG1vZGVsIGlzIGZvbGxvd2VkIGFzIHNwZWNpZmll ZCBpbiBbUkZDNTA3MF0gZm9yIGVhY2ggb2YgdGhlXAogICBSSUQgbWVzc2FnZSB0eXBlcy4gIFRo ZSBSSUQgc2NoZW1hIGlzIHVzZWQgaW4gY29tYmluYXRpb24gd2l0aCBJT0RFRlwKICAgZG9jdW1l bnRzIHRvIGZhY2lsaXRhdGUgUklEIGNvbW11bmljYXRpb25zLiAgRWFjaCBtZXNzYWdlIHR5cGUg dmFyaWVzXAogICBzbGlnaHRseSBpbiBmb3JtYXQgYW5kIHB1cnBvc2U7IGhlbmNlLCB0aGUgcmVx dWlyZW1lbnRzIHZhcnkgYW5kIGFyZVwKICAgc3BlY2lmaWVkIGZvciBlYWNoLiAgQWxsIGNsYXNz ZXMsIGVsZW1lbnRzLCBhdHRyaWJ1dGVzLCBldGMuLCB0aGF0XAogICBhcmUgZGVmaW5lZCBpbiB0 aGUgSU9ERUYtRG9jdW1lbnQgYXJlIHZhbGlkIGluIHRoZSBjb250ZXh0IG9mIGEgUklEXAogICBt ZXNzYWdlOyBob3dldmVyLCBzb21lIGxpc3RlZCBhcyBvcHRpb25hbCBpbiBJT0RFRiBhcmUgbWFu ZGF0b3J5IGZvclwKICAgUklEIGFzIGxpc3RlZCBmb3IgZWFjaCBtZXNzYWdlIHR5cGUuICBUaGUg SU9ERUYgbW9kZWwgTVVTVCBiZSBmdWxseVwKICAgaW1wbGVtZW50ZWQgdG8gZW5zdXJlIHByb3Bl ciBwYXJzaW5nIG9mIGFsbCBSSUQgbWVzc2FnZXMuXApcCiAgIE5vdGU6IFRoZSBpbXBsZW1lbnRh dGlvbiBvZiBSSUQgbWF5IGF1dG9tYXRlIHRoZSBhYmlsaXR5IHRvIGZpbGwgaW5cCiAgIHRoZSBj b250ZW50IHJlcXVpcmVkIGZvciBlYWNoIG1lc3NhZ2UgdHlwZSBmcm9tIHBhY2tldCBpbnB1dCxc CiAgIGluY2lkZW50IGRhdGEsIHNpdHVhdGlvbmFsIGF3YXJlbmVzcyBpbmZvcm1hdGlvbiwgb3Ig ZGVmYXVsdCB2YWx1ZXNcCiAgIHN1Y2ggYXMgdGhhdCB1c2VkIGluIHRoZSBFdmVudERhdGEgY2xh c3MuXApcCjQuMS4gIFRyYWNlUmVxdWVzdFwKXAogICBEZXNjcmlwdGlvbjogVGhpcyBtZXNzYWdl IG9yIGRvY3VtZW50IGlzIHNlbnQgdG8gdGhlIG5ldHdvcmtcCiAgIG1hbmFnZW1lbnQgc3RhdGlv biBuZXh0IGluIHRoZSB1cHN0cmVhbSB0cmFjZSBvbmNlIHRoZSB1cHN0cmVhbVwKICAgc291cmNl IG9mIHRoZSB0cmFmZmljIGhhcyBiZWVuIGlkZW50aWZpZWQuICBUaGUgZm9sbG93aW5nIGluZm9y bWF0aW9uXAogICBpcyByZXF1aXJlZCBmb3IgVHJhY2VSZXF1ZXN0IG1lc3NhZ2VzIGFuZCBpcyBw cm92aWRlZCB0aHJvdWdoOlwKXAogICBSSUQgSW5mb3JtYXRpb246XApcClwKXApNb3JpYXJ0eSAg ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFn ZSAyMl1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgUklEUG9saWN5XApcCiAgICAgICAg IFJJRCBtZXNzYWdlIHR5cGUsIEluY2lkZW50SUQsIGFuZCBkZXN0aW5hdGlvbiBwb2xpY3lcCiAg ICAgICAgIGluZm9ybWF0aW9uXApcCiAgIElPREVGIEluZm9ybWF0aW9uOlwKXAogICAgICBUaW1l IFN0YW1wcyAoRGV0ZWN0VGltZSwgU3RhcnRUaW1lLCBFbmRUaW1lLCBSZXBvcnRUaW1lKS5cClwK ICAgICAgSW5jaWRlbnQgSWRlbnRpZmllciAoSW5jaWRlbnQgY2xhc3MsIEluY2lkZW50SUQpLlwK XAogICAgICBDb25maWRlbmNlIHJhdGluZyBvZiBzZWN1cml0eSBpbmNpZGVudCAoSW1wYWN0IGFu ZCBDb25maWRlbmNlXAogICAgICBjbGFzcykuXApcCiAgICAgIFN5c3RlbSBjbGFzcyBpcyB1c2Vk IHRvIGxpc3QgYm90aCB0aGUgU291cmNlIGFuZCBEZXN0aW5hdGlvbi5cClwKICAgICAgRXhwZWN0 YXRpb24gY2xhc3Mgc2hvdWxkIGJlIHVzZWQgdG8gcmVxdWVzdCBhbnkgc3BlY2lmaWMgYWN0aW9u c1wKICAgICAgdG8gYmUgdGFrZW4gY2xvc2UgdG8gdGhlIHNvdXJjZS5cClwKICAgICAgUGF0aCBp bmZvcm1hdGlvbiBvZiBuZXN0ZWQgUklEIHN5c3RlbXMsIGJlZ2lubmluZyB3aXRoIHRoZSByZXF1 ZXN0XAogICAgICBvcmlnaW5hdG9yIHVzZWQgaW4gdGhlIHRyYWNlIHVzaW5nIElPREVGIEV2ZW50 RGF0YSB3aXRoIGNhdGVnb3J5XAogICAgICBzZXQgdG8gImluZnJhc3RydWN0dXJlIi5cClwKICAg ICAgRXZlbnQsIFJlY29yZCwgYW5kIFJlY29yZEl0ZW0gY2xhc3NlcyB0byBpbmNsdWRlIGV4YW1w bGUgcGFja2V0c1wKICAgICAgYW5kIG90aGVyIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIGlu Y2lkZW50LiAgTm90ZTogRXZlbnRcCiAgICAgIGluZm9ybWF0aW9uIGluY2x1ZGVkIGhlcmUgcmVx dWlyZXMgYSBzZWNvbmQgaW5zdGFuY2Ugb2YgRXZlbnREYXRhXAogICAgICBpbiBhZGRpdGlvbiB0 byB0aGF0IHVzZWQgdG8gY29udmV5IHNlcnZpY2UvbmV0d29yayBwcm92aWRlciAoU1ApXAogICAg ICBwYXRoIGNvbnRhY3QgaW5mb3JtYXRpb24uXApcCiAgIFN0YW5kYXJkcyBmb3IgZW5jcnlwdGlv biBhbmQgZGlnaXRhbCBzaWduYXR1cmVzIFtSRkMzMjc1XSwgW1hNTHNpZ106XApcCiAgICAgIERp Z2l0YWwgc2lnbmF0dXJlIGZyb20gaW5pdGlhdGluZyBDU0lSVCBvciBwcm92aWRlciBzeXN0ZW0g c2VuZGluZ1wKICAgICAgdGhlIFJJRCBtZXNzYWdlLCBwYXNzZWQgdG8gYWxsIHN5c3RlbXMgaW4g dXBzdHJlYW0gdHJhY2UgdXNpbmcgWE1MXAogICAgICBkaWdpdGFsIHNpZ25hdHVyZS5cClwKICAg QSBERG9TIGF0dGFjayBjYW4gaGF2ZSBtYW55IHNvdXJjZXMsIHJlc3VsdGluZyBpbiBtdWx0aXBs ZSB0cmFjZXMgdG9cCiAgIGxvY2F0ZSB0aGUgc291cmNlcyBvZiB0aGUgYXR0YWNrLiAgSXQgbWF5 IGJlIHZhbGlkIHRvIGNvbnRpbnVlXAogICBtdWx0aXBsZSB0cmFjZXMgZm9yIGEgc2luZ2xlIGF0 dGFjay4gIFRoZSBwYXRoIGluZm9ybWF0aW9uIHdvdWxkXAogICBlbmFibGUgdGhlIGFkbWluaXN0 cmF0b3JzIHRvIGRldGVybWluZSBpZiB0aGUgZXhhY3QgdHJhY2UgaGFkIGFscmVhZHlcCiAgIHBh c3NlZCB0aHJvdWdoIGEgc2luZ2xlIG5ldHdvcmsuICBUaGUgSW5jaWRlbnQgSWRlbnRpZmllciBt dXN0IGFsc29cCiAgIGJlIHVzZWQgdG8gaWRlbnRpZnkgbXVsdGlwbGUgVHJhY2VSZXF1ZXN0cyBm cm9tIGEgc2luZ2xlIGluY2lkZW50LlwKICAgSWYgYSBzaW5nbGUgVHJhY2VSZXF1ZXN0IHJlc3Vs dHMgaW4gZGl2ZXJnZW50IHBhdGhzIG9mIFRyYWNlUmVxdWVzdHMsXAogICBhIHNlcGFyYXRlIGlu c3RhbmNlIG51bWJlciBNVVNUIGJlIHVzZWQgdW5kZXIgdGhlIHNhbWUgSW5jaWRlbnRJRC5cCiAg IFRoZSBJbmNpZGVudElEIGluc3RhbmNlIG51bWJlciBvZiBJT0RFRiBjYW4gYmUgdXNlZCB0byBj b3JyZWxhdGVcCiAgIHJlbGF0ZWQgaW5jaWRlbnQgZGF0YSB0aGF0IGlzIHBhcnQgb2YgYSBsYXJn ZXIgaW5jaWRlbnQuXApcClwKXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVz IEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyM11cClwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDExXApcClwKNC4yLiAgUmVxdWVzdEF1dGhvcml6YXRpb25cClwKICAgRGVzY3JpcHRpb246IFRo aXMgbWVzc2FnZSBpcyBzZW50IHRvIHRoZSBpbml0aWF0aW5nIFJJRCBzeXN0ZW0gZnJvbVwKICAg dGhlIG5leHQgdXBzdHJlYW0gcHJvdmlkZXIncyBhcHBsaWNhdGlvbiBvciBzeXN0ZW0gZGVzaWdu YXRlZCBmb3JcCiAgIGFjY2VwdGluZyBSSUQgY29tbXVuaWNhdGlvbnMgdG8gcHJvdmlkZSBpbmZv cm1hdGlvbiBvbiB0aGUgcmVxdWVzdFwKICAgc3RhdHVzIGluIHRoZSBjdXJyZW50IG5ldHdvcmsu XApcCiAgIFRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQgZm9yIFJlcXVlc3RB dXRob3JpemF0aW9uXAogICBtZXNzYWdlcyBhbmQgaXMgcHJvdmlkZWQgdGhyb3VnaDpcClwKICAg UklEIEluZm9ybWF0aW9uOlwKXAogICAgICBSSURQb2xpY3lcClwKICAgICAgICAgUklEIG1lc3Nh Z2UgdHlwZSwgSW5jaWRlbnRJRCwgYW5kIGRlc3RpbmF0aW9uIHBvbGljeVwKICAgICAgICAgaW5m b3JtYXRpb25cClwKICAgICAgUmVxdWVzdFN0YXR1cyBjbGFzczpcClwKICAgICAgICAgU3RhdHVz IG9mIFRyYWNlUmVxdWVzdFwKXAogICBTdGFuZGFyZHMgZm9yIGVuY3J5cHRpb24gYW5kIGRpZ2l0 YWwgc2lnbmF0dXJlcyBbUkZDMzI3NV0sIFtYTUxzaWddOlwKXAogICAgICBEaWdpdGFsIHNpZ25h dHVyZSBvZiByZXNwb25kaW5nIENTSVJUIG9yIHByb3ZpZGVyIGZvciBhdXRoZW50aWNpdHlcCiAg ICAgIG9mIFRyYWNlIFN0YXR1cyBNZXNzYWdlLCBmcm9tIHRoZSBDU0lSVCBvciBwcm92aWRlciBj cmVhdGluZyB0aGlzXAogICAgICBtZXNzYWdlIHVzaW5nIFhNTCBkaWdpdGFsIHNpZ25hdHVyZS5c ClwKICAgQSBtZXNzYWdlIGlzIHNlbnQgYmFjayB0byB0aGUgaW5pdGlhdGluZyBDU0lSVCBvciBw cm92aWRlcidzIHN5c3RlbVwKICAgYWNjZXB0aW5nIFJJRCBjb21tdW5pY2F0aW9ucyBvZiB0aGUg dHJhY2UgYXMgc3RhdHVzIG5vdGlmaWNhdGlvbi5cCiAgIFRoaXMgbWVzc2FnZSB2ZXJpZmllcyB0 aGF0IHRoZSBuZXh0IFJJRCBzeXN0ZW0gaW4gdGhlIHBhdGggaGFzXAogICByZWNlaXZlZCB0aGUg bWVzc2FnZSBmcm9tIHRoZSBwcmV2aW91cyBzeXN0ZW0gaW4gdGhlIHBhdGguICBUaGlzXAogICBt ZXNzYWdlIGFsc28gdmVyaWZpZXMgdGhhdCB0aGUgdHJhY2UgaXMgbm93IGNvbnRpbnVpbmcsIGhh cyBzdG9wcGVkLFwKICAgb3IgaXMgcGVuZGluZyBpbiB0aGUgbmV4dCB1cHN0cmVhbSBDU0lSVCBv ciBwcm92aWRlcidzIFJJRCBzeXN0ZW0uXAogICBUaGUgUGVuZGluZyBzdGF0dXMgd291bGQgYmUg YXV0b21hdGljYWxseSBnZW5lcmF0ZWQgYWZ0ZXIgYSAyLW1pbnV0ZVwKICAgdGltZW91dCB3aXRo b3V0IHN5c3RlbS1wcmVkZWZpbmVkIG9yIGFkbWluaXN0cmF0b3IgYWN0aW9uIHRha2VuIHRvXAog ICBhcHByb3ZlIG9yIGRpc2FwcHJvdmUgdGhlIHRyYWNlIGNvbnRpbnVhbmNlLiAgSWYgYSBSZXF1 ZXN0IGlzIGRlbmllZCxcCiAgIHRoZSBvcmlnaW5hdG9yIGFuZCBzZW5kaW5nIHBlZXIgKGlmIHRo ZXkgYXJlIG5vdCB0aGUgc2FtZSkgc2hhbGwgYm90aFwKICAgcmVjZWl2ZSB0aGUgbWVzc2FnZS4g IFRoaXMgZW5hYmxlcyB0aGUgc2VuZGluZyBwZWVyIHRoZSBvcHRpb24gdG9cCiAgIHRha2UgYWN0 aW9uIHRvIHN0b3Agb3IgbWl0aWdhdGUgdGhlIHRyYWZmaWMgYXMgY2xvc2UgdG8gdGhlIHNvdXJj ZSBhc1wKICAgcG9zc2libGUuXApcCjQuMy4gIFJlc3VsdFwKXAogICBEZXNjcmlwdGlvbjogVGhp cyBtZXNzYWdlIGluZGljYXRlcyB0aGF0IHRoZSB0cmFjZSBvciBpbnZlc3RpZ2F0aW9uXAogICBo YXMgYmVlbiBjb21wbGV0ZWQgYW5kIHByb3ZpZGVzIHRoZSByZXN1bHQuICBUaGUgUmVzdWx0IG1l c3NhZ2VcCiAgIGluY2x1ZGVzIGluZm9ybWF0aW9uIG9uIHdoZXRoZXIgb3Igbm90IGEgc291cmNl IHdhcyBmb3VuZCBhbmQgdGhlXAogICBzb3VyY2UgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgSW5j aWRlbnRTb3VyY2UgY2xhc3MuICBUaGUgUmVzdWx0XAogICBpbmZvcm1hdGlvbiBzaGFsbCBnbyBi YWNrIHRvIHRoZSBvcmlnaW5hdGluZyBSSUQgc3lzdGVtIHRoYXQgYmVnYW5cClwKXApcCk1vcmlh cnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAg IFtQYWdlIDI0XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMg ICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICB0aGUgaW52ZXN0aWdhdGlvbiBv ciB0cmFjZS4gIEFuIHByb3ZpZGVyIG1heSB1c2UgYW55IG51bWJlciBvZlwKICAgaW5jaWRlbnQg aGFuZGxpbmcgZGF0YSBzb3VyY2VzIHRvIGFzY2VydGFpbiB0aGUgdHJ1ZSBzb3VyY2Ugb2YgYW5c CiAgIGF0dGFjay4gIEFsbCBvZiB0aGUgcG9zc2libGUgaW5mb3JtYXRpb24gc291cmNlcyBtYXkg b3IgbWF5IG5vdCBiZVwKICAgcmVhZGlseSB0aWVkIGludG8gdGhlIFJJRCBjb21tdW5pY2F0aW9u cyBzeXN0ZW0uXApcCiAgIFRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQgZm9y IFJlc3VsdCBtZXNzYWdlcyBhbmQgd2lsbCBiZVwKICAgcHJvdmlkZWQgdGhyb3VnaDpcClwKICAg ICAgUklEIEluZm9ybWF0aW9uOlwKXAogICAgICAgICBSSURQb2xpY3lcClwKICAgICAgICAgICAg UklEIG1lc3NhZ2UgdHlwZSwgSW5jaWRlbnRJRCwgYW5kIGRlc3RpbmF0aW9uIHBvbGljeVwKICAg ICAgICAgICAgaW5mb3JtYXRpb25cClwKICAgICAgICAgSW5jaWRlbnQgU291cmNlXApcCiAgICAg ICAgICAgIFRoZSBJbmNpZGVudFNvdXJjZSBjbGFzcyBvZiB0aGUgUklEIHNjaGVtYSBpcyB1c2Vk IHRvIG5vdGVcCiAgICAgICAgICAgIGlmIGEgc291cmNlIHdhcyBpZGVudGlmaWVkIGFuZCBwcm92 aWRlIHRoZSBzb3VyY2VcCiAgICAgICAgICAgIGFkZHJlc3MoZXMpLlwKXAogICAgICBJT0RFRiBJ bmZvcm1hdGlvbjpcClwKICAgICAgICAgVGltZSBTdGFtcHMgKERldGVjdFRpbWUsIFN0YXJ0VGlt ZSwgRW5kVGltZSwgUmVwb3J0VGltZSkuXApcCiAgICAgICAgIEluY2lkZW50IElkZW50aWZpZXIg KEluY2lkZW50IGNsYXNzLCBJbmNpZGVudElEKS5cClwKICAgICAgICAgICAgVHJhY2UgbnVtYmVy IC0gdXNlZCBmb3IgbXVsdGlwbGUgdHJhY2VzIG9mIGEgc2luZ2xlXAogICAgICAgICAgICBpbmNp ZGVudDsgbXVzdCBiZSBub3RlZC5cClwKICAgICAgICAgQ29uZmlkZW5jZSByYXRpbmcgb2Ygc2Vj dXJpdHkgaW5jaWRlbnQgKEltcGFjdCBhbmQgQ29uZmlkZW5jZVwKICAgICAgICAgY2xhc3MpLlwK XAogICAgICAgICBTeXN0ZW0gY2xhc3MgaXMgdXNlZCB0byBsaXN0IGJvdGggdGhlIFNvdXJjZSBh bmQgRGVzdGluYXRpb25cCiAgICAgICAgIEluZm9ybWF0aW9uIHVzZWQgaW4gdGhlIGF0dGFjayBh bmQgbXVzdCBub3RlIGlmIHRoZSB0cmFmZmljIGlzXAogICAgICAgICBzcG9vZmVkLCB0aHVzIHJl cXVpcmluZyBhbiB1cHN0cmVhbSBUcmFjZVJlcXVlc3QgaW4gUklELlwKXAogICAgICAgICBIaXN0 b3J5IGNsYXNzICJhdHlwZSIgYXR0cmlidXRlIGlzIHVzZWQgdG8gbm90ZSBhbnkgYWN0aW9uc1wK ICAgICAgICAgdGFrZW4uXApcCiAgICAgICAgIEhpc3RvcnkgY2xhc3MgYWxzbyBub3RlcyBhbnkg b3RoZXIgYmFja2dyb3VuZCBpbmZvcm1hdGlvblwKICAgICAgICAgaW5jbHVkaW5nIG5vdGVzIGFi b3V0IHRoZSBjb25maWRlbmNlIGxldmVsIG9yIHJhdGluZyBvZiB0aGVcCiAgICAgICAgIHJlc3Vs dCBpbmZvcm1hdGlvbi5cClwKICAgICAgICAgUGF0aCBpbmZvcm1hdGlvbiBvZiBuZXN0ZWQgUklE IHN5c3RlbXMsIGJlZ2lubmluZyB3aXRoIHRoZVwKICAgICAgICAgcmVxdWVzdCBvcmlnaW5hdG9y IHVzZWQgaW4gdGhlIHRyYWNlIHVzaW5nIElPREVGIEV2ZW50RGF0YSB3aXRoXAogICAgICAgICBj YXRlZ29yeSBzZXQgdG8gImluZnJhc3RydWN0dXJlIi4gIFRoZSBsYXN0IFNQIGxpc3RlZCBpcyB0 aGUgU1BcCiAgICAgICAgIHRoYXQgbG9jYXRlZCB0aGUgc291cmNlIG9mIHRoZSB0cmFmZmljICh0 aGUgcHJvdmlkZXIgc2VuZGluZ1wKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjVdXApcCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3Qg MjAxMVwKXApcCiAgICAgICAgIHRoZSBSZXN1bHQgbWVzc2FnZSkuXApcCiAgICAgICAgIEV2ZW50 LCBSZWNvcmQsIGFuZCBSZWNvcmRJdGVtIGNsYXNzZXMgdG8gaW5jbHVkZSBleGFtcGxlXAogICAg ICAgICBwYWNrZXRzIGFuZCBvdGhlciBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBpbmNpZGVu dFwKICAgICAgICAgKG9wdGlvbmFsKS4gIE5vdGU6IEV2ZW50IGluZm9ybWF0aW9uIGluY2x1ZGVk IGhlcmUgcmVxdWlyZXMgYVwKICAgICAgICAgc2Vjb25kIGluc3RhbmNlIG9mIEV2ZW50RGF0YSBp biBhZGRpdGlvbiB0byB0aGF0IHVzZWQgdG8gY29udmV5XAogICAgICAgICBTUCBwYXRoIGNvbnRh Y3QgaW5mb3JtYXRpb24uXApcCiAgICAgIFN0YW5kYXJkcyBmb3IgZW5jcnlwdGlvbiBhbmQgZGln aXRhbCBzaWduYXR1cmVzIFtSRkMzMjc1XTpcClwKICAgICAgICAgRGlnaXRhbCBzaWduYXR1cmUg b2Ygc291cmNlIENTSVJUIG9yIHByb3ZpZGVyIGZvciBhdXRoZW50aWNpdHlcCiAgICAgICAgIG9m IFJlc3VsdCBtZXNzYWdlLCBmcm9tIHRoZSBDU0lSVCBvciBwcm92aWRlciBjcmVhdGluZyB0aGlz XAogICAgICAgICBtZXNzYWdlIHVzaW5nIFhNTCBkaWdpdGFsIHNpZ25hdHVyZS5cClwKICAgQSBt ZXNzYWdlIGlzIHNlbnQgYmFjayB0byB0aGUgaW5pdGlhdGluZyBDU0lSVCBvciBwcm92aWRlcidz IFJJRFwKICAgc3lzdGVtIHRvIG5vdGlmeSB0aGUgQ1NJUlQgdGhhdCB0aGUgc291cmNlIGhhcyBi ZWVuIGxvY2F0ZWQuICBUaGVcCiAgIGFjdHVhbCBzb3VyY2UgaW5mb3JtYXRpb24gbWF5IG9yIG1h eSBub3QgYmUgaW5jbHVkZWQsIGRlcGVuZGluZyBvblwKICAgdGhlIHBvbGljeSBvZiB0aGUgbmV0 d29yayBpbiB3aGljaCB0aGUgY2xpZW50IG9yIGhvc3QgaXMgYXR0YWNoZWQuXAogICBBbnkgYWN0 aW9uIHRha2VuIGJ5IHRoZSBTUCB0byBhY3QgdXBvbiB0aGUgZGlzY292ZXJ5IG9mIHRoZSBzb3Vy Y2Ugb2ZcCiAgIGEgdHJhY2Ugc2hvdWxkIGJlIGluY2x1ZGVkLiAgVGhlIFNQIG1heSBiZSBhYmxl IHRvIGF1dG9tYXRlIHRoZVwKICAgYWRqdXN0bWVudCBvZiBmaWx0ZXJzIGF0IHRoZWlyIGJvcmRl ciByb3V0ZXIgdG8gYmxvY2sgb3V0Ym91bmQgYWNjZXNzXAogICBmb3IgdGhlIG1hY2hpbmUocykg ZGlzY292ZXJlZCBhcyBhIHBhcnQgb2YgdGhlIGF0dGFjay4gIFRoZSBmaWx0ZXJzXAogICBtYXkg YmUgY29tcHJlaGVuc2l2ZSBlbm91Z2ggdG8gYmxvY2sgYWxsIEludGVybmV0IGFjY2VzcyB1bnRp bCB0aGVcCiAgIGhvc3QgaGFzIHRha2VuIHRoZSBhcHByb3ByaWF0ZSBhY3Rpb24gdG8gcmVzb2x2 ZSBhbnkgc2VjdXJpdHkgaXNzdWVzXAogICBvciB0byByYXRlLWxpbWl0IHRoZSBpbmdyZXNzIHRy YWZmaWMgYXMgY2xvc2UgdG8gdGhlIHNvdXJjZSBhc1wKICAgcG9zc2libGUuXApcCiAgIFNlY3Vy aXR5IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDYgc2hh bGwgYmVcCiAgIHRha2VuIGludG8gYWNjb3VudC5cClwKICAgTm90ZTogVGhlIEhpc3RvcnkgY2xh c3MgaGFzIGJlZW4gZXhwYW5kZWQgaW4gSU9ERUYgdG8gYWNjb21tb2RhdGUgYWxsXAogICBvZiB0 aGUgcG9zc2libGUgYWN0aW9ucyB0YWtlbiBhcyBhIHJlc3VsdCBvZiBhIFJJRCBUcmFjZVJlcXVl c3Qgb3JcCiAgIEludmVzdGlnYXRpb24gcmVxdWVzdCB1c2luZyB0aGUgImlvZGVmOmF0eXBlIiwg b3IgYWN0aW9uIHR5cGUsXAogICBhdHRyaWJ1dGUuICBUaGUgSGlzdG9yeSBjbGFzcyBzaG91bGQg YmUgdXNlZCB0byBub3RlIGFsbCBhY3Rpb25zXAogICB0YWtlbiBjbG9zZSB0byB0aGUgc291cmNl IG9mIGEgdHJhY2Ugb3IgaW5jaWRlbnQgdXNpbmcgdGhlIG1vc3RcCiAgIGFwcHJvcHJpYXRlIG9w dGlvbiBmb3IgdGhlIHR5cGUgb2YgYWN0aW9uIGFsb25nIHdpdGggYSBkZXNjcmlwdGlvbi5cCiAg IFRoZSAiYXR5cGUiIGF0dHJpYnV0ZSBpbiB0aGUgRXhwZWN0YXRpb24gY2xhc3MgY2FuIGFsc28g YmUgdXNlZCB0b1wKICAgcmVxdWVzdCBhbiBhcHByb3ByaWF0ZSBhY3Rpb24gd2hlbiBhIFRyYWNl UmVxdWVzdCBvciBJbnZlc3RpZ2F0aW9uXAogICByZXF1ZXN0IGlzIG1hZGUuXApcCjQuNC4gIElu dmVzdGlnYXRpb24gUmVxdWVzdFwKXAogICBEZXNjcmlwdGlvbjogVGhpcyBtZXNzYWdlIHR5cGUg aXMgdXNlZCB3aGVuIHRoZSBzb3VyY2Ugb2YgdGhlIHRyYWZmaWNcCiAgIGlzIGJlbGlldmVkIG5v dCB0byBiZSBzcG9vZmVkLiAgVGhlIHB1cnBvc2Ugb2YgdGhlIEludmVzdGlnYXRpb25cCiAgIHJl cXVlc3QgbWVzc2FnZSBpcyB0byBsZXZlcmFnZSB0aGUgZXhpc3RpbmcgYmlsYXRlcmFsIHBlZXJc CiAgIHJlbGF0aW9uc2hpcHMgaW4gb3JkZXIgdG8gbm90aWZ5IHRoZSBuZXR3b3JrIHByb3ZpZGVy IGNsb3Nlc3QgdG8gdGhlXAogICBzb3VyY2Ugb2YgdGhlIHZhbGlkIHRyYWZmaWMgdGhhdCBzb21l IGV2ZW50IG9jY3VycmVkLCB3aGljaCBtYXkgYmUgYVwKICAgc2VjdXJpdHktcmVsYXRlZCBpbmNp ZGVudC5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAs IDIwMTIgICAgICAgICAgICAgIFtQYWdlIDI2XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBU aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGlzIHJlcXVpcmVkIGZvciBJbnZlc3RpZ2F0aW9uIHJl cXVlc3RcCiAgIG1lc3NhZ2VzIGFuZCBpcyBwcm92aWRlZCB0aHJvdWdoOlwKXAogICAgICBSSUQg SW5mb3JtYXRpb246XApcCiAgICAgICAgIFJJRCBQb2xpY3lcClwKICAgICAgICAgICAgUklEIG1l c3NhZ2UgdHlwZSwgSW5jaWRlbnRJRCwgYW5kIGRlc3RpbmF0aW9uIHBvbGljeVwKICAgICAgICAg ICAgaW5mb3JtYXRpb25cClwKICAgICAgSU9ERUYgSW5mb3JtYXRpb246XApcCiAgICAgICAgIFRp bWUgU3RhbXBzIChEZXRlY3RUaW1lLCBTdGFydFRpbWUsIEVuZFRpbWUsIFJlcG9ydFRpbWUpLlwK XAogICAgICAgICBJbmNpZGVudCBJZGVudGlmaWVyIChJbmNpZGVudCBjbGFzcywgSW5jaWRlbnRJ RCkuXApcCiAgICAgICAgICAgIFRyYWNlIG51bWJlciAtIHVzZWQgZm9yIG11bHRpcGxlIHRyYWNl cyBvZiBhIHNpbmdsZVwKICAgICAgICAgICAgaW5jaWRlbnQ7IG11c3QgYmUgbm90ZWQuXApcCiAg ICAgICAgIENvbmZpZGVuY2UgcmF0aW5nIG9mIHNlY3VyaXR5IGluY2lkZW50IChJbXBhY3QgYW5k IENvbmZpZGVuY2VcCiAgICAgICAgIGNsYXNzKS5cClwKICAgICAgICAgU3lzdGVtIGNsYXNzIGlz IHVzZWQgdG8gbGlzdCBib3RoIHRoZSBTb3VyY2UgYW5kIERlc3RpbmF0aW9uXAogICAgICAgICBJ bmZvcm1hdGlvbiB1c2VkIGluIHRoZSBhdHRhY2sgYW5kIG11c3Qgbm90ZSBpZiB0aGUgdHJhZmZp YyBpc1wKICAgICAgICAgc3Bvb2ZlZCwgdGh1cyByZXF1aXJpbmcgYW4gdXBzdHJlYW0gVHJhY2VS ZXF1ZXN0IGluIFJJRC5cClwKICAgICAgICAgRXhwZWN0YXRpb24gY2xhc3Mgc2hvdWxkIGJlIHVz ZWQgdG8gcmVxdWVzdCBhbnkgc3BlY2lmaWNcCiAgICAgICAgIGFjdGlvbnMgdG8gYmUgdGFrZW4g Y2xvc2UgdG8gdGhlIHNvdXJjZS5cClwKICAgICAgICAgUGF0aCBpbmZvcm1hdGlvbiBvZiBuZXN0 ZWQgc3lzdGVtcyBjb21tdW5pY2F0aW5nIHZpYSBSSURcCiAgICAgICAgIG1lc3NhZ2VzLCBiZWdp bm5pbmcgd2l0aCB0aGUgcmVxdWVzdCBvcmlnaW5hdG9yIHVzZWQgaW4gdGhlXAogICAgICAgICB0 cmFjZSB1c2luZyBJT0RFRiBFdmVudERhdGEgd2l0aCBjYXRlZ29yeSBzZXQgdG9cCiAgICAgICAg ICJpbmZyYXN0cnVjdHVyZSIuXApcCiAgICAgICAgIEV2ZW50LCBSZWNvcmQsIGFuZCBSZWNvcmRJ dGVtIGNsYXNzZXMgdG8gaW5jbHVkZSBleGFtcGxlXAogICAgICAgICBwYWNrZXRzIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBpbmNpZGVudC4gIE5vdGU6XAogICAgICAgICBF dmVudCBpbmZvcm1hdGlvbiBpbmNsdWRlZCBoZXJlIHJlcXVpcmVzIGEgc2Vjb25kIGluc3RhbmNl IG9mXAogICAgICAgICBFdmVudERhdGEgaW4gYWRkaXRpb24gdG8gdGhhdCB1c2VkIHRvIGNvbnZl eSBTUCBwYXRoIGNvbnRhY3RcCiAgICAgICAgIGluZm9ybWF0aW9uLlwKXAogICAgICBTdGFuZGFy ZHMgZm9yIGVuY3J5cHRpb24gYW5kIGRpZ2l0YWwgc2lnbmF0dXJlcyBbUkZDMzI3NV06XApcCiAg ICAgICAgIERpZ2l0YWwgc2lnbmF0dXJlIGZyb20gaW5pdGlhdGluZyBzeXN0ZW0gc2VuZGluZyB0 aGUgUklEXAogICAgICAgICBtZXNzYWdlLCBwYXNzZWQgdG8gYWxsIHN5c3RlbXMgaW4gdXBzdHJl YW0gdHJhY2UgdXNpbmcgWE1MXAogICAgICAgICBkaWdpdGFsIHNpZ25hdHVyZS5cClwKICAgU2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQgaW5jbHVkZSB0aGUgYWJpbGl0eSB0byBlbmNyeXB0 XAogICBbWE1MZW5jcnlwdF0gdGhlIGNvbnRlbnRzIG9mIHRoZSBJbnZlc3RpZ2F0aW9uIHJlcXVl c3QgbWVzc2FnZSB1c2luZ1wKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjddXApcCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAx MVwKXApcCiAgIHRoZSBwdWJsaWMga2V5IG9mIHRoZSBkZXN0aW5hdGlvbiBSSUQgc3lzdGVtLiAg VGhlIGluY2lkZW50IG51bWJlclwKICAgd291bGQgaW5jcmVhc2UgYXMgaWYgaXQgd2VyZSBhIFRy YWNlUmVxdWVzdCBtZXNzYWdlIGluIG9yZGVyIHRvXAogICBlbnN1cmUgdW5pcXVlbmVzcyB3aXRo aW4gdGhlIHN5c3RlbS4gIFRoZSByZWxheWluZyBwZWVycyB3b3VsZCBhbHNvXAogICBhcHBlbmQg dGhlaXIgQXV0b25vbW91cyBTeXN0ZW0gKEFTKSBvciBSSUQgc3lzdGVtIGluZm9ybWF0aW9uIGFz IHRoZVwKICAgcmVxdWVzdCBtZXNzYWdlIHdhcyByZWxheWVkIGFsb25nIHRoZSB3ZWIgb2YgbmV0 d29yayBwcm92aWRlcnMgc29cCiAgIHRoYXQgdGhlIFJlc3VsdCBtZXNzYWdlIGNvdWxkIHV0aWxp emUgdGhlIHNhbWUgcGF0aCBhcyB0aGUgc2V0IG9mXAogICB0cnVzdCByZWxhdGlvbnNoaXBzIGZv ciB0aGUgcmV0dXJuIG1lc3NhZ2UsIHRodXMgaW5kaWNhdGluZyBhbnlcCiAgIGFjdGlvbnMgdGFr ZW4uICBUaGUgcmVxdWVzdCB3b3VsZCBhbHNvIGJlIHJlY29yZGVkIGluIHRoZSBzdGF0ZVwKICAg dGFibGVzIG9mIGJvdGggdGhlIGluaXRpYXRpbmcgYW5kIGRlc3RpbmF0aW9uIFNQIFJJRCBzeXN0 ZW1zLiAgVGhlXAogICBkZXN0aW5hdGlvbiBTUCBpcyByZXNwb25zaWJsZSBmb3IgYW55IGFjdGlv bnMgdGFrZW4gYXMgYSByZXN1bHQgb2ZcCiAgIHRoZSByZXF1ZXN0IGluIGFkaGVyZW5jZSB0byBh bnkgc2VydmljZSBsZXZlbCBhZ3JlZW1lbnRzIG9yIGludGVybmFsXAogICBwb2xpY2llcy4gIFRo ZSBTUCBzaG91bGQgY29uZmlybSB0aGF0IHRoZSB0cmFmZmljIGFjdHVhbGx5IG9yaWdpbmF0ZWRc CiAgIGZyb20gdGhlIHN1c3BlY3RlZCBzeXN0ZW0gYmVmb3JlIHRha2luZyBhbnkgYWN0aW9uIGFu ZCBjb25maXJtIHRoZVwKICAgcmVhc29uIGZvciB0aGUgcmVxdWVzdC4gIFRoZSByZXF1ZXN0IG1h eSBiZSBzZW50IGRpcmVjdGx5IHRvIGEga25vd25cCiAgIFJJRCBzeXN0ZW0gb3Igcm91dGVkIGJ5 IHRoZSBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgYXR0YWNrIHVzaW5nIHRoZVwKICAgbWVzc2FnZSBk ZXN0aW5hdGlvbiBvZiBSSURQb2xpY3ksIFNvdXJjZU9mSW5jaWRlbnQuICBOb3RlOiBBbGxcCiAg IGludGVybWVkaWF0ZSBwYXJ0aWVzIG11c3QgYmUgYWJsZSB0byB2aWV3IFJJRFBvbGljeSBpbmZv cm1hdGlvbiBpblwKICAgb3JkZXIgdG8gcHJvcGVybHkgZGlyZWN0IFJJRCBtZXNzYWdlcy5cClwK NC41LiAgUmVwb3J0XApcCiAgIERlc2NyaXB0aW9uOiBUaGlzIG1lc3NhZ2Ugb3IgZG9jdW1lbnQg aXMgc2VudCB0byBhIFJJRCBzeXN0ZW0gdG9cCiAgIHByb3ZpZGUgYSByZXBvcnQgb2YgYSBzZWN1 cml0eSBpbmNpZGVudC4gIFRoaXMgbWVzc2FnZSBkb2VzIG5vdFwKICAgcmVxdWlyZSBhbnkgYWN0 aW9ucyB0byBiZSB0YWtlbiwgZXhjZXB0IHRvIGZpbGUgdGhlIHJlcG9ydCBvbiB0aGVcCiAgIHJl Y2VpdmluZyBSSUQgc3lzdGVtIG9yIGFzc29jaWF0ZWQgZGF0YWJhc2UuXApcCiAgIFRoZSBmb2xs b3dpbmcgaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQgZm9yIFJlcG9ydCBtZXNzYWdlcyBhbmQgd2ls bCBiZVwKICAgcHJvdmlkZWQgdGhyb3VnaDpcClwKICAgICAgUklEIEluZm9ybWF0aW9uOlwKXAog ICAgICAgICBSSUQgUG9saWN5IFJJRCBtZXNzYWdlIHR5cGUsIEluY2lkZW50SUQsIGFuZCBkZXN0 aW5hdGlvbiBwb2xpY3lcCiAgICAgICAgIGluZm9ybWF0aW9uXApcCiAgICAgIFRoZSBmb2xsb3dp bmcgZGF0YSBpcyByZWNvbW1lbmRlZCBpZiBhdmFpbGFibGUgYW5kIGNhbiBiZSBwcm92aWRlZFwK ICAgICAgdGhyb3VnaDpcClwKICAgICAgSU9ERUYgSW5mb3JtYXRpb246XApcCiAgICAgICAgIFRp bWUgU3RhbXBzIChEZXRlY3RUaW1lLCBTdGFydFRpbWUsIEVuZFRpbWUsIFJlcG9ydFRpbWUpLlwK XAogICAgICAgICBJbmNpZGVudCBJZGVudGlmaWVyIChJbmNpZGVudCBjbGFzcywgSW5jaWRlbnRJ RCkuICBUcmFjZSBudW1iZXJcCiAgICAgICAgIC0gdXNlZCBmb3IgbXVsdGlwbGUgdHJhY2VzIG9m IGEgc2luZ2xlIGluY2lkZW50OyBtdXN0IGJlIG5vdGVkLlwKXAogICAgICAgICBDb25maWRlbmNl IHJhdGluZyBvZiBzZWN1cml0eSBpbmNpZGVudCAoSW1wYWN0IGFuZCBDb25maWRlbmNlXAogICAg ICAgICBjbGFzcykuXApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjhdXApcCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAx MVwKXApcCiAgICAgICAgIFN5c3RlbSBjbGFzcyBpcyB1c2VkIHRvIGxpc3QgYm90aCB0aGUgU291 cmNlIGFuZCBEZXN0aW5hdGlvblwKICAgICAgICAgSW5mb3JtYXRpb24gdXNlZCBpbiB0aGUgYXR0 YWNrLlwKXAogICAgICAgICBFdmVudCwgUmVjb3JkLCBhbmQgUmVjb3JkSXRlbSBjbGFzc2VzIHRv IGluY2x1ZGUgZXhhbXBsZVwKICAgICAgICAgcGFja2V0cyBhbmQgb3RoZXIgaW5mb3JtYXRpb24g cmVsYXRlZCB0byB0aGUgaW5jaWRlbnRcCiAgICAgICAgIChvcHRpb25hbCkuXApcCiAgICAgIFN0 YW5kYXJkcyBmb3IgZW5jcnlwdGlvbiBhbmQgZGlnaXRhbCBzaWduYXR1cmVzIFtSRkMzMjc1XTpc ClwKICAgICAgICAgRGlnaXRhbCBzaWduYXR1cmUgZnJvbSBpbml0aWF0aW5nIFJJRCBzeXN0ZW0s IHBhc3NlZCB0byBhbGxcCiAgICAgICAgIHN5c3RlbXMgcmVjZWl2aW5nIHRoZSByZXBvcnQgdXNp bmcgWE1MIGRpZ2l0YWwgc2lnbmF0dXJlLlwKXAogICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyB3 b3VsZCBpbmNsdWRlIHRoZSBhYmlsaXR5IHRvIGVuY3J5cHRcCiAgIFtYTUxlbmNyeXB0XSB0aGUg Y29udGVudHMgb2YgdGhlIFJlcG9ydCBtZXNzYWdlIHVzaW5nIHRoZSBwdWJsaWMga2V5XAogICBv ZiB0aGUgZGVzdGluYXRpb24gUklEIHN5c3RlbS4gIFNlbmRlcnMgb2YgYSBSZXBvcnQgbWVzc2Fn ZSBzaG91bGRcCiAgIG5vdGUgdGhhdCB0aGUgaW5mb3JtYXRpb24gbWF5IGJlIHVzZWQgdG8gY29y cmVsYXRlIHNlY3VyaXR5IGluY2lkZW50XAogICBpbmZvcm1hdGlvbiBmb3IgdGhlIHB1cnBvc2Ug b2YgdHJlbmRpbmcsIHBhdHRlcm4gZGV0ZWN0aW9uLCBldGMuLCBhbmRcCiAgIG1heSBiZSBzaGFy ZWQgd2l0aCBvdGhlciBwYXJ0aWVzIHVubGVzcyBvdGhlcndpc2UgYWdyZWVkIHVwb24gd2l0aFwK ICAgdGhlIHJlY2VpdmluZyBSSUQgc3lzdGVtLiAgVGhlcmVmb3JlLCBzZW5kaW5nIHBhcnRpZXMg b2YgYSBSZXBvcnRcCiAgIG1lc3NhZ2UgbWF5IG9iZnVzY2F0ZSBvciByZW1vdmUgZGVzdGluYXRp b24gYWRkcmVzc2VzIG9yIG90aGVyXAogICBzZW5zaXRpdmUgaW5mb3JtYXRpb24gYmVmb3JlIHNl bmRpbmcgYSBSZXBvcnQgbWVzc2FnZS4gIEEgUmVwb3J0XAogICBtZXNzYWdlIG1heSBiZSBzZW50 IGVpdGhlciB0byBmaWxlIGFuIGluY2lkZW50IHJlcG9ydCBvciBpbiByZXNwb25zZVwKICAgdG8g YW4gSW5jaWRlbnRRdWVyeSwgYW5kIGRhdGEgc2Vuc2l0aXZpdHkgbXVzdCBiZSBjb25zaWRlcmVk IGluIGJvdGhcCiAgIGNhc2VzLiAgVGhlIFNQIHBhdGggaW5mb3JtYXRpb24gaXMgbm90IG5lY2Vz c2FyeSBmb3IgdGhpcyBtZXNzYWdlLCBhc1wKICAgaXQgd2lsbCBiZSBjb21tdW5pY2F0ZWQgZGly ZWN0bHkgYmV0d2VlbiB0d28gdHJ1c3RlZCBSSUQgc3lzdGVtcy5cClwKNC42LiAgSW5jaWRlbnRR dWVyeVwKXAogICBEZXNjcmlwdGlvbjogVGhlIEluY2lkZW50UXVlcnkgbWVzc2FnZSBpcyB1c2Vk IHRvIHJlcXVlc3QgaW5jaWRlbnRcCiAgIGluZm9ybWF0aW9uIGZyb20gYSB0cnVzdGVkIFJJRCBz eXN0ZW0uICBUaGUgcmVxdWVzdCBjYW4gaW5jbHVkZSB0aGVcCiAgIGluY2lkZW50IG51bWJlciwg aWYga25vd24sIG9yIGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0IHRoZVwKICAgaW5jaWRlbnQu ICBJZiB0aGUgaW5jaWRlbnQgbnVtYmVyIGlzIGtub3duLCB0aGUgUmVwb3J0IG1lc3NhZ2VcCiAg IGNvbnRhaW5pbmcgdGhlIGluY2lkZW50IGluZm9ybWF0aW9uIGNhbiBlYXNpbHkgYmUgcmV0dXJu ZWQgdG8gdGhlXAogICB0cnVzdGVkIHJlcXVlc3RvciB1c2luZyBhdXRvbWF0ZWQgbWV0aG9kcy4g IElmIGFuIGV4YW1wbGUgcGFja2V0IG9yXAogICBvdGhlciB1bmlxdWUgaW5mb3JtYXRpb24gaXMg aW5jbHVkZWQgaW4gdGhlIEluY2lkZW50UXVlcnksIHRoZSByZXR1cm5cCiAgIHJlcG9ydCBtYXkg YmUgYXV0b21hdGVkOyBvdGhlcndpc2UsIGFuYWx5c3QgaW50ZXJ2ZW50aW9uIG1heSBiZVwKICAg cmVxdWlyZWQuXApcCiAgIFRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gbXVzdCBiZSB1c2VkIGZv ciBhbiBJbmNpZGVudFF1ZXJ5IG1lc3NhZ2VcCiAgIGFuZCBpcyBwcm92aWRlZCB0aHJvdWdoOlwK XAogICAgICBSSUQgSW5mb3JtYXRpb246XApcCiAgICAgICAgIFJJRCBQb2xpY3lcClwKICAgICAg ICAgICAgUklEIG1lc3NhZ2UgdHlwZSwgSW5jaWRlbnRJRCwgYW5kIGRlc3RpbmF0aW9uIHBvbGlj eVwKICAgICAgICAgICAgaW5mb3JtYXRpb25cClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjldXApcCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAg ICBBdWd1c3QgMjAxMVwKXApcCiAgICAgIElPREVGIEluZm9ybWF0aW9uIChvcHRpb25hbCk6XApc CiAgICAgICAgIFRpbWUgU3RhbXBzIChEZXRlY3RUaW1lLCBTdGFydFRpbWUsIEVuZFRpbWUsIFJl cG9ydFRpbWUpLlwKXAogICAgICAgICBJbmNpZGVudCBJZGVudGlmaWVyIChJbmNpZGVudCBjbGFz cywgSW5jaWRlbnRJRCkuXApcCiAgICAgICAgICAgIFRyYWNlIG51bWJlciAtIHVzZWQgZm9yIG11 bHRpcGxlIHRyYWNlcyBvZiBhIHNpbmdsZVwKICAgICAgICAgICAgaW5jaWRlbnQ7IG11c3QgYmUg bm90ZWQuXApcCiAgICAgICAgIENvbmZpZGVuY2UgcmF0aW5nIG9mIHNlY3VyaXR5IGluY2lkZW50 IChJbXBhY3QgYW5kIENvbmZpZGVuY2VcCiAgICAgICAgIGNsYXNzKS5cClwKICAgICAgICAgU3lz dGVtIGNsYXNzIGlzIHVzZWQgdG8gbGlzdCBib3RoIHRoZSBTb3VyY2UgYW5kIERlc3RpbmF0aW9u XAogICAgICAgICBJbmZvcm1hdGlvbiB1c2VkIGluIHRoZSBhdHRhY2suXApcCiAgICAgICAgIEV2 ZW50LCBSZWNvcmQsIGFuZCBSZWNvcmRJdGVtIGNsYXNzZXMgdG8gaW5jbHVkZSBleGFtcGxlXAog ICAgICAgICBwYWNrZXRzIGFuZCBvdGhlciBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBpbmNp ZGVudFwKICAgICAgICAgKG9wdGlvbmFsKS5cClwKICAgICAgU3RhbmRhcmRzIGZvciBlbmNyeXB0 aW9uIGFuZCBkaWdpdGFsIHNpZ25hdHVyZXMgW1JGQzMyNzVdOlwKXAogICAgICAgICBEaWdpdGFs IHNpZ25hdHVyZSBmcm9tIGluaXRpYXRpbmcgUklEIHN5c3RlbSwgcGFzc2VkIHRvIGFsbFwKICAg ICAgICAgc3lzdGVtcyByZWNlaXZpbmcgdGhlIEluY2lkZW50UXVlcnkgdXNpbmcgWE1MIGRpZ2l0 YWxcCiAgICAgICAgIHNpZ25hdHVyZS4gIElmIGEgcGFja2V0IGlzIG5vdCBpbmNsdWRlZCwgdGhl IHNpZ25hdHVyZSBtYXkgYmVcCiAgICAgICAgIGJhc2VkIG9uIHRoZSBSSURQb2xpY3kgY2xhc3Mu XApcCiAgIFRoZSBwcm9wZXIgcmVzcG9uc2UgdG8gdGhlIEluY2lkZW50UXVlcnkgbWVzc2FnZSBp cyBhIFJlcG9ydCBtZXNzYWdlLlwKICAgTXVsdGlwbGUgaW5jaWRlbnRzIG1heSBiZSByZXR1cm5l ZCBmb3IgYSBzaW5nbGUgcXVlcnkgaWYgYW4gaW5jaWRlbnRcCiAgIHR5cGUgaXMgcmVxdWVzdGVk LiAgSW4gdGhpcyBjYXNlLCB0aGUgcmVjZWl2aW5nIHN5c3RlbSB3b3VsZCBzZW5kIGFuXAogICBJ T0RFRiBkb2N1bWVudCBjb250YWluaW5nIG11bHRpcGxlIGluY2lkZW50cyBvciBhbGwgaW5zdGFu Y2VzIG9mIGFuXAogICBpbmNpZGVudC4gIFRoZSBzeXN0ZW0gc2VuZGluZyB0aGUgcmVwbHkgbWF5 IHByZS1zZXQgYSBsaW1pdCB0byB0aGVcCiAgIG51bWJlciBvZiBkb2N1bWVudHMgcmV0dXJuZWQg aW4gb25lIHJlcG9ydC4gIFRoZSByZWNvbW1lbmRlZCBsaW1pdCBpc1wKICAgNSwgdG8gcHJldmVu dCB0aGUgZG9jdW1lbnRzIGZyb20gYmVjb21pbmcgdG9vIGxhcmdlLiAgT3RoZXIgdHJhbnNmZXJc CiAgIG1ldGhvZHMgbWF5IGJlIHN1aXRlZCBiZXR0ZXIgdGhhbiBSSUQgZm9yIGxhcmdlIHRyYW5z ZmVycyBvZiBkYXRhLlwKICAgVGhlIENvbmZpZGVuY2UgcmF0aW5nIG1heSBiZSB1c2VkIGluIHRo ZSBJbmNpZGVudFF1ZXJ5IG1lc3NhZ2UgdG9cCiAgIHNlbGVjdCBvbmx5IGluY2lkZW50cyB3aXRo IGFuIGVxdWFsIG9yIGhpZ2hlciBDb25maWRlbmNlIHJhdGluZyB0aGFuXAogICB3aGF0IGlzIHNw ZWNpZmllZC4gIFRoaXMgbWF5IGJlIHVzZWQgZm9yIGNhc2VzIHdoZW4gaW5mb3JtYXRpb24gaXNc CiAgIGdhdGhlcmVkIG9uIGEgdHlwZSBvZiBpbmNpZGVudCBidXQgbm90IG9uIHNwZWNpZmljcyBh Ym91dCBhIHNpbmdsZVwKICAgaW5jaWRlbnQuICBTb3VyY2UgYW5kIERlc3RpbmF0aW9uIEluZm9y bWF0aW9uIG1heSBub3QgYmUgbmVlZGVkIGlmXAogICB0aGUgSW5jaWRlbnRRdWVyeSBpcyBpbnRl bmRlZCB0byBnYXRoZXIgZGF0YSBhYm91dCBhIHNwZWNpZmljIHR5cGUgb2ZcCiAgIGluY2lkZW50 IGFzIHdlbGwuXApcClwKNS4gIFJJRCBDb21tdW5pY2F0aW9uIEV4Y2hhbmdlc1wKXAogICBUaGUg Zm9sbG93aW5nIHNlY3Rpb24gb3V0bGluZXMgdGhlIGNvbW11bmljYXRpb24gZmxvd3MgZm9yIFJJ RCBhbmRcCiAgIGFsc28gcHJvdmlkZXMgZXhhbXBsZXMgb2YgbWVzc2FnZXMuXApcClwKXApcCk1v cmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAg ICAgIFtQYWdlIDMwXVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1i aXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBOb3RlOiBGb3IgZWFjaCBl eGFtcGxlIGxpc3RlZCBiZWxvdywgW1JGQzU3MzVdIGFkZHJlc3NlcyB3ZXJlIHVzZWQuXAogICBB c3N1bWUgdGhhdCBlYWNoIElQIGFkZHJlc3MgbGlzdGVkIGlzIGFjdHVhbGx5IGEgc2VwYXJhdGUg bmV0d29ya1wKICAgcmFuZ2UgaGVsZCBieSBkaWZmZXJlbnQgU1BzLiAgQWRkcmVzc2VzIHdlcmUg dXNlZCBmcm9tIC8yNyBuZXR3b3JrXAogICByYW5nZXMuXApcCjUuMS4gIFVwc3RyZWFtIFRyYWNl IENvbW11bmljYXRpb24gRmxvd1wKXAogICBUaGUgZGlhZ3JhbSBiZWxvdyBvdXRsaW5lcyB0aGUg UklEIFRyYWNlUmVxdWVzdCBjb21tdW5pY2F0aW9uIGZsb3dcCiAgIGJldHdlZW4gUklEIHN5c3Rl bXMgb24gZGlmZmVyZW50IG5ldHdvcmtzIHRyYWNpbmcgYW4gYXR0YWNrLlwKXAogICAgQXR0YWNr IERlc3QgICAgICBTUC0xICAgICAgICAgICAgU1AtMiAgICAgICAgU1AtMyAgICAgICAgQXR0YWNr IFNyY1wKXAogICAgMS4gQXR0YWNrICAgIHwgIEF0dGFja1wKICAgICAgIHJlcG9ydGVkICB8ICBk ZXRlY3RlZFwKXAogICAgMi4gICAgICAgICAgICAgIEluaXRpYXRlIHRyYWNlXApcCiAgICAzLiAg ICAgICAgICAgICAgTG9jYXRlIG9yaWdpblwKICAgICAgICAgICAgICAgICAgICB0aHJvdWdoXAog ICAgICAgICAgICAgICAgICAgIHVwc3RyZWFtIFNQXApcCiAgICA0LiAgICAgICAgICAgICAgby0t LVRyYWNlUmVxdWVzdC0tLS0tJmd0O1wKXAogICAgNS4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUcmFjZVwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5pdGlhdGVk XApcCiAgICA2LiAgICAgICAgICAgICAgJmx0Oy1SZXF1ZXN0QXV0aG9yaXphdGlvbi1vXApcCiAg ICA3LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExvY2F0ZSBvcmlnaW5cCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRocm91Z2hcCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHVwc3RyZWFtIFNQXApcCiAgICA4LiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG8tLS1UcmFjZVJlcXVlc3QtLS0mZ3Q7XApcCiAgICA5LiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRyYWNlIEluaXRpYXRlZFwKXAogICAgMTAu ICAgICAgICAgICAgICZsdDstLS0tLS0tLS0tUmVxdWVzdEF1dGhvcml6YXRpb24tLS0tb1wKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDstLS1SZXF1ZXN0QXV0aC0tLW9c ClwKICAgIDExLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTG9j YXRlIGF0dGFja1wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc291cmNlIG9uIG5ldHdvcmsgICBYXApcCiAgICAxMi4gICAgICAgICAgICAgJmx0Oy0t LS0tLS0tLS0tLVJlc3VsdC0tLS0tLS0tLS0tLS0tLS1vXApcCiAgICAgICAgICAgICAgICAgRmln dXJlIDc6IFRyYWNlUmVxdWVzdCBDb21tdW5pY2F0aW9uIEZsb3dcClwKICAgQmVmb3JlIGEgdHJh Y2UgaXMgaW5pdGlhdGVkLCB0aGUgUklEIHN5c3RlbSBzaG91bGQgdmVyaWZ5IGlmIGFuXAogICBp bnN0YW5jZSBvZiB0aGUgdHJhY2Ugb3IgYSBzaW1pbGFyIHJlcXVlc3QgaXMgbm90IGFjdGl2ZS4g IFRoZSB0cmFjZXNcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDMxXVwKXApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwK XAogICBtYXkgYmUgcmVzb3VyY2UgaW50ZW5zaXZlOyB0aGVyZWZvcmUsIHByb3ZpZGVycyBuZWVk IHRvIGJlIGFibGUgdG9cCiAgIGRldGVjdCBwb3RlbnRpYWwgYWJ1c2Ugb2YgdGhlIHN5c3RlbSBv ciB1bmludGVudGlvbmFsIHJlc291cmNlXAogICBkcmFpbnMuICBJbmZvcm1hdGlvbiBzdWNoIGFz IHRoZSBTb3VyY2UgYW5kIERlc3RpbmF0aW9uIEluZm9ybWF0aW9uLFwKICAgYXNzb2NpYXRlZCBw YWNrZXRzLCBhbmQgdGhlIGluY2lkZW50IG1heSBiZSBkZXNpcmFibGUgdG8gbWFpbnRhaW4gZm9y XAogICBhIHBlcmlvZCBvZiB0aW1lIGRldGVybWluZWQgYnkgYWRtaW5pc3RyYXRvcnMuXApcCiAg IFRoZSBjb21tdW5pY2F0aW9uIGZsb3cgZGVtb25zdHJhdGVzIHRoYXQgYSBSZXF1ZXN0QXV0aG9y aXphdGlvblwKICAgbWVzc2FnZSBpcyBzZW50IHRvIGJvdGggdGhlIGRvd25zdHJlYW0gcGVlciBh bmQgdGhlIG9yaWdpbmFsXAogICByZXF1ZXN0b3IuICBJZiBhIFRyYWNlUmVxdWVzdCBpcyBkZW5p ZWQsIHRoZSBkb3duc3RyZWFtIHBlZXIgaGFzIHRoZVwKICAgb3B0aW9uIHRvIHRha2UgYW4gYWN0 aW9uIGFuZCByZXNwb25kIHdpdGggYSBSZXN1bHQgbWVzc2FnZS4gIFRoZVwKICAgb3JpZ2luYXRv ciBvZiB0aGUgcmVxdWVzdCBtYXkgZm9sbG93IHVwIHdpdGggdGhlIGRvd25zdHJlYW0gcGVlciBv ZlwKICAgdGhlIFNQIGludm9sdmVkIHVzaW5nIGFuIEludmVzdGlnYXRpb24gcmVxdWVzdCB0byBl bnN1cmUgdGhhdCBhblwKICAgYWN0aW9uIGlzIHRha2VuIGlmIG5vIHJlc3BvbnNlIGlzIHJlY2Vp dmVkLiAgTm90aGluZyBwcmVjbHVkZXMgdGhlXAogICBvcmlnaW5hdG9yIG9mIHRoZSByZXF1ZXN0 IGZyb20gaW5pdGlhdGluZyBhIG5ldyBUcmFjZVJlcXVlc3RcCiAgIGJ5cGFzc2luZyB0aGUgU1Ag dGhhdCBkZW5pZWQgdGhlIHJlcXVlc3QsIGlmIGEgdHJhY2UgaXMgbmVlZGVkIGJleW9uZFwKICAg dGhhdCBwb2ludC4gIEFub3RoZXIgb3B0aW9uIG1heSBiZSBmb3IgdGhlIGluaXRpYXRvciB0byBz ZW5kIGFuXAogICBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgdG8gYW4gU1AgdXBzdHJlYW0gb2YgdGhl IFNQIHRoYXQgZGVuaWVkIHRoZVwKICAgcmVxdWVzdCBpZiBlbm91Z2ggaW5mb3JtYXRpb24gd2Fz IGdhdGhlcmVkIHRvIGRpc2Nlcm4gdGhlIHRydWUgc291cmNlXAogICBvZiB0aGUgYXR0YWNrIHRy YWZmaWMgZnJvbSB0aGUgaW5jaWRlbnQgaGFuZGxpbmcgaW5mb3JtYXRpb24uXApcCjUuMS4xLiAg UklEIFRyYWNlUmVxdWVzdCBFeGFtcGxlXApcCiAgIFRoZSBleGFtcGxlIGxpc3RlZCBpcyBvZiBh IFRyYWNlUmVxdWVzdCBiYXNlZCBvbiB0aGUgaW5jaWRlbnQgcmVwb3J0XAogICBleGFtcGxlIGZy b20gdGhlIElPREVGIGRvY3VtZW50LiAgVGhlIFJJRCBleHRlbnNpb24gY2xhc3NlcyB3ZXJlXAog ICBpbmNsdWRlZCBhcyBhcHByb3ByaWF0ZSBmb3IgYSBUcmFjZVJlcXVlc3QgbWVzc2FnZSB1c2lu ZyB0aGVcCiAgIFJJRFBvbGljeSBjbGFzcy4gIFRoZSBleGFtcGxlIGdpdmVuIGlzIHRoYXQgb2Yg YSBDU0lSVCByZXBvcnRpbmcgYVwKICAgRG9TIGF0dGFjayBpbiBwcm9ncmVzcyB0byB0aGUgdXBz dHJlYW0gU1AuICBUaGUgcmVxdWVzdCBhc2tzIHRoZSBuZXh0XAogICBTUCB0byBjb250aW51ZSB0 aGUgdHJhY2UgYW5kIGhhdmUgdGhlIHRyYWZmaWMgbWl0aWdhdGVkIGNsb3NlciB0byB0aGVcCiAg IHNvdXJjZSBvZiB0aGUgdHJhZmZpYy5cClwKICAgSW4gdGhlIGZvbGxvd2luZyBleGFtcGxlLCB1 c2Ugb2YgW1hNTHNpZ10gdG8gZ2VuZXJhdGUgZGlnaXRhbFwKICAgc2lnbmF0dXJlcyBkb2VzIG5v dCBjdXJyZW50bHkgcHJvdmlkZSBkaWdlc3QgYWxnb3JpdGhtIGFnaWxpdHksIGFzXAogICBbWE1M c2lnXSBvbmx5IHN1cHBvcnRzIFNIQS0xLiAgQSBmdXR1cmUgdmVyc2lvbiBvZiBbWE1Mc2lnXSBt YXlcCiAgIHN1cHBvcnQgYWRkaXRpb25hbCBkaWdlc3QgYWxnb3JpdGhtcyB0byBzdXBwb3J0IGRp Z2VzdCBhbGdvcml0aG1cCiAgIGFnaWxpdHkuXApcCiAgJmx0O2lvZGVmLXJpZDpSSUQgeG1sbnM6 aW9kZWYtcmlkPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0xLjAiXAogICAgICAg ICAgICAgICAgIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCIm Z3Q7XAogICAgJmx0O2lvZGVmLXJpZDpSSURQb2xpY3kgTXNnVHlwZT0iVHJhY2VSZXF1ZXN0IlwK ICAgICAgICAgICAgICAgICAgICAgICAgIE1zZ0Rlc3RpbmF0aW9uPSJSSURTeXN0ZW0iJmd0O1wK ICAgICAgJmx0O2lvZGVmLXJpZDpQb2xpY3lSZWdpb24gcmVnaW9uPSJJbnRyYUNvbnNvcnRpdW0i LyZndDtcCiAgICAgICZsdDtpb2RlZjpOb2RlJmd0O1wKICAgICAgICAmbHQ7aW9kZWY6QWRkcmVz cyBjYXRlZ29yeT0iaXB2NC1hZGRyIiZndDsxOTIuMC4yLjMmbHQ7L2lvZGVmOkFkZHJlc3MmZ3Q7 XAogICAgICAmbHQ7L2lvZGVmOk5vZGUmZ3Q7XAogICAgICAmbHQ7aW9kZWYtcmlkOlRyYWZmaWNU eXBlIHR5cGU9IkF0dGFjayIvJmd0O1wKICAgICAgJmx0O2lvZGVmOkluY2lkZW50SUQgbmFtZT0i Q0VSVC1GT1ItT1VSLURPTUFJTiImZ3Q7XAogICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjA3 LTFcCiAgICAgICZsdDsvaW9kZWY6SW5jaWRlbnRJRCZndDtcClwKXApcCk1vcmlhcnR5ICAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDMy XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAg ICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgJmx0Oy9pb2RlZi1yaWQ6UklEUG9saWN5Jmd0 O1wKICAmbHQ7L2lvZGVmLXJpZDpSSUQmZ3Q7XApcClwKICAmbHQ7IS0tIElPREVGLURvY3VtZW50 IGFjY29tcGFuaWVkIGJ5IHRoZSBhYm92ZSBSSUQgLS0mZ3Q7XApcCiAgJmx0O2lvZGVmOklPREVG LURvY3VtZW50IHZlcnNpb249IjEuMDAiXAogICAgICAgICAgICAgICAgICAgICAgICB4bWxuczpp b2RlZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiJmd0O1wKICAgICZsdDtpb2Rl ZjpJbmNpZGVudCByZXN0cmljdGlvbj0ibmVlZC10by1rbm93IiBwdXJwb3NlPSJ0cmFjZWJhY2si Jmd0O1wKICAgICAgJmx0O2lvZGVmOkluY2lkZW50SUQgbmFtZT0iQ0VSVC1GT1ItT1VSLURPTUFJ TiImZ3Q7XAogICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjA3LTFcCiAgICAgICZsdDsvaW9k ZWY6SW5jaWRlbnRJRCZndDtcCiAgICAgICZsdDtpb2RlZjpEZXRlY3RUaW1lJmd0OzIwMDQtMDIt MDJUMjI6NDk6MjQrMDA6MDAmbHQ7L2lvZGVmOkRldGVjdFRpbWUmZ3Q7XAogICAgICAmbHQ7aW9k ZWY6U3RhcnRUaW1lJmd0OzIwMDQtMDItMDJUMjI6MTk6MjQrMDA6MDAmbHQ7L2lvZGVmOlN0YXJ0 VGltZSZndDtcCiAgICAgICZsdDtpb2RlZjpSZXBvcnRUaW1lJmd0OzIwMDQtMDItMDJUMjM6MjA6 MjQrMDA6MDAmbHQ7L2lvZGVmOlJlcG9ydFRpbWUmZ3Q7XAogICAgICAmbHQ7aW9kZWY6RGVzY3Jp cHRpb24mZ3Q7SG9zdCBpbnZvbHZlZCBpbiBEb1MgYXR0YWNrJmx0Oy9pb2RlZjpEZXNjcmlwdGlv biZndDtcCiAgICAgICZsdDtpb2RlZjpBc3Nlc3NtZW50Jmd0O1wKICAgICAgICAmbHQ7aW9kZWY6 SW1wYWN0IHNldmVyaXR5PSJsb3ciIGNvbXBsZXRpb249ImZhaWxlZCIgdHlwZT0iZG9zIi8mZ3Q7 XAogICAgICAmbHQ7L2lvZGVmOkFzc2Vzc21lbnQmZ3Q7XAogICAgICAmbHQ7aW9kZWY6Q29udGFj dCByb2xlPSJjcmVhdG9yIiB0eXBlPSJvcmdhbml6YXRpb24iJmd0O1wKICAgICAgICAmbHQ7aW9k ZWY6Q29udGFjdE5hbWUmZ3Q7Q29uc3RpdHVlbmN5LWNvbnRhY3QgZm9yIDE5Mi4wLjIuMzVcCiAg ICAgICAgJmx0Oy9pb2RlZjpDb250YWN0TmFtZSZndDtcCiAgICAgICAgJmx0O2lvZGVmOkVtYWls Jmd0O0NvbnN0aXR1ZW5jeS1jb250YWN0QDE5Mi4wLjIuMzUmbHQ7L2lvZGVmOkVtYWlsJmd0O1wK ICAgICAgJmx0Oy9pb2RlZjpDb250YWN0Jmd0O1wKICAgICAgJmx0O2lvZGVmOkV2ZW50RGF0YSZn dDtcCiAgICAgICAgJmx0O2lvZGVmOkZsb3cmZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOlN5c3Rl bSBjYXRlZ29yeT0ic291cmNlIiZndDtcCiAgICAgICAgICAgICZsdDtpb2RlZjpOb2RlJmd0O1wK ICAgICAgICAgICAgICAmbHQ7aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1hZGRyIiZndDsx OTIuMC4yLjM1XAogICAgICAgICAgICAgICZsdDsvaW9kZWY6QWRkcmVzcyZndDtcCiAgICAgICAg ICAgICZsdDsvaW9kZWY6Tm9kZSZndDtcCiAgICAgICAgICAgICZsdDtpb2RlZjpTZXJ2aWNlJmd0 O1wKICAgICAgICAgICAgICAmbHQ7aW9kZWY6cG9ydCZndDszODc2NSZsdDsvaW9kZWY6cG9ydCZn dDtcCiAgICAgICAgICAgICZsdDsvaW9kZWY6U2VydmljZSZndDtcCiAgICAgICAgICAmbHQ7L2lv ZGVmOlN5c3RlbSZndDtcCiAgICAgICAgICAmbHQ7aW9kZWY6U3lzdGVtIGNhdGVnb3J5PSJ0YXJn ZXQiJmd0O1wKICAgICAgICAgICAgJmx0O2lvZGVmOk5vZGUmZ3Q7XAogICAgICAgICAgICAgICZs dDtpb2RlZjpBZGRyZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiJmd0OzE5Mi4wLjIuNjdcCiAgICAg ICAgICAgICAgJmx0Oy9pb2RlZjpBZGRyZXNzJmd0O1wKICAgICAgICAgICAgJmx0Oy9pb2RlZjpO b2RlJmd0O1wKICAgICAgICAgICAgJmx0O2lvZGVmOlNlcnZpY2UmZ3Q7XAogICAgICAgICAgICAg ICZsdDtpb2RlZjpwb3J0Jmd0OzgwJmx0Oy9pb2RlZjpwb3J0Jmd0O1wKICAgICAgICAgICAgJmx0 Oy9pb2RlZjpTZXJ2aWNlJmd0O1wKICAgICAgICAgICZsdDsvaW9kZWY6U3lzdGVtJmd0O1wKICAg ICAgICAmbHQ7L2lvZGVmOkZsb3cmZ3Q7XAogICAgICAgICZsdDtpb2RlZjpFeHBlY3RhdGlvbiBz ZXZlcml0eT0iaGlnaCIgYWN0aW9uPSJyYXRlLWxpbWl0LWhvc3QiJmd0O1wKICAgICAgICAgICZs dDtpb2RlZjpEZXNjcmlwdGlvbiZndDtcCiAgICAgICAgICAgIFJhdGUtbGltaXQgdHJhZmZpYyBj bG9zZSB0byBzb3VyY2VcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDMzXVwKXApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFc ClwKXAogICAgICAgICAgJmx0Oy9pb2RlZjpEZXNjcmlwdGlvbiZndDtcCiAgICAgICAgJmx0Oy9p b2RlZjpFeHBlY3RhdGlvbiZndDtcCiAgICAgICAgJmx0O2lvZGVmOlJlY29yZCZndDtcCiAgICAg ICAgICAmbHQ7aW9kZWY6UmVjb3JkRGF0YSZndDtcCiAgICAgICAgICAgICZsdDtpb2RlZjpEZXNj cmlwdGlvbiZndDtcCiAgICAgICAgICAgICAgVGhlIElQdjQgcGFja2V0IGluY2x1ZGVkIHdhcyB1 c2VkIGluIHRoZSBkZXNjcmliZWQgYXR0YWNrXAogICAgICAgICAgICAmbHQ7L2lvZGVmOkRlc2Ny aXB0aW9uJmd0O1wKICAgICAgICAgICAgJmx0O2lvZGVmOlJlY29yZEl0ZW0gZHR5cGU9ImlwdjQt cGFja2V0IiZndDs0NTAwMDA1MjJhZDlcCiAgICAgICAgICAgICAgIDAwMDBmZjA2YzQxZmMwYTgw MTAyMGEwMTAxMDI5NzZkMDA1MDEwM2UwMjA4MTBkOVwKICAgICAgICAgICAgICAgNGExMzUwMDIx MDAwYWQ2NzAwMDA1NDY4NjE2ZTZiMjA3OTZmNzUyMDY2NmY3MjIwXAogICAgICAgICAgICAgICA2 MzYxNzI2NTY2NzU2YzZjNzkyMDcyNjU2MTY0Njk2ZTY3MjA3NDY4Njk3MzIwNTJcCiAgICAgICAg ICAgICAgIDQ2NDMyZTBhXAogICAgICAgICAgICAmbHQ7L2lvZGVmOlJlY29yZEl0ZW0mZ3Q7XAog ICAgICAgICAgJmx0Oy9pb2RlZjpSZWNvcmREYXRhJmd0O1wKICAgICAgICAmbHQ7L2lvZGVmOlJl Y29yZCZndDtcCiAgICAgICZsdDsvaW9kZWY6RXZlbnREYXRhJmd0O1wKICAgICAgJmx0O2lvZGVm Okhpc3RvcnkmZ3Q7XAogICAgICAgICZsdDtpb2RlZjpIaXN0b3J5SXRlbSZndDtcCiAgICAgICAg ICAmbHQ7aW9kZWY6RGF0ZVRpbWUmZ3Q7MjAwMS0wOS0xNFQwODoxOTowMSswMDowMCZsdDsvaW9k ZWY6RGF0ZVRpbWUmZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOkluY2lkZW50SUQgbmFtZT0iQ1NJ UlQtRk9SLU9VUi1ET01BSU4iJmd0O1wKICAgICAgICAgICAgQ1NJUlQtRk9SLU9VUi1ET01BSU4j MjA3LTFcCiAgICAgICAgICAmbHQ7L2lvZGVmOkluY2lkZW50SUQmZ3Q7XAogICAgICAgICAgJmx0 O2lvZGVmOkRlc2NyaXB0aW9uJmd0O1wKICAgICAgICAgICAgTm90aWZpY2F0aW9uIHNlbnQgdG8g bmV4dCB1cHN0cmVhbSBTUCBjbG9zZXIgdG8gMTkyLjAuMi4zNVwKICAgICAgICAgICZsdDsvaW9k ZWY6RGVzY3JpcHRpb24mZ3Q7XAogICAgICAgICZsdDsvaW9kZWY6SGlzdG9yeUl0ZW0mZ3Q7XAog ICAgICAmbHQ7L2lvZGVmOkhpc3RvcnkmZ3Q7XAogICAgJmx0Oy9pb2RlZjpJbmNpZGVudCZndDtc CiAgJmx0Oy9pb2RlZjpJT0RFRi1Eb2N1bWVudCZndDtcClwKICAmbHQ7IS0tIERpZ2l0YWwgc2ln bmF0dXJlIGFjY29tcGFuaWVkIGJ5IGFib3ZlIFJJRCBhbmQgSU9ERUYgLS0mZ3Q7XApcCiAgJmx0 O0VudmVsb3BlIHhtbG5zPSJ1cm46ZW52ZWxvcGUiXAogICAgICAgICAgICB4bWxuczppb2RlZj0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiXAogICAgICAgICAgICB4bWxuczppb2Rl Zi1yaWQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtcmlkLTEuMCImZ3Q7XAogICAgJmx0 O2lvZGVmOklPREVGLURvY3VtZW50Jmd0O1wKICAgICAgJmx0O2lvZGVmOkluY2lkZW50Jmd0O1wK ICAgICAgICAmbHQ7aW9kZWY6RXZlbnREYXRhJmd0O1wKICAgICAgICAgICZsdDtpb2RlZjpSZWNv cmQmZ3Q7XAogICAgICAgICAgICAmbHQ7aW9kZWY6UmVjb3JkRGF0YSZndDtcCiAgICAgICAgICAg ICAgJmx0O2lvZGVmOlJlY29yZEl0ZW0gdHlwZT0iaXB2NC1wYWNrZXQiJmd0OzQ1MDAwMDUyMmFk OVwKICAgICAgICAgICAgICAgMDAwMGZmMDZjNDFmYzBhODAxMDIwYTAxMDEwMjk3NmQwMDUwMTAz ZTAyMDgxMGQ5XAogICAgICAgICAgICAgICA0YTEzNTAwMjEwMDBhZDY3MDAwMDU0Njg2MTZlNmIy MDc5NmY3NTIwNjY2ZjcyMjBcCiAgICAgICAgICAgICAgIDYzNjE3MjY1NjY3NTZjNmM3OTIwNzI2 NTYxNjQ2OTZlNjcyMDc0Njg2OTczMjA1MlwKICAgICAgICAgICAgICAgNDY0MzJlMGFcCiAgICAg ICAgICAgICAgJmx0Oy9pb2RlZjpSZWNvcmRJdGVtJmd0O1wKICAgICAgICAgICAgJmx0Oy9pb2Rl ZjpSZWNvcmREYXRhJmd0O1wKICAgICAgICAgICZsdDsvaW9kZWY6UmVjb3JkJmd0O1wKXApcClwK TW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAg ICAgICAgW1BhZ2UgMzRdXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1 LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgICAgJmx0Oy9pb2Rl ZjpFdmVudERhdGEmZ3Q7XAogICAgICAmbHQ7L2lvZGVmOkluY2lkZW50Jmd0O1wKICAgICZsdDsv aW9kZWY6SU9ERUYtRG9jdW1lbnQmZ3Q7XAogICAgJmx0O1NpZ25hdHVyZSB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyImZ3Q7XAogICAgICAmbHQ7U2lnbmVkSW5mbyZn dDtcCiAgICAgICAgJmx0O0Nhbm9uaWNhbGl6YXRpb25NZXRob2RcCiAgICAgICAgICAgQWxnb3Jp dGhtPSJodHRwOi8vd3d3LnczLm9yZy9UUi8yMDAxL1wKICAgICAgICAgICAgUkVDLXhtbC1jMTRu LTIwMDEwMzE1I1dpdGhDb21tZW50cyIvJmd0O1wKICAgICAgICAmbHQ7U2lnbmF0dXJlTWV0aG9k XAogICAgICAgICAgIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2ln I2RzYS1zaGExIi8mZ3Q7XAogICAgICAgICZsdDtSZWZlcmVuY2UgVVJJPSIiJmd0O1wKICAgICAg ICAgICZsdDtUcmFuc2Zvcm1zJmd0O1wKICAgICAgICAgICAgJmx0O1RyYW5zZm9ybSBBbGdvcml0 aG09XAogICAgICAgICAgICAgImh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNlbnZl bG9wZWQtc2lnbmF0dXJlIi8mZ3Q7XAogICAgICAgICAgJmx0Oy9UcmFuc2Zvcm1zJmd0O1wKICAg ICAgICAgICZsdDtEaWdlc3RNZXRob2RcCiAgICAgICAgICAgICBBbGdvcml0aG09Imh0dHA6Ly93 d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIi8mZ3Q7XAogICAgICAgICAgJmx0O0RpZ2Vz dFZhbHVlJmd0O0tpSTUrNlNuRkFzNDI5Vk53c29KakhQcGxtbz0mbHQ7L0RpZ2VzdFZhbHVlJmd0 O1wKICAgICAgICAmbHQ7L1JlZmVyZW5jZSZndDtcCiAgICAgICZsdDsvU2lnbmVkSW5mbyZndDtc CiAgICAgICZsdDtTaWduYXR1cmVWYWx1ZSZndDtcCiAgICAgICAgVnZ5WHFDempvVzBtMk5keE5l VG9YUWNxY1NNODBXK0pNVytLbjAxY1MzejNLUXdDUGVzd3pnPT1cCiAgICAgICZsdDsvU2lnbmF0 dXJlVmFsdWUmZ3Q7XAogICAgICAmbHQ7S2V5SW5mbyZndDtcCiAgICAgICAgJmx0O0tleVZhbHVl Jmd0O1wKICAgICAgICAgICZsdDtEU0FLZXlWYWx1ZSZndDtcCiAgICAgICAgICAgICZsdDtQJmd0 Oy9LYUN6bzRTeXJvbTc4ejNFUTVTYmJCNHNGN2V5ODBldEtJSTg2NFdGNjRCODF1UnBINXQ5alwK ICAgICAgICAgICAgICAgUVR4ZUV1MEltYnpSTXF6VkRaa1ZHOXhEN25OMWt1Rnc9PSZsdDsvUCZn dDtcCiAgICAgICAgICAgICZsdDtRJmd0O2xpN2R6RGFjdW82N0pnN210cUVtMlRSdU9NVT0mbHQ7 L1EmZ3Q7XAogICAgICAgICAgICAmbHQ7RyZndDtaNFJ4c25xYzlFN3BHa25GRkgyeHFhcnlSUEJh UTAxa2hwTWRMUlFuRzU0MUF3dHgvWFBhRjVcCiAgICAgICAgICAgICAgIEJwc3k0cE5XTU9IQ0Jp TlUwTm9ncHNRVzVRdm5sTXBBPT0mbHQ7L0cmZ3Q7XAogICAgICAgICAgICAmbHQ7WSZndDtWRldU RDRJL2FLbmk0WWhEeVl4QUpvem1qMWlBelBMdzlXd2Q1QitaOUo1RTdsSGpjQUorYnNcCiAgICAg ICAgICAgICAgIEhpZlR5WWRuaityb0d6eTRvMDlZbnRZRDh6bmVRN2x3PT0mbHQ7L1kmZ3Q7XAog ICAgICAgICAgJmx0Oy9EU0FLZXlWYWx1ZSZndDtcCiAgICAgICAgJmx0Oy9LZXlWYWx1ZSZndDtc CiAgICAgICZsdDsvS2V5SW5mbyZndDtcCiAgICAmbHQ7L1NpZ25hdHVyZSZndDtcCiAgJmx0Oy9F bnZlbG9wZSZndDtcClwKXAo1LjEuMi4gIFJlcXVlc3RBdXRob3JpemF0aW9uIE1lc3NhZ2UgRXhh bXBsZVwKXAogICBUaGUgZXhhbXBsZSBSZXF1ZXN0QXV0aG9yaXphdGlvbiBtZXNzYWdlIGlzIGlu IHJlc3BvbnNlIHRvIHRoZVwKICAgVHJhY2VSZXF1ZXN0IG1lc3NhZ2UgbGlzdGVkIGFib3ZlLiAg VGhlIFNQIHRoYXQgcmVjZWl2ZWQgdGhlIHJlcXVlc3RcCiAgIGlzIHJlc3BvbmRpbmcgdG8gYXBw cm92ZSB0aGUgdHJhY2UgY29udGludWFuY2UgaW4gdGhlaXIgbmV0d29yay5cClwKXApcClwKXApc Ck1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAg ICAgICAgIFtQYWdlIDM1XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0 NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAmbHQ7aW9kZWYtcmlk OlJJRCB4bWxuczppb2RlZi1yaWQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtcmlkLTEu MCJcCiAgICAgICAgICAgICAgICAgIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z OmlvZGVmLTEuMCImZ3Q7XAogICAgICZsdDtpb2RlZi1yaWQ6UklEUG9saWN5IE1zZ1R5cGU9IlJl cXVlc3RBdXRob3JpemF0aW9uIlwKICAgICAgICAgICAgICAgICAgICAgICAgICBNc2dEZXN0aW5h dGlvbj0iUklEU3lzdGVtIiZndDtcCiAgICAgICAmbHQ7aW9kZWYtcmlkOlBvbGljeVJlZ2lvbiBy ZWdpb249IkludHJhQ29uc29ydGl1bSIvJmd0O1wKICAgICAgICZsdDtpb2RlZjpOb2RlJmd0O1wK ICAgICAgICAgJmx0O2lvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImlwdjQtYWRkciImZ3Q7MTkyLjAu Mi42NyZsdDsvaW9kZWY6QWRkcmVzcyZndDtcCiAgICAgICAmbHQ7L2lvZGVmOk5vZGUmZ3Q7XAog ICAgICAgJmx0O2lvZGVmLXJpZDpUcmFmZmljVHlwZSB0eXBlPSJBdHRhY2siLyZndDtcCiAgICAg ICAmbHQ7aW9kZWY6SW5jaWRlbnRJRCBuYW1lPSJDRVJULUZPUi1PVVItRE9NQUlOIiZndDtcCiAg ICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjA3LTFcCiAgICAgICAmbHQ7L2lvZGVmOkluY2lk ZW50SUQmZ3Q7XAogICAgICZsdDsvaW9kZWYtcmlkOlJJRFBvbGljeSZndDtcCiAgICAgJmx0O2lv ZGVmLXJpZDpSZXF1ZXN0U3RhdHVzIEF1dGhvcml6YXRpb25TdGF0dXM9IkFwcHJvdmVkIi8mZ3Q7 XAogICAmbHQ7L2lvZGVmLXJpZDpSSUQmZ3Q7Jmx0Oy9zZWN0aW9uJmd0O1wKXAo1LjEuMy4gIFJl c3VsdCBNZXNzYWdlIEV4YW1wbGVcClwKICAgVGhlIGV4YW1wbGUgUmVzdWx0IG1lc3NhZ2UgaXMg aW4gcmVzcG9uc2UgdG8gdGhlIFRyYWNlUmVxdWVzdCBsaXN0ZWRcCiAgIGFib3ZlLiAgVGhpcyBt ZXNzYWdlIHR5cGUgb25seSBjb21lcyBhZnRlciBhIFJlcXVlc3RBdXRob3JpemF0aW9uXAogICB3 aXRoaW4gdGhlIFRyYWNlUmVxdWVzdCBmbG93IG9mIG1lc3NhZ2VzLiAgSXQgbWF5IGJlIGEgZGly ZWN0XAogICByZXNwb25zZSB0byBhbiBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QuICBUaGlzIG1lc3Nh Z2UgcHJvdmlkZXNcCiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzb3VyY2Ugb2YgdGhlIGF0dGFj ayBhbmQgdGhlIGFjdGlvbnMgdGFrZW4gdG9cCiAgIG1pdGlnYXRlIHRoZSB0cmFmZmljLlwKXAog ICZsdDtpb2RlZi1yaWQ6UklEIHhtbG5zOmlvZGVmLXJpZD0idXJuOmlldGY6cGFyYW1zOnhtbDpu czppb2RlZi1yaWQtMS4wIlwKICAgICAgICAgICAgICAgICB4bWxuczppb2RlZj0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiJmd0O1wKICAgICZsdDtpb2RlZi1yaWQ6UklEUG9saWN5 IE1zZ1R5cGU9IlJlc3VsdCJcCiAgICAgICAgICAgICAgICAgICAgICAgICBNc2dEZXN0aW5hdGlv bj0iUklEU3lzdGVtIiZndDtcCiAgICAgICZsdDtpb2RlZi1yaWQ6UG9saWN5UmVnaW9uIHJlZ2lv bj0iSW50cmFDb25zb3J0aXVtIi8mZ3Q7XAogICAgICAmbHQ7aW9kZWY6Tm9kZSZndDtcCiAgICAg ICAgJmx0O2lvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImlwdjQtYWRkciImZ3Q7MTkyLjAuMi42NyZs dDsvaW9kZWY6QWRkcmVzcyZndDtcCiAgICAgICZsdDsvaW9kZWY6Tm9kZSZndDtcCiAgICAgICZs dDtpb2RlZi1yaWQ6VHJhZmZpY1R5cGUgdHlwZT0iQXR0YWNrIi8mZ3Q7XAogICAgICAmbHQ7aW9k ZWY6SW5jaWRlbnRJRCBuYW1lPSJDRVJULUZPUi1PVVItRE9NQUlOIiZndDtcCiAgICAgICAgQ0VS VC1GT1ItT1VSLURPTUFJTiMyMDctMVwKICAgICAgJmx0Oy9pb2RlZjpJbmNpZGVudElEJmd0O1wK ICAgICZsdDsvaW9kZWYtcmlkOlJJRFBvbGljeSZndDtcCiAgICAmbHQ7aW9kZWYtcmlkOkluY2lk ZW50U291cmNlJmd0O1wKICAgICAgJmx0O2lvZGVmLXJpZDpTb3VyY2VGb3VuZCZndDt0cnVlJmx0 Oy9pb2RlZi1yaWQ6U291cmNlRm91bmQmZ3Q7XAogICAgICAmbHQ7aW9kZWY6Tm9kZSZndDtcCiAg ICAgICAgJmx0O2lvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImlwdjQtYWRkciImZ3Q7MTkyLjAuMi4z NyZsdDsvaW9kZWY6QWRkcmVzcyZndDtcCiAgICAgICZsdDsvaW9kZWY6Tm9kZSZndDtcCiAgICAm bHQ7L2lvZGVmLXJpZDpJbmNpZGVudFNvdXJjZSZndDtcCiAgJmx0Oy9pb2RlZi1yaWQ6UklEJmd0 O1wKXAogICZsdDshLS0gSU9ERUYtRG9jdW1lbnQgYWNjb21wYW5pZWQgYnkgdGhlIGFib3ZlIFJJ RCAtLSZndDtcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzZdXApcCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApc CiAgJmx0O2lvZGVmOklPREVGLURvY3VtZW50IHZlcnNpb249IjEuMDAiXAogICAgICAgICAgICAg ICAgICAgICAgICB4bWxuczppb2RlZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAi Jmd0O1wKICAgICZsdDtpb2RlZjpJbmNpZGVudCByZXN0cmljdGlvbj0ibmVlZC10by1rbm93IiBw dXJwb3NlPSJ0cmFjZWJhY2siJmd0O1wKICAgICAgJmx0O2lvZGVmOkluY2lkZW50SUQgbmFtZT0i Q0VSVC1GT1ItT1VSLURPTUFJTiImZ3Q7XAogICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjA3 LTFcCiAgICAgICZsdDsvaW9kZWY6SW5jaWRlbnRJRCZndDtcCiAgICAgICZsdDtpb2RlZjpEZXRl Y3RUaW1lJmd0OzIwMDQtMDItMDJUMjI6NDk6MjQrMDA6MDAmbHQ7L2lvZGVmOkRldGVjdFRpbWUm Z3Q7XAogICAgICAmbHQ7aW9kZWY6U3RhcnRUaW1lJmd0OzIwMDQtMDItMDJUMjI6MTk6MjQrMDA6 MDAmbHQ7L2lvZGVmOlN0YXJ0VGltZSZndDtcCiAgICAgICZsdDtpb2RlZjpSZXBvcnRUaW1lJmd0 OzIwMDQtMDItMDJUMjM6MjA6MjQrMDA6MDAmbHQ7L2lvZGVmOlJlcG9ydFRpbWUmZ3Q7XAogICAg ICAmbHQ7aW9kZWY6RGVzY3JpcHRpb24mZ3Q7SG9zdCBpbnZvbHZlZCBpbiBEb1MgYXR0YWNrJmx0 Oy9pb2RlZjpEZXNjcmlwdGlvbiZndDtcCiAgICAgICZsdDtpb2RlZjpBc3Nlc3NtZW50Jmd0O1wK ICAgICAgICAmbHQ7aW9kZWY6SW1wYWN0IHNldmVyaXR5PSJsb3ciIGNvbXBsZXRpb249ImZhaWxl ZCIgdHlwZT0iZG9zIi8mZ3Q7XAogICAgICAmbHQ7L2lvZGVmOkFzc2Vzc21lbnQmZ3Q7XAogICAg ICAmbHQ7aW9kZWY6Q29udGFjdCByb2xlPSJjcmVhdG9yIiB0eXBlPSJvcmdhbml6YXRpb24iJmd0 O1wKICAgICAgICAmbHQ7aW9kZWY6Q29udGFjdE5hbWUmZ3Q7Q29uc3RpdHVlbmN5LWNvbnRhY3Qg Zm9yIDE5Mi4wLjIuMzVcCiAgICAgICAgJmx0Oy9pb2RlZjpDb250YWN0TmFtZSZndDtcCiAgICAg ICAgJmx0O2lvZGVmOkVtYWlsJmd0O0NvbnN0aXR1ZW5jeS1jb250YWN0QDE5Mi4wLjIuMzUmbHQ7 L2lvZGVmOkVtYWlsJmd0O1wKICAgICAgJmx0Oy9pb2RlZjpDb250YWN0Jmd0O1wKICAgICAgJmx0 O2lvZGVmOkV2ZW50RGF0YSZndDtcCiAgICAgICAgJmx0O2lvZGVmOkNvbnRhY3Qgcm9sZT0iYWRt aW4iIHR5cGU9Im9yZ2FuaXphdGlvbiImZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOkNvbnRhY3RO YW1lJmd0O0FkbWluLWNvbnRhY3QgZm9yIDE5Mi4wLjIuMzVcCiAgICAgICAgICAmbHQ7L2lvZGVm OkNvbnRhY3ROYW1lJmd0O1wKICAgICAgICAgICZsdDtpb2RlZjpFbWFpbCZndDtBZG1pbi1jb250 YWN0QDEwLjEuMS4yJmx0Oy9pb2RlZjpFbWFpbCZndDtcCiAgICAgICAgJmx0Oy9pb2RlZjpDb250 YWN0Jmd0O1wKICAgICAgICAmbHQ7aW9kZWY6RmxvdyZndDtcCiAgICAgICAgICAmbHQ7aW9kZWY6 U3lzdGVtIGNhdGVnb3J5PSJpbnRlcm1lZGlhdGUiJmd0O1wKICAgICAgICAgICAgJmx0O2lvZGVm Ok5vZGUmZ3Q7XAogICAgICAgICAgICAgICZsdDtpb2RlZjpBZGRyZXNzIGNhdGVnb3J5PSJpcHY0 LWFkZHIiJmd0OzE5Mi4wLjIuMzVcCiAgICAgICAgICAgICAgJmx0Oy9pb2RlZjpBZGRyZXNzJmd0 O1wKICAgICAgICAgICAgJmx0Oy9pb2RlZjpOb2RlJmd0O1wKICAgICAgICAgICZsdDsvaW9kZWY6 U3lzdGVtJmd0O1wKICAgICAgICAmbHQ7L2lvZGVmOkZsb3cmZ3Q7XAogICAgICAgICZsdDtpb2Rl ZjpFdmVudERhdGEmZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOkNvbnRhY3Qgcm9sZT0iYWRtaW4i IHR5cGU9Im9yZ2FuaXphdGlvbiImZ3Q7XAogICAgICAgICAgICAmbHQ7aW9kZWY6Q29udGFjdE5h bWUmZ3Q7QWRtaW4tY29udGFjdCBmb3IgMTkyLjAuMi4zXAogICAgICAgICAgICAmbHQ7L2lvZGVm OkNvbnRhY3ROYW1lJmd0O1wKICAgICAgICAgICAgJmx0O2lvZGVmOkVtYWlsJmd0O0FkbWluLWNv bnRhY3RAMTkyLjAuMi4zJmx0Oy9pb2RlZjpFbWFpbCZndDtcCiAgICAgICAgICAmbHQ7L2lvZGVm OkNvbnRhY3QmZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOkZsb3cmZ3Q7XAogICAgICAgICAgICAm bHQ7aW9kZWY6U3lzdGVtIGNhdGVnb3J5PSJpbnRlcm1lZGlhdGUiJmd0O1wKICAgICAgICAgICAg ICAmbHQ7aW9kZWY6Tm9kZSZndDtcCiAgICAgICAgICAgICAgICAmbHQ7aW9kZWY6QWRkcmVzcyBj YXRlZ29yeT0iaXB2NC1hZGRyIiZndDsxOTIuMC4yLjNcCiAgICAgICAgICAgICAgICAmbHQ7L2lv ZGVmOkFkZHJlc3MmZ3Q7XAogICAgICAgICAgICAgICZsdDsvaW9kZWY6Tm9kZSZndDtcCiAgICAg ICAgICAgICZsdDsvaW9kZWY6U3lzdGVtJmd0O1wKICAgICAgICAgICZsdDsvaW9kZWY6RmxvdyZn dDtcCiAgICAgICAgJmx0Oy9pb2RlZjpFdmVudERhdGEmZ3Q7XAogICAgICAmbHQ7L2lvZGVmOkV2 ZW50RGF0YSZndDtcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDM3XVwKXApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwK XAogICAgICAmbHQ7aW9kZWY6RXZlbnREYXRhJmd0O1wKICAgICAgICAmbHQ7aW9kZWY6RmxvdyZn dDtcCiAgICAgICAgICAmbHQ7aW9kZWY6U3lzdGVtIGNhdGVnb3J5PSJzb3VyY2UiJmd0O1wKICAg ICAgICAgICAgJmx0O2lvZGVmOk5vZGUmZ3Q7XAogICAgICAgICAgICAgICZsdDtpb2RlZjpBZGRy ZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiJmd0OzE5Mi4wLjIuMzVcCiAgICAgICAgICAgICAgJmx0 Oy9pb2RlZjpBZGRyZXNzJmd0O1wKICAgICAgICAgICAgJmx0Oy9pb2RlZjpOb2RlJmd0O1wKICAg ICAgICAgICAgJmx0O2lvZGVmOlNlcnZpY2UmZ3Q7XAogICAgICAgICAgICAgICZsdDtpb2RlZjpw b3J0Jmd0OzM4NzY1Jmx0Oy9pb2RlZjpwb3J0Jmd0O1wKICAgICAgICAgICAgJmx0Oy9pb2RlZjpT ZXJ2aWNlJmd0O1wKICAgICAgICAgICZsdDsvaW9kZWY6U3lzdGVtJmd0O1wKICAgICAgICAgICZs dDtpb2RlZjpTeXN0ZW0gY2F0ZWdvcnk9InRhcmdldCImZ3Q7XAogICAgICAgICAgICAmbHQ7aW9k ZWY6Tm9kZSZndDtcCiAgICAgICAgICAgICAgJmx0O2lvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9Imlw djQtYWRkciImZ3Q7MTkyLjAuMi42N1wKICAgICAgICAgICAgICAmbHQ7L2lvZGVmOkFkZHJlc3Mm Z3Q7XAogICAgICAgICAgICAmbHQ7L2lvZGVmOk5vZGUmZ3Q7XAogICAgICAgICAgICAmbHQ7aW9k ZWY6U2VydmljZSZndDtcCiAgICAgICAgICAgICAgJmx0O2lvZGVmOnBvcnQmZ3Q7ODAmbHQ7L2lv ZGVmOnBvcnQmZ3Q7XAogICAgICAgICAgICAmbHQ7L2lvZGVmOlNlcnZpY2UmZ3Q7XAogICAgICAg ICAgJmx0Oy9pb2RlZjpTeXN0ZW0mZ3Q7XAogICAgICAgICZsdDsvaW9kZWY6RmxvdyZndDtcCiAg ICAgICAgJmx0O2lvZGVmOkV4cGVjdGF0aW9uIHNldmVyaXR5PSJoaWdoIiBhY3Rpb249InJhdGUt bGltaXQtaG9zdCImZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOkRlc2NyaXB0aW9uJmd0O1wKICAg ICAgICAgICAgUmF0ZS1saW1pdCB0cmFmZmljIGNsb3NlIHRvIHNvdXJjZVwKICAgICAgICAgICZs dDsvaW9kZWY6RGVzY3JpcHRpb24mZ3Q7XAogICAgICAgICZsdDsvaW9kZWY6RXhwZWN0YXRpb24m Z3Q7XAogICAgICAgICZsdDtpb2RlZjpSZWNvcmQmZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOlJl Y29yZERhdGEmZ3Q7XAogICAgICAgICAgICAmbHQ7aW9kZWY6RGVzY3JpcHRpb24mZ3Q7XAogICAg ICAgICAgICAgIFRoZSBJUHY0IHBhY2tldCBpbmNsdWRlZCB3YXMgdXNlZCBpbiB0aGUgZGVzY3Jp YmVkIGF0dGFja1wKICAgICAgICAgICAgJmx0Oy9pb2RlZjpEZXNjcmlwdGlvbiZndDtcCiAgICAg ICAgICAgICZsdDtpb2RlZjpSZWNvcmRJdGVtIGR0eXBlPSJpcHY0LXBhY2tldCImZ3Q7NDUwMDAw NTIyYWQ5XAogICAgICAgICAgICAwMDAwZmYwNmM0MWZjMGE4MDEwMjBhMDEwMTAyOTc2ZDAwNTAx MDNlMDIwODEwZDlcCiAgICAgICAgICAgIDRhMTM1MDAyMTAwMGFkNjcwMDAwNTQ2ODYxNmU2YjIw Nzk2Zjc1MjA2NjZmNzIyMFwKICAgICAgICAgICAgNjM2MTcyNjU2Njc1NmM2Yzc5MjA3MjY1NjE2 NDY5NmU2NzIwNzQ2ODY5NzMyMDUyXAogICAgICAgICAgICA0NjQzMmUwYVwKICAgICAgICAgICAg Jmx0Oy9pb2RlZjpSZWNvcmRJdGVtJmd0O1wKICAgICAgICAgICZsdDsvaW9kZWY6UmVjb3JkRGF0 YSZndDtcCiAgICAgICAgJmx0Oy9pb2RlZjpSZWNvcmQmZ3Q7XAogICAgICAmbHQ7L2lvZGVmOkV2 ZW50RGF0YSZndDtcCiAgICAgICZsdDtpb2RlZjpIaXN0b3J5Jmd0O1wKICAgICAgICAmbHQ7aW9k ZWY6SGlzdG9yeUl0ZW0mZ3Q7XAogICAgICAgICAgJmx0O2lvZGVmOkRhdGVUaW1lJmd0OzIwMDQt MDItMDJUMjI6NTM6MDErMDA6MDAmbHQ7L2lvZGVmOkRhdGVUaW1lJmd0O1wKICAgICAgICAgICZs dDtpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNTSVJULUZPUi1PVVItRE9NQUlOIiZndDtcCiAgICAg ICAgICAgIENTSVJULUZPUi1PVVItRE9NQUlOIzIwNy0xXAogICAgICAgICAgJmx0Oy9pb2RlZjpJ bmNpZGVudElEJmd0O1wKICAgICAgICAgICZsdDtpb2RlZjpEZXNjcmlwdGlvbiZndDtcCiAgICAg ICAgICAgIE5vdGlmaWNhdGlvbiBzZW50IHRvIG5leHQgdXBzdHJlYW0gU1AgY2xvc2VyIHRvIDE5 Mi4wLjIuMzVcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg MjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDM4XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAog ICAgICAgICAgJmx0Oy9pb2RlZjpEZXNjcmlwdGlvbiZndDtcCiAgICAgICAgJmx0Oy9pb2RlZjpI aXN0b3J5SXRlbSZndDtcCiAgICAgICAgJmx0O2lvZGVmOkhpc3RvcnlJdGVtIGFjdGlvbj0icmF0 ZS1saW1pdC1ob3N0IiZndDtcCiAgICAgICAgICAmbHQ7aW9kZWY6RGF0ZVRpbWUmZ3Q7MjAwNC0w Mi0wMlQyMzowNzoyMSswMDowMCZsdDsvaW9kZWY6RGF0ZVRpbWUmZ3Q7XAogICAgICAgICAgJmx0 O2lvZGVmOkluY2lkZW50SUQgbmFtZT0iQ1NJUlQtRk9SLVNQMyImZ3Q7XAogICAgICAgICAgICBD U0lSVC1GT1ItU1AzIzMyOTEtMVwKICAgICAgICAgICZsdDsvaW9kZWY6SW5jaWRlbnRJRCZndDtc CiAgICAgICAgICAmbHQ7aW9kZWY6RGVzY3JpcHRpb24mZ3Q7XAogICAgICAgICAgICBIb3N0IHJh dGUtbGltaXRlZCBmb3IgMjQgaG91cnNcCiAgICAgICAgICAmbHQ7L2lvZGVmOkRlc2NyaXB0aW9u Jmd0O1wKICAgICAgICAmbHQ7L2lvZGVmOkhpc3RvcnlJdGVtJmd0O1wKICAgICAgJmx0Oy9pb2Rl ZjpIaXN0b3J5Jmd0O1wKICAgICZsdDsvaW9kZWY6SW5jaWRlbnQmZ3Q7XAogICZsdDsvaW9kZWY6 SU9ERUYtRG9jdW1lbnQmZ3Q7XApcCjUuMi4gIEludmVzdGlnYXRpb24gUmVxdWVzdCBDb21tdW5p Y2F0aW9uIEZsb3dcClwKICAgVGhlIGRpYWdyYW0gYmVsb3cgb3V0bGluZXMgdGhlIFJJRCBJbnZl c3RpZ2F0aW9uIHJlcXVlc3RcCiAgIGNvbW11bmljYXRpb24gZmxvdyBiZXR3ZWVuIFJJRCBzeXN0 ZW1zIG9uIGRpZmZlcmVudCBuZXR3b3JrcyBmb3IgYVwKICAgc2VjdXJpdHkgaW5jaWRlbnQgd2l0 aCBhIGtub3duIHNvdXJjZSBhZGRyZXNzLiAgVGhlIHByb3BlciByZXNwb25zZVwKICAgdG8gYW4g SW52ZXN0aWdhdGlvbiByZXF1ZXN0IGlzIGEgUmVzdWx0IG1lc3NhZ2UuICBJZiB0aGVyZSBpcyBh XAogICBwcm9ibGVtIHdpdGggdGhlIHJlcXVlc3QsIHN1Y2ggYXMgYSBmYWlsdXJlIHRvIHZhbGlk YXRlIHRoZSBkaWdpdGFsXAogICBzaWduYXR1cmUgb3IgZGVjcnlwdCB0aGUgcmVxdWVzdCwgYSBS ZXF1ZXN0QXV0aG9yaXphdGlvbiBtZXNzYWdlIGlzXAogICBzZW50IHRvIHRoZSByZXF1ZXN0b3Iu ICBUaGUgUmVxdWVzdEF1dGhvcml6YXRpb24gbWVzc2FnZSBzaG91bGRcCiAgIHByb3ZpZGUgdGhl IHJlYXNvbiB3aHkgdGhlIG1lc3NhZ2UgY291bGQgbm90IGJlIHByb2Nlc3NlZC5cClwKICAgICAg ICBBdHRhY2sgRGVzdCAgICAgIFNQLTEgICAgICAgICAgICAgIFNQLTIgICAgICAgIEF0dGFjayBT cmNcClwKICAgICAgICAxLiBBdHRhY2sgICAgfCAgQXR0YWNrXAogICAgICAgICAgIHJlcG9ydGVk ICB8ICBkZXRlY3RlZFwKXAogICAgICAgIDIuICAgICAgICAgICAgICBEZXRlcm1pbmUgc291cmNl XAogICAgICAgICAgICAgICAgICAgICAgICBvZiBzZWN1cml0eSBpbmNpZGVudFwKXAogICAgICAg IDMuICAgICAgICAgICAgICBvLS0tSW52ZXN0aWdhdGlvbi0tLS0mZ3Q7XApcCiAgICAgICAgNC4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXNlYXJjaFwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGluY2lkZW50IGFuZFwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGRldGVybWluZSBhcHByb3ByaWF0ZVwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGFjdGlvbnMgdG8gdGFrZVwKXAogICAgICAgIDUuICAg ICAgICAgICAgICAmbHQ7LS0tLS0tLVJlc3VsdC0tLS0tLS1vXApcClwKICAgICAgICAgICAgICAg IEZpZ3VyZSA4OiBJbnZlc3RpZ2F0aW9uIENvbW11bmljYXRpb24gRmxvd1wKXApcClwKXApcClwK TW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAg ICAgICAgW1BhZ2UgMzldXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1 LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCjUuMi4xLiAgSW52ZXN0aWdh dGlvbiBSZXF1ZXN0IEV4YW1wbGVcClwKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIG9ubHkgaW5j bHVkZXMgdGhlIFJJRC1zcGVjaWZpYyBkZXRhaWxzLiAgVGhlXAogICBJT0RFRiBhbmQgc2VjdXJp dHkgbWVhc3VyZXMgYXJlIHNpbWlsYXIgdG8gdGhlIFRyYWNlUmVxdWVzdFwKICAgaW5mb3JtYXRp b24sIHdpdGggdGhlIGV4Y2VwdGlvbiB0aGF0IHRoZSBzb3VyY2UgaXMga25vd24gYW5kIHRoZVwK ICAgcmVjZWl2aW5nIFJJRCBzeXN0ZW0gaXMga25vd24gdG8gYmUgY2xvc2UgdG8gdGhlIHNvdXJj ZS4gIFRoZSBzb3VyY2VcCiAgIGtub3duIGlzIGluZGljYXRlZCBpbiB0aGUgSU9ERUYgZG9jdW1l bnQsIHdoaWNoIGFsbG93cyBmb3IgaW5jaWRlbnRcCiAgIHNvdXJjZXMgdG8gYmUgbGlzdGVkIGFz IHNwb29mZWQsIGlmIGFwcHJvcHJpYXRlLlwKXAogICZsdDtpb2RlZi1yaWQ6UklEIHhtbG5zOmlv ZGVmLXJpZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi1yaWQtMS4wIlwKICAgICAgICAg ICAgICAgICB4bWxuczppb2RlZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiJmd0 O1wKICAgICZsdDtpb2RlZi1yaWQ6UklEUG9saWN5IE1zZ1R5cGU9IkludmVzdGlnYXRpb24iXAog ICAgICAgICAgICAgICAgICAgICAgICAgTXNnRGVzdGluYXRpb249IlNvdXJjZU9mSW5jaWRlbnQi Jmd0O1wKICAgICAgJmx0O2lvZGVmLXJpZDpQb2xpY3lSZWdpb24gcmVnaW9uPSJQZWVyVG9QZWVy Ii8mZ3Q7XAogICAgICAmbHQ7aW9kZWY6Tm9kZSZndDtcCiAgICAgICAgJmx0O2lvZGVmOkFkZHJl c3MgY2F0ZWdvcnk9ImlwdjQtYWRkciImZ3Q7MTkyLjAuMi45OCZsdDsvaW9kZWY6QWRkcmVzcyZn dDtcCiAgICAgICZsdDsvaW9kZWY6Tm9kZSZndDtcCiAgICAgICZsdDtpb2RlZi1yaWQ6VHJhZmZp Y1R5cGUgdHlwZT0iQXR0YWNrIi8mZ3Q7XAogICAgICAmbHQ7aW9kZWY6SW5jaWRlbnRJRCBuYW1l PSJDRVJULUZPUi1PVVItRE9NQUlOIiZndDtcCiAgICAgICAgQ0VSVC1GT1ItT1VSLURPTUFJTiMy MDgtMVwKICAgICAgJmx0Oy9pb2RlZjpJbmNpZGVudElEJmd0O1wKICAgICZsdDsvaW9kZWYtcmlk OlJJRFBvbGljeSZndDtcCiAgJmx0Oy9pb2RlZi1yaWQ6UklEJmd0O1wKXAogICZsdDshLS0gSU9E RUYtRG9jdW1lbnQgYWNjb21wYW5pZWQgYnkgdGhlIGFib3ZlIFJJRCAtLSZndDtcClwKICAmbHQ7 aW9kZWY6SU9ERUYtRG9jdW1lbnQgdmVyc2lvbj0iMS4wMCJcCiAgICAgICAgICAgICAgICAgICAg ICAgIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCImZ3Q7XAog ICAgJmx0O2lvZGVmOkluY2lkZW50IHJlc3RyaWN0aW9uPSJuZWVkLXRvLWtub3ciIHB1cnBvc2U9 Im90aGVyIiZndDtcCiAgICAgICZsdDtpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNFUlQtRk9SLU9V Ui1ET01BSU4iJmd0O1wKICAgICAgICBDRVJULUZPUi1PVVItRE9NQUlOIzIwOC0xXAogICAgICAm bHQ7L2lvZGVmOkluY2lkZW50SUQmZ3Q7XAogICAgICAmbHQ7aW9kZWY6RGV0ZWN0VGltZSZndDsy MDA0LTAyLTA1VDA4OjEzOjMzKzAwOjAwJmx0Oy9pb2RlZjpEZXRlY3RUaW1lJmd0O1wKICAgICAg Jmx0O2lvZGVmOlN0YXJ0VGltZSZndDsyMDA0LTAyLTA1VDA4OjEzOjMxKzAwOjAwJmx0Oy9pb2Rl ZjpTdGFydFRpbWUmZ3Q7XAogICAgICAmbHQ7aW9kZWY6RW5kVGltZSZndDsyMDA0LTAyLTA1VDA4 OjEzOjMzKzAwOjAwJmx0Oy9pb2RlZjpFbmRUaW1lJmd0O1wKICAgICAgJmx0O2lvZGVmOlJlcG9y dFRpbWUmZ3Q7MjAwNC0wMi0wNVQwODoxMzozNSswMDowMCZsdDsvaW9kZWY6UmVwb3J0VGltZSZn dDtcCiAgICAgICZsdDtpb2RlZjpEZXNjcmlwdGlvbiZndDtIb3N0IGludm9sdmVkIGluIERvUyBh dHRhY2smbHQ7L2lvZGVmOkRlc2NyaXB0aW9uJmd0O1wKICAgICAgJmx0O2lvZGVmOkFzc2Vzc21l bnQmZ3Q7XAogICAgICAgICZsdDtpb2RlZjpJbXBhY3Qgc2V2ZXJpdHk9ImxvdyIgY29tcGxldGlv bj0iZmFpbGVkIiB0eXBlPSJyZWNvbiIvJmd0O1wKICAgICAgJmx0Oy9pb2RlZjpBc3Nlc3NtZW50 Jmd0O1wKICAgICAgJmx0O2lvZGVmOkNvbnRhY3Qgcm9sZT0iY3JlYXRvciIgdHlwZT0ib3JnYW5p emF0aW9uIiZndDtcCiAgICAgICAgJmx0O2lvZGVmOkNvbnRhY3ROYW1lJmd0O0NvbnN0aXR1ZW5j eS1jb250YWN0IGZvciAxOTIuMC4yLjM1XAogICAgICAgICZsdDsvaW9kZWY6Q29udGFjdE5hbWUm Z3Q7XAogICAgICAgICZsdDtpb2RlZjpFbWFpbCZndDtDb25zdGl0dWVuY3ktY29udGFjdEAxMC4x LjEuMiZsdDsvaW9kZWY6RW1haWwmZ3Q7XAogICAgICAmbHQ7L2lvZGVmOkNvbnRhY3QmZ3Q7XAog ICAgICAmbHQ7aW9kZWY6RXZlbnREYXRhJmd0O1wKICAgICAgICAmbHQ7aW9kZWY6RmxvdyZndDtc CiAgICAgICAgICAmbHQ7aW9kZWY6U3lzdGVtIGNhdGVnb3J5PSJzb3VyY2UiJmd0O1wKXApcClwK TW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAg ICAgICAgW1BhZ2UgNDBdXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1 LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgICAgICAgICZsdDtp b2RlZjpOb2RlJmd0O1wKICAgICAgICAgICAgICAmbHQ7aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0i aXB2NC1hZGRyIiZndDsxOTIuMC4yLjM1XAogICAgICAgICAgICAgICZsdDsvaW9kZWY6QWRkcmVz cyZndDtcCiAgICAgICAgICAgICZsdDsvaW9kZWY6Tm9kZSZndDtcCiAgICAgICAgICAgICZsdDtp b2RlZjpTZXJ2aWNlJmd0O1wKICAgICAgICAgICAgICAmbHQ7aW9kZWY6cG9ydCZndDs0MTQyMSZs dDsvaW9kZWY6cG9ydCZndDtcCiAgICAgICAgICAgICZsdDsvaW9kZWY6U2VydmljZSZndDtcCiAg ICAgICAgICAmbHQ7L2lvZGVmOlN5c3RlbSZndDtcCiAgICAgICAgICAmbHQ7aW9kZWY6U3lzdGVt IGNhdGVnb3J5PSJ0YXJnZXQiJmd0O1wKICAgICAgICAgICAgJmx0O2lvZGVmOk5vZGUmZ3Q7XAog ICAgICAgICAgICAgICZsdDtpb2RlZjpBZGRyZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiJmd0OzE5 Mi4wLjIuNjdcCiAgICAgICAgICAgICAgJmx0Oy9pb2RlZjpBZGRyZXNzJmd0O1wKICAgICAgICAg ICAgJmx0Oy9pb2RlZjpOb2RlJmd0O1wKICAgICAgICAgICAgJmx0O2lvZGVmOlNlcnZpY2UmZ3Q7 XAogICAgICAgICAgICAgICZsdDtpb2RlZjpwb3J0Jmd0OzgwJmx0Oy9pb2RlZjpwb3J0Jmd0O1wK ICAgICAgICAgICAgJmx0Oy9pb2RlZjpTZXJ2aWNlJmd0O1wKICAgICAgICAgICZsdDsvaW9kZWY6 U3lzdGVtJmd0O1wKICAgICAgICAmbHQ7L2lvZGVmOkZsb3cmZ3Q7XAogICAgICAgICZsdDtpb2Rl ZjpFeHBlY3RhdGlvbiBzZXZlcml0eT0iaGlnaCIgYWN0aW9uPSJpbnZlc3RpZ2F0ZSImZ3Q7XAog ICAgICAgICAgJmx0O2lvZGVmOkRlc2NyaXB0aW9uJmd0O1wKICAgICAgICAgICAgSW52ZXN0aWdh dGUgd2hldGhlciBzb3VyY2UgaGFzIGJlZW4gY29tcHJvbWlzZWRcCiAgICAgICAgICAmbHQ7L2lv ZGVmOkRlc2NyaXB0aW9uJmd0O1wKICAgICAgICAmbHQ7L2lvZGVmOkV4cGVjdGF0aW9uJmd0O1wK ICAgICAgJmx0Oy9pb2RlZjpFdmVudERhdGEmZ3Q7XAogICAgICAmbHQ7aW9kZWY6SGlzdG9yeSZn dDtcCiAgICAgICAgJmx0O2lvZGVmOkhpc3RvcnlJdGVtJmd0O1wKICAgICAgICAgICZsdDtpb2Rl ZjpEYXRlVGltZSZndDsyMDA0LTAyLTA1VDA4OjE5OjAxKzAwOjAwJmx0Oy9pb2RlZjpEYXRlVGlt ZSZndDtcCiAgICAgICAgICAmbHQ7aW9kZWY6SW5jaWRlbnRJRCBuYW1lPSJDU0lSVC1GT1ItT1VS LURPTUFJTiImZ3Q7XAogICAgICAgICAgICBDU0lSVC1GT1ItT1VSLURPTUFJTiMyMDgtMVwKICAg ICAgICAgICZsdDsvaW9kZWY6SW5jaWRlbnRJRCZndDtcCiAgICAgICAgICAmbHQ7aW9kZWY6RGVz Y3JpcHRpb24mZ3Q7XAogICAgICAgICAgICBJbnZlc3RpZ2F0aW9uIHJlcXVlc3Qgc2VudCB0byBT UCBmb3IgMTkyLjAuMi4zNVwKICAgICAgICAgICZsdDsvaW9kZWY6RGVzY3JpcHRpb24mZ3Q7XAog ICAgICAgICZsdDsvaW9kZWY6SGlzdG9yeUl0ZW0mZ3Q7XAogICAgICAmbHQ7L2lvZGVmOkhpc3Rv cnkmZ3Q7XAogICAgJmx0Oy9pb2RlZjpJbmNpZGVudCZndDtcCiAgJmx0Oy9pb2RlZjpJT0RFRi1E b2N1bWVudCZndDtcClwKNS4yLjIuICBSZXF1ZXN0QXV0aG9yaXphdGlvbiBNZXNzYWdlIEV4YW1w bGVcClwKICAgVGhlIGV4YW1wbGUgUmVxdWVzdEF1dGhvcml6YXRpb24gbWVzc2FnZSBpcyBpbiBy ZXNwb25zZSB0byB0aGVcCiAgIEludmVzdGlnYXRpb24gcmVxdWVzdCBsaXN0ZWQgYWJvdmUuICBU aGUgU1AgdGhhdCByZWNlaXZlZCB0aGUgcmVxdWVzdFwKICAgd2FzIHVuYWJsZSB0byB2YWxpZGF0 ZSB0aGUgZGlnaXRhbCBzaWduYXR1cmUgdXNlZCB0byBhdXRoZW50aWNhdGUgdGhlXAogICBzZW5k aW5nIFJJRCBzeXN0ZW0uXApcClwKXApcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQxXVwKXApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVn dXN0IDIwMTFcClwKXAogICAmbHQ7aW9kZWYtcmlkOlJJRCB4bWxuczppb2RlZi1yaWQ9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtcmlkLTEuMCJcCiAgICAgICAgICAgICAgICAgIHhtbG5z OmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCImZ3Q7XAogICAgICZsdDtp b2RlZi1yaWQ6UklEUG9saWN5IE1zZ1R5cGU9IlJlcXVlc3RBdXRob3JpemF0aW9uIlwKICAgICAg ICAgICAgICAgICAgICAgICAgICBNc2dEZXN0aW5hdGlvbj0iUklEU3lzdGVtIiZndDtcCiAgICAg ICAmbHQ7aW9kZWYtcmlkOlBvbGljeVJlZ2lvbiByZWdpb249IkludHJhQ29uc29ydGl1bSIvJmd0 O1wKICAgICAgICZsdDtpb2RlZjpOb2RlJmd0O1wKICAgICAgICAgJmx0O2lvZGVmOkFkZHJlc3Mg Y2F0ZWdvcnk9ImlwdjQtYWRkciImZ3Q7MTkyLjAuMi42NyZsdDsvaW9kZWY6QWRkcmVzcyZndDtc CiAgICAgICAmbHQ7L2lvZGVmOk5vZGUmZ3Q7XAogICAgICAgJmx0O2lvZGVmLXJpZDpUcmFmZmlj VHlwZSB0eXBlPSJBdHRhY2siLyZndDtcCiAgICAgICAmbHQ7aW9kZWY6SW5jaWRlbnRJRCBuYW1l PSJDRVJULUZPUi1PVVItRE9NQUlOIiZndDtcCiAgICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4j MjA4LTFcCiAgICAgICAmbHQ7L2lvZGVmOkluY2lkZW50SUQmZ3Q7XAogICAgICZsdDsvaW9kZWYt cmlkOlJJRFBvbGljeSZndDtcCiAgICAgJmx0O2lvZGVmLXJpZDpSZXF1ZXN0U3RhdHVzIEF1dGhv cml6YXRpb25TdGF0dXM9IkRlbmllZCJcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1 c3RpZmljYXRpb249IkF1dGhlbnRpY2F0aW9uIi8mZ3Q7XAogICAmbHQ7L2lvZGVmLXJpZDpSSUQm Z3Q7XApcCjUuMy4gIFJlcG9ydCBDb21tdW5pY2F0aW9uIEZsb3dcClwKICAgVGhlIGRpYWdyYW0g YmVsb3cgb3V0bGluZXMgdGhlIFJJRCBSZXBvcnQgY29tbXVuaWNhdGlvbiBmbG93IGJldHdlZW5c CiAgIFJJRCBzeXN0ZW1zIG9uIGRpZmZlcmVudCBuZXR3b3Jrcy5cClwKICAgICAgICAgICBTUC0x ICAgICAgICAgICAgICAgICAgICAgICAgICAgU1AtMlwKXAogICAgICAgIDEuIEdlbmVyYXRlIGlu Y2lkZW50IGluZm9ybWF0aW9uXAogICAgICAgICAgIGFuZCBwcmVwYXJlIFJlcG9ydCBtZXNzYWdl XApcCiAgICAgICAgMi4gICAgICAgICAgICAgIG8tLS0tLS0tUmVwb3J0LS0tLS0tLSZndDtcClwK ICAgICAgICAzLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpbGUgcmVwb3J0IGluIGRh dGFiYXNlXApcClwKICAgICAgICAgICAgICAgICAgICBGaWd1cmUgOTogUmVwb3J0IENvbW11bmlj YXRpb24gRmxvd1wKXAogICBUaGUgUmVwb3J0IGNvbW11bmljYXRpb24gZmxvdyBpcyB1c2VkIHRv IHByb3ZpZGUgaW5mb3JtYXRpb24gb25cCiAgIHNwZWNpZmljIGluY2lkZW50cyBkZXRlY3RlZCBv biB0aGUgbmV0d29yay4gIEluY2lkZW50IGluZm9ybWF0aW9uIG1heVwKICAgYmUgc2hhcmVkIGJl dHdlZW4gQ1NJUlRzIG9yIHBhcnRpY2lwYXRpbmcgUklEIGhvc3RzIHVzaW5nIHRoaXNcCiAgIGZv cm1hdC4gIFdoZW4gYSByZXBvcnQgaXMgcmVjZWl2ZWQsIHRoZSBSSUQgc3lzdGVtIG11c3QgdmVy aWZ5IHRoYXRcCiAgIHRoZSByZXBvcnQgaGFzIG5vdCBhbHJlYWR5IGJlZW4gZmlsZWQuICBUaGUg aW5jaWRlbnQgbnVtYmVyIGFuZFwKICAgaW5jaWRlbnQgZGF0YSwgc3VjaCBhcyB0aGUgaGV4YWRl Y2ltYWwgcGFja2V0IGFuZCBpbmNpZGVudCBjbGFzc1wKICAgaW5mb3JtYXRpb24sIGNhbiBiZSB1 c2VkIHRvIGNvbXBhcmUgd2l0aCBleGlzdGluZyBkYXRhYmFzZSBlbnRyaWVzLlwKICAgVGhlIFJl cG9ydCBtZXNzYWdlIHR5cGljYWxseSBkb2VzIG5vdCBoYXZlIGEgcmVzcG9uc2UuICBJZiB0aGVy ZSBpcyBhXAogICBwcm9ibGVtIHdpdGggdGhlIFJlcG9ydCBtZXNzYWdlLCBzdWNoIGFzIGEgZmFp bHVyZSB0byB2YWxpZGF0ZSB0aGVcCiAgIGRpZ2l0YWwgc2lnbmF0dXJlIFtSRkMzMjc1XSBvciBk ZWNyeXB0IHRoZSByZXF1ZXN0LCBhXAogICBSZXF1ZXN0QXV0aG9yaXphdGlvbiBtZXNzYWdlIGlz IHNlbnQgdG8gdGhlIHJlcXVlc3Rvci4gIFRoZVwKICAgUmVxdWVzdEF1dGhvcml6YXRpb24gbWVz c2FnZSBzaG91bGQgcHJvdmlkZSB0aGUgcmVhc29uIHdoeSB0aGVcCiAgIG1lc3NhZ2UgY291bGQg bm90IGJlIHByb2Nlc3NlZC5cClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNDJdXApcCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3Qg MjAxMVwKXApcCjUuMy4xLiAgUmVwb3J0IEV4YW1wbGVcClwKICAgVGhlIGZvbGxvd2luZyBleGFt cGxlIG9ubHkgaW5jbHVkZXMgdGhlIFJJRC1zcGVjaWZpYyBkZXRhaWxzLiAgVGhpc1wKICAgcmVw b3J0IGlzIGFuIHVuc29saWNpdGVkIFJlcG9ydCBtZXNzYWdlIHRoYXQgaW5jbHVkZXMgYW4gSVB2 NCBwYWNrZXQuXAogICBUaGUgSU9ERUYgZG9jdW1lbnQgYW5kIGRpZ2l0YWwgc2lnbmF0dXJlIHdv dWxkIGJlIHNpbWlsYXIgdG8gdGhlXAogICBUcmFjZVJlcXVlc3QgaW5mb3JtYXRpb24uXApcCiAg ICZsdDtpb2RlZi1yaWQ6UklEIHhtbG5zOmlvZGVmLXJpZD0idXJuOmlldGY6cGFyYW1zOnhtbDpu czppb2RlZi1yaWQtMS4wIlwKICAgICAgICAgICAgICAgICAgeG1sbnM6aW9kZWY9InVybjppZXRm OnBhcmFtczp4bWw6bnM6aW9kZWYtMS4wIiZndDtcCiAgICAgJmx0O2lvZGVmLXJpZDpSSURQb2xp Y3kgTXNnVHlwZT0iUmVwb3J0IiBNc2dEZXN0aW5hdGlvbj0iUklEU3lzdGVtIiZndDtcCiAgICAg ICAmbHQ7aW9kZWYtcmlkOlBvbGljeVJlZ2lvbiByZWdpb249IlBlZXJUb1BlZXIiLyZndDtcCiAg ICAgICAmbHQ7aW9kZWY6Tm9kZSZndDtcCiAgICAgICAgICZsdDtpb2RlZjpBZGRyZXNzIGNhdGVn b3J5PSJpcHY0LWFkZHIiJmd0OzE5Mi4wLjIuMTMwJmx0Oy9pb2RlZjpBZGRyZXNzJmd0O1wKICAg ICAgICZsdDsvaW9kZWY6Tm9kZSZndDtcCiAgICAgICAmbHQ7aW9kZWYtcmlkOlRyYWZmaWNUeXBl IHR5cGU9IkF0dGFjayIvJmd0O1wKICAgICAgICZsdDtpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNF UlQtRk9SLU9VUi1ET01BSU4iJmd0O1wKICAgICAgICAgQ0VSVC1GT1ItT1VSLURPTUFJTiMyMDkt MVwKICAgICAgICZsdDsvaW9kZWY6SW5jaWRlbnRJRCZndDtcCiAgICAgJmx0Oy9pb2RlZi1yaWQ6 UklEUG9saWN5Jmd0O1wKICAgJmx0Oy9pb2RlZi1yaWQ6UklEJmd0O1wKXAogICAmbHQ7IS0tIElP REVGLURvY3VtZW50IGFjY29tcGFuaWVkIGJ5IHRoZSBhYm92ZSBSSUQgLS0mZ3Q7XApcCiAgICZs dDtpb2RlZjpJT0RFRi1Eb2N1bWVudCB2ZXJzaW9uPSIxLjAwIlwKICAgICAgICAgICAgICAgICAg ICAgICAgIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCImZ3Q7 XAogICAgICZsdDtpb2RlZjpJbmNpZGVudCByZXN0cmljdGlvbj0ibmVlZC10by1rbm93IiBwdXJw b3NlPSJyZXBvcnRpbmciJmd0O1wKICAgICAgICZsdDtpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNF UlQtRk9SLU9VUi1ET01BSU4iJmd0O1wKICAgICAgICAgQ0VSVC1GT1ItT1VSLURPTUFJTiMyMDkt MVwKICAgICAgICZsdDsvaW9kZWY6SW5jaWRlbnRJRCZndDtcCiAgICAgICAmbHQ7aW9kZWY6RGV0 ZWN0VGltZSZndDsyMDA0LTAyLTA1VDEwOjIxOjA4KzAwOjAwJmx0Oy9pb2RlZjpEZXRlY3RUaW1l Jmd0O1wKICAgICAgICZsdDtpb2RlZjpTdGFydFRpbWUmZ3Q7MjAwNC0wMi0wNVQxMDoyMTowNSsw MDowMCZsdDsvaW9kZWY6U3RhcnRUaW1lJmd0O1wKICAgICAgICZsdDtpb2RlZjpFbmRUaW1lJmd0 OzIwMDQtMDItMDVUMTA6MzU6MDArMDA6MDAmbHQ7L2lvZGVmOkVuZFRpbWUmZ3Q7XAogICAgICAg Jmx0O2lvZGVmOlJlcG9ydFRpbWUmZ3Q7MjAwNC0wMi0wNVQxMDoyNzozOCswMDowMCZsdDsvaW9k ZWY6UmVwb3J0VGltZSZndDtcCiAgICAgICAmbHQ7aW9kZWY6RGVzY3JpcHRpb24mZ3Q7SG9zdCBp bGxpY2l0bHkgYWNjZXNzZWQgYWRtaW4gYWNjb3VudFwKICAgICAgICZsdDsvaW9kZWY6RGVzY3Jp cHRpb24mZ3Q7XAogICAgICAgJmx0O2lvZGVmOkFzc2Vzc21lbnQmZ3Q7XAogICAgICAgICAmbHQ7 aW9kZWY6SW1wYWN0IHNldmVyaXR5PSJoaWdoIiBjb21wbGV0aW9uPSJzdWNjZWVkZWQiXAogICAg ICAgICAgICAgICAgICAgICAgIHR5cGU9ImFkbWluIi8mZ3Q7XAogICAgICAgICAmbHQ7aW9kZWY6 Q29uZmlkZW5jZSByYXRpbmc9ImhpZ2giLyZndDtcCiAgICAgICAmbHQ7L2lvZGVmOkFzc2Vzc21l bnQmZ3Q7XAogICAgICAgJmx0O2lvZGVmOkNvbnRhY3Qgcm9sZT0iY3JlYXRvciIgdHlwZT0ib3Jn YW5pemF0aW9uIiZndDtcCiAgICAgICAgICZsdDtpb2RlZjpDb250YWN0TmFtZSZndDtDb25zdGl0 dWVuY3ktY29udGFjdCBmb3IgMTkyLjAuMi4zNVwKICAgICAgICAgJmx0Oy9pb2RlZjpDb250YWN0 TmFtZSZndDtcCiAgICAgICAgICZsdDtpb2RlZjpFbWFpbCZndDtDb25zdGl0dWVuY3ktY29udGFj dEAxMC4xLjEuMiZsdDsvaW9kZWY6RW1haWwmZ3Q7XAogICAgICAgJmx0Oy9pb2RlZjpDb250YWN0 Jmd0O1wKICAgICAgICZsdDtpb2RlZjpFdmVudERhdGEmZ3Q7XAogICAgICAgICAmbHQ7aW9kZWY6 RmxvdyZndDtcCiAgICAgICAgICAgJmx0O2lvZGVmOlN5c3RlbSBjYXRlZ29yeT0ic291cmNlIiZn dDtcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIw MTIgICAgICAgICAgICAgIFtQYWdlIDQzXVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICAg ICAgICAgJmx0O2lvZGVmOk5vZGUmZ3Q7XAogICAgICAgICAgICAgICAmbHQ7aW9kZWY6QWRkcmVz cyBjYXRlZ29yeT0iaXB2NC1hZGRyIiZndDsxOTIuMC4yLjM1XAogICAgICAgICAgICAgICAmbHQ7 L2lvZGVmOkFkZHJlc3MmZ3Q7XAogICAgICAgICAgICAgJmx0Oy9pb2RlZjpOb2RlJmd0O1wKICAg ICAgICAgICAgICZsdDtpb2RlZjpTZXJ2aWNlJmd0O1wKICAgICAgICAgICAgICAgJmx0O2lvZGVm OnBvcnQmZ3Q7MzI4MjEmbHQ7L2lvZGVmOnBvcnQmZ3Q7XAogICAgICAgICAgICAgJmx0Oy9pb2Rl ZjpTZXJ2aWNlJmd0O1wKICAgICAgICAgICAmbHQ7L2lvZGVmOlN5c3RlbSZndDtcCiAgICAgICAg ICAgJmx0O2lvZGVmOlN5c3RlbSBjYXRlZ29yeT0idGFyZ2V0IiZndDtcCiAgICAgICAgICAgICAm bHQ7aW9kZWY6Tm9kZSZndDtcCiAgICAgICAgICAgICAgICZsdDtpb2RlZjpBZGRyZXNzIGNhdGVn b3J5PSJpcHY0LWFkZHIiJmd0OzE5Mi4wLjIuNjdcCiAgICAgICAgICAgICAgICZsdDsvaW9kZWY6 QWRkcmVzcyZndDtcCiAgICAgICAgICAgICAmbHQ7L2lvZGVmOk5vZGUmZ3Q7XAogICAgICAgICAg ICAgJmx0O2lvZGVmOlNlcnZpY2UmZ3Q7XAogICAgICAgICAgICAgICAmbHQ7aW9kZWY6cG9ydCZn dDsyMiZsdDsvaW9kZWY6cG9ydCZndDtcCiAgICAgICAgICAgICAmbHQ7L2lvZGVmOlNlcnZpY2Um Z3Q7XAogICAgICAgICAgICZsdDsvaW9kZWY6U3lzdGVtJmd0O1wKICAgICAgICAgJmx0Oy9pb2Rl ZjpGbG93Jmd0O1wKICAgICAgICZsdDsvaW9kZWY6RXZlbnREYXRhJmd0O1wKICAgICAgICZsdDtp b2RlZjpIaXN0b3J5Jmd0O1wKICAgICAgICAgJmx0O2lvZGVmOkhpc3RvcnlJdGVtJmd0O1wKICAg ICAgICAgICAmbHQ7aW9kZWY6RGF0ZVRpbWUmZ3Q7MjAwNC0wMi0wNVQxMDoyODowMCswMDowMCZs dDsvaW9kZWY6RGF0ZVRpbWUmZ3Q7XAogICAgICAgICAgICZsdDtpb2RlZjpJbmNpZGVudElEIG5h bWU9IkNTSVJULUZPUi1PVVItRE9NQUlOIiZndDtcCiAgICAgICAgICAgICBDU0lSVC1GT1ItT1VS LURPTUFJTiMyMDktMVwKICAgICAgICAgICAmbHQ7L2lvZGVmOkluY2lkZW50SUQmZ3Q7XAogICAg ICAgICAgICZsdDtpb2RlZjpEZXNjcmlwdGlvbiZndDtcCiAgICAgICAgICAgICBJbmNpZGVudCBy ZXBvcnQgc2VudCB0byBTUCBmb3IgMTkyLjAuMi4zNVwKICAgICAgICAgICAmbHQ7L2lvZGVmOkRl c2NyaXB0aW9uJmd0O1wKICAgICAgICAgJmx0Oy9pb2RlZjpIaXN0b3J5SXRlbSZndDtcCiAgICAg ICAmbHQ7L2lvZGVmOkhpc3RvcnkmZ3Q7XAogICAgICZsdDsvaW9kZWY6SW5jaWRlbnQmZ3Q7XAog ICAmbHQ7L2lvZGVmOklPREVGLURvY3VtZW50Jmd0O1wKXAo1LjQuICBJbmNpZGVudFF1ZXJ5IENv bW11bmljYXRpb24gRmxvd1wKXAogICBUaGUgZGlhZ3JhbSBiZWxvdyBvdXRsaW5lcyB0aGUgUklE IEluY2lkZW50UXVlcnkgY29tbXVuaWNhdGlvbiBmbG93XAogICBiZXR3ZWVuIFJJRCBzeXN0ZW1z IG9uIGRpZmZlcmVudCBuZXR3b3Jrcy5cClwKXApcClwKXApcClwKXApcClwKXApcClwKXApNb3Jp YXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAg ICBbUGFnZSA0NF1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlz ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgICAgICBTUC0xICAgICAg ICAgICAgICAgICAgICAgICAgICAgU1AtMlwKXAogICAgICAgIDEuIEdlbmVyYXRlIGEgcmVxdWVz dCBmb3JcCiAgICAgICAgICAgaW5mb3JtYXRpb24gb24gYSBzcGVjaWZpY1wKICAgICAgICAgICBp bmNpZGVudCBudW1iZXIgb3IgaW5jaWRlbnQgdHlwZVwKXAogICAgICAgIDIuICAgICAgICAgICAg ICBvLS0tSW5jaWRlbnRRdWVyeS0tLSZndDtcClwKICAgICAgICAzLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFZlcmlmeSBwb2xpY3kgaW5mb3JtYXRpb25cCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBhbmQgZGV0ZXJtaW5lIGlmIG1hdGNoZXMgZXhpc3RcCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgcmVxdWVzdGVkIGluZm9y bWF0aW9uXApcCiAgICAgICAgNC4gICAgICAgICAgICAgICZsdDstLS0tLS0tUmVwb3J0LS0tLS0t b1wKXAogICAgICAgIDUuICBBc3NvY2lhdGUgcmVwb3J0IHRvIHJlcXVlc3RcCiAgICAgICAgICAg IGJ5IGluY2lkZW50IG51bWJlciBvciB0eXBlXAogICAgICAgICAgICBhbmQgZmlsZSByZXBvcnQo cykuXApcCiAgICAgICAgICAgICAgICBGaWd1cmUgMTA6IEluY2lkZW50UXVlcnkgQ29tbXVuaWNh dGlvbiBGbG93XApcCiAgIFRoZSBJbmNpZGVudFF1ZXJ5IG1lc3NhZ2UgY29tbXVuaWNhdGlvbiBy ZWNlaXZlcyBhIHJlc3BvbnNlIG9mIGFcCiAgIFJlcG9ydCBtZXNzYWdlLiAgSWYgdGhlIFJlcG9y dCBtZXNzYWdlIGlzIGVtcHR5LCB0aGUgcmVzcG9uZGluZyBob3N0XAogICBkaWQgbm90IGhhdmUg aW5mb3JtYXRpb24gYXZhaWxhYmxlIHRvIHNoYXJlIHdpdGggdGhlIHJlcXVlc3Rvci4gIFRoZVwK ICAgaW5jaWRlbnQgbnVtYmVyIGFuZCByZXNwb25kaW5nIFJJRCBzeXN0ZW0sIGFzIHdlbGwgYXMg dGhlIHRyYW5zcG9ydCxcCiAgIGFzc2lzdCBpbiB0aGUgYXNzb2NpYXRpb24gb2YgdGhlIHJlcXVl c3QgYW5kIHJlc3BvbnNlIHNpbmNlIGEgcmVwb3J0XAogICBjYW4gYmUgZmlsZWQgYW5kIGlzIG5v dCBhbHdheXMgc29saWNpdGVkLiAgSWYgdGhlcmUgaXMgYSBwcm9ibGVtIHdpdGhcCiAgIHRoZSBJ bmNpZGVudFF1ZXJ5IG1lc3NhZ2UsIHN1Y2ggYXMgYSBmYWlsdXJlIHRvIHZhbGlkYXRlIHRoZSBk aWdpdGFsXAogICBzaWduYXR1cmUgb3IgZGVjcnlwdCB0aGUgcmVxdWVzdCwgYSBSZXF1ZXN0QXV0 aG9yaXphdGlvbiBtZXNzYWdlIGlzXAogICBzZW50IHRvIHRoZSByZXF1ZXN0b3IuICBUaGUgUmVx dWVzdEF1dGhvcml6YXRpb24gbWVzc2FnZSBzaG91bGRcCiAgIHByb3ZpZGUgdGhlIHJlYXNvbiB3 aHkgdGhlIG1lc3NhZ2UgY291bGQgbm90IGJlIHByb2Nlc3NlZC5cClwKNS40LjEuICBJbmNpZGVu dFF1ZXJ5IEV4YW1wbGVcClwKICAgVGhlIEluY2lkZW50UXVlcnkgcmVxdWVzdCBtYXkgYmUgcmVj ZWl2ZWQgaW4gc2V2ZXJhbCBmb3JtYXRzIGFzIGFcCiAgIHJlc3VsdCBvZiB0aGUgdHlwZSBvZiBx dWVyeSBiZWluZyBwZXJmb3JtZWQuICBJZiB0aGUgaW5jaWRlbnQgbnVtYmVyXAogICBpcyB0aGUg b25seSBpbmZvcm1hdGlvbiBwcm92aWRlZCwgdGhlIElPREVGIGRvY3VtZW50IGFuZCBJUCBwYWNr ZXRcCiAgIGRhdGEgbWF5IG5vdCBiZSBuZWVkZWQgdG8gY29tcGxldGUgdGhlIHJlcXVlc3QuICBI b3dldmVyLCBpZiBhIHR5cGVcCiAgIG9mIGluY2lkZW50IGlzIHJlcXVlc3RlZCwgdGhlIGluY2lk ZW50IG51bWJlciByZW1haW5zIE5VTEwsIGFuZCB0aGVcCiAgIElQIHBhY2tldCBkYXRhIHdpbGwg bm90IGJlIGluY2x1ZGVkIGluIHRoZSBJT0RFRiBSZWNvcmRJdGVtIGNsYXNzO1wKICAgdGhlIG90 aGVyIGluY2lkZW50IGluZm9ybWF0aW9uIGlzIHRoZSBtYWluIHNvdXJjZSBmb3IgY29tcGFyaXNv bi4gIEluXAogICB0aGUgY2FzZSBpbiB3aGljaCBhbiBpbmNpZGVudCBudW1iZXIgbWF5IG5vdCBi ZSB0aGUgc2FtZSBiZXR3ZWVuXAogICBDU0lSVHMsIHRoZSBpbmNpZGVudCBudW1iZXIgYW5kL29y IElQIHBhY2tldCBpbmZvcm1hdGlvbiBjYW4gYmVcCiAgIHByb3ZpZGVkIGFuZCB1c2VkIGZvciBj b21wYXJpc29uIG9uIHRoZSByZWNlaXZpbmcgUklEIHN5c3RlbSB0b1wKICAgZ2VuZXJhdGUgKGEp IFJlcG9ydCBtZXNzYWdlKHMpLlwKXApcClwKXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0NV1cClwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDExXApcClwKICAgJmx0O2lvZGVmLXJpZDpSSUQgeG1sbnM6aW9kZWYtcmlkPSJ1 cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0xLjAiXAogICAgICAgICAgICAgICAgICB4 bWxuczppb2RlZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiJmd0O1wKICAgICAm bHQ7aW9kZWYtcmlkOlJJRFBvbGljeSBNc2dUeXBlPSJJbmNpZGVudFF1ZXJ5IlwKICAgICAgICAg ICAgICAgICAgICAgICAgICBNc2dEZXN0aW5hdGlvbj0iUklEU3lzdGVtIiZndDtcCiAgICAgICAm bHQ7aW9kZWYtcmlkOlBvbGljeVJlZ2lvbiByZWdpb249IlBlZXJUb1BlZXIiLyZndDtcCiAgICAg ICAmbHQ7aW9kZWY6Tm9kZSZndDtcCiAgICAgICAgICZsdDtpb2RlZjpBZGRyZXNzIGNhdGVnb3J5 PSJpcHY0LWFkZHIiJmd0OzE5Mi4wLjIuMyZsdDsvaW9kZWY6QWRkcmVzcyZndDtcCiAgICAgICAm bHQ7L2lvZGVmOk5vZGUmZ3Q7XAogICAgICAgJmx0O2lvZGVmLXJpZDpUcmFmZmljVHlwZSB0eXBl PSJBdHRhY2siLyZndDtcCiAgICAgICAmbHQ7aW9kZWY6SW5jaWRlbnRJRCBuYW1lPSJDRVJULUZP Ui1PVVItRE9NQUlOIiZndDtcCiAgICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjEwLTFcCiAg ICAgICAmbHQ7L2lvZGVmOkluY2lkZW50SUQmZ3Q7XAogICAgICZsdDsvaW9kZWYtcmlkOlJJRFBv bGljeSZndDtcCiAgICZsdDsvaW9kZWYtcmlkOlJJRCZndDtcClwKXAo2LiAgUklEIFNjaGVtYSBE ZWZpbml0aW9uXApcCiAmbHQ7P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0 O1wKICZsdDt4czpzY2hlbWEgeG1sbnM6aW9kZWYtcmlkPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z OmlvZGVmLXJpZC0xLjAiXAogIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlv ZGVmLTEuMCJcCiAgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIlwK ICB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyJcCiAgdGFyZ2V0 TmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0xLjAiXAogIGVsZW1l bnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIiBhdHRyaWJ1dGVGb3JtRGVmYXVsdD0idW5xdWFsaWZp ZWQiJmd0O1wKICZsdDt4czppbXBvcnQgbmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z OmlvZGVmLTEuMCJcCiAgc2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMveG1sLXJlZ2lzdHJ5L1wKICBzY2hlbWEvaW9kZWYtcmlkLTEuMC54c2QiLyZndDtcClwK ICZsdDt4czppbXBvcnQgbmFtZXNwYWNlPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRz aWcjIlwKICBzY2hlbWFMb2NhdGlvbj1cCiAgImh0dHA6Ly93d3cudzMub3JnL1RSL3htbGRzaWct Y29yZS94bWxkc2lnLWNvcmUtc2NoZW1hLnhzZCIvJmd0O1wKXAogJmx0OyEtLSAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqXAog KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqXAogKioqICBSZWFsLXRpbWUgSW50ZXItbmV0d29yayBEZWZlbnNlIC0gUklE IFhNTCBTY2hlbWEgICAgICAgICAgICAgKioqXAogKioqICAgIE5hbWVzcGFjZSAtIGlvZGVmLXJp ZCwgQXVndXN0IDIwMTEgICAgICAgICAgICAgICAgICAgICAgICAgKioqXAogKioqICAgIFRoZSBu YW1lc3BhY2UgaXMgZGVmaW5lZCB0byBzdXBwb3J0IHRyYW5zcG9ydCBvZiBJT0RFRiAgICAgKioq XAogKioqICAgICBkb2N1bWVudHMgZm9yIGV4Y2hhbmdpbmcgaW5jaWRlbnQgaW5mb3JtYXRpb24u ICAgICAgICAgICAgKioqXAogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqXAogLS0mZ3Q7XAogJmx0OyEtLVJJRCBhY3Rz IGFzIGFuIGVudmVsb3BlIGZvciBJT0RFRiBkb2N1bWVudHMgdG8gc3VwcG9ydCB0aGUgZXhjaGFu Z2VcCiAgICAgb2YgbWVzc2FnZXMtLSZndDtcCiAmbHQ7IS0tXAogPT09PT09IFJlYWwtVGltZSBJ bnRlci1uZXR3b3JrIERlZmVuc2UgLSBSSUQgPT09PT09XAogPT09PSAgU3VnZ2VzdGVkIGRlZmlu aXRpb24gZm9yIFJJRCBtZXNzYWdpbmcgPT09PT09XAogIC0tJmd0O1wKXApcClwKXApNb3JpYXJ0 eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBb UGFnZSA0Nl1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAg ICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICZsdDt4czphbm5vdGF0aW9uJmd0O1wK ICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7WE1MIFNjaGVtYSB3cmFwcGVyIGZvciBJT0RFRiZs dDsveHM6ZG9jdW1lbnRhdGlvbiZndDtcCiAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7XAogJmx0O3hz OmVsZW1lbnQgbmFtZT0iUklEIiB0eXBlPSJpb2RlZi1yaWQ6UklEVHlwZSIvJmd0O1wKICAgJmx0 O3hzOmNvbXBsZXhUeXBlIG5hbWU9IlJJRFR5cGUiJmd0O1wKICAgICAmbHQ7eHM6c2VxdWVuY2Um Z3Q7XAogICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJpb2RlZi1yaWQ6UklEUG9saWN5IiBtaW5P Y2N1cnM9IjAiLyZndDtcCiAgICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9ImlvZGVmLXJpZDpSZXF1 ZXN0U3RhdHVzIiBtaW5PY2N1cnM9IjAiLyZndDtcCiAgICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9 ImlvZGVmLXJpZDpJbmNpZGVudFNvdXJjZSIgbWluT2NjdXJzPSIwIi8mZ3Q7XAogICAgICZsdDsv eHM6c2VxdWVuY2UmZ3Q7XAogICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0O1wKXAogJmx0OyEtLVVz ZWQgaW4gUmVxdWVzdEF1dGhvcml6YXRpb24gTWVzc2FnZSBmb3IgUklELS0mZ3Q7XApcCiAmbHQ7 eHM6ZWxlbWVudCBuYW1lPSJSZXF1ZXN0U3RhdHVzIiB0eXBlPSJpb2RlZi1yaWQ6UmVxdWVzdFN0 YXR1c1R5cGUiLyZndDtcCiAgICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJSZXF1ZXN0U3RhdHVz VHlwZSImZ3Q7XAogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9IkF1dGhvcml6YXRpb25TdGF0 dXMiIHVzZT0icmVxdWlyZWQiJmd0O1wKICAgICAgICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7XAog ICAgICAgICAgICZsdDt4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpOTVRPS0VOIiZndDtcCiAgICAg ICAgICAgJmx0O3hzOndoaXRlU3BhY2UgdmFsdWU9ImNvbGxhcHNlIi8mZ3Q7XAogICAgICAgICAg ICAgJmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJBcHByb3ZlZCIvJmd0O1wKICAgICAgICAgICAg ICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iRGVuaWVkIi8mZ3Q7XAogICAgICAgICAgICAgJmx0 O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJQZW5kaW5nIi8mZ3Q7XAogICAgICAgICAgICAgJmx0O3hz OmVudW1lcmF0aW9uIHZhbHVlPSJleHQtdmFsdWUiLyZndDtcCiAgICAgICAgICAgJmx0Oy94czpy ZXN0cmljdGlvbiZndDtcCiAgICAgICAgICZsdDsveHM6c2ltcGxlVHlwZSZndDtcCiAgICAgICZs dDsveHM6YXR0cmlidXRlJmd0O1wKICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJleHQtQXV0 aG9yaXphdGlvblN0YXR1cyJcCiAgICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIiB1 c2U9Im9wdGlvbmFsIi8mZ3Q7XAogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9Ikp1c3RpZmlj YXRpb24iJmd0O1wKICAgICAgICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7XAogICAgICAgICAgICZs dDt4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpOTVRPS0VOIiZndDtcCiAgICAgICAgICAgJmx0O3hz OndoaXRlU3BhY2UgdmFsdWU9ImNvbGxhcHNlIi8mZ3Q7XAogICAgICAgICAgICAgJmx0O3hzOmVu dW1lcmF0aW9uIHZhbHVlPSJTeXN0ZW1SZXNvdXJjZSIvJmd0O1wKICAgICAgICAgICAgICZsdDt4 czplbnVtZXJhdGlvbiB2YWx1ZT0iQXV0aGVudGljYXRpb24iLyZndDtcCiAgICAgICAgICAgICAm bHQ7eHM6ZW51bWVyYXRpb24gdmFsdWU9IkF1dGhlbnRpY2F0aW9uT3JpZ2luIi8mZ3Q7XAogICAg ICAgICAgICAgJmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJFbmNyeXB0aW9uIi8mZ3Q7XAogICAg ICAgICAgICAgJmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJPdGhlciIvJmd0O1wKICAgICAgICAg ICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iZXh0LXZhbHVlIi8mZ3Q7XAogICAgICAgICAg ICZsdDsveHM6cmVzdHJpY3Rpb24mZ3Q7XAogICAgICAgICAmbHQ7L3hzOnNpbXBsZVR5cGUmZ3Q7 XAogICAgICAmbHQ7L3hzOmF0dHJpYnV0ZSZndDtcCiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFt ZT0iZXh0LUp1c3RpZmljYXRpb24iXAogICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOnN0cmlu ZyIgdXNlPSJvcHRpb25hbCIvJmd0O1wKICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9InJlc3Ry aWN0aW9uIiB0eXBlPSJpb2RlZjpyZXN0cmljdGlvbi10eXBlIi8mZ3Q7XAogICAmbHQ7L3hzOmNv bXBsZXhUeXBlJmd0O1wKXAogJmx0OyEtLUluY2lkZW50IFNvdXJjZSBJbmZvcm1hdGlvbiBmb3Ig UmVzdWx0IE1lc3NhZ2UtLSZndDtcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQ3XVwKXApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0 IDIwMTFcClwKXAogJmx0O3hzOmVsZW1lbnQgbmFtZT0iSW5jaWRlbnRTb3VyY2UiIHR5cGU9Imlv ZGVmLXJpZDpJbmNpZGVudFNvdXJjZVR5cGUiLyZndDtcCiAgICZsdDt4czpjb21wbGV4VHlwZSBu YW1lPSJJbmNpZGVudFNvdXJjZVR5cGUiJmd0O1wKICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7XAog ICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJpb2RlZi1yaWQ6U291cmNlRm91bmQiLyZndDtcCiAg ICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9ImlvZGVmOk5vZGUiIG1pbk9jY3Vycz0iMCJcCiAgICAg ICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDtcCiAgICAgJmx0Oy94czpzZXF1ZW5jZSZn dDtcCiAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJyZXN0cmljdGlvbiIgdHlwZT0iaW9kZWY6 cmVzdHJpY3Rpb24tdHlwZSIvJmd0O1wKICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDtcCiAgICZs dDt4czplbGVtZW50IG5hbWU9IlNvdXJjZUZvdW5kIiB0eXBlPSJ4czpib29sZWFuIi8mZ3Q7XApc CiAmbHQ7IS0tXAogPT09PT09IFJlYWwtVGltZSBJbnRlci1uZXR3b3JrIERlZmVuc2UgUG9saWN5 IC0gUklEUG9saWN5ID09PT09PVwKID09PT09PSAgRGVmaW5pdGlvbiBmb3IgUklEUG9saWN5IGZv ciBtZXNzYWdpbmdcCiAgLS0mZ3Q7XApcCiAmbHQ7eHM6YW5ub3RhdGlvbiZndDtcCiAgJmx0O3hz OmRvY3VtZW50YXRpb24mZ3Q7UklEIFBvbGljeSB1c2VkIGZvciB0cmFuc3BvcnQgb2ZcCiAgICAg IG1lc3NhZ2VzJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0O1wKICZsdDsveHM6YW5ub3RhdGlvbiZn dDtcClwKICZsdDshLS0gUklEUG9saWN5IGluZm9ybWF0aW9uIHdpdGggc2V0dGluZyBpbmZvcm1h dGlvbiBsaXN0ZWQgaW4gUklEXAogICAgICBkb2N1bWVudGF0aW9uIC0tJmd0O1wKXAogJmx0O3hz OmVsZW1lbnQgbmFtZT0iUklEUG9saWN5IiB0eXBlPSJpb2RlZi1yaWQ6UklEUG9saWN5VHlwZSIv Jmd0O1wKICAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9IlJJRFBvbGljeVR5cGUiJmd0O1wKICAg ICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7XAogICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJpb2RlZi1y aWQ6UG9saWN5UmVnaW9uIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0O1wKICAgICAgICZsdDt4 czplbGVtZW50IHJlZj0iaW9kZWY6Tm9kZSIvJmd0O1wKICAgICAgICZsdDt4czplbGVtZW50IHJl Zj0iaW9kZWYtcmlkOlRyYWZmaWNUeXBlIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0O1wKICAg ICAgICZsdDt4czplbGVtZW50IHJlZj0iaW9kZWY6SW5jaWRlbnRJRCIgbWluT2NjdXJzPSIwIi8m Z3Q7XAogICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7XAogICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1l PSJNc2dUeXBlIiB1c2U9InJlcXVpcmVkIiZndDtcCiAgICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7 XAogICAgICAgJmx0O3hzOnJlc3RyaWN0aW9uIGJhc2U9InhzOk5NVE9LRU4iJmd0O1wKICAgICAg ICZsdDt4czp3aGl0ZVNwYWNlIHZhbHVlPSJjb2xsYXBzZSIvJmd0O1wKICAgICAgICAgJmx0O3hz OmVudW1lcmF0aW9uIHZhbHVlPSJUcmFjZVJlcXVlc3QiLyZndDtcCiAgICAgICAgICZsdDt4czpl bnVtZXJhdGlvbiB2YWx1ZT0iUmVxdWVzdEF1dGhvcml6YXRpb24iLyZndDtcCiAgICAgICAgICZs dDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iUmVzdWx0Ii8mZ3Q7XAogICAgICAgICAmbHQ7eHM6ZW51 bWVyYXRpb24gdmFsdWU9IkludmVzdGlnYXRpb24iLyZndDtcCiAgICAgICAgICZsdDt4czplbnVt ZXJhdGlvbiB2YWx1ZT0iUmVwb3J0Ii8mZ3Q7XAogICAgICAgICAmbHQ7eHM6ZW51bWVyYXRpb24g dmFsdWU9IkluY2lkZW50UXVlcnkiLyZndDtcCiAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2 YWx1ZT0iZXh0LXZhbHVlIi8mZ3Q7XAogICAgICAgJmx0Oy94czpyZXN0cmljdGlvbiZndDtcCiAg ICAgJmx0Oy94czpzaW1wbGVUeXBlJmd0O1wKICAgICZsdDsveHM6YXR0cmlidXRlJmd0O1wKICAg Jmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJleHQtTXNnVHlwZSIgdHlwZT0ieHM6c3RyaW5nIiB1c2U9 Im9wdGlvbmFsIi8mZ3Q7XAogICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9Ik1zZ0Rlc3RpbmF0aW9u IiB1c2U9InJlcXVpcmVkIiZndDtcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQ4XVwKXApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0 IDIwMTFcClwKXAogICAgICZsdDt4czpzaW1wbGVUeXBlJmd0O1wKICAgICAgICZsdDt4czpyZXN0 cmljdGlvbiBiYXNlPSJ4czpOTVRPS0VOIiZndDtcCiAgICAgICAmbHQ7eHM6d2hpdGVTcGFjZSB2 YWx1ZT0iY29sbGFwc2UiLyZndDtcCiAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0i UklEU3lzdGVtIi8mZ3Q7XAogICAgICAgICAmbHQ7eHM6ZW51bWVyYXRpb24gdmFsdWU9IlNvdXJj ZU9mSW5jaWRlbnQiLyZndDtcCiAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iZXh0 LXZhbHVlIi8mZ3Q7XAogICAgICAgJmx0Oy94czpyZXN0cmljdGlvbiZndDtcCiAgICAgJmx0Oy94 czpzaW1wbGVUeXBlJmd0O1wKICAgICZsdDsveHM6YXR0cmlidXRlJmd0O1wKICAgJmx0O3hzOmF0 dHJpYnV0ZSBuYW1lPSJleHQtTXNnRGVzdGluYXRpb24iIHR5cGU9InhzOnN0cmluZyJcCiAgICAg ICAgICAgICAgICAgdXNlPSJvcHRpb25hbCIvJmd0O1wKICAgICZsdDsveHM6Y29tcGxleFR5cGUm Z3Q7XAogICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJQb2xpY3lSZWdpb24iJmd0O1wKICAgICAmbHQ7 eHM6Y29tcGxleFR5cGUmZ3Q7XAogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9InJlZ2lvbiIg dXNlPSJyZXF1aXJlZCImZ3Q7XAogICAgICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7XAogICAgICAg ICZsdDt4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpOTVRPS0VOIiZndDtcCiAgICAgICAgJmx0O3hz OndoaXRlU3BhY2UgdmFsdWU9ImNvbGxhcHNlIi8mZ3Q7XAogICAgICAgICAgJmx0O3hzOmVudW1l cmF0aW9uIHZhbHVlPSJDbGllbnRUb1NQIi8mZ3Q7XAogICAgICAgICAgJmx0O3hzOmVudW1lcmF0 aW9uIHZhbHVlPSJTUFRvQ2xpZW50Ii8mZ3Q7XAogICAgICAgICAgJmx0O3hzOmVudW1lcmF0aW9u IHZhbHVlPSJJbnRyYUNvbnNvcnRpdW0iLyZndDtcCiAgICAgICAgICAmbHQ7eHM6ZW51bWVyYXRp b24gdmFsdWU9IlBlZXJUb1BlZXIiLyZndDtcCiAgICAgICAgICAmbHQ7eHM6ZW51bWVyYXRpb24g dmFsdWU9IkJldHdlZW5Db25zb3J0aXVtcyIvJmd0O1wKICAgICAgICAgICZsdDt4czplbnVtZXJh dGlvbiB2YWx1ZT0iQWNyb3NzTmF0aW9uYWxCb3VuZGFyaWVzIi8mZ3Q7XAogICAgICAgICAgJmx0 O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJMYXdFbmZvcmNlbWVudCIvJmd0O1wKICAgICAgICAgICZs dDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iZXh0LXZhbHVlIi8mZ3Q7XAogICAgICAgICZsdDsveHM6 cmVzdHJpY3Rpb24mZ3Q7XAogICAgICAgJmx0Oy94czpzaW1wbGVUeXBlJmd0O1wKICAgICAgJmx0 Oy94czphdHRyaWJ1dGUmZ3Q7XAogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9ImV4dC1yZWdp b24iXAogICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOnN0cmluZyIgdXNlPSJvcHRpb25hbCIv Jmd0O1wKICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0O1wKICAgJmx0Oy94czplbGVtZW50Jmd0 O1wKICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iVHJhZmZpY1R5cGUiJmd0O1wKICAgICAmbHQ7eHM6 Y29tcGxleFR5cGUmZ3Q7XAogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9InR5cGUiIHVzZT0i cmVxdWlyZWQiJmd0O1wKICAgICAgICZsdDt4czpzaW1wbGVUeXBlJmd0O1wKICAgICAgICAmbHQ7 eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6Tk1UT0tFTiImZ3Q7XAogICAgICAgICZsdDt4czp3aGl0 ZVNwYWNlIHZhbHVlPSJjb2xsYXBzZSIvJmd0O1wKICAgICAgICAgICZsdDt4czplbnVtZXJhdGlv biB2YWx1ZT0iQXR0YWNrIi8mZ3Q7XAogICAgICAgICAgJmx0O3hzOmVudW1lcmF0aW9uIHZhbHVl PSJOZXR3b3JrIi8mZ3Q7XAogICAgICAgICAgJmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJDb250 ZW50Ii8mZ3Q7XAogICAgICAgICAgJmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJPZmZpY2lhbEJ1 c2luZXNzIi8mZ3Q7XAogICAgICAgICAgJmx0O3hzOmVudW1lcmF0aW9uIHZhbHVlPSJPdGhlciIv Jmd0O1wKICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iZXh0LXZhbHVlIi8mZ3Q7 XAogICAgICAgICZsdDsveHM6cmVzdHJpY3Rpb24mZ3Q7XAogICAgICAgJmx0Oy94czpzaW1wbGVU eXBlJmd0O1wKICAgICAgJmx0Oy94czphdHRyaWJ1dGUmZ3Q7XApcClwKXApNb3JpYXJ0eSAgICAg ICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0 OV1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJl eHQtdHlwZSJcCiAgICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIiB1c2U9Im9wdGlv bmFsIi8mZ3Q7XAogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9InJlc3RyaWN0aW9uIiB0eXBl PSJpb2RlZjpyZXN0cmljdGlvbi10eXBlIi8mZ3Q7XAogICAgICZsdDsveHM6Y29tcGxleFR5cGUm Z3Q7XAogICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7XAogJmx0Oy94czpzY2hlbWEmZ3Q7XApcClwKNy4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zXApcCiAgIFJJRCBoYXMgbWFueSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBidWlsdCBpbnRvIHRoZSBkZXNpZ24gb2YgdGhlXAogICBwcm90b2NvbCwgc2V2 ZXJhbCBvZiB3aGljaCBhcmUgZGVzY3JpYmVkIGluIHRoZSBmb2xsb3dpbmcgc3ViLVwKICAgc2Vj dGlvbnMuICBGb3IgYSBjb21wbGV0ZSB2aWV3IG9mIHNlY3VyaXR5LCBjb25zaWRlcmF0aW9ucyBu ZWVkIHRvXAogICBpbmNsdWRlIHRoZSBhdmFpbGFiaWxpdHksIGNvbmZpZGVudGlhbGl0eSwgYW5k IGludGVncml0eSBjb25jZXJucyBmb3JcCiAgIHRoZSB0cmFuc3BvcnQsIHN0b3JhZ2UsIGFuZCBl eGNoYW5nZSBvZiBpbmZvcm1hdGlvbi5cClwKICAgQXV0aGVudGljYXRlZCBlbmNyeXB0ZWQgdHVu bmVscyBiZXR3ZWVuIFJJRCBzeXN0ZW1zIE1VU1QgYmUgdXNlZCB0b1wKICAgcHJvdmlkZSBjb25m aWRlbnRpYWxpdHksIGludGVncml0eSwgYXV0aGVudGljaXR5LCBhbmQgcHJpdmFjeSBmb3IgdGhl XAogICBkYXRhLiAgVHJ1c3QgcmVsYXRpb25zaGlwcyBhcmUgYmFzZWQgb24gY29uc29ydGl1bXMg YW5kIGVzdGFibGlzaGVkXAogICB0cnVzdCByZWxhdGlvbnNoaXBzIG9mIHB1YmxpYyBrZXkgaW5m cmFzdHJ1Y3R1cmUgKFBLSSkgY3Jvc3MtXAogICBjZXJ0aWZpY2F0aW9ucyBvZiBjb25zb3J0aXVt cy4gIEJ5IHVzaW5nIFJJRFBvbGljeSBpbmZvcm1hdGlvbiwgVExTLFwKICAgYW5kIHRoZSBYTUwg c2VjdXJpdHkgZmVhdHVyZXMgb2YgZW5jcnlwdGlvbiBbWE1MZW5jcnlwdF0gYW5kIGRpZ2l0YWxc CiAgIHNpZ25hdHVyZXMgW1JGQzMyNzVdLCBbWE1Mc2lnXSwgUklEIHRha2VzIGFkdmFudGFnZSBv ZiBleGlzdGluZ1wKICAgc2VjdXJpdHkgc3RhbmRhcmRzLiAgVGhlIHN0YW5kYXJkcyBwcm92aWRl IGNsZWFyIG1ldGhvZHMgdG8gZW5zdXJlXAogICB0aGF0IG1lc3NhZ2VzIGFyZSBzZWN1cmUsIGF1 dGhlbnRpY2F0ZWQsIGFuZCBhdXRob3JpemVkLCBhbmQgdGhhdCB0aGVcCiAgIG1lc3NhZ2VzIG1l ZXQgcG9saWN5IGFuZCBwcml2YWN5IGd1aWRlbGluZXMgYW5kIG1haW50YWluIGludGVncml0eS5c ClwKICAgQXMgc3BlY2lmaWVkIGluIHRoZSByZWxldmFudCBzZWN0aW9ucyBvZiB0aGlzIGRvY3Vt ZW50LCB0aGUgWE1MXAogICBkaWdpdGFsIHNpZ25hdHVyZSBbUkZDMzI3NV0gYW5kIFhNTCBlbmNy eXB0aW9uIFtYTUxlbmNyeXB0XSBhcmUgdXNlZFwKICAgaW4gdGhlIGZvbGxvd2luZyBjYXNlczpc ClwKICAgWE1MIERpZ2l0YWwgU2lnbmF0dXJlXApcCiAgIG8gIFRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBUcmFjZVJlcXVlc3Qgb3IgSW52ZXN0aWdhdGlvbiByZXF1ZXN0IE1VU1RcCiAgICAgIHVzZSBh IGRldGFjaGVkIHNpZ25hdHVyZSB0byBzaWduIGF0IGxlYXN0IG9uZSBvZiB0aGUgb3JpZ2luYWwg SVBcCiAgICAgIHBhY2tldHMgaW5jbHVkZWQgaW4gdGhlIFJlY29yZEl0ZW0gY2xhc3MgZGF0YSB0 byBwcm92aWRlXAogICAgICBhdXRoZW50aWNhdGlvbiB0byBhbGwgdXBzdHJlYW0gcGFydGljaXBh bnRzIGluIHRoZSB0cmFjZSBvZiB0aGVcCiAgICAgIG9yaWdpbi4gIEFsbCBJUCBwYWNrZXRzIHBy b3ZpZGVkIGJ5IHRoZSBvcmlnaW5hdG9yIG1heSBiZSBzaWduZWQsXAogICAgICBhbmQgYWRkaXRp b25hbCBwYWNrZXRzIGFkZGVkIGJ5IHVwc3RyZWFtIHBlZXJzIGluIHRoZSB0cmFjZSBtYXkgYmVc CiAgICAgIHNpZ25lZCBieSB0aGUgcGVlciBhZGRpbmcgdGhlIGRhdGEsIHdoaWxlIG1haW50YWlu aW5nIHRoZSBJUFwKICAgICAgcGFja2V0IGFuZCBkZXRhY2hlZCBzaWduYXR1cmUgZnJvbSB0aGUg b3JpZ2luYWwgcmVxdWVzdG9yLiAgVGhpc1wKICAgICAgc2lnbmF0dXJlIE1VU1QgYmUgcGFzc2Vk IHRvIGFsbCByZWNpcGllbnRzIG9mIHRoZSBUcmFjZVJlcXVlc3QuXApcCiAgIG8gIElmIGFuIElu dmVzdGlnYXRpb24gcmVxdWVzdCBkb2VzIG5vdCBpbmNsdWRlIGFuIElQIHBhY2tldCwgdGhlXAog ICAgICBFdmVudERhdGEgY2xhc3MgaW5zdGFuY2UgZnJvbSBlYWNoIHRoZSBwYXJ0aWVzIGludm9s dmVkIGluIHRoZVwKICAgICAgaW52ZXN0aWdhdGlvbiBNVVNUIGJlIHNpZ25lZCB1c2luZyBhIGRl dGFjaGVkIHNpZ25hdHVyZS4gIFRoZVwKICAgICAgRXZlbnREYXRhIGNsYXNzIGNhbiBiZSB1c2Vk IHRvIGV4dGVuZCBpbmZvcm1hdGlvbiBhYm91dCBhblwKICAgICAgaW5jaWRlbnQgYnkgZWFjaCBD U0lSVCBvciBTUCBpbnZvbHZlZCBpbiB0aGUgaW52ZXN0aWdhdGlvbi4gIFVzaW5nXApcClwKXApN b3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAg ICAgICBbUGFnZSA1MF1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUt YmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgdGhpcyBjbGFzcyBm b3IgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlIHdoZW4gYW4gSVAgUGFja2V0IGlzIG5vdFwKICAgICAg aW5jbHVkZWQgcHJvdmlkZXMgYSBtZXRob2QgdG8gdmVyaWZ5IGVhY2ggcGFydHkgY29udHJpYnV0 aW5nIHRvXAogICAgICB0aGUgZGV0YWlscyBvZiB0aGUgaW5jaWRlbnQuXApcCiAgIG8gIEZvciBh bGwgbWVzc2FnZSB0eXBlcywgdGhlIGZ1bGwgSU9ERUYvUklEIGRvY3VtZW50IE1VU1QgYmUgc2ln bmVkXAogICAgICB1c2luZyBhbiBlbnZlbG9wZWQgc2lnbmF0dXJlIGJ5IHRoZSBzZW5kaW5nIHBl ZXIgdG8gcHJvdmlkZVwKICAgICAgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSB0byB0aGUg cmVjZWl2aW5nIFJJRCBzeXN0ZW0uXApcCiAgIFhNTCBFbmNyeXB0aW9uXApcCiAgIG8gIFRoZSBJ T0RFRi9SSUQgZG9jdW1lbnQgbWF5IGJlIGVuY3J5cHRlZCB0byBwcm92aWRlIGFuIGV4dHJhIGxh eWVyXAogICAgICBvZiBzZWN1cml0eSBiZXR3ZWVuIHBlZXJzIHNvIHRoYXQgdGhlIG1lc3NhZ2Ug aXMgbm90IG9ubHlcCiAgICAgIGVuY3J5cHRlZCBmb3IgdGhlIHRyYW5zcG9ydCwgYnV0IGFsc28g d2hpbGUgc3RvcmVkLiAgVGhpcyBiZWhhdmlvclwKICAgICAgd291bGQgYmUgYWdyZWVkIHVwb24g YmV0d2VlbiBwZWVycyBvciBhIGNvbnNvcnRpdW0sIG9yIGRldGVybWluZWRcCiAgICAgIG9uIGEg cGVyLW1lc3NhZ2UgYmFzaXMsIGRlcGVuZGluZyBvbiBzZWN1cml0eSByZXF1aXJlbWVudHMuICBJ dFwKICAgICAgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlcmUgYXJlIGNhc2VzIGZvciB0cmFuc3Bv cnQgd2hlcmUgdGhlXAogICAgICBSSURQb2xpY3kgY2xhc3MgbmVlZHMgdG8gYmUgcHJlc2VudGVk IGluIGNsZWFyIHRleHQsIGFzIGRldGFpbGVkXAogICAgICBpbiB0aGUgdHJhbnNwb3J0IGRvY3Vt ZW50IFtSRkM2MDQ2XS5cClwKICAgbyAgQW4gSW52ZXN0aWdhdGlvbiByZXF1ZXN0LCBvciBhbnkg b3RoZXIgbWVzc2FnZSB0eXBlIHRoYXQgbWF5IGJlXAogICAgICByZWxheWVkIHRocm91Z2ggUklE IHN5c3RlbXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgZGVzdGluYXRpb24gYXNcCiAgICAgIGEg cmVzdWx0IG9mIHRydXN0IHJlbGF0aW9uc2hpcHMsIG1heSBiZSBlbmNyeXB0ZWQgZm9yIHRoZSBp bnRlbmRlZFwKICAgICAgcmVjaXBpZW50LiAgVGhpcyBtYXkgYmUgbmVjZXNzYXJ5IGlmIHRoZSBS SUQgbmV0d29yayBpcyBiZWluZyB1c2VkXAogICAgICBmb3IgbWVzc2FnZSB0cmFuc2ZlciwgdGhl IGludGVybWVkaWF0ZSBwYXJ0aWVzIGRvIG5vdCBuZWVkIHRvIGhhdmVcCiAgICAgIGtub3dsZWRn ZSBvZiB0aGUgcmVxdWVzdCBjb250ZW50cywgYW5kIGEgZGlyZWN0IGNvbW11bmljYXRpb24gcGF0 aFwKICAgICAgZG9lcyBub3QgZXhpc3QuICBJbiB0aGF0IGNhc2UsIHRoZSBSSURQb2xpY3kgY2xh c3MgaXMgdXNlZCBieVwKICAgICAgaW50ZXJtZWRpYXRlIHBhcnRpZXMgYW5kIGlzIG1haW50YWlu ZWQgaW4gY2xlYXIgdGV4dC5cClwKICAgbyAgVGhlIGFjdGlvbiB0YWtlbiBpbiB0aGUgUmVzdWx0 IG1lc3NhZ2UgbWF5IGJlIGVuY3J5cHRlZCB1c2luZyB0aGVcCiAgICAgIGtleSBvZiB0aGUgcmVx dWVzdCBvcmlnaW5hdG9yLiAgSW4gdGhhdCBjYXNlLCB0aGUgaW50ZXJtZWRpYXRlXAogICAgICBw YXJ0aWVzIGNhbiB2aWV3IHRoZSBSSURQb2xpY3kgaW5mb3JtYXRpb24gYW5kIGtub3cgdGhlIHRy YWNlIGhhc1wKICAgICAgYmVlbiBjb21wbGV0ZWQgYW5kIGRvIG5vdCBuZWVkIHRvIHNlZSB0aGUg YWN0aW9uLiAgSWYgdGhlIHVzZSBvZlwKICAgICAgZW5jcnlwdGlvbiB3ZXJlIGxpbWl0ZWQgdG8g c2VjdGlvbnMgb2YgdGhlIG1lc3NhZ2UsIHRoZSBIaXN0b3J5XAogICAgICBjbGFzcyBpbmZvcm1h dGlvbiB3b3VsZCBiZSBlbmNyeXB0ZWQuICBPdGhlcndpc2UsIGl0IGlzXAogICAgICBSRUNPTU1F TkRFRCB0byBlbmNyeXB0IHRoZSBlbnRpcmUgSU9ERUYvUklEIGRvY3VtZW50LCB1c2luZyBhblwK ICAgICAgZW52ZWxvcGVkIHNpZ25hdHVyZSwgZm9yIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSByZXF1 ZXN0LiAgVGhlXAogICAgICBleGlzdGVuY2Ugb2YgdGhlIFJlc3VsdCBtZXNzYWdlIGZvciBhbiBp bmNpZGVudCB3b3VsZCB0ZWxsIGFueVwKICAgICAgaW50ZXJtZWRpYXRlIHBhcnRpZXMgdXNlZCBp biB0aGUgcGF0aCBvZiB0aGUgaW5jaWRlbnRcCiAgICAgIGludmVzdGlnYXRpb24gdGhhdCB0aGUg aW5jaWRlbnQgaGFuZGxpbmcgaGFzIGJlZW4gY29tcGxldGVkLlwKXAogICBvICBUaGUgaW9kZWY6 cmVzdHJpY3Rpb24gYXR0cmlidXRlIHNldHMgZXhwZWN0YXRpb25zIGZvciB0aGUgcHJpdmFjeVwK ICAgICAgb2YgYW4gaW5jaWRlbnQgYW5kIGlzIGRlZmluZWQgaW4gc2VjdGlvbiAzLjIgb2YgUkZD NTA3MC4gIFRoZVwKICAgICAgcmVzdHJpY3Rpb24gYXR0cmlidXRlIGNhbiBiZSBzZXQgaW4gYW55 IG9mIHRoZSBSSUQgY2xhc3NlcyB0b1wKICAgICAgZGVmaW5lIHJlc3RyaWN0aW9ucyBmb3IgdGhl IGNvbXBsZXRlIGV4Y2hhbmdlIG9mIGFuIElPREVGIGRvY3VtZW50XAogICAgICAoaW5jbHVkaW5n IGFueSBleHRlbnNpb25zKSBvciB3aXRoaW4gc3BlY2lmaWMgY2xhc3NlcyBvZiBJT0RFRiBvclwK ICAgICAgSU9ERUYgZXh0ZW5zaW9ucyB3aGVyZSBtb3JlIGxpbWl0ZWQgcmVzdHJpY3Rpb25zIGFy ZSBkZXNpcmVkLiAgVGhlXAogICAgICByZXN0cmljdGlvbiBhdHRyaWJ1dGUgaXMgY29udGFpbmVk IGluIGVhY2ggb2YgdGhlIFJJRCBjbGFzc2VzIGFuZFwKICAgICAgTVVTVCBiZSB1c2VkIGluIGFj Y29yZGFuY2Ugd2l0aCBwcml2YWN5IGV4cGVjdGF0aW9ucyBmb3IgZWl0aGVyXApcClwKXApNb3Jp YXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAg ICBbUGFnZSA1MV1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlz ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgc2VjdGlvbnMgb2YgdGhl IElPREVGIGRvY3VtZW50IG9yIHRoZSBjb21wbGV0ZSBJT0RFRiBkb2N1bWVudC5cCiAgICAgIENv bnNvcnRpdW1zIGFuZCBvcmdhbml6YXRpb25zIHNob3VsZCBjb25zaWRlciB0aGlzIGd1aWRhbmNl IHdoZW5cCiAgICAgIGNyZWF0aW5nIGV4Y2hhbmdlIHBvbGljaWVzLlwKXAogICBvICBFeHBlY3Rh dGlvbnMgYmFzZWQgb24gcmVzdHJpY3Rpb24gc2V0dGluZzpcClwKICAgICAgKiAgSWYgcmVzdHJp Y3Rpb24gaXMgc2V0IHRvICJwcml2YXRlIiwgdGhlIGNsYXNzIG9yIGRvY3VtZW50IE1VU1RcCiAg ICAgICAgIGJlIGVuY3J5cHRlZCBmb3IgdGhlIHJlY2lwaWVudCB1c2luZyBYTUwgZW5jcnlwdGlv biBhbmQgdGhlXAogICAgICAgICBwdWJsaWMga2V5IG9mIHRoZSByZWNpcGllbnQuXApcCiAgICAg ICogIElmIHJlc3RyaWN0aW9uIGlzIHNldCB0byAibmVlZC10by1rbm93IiwgdGhlIGNsYXNzIG9y IGRvY3VtZW50XAogICAgICAgICBNVVNUIGJlIGVuY3J5cHRlZCB0byBlbnN1cmUgb25seSB0aG9z ZSB3aXRoIG5lZWQtdG8ta25vdyBhY2Nlc3NcCiAgICAgICAgIGNhbiBkZWNyeXB0IHRoZSBkYXRh LiAgVGhlIGRvY3VtZW50IGNhbiBlaXRoZXIgYmUgZW5jcnlwdGVkIGZvclwKICAgICAgICAgZWFj aCBpbmRpdmlkdWFsIGZvciB3aGljaCBhY2Nlc3MgaXMgaW50ZW5kZWQgb3IgYSBzaW5nbGUgZ3Jv dXBcCiAgICAgICAgIGtleSBtYXkgYmUgdXNlZC4gIEEgZ3JvdXAga2V5IGluIHRoaXMgaW5zdGFu Y2UgcmVmZXJzIHRvIGFcCiAgICAgICAgIHNpbmdsZSBrZXkgKHN5bW1ldHJpYykgdGhhdCBpcyB1 c2VkIHRvIGVuY3J5cHQgdGhlIGJsb2NrIG9mXAogICAgICAgICBkYXRhLiAgVGhlIHVzZXJzIHdp dGggbmVlZC10by1rbm93IGFjY2VzcyBwcml2aWxlZ2VzIG1heSBiZVwKICAgICAgICAgZ2l2ZW4g YWNjZXNzIHRvIHRoZSBzaGFyZWQga2V5IGJ5IGRpc3RyaWJ1dGluZyBvciBwcm92aWRpbmdcCiAg ICAgICAgIGFjY2VzcyB0byBpdCBlbmNyeXB0ZWQgd2l0aCBlYWNoIG9mIHRoZWlyIHB1YmxpYyBr ZXlzLlwKXAogICAgICAqICBJZiByZXN0cmljdGlvbiBpcyBzZXQgdG8gInB1YmxpYyIsIHRoZSBj bGFzcyBvciBkb2N1bWVudCBNVVNUXAogICAgICAgICBiZSBzZW50IGluIGNsZWFyIHRleHQuICBU aGlzIHNldHRpbmcgY2FuIGJlIGNyaXRpY2FsIGlmIGNlcnRhaW5cCiAgICAgICAgIHNlY3Rpb25z IG9mIGEgZG9jdW1lbnQgb3IgYW4gZW50aXJlIGRvY3VtZW50IGFyZSB0byBiZSBzaGFyZWRcCiAg ICAgICAgIHdpdGhvdXQgcmVzdHJpY3Rpb25zLiAgVGhpcyBwcm92aWRlcyBmbGV4aWJpbGl0eSB3 aXRoaW4gYW5cCiAgICAgICAgIGluY2lkZW50IHRvIHNoYXJlIG91dCBjZXJ0YWluIGluZm9ybWF0 aW9uIGZyZWVseSB3aGVyZVwKICAgICAgICAgYXBwcm9wcmlhdGUuXApcCiAgICAgICogIElmIHJl c3RyaWN0aW9uIGlzIHNldCB0byAiZGVmYXVsdCIsIFRoZSBpbmZvcm1hdGlvbiBjYW4gYmVcCiAg ICAgICAgIHNoYXJlZCBhY2NvcmRpbmcgdG8gYW4gaW5mb3JtYXRpb24gZGlzY2xvc3VyZSBwb2xp Y3kgcHJlLVwKICAgICAgICAgYXJyYW5nZWQgYnkgdGhlIGNvbW11bmljYXRpbmcgcGFydGllcy5c ClwKICAgbyAgRXhwZWN0YXRpb25zIGJhc2VkIG9uIHBsYWNlbWVudCBvZiB0aGUgcmVzdHJpY3Rp b24gc2V0dGluZzpcClwKICAgICAgKiAgSWYgcmVzdHJpY3Rpb24gaXMgc2V0IHdpdGhpbiBvbmUg b2YgdGhlIFJJRCBjbGFzc2VzLCB0aGVcCiAgICAgICAgIHJlc3RyaWN0aW9uIGFwcGxpZXMgdG8g dGhlIGVudGlyZSBJT0RFRiBkb2N1bWVudC5cClwKICAgICAgKiAgSWYgcmVzdHJpY3Rpb24gaXMg c2V0IHdpdGhpbiBpbmRpdmlkdWFsIElPREVGIGNsYXNzZXMsIHRoZVwKICAgICAgICAgcmVzdHJp Y3Rpb24gYXBwbGllcyB0byB0aGUgc3BlY2lmaWMgSU9ERUYgY2xhc3MgYW5kIHRoZVwKICAgICAg ICAgY2hpbGRyZW4gb2YgdGhhdCBjbGFzcy5cClwKICAgVGhlIGZvcm1hdGlvbiBvZiBwb2xpY2ll cyBpcyBhIHZlcnkgaW1wb3J0YW50IGFzcGVjdCBvZiB1c2luZyBhXAogICBtZXNzYWdpbmcgc3lz dGVtIGxpa2UgUklEIHRvIGV4Y2hhbmdlIHBvdGVudGlhbGx5IHNlbnNpdGl2ZVwKICAgaW5mb3Jt YXRpb24uICBNYW55IGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSBpbnZvbHZlZCBmb3IgcGVlcmlu Z1wKICAgcGFydGllcywgYW5kIHNvbWUgZ3VpZGVsaW5lcyB0byBwcm90ZWN0IHRoZSBkYXRhLCBz eXN0ZW1zLCBhbmRcCiAgIHRyYW5zcG9ydCBhcmUgY292ZXJlZCBpbiB0aGlzIHNlY3Rpb24uICBQ b2xpY2llcyBlc3RhYmxpc2hlZCBzaG91bGRcCiAgIHByb3ZpZGUgZ3VpZGVsaW5lcyBmb3IgY29t bXVuaWNhdGlvbiBtZXRob2RzLCBzZWN1cml0eSwgYW5kIGZhbGwtYmFja1wKICAgcHJvY2VkdXJl cy5cClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwg MjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTJdXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIFRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlIHN0b3JhZ2UgYW5kIGV4Y2hhbmdlIG9m XAogICBpbmZvcm1hdGlvbiBpbiBSSUQgbWVzc2FnaW5nIG1heSBpbmNsdWRlIGFkaGVyZW5jZSB0 byBsb2NhbCxcCiAgIHJlZ2lvbmFsLCBvciBuYXRpb25hbCByZWd1bGF0aW9ucyBpbiBhZGRpdGlv biB0byB0aGUgb2JsaWdhdGlvbnMgdG9cCiAgIHByb3RlY3QgY2xpZW50IGluZm9ybWF0aW9uIGR1 cmluZyBhbiBpbnZlc3RpZ2F0aW9uLiAgUklEIFBvbGljeSBpcyBhXAogICBuZWNlc3NhcnkgdG9v bCBmb3IgbGlzdGluZyB0aGUgcmVxdWlyZW1lbnRzIG9mIG1lc3NhZ2VzIHRvIHByb3ZpZGUgYVwK ICAgbWV0aG9kIHRvIGNhdGVnb3JpemUgZGF0YSBlbGVtZW50cyBmb3IgcHJvcGVyIGhhbmRsaW5n LiAgQ29udHJvbHMgYXJlXAogICBhbHNvIHByb3ZpZGVkIGZvciB0aGUgc2VuZGluZyBlbnRpdHkg dG8gcHJvdGVjdCBtZXNzYWdlcyBmcm9tIHRoaXJkXAogICBwYXJ0aWVzIHRocm91Z2ggWE1MIGVu Y3J5cHRpb24uXApcCiAgIFJJRCBwcm92aWRlcyBhIG1ldGhvZCB0byBleGNoYW5nZSBpbmNpZGVu dCBoYW5kbGluZyByZXF1ZXN0IGFuZFwKICAgUmVwb3J0IG1lc3NhZ2VzIHRvIHBlZXIgbmV0d29y a3MuICBOZXR3b3JrIGFkbWluaXN0cmF0b3JzLCB3aG8gaGF2ZVwKICAgdGhlIGFiaWxpdHkgdG8g YmFzZSB0aGUgZGVjaXNpb24gb24gdGhlIGF2YWlsYWJsZSByZXNvdXJjZXMgYW5kIG90aGVyXAog ICBmYWN0b3JzIG9mIHRoZWlyIG5ldHdvcmssIG1haW50YWluIGNvbnRyb2wgb2YgaW5jaWRlbnQg aW52ZXN0aWdhdGlvbnNcCiAgIHdpdGhpbiB0aGVpciBvd24gbmV0d29yay4gIFRodXMsIFJJRCBw cm92aWRlcyB0aGUgYWJpbGl0eSBmb3JcCiAgIHBhcnRpY2lwYXRpbmcgbmV0d29ya3MgdG8gbWFu YWdlIHRoZWlyIG93biBzZWN1cml0eSBjb250cm9scyxcCiAgIGxldmVyYWdpbmcgdGhlIGluZm9y bWF0aW9uIGxpc3RlZCBpbiBSSURQb2xpY3kuXApcCjcuMS4gIE1lc3NhZ2UgVHJhbnNwb3J0XApc CiAgIFRoZSB0cmFuc3BvcnQgc3BlY2lmaWNhdGlvbnMgYXJlIGZ1bGx5IGRlZmluZWQgaW4gYSBz ZXBhcmF0ZSBkb2N1bWVudFwKICAgW1JGQzYwNDZdLiAgVGhlIHNwZWNpZmllZCB0cmFuc3BvcnQg cHJvdG9jb2xzIE1VU1QgdXNlIGVuY3J5cHRpb24gdG9cCiAgIHByb3ZpZGUgYW4gYWRkaXRpb25h bCBsZXZlbCBvZiBzZWN1cml0eSBhbmQgaW50ZWdyaXR5LCB3aGlsZVwKICAgc3VwcG9ydGluZyBt dXR1YWwgYXV0aGVudGljYXRpb24gdGhyb3VnaCBiaS1kaXJlY3Rpb25hbCBjZXJ0aWZpY2F0ZVwK ICAgdXNhZ2UuICBBbnkgc3Vic2VxdWVudCB0cmFuc3BvcnQgbWV0aG9kIGRlZmluZWQgc2hvdWxk IHRha2UgYWR2YW50YWdlXAogICBvZiBleGlzdGluZyBzdGFuZGFyZHMgZm9yIGVhc2Ugb2YgaW1w bGVtZW50YXRpb24gYW5kIGludGVncmF0aW9uIG9mXAogICBSSUQgc3lzdGVtcy4gIFNlc3Npb24g ZW5jcnlwdGlvbiBmb3IgdGhlIHRyYW5zcG9ydCBvZiBSSUQgbWVzc2FnZXMgaXNcCiAgIGVuZm9y Y2VkIGluIHRoZSB0cmFuc3BvcnQgc3BlY2lmaWNhdGlvbi4gIFRoZSBwcml2YWN5IGFuZCBzZWN1 cml0eVwKICAgY29uc2lkZXJhdGlvbnMgYXJlIGFkZHJlc3NlZCBmdWxseSBpbiBSSUQgdG8gcHJv dGVjdCBzZW5zaXRpdmVcCiAgIHBvcnRpb25zIG9mIGRvY3VtZW50cyBhbmQgcHJvdmlkZSBhIG1l dGhvZCB0byBhdXRoZW50aWNhdGUgdGhlXAogICBtZXNzYWdlcy4gIFRoZXJlZm9yZSwgUklEIG1l c3NhZ2VzIGRvIG5vdCByZWx5IG9uIHRoZSBzZWN1cml0eVwKICAgcHJvdmlkZWQgYnkgdGhlIHRy YW5zcG9ydCBsYXllciBhbG9uZS4gIFRoZSBlbmNyeXB0aW9uIHJlcXVpcmVtZW50c1wKICAgYW5k IGNvbnNpZGVyYXRpb25zIGZvciBSSUQgYXJlIGRpc2N1c3NlZCBhdCB0aGUgYmVnaW5uaW5nIG9m IFNlY3Rpb25cCiAgIDYgb2YgdGhpcyBkb2N1bWVudC5cClwKICAgWE1MIHNlY3VyaXR5IGZ1bmN0 aW9ucyBzdWNoIGFzIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBbUkZDMzI3NV0gYW5kXAogICBlbmNy eXB0aW9uIFtYTUxlbmNyeXB0XSBwcm92aWRlIGEgc3RhbmRhcmRzLWJhc2VkIG1ldGhvZCB0byBl bmNyeXB0XAogICBhbmQgZGlnaXRhbGx5IHNpZ24gUklEIG1lc3NhZ2VzLiAgUklEIG1lc3NhZ2Vz IHNwZWNpZnkgc3lzdGVtIHVzZSBhbmRcCiAgIHByaXZhY3kgZ3VpZGVsaW5lcyB0aHJvdWdoIHRo ZSBSSURQb2xpY3kgY2xhc3MuICBBIHB1YmxpYyBrZXlcCiAgIGluZnJhc3RydWN0dXJlIChQS0kp IHByb3ZpZGVzIHRoZSBiYXNlIGZvciBhdXRoZW50aWNhdGlvbiBhbmRcCiAgIGF1dGhvcml6YXRp b24sIGVuY3J5cHRpb24sIGFuZCBkaWdpdGFsIHNpZ25hdHVyZXMgdG8gZXN0YWJsaXNoIHRydXN0 XAogICByZWxhdGlvbnNoaXBzIGJldHdlZW4gbWVtYmVycyBvZiBhIFJJRCBjb25zb3J0aXVtIG9y IGEgcGVlcmluZ1wKICAgY29uc29ydGl1bS5cClwKICAgWE1MIHNlY3VyaXR5IGZ1bmN0aW9ucyBz dWNoIGFzIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBbUkZDMzI3NV0gYW5kXAogICBlbmNyeXB0aW9u IFtYTUxlbmNyeXB0XSBjYW4gYmUgdXNlZCB3aXRoaW4gdGhlIGNvbnRlbnRzIG9mIHRoZVwKICAg bWVzc2FnZSBmb3IgcHJpdmFjeSBhbmQgc2VjdXJpdHkgaW4gY2FzZXMgZm9yIHdoaWNoIGNlcnRh aW4gZWxlbWVudHNcCiAgIG11c3QgcmVtYWluIGVuY3J5cHRlZCBvciBzaWduZWQgYXMgdGhleSB0 cmF2ZXJzZSB0aGUgcGF0aCBvZiBhIHRyYWNlLlwKICAgRm9yIGV4YW1wbGUsIHRoZSBkaWdpdGFs IHNpZ25hdHVyZSBvbiBhIFRyYWNlUmVxdWVzdCBjYW4gYmUgdXNlZCB0b1wKXApcClwKTW9yaWFy dHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAg W1BhZ2UgNTNdXApcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAg ICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIHZlcmlmeSB0aGUgaWRlbnRpdHkg b2YgdGhlIHRyYWNlIG9yaWdpbmF0b3IuICBUaGUgdXNlIG9mIHRoZSBYTUxcCiAgIHNlY3VyaXR5 IGZlYXR1cmVzIGluIFJJRCBtZXNzYWdpbmcgaXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZVwKICAg c3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBJT0RFRiBtb2RlbDsgaG93ZXZlciwgdGhlIHVzZSByZXF1 aXJlbWVudHMgbWF5XAogICBkaWZmZXIgc2luY2UgUklEIGFsc28gaW5jb3Jwb3JhdGVzIGNvbW11 bmljYXRpb24gb2Ygc2VjdXJpdHkgaW5jaWRlbnRcCiAgIGluZm9ybWF0aW9uLlwKXAo3LjIuICBN ZXNzYWdlIERlbGl2ZXJ5IFByb3RvY29sIC0gSW50ZWdyaXR5IGFuZCBBdXRoZW50aWNhdGlvblwK XAogICBUaGUgUklEIHByb3RvY29sIG11c3QgYmUgYWJsZSB0byBndWFyYW50ZWUgZGVsaXZlcnkg YW5kIG1lZXQgdGhlXAogICBuZWNlc3Nhcnkgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIGEgc3Rh dGUtb2YtdGhlLWFydCBwcm90b2NvbC4gIEluXAogICBvcmRlciB0byBndWFyYW50ZWUgZGVsaXZl cnksIFRDUCBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyB0aGVcCiAgIHVuZGVybHlpbmcgcHJvdG9j b2wgd2l0aGluIHRoZSBjdXJyZW50IG5ldHdvcmsgc3RhbmRhcmQgcHJhY3RpY2VzLlwKXAogICBT ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBtdXN0IGluY2x1ZGUgdGhlIGludGVncml0eSwgYXV0aGVu dGljYXRpb24sXAogICBwcml2YWN5LCBhbmQgYXV0aG9yaXphdGlvbiBvZiB0aGUgbWVzc2FnZXMg c2VudCBiZXR3ZWVuIFJJRFwKICAgY29tbXVuaWNhdGlvbiBzeXN0ZW1zIG9yIElIU3MuICBUaGUg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIFJJRCBzeXN0ZW1zXAogICBtdXN0IGJlIGF1dGhlbnRpY2F0 ZWQgYW5kIGVuY3J5cHRlZCB0byBlbnN1cmUgdGhlIGludGVncml0eSBvZiB0aGVcCiAgIG1lc3Nh Z2VzIGFuZCB0aGUgUklEIHN5c3RlbXMgaW52b2x2ZWQgaW4gdGhlIHRyYWNlLiAgQW5vdGhlciBj b25jZXJuXAogICB0aGF0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpcyBhdXRoZW50aWNhdGlvbiBm b3IgYSByZXF1ZXN0IHRoYXRcCiAgIHRyYXZlcnNlcyBtdWx0aXBsZSBuZXR3b3Jrcy4gIEluIHRo aXMgc2NlbmFyaW8sIHN5c3RlbXMgaW4gdGhlIHBhdGhcCiAgIG9mIHRoZSBtdWx0aS1ob3AgVHJh Y2VSZXF1ZXN0IG5lZWQgdG8gYXV0aG9yaXplIGEgdHJhY2UgZnJvbSBub3Qgb25seVwKICAgdGhl aXIgbmVpZ2hib3IgbmV0d29yaywgYnV0IGFsc28gZnJvbSB0aGUgaW5pdGlhdGluZyBSSUQgc3lz dGVtIGFzXAogICBkaXNjdXNzZWQgaW4gU2VjdGlvbiA2LjQuICBTZXZlcmFsIG1ldGhvZHMgY2Fu IGJlIHVzZWQgdG8gZW5zdXJlXAogICBpbnRlZ3JpdHkgYW5kIHByaXZhY3kgb2YgdGhlIGNvbW11 bmljYXRpb24uXApcCiAgIFRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtIHNlbGVjdGVkIE1VU1QgZm9s bG93IHRoZSBkZWZpbmVkIHRyYW5zcG9ydFwKICAgcHJvdG9jb2wgW1JGQzYwNDZdIHdoZW4gdXNp bmcgUklEIG1lc3NhZ2luZyB0byBlbnN1cmUgY29uc2lzdGVuY3lcCiAgIGFtb25nIHRoZSBwZWVy cy4gIENvbnNvcnRpdW1zIG1heSB2YXJ5IHRoZWlyIHNlbGVjdGVkIHRyYW5zcG9ydFwKICAgbWVj aGFuaXNtcyBhbmQgdGh1cyBtdXN0IGRlY2lkZSB1cG9uIGEgbXV0dWFsIHByb3RvY29sIHRvIHVz ZSBmb3JcCiAgIHRyYW5zcG9ydCB3aGVuIGNvbW11bmljYXRpbmcgd2l0aCBwZWVycyBpbiBhIG5l aWdoYm9yaW5nIGNvbnNvcnRpdW1cCiAgIHVzaW5nIFJJRC4gIFJJRCBzeXN0ZW1zIE1VU1QgaW1w bGVtZW50IGFuZCBkZXBsb3kgSFRUUFMgYXMgZGVmaW5lZCBpblwKICAgdGhlIHRyYW5zcG9ydCBk b2N1bWVudCBbUkZDNjA0Nl0gYW5kIG9wdGlvbmFsbHkgc3VwcG9ydCBvdGhlclwKICAgcHJvdG9j b2xzIHN1Y2ggYXMgdGhlIEJsb2NrcyBFeHRlbnNpYmxlIEV4Y2hhbmdlIFByb3RvY29sIChCRUVQ KS5cCiAgIFJJRCwgdGhlIFhNTCBzZWN1cml0eSBmdW5jdGlvbnMsIGFuZCB0cmFuc3BvcnQgcHJv dG9jb2xzIG11c3RcCiAgIHByb3Blcmx5IGludGVncmF0ZSB3aXRoIGEgcHVibGljIGtleSBpbmZy YXN0cnVjdHVyZSAoUEtJKSBtYW5hZ2VkIGJ5XAogICB0aGUgY29uc29ydGl1bSBvciBvbmUgbWFu YWdlZCBieSBhIHRydXN0ZWQgZW50aXR5LiAgRm9yIHRoZSBJbnRlcm5ldCxcCiAgIGFuIGV4YW1w bGUgb2YgYW4gZXhpc3RpbmcgZWZmb3J0IHRoYXQgY291bGQgYmUgbGV2ZXJhZ2VkIHRvIHByb3Zp ZGVcCiAgIHRoZSBzdXBwb3J0aW5nIFBLSSBjb3VsZCBiZSB0aGUgQW1lcmljYW4gUmVnaXN0cnkg Zm9yIEludGVybmV0XAogICBOdW1iZXJzIChBUklOKSBhbmQgdGhlIFJlZ2lvbmFsIEludGVybmV0 IFJlZ2lzdHJ5J3MgKFJJUidzKSBQS0lcCiAgIGhpZXJhcmNoeS4gIFNlY3VyaXR5IGFuZCBwcml2 YWN5IGNvbnNpZGVyYXRpb25zIHJlbGF0ZWQgdG9cCiAgIGNvbnNvcnRpdW1zIGFyZSBkaXNjdXNz ZWQgaW4gU2VjdGlvbnMgNi41IGFuZCA2LjYuXApcCjcuMy4gIFRyYW5zcG9ydCBDb21tdW5pY2F0 aW9uXApcCiAgIE91dC1vZi1iYW5kIGNvbW11bmljYXRpb25zIGRlZGljYXRlZCB0byBTUCBpbnRl cmFjdGlvbiBmb3IgUklEXAogICBtZXNzYWdpbmcgd291bGQgcHJvdmlkZSBhZGRpdGlvbmFsIHNl Y3VyaXR5IGFzIHdlbGwgYXMgZ3VhcmFudGVlZFwKICAgYmFuZHdpZHRoIGR1cmluZyBhIGRlbmlh bC1vZi1zZXJ2aWNlIGF0dGFjay4gIEZvciBleGFtcGxlLCBhbiBvdXQtb2YtXAogICBiYW5kIGNo YW5uZWwgbWF5IGNvbnNpc3Qgb2YgbG9naWNhbCBwYXRocyBkZWZpbmVkIG92ZXIgdGhlIGV4aXN0 aW5nXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAy MDEyICAgICAgICAgICAgICBbUGFnZSA1NF1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgbmV0 d29yay4gIE91dC1vZi1iYW5kIGNvbW11bmljYXRpb25zIG1heSBub3QgYmUgcG9zc2libGUgYmV0 d2VlbiBhbGxcCiAgIG5ldHdvcmsgcHJvdmlkZXJzLCBidXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQg dG8gcHJvdGVjdCB0aGUgbmV0d29ya1wKICAgbWFuYWdlbWVudCBzeXN0ZW1zIHVzZWQgZm9yIFJJ RCBtZXNzYWdpbmcuICBNZXRob2RzIHRvIHByb3RlY3QgdGhlXAogICBkYXRhIHRyYW5zcG9ydCBt YXkgYWxzbyBiZSBwcm92aWRlZCB0aHJvdWdoIHNlc3Npb24gZW5jcnlwdGlvbi5cClwKICAgSW4g b3JkZXIgdG8gYWRkcmVzcyB0aGUgaW50ZWdyaXR5IGFuZCBhdXRoZW50aWNpdHkgb2YgbWVzc2Fn ZXMsXAogICB0cmFuc3BvcnQgZW5jcnlwdGlvbiBNVVNUIGJlIHVzZWQgdG8gc2VjdXJlIHRoZSB0 cmFmZmljIHNlbnQgYmV0d2VlblwKICAgUklEIHN5c3RlbXMuICBTeXN0ZW1zIHdpdGggcHJlZGVm aW5lZCByZWxhdGlvbnNoaXBzIGZvciBSSUQgd291bGRcCiAgIGluY2x1ZGUgdGhvc2Ugd2hvIHBl ZXIgd2l0aGluIGEgY29uc29ydGl1bSB3aXRoIGFncmVlZC11cG9uXAogICBhcHByb3ByaWF0ZSB1 c2UgcmVndWxhdGlvbnMgYW5kIGZvciBwZWVyaW5nIGNvbnNvcnRpdW1zLiAgVHJ1c3RcCiAgIHJl bGF0aW9uc2hpcHMgbWF5IGFsc28gYmUgZGVmaW5lZCB0aHJvdWdoIGEgYnJpZGdlZCBvciBoaWVy YXJjaGljYWxcCiAgIFBLSSBpbiB3aGljaCBib3RoIHBlZXJzIGJlbG9uZy5cClwKICAgU3lzdGVt cyB1c2VkIHRvIHNlbmQgYXV0aGVudGljYXRlZCBSSUQgbWVzc2FnZXMgYmV0d2VlbiBuZXR3b3Jr cyBNVVNUXAogICB1c2UgYSBzZWN1cmVkIHN5c3RlbSBhbmQgaW50ZXJmYWNlIHRvIGNvbm5lY3Qg dG8gYSBib3JkZXIgbmV0d29yaydzXAogICBSSUQgc3lzdGVtcy4gIEVhY2ggY29ubmVjdGlvbiB0 byBhIFJJRCBzeXN0ZW0gTVVTVCBtZWV0IHRoZSBzZWN1cml0eVwKICAgcmVxdWlyZW1lbnRzIGFn cmVlZCB1cG9uIHRocm91Z2ggdGhlIGNvbnNvcnRpdW0gcmVndWxhdGlvbnMsIHBlZXJpbmcsXAog ICBvciBTTEFzLiAgVGhlIFJJRCBzeXN0ZW0gTVVTVCBvbmx5IGxpc3RlbiBmb3IgYW5kIHNlbmQg UklEIG1lc3NhZ2VzXAogICBvbiB0aGUgZGVzaWduYXRlZCBwb3J0LCB3aGljaCBhbHNvIE1VU1Qg YmUgb3ZlciBhbiBlbmNyeXB0ZWQgdHVubmVsXAogICBtZWV0aW5nIHRoZSBtaW5pbXVtIHJlcXVp cmVtZW50IG9mIGFsZ29yaXRobXMgYW5kIGtleSBsZW5ndGhzXAogICBlc3RhYmxpc2hlZCBieSB0 aGUgY29uc29ydGl1bSwgcGVlcmluZywgb3IgU0xBLiAgVGhlIHNlbGVjdGVkXAogICBjcnlwdG9n cmFwaGljIGFsZ29yaXRobXMgZm9yIHN5bW1ldHJpYyBlbmNyeXB0aW9uLCBkaWdpdGFsXAogICBz aWduYXR1cmVzLCBhbmQgaGFzaCBmdW5jdGlvbnMgTVVTVCBtZWV0IG1pbmltdW0gc2VjdXJpdHkg bGV2ZWxzIG9mXAogICB0aGUgdGltZXMuICBUaGUgZW5jcnlwdGlvbiBzdHJlbmd0aCBNVVNUIGFk aGVyZSB0byBpbXBvcnQgYW5kIGV4cG9ydFwKICAgcmVndWxhdGlvbnMgb2YgdGhlIGludm9sdmVk IGNvdW50cmllcyBmb3IgZGF0YSBleGNoYW5nZS5cClwKNy40LiAgQXV0aGVudGljYXRpb24gb2Yg UklEIFByb3RvY29sXApcCiAgIEluIG9yZGVyIHRvIGVuc3VyZSB0aGUgYXV0aGVudGljaXR5IG9m IHRoZSBSSUQgbWVzc2FnZXMsIGEgbWVzc2FnZVwKICAgYXV0aGVudGljYXRpb24gc2NoZW1lIGlz IHVzZWQgdG8gc2VjdXJlIHRoZSBwcm90b2NvbC4gIFhNTCBzZWN1cml0eVwKICAgZnVuY3Rpb25z IHV0aWxpemVkIGluIFJJRCByZXF1aXJlIGEgdHJ1c3QgY2VudGVyIHN1Y2ggYXMgYSBQS0kgZm9y XAogICB0aGUgZGlzdHJpYnV0aW9uIG9mIGNyZWRlbnRpYWxzIHRvIHByb3ZpZGUgdGhlIG5lY2Vz c2FyeSBsZXZlbCBvZlwKICAgc2VjdXJpdHkgZm9yIHRoaXMgcHJvdG9jb2wuICBMYXllcmVkIHRy YW5zcG9ydCBwcm90b2NvbHMgYWxzbyB1dGlsaXplXAogICBlbmNyeXB0aW9uIGFuZCByZWx5IG9u IGEgdHJ1c3QgY2VudGVyLiAgUHVibGljIGtleSBjZXJ0aWZpY2F0ZSBwYWlyc1wKICAgaXNzdWVk IGJ5IGEgdHJ1c3RlZCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAoQ0EpIE1BWSBiZSB1c2VkIHRv XAogICBwcm92aWRlIHRoZSBuZWNlc3NhcnkgbGV2ZWwgb2YgYXV0aGVudGljYXRpb24gYW5kIGVu Y3J5cHRpb24gZm9yIHRoZVwKICAgUklEIHByb3RvY29sLiAgVGhlIENBIHVzZWQgZm9yIFJJRCBt ZXNzYWdpbmcgbXVzdCBiZSB0cnVzdGVkIGJ5IGFsbFwKICAgaW52b2x2ZWQgcGFydGllcyBhbmQg bWF5IHRha2UgYWR2YW50YWdlIG9mIHNpbWlsYXIgZWZmb3J0cywgc3VjaCBhc1wKICAgdGhlIElu dGVybmV0MiBmZWRlcmF0ZWQgUEtJIG9yIHRoZSBBUklOL1JJUiBlZmZvcnQgdG8gcHJvdmlkZSBh IFBLSVwKICAgdG8gbmV0d29yayBwcm92aWRlcnMuICBUaGUgUEtJIHVzZWQgZm9yIGF1dGhlbnRp Y2F0aW9uIHdvdWxkIGFsc29cCiAgIHByb3ZpZGUgdGhlIG5lY2Vzc2FyeSBjZXJ0aWZpY2F0ZXMg bmVlZGVkIGZvciBlbmNyeXB0aW9uIHVzZWQgZm9yIHRoZVwKICAgUklEIHRyYW5zcG9ydCBwcm90 b2NvbCBbUkZDNjA0Nl0uXApcCiAgIFRoZSB1c2Ugb2YgcHJlLXNoYXJlZCBrZXlzIG1heSBiZSBj b25zaWRlcmVkIGZvciBhdXRoZW50aWNhdGlvbi4gIElmXAogICB0aGlzIG9wdGlvbiBpcyBzZWxl Y3RlZCwgdGhlIHNwZWNpZmljYXRpb25zIHNldCBmb3J0aCBpbiAiUHJlLVNoYXJlZFwKICAgS2V5 IENpcGhlcnN1aXRlcyBmb3IgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIiBbUkZDNDI3 OV0gTVVTVFwKICAgYmUgZm9sbG93ZWQuXApcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDU1XVwKXApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAg QXVndXN0IDIwMTFcClwKXAogICBIb3N0cyByZWNlaXZpbmcgYSBSSUQgbWVzc2FnZSBNVVNUIGJl IGFibGUgdG8gdmVyaWZ5IHRoYXQgdGhlIHNlbmRlclwKICAgb2YgdGhlIHJlcXVlc3QgaXMgdmFs aWQgYW5kIHRydXN0ZWQuICBVc2luZyBkaWdpdGFsIHNpZ25hdHVyZXMgb24gYVwKICAgaGFzaCBv ZiB0aGUgUklEIG1lc3NhZ2Ugd2l0aCBhbiBYLjUwOSB2ZXJzaW9uIDMgY2VydGlmaWNhdGUgaXNz dWVkIGJ5XAogICBhIHRydXN0ZWQgcGFydHkgTVVTVCBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0 aGUgcmVxdWVzdC4gIFRoZSBYLjUwOVwKICAgdmVyc2lvbiAzIHNwZWNpZmljYXRpb25zIGFzIHdl bGwgYXMgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlXAogICBzcGVjaWZpY2F0aW9ucyBhbmQgcGF0aCB2 YWxpZGF0aW9uIHN0YW5kYXJkcyBzZXQgZm9ydGggaW4gW1JGQzUyODBdXAogICBNVVNUIGJlIGZv bGxvd2VkIGluIG9yZGVyIHRvIGludGVyb3BlcmF0ZSB3aXRoIGEgUEtJIGRlc2lnbmVkIGZvclwK ICAgc2ltaWxhciBwdXJwb3Nlcy4gIFRoZSBJT0RFRiBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgZm9s bG93ZWQgZm9yXAogICBkaWdpdGFsIHNpZ25hdHVyZXMgdG8gcHJvdmlkZSB0aGUgYXV0aGVudGlj YXRpb24gYW5kIGludGVncml0eVwKICAgYXNwZWN0cyByZXF1aXJlZCBmb3Igc2VjdXJlIG1lc3Nh Z2luZyBiZXR3ZWVuIG5ldHdvcmsgcHJvdmlkZXJzLiAgVGhlXAogICB1c2Ugb2YgZGlnaXRhbCBz aWduYXR1cmVzIGluIFJJRCBYTUwgbWVzc2FnZXMgTVVTVCBmb2xsb3cgdGhlIFdvcmxkXAogICBX aWRlIFdlYiBDb25zb3J0aXVtIChXM0MpIHJlY29tbWVuZGF0aW9ucyBmb3Igc2lnbmF0dXJlIHN5 bnRheCBhbmRcCiAgIHByb2Nlc3Npbmcgd2hlbiBlaXRoZXIgdGhlIFhNTCBlbmNyeXB0aW9uIFtY TUxlbmNyeXB0XSBvciBkaWdpdGFsXAogICBzaWduYXR1cmUgW1hNTHNpZ10sIFtSRkMzMjc1XSBp cyB1c2VkIHdpdGhpbiBhIGRvY3VtZW50LiAgVHJhbnNwb3J0XAogICBzcGVjaWZpY2F0aW9ucyBh cmUgZGV0YWlsZWQgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBbUkZDNjA0Nl0uXApcCiAgIEl0IG1p Z2h0IGJlIGhlbHBmdWwgdG8gZGVmaW5lIGFuIGV4dGVuc2lvbiB0byB0aGUgYXV0aGVudGljYXRp b25cCiAgIHNjaGVtZSB0aGF0IHVzZXMgYXR0cmlidXRlIGNlcnRpZmljYXRlcyBbUkZDNTc1NV0g aW4gc3VjaCBhIHdheSB0aGF0XAogICBhbiBhcHBsaWNhdGlvbiBjb3VsZCBhdXRvbWF0aWNhbGx5 IGRldGVybWluZSB3aGV0aGVyIGh1bWFuXAogICBpbnRlcnZlbnRpb24gaXMgbmVlZGVkIHRvIGF1 dGhvcml6ZSBhIHJlcXVlc3Q7IGhvd2V2ZXIsIHRoZVwKICAgc3BlY2lmaWNhdGlvbiBvZiBzdWNo IGFuIGV4dGVuc2lvbiBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuXApcCjcuNC4x LiAgTXVsdGktSG9wIFRyYWNlUmVxdWVzdCBBdXRoZW50aWNhdGlvblwKXAogICBCaWxhdGVyYWwg dHJ1c3QgcmVsYXRpb25zIGJldHdlZW4gbmV0d29yayBwcm92aWRlcnMgZW5zdXJlIHRoZVwKICAg YXV0aGVudGljaXR5IG9mIHJlcXVlc3RzIGZvciBUcmFjZVJlcXVlc3RzIGZyb20gaW1tZWRpYXRl IHBlZXJzIGluXAogICB0aGUgd2ViIG9mIG5ldHdvcmtzIGZvcm1lZCB0byBwcm92aWRlIHRoZSB0 cmFjZWJhY2sgY2FwYWJpbGl0eS4gIEFcCiAgIG5ldHdvcmsgcHJvdmlkZXIgc2V2ZXJhbCBob3Bz IGludG8gdGhlIHBhdGggb2YgdGhlIFJJRCB0cmFjZSBtdXN0XAogICB0cnVzdCB0aGUgaW5mb3Jt YXRpb24gZnJvbSBpdHMgb3duIHRydXN0IHJlbGF0aW9uc2hpcHMgYXMgd2VsbCBhcyB0aGVcCiAg IHByZXZpb3VzIHRydXN0IHJlbGF0aW9uc2hpcHMgaW4gdGhlIGRvd25zdHJlYW0gcGF0aC4gIEZv ciBwcmFjdGljYWxcCiAgIHJlYXNvbnMsIHRoZSBTUHMgbWF5IHdhbnQgdG8gcHJpb3JpdGl6ZSBp bmNpZGVudCBoYW5kbGluZyBldmVudHNcCiAgIGJhc2VkIHVwb24gdGhlIGltbWVkaWF0ZSBwZWVy IGZvciBhIFRyYWNlUmVxdWVzdCwgdGhlIG9yaWdpbmF0b3IsIGFuZFwKICAgdGhlIGxpc3RlZCBD b25maWRlbmNlIHJhdGluZyBmb3IgdGhlIGluY2lkZW50LiAgSW4gb3JkZXIgdG8gcHJvdmlkZSBh XAogICBoaWdoZXIgYXNzdXJhbmNlIGxldmVsIG9mIHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIFRy YWNlUmVxdWVzdCwgdGhlXAogICBvcmlnaW5hdGluZyBSSUQgc3lzdGVtIGlzIGluY2x1ZGVkIGlu IHRoZSBUcmFjZVJlcXVlc3QgYWxvbmcgd2l0aFwKICAgY29udGFjdCBpbmZvcm1hdGlvbiBhbmQg dGhlIGluZm9ybWF0aW9uIG9mIGFsbCBSSUQgc3lzdGVtcyBpbiB0aGVcCiAgIHBhdGggdGhlIHRy YWNlIGhhcyB0YWtlbi4gIFRoaXMgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgdGhyb3VnaCB0aGVc CiAgIElPREVGIEV2ZW50RGF0YSBjbGFzcyBuZXN0aW5nIHRoZSBsaXN0IG9mIHN5c3RlbXMgYW5k IGNvbnRhY3RzXAogICBpbnZvbHZlZCBpbiBhIHRyYWNlLCB3aGlsZSBzZXR0aW5nIHRoZSBjYXRl Z29yeSBhdHRyaWJ1dGUgdG9cCiAgICJpbmZyYXN0cnVjdHVyZSIuXApcCiAgIEEgc2Vjb25kIG1l YXN1cmUgTVVTVCBiZSB0YWtlbiB0byBlbnN1cmUgdGhlIGlkZW50aXR5IG9mIHRoZVwKICAgb3Jp Z2luYXRpbmcgUklEIHN5c3RlbS4gIFRoZSBvcmlnaW5hdGluZyBSSUQgc3lzdGVtIE1VU1QgaW5j bHVkZSBhXAogICBkaWdpdGFsIHNpZ25hdHVyZSBpbiB0aGUgVHJhY2VSZXF1ZXN0IHNlbnQgdG8g YWxsIHN5c3RlbXMgaW4gdGhlXAogICB1cHN0cmVhbSBwYXRoLiAgVGhlIGRpZ2l0YWwgc2lnbmF0 dXJlIGZyb20gdGhlIFJJRCBzeXN0ZW0gaXNcCiAgIHBlcmZvcm1lZCBvbiB0aGUgUmVjb3JkSXRl bSBjbGFzcyBvZiB0aGUgSU9ERUYgZm9sbG93aW5nIHRoZSBYTUxcCiAgIGRpZ2l0YWwgc2lnbmF0 dXJlIHNwZWNpZmljYXRpb25zIGZyb20gVzNDIFtYTUxzaWddIHVzaW5nIGEgZGV0YWNoZWRcCiAg IHNpZ25hdHVyZS4gIFRoZSBzaWduYXR1cmUgTVVTVCBiZSBwYXNzZWQgdG8gYWxsIHBhcnRpZXMg dGhhdCByZWNlaXZlXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1Nl1cClwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApc ClwKICAgYSBUcmFjZVJlcXVlc3QsIGFuZCBlYWNoIHBhcnR5IE1VU1QgYmUgYWJsZSB0byBwZXJm b3JtIGZ1bGwgcGF0aFwKICAgdmFsaWRhdGlvbiBvbiB0aGUgZGlnaXRhbCBzaWduYXR1cmUuICBG dWxsIHBhdGggdmFsaWRhdGlvbiB2ZXJpZmllc1wKICAgdGhlIGNoYWluaW5nIHJlbGF0aW9uc2hp cCB0byBhIHRydXN0ZWQgcm9vdCBhbmQgYWxzbyBwZXJmb3JtcyBhXAogICBjZXJ0aWZpY2F0ZSBy ZXZvY2F0aW9uIGNoZWNrLiAgSW4gb3JkZXIgdG8gYWNjb21tb2RhdGUgdGhhdFwKICAgcmVxdWly ZW1lbnQsIHRoZSBJUCBwYWNrZXQgaW4gdGhlIFJlY29yZEl0ZW0gZGF0YSBNVVNUIHJlbWFpblwK ICAgdW5jaGFuZ2VkIGFzIGEgcmVxdWVzdCBpcyBwYXNzZWQgYWxvbmcgYmV0d2VlbiBwcm92aWRl cnMgYW5kIGlzIHRoZVwKICAgb25seSBlbGVtZW50IGZvciB3aGljaCB0aGUgc2lnbmF0dXJlIGlz IGFwcGxpZWQuICBJZiBhZGRpdGlvbmFsXAogICBwYWNrZXRzIGFyZSBpbmNsdWRlZCBpbiB0aGUg ZG9jdW1lbnQgYXQgdXBzdHJlYW0gcGVlcnMsIHRoZSBpbml0aWFsXAogICBwYWNrZXQgTVVTVCBz dGlsbCByZW1haW4gd2l0aCB0aGUgZGV0YWNoZWQgc2lnbmF0dXJlLiAgVGhlIHN1YnNlcXVlbnRc CiAgIHBhY2tldHMgbWF5IGJlIHNpZ25lZCBieSB0aGUgcGVlciBhZGRpbmcgdGhlIGluY2lkZW50 IGluZm9ybWF0aW9uIGZvclwKICAgdGhlIGludmVzdGlnYXRpb24uICBBIHNlY29uZCBiZW5lZml0 IHRvIHRoaXMgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGVcCiAgIGludGVncml0eSBvZiB0aGUgZmls dGVyIHVzZWQgaXMgZW5zdXJlZCBhcyBpdCBpcyBwYXNzZWQgdG8gc3Vic2VxdWVudFwKICAgU1Bz IGluIHRoZSB1cHN0cmVhbSB0cmFjZSBvZiB0aGUgcGFja2V0LiAgVGhlIHRydXN0ZWQgUEtJIGFs c29cCiAgIHByb3ZpZGVzIHRoZSBrZXlzIHVzZWQgdG8gZGlnaXRhbGx5IHNpZ24gdGhlIFJlY29y ZEl0ZW0gY2xhc3MgZm9yXAogICBUcmFjZVJlcXVlc3RzIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50 IG9mIGF1dGhlbnRpY2F0aW5nIHRoZSBvcmlnaW5hbFwKICAgcmVxdWVzdC4gIEFueSBob3N0IGlu IHRoZSBwYXRoIG9mIHRoZSB0cmFjZSBzaG91bGQgYmUgYWJsZSB0byB2ZXJpZnlcCiAgIHRoZSBk aWdpdGFsIHNpZ25hdHVyZSB1c2luZyB0aGUgdHJ1c3RlZCBQS0kuXApcCiAgIEluIHRoZSBjYXNl IGluIHdoaWNoIGFuIGVudGVycHJpc2UgbmV0d29yayB1c2luZyBSSUQgc2VuZHMgYVwKICAgVHJh Y2VSZXF1ZXN0IHRvIGl0cyBwcm92aWRlciwgdGhlIHNpZ25hdHVyZSBmcm9tIHRoZSBlbnRlcnBy aXNlXAogICBuZXR3b3JrIE1VU1QgYmUgaW5jbHVkZWQgaW4gdGhlIGluaXRpYWwgcmVxdWVzdC4g IFRoZSBTUCBtYXkgZ2VuZXJhdGVcCiAgIGEgbmV3IHJlcXVlc3QgdG8gc2VuZCB1cHN0cmVhbSB0 byBtZW1iZXJzIG9mIHRoZSBTUCBjb25zb3J0aXVtIHRvXAogICBjb250aW51ZSB0aGUgdHJhY2Uu ICBJZiB0aGUgb3JpZ2luYWwgcmVxdWVzdCBpcyBzZW50LCB0aGUgb3JpZ2luYXRpbmdcCiAgIFNQ LCBhY3Rpbmcgb24gYmVoYWxmIG9mIHRoZSBlbnRlcnByaXNlIG5ldHdvcmsgdW5kZXIgYXR0YWNr LCBNVVNUXAogICBhbHNvIGRpZ2l0YWxseSBzaWduLCB3aXRoIGFuIGVudmVsb3BlZCBzaWduYXR1 cmUsIHRoZSBmdWxsIElPREVGXAogICBkb2N1bWVudCB0byBhc3N1cmUgdGhlIGF1dGhlbnRpY2l0 eSBvZiB0aGUgVHJhY2VSZXF1ZXN0LiAgQW4gU1AgdGhhdFwKICAgb2ZmZXJzIFJJRCBhcyBhIHNl cnZpY2UgbWF5IGJlIHVzaW5nIGl0cyBvd24gUEtJIHRvIHNlY3VyZSBSSURcCiAgIGNvbW11bmlj YXRpb25zIGJldHdlZW4gaXRzIFJJRCBzeXN0ZW0gYW5kIHRoZSBhdHRhY2hlZCBlbnRlcnByaXNl XAogICBuZXR3b3Jrcy4gIFNQcyBwYXJ0aWNpcGF0aW5nIGluIHRoZSB0cmFjZSBNVVNUIGJlIGFi bGUgdG8gZGV0ZXJtaW5lXAogICB0aGUgYXV0aGVudGljaXR5IG9mIFJJRCByZXF1ZXN0cy5cClwK Ny41LiAgQ29uc29ydGl1bXMgYW5kIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmVzXApcCiAgIENv bnNvcnRpdW1zIG9mIFNQcyBhcmUgYW4gaWRlYWwgd2F5IHRvIGVzdGFibGlzaCBhIGNvbW11bmlj YXRpb24gd2ViXAogICBvZiB0cnVzdCBmb3IgUklEIG1lc3NhZ2luZy4gIFRoZSBjb25zb3J0aXVt IGNvdWxkIHByb3ZpZGUgY2VudHJhbGl6ZWRcCiAgIHJlc291cmNlcywgc3VjaCBhcyBhIFBLSSwg YW5kIGVzdGFibGlzaGVkIGd1aWRlbGluZXMgZm9yIHVzZSBvZiB0aGVcCiAgIFJJRCBwcm90b2Nv bC4gIFRoZSBjb25zb3J0aXVtIHdvdWxkIGFsc28gYXNzaXN0IGluIGVzdGFibGlzaGluZyB0cnVz dFwKICAgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHRoZSBwYXJ0aWNpcGF0aW5nIFNQcyB0byBhY2hp ZXZlIHRoZSBuZWNlc3NhcnlcCiAgIGxldmVsIG9mIGNvb3BlcmF0aW9uIGFuZCBleHBlcmllbmNl LXNoYXJpbmcgYW1vbmcgdGhlIGNvbnNvcnRpdW1cCiAgIGVudGl0aWVzLiAgVGhpcyBtYXkgYmUg ZXN0YWJsaXNoZWQgdGhyb3VnaCBQS0kgY2VydGlmaWNhdGUgcG9saWN5XAogICBbUkZDMzY0N10g cmV2aWV3cyB0byBkZXRlcm1pbmUgdGhlIGFwcHJvcHJpYXRlIHRydXN0IGxldmVscyBiZXR3ZWVu XAogICBvcmdhbml6YXRpb25zIG9yIGVudGl0aWVzLiAgVGhlIGNvbnNvcnRpdW0gbWF5IGFsc28g YmUgdXNlZCBmb3Igb3RoZXJcCiAgIHB1cnBvc2VzIHRvIGJldHRlciBmYWNpbGl0YXRlIGNvbW11 bmljYXRpb24gYW1vbmcgU1BzIGluIGEgY29tbW9uXAogICBhcmVhIChJbnRlcm5ldCwgcmVnaW9u LCBnb3Zlcm5tZW50LCBlZHVjYXRpb24sIHByaXZhdGUgbmV0d29ya3MsXAogICBldGMuKS5cClwK ICAgVXNpbmcgYSBQS0kgdG8gZGlzdHJpYnV0ZSBjZXJ0aWZpY2F0ZXMgdXNlZCBieSBSSUQgc3lz dGVtcyBwcm92aWRlc1wKICAgYW4gYWxyZWFkeSBlc3RhYmxpc2hlZCBtZXRob2QgdG8gbGluayB0 cnVzdCByZWxhdGlvbnNoaXBzIGJldHdlZW4gU1BzXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1N11cClwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDExXApcClwKICAgb2YgY29uc29ydGl1bXMgdGhhdCB3b3VsZCBwZWVyIHdp dGggU1BzIGJlbG9uZ2luZyB0byBhIHNlcGFyYXRlXAogICBjb25zb3J0aXVtLiAgSW4gb3RoZXIg d29yZHMsIGNvbnNvcnRpdW1zIGNvdWxkIHBlZXIgd2l0aCBvdGhlclwKICAgY29uc29ydGl1bXMg dG8gZW5hYmxlIGNvbW11bmljYXRpb24gb2YgUklEIG1lc3NhZ2VzIGJldHdlZW4gdGhlXAogICBw YXJ0aWNpcGF0aW5nIFNQcy4gIFRoZSBQS0kgYWxvbmcgd2l0aCBNZW1vcmFuZHVtcyBvZiBBZ3Jl ZW1lbnQgY291bGRcCiAgIGJlIHVzZWQgdG8gbGluayBib3JkZXIgZGlyZWN0b3JpZXMgdG8gc2hh cmUgcHVibGljIGtleSBpbmZvcm1hdGlvbiBpblwKICAgYSBicmlkZ2UsIGEgaGllcmFyY2h5LCBv ciBhIHNpbmdsZSBjcm9zcy1jZXJ0aWZpY2F0aW9uIHJlbGF0aW9uc2hpcC5cClwKICAgQ29uc29y dGl1bXMgYWxzbyBuZWVkIHRvIGVzdGFibGlzaCBndWlkZWxpbmVzIGZvciBlYWNoIHBhcnRpY2lw YXRpbmdcCiAgIFNQIHRvIGFkaGVyZSB0by4gIFRoZSBSRUNPTU1FTkRFRCBndWlkZWxpbmVzIGlu Y2x1ZGU6XApcCiAgIG8gIFBoeXNpY2FsIGFuZCBsb2dpY2FsIHByYWN0aWNlcyB0byBwcm90ZWN0 IFJJRCBzeXN0ZW1zO1wKXAogICBvICBOZXR3b3JrIGFuZCBhcHBsaWNhdGlvbiBsYXllciBwcm90 ZWN0aW9uIGZvciBSSUQgc3lzdGVtcyBhbmRcCiAgICAgIGNvbW11bmljYXRpb25zO1wKXAogICBv ICBQcm9wZXIgdXNlIGd1aWRlbGluZXMgZm9yIFJJRCBzeXN0ZW1zLCBtZXNzYWdlcywgYW5kIHJl cXVlc3RzOyBhbmRcClwKICAgbyAgQSBQS0kgdG8gcHJvdmlkZSBhdXRoZW50aWNhdGlvbiwgaW50 ZWdyaXR5LCBhbmQgcHJpdmFjeS5cClwKICAgVGhlIGZ1bmN0aW9ucyBkZXNjcmliZWQgZm9yIGEg Y29uc29ydGl1bSdzIHJvbGUgd291bGQgcGFyYWxsZWwgdGhhdFwKICAgb2YgYSBQS0kgZmVkZXJh dGlvbi4gIFRoZSBQS0kgZmVkZXJhdGlvbnMgdGhhdCBjdXJyZW50bHkgZXhpc3QgYXJlXAogICBy ZXNwb25zaWJsZSBmb3IgZXN0YWJsaXNoaW5nIHNlY3VyaXR5IGd1aWRlbGluZXMgYW5kIFBLSSB0 cnVzdFwKICAgbW9kZWxzLiAgVGhlIHRydXN0IG1vZGVscyBhcmUgdXNlZCB0byBzdXBwb3J0IGFw cGxpY2F0aW9ucyB0byBzaGFyZVwKICAgaW5mb3JtYXRpb24gdXNpbmcgdHJ1c3RlZCBtZXRob2Rz IGFuZCBwcm90b2NvbHMuXApcCiAgIEEgUEtJIGNhbiBhbHNvIHByb3ZpZGUgdGhlIHNhbWUgbGV2 ZWwgb2Ygc2VjdXJpdHkgZm9yIGNvbW11bmljYXRpb25cCiAgIGJldHdlZW4gYW4gZW5kIGVudGl0 eSAoZW50ZXJwcmlzZSwgZWR1Y2F0aW9uYWwsIG9yIGdvdmVybm1lbnRcCiAgIGN1c3RvbWVyIG5l dHdvcmspIGFuZCB0aGUgU1AuICBUaGUgUEtJIG1heSBiZSBhIHN1Ym9yZGluYXRlIENBIG9yIGlu XAogICB0aGUgQ0EgaGllcmFyY2h5IGZyb20gdGhlIFNQJ3MgY29uc29ydGl1bSB0byBlc3RhYmxp c2ggdGhlIHRydXN0XAogICByZWxhdGlvbnNoaXBzIG5lY2Vzc2FyeSBhcyB0aGUgcmVxdWVzdCBp cyBtYWRlIHRvIG90aGVyIGNvbm5lY3RlZFwKICAgbmV0d29ya3MuXApcCjcuNi4gIFByaXZhY3kg Q29uY2VybnMgYW5kIFN5c3RlbSBVc2UgR3VpZGVsaW5lc1wKXAogICBQcml2YWN5IGlzc3VlcyBy YWlzZSBtYW55IGNvbmNlcm5zIHdoZW4gaW5mb3JtYXRpb24tc2hhcmluZyBpc1wKICAgcmVxdWly ZWQgdG8gYWNoaWV2ZSB0aGUgZ29hbCBvZiBzdG9wcGluZyBvciBtaXRpZ2F0aW5nIHRoZSBlZmZl Y3RzIG9mXAogICBhIHNlY3VyaXR5IGluY2lkZW50LiAgVGhlIFJJRFBvbGljeSBjbGFzcyBpcyB1 c2VkIHRvIGF1dG9tYXRlIHRoZVwKICAgZW5mb3JjZW1lbnQgb2YgdGhlIHByaXZhY3kgY29uY2Vy bnMgbGlzdGVkIHdpdGhpbiB0aGlzIGRvY3VtZW50LiAgVGhlXAogICBwcml2YWN5IGFuZCBzeXN0 ZW0gdXNlIGNvbmNlcm5zIHRoYXQgTVVTVCBiZSBhZGRyZXNzZWQgaW4gdGhlIFJJRFwKICAgc3lz dGVtIGFuZCBvdGhlciBpbnRlZ3JhdGVkIGNvbXBvbmVudHMgaW5jbHVkZSB0aGUgZm9sbG93aW5n OlwKXAogICBOZXR3b3JrIFByb3ZpZGVyIENvbmNlcm5zOlwKXAogICBvICBQcml2YWN5IG9mIGRh dGEgbW9uaXRvcmVkIGFuZC9vciBzdG9yZWQgb24gSURTcyBmb3IgYXR0YWNrXAogICAgICBkZXRl Y3Rpb24uXApcCiAgIG8gIFByaXZhY3kgb2YgZGF0YSBtb25pdG9yZWQgYW5kIHN0b3JlZCBvbiBz eXN0ZW1zIHVzZWQgdG8gdHJhY2VcCiAgICAgIHRyYWZmaWMgYWNyb3NzIGEgc2luZ2xlIG5ldHdv cmsuXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAy MDEyICAgICAgICAgICAgICBbUGFnZSA1OF1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgQ3Vz dG9tZXIgQXR0YWNoZWQgTmV0d29ya3MgUGFydGljaXBhdGluZyBpbiBSSUQgd2l0aCBTUDpcClwK ICAgbyAgQ3VzdG9tZXIgbmV0d29ya3MgbWF5IGluY2x1ZGUgYW4gZW50ZXJwcmlzZSwgZWR1Y2F0 aW9uYWwsXAogICAgICBnb3Zlcm5tZW50LCBvciBvdGhlciBhdHRhY2hlZCBuZXR3b3JrcyB0byBh biBTUCBwYXJ0aWNpcGF0aW5nIGluXAogICAgICBSSUQgYW5kIE1VU1QgYmUgbWFkZSBmdWxseSBh d2FyZSBvZiB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3lcCiAgICAgIGNvbnNpZGVyYXRpb25zIGZv ciB1c2luZyBSSUQuXApcCiAgIG8gIEN1c3RvbWVycyBNVVNUIGtub3cgdGhlIHNlY3VyaXR5IGFu ZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGluXAogICAgICBwbGFjZSBieSB0aGVpciBTUCBhbmQg dGhlIGNvbnNvcnRpdW0gb2Ygd2hpY2ggdGhlIFNQIGlzIGEgbWVtYmVyLlwKXAogICBvICBDdXN0 b21lcnMgTVVTVCB1bmRlcnN0YW5kIHRoYXQgdGhlaXIgZGF0YSBjYW4gYW5kIHdpbGwgYmUgc2Vu dCB0b1wKICAgICAgb3RoZXIgU1BzIGluIG9yZGVyIHRvIGNvbXBsZXRlIGEgdHJhY2UgdW5sZXNz IGFuIGFncmVlbWVudCBzdGF0aW5nXAogICAgICBvdGhlcndpc2UgaXMgbWFkZSBpbiB0aGUgc2Vy dmljZSBsZXZlbCBhZ3JlZW1lbnRzIGJldHdlZW4gdGhlXAogICAgICBjdXN0b21lciBhbmQgU1Au XApcCiAgIFBhcnRpZXMgSW52b2x2ZWQgaW4gdGhlIEF0dGFjazpcClwKICAgbyAgUHJpdmFjeSBv ZiB0aGUgaWRlbnRpdHkgb2YgYSBob3N0IGludm9sdmVkIGluIGFuIGF0dGFjay5cClwKICAgbyAg UHJpdmFjeSBvZiBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9u IHVzZWQgZm9yXAogICAgICBjb21tdW5pY2F0aW9uIHB1cnBvc2VzIG92ZXIgdGhlIG1vbml0b3Jl ZCBvciBSSUQgY29ubmVjdGVkXAogICAgICBuZXR3b3JrKHMpLlwKXAogICBvICBQcm90ZWN0aW9u IG9mIGRhdGEgZnJvbSBiZWluZyB2aWV3ZWQgYnkgaW50ZXJtZWRpYXRlIHBhcnRpZXMgaW5cCiAg ICAgIHRoZSBwYXRoIG9mIGFuIEludmVzdGlnYXRpb24gcmVxdWVzdCBNVVNUIGJlIGNvbnNpZGVy ZWQuXApcCiAgIENvbnNvcnRpdW0gQ29uc2lkZXJhdGlvbnM6XApcCiAgIG8gIFN5c3RlbSB1c2Ug cmVzdHJpY3RlZCB0byBzZWN1cml0eSBpbmNpZGVudCBoYW5kbGluZyB3aXRoaW4gdGhlXAogICAg ICBsb2NhbCByZWdpb24ncyBkZWZpbml0aW9ucyBvZiBhcHByb3ByaWF0ZSB0cmFmZmljIGZvciB0 aGUgbmV0d29ya1wKICAgICAgbW9uaXRvcmVkIGFuZCBsaW5rZWQgdmlhIFJJRCBpbiBhIHNpbmds ZSBjb25zb3J0aXVtIGFsc28gYWJpZGluZ1wKICAgICAgYnkgdGhlIGNvbnNvcnRpdW0ncyB1c2Ug Z3VpZGVsaW5lcy5cClwKICAgbyAgU3lzdGVtIHVzZSBwcm9oaWJpdGluZyB0aGUgY29uc29ydGl1 bSdzIHBhcnRpY2lwYXRpbmcgU1BzIGZyb21cCiAgICAgIGluYXBwcm9wcmlhdGVseSB0cmFjaW5n IG5vbi1hdHRhY2sgdHJhZmZpYyB0byBsb2NhdGUgc291cmNlcyBvclwKICAgICAgbWl0aWdhdGUg dHJhZmZpYyB1bmxhd2Z1bGx5IHdpdGhpbiB0aGUganVyaXNkaWN0aW9uIG9yIHJlZ2lvbi5cClwK ICAgSW50ZXItQ29uc29ydGl1bSBDb25zaWRlcmF0aW9uczpcClwKICAgbyAgU3lzdGVtIHVzZSBi ZXR3ZWVuIHBlZXJpbmcgY29uc29ydGl1bXMgTVVTVCBhbHNvIGFkaGVyZSB0byBhbnlcCiAgICAg IGdvdmVybm1lbnQgY29tbXVuaWNhdGlvbiByZWd1bGF0aW9ucyB0aGF0IGFwcGx5IGJldHdlZW4g dGhvc2UgdHdvXAogICAgICByZWdpb25zLCBzdWNoIGFzIGVuY3J5cHRpb24gZXhwb3J0IGFuZCBp bXBvcnQgcmVzdHJpY3Rpb25zLiAgVGhpc1wKICAgICAgbWF5IGluY2x1ZGUgY29uc29ydGl1bXMg dGhhdCBhcmUgY2F0ZWdvcml6ZWQgYXNcCiAgICAgICJCZXR3ZWVuQ29uc29ydGl1bXMiIG9yICJB Y3Jvc3NOYXRpb25hbEJvdW5kYXJpZXMiLlwKXAogICBvICBTeXN0ZW0gdXNlIGJldHdlZW4gY29u c29ydGl1bXMgTVVTVCBOT1QgcmVxdWVzdCB0cmFmZmljIHRyYWNlcyBhbmRcCiAgICAgIGFjdGlv bnMgYmV5b25kIHRoZSBzY29wZSBpbnRlbmRlZCBhbmQgcGVybWl0dGVkIGJ5IGxhdyBvciBpbnRl ci1cCiAgICAgIGNvbnNvcnRpdW0gYWdyZWVtZW50cy5cClwKXApcCk1vcmlhcnR5ICAgICAgICAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDU5XVwK XApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAg ICAgICAgQXVndXN0IDIwMTFcClwKXAogICBvICBTeXN0ZW0gdXNlIGJldHdlZW4gY29uc29ydGl1 bXMgY2xhc3NpZmllZCBhc1wKICAgICAgIkFjcm9zc05hdGlvbmFsQm91bmRhcmllcyIgTVVTVCBy ZXNwZWN0IG5hdGlvbmFsIGJvdW5kYXJ5IGlzc3Vlc1wKICAgICAgYW5kIGxpbWl0IHJlcXVlc3Rz IHRvIGFwcHJvcHJpYXRlIHN5c3RlbSB1c2UgYW5kIG5vdCB0byBhY2hpZXZlXAogICAgICB0aGVp ciBvd24gYWdlbmRhIHRvIGxpbWl0IG9yIHJlc3RyaWN0IHRyYWZmaWMgdGhhdCBpcyBvdGhlcndp c2VcCiAgICAgIHBlcm1pdHRlZCB3aXRoaW4gdGhlIGNvdW50cnkgaW4gd2hpY2ggdGhlIHBlZXJp bmcgY29uc29ydGl1bVwKICAgICAgcmVzaWRlcy5cClwKICAgVGhlIHNlY3VyaXR5IGFuZCBwcml2 YWN5IGNvbnNpZGVyYXRpb25zIGxpc3RlZCBhYm92ZSBhcmUgZm9yIHRoZVwKICAgY29uc29ydGl1 bXMsIFNQcywgYW5kIGVudGVycHJpc2VzIHRvIGFncmVlIHVwb24uICBUaGUgYWdyZWVkLXVwb25c CiAgIHBvbGljaWVzIG1heSBiZSBmYWNpbGl0YXRlZCB0aHJvdWdoIHVzZSBvZiB0aGUgUklEUG9s aWN5IGNsYXNzLiAgU29tZVwKICAgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBhcmUgYWRkcmVzc2Vk IHRocm91Z2ggdGhlIFJJRCBndWlkZWxpbmVzIGZvclwKICAgZW5jcnlwdGlvbiBhbmQgZGlnaXRh bCBzaWduYXR1cmVzIGFzIGRlc2NyaWJlZCBhdCB0aGUgYmVnaW5uaW5nIG9mXAogICBTZWN0aW9u IDYuXApcCiAgIFJJRCBpcyB1c2VmdWwgaW4gZGV0ZXJtaW5pbmcgdGhlIHRydWUgc291cmNlIG9m IGEgcGFja2V0IHRoYXRcCiAgIHRyYXZlcnNlcyBtdWx0aXBsZSBuZXR3b3JrcyBvciB0byBjb21t dW5pY2F0ZSBzZWN1cml0eSBpbmNpZGVudHMgYW5kXAogICBhdXRvbWF0ZSB0aGUgcmVzcG9uc2Uu ICBUaGUgaW5mb3JtYXRpb24gb2J0YWluZWQgZnJvbSB0aGUgdHJhY2UgbWF5XAogICBkZXRlcm1p bmUgdGhlIGlkZW50aXR5IG9mIHRoZSBzb3VyY2UgaG9zdCBvciB0aGUgbmV0d29yayBwcm92aWRl clwKICAgdXNlZCBieSB0aGUgc291cmNlIG9mIHRoZSB0cmFmZmljLiAgSXQgc2hvdWxkIGJlIG5v dGVkIHRoYXQgdGhlIHRyYWNlXAogICBtZWNoYW5pc20gdXNlZCBhY3Jvc3MgYSBzaW5nbGUtbmV0 d29yayBwcm92aWRlciBtYXkgYWxzbyByYWlzZVwKICAgcHJpdmFjeSBjb25jZXJucyBmb3IgdGhl IGNsaWVudHMgb2YgdGhlIG5ldHdvcmsuICBNZXRob2RzIHRoYXQgbWF5XAogICByYWlzZSBjb25j ZXJuIGluY2x1ZGUgdGhvc2UgdGhhdCBpbnZvbHZlIHN0b3JpbmcgcGFja2V0cyBmb3Igc29tZVwK ICAgbGVuZ3RoIG9mIHRpbWUgaW4gb3JkZXIgdG8gdHJhY2UgcGFja2V0cyBhZnRlciB0aGUgZmFj dC4gIE1vbml0b3JpbmdcCiAgIG5ldHdvcmtzIGZvciBpbnRydXNpb25zIGFuZCBmb3IgdHJhY2lu ZyBjYXBhYmlsaXRpZXMgYWxzbyByYWlzZXNcCiAgIGNvbmNlcm5zIGZvciBwb3RlbnRpYWxseSBz ZW5zaXRpdmUgdmFsaWQgdHJhZmZpYyB0aGF0IG1heSBiZVwKICAgdHJhdmVyc2luZyB0aGUgbW9u aXRvcmVkIG5ldHdvcmsuICBJRFNzIGFuZCBzaW5nbGUtbmV0d29yayB0cmFjaW5nXAogICBhcmUg b3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCwgYnV0IHRoZSBjb25jZXJuIHNo b3VsZCBiZVwKICAgbm90ZWQgYW5kIGFkZHJlc3NlZCB3aXRoaW4gdGhlIHVzZSBndWlkZWxpbmVz IG9mIHRoZSBuZXR3b3JrLiAgU29tZVwKICAgSURTcyBhbmQgc2luZ2xlLW5ldHdvcmsgdHJhY2Ug bWVjaGFuaXNtcyBhdHRlbXB0IHRvIHByb3Blcmx5IGFkZHJlc3NcCiAgIHRoZXNlIGlzc3Vlcy4g IFJJRCBpcyBkZXNpZ25lZCB0byBwcm92aWRlIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgYnlcCiAg IGFueSBzaW5nbGUtbmV0d29yayB0cmFjZSBtZWNoYW5pc20uICBUaGUgcHJvdmlkZXIncyBjaG9p Y2Ugb2YgYVwKICAgc2luZ2xlIHRyYWNlIG1lY2hhbmlzbSBkZXBlbmRzIG9uIHJlc291cmNlcywg ZXhpc3Rpbmcgc29sdXRpb25zLCBhbmRcCiAgIGxvY2FsIGxlZ2lzbGF0aW9uLiAgUHJpdmFjeSBj b25jZXJucyBpbiByZWdhcmQgdG8gdGhlIHNpbmdsZS1uZXR3b3JrXAogICB0cmFjZSBtdXN0IGJl IGRlYWx0IHdpdGggYXQgdGhlIGNsaWVudC10by1TUCBsZXZlbCBhbmQgYXJlIG91dCBvZlwKICAg c2NvcGUgZm9yIFJJRCBtZXNzYWdpbmcuXApcCiAgIFRoZSBpZGVudGl0eSBvZiB0aGUgdHJ1ZSBz b3VyY2Ugb2YgYW4gYXR0YWNrIHBhY2tldCBiZWluZyB0cmFjZWRcCiAgIHRocm91Z2ggUklEIGNv dWxkIGJlIHNlbnNpdGl2ZS4gIFRoZSB0cnVlIGlkZW50aXR5IGxpc3RlZCBpbiBhIFJlc3VsdFwK ICAgbWVzc2FnZSBjYW4gYmUgcHJvdGVjdGVkIHRocm91Z2ggdGhlIHVzZSBvZiBlbmNyeXB0aW9u IFtYTUxlbmNyeXB0XVwKICAgZW52ZWxvcGluZyB0aGUgSU9ERUYgZG9jdW1lbnQgYW5kIFJJRCBS ZXN1bHQgaW5mb3JtYXRpb24sIHVzaW5nIHRoZVwKICAgcHVibGljIGVuY3J5cHRpb24ga2V5IG9m IHRoZSBvcmlnaW5hdGluZyBTUC4gIEFsdGVybmF0aXZlbHksIHRoZVwKICAgYWN0aW9uIHRha2Vu IG1heSBiZSBsaXN0ZWQgd2l0aG91dCB0aGUgaWRlbnRpdHkgYmVpbmcgcmV2ZWFsZWQgdG8gdGhl XAogICBvcmlnaW5hdGluZyBTUC4gIFRoZSB1bHRpbWF0ZSBnb2FsIG9mIHRoZSBSSUQgY29tbXVu aWNhdGlvbiBzeXN0ZW0gaXNcCiAgIHRvIHN0b3Agb3IgbWl0aWdhdGUgYXR0YWNrIHRyYWZmaWMs IG5vdCB0byBlbnN1cmUgdGhhdCB0aGUgaWRlbnRpdHlcCiAgIG9mIHRoZSBhdHRhY2sgdHJhZmZp YyBpcyBrbm93biB0byBpbnZvbHZlZCBwYXJ0aWVzLiAgVGhlIFNQIHRoYXRcCiAgIGlkZW50aWZp ZXMgdGhlIHNvdXJjZSBzaG91bGQgZGVhbCBkaXJlY3RseSB3aXRoIHRoZSBpbnZvbHZlZCBwYXJ0 aWVzXAogICBhbmQgcHJvcGVyIGF1dGhvcml0aWVzIGluIG9yZGVyIHRvIGRldGVybWluZSB0aGUg Z3VpZGVsaW5lcyBmb3IgdGhlXAogICByZWxlYXNlIG9mIHN1Y2ggaW5mb3JtYXRpb24sIGlmIGl0 IGlzIHJlZ2FyZGVkIGFzIHNlbnNpdGl2ZS4gIEluIHNvbWVcClwKXApcCk1vcmlhcnR5ICAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDYw XVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAg ICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBzaXR1YXRpb25zLCBzeXN0ZW1zIHVzZWQgaW4g YXR0YWNrcyBhcmUgY29tcHJvbWlzZWQgYnkgYW4gdW5rbm93blwKICAgc291cmNlIGFuZCwgaW4g dHVybiwgYXJlIHVzZWQgdG8gYXR0YWNrIG90aGVyIHN5c3RlbXMuICBJbiB0aGF0XAogICBzaXR1 YXRpb24sIHRoZSByZXB1dGF0aW9uIG9mIGEgYnVzaW5lc3Mgb3Igb3JnYW5pemF0aW9uIG1heSBi ZSBhdFwKICAgc3Rha2UsIGFuZCB0aGUgYWN0aW9uIHRha2VuIG1heSBiZSB0aGUgb25seSBhZGRp dGlvbmFsIGluZm9ybWF0aW9uXAogICByZXBvcnRlZCBpbiB0aGUgUmVzdWx0IG1lc3NhZ2UgdG8g dGhlIG9yaWdpbmF0aW5nIHN5c3RlbS4gIElmIHRoZVwKICAgc2VjdXJpdHkgaW5jaWRlbnQgaXMg YSBtaW5vciBpbmNpZGVudCwgc3VjaCBhcyBhIHpvbWJpZSBzeXN0ZW0gdXNlZFwKICAgaW4gcGFy dCBvZiBhIGxhcmdlLXNjYWxlIEREb1MgYXR0YWNrLCBlbnN1cmluZyB0aGUgc3lzdGVtIGlzIHRh a2VuXAogICBvZmYgdGhlIG5ldHdvcmsgdW50aWwgaXQgaGFzIGJlZW4gZml4ZWQgbWF5IGJlIHN1 ZmZpY2llbnQuICBUaGVcCiAgIGRlY2lzaW9uIGlzIGxlZnQgdG8gdGhlIHN5c3RlbSB1c2VycyBh bmQgY29uc29ydGl1bXMgdG8gZGV0ZXJtaW5lXAogICBhcHByb3ByaWF0ZSBkYXRhIHRvIGJlIHNo YXJlZCBnaXZlbiB0aGF0IHRoZSBnb2FsIG9mIHRoZVwKICAgc3BlY2lmaWNhdGlvbiBpcyB0byBw cm92aWRlIHRoZSBhcHByb3ByaWF0ZSB0ZWNobmljYWwgb3B0aW9ucyB0b1wKICAgcmVtYWluIGNv bXBsaWFudC4gIFRoZSB0ZXh0dWFsIGRlc2NyaXB0aW9ucyBzaG91bGQgaW5jbHVkZSBkZXRhaWxz IG9mXAogICB0aGUgaW5jaWRlbnQgaW4gb3JkZXIgdG8gcHJvdGVjdCB0aGUgcmVwdXRhdGlvbiBv ZiB0aGUgdW5rbm93aW5nXAogICBhdHRhY2tlciBhbmQgcHJldmVudCB0aGUgbmVlZCBmb3IgYWRk aXRpb25hbCBpbnZlc3RpZ2F0aW9uLiAgTG9jYWwsXAogICBzdGF0ZSwgb3IgbmF0aW9uYWwgbGF3 cyBtYXkgZGljdGF0ZSB0aGUgYXBwcm9wcmlhdGUgcmVwb3J0aW5nIGFjdGlvblwKICAgZm9yIHNw ZWNpZmljIHNlY3VyaXR5IGluY2lkZW50cy5cClwKICAgUHJpdmFjeSBiZWNvbWVzIGFuIGlzc3Vl IHdoZW5ldmVyIHNlbnNpdGl2ZSBkYXRhIHRyYXZlcnNlcyBhIG5ldHdvcmsuXAogICBGb3IgZXhh bXBsZSwgaWYgYW4gYXR0YWNrIG9jY3VycmVkIGJldHdlZW4gYSBzcGVjaWZpYyBzb3VyY2UgYW5k XAogICBkZXN0aW5hdGlvbiwgdGhlbiBldmVyeSBuZXR3b3JrIHByb3ZpZGVyIGluIHRoZSBwYXRo IG9mIHRoZSB0cmFjZVwKICAgd291bGQgYmVjb21lIGF3YXJlIHRoYXQgdGhlIGN5YmVyIGF0dGFj ayBvY2N1cnJlZC4gIEluIGEgdGFyZ2V0ZWRcCiAgIGF0dGFjaywgaXQgbWF5IG5vdCBiZSBkZXNp cmFibGUgdGhhdCBpbmZvcm1hdGlvbiBhYm91dCB0d28gbmF0aW9uXAogICBzdGF0ZXMgdGhhdCBh cmUgYmF0dGxpbmcgYSBjeWJlciB3YXIgd291bGQgYmVjb21lIGdlbmVyYWwga25vd2xlZGdlXAog ICB0byBhbGwgaW50ZXJtZWRpYXRlIHBhcnRpZXMuICBIb3dldmVyLCBpdCBpcyBpbXBvcnRhbnQg dG8gYWxsb3cgdGhlXAogICB0cmFjZXMgdG8gdGFrZSBwbGFjZSBpbiBvcmRlciB0byBoYWx0IHRo ZSBhY3Rpdml0eSBzaW5jZSB0aGUgaGVhbHRoXAogICBvZiB0aGUgbmV0d29ya3MgaW4gdGhlIHBh dGggY291bGQgYWxzbyBiZSBhdCBzdGFrZSBkdXJpbmcgdGhlIGF0dGFjay5cCiAgIFRoaXMgcHJv dmlkZXMgYSBzZWNvbmQgYXJndW1lbnQgZm9yIGFsbG93aW5nIHRoZSBSZXN1bHQgbWVzc2FnZSB0 b1wKICAgb25seSBpbmNsdWRlIGFuIGFjdGlvbiB0YWtlbiBhbmQgbm90IHRoZSBpZGVudGl0eSBv ZiB0aGUgb2ZmZW5kaW5nXAogICBob3N0LiAgSW4gdGhlIGNhc2Ugb2YgYW4gSW52ZXN0aWdhdGlv biByZXF1ZXN0LCB3aGVyZSB0aGUgb3JpZ2luYXRpbmdcCiAgIFNQIGlzIGF3YXJlIG9mIHRoZSBT UCB0aGF0IHdpbGwgcmVjZWl2ZSB0aGUgcmVxdWVzdCBmb3IgcHJvY2Vzc2luZyxcCiAgIHRoZSBm cmVlLWZvcm0gdGV4dCBhcmVhcyBvZiB0aGUgZG9jdW1lbnQgY291bGQgYmUgZW5jcnlwdGVkXAog ICBbWE1MZW5jcnlwdF0gdXNpbmcgdGhlIHB1YmxpYyBrZXkgb2YgdGhlIGRlc3RpbmF0aW9uIFNQ IHRvIGVuc3VyZVwKICAgdGhhdCBubyBvdGhlciBTUCBpbiB0aGUgcGF0aCBjYW4gcmVhZCB0aGUg Y29udGVudHMuICBUaGUgZW5jcnlwdGlvblwKICAgd291bGQgYmUgYWNjb21wbGlzaGVkIHRocm91 Z2ggdGhlIFczQyBbWE1MZW5jcnlwdF0gc3BlY2lmaWNhdGlvbiBmb3JcCiAgIGVuY3J5cHRpbmcg YW4gZWxlbWVudC5cClwKICAgSW4gc29tZSBzaXR1YXRpb25zLCBhbGwgbmV0d29yayB0cmFmZmlj IG9mIGEgbmF0aW9uIG1heSBiZSBncmFudGVkXAogICB0aHJvdWdoIGEgc2luZ2xlIG5ldHdvcmsg cHJvdmlkZXIuICBJbiB0aGF0IHNpdHVhdGlvbiwgb3B0aW9ucyBtdXN0XAogICBzdXBwb3J0IHNl bmRpbmcgUmVzdWx0IG1lc3NhZ2VzIGZyb20gYSBkb3duc3RyZWFtIHBlZXIgb2YgdGhhdFwKICAg bmV0d29yayBwcm92aWRlci4gIFRoYXQgb3B0aW9uIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgbGV2 ZWwgb2ZcCiAgIGFic3RyYWN0aW9uIHRvIGhpZGUgdGhlIGlkZW50aXR5IGFuZCB0aGUgU1Agb2Yg dGhlIGlkZW50aWZpZWQgc291cmNlXAogICBvZiB0aGUgdHJhZmZpYy4gIExlZ2FsIGFjdGlvbiBt YXkgb3ZlcnJpZGUgdGhpcyB0ZWNobmljYWwgZGVjaXNpb25cCiAgIGFmdGVyIHRoZSB0cmFjZSBo YXMgdGFrZW4gcGxhY2UsIGJ1dCB0aGF0IGlzIG91dCBvZiB0aGUgdGVjaG5pY2FsXAogICBzY29w ZSBvZiB0aGlzIGRvY3VtZW50LlwKXAogICBQcml2YWN5IGNvbmNlcm5zIHdoZW4gdXNpbmcgYW4g SW52ZXN0aWdhdGlvbiByZXF1ZXN0IHRvIHJlcXVlc3RcCiAgIGFjdGlvbiBjbG9zZSB0byB0aGUg c291cmNlIG9mIHZhbGlkIGF0dGFjayB0cmFmZmljIG5lZWRzIHRvIGJlXAogICBjb25zaWRlcmVk LiAgQWx0aG91Z2ggdGhlIGludGVybWVkaWF0ZSBTUHMgbWF5IHJlbGF5IHRoZSByZXF1ZXN0IGlm XApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwLCAyMDEy ICAgICAgICAgICAgICBbUGFnZSA2MV1cClwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg IFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgdGhlcmUg aXMgbm8gZGlyZWN0IHRydXN0IHJlbGF0aW9uc2hpcCB0byB0aGUgY2xvc2VzdCBTUCB0byB0aGVc CiAgIHNvdXJjZSwgdGhlIGludGVybWVkaWF0ZSBTUHMgZG8gbm90IHJlcXVpcmUgdGhlIGFiaWxp dHkgdG8gc2VlIHRoZVwKICAgY29udGVudHMgb2YgdGhlIHBhY2tldCBvciB0aGUgdGV4dCBkZXNj cmlwdGlvbiBmaWVsZChzKSBpbiB0aGVcCiAgIHJlcXVlc3QuICBUaGlzIG1lc3NhZ2UgdHlwZSBk b2VzIG5vdCByZXF1aXJlIGFueSBhY3Rpb24gYnkgdGhlXAogICBpbnRlcm1lZGlhdGUgUklEIHN5 c3RlbXMsIGV4Y2VwdCB0byByZWxheSB0aGUgcGFja2V0IHRvIHRoZSBuZXh0IFNQXAogICBpbiB0 aGUgcGF0aC4gIFRoZXJlZm9yZSwgdGhlIGNvbnRlbnRzIG9mIHRoZSByZXF1ZXN0IG1heSBiZSBl bmNyeXB0ZWRcCiAgIGZvciB0aGUgZGVzdGluYXRpb24gc3lzdGVtLiAgVGhlIGludGVybWVkaWF0 ZSBTUHMgd291bGQgb25seSBuZWVkIHRvXAogICBrbm93IGhvdyB0byBkaXJlY3QgdGhlIHJlcXVl c3QgdG8gdGhlIG1hbmFnZXIgb2YgdGhlIEFTTiBpbiB3aGljaCB0aGVcCiAgIHNvdXJjZSBJUCBh ZGRyZXNzIGJlbG9uZ3MuXApcCiAgIFRyYWNlcyBtdXN0IGJlIGxlZ2l0aW1hdGUgc2VjdXJpdHkt cmVsYXRlZCBpbmNpZGVudHMgYW5kIG5vdCB1c2VkIGZvclwKICAgcHVycG9zZXMgc3VjaCBhcyBz YWJvdGFnZSBvciBjZW5zb3JzaGlwLiAgQW4gZXhhbXBsZSBvZiBzdWNoIGFidXNlIG9mXAogICB0 aGUgc3lzdGVtIHdvdWxkIGluY2x1ZGUgYSByZXF1ZXN0IHRvIGJsb2NrIG9yIHJhdGUtbGltaXQg bGVnaXRpbWF0ZVwKICAgdHJhZmZpYyB0byBwcmV2ZW50IGluZm9ybWF0aW9uIGZyb20gYmVpbmcg c2hhcmVkIGJldHdlZW4gdXNlcnMgb24gdGhlXAogICBJbnRlcm5ldCAocmVzdHJpY3RpbmcgYWNj ZXNzIHRvIG9ubGluZSB2ZXJzaW9ucyBvZiBwYXBlcnMpIG9yXAogICByZXN0cmljdGluZyBhY2Nl c3MgZnJvbSBhIGNvbXBldGl0b3IncyBwcm9kdWN0IGluIG9yZGVyIHRvIHNhYm90YWdlIGFcCiAg IGJ1c2luZXNzLlwKXAogICBJbnRyYS1jb25zb3J0aXVtIFJJRCBjb21tdW5pY2F0aW9ucyByYWlz ZSBhZGRpdGlvbmFsIGlzc3VlcyxcCiAgIGVzcGVjaWFsbHkgd2hlbiB0aGUgcGVlcmluZyBjb25z b3J0aXVtcyByZXNpZGUgaW4gZGlmZmVyZW50IHJlZ2lvbnNcCiAgIG9yIG5hdGlvbnMuICBUcmFj ZVJlcXVlc3RzIGFuZCByZXF1ZXN0ZWQgYWN0aW9ucyB0byBtaXRpZ2F0ZSB0cmFmZmljXAogICBt dXN0IGFkaGVyZSB0byB0aGUgYXBwcm9wcmlhdGUgdXNlIGd1aWRlbGluZXMgYW5kIHlldCBwcmV2 ZW50IGFidXNlXAogICBvZiB0aGUgc3lzdGVtLiAgRmlyc3QsIHRoZSBwZWVyaW5nIGNvbnNvcnRp dW1zIE1VU1QgaWRlbnRpZnkgdGhlXAogICB0eXBlcyBvZiB0cmFmZmljIHRoYXQgY2FuIGJlIHRy YWNlZCBiZXR3ZWVuIHRoZSBib3JkZXJzIG9mIHRoZVwKICAgcGFydGljaXBhdGluZyBTUHMgb2Yg ZWFjaCBjb25zb3J0aXVtLiAgVGhlIHRyYWZmaWMgdHJhY2VkIHNob3VsZCBiZVwKICAgbGltaXRl ZCB0byBzZWN1cml0eS1pbmNpZGVudC1yZWxhdGVkIHRyYWZmaWMuICBTZWNvbmQsIHRoZSB0cmFj ZXNcCiAgIHBlcm1pdHRlZCB3aXRoaW4gb25lIGNvbnNvcnRpdW0gaWYgcGFzc2VkIHRvIGEgcGVl cmluZyBjb25zb3J0aXVtIG1heVwKICAgaW5mcmluZ2UgdXBvbiB0aGUgcGVlcmluZyBjb25zb3J0 aXVtJ3MgZnJlZWRvbSBvZiBpbmZvcm1hdGlvbiBsYXdzLlwKICAgQW4gZXhhbXBsZSB3b3VsZCBi ZSBhIGNvbnNvcnRpdW0gaW4gb25lIGNvdW50cnkgcGVybWl0dGluZyBhIHRyYWNlIG9mXAogICB0 cmFmZmljIGNvbnRhaW5pbmcgb2JqZWN0aW9uYWJsZSBtYXRlcmlhbCwgb3V0bGF3ZWQgd2l0aGlu IHRoYXRcCiAgIGNvdW50cnkuICBUaGUgUklEIHRyYWNlIG1heSBiZSBhIHZhbGlkIHVzZSBvZiB0 aGUgc3lzdGVtIHdpdGhpbiB0aGVcCiAgIGNvbmZpbmVzIG9mIHRoYXQgY291bnRyeSdzIG5ldHdv cmsgYm9yZGVyOyBob3dldmVyLCBpdCBtYXkgbm90IGJlXAogICBwZXJtaXR0ZWQgdG8gY29udGlu dWUgYWNyb3NzIG5ldHdvcmsgYm91bmRhcmllcyB3aGVyZSBzdWNoIGNvbnRlbnQgaXNcCiAgIHBl cm1pdHRlZCB1bmRlciBsYXcuICBCeSBjb250aW51aW5nIHRoZSB0cmFjZSBpbiBhbm90aGVyIGNv dW50cnknc1wKICAgbmV0d29yaywgdGhlIHRyYWNlIGFuZCByZXNwb25zZSBjb3VsZCBoYXZlIHRo ZSBlZmZlY3Qgb2YgaW1wcm9wZXJseVwKICAgcmVzdHJpY3RpbmcgYWNjZXNzIHRvIGRhdGEuICBB IGNvbnRpbnVlZCB0cmFjZSBpbnRvIGEgc2Vjb25kIGNvdW50cnlcCiAgIG1heSBicmVhayB0aGUg bGF3cyBhbmQgcmVndWxhdGlvbnMgb2YgdGhhdCBuYXRpb24uICBBbnkgc3VjaCB0cmFjZXNcCiAg IE1VU1QgY2Vhc2UgYXQgdGhlIGNvdW50cnkncyBib3JkZXIuXApcCiAgIFRoZSBwcml2YWN5IGNv bmNlcm5zIGxpc3RlZCBpbiB0aGlzIHNlY3Rpb24gYWRkcmVzcyBpc3N1ZXMgYW1vbmcgdGhlXAog ICB0cnVzdGVkIHBhcnRpZXMgaW52b2x2ZWQgaW4gYSB0cmFjZSB3aXRoaW4gYW4gU1AsIGEgUklE IGNvbnNvcnRpdW0sXAogICBhbmQgcGVlcmluZyBSSUQgY29uc29ydGl1bXMuICBEYXRhIHVzZWQg Zm9yIFJJRCBjb21tdW5pY2F0aW9ucyBtdXN0XAogICBhbHNvIGJlIHByb3RlY3RlZCBmcm9tIHBh cnRpZXMgdGhhdCBhcmUgbm90IHRydXN0ZWQuICBUaGlzIHByb3RlY3Rpb25cCiAgIGlzIHByb3Zp ZGVkIHRocm91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIG9mIGRvY3VtZW50 cyBhc1wKICAgdGhleSB0cmF2ZXJzZSB0aGUgcGF0aCBvZiB0cnVzdGVkIHNlcnZlcnMuICBFYWNo IFJJRCBzeXN0ZW0gTVVTVFwKICAgcGVyZm9ybSBhIGJpLWRpcmVjdGlvbmFsIGF1dGhlbnRpY2F0 aW9uIHdoZW4gc2VuZGluZyBhIFJJRCBtZXNzYWdlXAogICBhbmQgdXNlIHRoZSBwdWJsaWMgZW5j cnlwdGlvbiBrZXkgb2YgdGhlIHVwc3RyZWFtIG9yIGRvd25zdHJlYW0gcGVlclwKICAgdG8gc2Vu ZCBhIG1lc3NhZ2Ugb3IgZG9jdW1lbnQgb3ZlciB0aGUgbmV0d29yay4gIFRoaXMgbWVhbnMgdGhh dCB0aGVcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAs IDIwMTIgICAgICAgICAgICAgIFtQYWdlIDYyXVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBk b2N1bWVudCBpcyBkZWNyeXB0ZWQgYW5kIHJlLWVuY3J5cHRlZCBhdCBlYWNoIFJJRCBzeXN0ZW0g dmlhIFRMU1wKICAgb3ZlciB0aGUgdHJhbnNwb3J0IHByb3RvY29sIFtSRkM2MDQ2XS4gIFRoZSBS SUQgbWVzc2FnZXMgbWF5IGJlXAogICBkZWNyeXB0ZWQgYXQgZWFjaCBSSUQgc3lzdGVtIGluIG9y ZGVyIHRvIHByb3Blcmx5IHByb2Nlc3MgdGhlIHJlcXVlc3RcCiAgIG9yIHJlbGF5IHRoZSBpbmZv cm1hdGlvbi4gIFRvZGF5J3MgcHJvY2Vzc2luZyBwb3dlciBpcyBtb3JlIHRoYW5cCiAgIHN1ZmZp Y2llbnQgdG8gaGFuZGxlIHRoZSBtaW5pbWFsIGJ1cmRlbiBvZiBlbmNyeXB0aW5nIGFuZCBkZWNy eXB0aW5nXAogICByZWxhdGl2ZWx5IHNtYWxsIHR5cGljYWwgUklEIG1lc3NhZ2VzLlwKXApcCjgu ICBJQU5BIENvbnNpZGVyYXRpb25zXApcCiAgIFRoaXMgZG9jdW1lbnQgdXNlcyBVUk5zIHRvIGRl c2NyaWJlIFhNTCBuYW1lc3BhY2VzIGFuZCBYTUwgc2NoZW1hc1wKICAgW1hNTHNjaGVtYV0gY29u Zm9ybWluZyB0byBhIHJlZ2lzdHJ5IG1lY2hhbmlzbSBkZXNjcmliZWQgaW5cCiAgIFtSRkMzNjg4 XS5cClwKICAgUmVnaXN0cmF0aW9uIHJlcXVlc3QgZm9yIHRoZSBpb2RlZi1yaWQgbmFtZXNwYWNl OlwKXAogICBVUkk6IHVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtcmlkLTEuMFwKXAogICBS ZWdpc3RyYW50IENvbnRhY3Q6IFNlZSB0aGUgIkF1dGhvcidzIEFkZHJlc3MiIHNlY3Rpb24gb2Yg dGhpc1wKICAgZG9jdW1lbnQuXApcCiAgIFhNTDogTm9uZS4gIE5hbWVzcGFjZSBVUklzIGRvIG5v dCByZXByZXNlbnQgYW4gWE1MIHNwZWNpZmljYXRpb24uXApcCiAgIFJlZ2lzdHJhdGlvbiByZXF1 ZXN0IGZvciB0aGUgaW9kZWYtcmlkIFhNTCBzY2hlbWE6XApcCiAgIFVSSTogdXJuOmlldGY6cGFy YW1zOnhtbDpzY2hlbWE6aW9kZWYtcmlkLTEuMFwKXAogICBSZWdpc3RyYW50IENvbnRhY3Q6IFNl ZSB0aGUgIkF1dGhvcidzIEFkZHJlc3MiIHNlY3Rpb24gb2YgdGhpc1wKICAgZG9jdW1lbnQuXApc CiAgIFhNTDogU2VlIFNlY3Rpb24gNSwgIlJJRCBTY2hlbWEgRGVmaW5pdGlvbiIsIG9mIHRoaXMg ZG9jdW1lbnQuXApcClwKOS4gIFN1bW1hcnlcClwKICAgU2VjdXJpdHkgaW5jaWRlbnRzIGhhdmUg YWx3YXlzIGJlZW4gZGlmZmljdWx0IHRvIHRyYWNlIGFzIGEgcmVzdWx0IG9mXAogICB0aGUgc3Bv b2ZlZCBzb3VyY2VzLCByZXNvdXJjZSBsaW1pdGF0aW9ucywgYW5kIGJhbmR3aWR0aCB1dGlsaXph dGlvblwKICAgcHJvYmxlbXMuICBJbmNpZGVudCByZXNwb25zZSBpcyBvZnRlbiBzbG93IGV2ZW4g d2hlbiB0aGUgSVAgYWRkcmVzc1wKICAgaXMga25vd24gdG8gYmUgdmFsaWQgYmVjYXVzZSBvZiB0 aGUgcmVzb3VyY2VzIHJlcXVpcmVkIHRvIG5vdGlmeSB0aGVcCiAgIHJlc3BvbnNpYmxlIHBhcnR5 IG9mIHRoZSBhdHRhY2sgYW5kIHRoZW4gdG8gc3RvcCBvciBtaXRpZ2F0ZSB0aGVcCiAgIGF0dGFj ayB0cmFmZmljLiAgTWV0aG9kcyB0byBpZGVudGlmeSBhbmQgdHJhY2UgYXR0YWNrcyBuZWFyIHJl YWwgdGltZVwKICAgYXJlIGVzc2VudGlhbCB0byB0aHdhcnRpbmcgYXR0YWNrIGF0dGVtcHRzLiAg TmV0d29yayBwcm92aWRlcnMgbmVlZFwKICAgcG9saWNpZXMgYW5kIGF1dG9tYXRlZCBtZXRob2Rz IHRvIGNvbWJhdCB0aGUgaGFja2VyJ3MgZWZmb3J0cy4gIFNQc1wKICAgbmVlZCBhdXRvbWF0ZWQg bW9uaXRvcmluZyBhbmQgcmVzcG9uc2UgY2FwYWJpbGl0aWVzIHRvIGlkZW50aWZ5IGFuZFwKICAg dHJhY2UgYXR0YWNrcyBxdWlja2x5IHdpdGhvdXQgcmVzb3VyY2UtaW50ZW5zaXZlIHNpZGUgZWZm ZWN0cy5cCiAgIEludGVncmF0aW9uIHdpdGggYSBjZW50cmFsaXplZCBjb21tdW5pY2F0aW9uIHN5 c3RlbSB0byBjb29yZGluYXRlIHRoZVwKICAgZGV0ZWN0aW9uLCB0cmFjaW5nLCBhbmQgaWRlbnRp ZmljYXRpb24gb2YgYXR0YWNrIHNvdXJjZXMgb24gYSBzaW5nbGVcCiAgIG5ldHdvcmsgaXMgZXNz ZW50aWFsLiAgUklEIHByb3ZpZGVzIGEgd2F5IHRvIGludGVncmF0ZSBTUCByZXNvdXJjZXNcClwK XApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDYzXVwKXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZD NjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBmb3IgZWFjaCBh c3BlY3Qgb2YgYXR0YWNrIGRldGVjdGlvbiwgdHJhY2luZywgYW5kIHNvdXJjZVwKICAgaWRlbnRp ZmljYXRpb24gYW5kIGV4dGVuZHMgdGhlIGNvbW11bmljYXRpb24gY2FwYWJpbGl0aWVzIGFtb25n XAogICBuZXR3b3JrIHByb3ZpZGVycy4gIFRoZSBjb21tdW5pY2F0aW9uIGlzIGFjY29tcGxpc2hl ZCB0aHJvdWdoIHRoZSB1c2VcCiAgIG9mIGZsZXhpYmxlIElPREVGIFhNTC1iYXNlZCBkb2N1bWVu dHMgcGFzc2VkIGJldHdlZW4gSUhTcyBvciBSSURcCiAgIHN5c3RlbXMuICBBIFRyYWNlUmVxdWVz dCBvciBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgaXMgY29tbXVuaWNhdGVkIHRvXAogICBhbiB1cHN0 cmVhbSBTUCBhbmQgbWF5IHJlc3VsdCBpbiBhbiB1cHN0cmVhbSB0cmFjZSBvciBpbiBhbiBhY3Rp b24gdG9cCiAgIHN0b3Agb3IgbWl0aWdhdGUgdGhlIGF0dGFjayB0cmFmZmljLiAgVGhlIG1lc3Nh Z2VzIGFyZSBjb21tdW5pY2F0ZWRcCiAgIGFtb25nIHBlZXJzIHdpdGggc2VjdXJpdHkgaW5oZXJl bnQgdG8gdGhlIFJJRCBtZXNzYWdpbmcgc2NoZW1lXAogICBwcm92aWRlZCB0aHJvdWdoIGV4aXN0 aW5nIHN0YW5kYXJkcyBzdWNoIGFzIFhNTCBlbmNyeXB0aW9uIGFuZFwKICAgZGlnaXRhbCBzaWdu YXR1cmVzLiAgUG9saWN5IGluZm9ybWF0aW9uIGlzIGNhcnJpZWQgaW4gdGhlIFJJRCBtZXNzYWdl XAogICBpdHNlbGYgdGhyb3VnaCB0aGUgdXNlIG9mIHRoZSBSSURQb2xpY3kuICBSSUQgcHJvdmlk ZXMgdGhlIHRpbWVseVwKICAgY29tbXVuaWNhdGlvbiBhbW9uZyBTUHMsIHdoaWNoIGlzIGVzc2Vu dGlhbCBmb3IgaW5jaWRlbnQgaGFuZGxpbmcuXApcClwKMTAuICBSZWZlcmVuY2VzXApcCjEwLjEu ICBOb3JtYXRpdmUgUmVmZXJlbmNlc1wKXAogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5 IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZVwKICAgICAgICAgICAgICBSZXF1aXJl bWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LlwKXAogICBbUkZDMzI3 NV0gIEVhc3RsYWtlLCBELiwgUmVhZ2xlLCBKLiwgYW5kIEQuIFNvbG8sICIoRXh0ZW5zaWJsZSBN YXJrdXBcCiAgICAgICAgICAgICAgTGFuZ3VhZ2UpIFhNTC1TaWduYXR1cmUgU3ludGF4IGFuZCBQ cm9jZXNzaW5nIiwgUkZDIDMyNzUsXAogICAgICAgICAgICAgIE1hcmNoIDIwMDIuXApcCiAgIFtS RkMzNjg4XSAgTWVhbGxpbmcsIE0uLCAiVGhlIElFVEYgWE1MIFJlZ2lzdHJ5IiwgQkNQIDgxLCBS RkMgMzY4OCxcCiAgICAgICAgICAgICAgSmFudWFyeSAyMDA0LlwKXAogICBbUkZDNDI3OV0gIEVy b25lbiwgUC4gYW5kIEguIFRzY2hvZmVuaWcsICJQcmUtU2hhcmVkIEtleSBDaXBoZXJzdWl0ZXNc CiAgICAgICAgICAgICAgZm9yIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSIsIFJGQyA0 Mjc5LFwKICAgICAgICAgICAgICBEZWNlbWJlciAyMDA1LlwKXAogICBbUkZDNTA3MF0gIERhbnls aXcsIFIuLCBNZWlqZXIsIEouLCBhbmQgWS4gRGVtY2hlbmtvLCAiVGhlIEluY2lkZW50XAogICAg ICAgICAgICAgIE9iamVjdCBEZXNjcmlwdGlvbiBFeGNoYW5nZSBGb3JtYXQiLCBSRkMgNTA3MCxc CiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNy5cClwKICAgW1JGQzUyODBdICBDb29wZXIsIEQu LCBTYW50ZXNzb24sIFMuLCBGYXJyZWxsLCBTLiwgQm9leWVuLCBTLixcCiAgICAgICAgICAgICAg SG91c2xleSwgUi4sIGFuZCBXLiBQb2xrLCAiSW50ZXJuZXQgWC41MDkgUHVibGljIEtleVwKICAg ICAgICAgICAgICBJbmZyYXN0cnVjdHVyZSBDZXJ0aWZpY2F0ZSBhbmQgQ2VydGlmaWNhdGUgUmV2 b2NhdGlvbiBMaXN0XAogICAgICAgICAgICAgIChDUkwpIFByb2ZpbGUiLCBSRkMgNTI4MCwgTWF5 IDIwMDguXApcCiAgIFtSRkM1NzU1XSAgRmFycmVsbCwgUy4sIEhvdXNsZXksIFIuLCBhbmQgUy4g VHVybmVyLCAiQW4gSW50ZXJuZXRcCiAgICAgICAgICAgICAgQXR0cmlidXRlIENlcnRpZmljYXRl IFByb2ZpbGUgZm9yIEF1dGhvcml6YXRpb24iLFwKICAgICAgICAgICAgICBSRkMgNTc1NSwgSmFu dWFyeSAyMDEwLlwKXAogICBbUkZDNjA0NV0gIE1vcmlhcnR5LCBLLiwgIlJlYWwtdGltZSBJbnRl ci1uZXR3b3JrIERlZmVuc2UgKFJJRCkiLFwKICAgICAgICAgICAgICBSRkMgNjA0NSwgTm92ZW1i ZXIgMjAxMC5cClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjRdXApcCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApc CiAgIFtSRkM2MDQ2XSAgTW9yaWFydHksIEsuIGFuZCBCLiBUcmFtbWVsbCwgIlRyYW5zcG9ydCBv ZiBSZWFsLXRpbWVcCiAgICAgICAgICAgICAgSW50ZXItbmV0d29yayBEZWZlbnNlIChSSUQpIE1l c3NhZ2VzIiwgUkZDIDYwNDYsXAogICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTAuXApcCjEwLjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzXApcCiAgIFtSRkMxOTMwXSAgSGF3a2luc29uLCBKLiBh bmQgVC4gQmF0ZXMsICJHdWlkZWxpbmVzIGZvciBjcmVhdGlvbixcCiAgICAgICAgICAgICAgc2Vs ZWN0aW9uLCBhbmQgcmVnaXN0cmF0aW9uIG9mIGFuIEF1dG9ub21vdXMgU3lzdGVtIChBUykiLFwK ICAgICAgICAgICAgICBCQ1AgNiwgUkZDIDE5MzAsIE1hcmNoIDE5OTYuXApcCiAgIFtSRkMyODI3 XSAgRmVyZ3Vzb24sIFAuIGFuZCBELiBTZW5pZSwgIk5ldHdvcmsgSW5ncmVzcyBGaWx0ZXJpbmc6 XAogICAgICAgICAgICAgIERlZmVhdGluZyBEZW5pYWwgb2YgU2VydmljZSBBdHRhY2tzIHdoaWNo IGVtcGxveSBJUCBTb3VyY2VcCiAgICAgICAgICAgICAgQWRkcmVzcyBTcG9vZmluZyIsIEJDUCAz OCwgUkZDIDI4MjcsIE1heSAyMDAwLlwKXAogICBbUkZDMzY0N10gIENob2toYW5pLCBTLiwgRm9y ZCwgVy4sIFNhYmV0dCwgUi4sIE1lcnJpbGwsIEMuLCBhbmQgUy5cCiAgICAgICAgICAgICAgV3Us ICJJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIENlcnRpZmljYXRlXAog ICAgICAgICAgICAgIFBvbGljeSBhbmQgQ2VydGlmaWNhdGlvbiBQcmFjdGljZXMgRnJhbWV3b3Jr IiwgUkZDIDM2NDcsXAogICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMuXApcCiAgIFtSRkMzOTE3 XSAgUXVpdHRlaywgSi4sIFpzZWJ5LCBULiwgQ2xhaXNlLCBCLiwgYW5kIFMuIFphbmRlcixcCiAg ICAgICAgICAgICAgIlJlcXVpcmVtZW50cyBmb3IgSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQg KElQRklYKSIsXAogICAgICAgICAgICAgIFJGQyAzOTE3LCBPY3RvYmVyIDIwMDQuXApcCiAgIFtS RkM1NzM1XSAgQ290dG9uLCBNLiBhbmQgTC4gVmVnb2RhLCAiU3BlY2lhbCBVc2UgSVB2NCBBZGRy ZXNzZXMiLFwKICAgICAgICAgICAgICBCQ1AgMTUzLCBSRkMgNTczNSwgSmFudWFyeSAyMDEwLlwK XApcCkF1dGhvcidzIEFkZHJlc3NcClwKICAgS2F0aGxlZW4gTS4gTW9yaWFydHlcCiAgIEVNQyBD b3Jwb3JhdGlvblwKICAgMTc2IFNvdXRoIFN0cmVldFwKICAgSG9wa2ludG9uLCBNQVwKICAgVW5p dGVkIFN0YXRlc1wKXAogICBQaG9uZTpcCiAgIEVtYWlsOiBLYXRobGVlbi5Nb3JpYXJ0eUBlbWMu Y29tXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAg RXhwaXJlcyBGZWJydWFyeSAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjVdXApcClwKfQ== --_002_AE31510960917D478171C79369B660FA0E051CE7F2MX06Acorpemcc_-- From david.black@emc.com Tue Aug 23 09:41:05 2011 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 BB75E21F8783 for ; Tue, 23 Aug 2011 09:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 cK-2pH99fY72 for ; Tue, 23 Aug 2011 09:41:04 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id AECB621F8591 for ; Tue, 23 Aug 2011 09:41:01 -0700 (PDT) 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 p7NGg9tA000522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Aug 2011 12:42:09 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 23 Aug 2011 12:41:53 -0400 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 p7NGfobS025550 for ; Tue, 23 Aug 2011 12:41:52 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 23 Aug 2011 12:41:51 -0400 From: To: , Date: Tue, 23 Aug 2011 12:41:51 -0400 Thread-Topic: RFC6045-bis, update per ITU comments and list discussions Thread-Index: AQHMXo5mIaSIRvdFOEiwAnJNhOiIG5UqncUg Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions 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, 23 Aug 2011 16:41:05 -0000 Hi Kathleen, > "LawEnforcement" was added as a RIDPolicy option in text and in schema. = This was added as a result of > some on and off-list discussions as the option is relevant today for Law = enforcement that already > accepts incidents in an IODEF format. IODEF is required in Japan when se= nding incidents to law > enforcement. That seems very general in isolation, as there are a lot of law enforcement= agencies. Is a single ENUM value sufficient, or is it useful to distinguish regional,= national and/or other law enforcement bodies? At a minimum, it would be useful to include a reminder that use of "LawEnfo= rcement" does not remove the requirement to additionally use "AcrossNationalBoundaries" w= hen the later also applies. -- XML Digital Signature This text is not clear to me: > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. Is that one signature covering all the EventData from every party involved,= or is each party supposed to supply a signature for the EventData contributed by that = party? I suspect the latter was intended (e.g., as I have no idea why Alice should b= e signing event data from Bob that she can't independently verify), so some rephrasin= g is probably in order. -- XML Encryption I'm somewhat concerned that the new XML Encryption text is requiring use of= keys without saying anything about key distribution or management. While mandating spec= ific key distribution and/or management protocols would be overly restrictive, it wo= uld be good to provide some guidance on what needs to be done for some level of assuran= ce that the encryption is done with the correct key and the intended recipient(s) (but = not other parties) will be able to decrypt the result. For example: (1) "private" uses a public key of the recipient. How does the sender verif= y the binding of the public key to the recipient's identity? A discussion of how to use a= certificate to do that (e.g., where's the recipient's identity in the RID/IODEF XML, how i= s it supposed to match which field in the certificate) with a suitable PKIX RFC reference wo= uld be helpful. A reminder to check for revocation (e.g., of the certificate) before using = a public key would also be good. (2) "need-to-know" allows use of a group-shared symmetric encryption key th= at is somehow distributed to the recipients. That's potentially dangerous if not careful= ly controlled, and as this is the "Security Considerations" section, some security conside= rations for that distribution are probably in order, starting with a warning that she who ha= s the symmetric key can decrypt, making control of that key vital to confidentiality of the= need-to-know information. Is there a straightforward way to optionally handle key distr= ibution in the IODEF/RID document (e.g., an XML section that contains the symmetric key en= crypted with each of the intended recipients' public keys)?=20 The "Characteristics of an Attack" material might be usefully recast as gui= dance for use of RID, which could be an appendix. Something to keep in mind when editing the next version is that this versio= n has a mix of IETF requirements key words (MUST/SHOULD/MAY) and non-IETF requirements = key works (shall/should/may) - picking one set would probably be better, and if ITU r= equires use of the latter, an explanation that maps them to their IETF counterparts wou= ld be good. Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of k= athleen.moriarty@emc.com > Sent: Friday, August 19, 2011 12:38 PM > To: MILE@ietf.org > Subject: [mile] RFC6045-bis, update per ITU comments and list discussions >=20 > Hello, >=20 > The attached is an updated version of RFC6045 (RFC6045-bis) which is up f= or determination in the ITU-T > in two weeks. As a result, of the ITU-T determination, the document need= s to move to standards track > and a -bis version is required. The ITU has requested text changes since= the document will be > translated into a number of other languages, those changes are reflected = in this version. Additional > textual changes may be made over the next two weeks through their review = process. >=20 > A few changes to RID have been made per comments on this list and I would= like to get opinions on how > they are addressed in the attached, specifically on the changes outlined = below: >=20 > "LawEnforcement" was added as a RIDPolicy option in text and in schema. = This was added as a result of > some on and off-list discussions as the option is relevant today for Law = enforcement that already > accepts incidents in an IODEF format. IODEF is required in Japan when se= nding incidents to law > enforcement. >=20 > Through Dr. Katherine Goodier and Gaus (Damir Rajnovic) work on the priva= cy and data marking > extension, they determined stricter guidance was needed for encryption op= tions. Guidance has been > added to the Security section for X ML encryption using the already defin= ed IODEF:restriction > attribute. The text is as follows for ease of review: >=20 > ________ > Security, XML encryption section: > o The iodef:restriction attribute sets expectations for the privacy > of an incident and is defined in section 3.2 of RFC5070. The > restriction attribute can be set in any of the RID classes to > define restrictions for the complete exchange of an IODEF document > (including any extensions) or within specific classes of IODEF or > IODEF extensions where more limited restrictions are desired. The > restriction attribute is contained in each of the RID classes and > MUST be used in accordance with privacy expectations for either > sections of the IODEF document or the complete IODEF document. > Consortiums and organizations should consider this guidance when > creating exchange policies. > o Expectations based on restriction setting: > * If restriction is set to "private", the class or document MUST > be encrypted for the recipient using XML encryption and the > public key of the recipient. > * If restriction is set to "need-to-know", the class or document > MUST be encrypted to ensure only those with need-to-know access > can decrypt the data. The document can either be encrypted for > each individual for which access is intended or a single group > key may be used. A group key in this instance refers to a > single key (symmetric) that is used to encrypt the block of > data. The users with need-to-know access privileges may be > given access to the shared key by distributing or providing > access to it encrypted with each of their public keys. > * If restriction is set to "public", the class or document MUST > be sent in clear text. This setting can be critical if certain > sections of a document or an entire document are to be shared > without restrictions. This provides flexibility within an > incident to share out certain information freely where > appropriate. > * If restriction is set to "default", The information can be > shared according to an information disclosure policy pre- > arranged by the communicating parties. > o Expectations based on placement of the restriction setting: > * If restriction is set within one of the RID classes, the > restriction applies to the entire IODEF document. > * If restriction is set within individual IODEF classes, the > restriction applies to the specific IODEF class and the > children of that class. > _________ >=20 > Since incidents may not be network-centric and may still have a use case = where the information > received is not directly from the originator, the digital signature on th= e IP packet may need an > alternate option for verifying the source. I am proposing the use of Eve= ntData where each party that > adds to the event data would provide a detached digital signature. Anoth= er option (not in the > document) would be to include a default IP packet, bit I think that could= be confusing. The text is > as follows: >=20 > ________ > Security, XML Digital Signature Section: > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. The > EventData class can be used to extend information about an > incident by each CSIRT or SP involved in the investigation. Using > this class for the digital signature when an IP Packet is not > included provides a method to verify each party contributing to > the details of the incident. > _________ >=20 >=20 > Sections removed: > 1.3, Attack Types and RID Messaging, > Section 2, RID Integration with Network Provider Technologies > 3 Characteristics of an Attack and subsections - should this be in an app= endix or where it was in the > document? > Section on RID Communication flow removed text as it was not relevant to = the > heading, may need to be moved to subsections if content is not addressed > already >=20 > Some sections were re-ordered, I will go back to update section reference= s in the next version. >=20 >=20 >=20 > Thank you in advance! >=20 > Kathleen From takeshi_takahashi@nict.go.jp Wed Aug 24 01:08:11 2011 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 4F87621F8AD3 for ; Wed, 24 Aug 2011 01:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R10bVyvoXCQ for ; Wed, 24 Aug 2011 01:08:09 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FC21F8ACC for ; Wed, 24 Aug 2011 01:08:09 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id p7O89GIl022022; Wed, 24 Aug 2011 17:09:16 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id p7O89Gfp025213; Wed, 24 Aug 2011 17:09:16 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id p7O89DFN025210; Wed, 24 Aug 2011 17:09:14 +0900 (JST) From: "Takeshi Takahashi" To: , References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> Date: Wed, 24 Aug 2011 09:09:47 +0100 Message-ID: <013601cc6235$3196b1d0$94c41570$@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: AQHZoScn83GYsZh9CRcfWQQM2pwT0QIjvf2BAWjmAmcB6FiKg5TkTB2g Content-Language: ja Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information 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, 24 Aug 2011 08:08:11 -0000 Hi David, Thanks for your email. 1) >> Maybe we could use ENUM (instead of ML_STRING), and enumerate possible specifications. >> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use >> ENUM for dtype and FraudType description. > > That sounds like a good approach - each RFC that registers a value for the ENUM should include a pointer to the XML Schema for that specification as part of making the registration with IANA (the IANA registry entry will reference the RFC for the details). This may help recipients ensure that they have local copies of the XML schemas necessary to parse expected content. Thank you for telling me the IANA issue. I appreciate that. 2) >> So, my assumption here is that a complete CVE (compatible with its >> schema) will be embedded here. > > I don't have a problem with that assumption, but think it should be stated because that conclusion is not obvious [well, at least not to me ;-) ]. It should be sufficient to state that the embedded element is a complete XML document that is formatted according to the schema referenced by the IANA registration of the ENUM value used for SpecificationName (see item 1). I see. I will. Thank you. >My concern is similar to item 1) - how does the recipient parse and check the version number? >The rules for this need to be precise, otherwise there may be unexpected string compare results. It'd be good if the version number could be extracted from the XML Schema for the embedded content (and hence >take advantage of the rules in the referenced specification for the syntax of [Specification]Version). > >A simple (silly) example of what can go wrong is that OVAL is currently at version 5.10 - that's not the same as 5.1, but if it's converted to a number, the result is easy to misparse it as being equivalent to 5.1 ;-). Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if the '.' causes problems in some tooling? All of these are easy for a human to sort out, but potential causes of problems in automated tools. Yes, I agree. To clarify this issue, I'll add a sentence "parsers are expected to read the namespace of the embedded structured information and identify specification name and data, whenever such information is available, and parse the embedded data." Then one potential question we might have is, do we need the SpecificationName and SpecificationVersion elements? If the namespace described in the embedded structured information identify the specification name and its version, one might think these elements are useless. However, in my opinion, we still need these elements since some of the embedded information could be non-xml in the future. Thank you. Take -----Original Message----- From: david.black@emc.com [mailto:david.black@emc.com] Sent: Tuesday, August 16, 2011 10:15 AM To: takeshi_takahashi@nict.go.jp; mile@ietf.org Subject: RE: [mile] draft on IODEF extension to support structured cybersecurity information Hi Take, Enjoy your vacation, here are some comments to look at when you return: 1) > Maybe we could use ENUM (instead of ML_STRING), and enumerate possible specifications. > For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > ENUM for dtype and FraudType description. That sounds like a good approach - each RFC that registers a value for the ENUM should include a pointer to the XML Schema for that specification as part of making the registration with IANA (the IANA registry entry will reference the RFC for the details). This may help recipients ensure that they have local copies of the XML schemas necessary to parse expected content. 2) > So, my assumption here is that a complete CVE (compatible with its > schema) will be embedded here. I don't have a problem with that assumption, but think it should be stated because that conclusion is not obvious [well, at least not to me ;-) ]. It should be sufficient to state that the embedded element is a complete XML document that is formatted according to the schema referenced by the IANA registration of the ENUM value used for SpecificationName (see item 1). > 3) > Maybe some text in the draft has caused mis-understanding. > Yes, the latest version of the XCCDF schema is 1.6. > I intended to say that the number of the version element is zero or one. > Most of specifications such as XCCDF etc. have versions while CVE does not. > Thus the number of this element class is ZERO or ONE. I misread what you wrote, sorry about that. I was looking for the syntax of the contents of the [Specification]Version element, and looked in the wrong place. My concern is similar to item 1) - how does the recipient parse and check the version number? The rules for this need to be precise, otherwise there may be unexpected string compare results. It'd be good if the version number could be extracted from the XML Schema for the embedded content (and hence take advantage of the rules in the referenced specification for the syntax of [Specification]Version). A simple (silly) example of what can go wrong is that OVAL is currently at version 5.10 - that's not the same as 5.1, but if it's converted to a number, the result is easy to misparse it as being equivalent to 5.1 ;-). Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if the '.' causes problems in some tooling? All of these are easy for a human to sort out, but potential causes of problems in automated tools. Thanks, --David > -----Original Message----- > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > Sent: Sunday, August 14, 2011 9:25 AM > To: Black, David; mile@ietf.org > Subject: RE: [mile] draft on IODEF exstension to support structured > cybersecurity information > > Hi David, > > Thank you for your kind comments. > I agree, I'll change the element class name. > > Regarding the issues you kindly raised in the email, let me describe > my understanding. > > 1) > My assumption was, when parsing the xml data, the parser anyway reads > the namespace described in the embedded xml data and parse the data. > But I agree, it would be better to limit the description of > SpecificationName. > Maybe we could use ENUM (instead of ML_STRING), and enumerate possible > specifications. > For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > ENUM for dtype and FraudType description. > Like the same way, the SpecificationName could use ENUM for describing > specifications, though we do not have that much specifications to > enumerate at this moment. > > 2) > I am not sure whether it is easier for information sender and receiver > to send/receive partial CVE data. > Maybe it would be easier for them to embed/receive/parse a complete > CVE data? > If we send a partial CVE or the other structured data, receiver may > suffer from some parsing problem, as you mentioned. > So, my assumption here is that a complete CVE (compatible with its > schema) will be embedded here. > > 3) > Maybe some text in the draft has caused mis-understanding. > Yes, the latest version of the XCCDF schema is 1.6. > I intended to say that the number of the version element is zero or one. > Most of specifications such as XCCDF etc. have versions while CVE does not. > Thus the number of this element class is ZERO or ONE. > > Above are my viewpoint, but I might be wrong. > Let me develop the draft based on your kind comments after my vacation. > Please correct me if I am wrong, I would like to welcome feedbacks. > > Thank you. > > Take > > > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Wednesday, August 10, 2011 8:45 AM > To: takeshi_takahashi@nict.go.jp; mile@ietf.org > Cc: david.black@emc.com > Subject: RE: [mile] draft on IODEF exstension to support structured > cybersecurity information > > Hi Take, > > For clarity I'd suggest not using "Version" as the name of both an > extension attribute and one of the classes in each extension. > Renaming the class to SpecificationVersion would be clearer (so > Version is the attribute with the version of the extension). > > I also have a few questions: > > (1) What strings are valid for SpecificationName? If the recipient > doesn't understand the SpecificationName, the information in the > extension may be unparseable, so this probably needs to be controlled. > > An IANA registry may be appropriate to list the valid strings and > associate each string with its corresponding specification. > > (2) How does one determine the format for information formatted > according to an external specification? > > For example, I believe that the XSD schema for the CVE list defines a > complete XML document, but I suspect that less than a complete XML > document is intended to be embedded because the proposed extension is > part of an IODEF XML document. > > (3) Why is the [Specification]Version limited to zero or one? > > For example, CAPEC is currently at Release 1.6. > > 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 > ---------------------------------------------------- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > Of Takeshi Takahashi > Sent: Monday, August 08, 2011 11:50 PM > To: mile@ietf.org > Subject: Re: [mile] draft on IODEF exstension to support structured > cybersecurity information > > Thank you for those of you who kindly gave me off-line messages . > > Let me share the draft with some minor modifications. > > Sincerely, > Take > > > 2011/8/5 Takeshi Takahashi : > > Dear all, > > > > > > > > The attached is the tentative version of the draft prepared based on > > the comments I've received in this mailing list (Thanks a lot for that). > > > > It would be great if you could provide some comments on Clause 4, > > where > the > > IODEF extension is defined. > > > > > > > > As you know, there are many ways to embed structured information > > (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very flexible. > > > > Thus, I would be happy to change and develop the draft further based > > on > your > > comments. > > > > > > > > I would like to welcome any comments on that. > > > > > > > > By the way, I will be on vacation, thus my response might be slow, > > sorry > for > > the inconvenience. > > > > > > > > Take > > > > > > > > PS: I've changed the title of the email. > > > > > > > > > > > > 2011/7/29 > > > >> > > > >> Thank you, the approach sounds good, especially since it is in use > >> today > > > >> by at least the Research and Education ISAC. Do others have > >> opinions on > > > >> the proposal here? > > > >> > > > >> Thanks for writing the first draft Take! > > > >> > > > >> Best regards, > > > >> Kathleen > > > >> ________________________________________ > > > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > >> Takeshi > > > >> Takahashi [takeshi_takahashi@nict.go.jp] > > > >> Sent: Friday, July 29, 2011 9:20 AM > > > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > > > >> Cc: mile@ietf.org > > > >> Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > >> Thank you, Bob, for the email. > > > >> I also like Tom's suggestion very much. > > > >> Let me work on the "draft" of the draft for a while, then come back > >> to > you > > > >> later. > > > >> > > > >> Take > > > >> > > > >> -----Original Message----- > > > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > > > >> Sent: Friday, July 29, 2011 9:10 AM > > > >> To: Kent_Landfield@McAfee.com > > > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > > > >> wes@ren-isac.net; mile@ietf.org > > > >> Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > >> I also like how this is evolving. > > > >> > > > >> I think, as Tom's suggestions pointed, that any and all of the > >> useful > > > >> types > > > >> of information that can help with understanding, diagnosing, and > >> getting > > > >> ahead of an incident should be added but for now we should focus on > >> those > > > >> the most established and well articulated. > > > >> > > > >> This can be the compliance/patch/configuration/platform information > > > >> related > > > >> to the SCAP use case, or event signature/attack pattern/traffic > > > >> characteristics from events, or the vulnerability/threat > >> characterization > > > >> space. > > > >> > > > >> I look forward to Taki's draft to see how he suggests positioning > >> these > > > >> concepts. > > > >> > > > >> Bob > > > >> > > > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > > > >> > I like where this is headed. > > > >> > > > > >> > Thanks Takeshi. I look forward to your draft. It will give us > something > > > >> real to discuss. I appreciate you jumping in and getting this started. > > > >> > > > > >> > One question that I am not clear on. What do we envision as the > >> > actual > > > >> set > > > >> of deliverables? From and SCAP related perspective, are we looking > >> at a > > > >> single draft covering all the extensions? > > > >> > > > > >> > Kent > > > >> > > > > >> > Kent Landfield > > > >> > Director Content Strategy, Architecture and Standards > > > >> > > > > >> > McAfee, Inc. > > > >> > 5000 Headquarters Dr. > > > >> > Plano, Texas 75024 > > > >> > > > > >> > Direct: +1.972.963.7096 > > > >> > Mobile: +1.817.637.8026 > > > >> > Web: www.mcafee.com > > > >> > > > > >> > From: Takeshi > > > >> > Takahashi >> > ict.g > > > >> > o.jp>> > > > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > > > >> > To: > > > >> > "Thomas.Millar@us-cert.gov" >> > mas.M > > > >> > illar@us-cert.gov>, > > > >> > "wes@ren-isac.net" >> > to:we > > > >> > s@ren-isac.net>>, > > > >> > "mile@ietf.org" >> > etf.o > > > >> > rg>> > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > Thank you for the email, Tom. > > > >> > > > > >> > So, here is what the draft needs to describe (if I understand Wes > >> > and > > > >> > Tom correctly). > > > >> > > > > >> > The draft should define ext-dtype (an attribute of AdditionalData > > > >> > Class) to identify the information type, rather than defining new > > > >> > class under AdditionalData. > > > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, > >> > ext-capec, > > > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal > >> > and > > > >> > could easily embed various structured information (CVE etc.) in > >> > the > > > >> > EventData.Record.RecordData.AdditionalData field. > > > >> > Then "should" statement should be carefully placed in the text of > > > >> > relevant class. > > > >> > > > > >> > I'll prepare some draft so that we could discuss and advance further. > > > >> > > > > >> > Take > > > >> > > > > >> > > > > >> > > > > >> > -----Original Message----- > > > >> > From: mile-bounces@ietf.org > > > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > > > >> > Thomas.Millar@us-cert.gov > > > >> > Sent: Thursday, July 28, 2011 6:28 PM > > > >> > To: wes@ren-isac.net; > > > >> > mile@ietf.org > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > I think this approach makes more sense. One of the things I think > > > >> > could be helpful is to have a number of SHOULD statements further > > > >> > describing the possible types of other documents that would be > > > >> > expected to ride under the AdditionalData elements of each class > >> > (not > > > >> just > > > >> EventData). > > > >> > What I'm thinking of looks like this (very unpolished): > > > >> > > > > >> > "The Method Class:AdditionalData class SHOULD contain data > >> > elements > > > >> > that describe the methods, tools or techniques employed to cause > >> > the > > > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning > >> > the > > > >> > method such as CVSS, CWSS, or CCE." > > > >> > > > > >> > "The Expectation Class[...] SHOULD contain data elements which > > > >> > describe configuration changes, detection heuristics, or [* > >> > (legal > > > >> > authorization?)] to assist in executing or implementing the > >> > requested > > > >> > action, such as XCCDF, OCIL, OVAL, etc" > > > >> > > > > >> > This could go towards encouraging better or at least more > >> > consistent > > > >> > use of "boundary objects" in the substance of incident reports. I > > > >> > could also go on about greater automation and such but that's > >> > probably > > > >> > out of scope for this e-mail. > > > >> > > > > >> > > > > >> > - Tom Millar, US-CERT > > > >> > > > > >> > thomas.millar@us-cert.gov > > > >> > BB: thomas.millar@dhs.gov / > > > >> > 202-631-1915 > > > >> > 24x7: soc@us-cert.gov / 888-282-0870 > > > >> > -----Original Message----- > > > >> > From: mile-bounces@ietf.org > > > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > > > >> > Sent: Thursday, July 28, 2011 11:08 AM > > > >> > To: mile@ietf.org > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > > > >> > > > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > > > >> > > > > >> > i've been sticking other "XML like" records under this (icsg1.1 > >> > data, > > > >> > etc...). > > > >> > > > > >> > pretty easy to do, just generate the "other standards" xml (or > >> > json or > > > >> > whatever), embed it there. turns iodef into a sharing platform > >> > for > > > >> > other data-types w/o having to extend it too much. > > > >> > > > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > > > >> > > > > >> > So, maybe we could extend the IODEF as described in Figure 1 of > >> > the > > > >> > attached txt file. (correct me if I'm wrong) We could define > > > >> > Incident.EventData.AdditionalData elements and describe them by > >> > using > > > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > > > >> > Regarding OVAL, we might define Incident.AdditionalData element, > >> > but I > > > >> > > > > >> > am not sure at this moment, thus is not described in the figure yet. > > > >> > I would like to tackle CAPEC first since I believe Kent would > >> > like to > > > >> > tackle CVE and CAPEC. > > > >> > > > > >> > -- > > > >> > Wes > > > >> > claimid.com/wesyoung > > > >> > soc@ren-isac.net > > > >> > > > > >> > * Wes Young> > > > >> > * 0xDDB6E946 - Unverified(L) > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > . > > > >> > > > > >> > > > >> _______________________________________________ > > > >> mile mailing list > > > >> mile@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > > > > -- > -- > Takeshi Takahashi, Ph.D. > +81 80 3490 2971 > http://www.taketaka.com/ > > From takeshi_takahashi@nict.go.jp Wed Aug 24 01:09:38 2011 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 A49E921F8B12 for ; Wed, 24 Aug 2011 01:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSgtA39KFQOz for ; Wed, 24 Aug 2011 01:09:37 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFDC21F8AD3 for ; Wed, 24 Aug 2011 01:09:36 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id p7O8Aiow022149; Wed, 24 Aug 2011 17:10:44 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id p7O8Ai0G025575; Wed, 24 Aug 2011 17:10:44 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id p7O8AfdY025566; Wed, 24 Aug 2011 17:10:42 +0900 (JST) From: "Takeshi Takahashi" To: "'Brian Trammell'" , References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <809F17A3-A382-477E-A608-271A1D42D6C6@tik.ee.ethz.ch> In-Reply-To: <809F17A3-A382-477E-A608-271A1D42D6C6@tik.ee.ethz.ch> Date: Wed, 24 Aug 2011 09:11:15 +0100 Message-ID: <013701cc6235$6638a9c0$32a9fd40$@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: AQHZoScn83GYsZh9CRcfWQQM2pwT0QIjvf2BAWjmAmcB6FiKgwElVLoZlNsocaA= Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information 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, 24 Aug 2011 08:09:38 -0000 Hi Brian, Thanks for your email. > In general, I agree: representing embedded information by ENUM as opposed to by freeform string is much preferable. However, if the embedded information is itself described by an XML Schema, then it may make sense to differentiate the embedded AdditionalData content not with a new ENUM, but rather by the namespace used by that schema. You still run into the subordinate namespace versioning problem, but this is now the job of the creator of the subordinate namespace to do correctly, which I would assume is the case for the SCAP use case. Basically, yes, I agree. As mentioned in the other email, I'll add a sentence "parsers are expected to read the namespace of the embedded structured information and identify specification name and data, whehever such information is available, and parse the embedded data." But maybe we still need these ENUM-based elements, since these embedded information could be non-xml in the future. At the same time, we could allow omitting SpecificationName and SpecificationVersion elements, since the namespace of the embedded xml data uniquely identify specification and its version as you mentioned. Thank you. Take -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] Sent: Tuesday, August 16, 2011 5:10 PM To: Cc: takeshi_takahashi@nict.go.jp; mile@ietf.org Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information Greetings, all, I'm just back from vacation and catching up on things, and still need to review the document completely, so expect more from me on this thread, soon. However, I did want to point one thing out here... In general, I agree: representing embedded information by ENUM as opposed to by freeform string is much preferable. However, if the embedded information is itself described by an XML Schema, then it may make sense to differentiate the embedded AdditionalData content not with a new ENUM, but rather by the namespace used by that schema. You still run into the subordinate namespace versioning problem, but this is now the job of the creator of the subordinate namespace to do correctly, which I would assume is the case for the SCAP use case. Regards, Brian On Aug 16, 2011, at 3:14 AM, wrote: > Hi Take, > > Enjoy your vacation, here are some comments to look at when you return: > > 1) >> Maybe we could use ENUM (instead of ML_STRING), and enumerate possible specifications. >> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use >> ENUM for dtype and FraudType description. > > That sounds like a good approach - each RFC that registers a value for the ENUM should include a pointer to the XML Schema for that specification as part of making the registration with IANA (the IANA registry entry will reference the RFC for the details). This may help recipients ensure that they have local copies of the XML schemas necessary to parse expected content. > > 2) >> So, my assumption here is that a complete CVE (compatible with its >> schema) will be embedded here. > > I don't have a problem with that assumption, but think it should be stated because that conclusion is not obvious [well, at least not to me ;-) ]. It should be sufficient to state that the embedded element is a complete XML document that is formatted according to the schema referenced by the IANA registration of the ENUM value used for SpecificationName (see item 1). > >> 3) >> Maybe some text in the draft has caused mis-understanding. >> Yes, the latest version of the XCCDF schema is 1.6. >> I intended to say that the number of the version element is zero or one. >> Most of specifications such as XCCDF etc. have versions while CVE does not. >> Thus the number of this element class is ZERO or ONE. > > I misread what you wrote, sorry about that. I was looking for the syntax of the contents of the [Specification]Version element, and looked in the wrong place. > > My concern is similar to item 1) - how does the recipient parse and check the version number? > The rules for this need to be precise, otherwise there may be unexpected string compare results. It'd be good if the version number could be extracted from the XML Schema for the embedded content (and hence take advantage of the rules in the referenced specification for the syntax of [Specification]Version). > > A simple (silly) example of what can go wrong is that OVAL is currently at version 5.10 - that's not the same as 5.1, but if it's converted to a number, the result is easy to misparse it as being equivalent to 5.1 ;-). Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if the '.' causes problems in some tooling? All of these are easy for a human to sort out, but potential causes of problems in automated tools. > > Thanks, > --David > >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Sunday, August 14, 2011 9:25 AM >> To: Black, David; mile@ietf.org >> Subject: RE: [mile] draft on IODEF exstension to support structured >> cybersecurity information >> >> Hi David, >> >> Thank you for your kind comments. >> I agree, I'll change the element class name. >> >> Regarding the issues you kindly raised in the email, let me describe >> my understanding. >> >> 1) >> My assumption was, when parsing the xml data, the parser anyway reads >> the namespace described in the embedded xml data and parse the data. >> But I agree, it would be better to limit the description of >> SpecificationName. >> Maybe we could use ENUM (instead of ML_STRING), and enumerate >> possible specifications. >> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use >> ENUM for dtype and FraudType description. >> Like the same way, the SpecificationName could use ENUM for >> describing specifications, though we do not have that much >> specifications to enumerate at this moment. >> >> 2) >> I am not sure whether it is easier for information sender and >> receiver to send/receive partial CVE data. >> Maybe it would be easier for them to embed/receive/parse a complete >> CVE data? >> If we send a partial CVE or the other structured data, receiver may >> suffer from some parsing problem, as you mentioned. >> So, my assumption here is that a complete CVE (compatible with its >> schema) will be embedded here. >> >> 3) >> Maybe some text in the draft has caused mis-understanding. >> Yes, the latest version of the XCCDF schema is 1.6. >> I intended to say that the number of the version element is zero or one. >> Most of specifications such as XCCDF etc. have versions while CVE does not. >> Thus the number of this element class is ZERO or ONE. >> >> Above are my viewpoint, but I might be wrong. >> Let me develop the draft based on your kind comments after my vacation. >> Please correct me if I am wrong, I would like to welcome feedbacks. >> >> Thank you. >> >> Take >> >> >> From: david.black@emc.com [mailto:david.black@emc.com] >> Sent: Wednesday, August 10, 2011 8:45 AM >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org >> Cc: david.black@emc.com >> Subject: RE: [mile] draft on IODEF exstension to support structured >> cybersecurity information >> >> Hi Take, >> >> For clarity I'd suggest not using "Version" as the name of both an >> extension attribute and one of the classes in each extension. >> Renaming the class to SpecificationVersion would be clearer (so >> Version is the attribute with the version of the extension). >> >> I also have a few questions: >> >> (1) What strings are valid for SpecificationName? If the recipient >> doesn't understand the SpecificationName, the information in the >> extension may be unparseable, so this probably needs to be controlled. >> >> An IANA registry may be appropriate to list the valid strings and >> associate each string with its corresponding specification. >> >> (2) How does one determine the format for information formatted >> according to an external specification? >> >> For example, I believe that the XSD schema for the CVE list defines a >> complete XML document, but I suspect that less than a complete XML >> document is intended to be embedded because the proposed extension is >> part of an IODEF XML document. >> >> (3) Why is the [Specification]Version limited to zero or one? >> >> For example, CAPEC is currently at Release 1.6. >> >> 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 >> ---------------------------------------------------- >> >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >> Of Takeshi Takahashi >> Sent: Monday, August 08, 2011 11:50 PM >> To: mile@ietf.org >> Subject: Re: [mile] draft on IODEF exstension to support structured >> cybersecurity information >> >> Thank you for those of you who kindly gave me off-line messages . >> >> Let me share the draft with some minor modifications. >> >> Sincerely, >> Take >> >> >> 2011/8/5 Takeshi Takahashi : >>> Dear all, >>> >>> >>> >>> The attached is the tentative version of the draft prepared based on >>> the comments I've received in this mailing list (Thanks a lot for that). >>> >>> It would be great if you could provide some comments on Clause 4, >>> where >> the >>> IODEF extension is defined. >>> >>> >>> >>> As you know, there are many ways to embed structured information >>> (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very flexible. >>> >>> Thus, I would be happy to change and develop the draft further based >>> on >> your >>> comments. >>> >>> >>> >>> I would like to welcome any comments on that. >>> >>> >>> >>> By the way, I will be on vacation, thus my response might be slow, >>> sorry >> for >>> the inconvenience. >>> >>> >>> >>> Take >>> >>> >>> >>> PS: I've changed the title of the email. >>> >>> >>> >>> >>> >>> 2011/7/29 >>> >>>> >>> >>>> Thank you, the approach sounds good, especially since it is in use >>>> today >>> >>>> by at least the Research and Education ISAC. Do others have >>>> opinions on >>> >>>> the proposal here? >>> >>>> >>> >>>> Thanks for writing the first draft Take! >>> >>>> >>> >>>> Best regards, >>> >>>> Kathleen >>> >>>> ________________________________________ >>> >>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of >>>> Takeshi >>> >>>> Takahashi [takeshi_takahashi@nict.go.jp] >>> >>>> Sent: Friday, July 29, 2011 9:20 AM >>> >>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com >>> >>>> Cc: mile@ietf.org >>> >>>> Subject: Re: [mile] Updated presentation from Side meeting >>> >>>> >>> >>>> Thank you, Bob, for the email. >>> >>>> I also like Tom's suggestion very much. >>> >>>> Let me work on the "draft" of the draft for a while, then come back >>>> to >> you >>> >>>> later. >>> >>>> >>> >>>> Take >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] >>> >>>> Sent: Friday, July 29, 2011 9:10 AM >>> >>>> To: Kent_Landfield@McAfee.com >>> >>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; >>> >>>> wes@ren-isac.net; mile@ietf.org >>> >>>> Subject: Re: [mile] Updated presentation from Side meeting >>> >>>> >>> >>>> I also like how this is evolving. >>> >>>> >>> >>>> I think, as Tom's suggestions pointed, that any and all of the >>>> useful >>> >>>> types >>> >>>> of information that can help with understanding, diagnosing, and >>>> getting >>> >>>> ahead of an incident should be added but for now we should focus on >>>> those >>> >>>> the most established and well articulated. >>> >>>> >>> >>>> This can be the compliance/patch/configuration/platform information >>> >>>> related >>> >>>> to the SCAP use case, or event signature/attack pattern/traffic >>> >>>> characteristics from events, or the vulnerability/threat >>>> characterization >>> >>>> space. >>> >>>> >>> >>>> I look forward to Taki's draft to see how he suggests positioning >>>> these >>> >>>> concepts. >>> >>>> >>> >>>> Bob >>> >>>> >>> >>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: >>> >>>>> I like where this is headed. >>> >>>>> >>> >>>>> Thanks Takeshi. I look forward to your draft. It will give us >> something >>> >>>> real to discuss. I appreciate you jumping in and getting this started. >>> >>>>> >>> >>>>> One question that I am not clear on. What do we envision as the >>>>> actual >>> >>>> set >>> >>>> of deliverables? From and SCAP related perspective, are we looking >>>> at a >>> >>>> single draft covering all the extensions? >>> >>>>> >>> >>>>> Kent >>> >>>>> >>> >>>>> Kent Landfield >>> >>>>> Director Content Strategy, Architecture and Standards >>> >>>>> >>> >>>>> McAfee, Inc. >>> >>>>> 5000 Headquarters Dr. >>> >>>>> Plano, Texas 75024 >>> >>>>> >>> >>>>> Direct: +1.972.963.7096 >>> >>>>> Mobile: +1.817.637.8026 >>> >>>>> Web: www.mcafee.com >>> >>>>> >>> >>>>> From: Takeshi >>> >>>>> Takahashi>>>> ct.g >>> >>>>> o.jp>> >>> >>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 >>> >>>>> To: >>> >>>>> "Thomas.Millar@us-cert.gov">>>> as.M >>> >>>>> illar@us-cert.gov>, >>> >>>>> "wes@ren-isac.net">>>> o:we >>> >>>>> s@ren-isac.net>>, >>> >>>>> "mile@ietf.org">>>> tf.o >>> >>>>> rg>> >>> >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>> >>>>> >>> >>>>> Thank you for the email, Tom. >>> >>>>> >>> >>>>> So, here is what the draft needs to describe (if I understand Wes >>>>> and >>> >>>>> Tom correctly). >>> >>>>> >>> >>>>> The draft should define ext-dtype (an attribute of AdditionalData >>> >>>>> Class) to identify the information type, rather than defining new >>> >>>>> class under AdditionalData. >>> >>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, >>>>> ext-capec, >>> >>>>> ext-cvss, ext-cwss, In this way, we could keep the change minimal >>>>> and >>> >>>>> could easily embed various structured information (CVE etc.) in >>>>> the >>> >>>>> EventData.Record.RecordData.AdditionalData field. >>> >>>>> Then "should" statement should be carefully placed in the text of >>> >>>>> relevant class. >>> >>>>> >>> >>>>> I'll prepare some draft so that we could discuss and advance further. >>> >>>>> >>> >>>>> Take >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -----Original Message----- >>> >>>>> From: mile-bounces@ietf.org >>> >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>> >>>>> Thomas.Millar@us-cert.gov >>> >>>>> Sent: Thursday, July 28, 2011 6:28 PM >>> >>>>> To: wes@ren-isac.net; >>> >>>>> mile@ietf.org >>> >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>> >>>>> >>> >>>>> I think this approach makes more sense. One of the things I think >>> >>>>> could be helpful is to have a number of SHOULD statements further >>> >>>>> describing the possible types of other documents that would be >>> >>>>> expected to ride under the AdditionalData elements of each class >>>>> (not >>> >>>> just >>> >>>> EventData). >>> >>>>> What I'm thinking of looks like this (very unpolished): >>> >>>>> >>> >>>>> "The Method Class:AdditionalData class SHOULD contain data >>>>> elements >>> >>>>> that describe the methods, tools or techniques employed to cause >>>>> the >>> >>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning >>>>> the >>> >>>>> method such as CVSS, CWSS, or CCE." >>> >>>>> >>> >>>>> "The Expectation Class[...] SHOULD contain data elements which >>> >>>>> describe configuration changes, detection heuristics, or [* (legal >>> >>>>> authorization?)] to assist in executing or implementing the >>>>> requested >>> >>>>> action, such as XCCDF, OCIL, OVAL, etc" >>> >>>>> >>> >>>>> This could go towards encouraging better or at least more >>>>> consistent >>> >>>>> use of "boundary objects" in the substance of incident reports. I >>> >>>>> could also go on about greater automation and such but that's >>>>> probably >>> >>>>> out of scope for this e-mail. >>> >>>>> >>> >>>>> >>> >>>>> - Tom Millar, US-CERT >>> >>>>> >>> >>>>> thomas.millar@us-cert.gov >>> >>>>> BB: thomas.millar@dhs.gov / >>> >>>>> 202-631-1915 >>> >>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>> >>>>> -----Original Message----- >>> >>>>> From: mile-bounces@ietf.org >>> >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young >>> >>>>> Sent: Thursday, July 28, 2011 11:08 AM >>> >>>>> To: mile@ietf.org >>> >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>> >>>>> >>> >>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM >>> >>>>> >>> >>>>> http://tools.ietf.org/html/rfc5070#section-3.19 >>> >>>>> >>> >>>>> i've been sticking other "XML like" records under this (icsg1.1 >>>>> data, >>> >>>>> etc...). >>> >>>>> >>> >>>>> pretty easy to do, just generate the "other standards" xml (or >>>>> json or >>> >>>>> whatever), embed it there. turns iodef into a sharing platform for >>> >>>>> other data-types w/o having to extend it too much. >>> >>>>> >>> >>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: >>> >>>>> >>> >>>>> So, maybe we could extend the IODEF as described in Figure 1 of >>>>> the >>> >>>>> attached txt file. (correct me if I'm wrong) We could define >>> >>>>> Incident.EventData.AdditionalData elements and describe them by >>>>> using >>> >>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. >>> >>>>> Regarding OVAL, we might define Incident.AdditionalData element, >>>>> but I >>> >>>>> >>> >>>>> am not sure at this moment, thus is not described in the figure yet. >>> >>>>> I would like to tackle CAPEC first since I believe Kent would like >>>>> to >>> >>>>> tackle CVE and CAPEC. >>> >>>>> >>> >>>>> -- >>> >>>>> Wes >>> >>>>> claimid.com/wesyoung >>> >>>>> soc@ren-isac.net >>> >>>>> >>> >>>>> * Wes Young> >>> >>>>> * 0xDDB6E946 - Unverified(L) >>> >>>>> _______________________________________________ >>> >>>>> mile mailing list >>> >>>>> mile@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/mile >>> >>>>> _______________________________________________ >>> >>>>> mile mailing list >>> >>>>> mile@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/mile >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> mile mailing list >>> >>>>> mile@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/mile >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> mile mailing list >>> >>>>> mile@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/mile >>> >>>>> . >>> >>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> mile mailing list >>> >>>> mile@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> -- >> Takeshi Takahashi, Ph.D. >> +81 80 3490 2971 >> http://www.taketaka.com/ >> >> > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Wed Aug 24 01:10:35 2011 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 CE31D21F8511 for ; Wed, 24 Aug 2011 01:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY9ar4MzV7Bs for ; Wed, 24 Aug 2011 01:10:34 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA4021F8B27 for ; Wed, 24 Aug 2011 01:10:34 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id p7O8BGZ5022165; Wed, 24 Aug 2011 17:11:16 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id p7O8BGRf025709; Wed, 24 Aug 2011 17:11:16 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id p7O8BDaW025700; Wed, 24 Aug 2011 17:11:15 +0900 (JST) From: "Takeshi Takahashi" To: "'Brian Trammell'" References: <000d01cc5647$62c4c070$284e4150$@go.jp> <44318F0F-7B19-4457-B09B-468CEB9EA0C7@tik.ee.ethz.ch> In-Reply-To: <44318F0F-7B19-4457-B09B-468CEB9EA0C7@tik.ee.ethz.ch> Date: Wed, 24 Aug 2011 09:11:48 +0100 Message-ID: <013801cc6235$79acfab0$6d06f010$@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: AQHZoScn83GYsZh9CRcfWQQM2pwT0QGmvsimlQLIKUA= Content-Language: ja Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information 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, 24 Aug 2011 08:10:35 -0000 Hi Brian, Thank you for the kind comments. > It appears that the AttackPattern, Vulnerability, and Weakness classes should probably have a multiplicity of 0..n -- 0 to support cases where these are not known, or n for cases where multiple external references are necessary. Yes, I agree. I'll add some sentences to clarify that. Let me update the draft and come back to you and all here with revised draft soon. Thank you. Take -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] Sent: Thursday, August 18, 2011 11:14 PM To: Takeshi Takahashi Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF exstension to support structured cybersecurity information Hi, Take, all, One point that came up here when we were discussing the draft at ETH follows... It appears that the AttackPattern, Vulnerability, and Weakness classes should probably have a multiplicity of 0..n -- 0 to support cases where these are not known, or n for cases where multiple external references are necessary. Thoughts? Cheers, Brian On Aug 9, 2011, at 5:49 AM, Takeshi Takahashi wrote: > Thank you for those of you who kindly gave me off-line messages . > > Let me share the draft with some minor modifications. > > Sincerely, > Take > > > 2011/8/5 Takeshi Takahashi : > > Dear all, > > > > > > > > The attached is the tentative version of the draft prepared based on > > the comments I've received in this mailing list (Thanks a lot for that). > > > > It would be great if you could provide some comments on Clause 4, > > where the IODEF extension is defined. > > > > > > > > As you know, there are many ways to embed structured information > > (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very flexible. > > > > Thus, I would be happy to change and develop the draft further based > > on your comments. > > > > > > > > I would like to welcome any comments on that. > > > > > > > > By the way, I will be on vacation, thus my response might be slow, > > sorry for the inconvenience. > > > > > > > > Take > > > > > > > > PS: I've changed the title of the email. > > > > > > > > > > > > 2011/7/29 > > > >> > > > >> Thank you, the approach sounds good, especially since it is in use > >> today > > > >> by at least the Research and Education ISAC. Do others have > >> opinions on > > > >> the proposal here? > > > >> > > > >> Thanks for writing the first draft Take! > > > >> > > > >> Best regards, > > > >> Kathleen > > > >> ________________________________________ > > > >> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > >> Takeshi > > > >> Takahashi [takeshi_takahashi@nict.go.jp] > > > >> Sent: Friday, July 29, 2011 9:20 AM > > > >> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > > > >> Cc: mile@ietf.org > > > >> Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > >> Thank you, Bob, for the email. > > > >> I also like Tom's suggestion very much. > > > >> Let me work on the "draft" of the draft for a while, then come back > >> to you > > > >> later. > > > >> > > > >> Take > > > >> > > > >> -----Original Message----- > > > >> From: Martin, Robert A. [mailto:ramartin@mitre.org] > > > >> Sent: Friday, July 29, 2011 9:10 AM > > > >> To: Kent_Landfield@McAfee.com > > > >> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > > > >> wes@ren-isac.net; mile@ietf.org > > > >> Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > >> I also like how this is evolving. > > > >> > > > >> I think, as Tom's suggestions pointed, that any and all of the > >> useful > > > >> types > > > >> of information that can help with understanding, diagnosing, and > >> getting > > > >> ahead of an incident should be added but for now we should focus on > >> those > > > >> the most established and well articulated. > > > >> > > > >> This can be the compliance/patch/configuration/platform information > > > >> related > > > >> to the SCAP use case, or event signature/attack pattern/traffic > > > >> characteristics from events, or the vulnerability/threat > >> characterization > > > >> space. > > > >> > > > >> I look forward to Taki's draft to see how he suggests positioning > >> these > > > >> concepts. > > > >> > > > >> Bob > > > >> > > > >> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > > > >> > I like where this is headed. > > > >> > > > > >> > Thanks Takeshi. I look forward to your draft. It will give us > >> > something > > > >> real to discuss. I appreciate you jumping in and getting this started. > > > >> > > > > >> > One question that I am not clear on. What do we envision as the > >> > actual > > > >> set > > > >> of deliverables? From and SCAP related perspective, are we looking > >> at a > > > >> single draft covering all the extensions? > > > >> > > > > >> > Kent > > > >> > > > > >> > Kent Landfield > > > >> > Director Content Strategy, Architecture and Standards > > > >> > > > > >> > McAfee, Inc. > > > >> > 5000 Headquarters Dr. > > > >> > Plano, Texas 75024 > > > >> > > > > >> > Direct: +1.972.963.7096 > > > >> > Mobile: +1.817.637.8026 > > > >> > Web: www.mcafee.com > > > >> > > > > >> > From: Takeshi > > > >> > Takahashi >> > ict.g > > > >> > o.jp>> > > > >> > Date: Thu, 28 Jul 2011 18:21:56 -0500 > > > >> > To: > > > >> > "Thomas.Millar@us-cert.gov" >> > mas.M > > > >> > illar@us-cert.gov>, > > > >> > "wes@ren-isac.net" >> > to:we > > > >> > s@ren-isac.net>>, > > > >> > "mile@ietf.org" >> > etf.o > > > >> > rg>> > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > Thank you for the email, Tom. > > > >> > > > > >> > So, here is what the draft needs to describe (if I understand Wes > >> > and > > > >> > Tom correctly). > > > >> > > > > >> > The draft should define ext-dtype (an attribute of AdditionalData > > > >> > Class) to identify the information type, rather than defining new > > > >> > class under AdditionalData. > > > >> > Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, > >> > ext-capec, > > > >> > ext-cvss, ext-cwss, In this way, we could keep the change minimal > >> > and > > > >> > could easily embed various structured information (CVE etc.) in > >> > the > > > >> > EventData.Record.RecordData.AdditionalData field. > > > >> > Then "should" statement should be carefully placed in the text of > > > >> > relevant class. > > > >> > > > > >> > I'll prepare some draft so that we could discuss and advance further. > > > >> > > > > >> > Take > > > >> > > > > >> > > > > >> > > > > >> > -----Original Message----- > > > >> > From: mile-bounces@ietf.org > > > >> > [mailto:mile-bounces@ietf.org] On Behalf Of > > > >> > Thomas.Millar@us-cert.gov > > > >> > Sent: Thursday, July 28, 2011 6:28 PM > > > >> > To: wes@ren-isac.net; > > > >> > mile@ietf.org > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > I think this approach makes more sense. One of the things I think > > > >> > could be helpful is to have a number of SHOULD statements further > > > >> > describing the possible types of other documents that would be > > > >> > expected to ride under the AdditionalData elements of each class > >> > (not > > > >> just > > > >> EventData). > > > >> > What I'm thinking of looks like this (very unpolished): > > > >> > > > > >> > "The Method Class:AdditionalData class SHOULD contain data > >> > elements > > > >> > that describe the methods, tools or techniques employed to cause > >> > the > > > >> > incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning > >> > the > > > >> > method such as CVSS, CWSS, or CCE." > > > >> > > > > >> > "The Expectation Class[...] SHOULD contain data elements which > > > >> > describe configuration changes, detection heuristics, or [* > >> > (legal > > > >> > authorization?)] to assist in executing or implementing the > >> > requested > > > >> > action, such as XCCDF, OCIL, OVAL, etc" > > > >> > > > > >> > This could go towards encouraging better or at least more > >> > consistent > > > >> > use of "boundary objects" in the substance of incident reports. I > > > >> > could also go on about greater automation and such but that's > >> > probably > > > >> > out of scope for this e-mail. > > > >> > > > > >> > > > > >> > - Tom Millar, US-CERT > > > >> > > > > >> > thomas.millar@us-cert.gov > > > >> > BB: thomas.millar@dhs.gov / > > > >> > 202-631-1915 > > > >> > 24x7: soc@us-cert.gov / 888-282-0870 > > > >> > -----Original Message----- > > > >> > From: mile-bounces@ietf.org > > > >> > [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > > > >> > Sent: Thursday, July 28, 2011 11:08 AM > > > >> > To: mile@ietf.org > > > >> > Subject: Re: [mile] Updated presentation from Side meeting > > > >> > > > > >> > * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > > > >> > > > > >> > http://tools.ietf.org/html/rfc5070#section-3.19 > > > >> > > > > >> > i've been sticking other "XML like" records under this (icsg1.1 > >> > data, > > > >> > etc...). > > > >> > > > > >> > pretty easy to do, just generate the "other standards" xml (or > >> > json or > > > >> > whatever), embed it there. turns iodef into a sharing platform > >> > for > > > >> > other data-types w/o having to extend it too much. > > > >> > > > > >> > On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > > > >> > > > > >> > So, maybe we could extend the IODEF as described in Figure 1 of > >> > the > > > >> > attached txt file. (correct me if I'm wrong) We could define > > > >> > Incident.EventData.AdditionalData elements and describe them by > >> > using > > > >> > CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > > > >> > Regarding OVAL, we might define Incident.AdditionalData element, > >> > but I > > > >> > > > > >> > am not sure at this moment, thus is not described in the figure yet. > > > >> > I would like to tackle CAPEC first since I believe Kent would > >> > like to > > > >> > tackle CVE and CAPEC. > > > >> > > > > >> > -- > > > >> > Wes > > > >> > claimid.com/wesyoung > > > >> > soc@ren-isac.net > > > >> > > > > >> > * Wes Young> > > > >> > * 0xDDB6E946 - Unverified(L) > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > > > > >> > _______________________________________________ > > > >> > mile mailing list > > > >> > mile@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/mile > > > >> > . > > > >> > > > > >> > > > >> _______________________________________________ > > > >> mile mailing list > > > >> mile@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > > > > > > > > > > -- > -- > Takeshi Takahashi, Ph.D. > +81 80 3490 2971 > http://www.taketaka.com/ > > _____________________________________ > __________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Wed Aug 24 01:16:23 2011 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 BE97F21F863E for ; Wed, 24 Aug 2011 01:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.788 X-Spam-Level: X-Spam-Status: No, score=-5.788 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k7GnX5Wwvze for ; Wed, 24 Aug 2011 01:16:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8628E21F8519 for ; Wed, 24 Aug 2011 01:16:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9893CD9305; Wed, 24 Aug 2011 10:17:26 +0200 (MEST) 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 qVucRiw054s0; Wed, 24 Aug 2011 10:17:26 +0200 (MEST) 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 A211FD9302; Wed, 24 Aug 2011 10:17:25 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <013601cc6235$3196b1d0$94c41570$@nict.go.jp> Date: Wed, 24 Aug 2011 10:17:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <510A8D02-449C-43C3-9D60-2F25C16BC277@tik.ee.ethz.ch> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <013601cc6235$3196b1d0$94c41570$@nict.go.jp> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information 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, 24 Aug 2011 08:16:23 -0000 Hi, Take, To my understanding, there are two possible answers to this last = question, each with their own disadvantages: 1. The SpecificationName and SpecificationVersion are present and = required, and MUST match any version information carried by the enclosed = XML namespace and schema. This gives you a nice envelope for determining = which version of the extension you're using, but can lead to = inconsistency if improperly used. It is unclear what a reader should do = when an inconsistency is detected. In line with common practice in = protocol design (send conservatively, accept liberally), I would suggest = "writers/senders MUST ensure the SpecificationName and = SpecificationVersion are consistent with the contents; if a = reader/receiver detects an inconsistency, it SHOULD prefer the = specification and version derived from the content, and SHOULD log the = inconsistency so a human can correct the problem." But it should be = addressed in any case. 2. The SpecificationName and SpecificationVersion are only present when = that information is not derivable from the enclosed XML namespace and = schema. This is ugly, because it introduces two ways of doing the same = thing... Best regards, Brian On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote: > Hi David,=09 >=20 > Thanks for your email. >=20 > 1) >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate = possible > specifications. >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use=20= >>> ENUM for dtype and FraudType description. >>=20 >> That sounds like a good approach - each RFC that registers a value = for the > ENUM should include a pointer to the XML Schema for that specification = as > part of making the registration with IANA (the IANA registry entry = will > reference the RFC for the details). This may help recipients ensure = that > they have local copies of the XML schemas necessary to parse expected > content. >=20 > Thank you for telling me the IANA issue. I appreciate that. >=20 > 2) >>> So, my assumption here is that a complete CVE (compatible with its=20= >>> schema) will be embedded here. >>=20 >> I don't have a problem with that assumption, but think it should be = stated > because that conclusion is not obvious [well, at least not to me ;-) = ]. It > should be sufficient to state that the embedded element is a complete = XML > document that is formatted according to the schema referenced by the = IANA > registration of the ENUM value used for SpecificationName (see item = 1). >=20 > I see. I will. Thank you. >=20 >> My concern is similar to item 1) - how does the recipient parse and = check > the version number? >> The rules for this need to be precise, otherwise there may be = unexpected > string compare results. It'd be good if the version number could be > extracted from the XML Schema for the embedded content (and hence = >take > advantage of the rules in the referenced specification for the syntax = of > [Specification]Version). >>=20 >> A simple (silly) example of what can go wrong is that OVAL is = currently at > version 5.10 - that's not the same as 5.1, but if it's converted to a > number, the result is easy to misparse it as being equivalent to 5.1 = ;-). > Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if = the '.' > causes problems in some tooling? All of these are easy for a human to = sort > out, but potential causes of problems in automated tools. >=20 > Yes, I agree. > To clarify this issue, I'll add a sentence "parsers are expected to = read the > namespace of the embedded structured information and identify = specification > name and data, whenever such information is available, and parse the > embedded data." >=20 > Then one potential question we might have is, do we need the > SpecificationName and SpecificationVersion elements? > If the namespace described in the embedded structured information = identify > the specification name and its version, one might think these elements = are > useless. > However, in my opinion, we still need these elements since some of the > embedded information could be non-xml in the future. >=20 > Thank you. >=20 > Take >=20 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com]=20 > Sent: Tuesday, August 16, 2011 10:15 AM > To: takeshi_takahashi@nict.go.jp; mile@ietf.org > Subject: RE: [mile] draft on IODEF extension to support structured > cybersecurity information >=20 > Hi Take, >=20 > Enjoy your vacation, here are some comments to look at when you = return: >=20 > 1) >> Maybe we could use ENUM (instead of ML_STRING), and enumerate = possible > specifications. >> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use=20 >> ENUM for dtype and FraudType description. >=20 > That sounds like a good approach - each RFC that registers a value for = the > ENUM should include a pointer to the XML Schema for that specification = as > part of making the registration with IANA (the IANA registry entry = will > reference the RFC for the details). This may help recipients ensure = that > they have local copies of the XML schemas necessary to parse expected > content. >=20 > 2) >> So, my assumption here is that a complete CVE (compatible with its=20 >> schema) will be embedded here. >=20 > I don't have a problem with that assumption, but think it should be = stated > because that conclusion is not obvious [well, at least not to me ;-) = ]. It > should be sufficient to state that the embedded element is a complete = XML > document that is formatted according to the schema referenced by the = IANA > registration of the ENUM value used for SpecificationName (see item = 1). >=20 >> 3) >> Maybe some text in the draft has caused mis-understanding. >> Yes, the latest version of the XCCDF schema is 1.6. >> I intended to say that the number of the version element is zero or = one. >> Most of specifications such as XCCDF etc. have versions while CVE = does > not. >> Thus the number of this element class is ZERO or ONE. >=20 > I misread what you wrote, sorry about that. I was looking for the = syntax of > the contents of the [Specification]Version element, and looked in the = wrong > place. >=20 > My concern is similar to item 1) - how does the recipient parse and = check > the version number? > The rules for this need to be precise, otherwise there may be = unexpected > string compare results. It'd be good if the version number could be > extracted from the XML Schema for the embedded content (and hence take > advantage of the rules in the referenced specification for the syntax = of > [Specification]Version). >=20 > A simple (silly) example of what can go wrong is that OVAL is = currently at > version 5.10 - that's not the same as 5.1, but if it's converted to a > number, the result is easy to misparse it as being equivalent to 5.1 = ;-). > Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if = the '.' > causes problems in some tooling? All of these are easy for a human to = sort > out, but potential causes of problems in automated tools. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >> Sent: Sunday, August 14, 2011 9:25 AM >> To: Black, David; mile@ietf.org >> Subject: RE: [mile] draft on IODEF exstension to support structured=20= >> cybersecurity information >>=20 >> Hi David, >>=20 >> Thank you for your kind comments. >> I agree, I'll change the element class name. >>=20 >> Regarding the issues you kindly raised in the email, let me describe=20= >> my understanding. >>=20 >> 1) >> My assumption was, when parsing the xml data, the parser anyway reads=20= >> the namespace described in the embedded xml data and parse the data. >> But I agree, it would be better to limit the description of=20 >> SpecificationName. >> Maybe we could use ENUM (instead of ML_STRING), and enumerate = possible=20 >> specifications. >> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use=20 >> ENUM for dtype and FraudType description. >> Like the same way, the SpecificationName could use ENUM for = describing=20 >> specifications, though we do not have that much specifications to=20 >> enumerate at this moment. >>=20 >> 2) >> I am not sure whether it is easier for information sender and = receiver=20 >> to send/receive partial CVE data. >> Maybe it would be easier for them to embed/receive/parse a complete=20= >> CVE data? >> If we send a partial CVE or the other structured data, receiver may=20= >> suffer from some parsing problem, as you mentioned. >> So, my assumption here is that a complete CVE (compatible with its=20 >> schema) will be embedded here. >>=20 >> 3) >> Maybe some text in the draft has caused mis-understanding. >> Yes, the latest version of the XCCDF schema is 1.6. >> I intended to say that the number of the version element is zero or = one. >> Most of specifications such as XCCDF etc. have versions while CVE = does > not. >> Thus the number of this element class is ZERO or ONE. >>=20 >> Above are my viewpoint, but I might be wrong. >> Let me develop the draft based on your kind comments after my = vacation. >> Please correct me if I am wrong, I would like to welcome feedbacks. >>=20 >> Thank you. >>=20 >> Take >>=20 >>=20 >> From: david.black@emc.com [mailto:david.black@emc.com] >> Sent: Wednesday, August 10, 2011 8:45 AM >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org >> Cc: david.black@emc.com >> Subject: RE: [mile] draft on IODEF exstension to support structured=20= >> cybersecurity information >>=20 >> Hi Take, >>=20 >> For clarity I'd suggest not using "Version" as the name of both an=20 >> extension attribute and one of the classes in each extension. =20 >> Renaming the class to SpecificationVersion would be clearer (so=20 >> Version is the attribute with the version of the extension). >>=20 >> I also have a few questions: >>=20 >> (1) What strings are valid for SpecificationName? If the recipient=20= >> doesn't understand the SpecificationName, the information in the=20 >> extension may be unparseable, so this probably needs to be = controlled. >>=20 >> An IANA registry may be appropriate to list the valid strings and=20 >> associate each string with its corresponding specification. >>=20 >> (2) How does one determine the format for information formatted=20 >> according to an external specification? >>=20 >> For example, I believe that the XSD schema for the CVE list defines a=20= >> complete XML document, but I suspect that less than a complete XML=20 >> document is intended to be embedded because the proposed extension is=20= >> part of an IODEF XML document. >>=20 >> (3) Why is the [Specification]Version limited to zero or one? >>=20 >> For example, CAPEC is currently at Release 1.6. >>=20 >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer EMC Corporation, 176 South = St.,=20 >> Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= >> Of Takeshi Takahashi >> Sent: Monday, August 08, 2011 11:50 PM >> To: mile@ietf.org >> Subject: Re: [mile] draft on IODEF exstension to support structured=20= >> cybersecurity information >>=20 >> Thank you for those of you who kindly gave me off-line messages . >>=20 >> Let me share the draft with some minor modifications. >>=20 >> Sincerely, >> Take >>=20 >>=20 >> 2011/8/5 Takeshi Takahashi : >>> Dear all, >>>=20 >>>=20 >>>=20 >>> The attached is the tentative version of the draft prepared based on=20= >>> the comments I've received in this mailing list (Thanks a lot for = that). >>>=20 >>> It would be great if you could provide some comments on Clause 4,=20 >>> where >> the >>> IODEF extension is defined. >>>=20 >>>=20 >>>=20 >>> As you know, there are many ways to embed structured information=20 >>> (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very > flexible. >>>=20 >>> Thus, I would be happy to change and develop the draft further based=20= >>> on >> your >>> comments. >>>=20 >>>=20 >>>=20 >>> I would like to welcome any comments on that. >>>=20 >>>=20 >>>=20 >>> By the way, I will be on vacation, thus my response might be slow,=20= >>> sorry >> for >>> the inconvenience. >>>=20 >>>=20 >>>=20 >>> Take >>>=20 >>>=20 >>>=20 >>> PS: I've changed the title of the email. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> 2011/7/29 >>>=20 >>>>=20 >>>=20 >>>> Thank you, the approach sounds good, especially since it is in use=20= >>>> today >>>=20 >>>> by at least the Research and Education ISAC. Do others have=20 >>>> opinions on >>>=20 >>>> the proposal here? >>>=20 >>>>=20 >>>=20 >>>> Thanks for writing the first draft Take! >>>=20 >>>>=20 >>>=20 >>>> Best regards, >>>=20 >>>> Kathleen >>>=20 >>>> ________________________________________ >>>=20 >>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of=20 >>>> Takeshi >>>=20 >>>> Takahashi [takeshi_takahashi@nict.go.jp] >>>=20 >>>> Sent: Friday, July 29, 2011 9:20 AM >>>=20 >>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com >>>=20 >>>> Cc: mile@ietf.org >>>=20 >>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>=20 >>>=20 >>>> Thank you, Bob, for the email. >>>=20 >>>> I also like Tom's suggestion very much. >>>=20 >>>> Let me work on the "draft" of the draft for a while, then come back=20= >>>> to >> you >>>=20 >>>> later. >>>=20 >>>>=20 >>>=20 >>>> Take >>>=20 >>>>=20 >>>=20 >>>> -----Original Message----- >>>=20 >>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] >>>=20 >>>> Sent: Friday, July 29, 2011 9:10 AM >>>=20 >>>> To: Kent_Landfield@McAfee.com >>>=20 >>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; >>>=20 >>>> wes@ren-isac.net; mile@ietf.org >>>=20 >>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>=20 >>>=20 >>>> I also like how this is evolving. >>>=20 >>>>=20 >>>=20 >>>> I think, as Tom's suggestions pointed, that any and all of the=20 >>>> useful >>>=20 >>>> types >>>=20 >>>> of information that can help with understanding, diagnosing, and=20 >>>> getting >>>=20 >>>> ahead of an incident should be added but for now we should focus on=20= >>>> those >>>=20 >>>> the most established and well articulated. >>>=20 >>>>=20 >>>=20 >>>> This can be the compliance/patch/configuration/platform information >>>=20 >>>> related >>>=20 >>>> to the SCAP use case, or event signature/attack pattern/traffic >>>=20 >>>> characteristics from events, or the vulnerability/threat=20 >>>> characterization >>>=20 >>>> space. >>>=20 >>>>=20 >>>=20 >>>> I look forward to Taki's draft to see how he suggests positioning=20= >>>> these >>>=20 >>>> concepts. >>>=20 >>>>=20 >>>=20 >>>> Bob >>>=20 >>>>=20 >>>=20 >>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: >>>=20 >>>>> I like where this is headed. >>>=20 >>>>>=20 >>>=20 >>>>> Thanks Takeshi. I look forward to your draft. It will give us >> something >>>=20 >>>> real to discuss. I appreciate you jumping in and getting this = started. >>>=20 >>>>>=20 >>>=20 >>>>> One question that I am not clear on. What do we envision as the=20 >>>>> actual >>>=20 >>>> set >>>=20 >>>> of deliverables? =46rom and SCAP related perspective, are we = looking=20 >>>> at a >>>=20 >>>> single draft covering all the extensions? >>>=20 >>>>>=20 >>>=20 >>>>> Kent >>>=20 >>>>>=20 >>>=20 >>>>> Kent Landfield >>>=20 >>>>> Director Content Strategy, Architecture and Standards >>>=20 >>>>>=20 >>>=20 >>>>> McAfee, Inc. >>>=20 >>>>> 5000 Headquarters Dr. >>>=20 >>>>> Plano, Texas 75024 >>>=20 >>>>>=20 >>>=20 >>>>> Direct: +1.972.963.7096 >>>=20 >>>>> Mobile: +1.817.637.8026 >>>=20 >>>>> Web: www.mcafee.com >>>=20 >>>>>=20 >>>=20 >>>>> From: Takeshi >>>=20 >>>>> Takahashi>>>> ict.g >>>=20 >>>>> o.jp>> >>>=20 >>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 >>>=20 >>>>> To: >>>=20 >>>>> "Thomas.Millar@us-cert.gov">>>> mas.M >>>=20 >>>>> illar@us-cert.gov>, >>>=20 >>>>> "wes@ren-isac.net">>>> to:we >>>=20 >>>>> s@ren-isac.net>>, >>>=20 >>>>> "mile@ietf.org">>>> etf.o >>>=20 >>>>> rg>> >>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>>=20 >>>=20 >>>>> Thank you for the email, Tom. >>>=20 >>>>>=20 >>>=20 >>>>> So, here is what the draft needs to describe (if I understand Wes=20= >>>>> and >>>=20 >>>>> Tom correctly). >>>=20 >>>>>=20 >>>=20 >>>>> The draft should define ext-dtype (an attribute of AdditionalData >>>=20 >>>>> Class) to identify the information type, rather than defining new >>>=20 >>>>> class under AdditionalData. >>>=20 >>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe,=20 >>>>> ext-capec, >>>=20 >>>>> ext-cvss, ext-cwss, In this way, we could keep the change minimal=20= >>>>> and >>>=20 >>>>> could easily embed various structured information (CVE etc.) in=20 >>>>> the >>>=20 >>>>> EventData.Record.RecordData.AdditionalData field. >>>=20 >>>>> Then "should" statement should be carefully placed in the text of >>>=20 >>>>> relevant class. >>>=20 >>>>>=20 >>>=20 >>>>> I'll prepare some draft so that we could discuss and advance = further. >>>=20 >>>>>=20 >>>=20 >>>>> Take >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>> -----Original Message----- >>>=20 >>>>> From: mile-bounces@ietf.org >>>=20 >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>=20 >>>>> Thomas.Millar@us-cert.gov >>>=20 >>>>> Sent: Thursday, July 28, 2011 6:28 PM >>>=20 >>>>> To: wes@ren-isac.net; >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>>=20 >>>=20 >>>>> I think this approach makes more sense. One of the things I think >>>=20 >>>>> could be helpful is to have a number of SHOULD statements further >>>=20 >>>>> describing the possible types of other documents that would be >>>=20 >>>>> expected to ride under the AdditionalData elements of each class=20= >>>>> (not >>>=20 >>>> just >>>=20 >>>> EventData). >>>=20 >>>>> What I'm thinking of looks like this (very unpolished): >>>=20 >>>>>=20 >>>=20 >>>>> "The Method Class:AdditionalData class SHOULD contain data=20 >>>>> elements >>>=20 >>>>> that describe the methods, tools or techniques employed to cause=20= >>>>> the >>>=20 >>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning=20 >>>>> the >>>=20 >>>>> method such as CVSS, CWSS, or CCE." >>>=20 >>>>>=20 >>>=20 >>>>> "The Expectation Class[...] SHOULD contain data elements which >>>=20 >>>>> describe configuration changes, detection heuristics, or [*=20 >>>>> (legal >>>=20 >>>>> authorization?)] to assist in executing or implementing the=20 >>>>> requested >>>=20 >>>>> action, such as XCCDF, OCIL, OVAL, etc" >>>=20 >>>>>=20 >>>=20 >>>>> This could go towards encouraging better or at least more=20 >>>>> consistent >>>=20 >>>>> use of "boundary objects" in the substance of incident reports. I >>>=20 >>>>> could also go on about greater automation and such but that's=20 >>>>> probably >>>=20 >>>>> out of scope for this e-mail. >>>=20 >>>>>=20 >>>=20 >>>>>=20 >>>=20 >>>>> - Tom Millar, US-CERT >>>=20 >>>>>=20 >>>=20 >>>>> thomas.millar@us-cert.gov >>>=20 >>>>> BB: thomas.millar@dhs.gov / >>>=20 >>>>> 202-631-1915 >>>=20 >>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>=20 >>>>> -----Original Message----- >>>=20 >>>>> From: mile-bounces@ietf.org >>>=20 >>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young >>>=20 >>>>> Sent: Thursday, July 28, 2011 11:08 AM >>>=20 >>>>> To: mile@ietf.org >>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>=20 >>>>>=20 >>>=20 >>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM >>>=20 >>>>>=20 >>>=20 >>>>> http://tools.ietf.org/html/rfc5070#section-3.19 >>>=20 >>>>>=20 >>>=20 >>>>> i've been sticking other "XML like" records under this (icsg1.1=20 >>>>> data, >>>=20 >>>>> etc...). >>>=20 >>>>>=20 >>>=20 >>>>> pretty easy to do, just generate the "other standards" xml (or=20 >>>>> json or >>>=20 >>>>> whatever), embed it there. turns iodef into a sharing platform=20 >>>>> for >>>=20 >>>>> other data-types w/o having to extend it too much. >>>=20 >>>>>=20 >>>=20 >>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: >>>=20 >>>>>=20 >>>=20 >>>>> So, maybe we could extend the IODEF as described in Figure 1 of=20 >>>>> the >>>=20 >>>>> attached txt file. (correct me if I'm wrong) We could define >>>=20 >>>>> Incident.EventData.AdditionalData elements and describe them by=20 >>>>> using >>>=20 >>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. >>>=20 >>>>> Regarding OVAL, we might define Incident.AdditionalData element,=20= >>>>> but I >>>=20 >>>>>=20 >>>=20 >>>>> am not sure at this moment, thus is not described in the figure = yet. >>>=20 >>>>> I would like to tackle CAPEC first since I believe Kent would=20 >>>>> like to >>>=20 >>>>> tackle CVE and CAPEC. >>>=20 >>>>>=20 >>>=20 >>>>> -- >>>=20 >>>>> Wes >>>=20 >>>>> claimid.com/wesyoung >>>=20 >>>>> soc@ren-isac.net >>>=20 >>>>>=20 >>>=20 >>>>> * Wes Young> >>>=20 >>>>> * 0xDDB6E946 - Unverified(L) >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>>=20 >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>>=20 >>>=20 >>>>> _______________________________________________ >>>=20 >>>>> mile mailing list >>>=20 >>>>> mile@ietf.org >>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>>> . >>>=20 >>>>>=20 >>>=20 >>>>=20 >>>=20 >>>> _______________________________________________ >>>=20 >>>> mile mailing list >>>=20 >>>> mile@ietf.org >>>=20 >>>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> -- >> Takeshi Takahashi, Ph.D. >> +81 80 3490 2971 >> http://www.taketaka.com/ >>=20 >>=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Wed Aug 24 01:42:38 2011 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 459DE21F8AE6 for ; Wed, 24 Aug 2011 01:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0A6zex+jUQl for ; Wed, 24 Aug 2011 01:42:36 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 064A321F8AD6 for ; Wed, 24 Aug 2011 01:42:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 85C1ED9307; Wed, 24 Aug 2011 10:43:45 +0200 (MEST) 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 fV6HDcLf4Vm8; Wed, 24 Aug 2011 10:43:45 +0200 (MEST) 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 3A90AD9302; Wed, 24 Aug 2011 10:43:44 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <018f01cc6238$e6fa0f60$b4ee2e20$@nict.go.jp> Date: Wed, 24 Aug 2011 10:43:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D14417A-40EE-4865-81B5-2D6A10EDCC85@tik.ee.ethz.ch> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <013601cc6235$3196b1d0$94c41570$@nict.go.jp> <510A8D02-449C-43C3-9D60-2F25C16BC277@tik.ee.ethz.ch> <018f01cc6238$e6fa0f60$b4ee2e20$@nict.go.jp> To: Takeshi Takahashi X-Mailer: Apple Mail (2.1084) Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information 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, 24 Aug 2011 08:42:38 -0000 Hi, Take, I prefer option 1 as well... (This would additionally appear to resolve my previous question.) Cheers, Brian On Aug 24, 2011, at 10:36 AM, Takeshi Takahashi wrote: > Hi Brian, >=20 > I like the 1st option you kindly raised here. > I appreciate your assistance. >=20 > Let me update the text and come back to the list soon. > (I will make sure all the comments I've received in this list should = be > reflected.) >=20 > Best Regards, > Take >=20 >=20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 > Sent: Wednesday, August 24, 2011 10:17 AM > To: Takeshi Takahashi > Cc: david.black@emc.com; mile@ietf.org > Subject: Re: [mile] draft on IODEF extension to support structured > cybersecurity information >=20 > Hi, Take, >=20 > To my understanding, there are two possible answers to this last = question, > each with their own disadvantages: >=20 > 1. The SpecificationName and SpecificationVersion are present and = required, > and MUST match any version information carried by the enclosed XML = namespace > and schema. This gives you a nice envelope for determining which = version of > the extension you're using, but can lead to inconsistency if = improperly > used. It is unclear what a reader should do when an inconsistency is > detected. In line with common practice in protocol design (send > conservatively, accept liberally), I would suggest "writers/senders = MUST > ensure the SpecificationName and SpecificationVersion are consistent = with > the contents; if a reader/receiver detects an inconsistency, it SHOULD > prefer the specification and version derived from the content, and = SHOULD > log the inconsistency so a human can correct the problem." But it = should be > addressed in any case. >=20 > 2. The SpecificationName and SpecificationVersion are only present = when that > information is not derivable from the enclosed XML namespace and = schema. > This is ugly, because it introduces two ways of doing the same = thing... >=20 > Best regards, >=20 > Brian >=20 > On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote: >=20 >> Hi David,=09 >>=20 >> Thanks for your email. >>=20 >> 1) >>>> Maybe we could use ENUM (instead of ML_STRING), and enumerate=20 >>>> possible >> specifications. >>>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use=20= >>>> ENUM for dtype and FraudType description. >>>=20 >>> That sounds like a good approach - each RFC that registers a value=20= >>> for the >> ENUM should include a pointer to the XML Schema for that = specification=20 >> as part of making the registration with IANA (the IANA registry entry=20= >> will reference the RFC for the details). This may help recipients=20 >> ensure that they have local copies of the XML schemas necessary to=20 >> parse expected content. >>=20 >> Thank you for telling me the IANA issue. I appreciate that. >>=20 >> 2) >>>> So, my assumption here is that a complete CVE (compatible with its >>>> schema) will be embedded here. >>>=20 >>> I don't have a problem with that assumption, but think it should be=20= >>> stated >> because that conclusion is not obvious [well, at least not to me ;-)=20= >> ]. It should be sufficient to state that the embedded element is a=20= >> complete XML document that is formatted according to the schema=20 >> referenced by the IANA registration of the ENUM value used for > SpecificationName (see item 1). >>=20 >> I see. I will. Thank you. >>=20 >>> My concern is similar to item 1) - how does the recipient parse and=20= >>> check >> the version number? >>> The rules for this need to be precise, otherwise there may be=20 >>> unexpected >> string compare results. It'd be good if the version number could be=20= >> extracted from the XML Schema for the embedded content (and hence=20 >>> take advantage of the rules in the referenced specification for the=20= >> syntax of [Specification]Version). >>>=20 >>> A simple (silly) example of what can go wrong is that OVAL is=20 >>> currently at >> version 5.10 - that's not the same as 5.1, but if it's converted to a=20= >> number, the result is easy to misparse it as being equivalent to 5.1 = ;-). >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if = the > '.' >> causes problems in some tooling? All of these are easy for a human = to=20 >> sort out, but potential causes of problems in automated tools. >>=20 >> Yes, I agree. >> To clarify this issue, I'll add a sentence "parsers are expected to=20= >> read the namespace of the embedded structured information and = identify=20 >> specification name and data, whenever such information is available,=20= >> and parse the embedded data." >>=20 >> Then one potential question we might have is, do we need the=20 >> SpecificationName and SpecificationVersion elements? >> If the namespace described in the embedded structured information=20 >> identify the specification name and its version, one might think = these=20 >> elements are useless. >> However, in my opinion, we still need these elements since some of = the=20 >> embedded information could be non-xml in the future. >>=20 >> Thank you. >>=20 >> Take >>=20 >> -----Original Message----- >> From: david.black@emc.com [mailto:david.black@emc.com] >> Sent: Tuesday, August 16, 2011 10:15 AM >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org >> Subject: RE: [mile] draft on IODEF extension to support structured=20 >> cybersecurity information >>=20 >> Hi Take, >>=20 >> Enjoy your vacation, here are some comments to look at when you = return: >>=20 >> 1) >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate=20 >>> possible >> specifications. >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use=20= >>> ENUM for dtype and FraudType description. >>=20 >> That sounds like a good approach - each RFC that registers a value = for=20 >> the ENUM should include a pointer to the XML Schema for that=20 >> specification as part of making the registration with IANA (the IANA=20= >> registry entry will reference the RFC for the details). This may = help=20 >> recipients ensure that they have local copies of the XML schemas=20 >> necessary to parse expected content. >>=20 >> 2) >>> So, my assumption here is that a complete CVE (compatible with its >>> schema) will be embedded here. >>=20 >> I don't have a problem with that assumption, but think it should be=20= >> stated because that conclusion is not obvious [well, at least not to=20= >> me ;-) ]. It should be sufficient to state that the embedded element=20= >> is a complete XML document that is formatted according to the schema=20= >> referenced by the IANA registration of the ENUM value used for > SpecificationName (see item 1). >>=20 >>> 3) >>> Maybe some text in the draft has caused mis-understanding. >>> Yes, the latest version of the XCCDF schema is 1.6. >>> I intended to say that the number of the version element is zero or = one. >>> Most of specifications such as XCCDF etc. have versions while CVE=20 >>> does >> not. >>> Thus the number of this element class is ZERO or ONE. >>=20 >> I misread what you wrote, sorry about that. I was looking for the=20 >> syntax of the contents of the [Specification]Version element, and=20 >> looked in the wrong place. >>=20 >> My concern is similar to item 1) - how does the recipient parse and=20= >> check the version number? >> The rules for this need to be precise, otherwise there may be=20 >> unexpected string compare results. It'd be good if the version = number=20 >> could be extracted from the XML Schema for the embedded content (and=20= >> hence take advantage of the rules in the referenced specification for=20= >> the syntax of [Specification]Version). >>=20 >> A simple (silly) example of what can go wrong is that OVAL is=20 >> currently at version 5.10 - that's not the same as 5.1, but if it's=20= >> converted to a number, the result is easy to misparse it as being > equivalent to 5.1 ;-). >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if = the > '.' >> causes problems in some tooling? All of these are easy for a human = to=20 >> sort out, but potential causes of problems in automated tools. >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] >>> Sent: Sunday, August 14, 2011 9:25 AM >>> To: Black, David; mile@ietf.org >>> Subject: RE: [mile] draft on IODEF exstension to support structured=20= >>> cybersecurity information >>>=20 >>> Hi David, >>>=20 >>> Thank you for your kind comments. >>> I agree, I'll change the element class name. >>>=20 >>> Regarding the issues you kindly raised in the email, let me describe=20= >>> my understanding. >>>=20 >>> 1) >>> My assumption was, when parsing the xml data, the parser anyway = reads=20 >>> the namespace described in the embedded xml data and parse the data. >>> But I agree, it would be better to limit the description of=20 >>> SpecificationName. >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate=20 >>> possible specifications. >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use=20= >>> ENUM for dtype and FraudType description. >>> Like the same way, the SpecificationName could use ENUM for=20 >>> describing specifications, though we do not have that much=20 >>> specifications to enumerate at this moment. >>>=20 >>> 2) >>> I am not sure whether it is easier for information sender and=20 >>> receiver to send/receive partial CVE data. >>> Maybe it would be easier for them to embed/receive/parse a complete=20= >>> CVE data? >>> If we send a partial CVE or the other structured data, receiver may=20= >>> suffer from some parsing problem, as you mentioned. >>> So, my assumption here is that a complete CVE (compatible with its >>> schema) will be embedded here. >>>=20 >>> 3) >>> Maybe some text in the draft has caused mis-understanding. >>> Yes, the latest version of the XCCDF schema is 1.6. >>> I intended to say that the number of the version element is zero or = one. >>> Most of specifications such as XCCDF etc. have versions while CVE=20 >>> does >> not. >>> Thus the number of this element class is ZERO or ONE. >>>=20 >>> Above are my viewpoint, but I might be wrong. >>> Let me develop the draft based on your kind comments after my = vacation. >>> Please correct me if I am wrong, I would like to welcome feedbacks. >>>=20 >>> Thank you. >>>=20 >>> Take >>>=20 >>>=20 >>> From: david.black@emc.com [mailto:david.black@emc.com] >>> Sent: Wednesday, August 10, 2011 8:45 AM >>> To: takeshi_takahashi@nict.go.jp; mile@ietf.org >>> Cc: david.black@emc.com >>> Subject: RE: [mile] draft on IODEF exstension to support structured=20= >>> cybersecurity information >>>=20 >>> Hi Take, >>>=20 >>> For clarity I'd suggest not using "Version" as the name of both an=20= >>> extension attribute and one of the classes in each extension. >>> Renaming the class to SpecificationVersion would be clearer (so=20 >>> Version is the attribute with the version of the extension). >>>=20 >>> I also have a few questions: >>>=20 >>> (1) What strings are valid for SpecificationName? If the recipient=20= >>> doesn't understand the SpecificationName, the information in the=20 >>> extension may be unparseable, so this probably needs to be = controlled. >>>=20 >>> An IANA registry may be appropriate to list the valid strings and=20 >>> associate each string with its corresponding specification. >>>=20 >>> (2) How does one determine the format for information formatted=20 >>> according to an external specification? >>>=20 >>> For example, I believe that the XSD schema for the CVE list defines = a=20 >>> complete XML document, but I suspect that less than a complete XML=20= >>> document is intended to be embedded because the proposed extension = is=20 >>> part of an IODEF XML document. >>>=20 >>> (3) Why is the [Specification]Version limited to zero or one? >>>=20 >>> For example, CAPEC is currently at Release 1.6. >>>=20 >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer EMC Corporation, 176 South=20 >>> St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>>=20 >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf=20= >>> Of Takeshi Takahashi >>> Sent: Monday, August 08, 2011 11:50 PM >>> To: mile@ietf.org >>> Subject: Re: [mile] draft on IODEF exstension to support structured=20= >>> cybersecurity information >>>=20 >>> Thank you for those of you who kindly gave me off-line messages . >>>=20 >>> Let me share the draft with some minor modifications. >>>=20 >>> Sincerely, >>> Take >>>=20 >>>=20 >>> 2011/8/5 Takeshi Takahashi : >>>> Dear all, >>>>=20 >>>>=20 >>>>=20 >>>> The attached is the tentative version of the draft prepared based = on=20 >>>> the comments I've received in this mailing list (Thanks a lot for = that). >>>>=20 >>>> It would be great if you could provide some comments on Clause 4,=20= >>>> where >>> the >>>> IODEF extension is defined. >>>>=20 >>>>=20 >>>>=20 >>>> As you know, there are many ways to embed structured information=20 >>>> (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very >> flexible. >>>>=20 >>>> Thus, I would be happy to change and develop the draft further = based=20 >>>> on >>> your >>>> comments. >>>>=20 >>>>=20 >>>>=20 >>>> I would like to welcome any comments on that. >>>>=20 >>>>=20 >>>>=20 >>>> By the way, I will be on vacation, thus my response might be slow,=20= >>>> sorry >>> for >>>> the inconvenience. >>>>=20 >>>>=20 >>>>=20 >>>> Take >>>>=20 >>>>=20 >>>>=20 >>>> PS: I've changed the title of the email. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> 2011/7/29 >>>>=20 >>>>>=20 >>>>=20 >>>>> Thank you, the approach sounds good, especially since it is in use=20= >>>>> today >>>>=20 >>>>> by at least the Research and Education ISAC. Do others have=20 >>>>> opinions on >>>>=20 >>>>> the proposal here? >>>>=20 >>>>>=20 >>>>=20 >>>>> Thanks for writing the first draft Take! >>>>=20 >>>>>=20 >>>>=20 >>>>> Best regards, >>>>=20 >>>>> Kathleen >>>>=20 >>>>> ________________________________________ >>>>=20 >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of=20= >>>>> Takeshi >>>>=20 >>>>> Takahashi [takeshi_takahashi@nict.go.jp] >>>>=20 >>>>> Sent: Friday, July 29, 2011 9:20 AM >>>>=20 >>>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com >>>>=20 >>>>> Cc: mile@ietf.org >>>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>>=20 >>>>>=20 >>>>=20 >>>>> Thank you, Bob, for the email. >>>>=20 >>>>> I also like Tom's suggestion very much. >>>>=20 >>>>> Let me work on the "draft" of the draft for a while, then come = back=20 >>>>> to >>> you >>>>=20 >>>>> later. >>>>=20 >>>>>=20 >>>>=20 >>>>> Take >>>>=20 >>>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>=20 >>>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] >>>>=20 >>>>> Sent: Friday, July 29, 2011 9:10 AM >>>>=20 >>>>> To: Kent_Landfield@McAfee.com >>>>=20 >>>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; >>>>=20 >>>>> wes@ren-isac.net; mile@ietf.org >>>>=20 >>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>>=20 >>>>>=20 >>>>=20 >>>>> I also like how this is evolving. >>>>=20 >>>>>=20 >>>>=20 >>>>> I think, as Tom's suggestions pointed, that any and all of the=20 >>>>> useful >>>>=20 >>>>> types >>>>=20 >>>>> of information that can help with understanding, diagnosing, and=20= >>>>> getting >>>>=20 >>>>> ahead of an incident should be added but for now we should focus = on=20 >>>>> those >>>>=20 >>>>> the most established and well articulated. >>>>=20 >>>>>=20 >>>>=20 >>>>> This can be the compliance/patch/configuration/platform = information >>>>=20 >>>>> related >>>>=20 >>>>> to the SCAP use case, or event signature/attack pattern/traffic >>>>=20 >>>>> characteristics from events, or the vulnerability/threat=20 >>>>> characterization >>>>=20 >>>>> space. >>>>=20 >>>>>=20 >>>>=20 >>>>> I look forward to Taki's draft to see how he suggests positioning=20= >>>>> these >>>>=20 >>>>> concepts. >>>>=20 >>>>>=20 >>>>=20 >>>>> Bob >>>>=20 >>>>>=20 >>>>=20 >>>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: >>>>=20 >>>>>> I like where this is headed. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Thanks Takeshi. I look forward to your draft. It will give us >>> something >>>>=20 >>>>> real to discuss. I appreciate you jumping in and getting this = started. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> One question that I am not clear on. What do we envision as the=20= >>>>>> actual >>>>=20 >>>>> set >>>>=20 >>>>> of deliverables? =46rom and SCAP related perspective, are we = looking=20 >>>>> at a >>>>=20 >>>>> single draft covering all the extensions? >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Kent >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Kent Landfield >>>>=20 >>>>>> Director Content Strategy, Architecture and Standards >>>>=20 >>>>>>=20 >>>>=20 >>>>>> McAfee, Inc. >>>>=20 >>>>>> 5000 Headquarters Dr. >>>>=20 >>>>>> Plano, Texas 75024 >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Direct: +1.972.963.7096 >>>>=20 >>>>>> Mobile: +1.817.637.8026 >>>>=20 >>>>>> Web: www.mcafee.com >>>>=20 >>>>>>=20 >>>>=20 >>>>>> From: Takeshi >>>>=20 >>>>>> Takahashi>>>>> ict.g >>>>=20 >>>>>> o.jp>> >>>>=20 >>>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 >>>>=20 >>>>>> To: >>>>=20 >>>>>> "Thomas.Millar@us-cert.gov">>>>> mas.M >>>>=20 >>>>>> illar@us-cert.gov>, >>>>=20 >>>>>> "wes@ren-isac.net">>>>> to:we >>>>=20 >>>>>> s@ren-isac.net>>, >>>>=20 >>>>>> "mile@ietf.org">>>>> etf.o >>>>=20 >>>>>> rg>> >>>>=20 >>>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Thank you for the email, Tom. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> So, here is what the draft needs to describe (if I understand Wes=20= >>>>>> and >>>>=20 >>>>>> Tom correctly). >>>>=20 >>>>>>=20 >>>>=20 >>>>>> The draft should define ext-dtype (an attribute of AdditionalData >>>>=20 >>>>>> Class) to identify the information type, rather than defining new >>>>=20 >>>>>> class under AdditionalData. >>>>=20 >>>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe,=20 >>>>>> ext-capec, >>>>=20 >>>>>> ext-cvss, ext-cwss, In this way, we could keep the change minimal=20= >>>>>> and >>>>=20 >>>>>> could easily embed various structured information (CVE etc.) in=20= >>>>>> the >>>>=20 >>>>>> EventData.Record.RecordData.AdditionalData field. >>>>=20 >>>>>> Then "should" statement should be carefully placed in the text of >>>>=20 >>>>>> relevant class. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> I'll prepare some draft so that we could discuss and advance = further. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> Take >>>>=20 >>>>>>=20 >>>>=20 >>>>>>=20 >>>>=20 >>>>>>=20 >>>>=20 >>>>>> -----Original Message----- >>>>=20 >>>>>> From: mile-bounces@ietf.org >>>>=20 >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of >>>>=20 >>>>>> Thomas.Millar@us-cert.gov >>>>=20 >>>>>> Sent: Thursday, July 28, 2011 6:28 PM >>>>=20 >>>>>> To: wes@ren-isac.net; >>>>=20 >>>>>> mile@ietf.org >>>>=20 >>>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>>=20 >>>>>>=20 >>>>=20 >>>>>> I think this approach makes more sense. One of the things I think >>>>=20 >>>>>> could be helpful is to have a number of SHOULD statements further >>>>=20 >>>>>> describing the possible types of other documents that would be >>>>=20 >>>>>> expected to ride under the AdditionalData elements of each class=20= >>>>>> (not >>>>=20 >>>>> just >>>>=20 >>>>> EventData). >>>>=20 >>>>>> What I'm thinking of looks like this (very unpolished): >>>>=20 >>>>>>=20 >>>>=20 >>>>>> "The Method Class:AdditionalData class SHOULD contain data=20 >>>>>> elements >>>>=20 >>>>>> that describe the methods, tools or techniques employed to cause=20= >>>>>> the >>>>=20 >>>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning=20= >>>>>> the >>>>=20 >>>>>> method such as CVSS, CWSS, or CCE." >>>>=20 >>>>>>=20 >>>>=20 >>>>>> "The Expectation Class[...] SHOULD contain data elements which >>>>=20 >>>>>> describe configuration changes, detection heuristics, or [* = (legal >>>>=20 >>>>>> authorization?)] to assist in executing or implementing the=20 >>>>>> requested >>>>=20 >>>>>> action, such as XCCDF, OCIL, OVAL, etc" >>>>=20 >>>>>>=20 >>>>=20 >>>>>> This could go towards encouraging better or at least more=20 >>>>>> consistent >>>>=20 >>>>>> use of "boundary objects" in the substance of incident reports. I >>>>=20 >>>>>> could also go on about greater automation and such but that's=20 >>>>>> probably >>>>=20 >>>>>> out of scope for this e-mail. >>>>=20 >>>>>>=20 >>>>=20 >>>>>>=20 >>>>=20 >>>>>> - Tom Millar, US-CERT >>>>=20 >>>>>>=20 >>>>=20 >>>>>> thomas.millar@us-cert.gov >>>>=20 >>>>>> BB: thomas.millar@dhs.gov / >>>>=20 >>>>>> 202-631-1915 >>>>=20 >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 >>>>=20 >>>>>> -----Original Message----- >>>>=20 >>>>>> From: mile-bounces@ietf.org >>>>=20 >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young >>>>=20 >>>>>> Sent: Thursday, July 28, 2011 11:08 AM >>>>=20 >>>>>> To: mile@ietf.org >>>>=20 >>>>>> Subject: Re: [mile] Updated presentation from Side meeting >>>>=20 >>>>>>=20 >>>>=20 >>>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM >>>>=20 >>>>>>=20 >>>>=20 >>>>>> http://tools.ietf.org/html/rfc5070#section-3.19 >>>>=20 >>>>>>=20 >>>>=20 >>>>>> i've been sticking other "XML like" records under this (icsg1.1=20= >>>>>> data, >>>>=20 >>>>>> etc...). >>>>=20 >>>>>>=20 >>>>=20 >>>>>> pretty easy to do, just generate the "other standards" xml (or=20 >>>>>> json or >>>>=20 >>>>>> whatever), embed it there. turns iodef into a sharing platform = for >>>>=20 >>>>>> other data-types w/o having to extend it too much. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: >>>>=20 >>>>>>=20 >>>>=20 >>>>>> So, maybe we could extend the IODEF as described in Figure 1 of=20= >>>>>> the >>>>=20 >>>>>> attached txt file. (correct me if I'm wrong) We could define >>>>=20 >>>>>> Incident.EventData.AdditionalData elements and describe them by=20= >>>>>> using >>>>=20 >>>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. >>>>=20 >>>>>> Regarding OVAL, we might define Incident.AdditionalData element,=20= >>>>>> but I >>>>=20 >>>>>>=20 >>>>=20 >>>>>> am not sure at this moment, thus is not described in the figure = yet. >>>>=20 >>>>>> I would like to tackle CAPEC first since I believe Kent would = like=20 >>>>>> to >>>>=20 >>>>>> tackle CVE and CAPEC. >>>>=20 >>>>>>=20 >>>>=20 >>>>>> -- >>>>=20 >>>>>> Wes >>>>=20 >>>>>> claimid.com/wesyoung >>>>=20 >>>>>> soc@ren-isac.net >>>>=20 >>>>>>=20 >>>>=20 >>>>>> * Wes Young> >>>>=20 >>>>>> * 0xDDB6E946 - Unverified(L) >>>>=20 >>>>>> _______________________________________________ >>>>=20 >>>>>> mile mailing list >>>>=20 >>>>>> mile@ietf.org >>>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>>> _______________________________________________ >>>>=20 >>>>>> mile mailing list >>>>=20 >>>>>> mile@ietf.org >>>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>>>=20 >>>>=20 >>>>>> _______________________________________________ >>>>=20 >>>>>> mile mailing list >>>>=20 >>>>>> mile@ietf.org >>>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>>>=20 >>>>=20 >>>>>> _______________________________________________ >>>>=20 >>>>>> mile mailing list >>>>=20 >>>>>> mile@ietf.org >>>>=20 >>>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>>> . >>>>=20 >>>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>> _______________________________________________ >>>>=20 >>>>> mile mailing list >>>>=20 >>>>> mile@ietf.org >>>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mile >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> -- >>> Takeshi Takahashi, Ph.D. >>> +81 80 3490 2971 >>> http://www.taketaka.com/ >>>=20 >>>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Aug 24 02:29:44 2011 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 2660421F893C for ; Wed, 24 Aug 2011 02:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 MxGaq0EdCYyu for ; Wed, 24 Aug 2011 02:29:42 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A4DB021F88A0 for ; Wed, 24 Aug 2011 02:29:41 -0700 (PDT) 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 p7O9UmoO009152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 05:30:48 -0400 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, 24 Aug 2011 05:30:40 -0400 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 p7O9Udsx018115 for ; Wed, 24 Aug 2011 05:30:40 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Wed, 24 Aug 2011 05:30:39 -0400 From: To: , Date: Wed, 24 Aug 2011 05:30:37 -0400 Thread-Topic: RFC6045-bis, update per ITU comments and list discussions Thread-Index: AQHMXo5mIaSIRvdFOEiwAnJNhOiIG5UqncUggAEVqzc= Message-ID: References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@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] RFC6045-bis, update per ITU comments and list discussions 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, 24 Aug 2011 09:29:44 -0000 Hello David, Thank you for your comments. Questions for the list are indented. I would like more opinions on a few of the questions raised. In particular= , for those that share documents with law enforcement, do we need multiple = options? This could be used in combination with the TrafficType option of = "OfficialBusiness", but does not specify if the government entity is local,= regional, national, etc. Should we include one option of LawEnforcement as the entities sendin= g/receiving the RID message would know what type of LawEnforcement agency in which the message is= being exchanged. Or do others on the list who exchange incident information think it would be helpf= ul to have multiple enumerated values to represent the types of agencies. The values for the second option= could be "LawEnforcement-local",=20 "LawEnforcement-regional", and "LawEnforcement-national". If the inc= ident documents are forwarded from one type of law enforcement agency to another, digital signatures on = the additions from each group would provide the traceability of any new information. I added the following to the description of the "LawEnforcement" enumeratio= n per David's suggestion: "If the law enforcement agency resides within a different nation that the s= ending entity, the "AcrossNationalBoundaries" enumeration MUST also be set.= " XML Encryption: Thank you for pointing out the need for clarification on the new text. The= intent is the same as if the IPPacket were to be used for the signature wh= ere only the text entered by an entity would be signed by that entity. =20 Would the additional sentence (2nd sentence) provide enough clarifica= tion for this intention: "If an Investigation request does not include an IP packet, the EventData c= lass instance from each the parties involved in the investigation MUST be s= igned using a detached signature. The signature MUST only be applied to th= e data entered or added from each entity to provide a method of authenticat= ion on the work added by any party involved in the investigation. The Even= tData class can be used to extend information about an incident by each CSI= RT or SP involved in the investigation. Using this class for the digital s= ignature when an IP Packet is not included provides a method to verify each= party contributing to the details of the incident." XML Encryption: I will provide additional information on the use of PKI, but will do this t= hrough pointers to existing standards like RFC5280. If there are updates t= o PKI, we should build in the flexibility to leverage updates to those spec= ifications. RFC5280 covers path validation (verify the chain of the certif= icate and status) so that one is able to verify the CA that signed a certif= icate and also check a revocation list. =20 As for key distribution, this is outside of IODEF and RID. I will be sure = to add additional text to provide references on recommendations for these f= unctions. The security of the key distribution process and the levels of t= rust for PKI would be based on policies agreed between entities. The identity of entities in the IODEF document are in the contact class. =20 For the use of a group key, I will be sure to reference the appropriate sta= ndards. Again in this case, policy sets the agreed upon handling of keys b= etween entities. There may be entities that do not require as high a level= of trust as other sets of entities or consortiums. I will be sure to incl= ude references to policies/agreements to set the appropriate levels of trus= t. I will develop text to address the questions raised in this section and sen= d them to the list for review. Thank you for the opinion on characteristics of an attack. I will add this= text back in, but will need to be careful to ensure other attack ties like= social engineering are represented in this section as the use cases for IO= DEF has expanded and will continue to expand with the addition of the propo= sed extensions for MILE. Thanks for the note on SHALL versus MUST. I forgot to mention that I will = use the SHALL and other ITU-T preferred key words for the ITU-T while forma= lizing the document over the next week+ in this forum. One the text is for= malized here with considerations for translating into multiple languages, I= will update the text in RFC6045-bis to match, but will use the IETF key wo= rds, MUST, etc. Thank you, Kathleen ________________________________________ From: Black, David Sent: Tuesday, August 23, 2011 12:41 PM To: Moriarty, Kathleen; MILE@ietf.org Subject: RE: RFC6045-bis, update per ITU comments and list discussions Hi Kathleen, > "LawEnforcement" was added as a RIDPolicy option in text and in schema. = This was added as a result of > some on and off-list discussions as the option is relevant today for Law = enforcement that already > accepts incidents in an IODEF format. IODEF is required in Japan when se= nding incidents to law > enforcement. That seems very general in isolation, as there are a lot of law enforcement= agencies. Is a single ENUM value sufficient, or is it useful to distinguish regional,= national and/or other law enforcement bodies? At a minimum, it would be useful to include a reminder that use of "LawEnfo= rcement" does not remove the requirement to additionally use "AcrossNationalBoundaries" w= hen the later also applies. -- XML Digital Signature This text is not clear to me: > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. Is that one signature covering all the EventData from every party involved,= or is each party supposed to supply a signature for the EventData contributed by that = party? I suspect the latter was intended (e.g., as I have no idea why Alice should b= e signing event data from Bob that she can't independently verify), so some rephrasin= g is probably in order. -- XML Encryption I'm somewhat concerned that the new XML Encryption text is requiring use of= keys without saying anything about key distribution or management. While mandating spec= ific key distribution and/or management protocols would be overly restrictive, it wo= uld be good to provide some guidance on what needs to be done for some level of assuran= ce that the encryption is done with the correct key and the intended recipient(s) (but = not other parties) will be able to decrypt the result. For example: (1) "private" uses a public key of the recipient. How does the sender verif= y the binding of the public key to the recipient's identity? A discussion of how to use a= certificate to do that (e.g., where's the recipient's identity in the RID/IODEF XML, how i= s it supposed to match which field in the certificate) with a suitable PKIX RFC reference wo= uld be helpful. A reminder to check for revocation (e.g., of the certificate) before using = a public key would also be good. (2) "need-to-know" allows use of a group-shared symmetric encryption key th= at is somehow distributed to the recipients. That's potentially dangerous if not careful= ly controlled, and as this is the "Security Considerations" section, some security conside= rations for that distribution are probably in order, starting with a warning that she who ha= s the symmetric key can decrypt, making control of that key vital to confidentiality of the= need-to-know information. Is there a straightforward way to optionally handle key distr= ibution in the IODEF/RID document (e.g., an XML section that contains the symmetric key en= crypted with each of the intended recipients' public keys)? The "Characteristics of an Attack" material might be usefully recast as gui= dance for use of RID, which could be an appendix. Something to keep in mind when editing the next version is that this versio= n has a mix of IETF requirements key words (MUST/SHOULD/MAY) and non-IETF requirements = key works (shall/should/may) - picking one set would probably be better, and if ITU r= equires use of the latter, an explanation that maps them to their IETF counterparts wou= ld be good. Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of k= athleen.moriarty@emc.com > Sent: Friday, August 19, 2011 12:38 PM > To: MILE@ietf.org > Subject: [mile] RFC6045-bis, update per ITU comments and list discussions > > Hello, > > The attached is an updated version of RFC6045 (RFC6045-bis) which is up f= or determination in the ITU-T > in two weeks. As a result, of the ITU-T determination, the document need= s to move to standards track > and a -bis version is required. The ITU has requested text changes since= the document will be > translated into a number of other languages, those changes are reflected = in this version. Additional > textual changes may be made over the next two weeks through their review = process. > > A few changes to RID have been made per comments on this list and I would= like to get opinions on how > they are addressed in the attached, specifically on the changes outlined = below: > > "LawEnforcement" was added as a RIDPolicy option in text and in schema. = This was added as a result of > some on and off-list discussions as the option is relevant today for Law = enforcement that already > accepts incidents in an IODEF format. IODEF is required in Japan when se= nding incidents to law > enforcement. > > Through Dr. Katherine Goodier and Gaus (Damir Rajnovic) work on the priva= cy and data marking > extension, they determined stricter guidance was needed for encryption op= tions. Guidance has been > added to the Security section for X ML encryption using the already defin= ed IODEF:restriction > attribute. The text is as follows for ease of review: > > ________ > Security, XML encryption section: > o The iodef:restriction attribute sets expectations for the privacy > of an incident and is defined in section 3.2 of RFC5070. The > restriction attribute can be set in any of the RID classes to > define restrictions for the complete exchange of an IODEF document > (including any extensions) or within specific classes of IODEF or > IODEF extensions where more limited restrictions are desired. The > restriction attribute is contained in each of the RID classes and > MUST be used in accordance with privacy expectations for either > sections of the IODEF document or the complete IODEF document. > Consortiums and organizations should consider this guidance when > creating exchange policies. > o Expectations based on restriction setting: > * If restriction is set to "private", the class or document MUST > be encrypted for the recipient using XML encryption and the > public key of the recipient. > * If restriction is set to "need-to-know", the class or document > MUST be encrypted to ensure only those with need-to-know access > can decrypt the data. The document can either be encrypted for > each individual for which access is intended or a single group > key may be used. A group key in this instance refers to a > single key (symmetric) that is used to encrypt the block of > data. The users with need-to-know access privileges may be > given access to the shared key by distributing or providing > access to it encrypted with each of their public keys. > * If restriction is set to "public", the class or document MUST > be sent in clear text. This setting can be critical if certain > sections of a document or an entire document are to be shared > without restrictions. This provides flexibility within an > incident to share out certain information freely where > appropriate. > * If restriction is set to "default", The information can be > shared according to an information disclosure policy pre- > arranged by the communicating parties. > o Expectations based on placement of the restriction setting: > * If restriction is set within one of the RID classes, the > restriction applies to the entire IODEF document. > * If restriction is set within individual IODEF classes, the > restriction applies to the specific IODEF class and the > children of that class. > _________ > > Since incidents may not be network-centric and may still have a use case = where the information > received is not directly from the originator, the digital signature on th= e IP packet may need an > alternate option for verifying the source. I am proposing the use of Eve= ntData where each party that > adds to the event data would provide a detached digital signature. Anoth= er option (not in the > document) would be to include a default IP packet, bit I think that could= be confusing. The text is > as follows: > > ________ > Security, XML Digital Signature Section: > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. The > EventData class can be used to extend information about an > incident by each CSIRT or SP involved in the investigation. Using > this class for the digital signature when an IP Packet is not > included provides a method to verify each party contributing to > the details of the incident. > _________ > > > Sections removed: > 1.3, Attack Types and RID Messaging, > Section 2, RID Integration with Network Provider Technologies > 3 Characteristics of an Attack and subsections - should this be in an app= endix or where it was in the > document? > Section on RID Communication flow removed text as it was not relevant to = the > heading, may need to be moved to subsections if content is not addressed > already > > Some sections were re-ordered, I will go back to update section reference= s in the next version. > > > > Thank you in advance! > > Kathleen From trammell@tik.ee.ethz.ch Wed Aug 24 02:56:47 2011 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 A152F21F8AF7 for ; Wed, 24 Aug 2011 02:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 yy-U1IpmdkAr for ; Wed, 24 Aug 2011 02:56:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 07C1821F8AF6 for ; Wed, 24 Aug 2011 02:56:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8EF32D9307; Wed, 24 Aug 2011 11:57:54 +0200 (MEST) 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 u740cIakt0A4; Wed, 24 Aug 2011 11:57:54 +0200 (MEST) 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 0BD03D9305; Wed, 24 Aug 2011 11:57:53 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: Date: Wed, 24 Aug 2011 11:57:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch> References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> To: X-Mailer: Apple Mail (2.1084) Cc: MILE@ietf.org Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions 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, 24 Aug 2011 09:56:47 -0000 hi, Kathleen, A couple of points, inline. Cheers, Brian On Aug 24, 2011, at 11:30 AM, wrote: > Hello David, >=20 > Thank you for your comments. Questions for the list are indented. >=20 > I would like more opinions on a few of the questions raised. In = particular, for those that share documents with law enforcement, do we = need multiple options? This could be used in combination with the = TrafficType option of "OfficialBusiness", but does not specify if the = government entity is local, regional, national, etc. >=20 > Should we include one option of LawEnforcement as the entities = sending/receiving the RID message > would know what type of LawEnforcement agency in which the = message is being exchanged. Or do others > on the list who exchange incident information think it would be = helpful to have multiple enumerated values > to represent the types of agencies. The values for the second = option could be "LawEnforcement-local",=20 > "LawEnforcement-regional", and "LawEnforcement-national". If the = incident documents are forwarded from > one type of law enforcement agency to another, digital signatures = on the additions from each group would > provide the traceability of any new information. I'm not sure we want to get into taxonomizing law enforcement agencies.=20= The local/regional/national is almost general enough for a lot of cases, = but it does tend to project an American-style arrangement of the = agencies onto the situation. "Local" and "Regional" agencies have very = different powers even among states; the situation is less and less = recognizably layered according to the American model the further you are = from America. Kantonspolizei Z=FCrich, to take an example off the top of = my head, is a local-sized, regional-level LEO with a territory = comparable in size of that covered by the NYPD, but with one tenth the = officers, which lists national border control as one of its = competencies. Italian national-level police forces have potentially = overlapping jurisdictions WRT incident handling, so "national" might not = give you additional information. And even trying to _determine_ the = relationships among LEOs in some countries is a job for (national-level) = intelligence agencies and/or graduate-level work in international = relations. The agency will be identified in the RID message, correct? This should = provide enough information for the sender/receiver to make choices to = data handling without resorting to an incomplete taxonomy, I think... > I added the following to the description of the "LawEnforcement" = enumeration per David's suggestion: > "If the law enforcement agency resides within a different nation that = the sending entity, the "AcrossNationalBoundaries" enumeration MUST also = be set." I would generalize this to "across jurisdictional boundaries," though I = am not exactly certain how. For example, EU organizations in countries = implementing EU data protection directives are more free to exchange = data with each other than with organizations outside (and this in and of = itself is subject to exceptions, cf. "EU safe harbor" provisions, or = operational exceptions for network security information). So, data could = cross the German/Austrian border, for example, but be subject to far = less restriction than crossing the German/American border. > XML Encryption: >=20 > Thank you for pointing out the need for clarification on the new text. = The intent is the same as if the IPPacket were to be used for the = signature where only the text entered by an entity would be signed by = that entity. =20 >=20 > Would the additional sentence (2nd sentence) provide enough = clarification for this intention: >=20 > "If an Investigation request does not include an IP packet, the = EventData class instance from each the parties involved in the = investigation MUST be signed using a detached signature. The signature = MUST only be applied to the data entered or added from each entity to = provide a method of authentication on the work added by any party = involved in the investigation. The EventData class can be used to = extend information about an incident by each CSIRT or SP involved in the = investigation. Using this class for the digital signature when an IP = Packet is not included provides a method to verify each party = contributing to the details of the incident." >=20 > XML Encryption: >=20 > I will provide additional information on the use of PKI, but will do = this through pointers to existing standards like RFC5280. If there are = updates to PKI, we should build in the flexibility to leverage updates = to those specifications. RFC5280 covers path validation (verify the = chain of the certificate and status) so that one is able to verify the = CA that signed a certificate and also check a revocation list. =20 >=20 > As for key distribution, this is outside of IODEF and RID. I will be = sure to add additional text to provide references on recommendations for = these functions. The security of the key distribution process and the = levels of trust for PKI would be based on policies agreed between = entities. >=20 > The identity of entities in the IODEF document are in the contact = class. =20 >=20 > For the use of a group key, I will be sure to reference the = appropriate standards. Again in this case, policy sets the agreed upon = handling of keys between entities. There may be entities that do not = require as high a level of trust as other sets of entities or = consortiums. I will be sure to include references to = policies/agreements to set the appropriate levels of trust. >=20 > I will develop text to address the questions raised in this section = and send them to the list for review. >=20 > Thank you for the opinion on characteristics of an attack. I will add = this text back in, but will need to be careful to ensure other attack = ties like social engineering are represented in this section as the use = cases for IODEF has expanded and will continue to expand with the = addition of the proposed extensions for MILE. >=20 > Thanks for the note on SHALL versus MUST. I forgot to mention that I = will use the SHALL and other ITU-T preferred key words for the ITU-T = while formalizing the document over the next week+ in this forum. One = the text is formalized here with considerations for translating into = multiple languages, I will update the text in RFC6045-bis to match, but = will use the IETF key words, MUST, etc. >=20 >=20 > Thank you, > Kathleen > ________________________________________ > From: Black, David > Sent: Tuesday, August 23, 2011 12:41 PM > To: Moriarty, Kathleen; MILE@ietf.org > Subject: RE: RFC6045-bis, update per ITU comments and list discussions >=20 > Hi Kathleen, >=20 >> "LawEnforcement" was added as a RIDPolicy option in text and in = schema. This was added as a result of >> some on and off-list discussions as the option is relevant today for = Law enforcement that already >> accepts incidents in an IODEF format. IODEF is required in Japan = when sending incidents to law >> enforcement. >=20 > That seems very general in isolation, as there are a lot of law = enforcement agencies. > Is a single ENUM value sufficient, or is it useful to distinguish = regional, national > and/or other law enforcement bodies? >=20 > At a minimum, it would be useful to include a reminder that use of = "LawEnforcement" does > not remove the requirement to additionally use = "AcrossNationalBoundaries" when the later > also applies. >=20 > -- XML Digital Signature >=20 > This text is not clear to me: >=20 >> o If an Investigation request does not include an IP packet, the >> EventData class instance from each the parties involved in the >> investigation MUST be signed using a detached signature. >=20 > Is that one signature covering all the EventData from every party = involved, or is each > party supposed to supply a signature for the EventData contributed by = that party? I > suspect the latter was intended (e.g., as I have no idea why Alice = should be signing > event data from Bob that she can't independently verify), so some = rephrasing is > probably in order. >=20 > -- XML Encryption >=20 > I'm somewhat concerned that the new XML Encryption text is requiring = use of keys without > saying anything about key distribution or management. While mandating = specific key > distribution and/or management protocols would be overly restrictive, = it would be good > to provide some guidance on what needs to be done for some level of = assurance that the > encryption is done with the correct key and the intended recipient(s) = (but not other > parties) will be able to decrypt the result. For example: >=20 > (1) "private" uses a public key of the recipient. How does the sender = verify the binding > of the public key to the recipient's identity? A discussion of how to = use a certificate to > do that (e.g., where's the recipient's identity in the RID/IODEF XML, = how is it supposed to > match which field in the certificate) with a suitable PKIX RFC = reference would be helpful. > A reminder to check for revocation (e.g., of the certificate) before = using a public key > would also be good. >=20 > (2) "need-to-know" allows use of a group-shared symmetric encryption = key that is somehow > distributed to the recipients. That's potentially dangerous if not = carefully controlled, > and as this is the "Security Considerations" section, some security = considerations for that > distribution are probably in order, starting with a warning that she = who has the symmetric > key can decrypt, making control of that key vital to confidentiality = of the need-to-know > information. Is there a straightforward way to optionally handle key = distribution in the > IODEF/RID document (e.g., an XML section that contains the symmetric = key encrypted with > each of the intended recipients' public keys)? >=20 > The "Characteristics of an Attack" material might be usefully recast = as guidance for use > of RID, which could be an appendix. >=20 > Something to keep in mind when editing the next version is that this = version has a mix > of IETF requirements key words (MUST/SHOULD/MAY) and non-IETF = requirements key works > (shall/should/may) - picking one set would probably be better, and if = ITU requires use > of the latter, an explanation that maps them to their IETF = counterparts would be good. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of kathleen.moriarty@emc.com >> Sent: Friday, August 19, 2011 12:38 PM >> To: MILE@ietf.org >> Subject: [mile] RFC6045-bis, update per ITU comments and list = discussions >>=20 >> Hello, >>=20 >> The attached is an updated version of RFC6045 (RFC6045-bis) which is = up for determination in the ITU-T >> in two weeks. As a result, of the ITU-T determination, the document = needs to move to standards track >> and a -bis version is required. The ITU has requested text changes = since the document will be >> translated into a number of other languages, those changes are = reflected in this version. Additional >> textual changes may be made over the next two weeks through their = review process. >>=20 >> A few changes to RID have been made per comments on this list and I = would like to get opinions on how >> they are addressed in the attached, specifically on the changes = outlined below: >>=20 >> "LawEnforcement" was added as a RIDPolicy option in text and in = schema. This was added as a result of >> some on and off-list discussions as the option is relevant today for = Law enforcement that already >> accepts incidents in an IODEF format. IODEF is required in Japan = when sending incidents to law >> enforcement. >>=20 >> Through Dr. Katherine Goodier and Gaus (Damir Rajnovic) work on the = privacy and data marking >> extension, they determined stricter guidance was needed for = encryption options. Guidance has been >> added to the Security section for X ML encryption using the already = defined IODEF:restriction >> attribute. The text is as follows for ease of review: >>=20 >> ________ >> Security, XML encryption section: >> o The iodef:restriction attribute sets expectations for the privacy >> of an incident and is defined in section 3.2 of RFC5070. The >> restriction attribute can be set in any of the RID classes to >> define restrictions for the complete exchange of an IODEF = document >> (including any extensions) or within specific classes of IODEF = or >> IODEF extensions where more limited restrictions are desired. = The >> restriction attribute is contained in each of the RID classes = and >> MUST be used in accordance with privacy expectations for either >> sections of the IODEF document or the complete IODEF document. >> Consortiums and organizations should consider this guidance when >> creating exchange policies. >> o Expectations based on restriction setting: >> * If restriction is set to "private", the class or document = MUST >> be encrypted for the recipient using XML encryption and the >> public key of the recipient. >> * If restriction is set to "need-to-know", the class or = document >> MUST be encrypted to ensure only those with need-to-know = access >> can decrypt the data. The document can either be encrypted = for >> each individual for which access is intended or a single = group >> key may be used. A group key in this instance refers to a >> single key (symmetric) that is used to encrypt the block of >> data. The users with need-to-know access privileges may be >> given access to the shared key by distributing or providing >> access to it encrypted with each of their public keys. >> * If restriction is set to "public", the class or document MUST >> be sent in clear text. This setting can be critical if = certain >> sections of a document or an entire document are to be shared >> without restrictions. This provides flexibility within an >> incident to share out certain information freely where >> appropriate. >> * If restriction is set to "default", The information can be >> shared according to an information disclosure policy pre- >> arranged by the communicating parties. >> o Expectations based on placement of the restriction setting: >> * If restriction is set within one of the RID classes, the >> restriction applies to the entire IODEF document. >> * If restriction is set within individual IODEF classes, the >> restriction applies to the specific IODEF class and the >> children of that class. >> _________ >>=20 >> Since incidents may not be network-centric and may still have a use = case where the information >> received is not directly from the originator, the digital signature = on the IP packet may need an >> alternate option for verifying the source. I am proposing the use of = EventData where each party that >> adds to the event data would provide a detached digital signature. = Another option (not in the >> document) would be to include a default IP packet, bit I think that = could be confusing. The text is >> as follows: >>=20 >> ________ >> Security, XML Digital Signature Section: >> o If an Investigation request does not include an IP packet, the >> EventData class instance from each the parties involved in the >> investigation MUST be signed using a detached signature. The >> EventData class can be used to extend information about an >> incident by each CSIRT or SP involved in the investigation. = Using >> this class for the digital signature when an IP Packet is not >> included provides a method to verify each party contributing to >> the details of the incident. >> _________ >>=20 >>=20 >> Sections removed: >> 1.3, Attack Types and RID Messaging, >> Section 2, RID Integration with Network Provider Technologies >> 3 Characteristics of an Attack and subsections - should this be in an = appendix or where it was in the >> document? >> Section on RID Communication flow removed text as it was not relevant = to the >> heading, may need to be moved to subsections if content is not = addressed >> already >>=20 >> Some sections were re-ordered, I will go back to update section = references in the next version. >>=20 >>=20 >>=20 >> Thank you in advance! >>=20 >> Kathleen > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From tony@yaanatech.com Wed Aug 24 03:08:42 2011 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 4631D21F8A6F for ; Wed, 24 Aug 2011 03:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DC_GIF_UNO_LARGO=2.275, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 e8ooWe0I9Jx9 for ; Wed, 24 Aug 2011 03:08:41 -0700 (PDT) Received: from webmail.yaanatech.com (server1.yaanatech.com [66.135.59.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA1721F851A for ; Wed, 24 Aug 2011 03:08:41 -0700 (PDT) Received: from [156.106.244.49] (unknown [156.106.244.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by webmail.yaanatech.com (Postfix) with ESMTP id 3680C1C78016; Wed, 24 Aug 2011 03:09:50 -0700 (PDT) Message-ID: <4E54CDEC.9070003@yaanatech.com> Date: Wed, 24 Aug 2011 12:09:48 +0200 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: Brian Trammell References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch> In-Reply-To: <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------050900090504030905020007" Cc: MILE@ietf.org Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussions X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tony@yaanatech.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 10:08:42 -0000 This is a multi-part message in MIME format. --------------050900090504030905020007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'd suggest that anything related to this subject be kept as generic as possible. The capabilities being supported are subject concurrently to many different legal requirements that are global, regional, national, sub-national, and local in nature. The authorities involved consist of a great many kinds of government agencies, including officers of a court in the case of eDiscovery and other kinds of civil proceedings. The ETSI global eWarrant standards work ultimately allowed for multiple generic terms for its interface, as depicted in the diagram below. You should consider the possibility of using only "authority." On 8/24/2011 11:57 AM, Brian Trammell wrote: > I would generalize this to "across jurisdictional boundaries," though I am not exactly certain how. For example, EU organizations in countries implementing EU data protection directives are more free to exchange data with each other than with organizations outside (and this in and of itself is subject to exceptions, cf. "EU safe harbor" provisions, or operational exceptions for network security information). So, data could cross the German/Austrian border, for example, but be subject to far less restriction than crossing the German/American border. --------------050900090504030905020007 Content-Type: multipart/related; boundary="------------050600090301070309060906" --------------050600090301070309060906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'd suggest that anything related to this subject be
kept as generic as possible.  The capabilities being
supported are subject concurrently to many different
legal requirements that are global, regional, national,
sub-national, and local in nature.  The authorities involved
consist of a great many kinds of government agencies,
including officers of a court in the case of eDiscovery and
other kinds of civil proceedings.

The ETSI global eWarrant standards work ultimately
allowed for multiple generic terms for its interface,
as depicted in the diagram below.  You should consider
the possibility of using only "authority."




 

On 8/24/2011 11:57 AM, Brian Trammell wrote: 
I would generalize this to "across jurisdictional boundaries," though I am not exactly certain how. For example, EU organizations in countries implementing EU data protection directives are more free to exchange data with each other than with organizations outside (and this in and of itself is subject to exceptions, cf. "EU safe harbor" provisions, or operational exceptions for network security information). So, data could cross the German/Austrian border, for example, but be subject to far less restriction than crossing the German/American border.

--------------050600090301070309060906 Content-Type: image/gif; name="clip_image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="clip_image002.gif" R0lGODlh7QGdAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAA AgDtAZMBhwAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2Zm ZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/ Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lm ZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/ Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xm ZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/ Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9m Zv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M/// Zv//mf//zP///wECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mix o8ePIEOKHEmypMmTBLGpXMmypcuXMGPKnEmzps2bOHPq3EkTpc+fQIMKJcmzqNGjSJMqXWpz qNOnUKNKZUq1qtWrWHdK3cq1q1eNWcOKHUvW6NezaNOqBVC2rdu3bdfKnUvXJ9y7ePMircu3 r9+MblsJ0ku48M2/iBMrTiizFQsWAQS1SvrYsOXLLhdr3vw3pqAAVwQJYnEl6RUWmFNf5sy6 tdqYkVlOVtmq9srZ2HDDPE3bpW3VwMW6Hk586ssrAV46hsxiMLbRnwOgjnkaufTZyx/rDs59 afHv4H/u/57eUvJk7diQs6hNmrr03JUdl27Fu7t9peHzgw8QQCB///0B8J+AAQ5oYIEDwdSe TJ+phNxK9R1HXoMNTvbZdvdlmJN+HLrG34cghijiiCMmKKFyo6k3WYQRuhRhK8mpx1xyGtao U4c4bvbfgQD2SKCPPJroIo0tISfZhc+R12KREyZ3YW0Y2iilTDlWmdiAIcEEY2krDRZbeuuB CSF5LjbnoJMBRDnlmjBZ6aZfWH7kmXRXIFeakdadOaZ7pBmp0mOh1cnmoC+9aShdcXrUWJ1m 5naaaJI955yjnol2mm6Mhkbopisd6ulaiXLE6aiqfWrqWR+CROqqlp3qKlepyv/J6qx5vWqr VKECRuuub93qq1O5YsTrsGX9aixQsYpK7LJZHessSsFaxOy0Vj1rLUnRVkSdIIFy662a1FJ7 7bghZTuRls1Bqu51Y4E7lmhFuashufR6ZG5EWnI5pL678bsTekchWRNuoPEk321r1quwRskK +xK3Cr4nU8FG/XYUf/7C9CU2C+4UqZhTLizyRfc+lO9uFMdUmUrm3SYYwr3FnBttk9JmW5Qp hilzbynaFtvLsgFdHsL0pTnZdvLqNfLSE5XsEEwQvwRZxi0t+Bh6owGa25cwrjhddfwp+RjG Upe2cceROfbhYICSzfLVaf55WmxmWgda1yttXCrTfD//5DRDJx+XsoKlITlbe9jF/VzcC9q5 eOFhXvpS3BEuePDlHBf82WCfzfdg5pFezttkFI+WdK19p77Q3wtBTXXmZE4+n94Ab+0c3vVV fud0MD48ncBoc3m2vrG9SDe/X7JI48rBqe48Qg1rq9zrjsu08meNZpf3bEharS9vmy8ndWSh fdkx4o1iw3V7HavPNr+NkwejlzXv/fz9A7HO2MOvTz1Tx0WbVNZsRxvKfY087ckaaTAEo6td TW55c87wIsgx+cWGds5pEWkE1jz8efBHF9GSdEbInLG9biWIo2CX4pY8xnGpY7xZ4MzKhJvN VZBlBTvYn27XHsktDoK0aRyR/xbHvA5+EH/6M4h7SCQx2ECOWy6szplOAxmv/QmBs3Pgdgan vizO7YV34xjxnAMoP7mPJV/C3qSqaJ8jejCJBYmJYLpFR3nBSzAydJSgaNYcwVjIOfBi2fss VMT0uCRqjjnSpOq0IuwEMj2MpFnNHlknfdXOiG50HhxTsqaUFZI77cNkJlW3SYGwiYpUrF9w 8NbGUT6vlGxh0xxVyR2hdceV9ytluHaZFFzmMkAS4aUwi+LLVwITX8NMJk6KacxzKfOZPWEm KZO4LTp+C5rTkqYmj/k036lrXTpbpV6ucDotGUab0wzm9FB2QtnojSw2RMpjaOmb24QSJ1xD HTr5Rv9N/kUsdhEbYlnomRO1tVOFZzTYbJYUl332TX+B2xdNoJM+R7qMZbqxEHaEhjSi0awl tTkS1JpDJCgRbX5kLBzSWtYbk2Jng7mxWDnN4tCHcrN1/hzfQcUEQ9KM7WigMaGDhKrA2DSo gLWJ25Z++raxhZMlfdwYxeYHo7C9T6hnYs7h5kY6toWNnIqbX1hqalOIRLRIXJwc54jkOPGp zUKUC+OWcEjA9KAJrqgpGnzmkz7ZhOl8Y1SJ0eATNyQBL0zSGUxX5Xa0BR21WWTl5033d8j+ NRFqNBIryBaXVNz0sEloLM3KfqZUxR1VcWkF2WPTR9pJTfV4t2GhvhI51D3/iVE4kZVsN31D vdSyBE+dq20B4ePa3dlWsIW7a5IImbihBnByG4SMYtEmwZcGFoAXrJnisJtUgnont0xzmutw c7TMHVQ6PmVjhE7rWePqCYWz4xbvSss9F87zYXQijcSoW9eEipW7HJuUZtsX3bGAN7wlE+GM FuxbHJK3YI/Sk/i2ZkUc3m670nXwcocrVjW1CHe/+9L6iLcitiJWu2Qk09y8+90Diyx6CFki iQAK1dhVRkZsbKB+X0imqVVvcWGlr4ZL+M6E5i25cCMju7j2s6llWLN1xR6XqjpTmrr4xZNV ohwtBanQfGw3SNvdHF8qmorWj1vklM0j/ZibLz+x/82Ko9l2Pobm5ziSS5S8s5t1M8lwfvIq V17avdzCUFaO5XOc1VCRAR1oLGdZSGQp9KKvYlCtZQg5VbZyoxUGY06WxZZdCgykMq0Xi+F2 0wvLFjZXXShUp/rRsWS1rLHhaixTdtarrvWrb41raOqa04+upre6Repe3+fXwI4x/47kR8mw qzExNWmkVenSxirndJryTbHth2xy5eqsv21wBUk46YFVuYgNJLdg4oxCGrvknem+50xYDJdu JzuOOXUJcxqTVHKaOifyVhm/oERVKAl0Z3KEd9qwdxNDn9Pe9AoVuCEkbvgiTDQWchl2/J2k 9dTwkRjVIUg3Zjr6ZNRmhv+UpJGReqajcevk5tkc54ZWb4h7O1Gui9hOu1hArmoWb50zE2QS e0VL69h/vonzUjN82wre9+gKry8ex5bBq4E1bBPerFtsHnFuTnyKNUFbOE3LwtsBsem0RY8U ky5AiX1OiDeLjxlje7i81heHaaawhkW+da6PC+f5rtplBV5AATP5PE8NnsHNtkaqQbl3dG06 gAVbPx0/m2ZxdSfBFMvuhvrdWg37ul13KnJ2k/1odtpq3hxopjjLG8qmizz69MVBhTPSs3CL PMv19GeyfP7vWBovwW2D9Jm81vAXJu/K+OvOxitH6WQH4uRXrvcaw7XCu+dsX/v+e9ADU8Hk ntH/ztGmG/MpVfZYlA3PH/d8AeoM8t6zJ56jXrX5657yaISMPrv/rAHJeETu1hLHF25UZDR9 0kJm0kCMAlQO5Hgkd3qSxy/YQ3Ujtx12wlV2JXg6E1x4wX/X4n9b1mwiWBNfRm3+ZhuWwmeP lIK3ERohhSLkVYIoF1PlAS9fBiEPY4MfpWa0V24G5oHeF2vGlheIdhdA6H07N4RhUXGndoTG EjZKWGqE4YT913lRuEtU6CxQeIXDlIVaWGSm1BJhyBJj2ClCqBJliIZnSGtrmIZsmBltGIdw OIdiKId1SIdkaId5iIdmyIdq6IVfCIiCmDqwNIiGeCqFeIiK+CadtoiO/+grjfiIkvgqiTiJ llgclXiJmsgakbiJntghmfiJ+KOGpPiGphiGqBhLqViKq3iKqviKrAiLrhiLtDiLttiKChGK oug8XHgjuQhruyhNvbghqwOMwehLw7hMxWiMxzhKyXgYDKGLzSgyz9gU0ciM03hE1VgTDdGJ 2ehG2xhN1/iN2kQTPbUTPoQUjxUvl9dixUiOwvg/RDJ4NoFpSmGPxzF+T+WO7wiPyPg/CMRW H+NHeecgReNyeUdngBRIBElXUBJIasQyCSkYUKQ4XnYbUdNmSQgR0uiPzkITRiIa72F554Fe OWSSybEcfrJfqFGAXiVDFzKB72EdbKNfL1knZP9DJ0ZlkvChX0nDkR3pkb9ijiGCGhjXPcuT HGxURUf1IJjWNTZ0Y3HWIH5ij5qTeWx0QyZHVXK3blckjg4RlEJ5K+bocW6VZDd0Q9eTJmvZ VeCDXlWEj3a1btenPi0Jl+uBaCNZgGbDLzgWgGboN9g4liNTliiklCeWlg+CHtrxOU2pNTbk gkVIlXFFOskVUqLFO1K5WNdzkBQJlt0oloR5KkS5enY1GgXDkluDkymZWKXDH+3mOPpHcXSZ aNK1HFE5j0YJGo7TOU8JGvFEJREhmqP5KSApQPNhOmkWNYiULmlGH0+VbQ6yR/QhG4WznNjp OY2CcRL5NpAike+XjsL/CZTFOYrhOJ7l6VDniZ7piU7rGRPtWVPv2SbxuU/z2Wr1WY6X8ViX so5dso+FEZ9BMqAFUqBAYqAgRKAHuqAJiqAK2qAM+qASiqCQVhgC8yAcdCZWOIUEwUQe+qEg GqIiOqIkWqImSiKIMUJh8yFDp6Iu2qIwyqIyuqI0+qIzaqM1GqM5eqM6iqM+2qNAeqOAZxn8 mSYZqh4bqjQdOmxMak1O2qRQ+qRSGqVUOqVWWqVYeqVaOmyQ8Rf8UV5gOjNhOqZiWqZkeqZm mqZouqZq2qZs+qZuOjPIgW9ECpyoWZsuk6EP5x+AeZ8qM5hdAZt+mhNz6mmGER0s6pXlZWGp /9GhfTqoQ4IYjwqp4Uanh/ozGJom1jF/2wZZAzGplPongBqooVqPXrefFmmkRhpJc9moBAGq oVqofUGPpSo4lmqhqYqnLKGnAZo/sEqpXQonB1erkWqohVGdglQbjneDeyogvwqpstoXzzqo 0bqG91kQ0+qnwQonxDoT1Vqq2NqtMlGtiJKt9/mtoeqo4vqnXjqs62pXt+qn6vquxeoX5jqf 6Eqp4Uqvgpei/IpW8Xqtr/qvlQon9/qe6CqLtFaKC2uKDTuGChuxDCuxDkuxEDuxGFuxGWsQ tPqu28oXgkqw8OpGHbuu5EoXB7ueJ5sWo8oVKXueHwuyInsmdUGcJP/xsuG4sqCCs9uos19h syJRsuIas4jiribbspzGs9Xos2qhtM/ItF6BtFLhtMlItIgysyM7F0ArElQ7jFCLKl3bi1+7 FVIbFULbrVYrFyFLsGMraGHLhW3rFW97hXFrtpKKtWmrtlhbt0+xtSExt1HIt7gCuEoouEPh tx9xtsSat2qxtv9quBFHuEMIuVAhucZGuUFRtpWLt5rbt3vbuT+BuB9hub2GuYdLurhmuj4B uqfLue36uZmkuLWqukKBurNGu9BytzPLuI0Lu0WruyKLu6Fru7ImvCXBukIhu6XKu2jhuPxq vL+ivLGKvEFBvKz2tfuZhL3SENa7aszbvL7/i1OG8aXcphDdi03QexLSS6lQixkZiRndeL7Q 9L0/a7Ti2r69GL/hK637y2t6AXKrwb2u66X9q2wuUh3aixTk6ygZVJDbyxDy+0zpaxLrC63G CBsgMrcS+D0jyR/0hhX6u7vUG7r22634Kzst9xx7pMIX+ZxT1kdtJkNbuC9Jhakb6EPyxT2s imYQg0feFcLBO8I/EcHKhL1S0yf6R1G7iZN9mYGbI5U9c5uCNCbkBEXOVj7rxiiLk8PyUUUN xHCPUm4OQcTJRL8/W8AHoTFDNx1OpqnLw3g/RCeLCZwlhkapOmyR4Zt3w5twdXuQ9KWPaZdz A58CPLMTfLxkPEwn/wxS7PNXzjlhqTkYmDZPkYSau7mr39Mc2pHHeYydGZY1qupseiVGW+It hLw6iSxMZhyoJUysiyyAwrMeF9KfbtyXalNB0AlJXhmcaGWXVGWkHifLdyPMWGwkKPUew3xC QMy2QuwTqcxLXyudFkdAKjJUvZlfQxUm2TFdG7hIqME+hJSA6qGd6ONTnJNePdlOYzzA3GrI wPghSeMuvaccGFxsM9VHzCMv6+zOXvrMu6SzIfLB1pPAlSIWMqKMqMzOINvKs5tlIiLQq5Jp y/y4zYwS/hwu5EoiEB0W7xvAEKzQMsvPBOKhoROncHrSZlpVimXSLI3SbLrPQdzPsHuiNP9d 0zZ90zgNInwK0kWLFd8EakrxmY0BwOOU00Z91Eid1Dv9aU5F0DOhQ3kEHIdcEm9bVQ9NFdEx bxUcFoWa1F791WD9oQKBuojKokvBcOrjg4SxyqRqFVXlU3aD1SvsOk6dFV0dohHqoHqd1wsa KxPK1xAa2H8NQp9aFlpVw3WNX2HCUlJd0RRc1Qu8NXrzbzbDQB2FcOQFMzQIUtiBFdXKRLiS oqjLdEkiYJVUQ9fpwGi2br9zO/5WJzUzS2NGFmxNtgy9E1QWW6bVospn1m8Dz01VQZkMOXkl XWvsWV81z0dxsiUyMltdFEPHqroN3Gk9NguMmis6HR5sV9YtVzr/utFGMdU3S2kYAylDB1S8 Sb5vbR15hTHWgVdAVkCFJTEfwppgpMkzTBUZXaDemLt/gbpqw6IXtnD79aVq0953Ex3aPd93 897czR6RHRa1TbbkLSKNUj1gLDGJ9FzcHd+ZA98dblBZBWSH89w14bMhYraObRLEOzdrE9+k c0Gv2d4bSN/FE7Lku92CpdZLId5BC9npfVnMUUkzmVZDjpO7+TXvgXRoreMMh9ZEdBVQK7qY 2L149B5l/eJM9+RN1ORxNWU5HmcRnhUTruIVTkhTxWAxxEUHTkK7mVmJNZshnpXq0eE49LY+ biomrhMNVEOwGR1H6TNpdJVNsuCS3ETb/63jaQ3eRZHnf3vmOEQxxbdQGi4opF1fAVl8Xg5I HZyqeL7i5QK8YVFVU1bnfT7FoHPnkl3iC97H8l2SaebgY1HmZgvpojrfQneVnXwdaiTiWR3p G2PqWclwB86an16zoD7ekRY21u05+bVkg87GGOPb213nO75WLsrj95jsP27rkq3kIELpIJJB GQziO04mm67qhKWTx44oot0W2E0nLZioV8Q952NVy7fYljPszHGntM3t5XLb6HiD9DGQlVSD MNyCKyzUtOHAQp2Rn3k0LwPl+g3wn7LnBmNnOANSHB80MpPZmR1yeZOkVeHoIHHReYGbYGcV Jr8RFn/yyUSTRf8j8PL08okra2s8dIxuqsgu6rsU4NR9aDbfERg/K9AJKJ0KkkPPiCgvatxp 2Evv8jRPLUnP8yTb9MzS8h6B9cui9RkR9RvB9cRC61Ax9dQK9hVB5R0h9sPi9S7P9rzi9haB 9mH5aEUPs3RPMmZfFQVvTaeDG9Jc9Vyd962R4gVx90hBRayXhNZ1UcEh9xpBxi0aIifO6QLJ HZCf9ixr+IWtFzM2UQjIqMFB9p5b1BtEbPL4wpFSfKqR+U1D+NADIJwPAJJ/N360qBgsQCO/ 82Xh+nNf+6/zGzI1NRtFWM+ZUYJf86lSIswvIiMd1tAf/TtS+/QkKPJF7vJe8HZFJ6b/3PCJ zRSkf7h7X/GW5eKMk6h9DqO/niTjvxRWLf3wH/837axrTccide7hnjlQ2DlAT1Kp2v4AgU3g QIIFDRq8EgDAQoYNHT6EGFHiRIoNWRzEmFHjxoEsAgRgETKkIIEeA1wR9PFiQpBXsKVcqdKl R5LYErrkmFMnRo8AWglqFRSo0KA/iw41SlRp0qJNnT6FKjRkVKpVrRZdGDRrq61df34E6/Di TrJkTYL9WNMji6BrsbX6eKXVS5BvPcrFdrdkgJpl/W7sWVHwYMKEA/xFnJElWr57x8Kcq5cu 27wnBcIUmDbx5oIJAXAGXbZuaNIYGYstnXgtiysi52KLe9ky/+zGdHFqnvwW5OvUfj0XBh4c +OjeZdc+3VsTc2Xlo2kKhBsg6MfifxPyrt77Z9/soKMrdEi8O0fJBp/nZi4w4djz0b+OHZ8z sHD69SFSj8/xJs/acClLhqwynARMacD8NEroQAUXzEki8Rgk6DyDcCsws9oqpK2vuzzCDkKC frMvxBDh87Cj2cy70LkU2attso86LNEmhWL8q5UrDKRxo4lIjDE23l47b7kgVezLvwdpnE9E JYM7LEcZWWvtRrwk8y+y3d6zkgWg7ALLyYE840ipHKscaMu3gvISmx29PGut3TKUjcWTvsLJ JLxasTNNGZfks7AjPTyLMSubazKlF/+XM1Q69XDzMkHy0MKRwe0Gcu/JNB3ksUSRNg2pJMpe Yg06lUDFyVD4WIIxxiT7ZDUi/MYEShBZt5tr1jLRDAqlWl/7SVdRFU3T0Y3mtFFRoSj96Vbu XuK1qVt5Gwoj/2bq9LIfzXwLW6MIIqkvbHV0NdMS5yL3LUoL6vBHdD/8M0YQW4X3IXH1LK2t dksEEzC2im0rJJdg6nS9qVwkSWDp8AxJ0dYGtnHAaW3sVBDWGluP4om7BakxgBUVKdKD1qQ3 O0FYWjbHVeNFucmQi1ssVXdnBAwsLWXk97qhUrLLJY0Puw42WefEWK7G/KP0JLluvAikkQ9T esvdtpR1Ydj//pUuoZ9dJgjklVPDc1R630U53nu3TmzhknMUVqOpnPN3X5ZccnRtcvnCGS64 jwMYpWyL5Ku1kdna1KWuNTapYC07tQyuYv09uyBMydZO1pVPDpvVVyHHHLS0M0rcsgRHzlXG q/PSGWObKOMrqZNSiixVxa1O0LKRbcr1sKGuawxxqostCeuBHs88+M3ArrzVeYVHfqN81X4s 9YSpFmmygWGi+DC7ER54NXJvLPrq1gh+UsvFPc/4Iv84zKs8jbROvv1Hiw9bZffnx2j5jLDD NVno9Md52SJxfdativapl5ypXJchyLago61uvWRWwPrW+iRyPPrNj3jwW9LYKti+/82VpoPe iWB1KuYxjgBvgyesDAbhdTkU0u+DpPGd8BToFxO20IXgUSGrKGjDzNkveA0THvt42D7K5TBE 8hti8nyYObsFcYJJtCAOjagkDUJxZS+E3KQyN5EqWpFeRZyicFjoRcxdMIxnnGIXydgoKaKx PjtcY7Da6EbD0HFEcQweGO0oGCTi8Ypz3CMXARlIwcDRjzQyIyG5aMhD4muQioTkERnZSAjp MZLh6SMl2XhJTlJxkppUUCI7aRFQhkyUnHzkKBnyyVLGx5KqzGQrHanKh3yElkKU5ctuGa5c bnKXv1xkL530yk6OUZgMOiUwb6nGY4owlbRkZTM9+MxLUv9zlNGUZmiIWcxseiiZkLSlMknZ TWRaE5XYJGfZzCnOc6ZzQdusZizdybJ1sjOSzJzn8OoZSXTmkyzfBKc9F9JPf+oEntUs6HgA Sshw2pOgCVXePhWJT4j+U6IC3SNFK2rQiwbSmBvlzEIxytCHghQhHQ1kSU3KLnGidI8qXele MCrPmJZFpBl1qR1hGtObTnSnK+3pSOmo0Zoe5KDgpGlRdRJUoaKRqEplqUB/alKmujGndJwq SI8KTqjqs6nAzOpGq2rHp3Z1T19dZlgrulWGJtWsirkqWuFX1q6OVadvtU5c5Vo8tUKUrQzF q2/0utew9TWhdrWqYQuKWMLGT7H//vwrTgNr08E2tlV0hSpj0fjYfGrWsvDi7Dwjm9HJWvSz nAytOz2bxtSmc7WnzWBryTnaobq1tF+qLGw9edul5taIsu3ma3UrIuBmk7ZD5W1OhDtc+xRX msvFIGaVCl3mMsm5zTyuU23LW+pW10/XPWZ3+Zpc/fjWu8IBrzCz61TyRvS8d20vXAUq3aKK 970UoW9N1xvGj8b3rPflb3p7ad/C+rd+5gXwYAScy/3yd2QPRkmEITxhCVeYwhe2cIYxvGEN d5jDH/ZwiDnc4AR/t3wndlOKUbxiFbeYxS92cYxhPGMZ15jGL54vY3S8Yx732Mc/BnKQhTxk Ihe5xPxd/0hYwqlk8DA5ybZcMpSbLOUnKyTKVp4ylqsMgCtzOcte3nKXxfzlMW/5yGdGc5rV vGY2t9nNb15zWOA8ZzrXeZdytnOe9bxnqyKYz38GdKAbGmhCF9rQwxn0oRW96EXjmdGPhjSg Ex1pSlf6zZO2dKY1XWJMb9rTn9ato0E9alITttOlRnWqW+pnVbfa1Zdl9atlPWv7nJrWt8b1 XGOda173miG29nWwhc2kXQ/b2KoG9rGVvWwzM9vZz/ZysaE97Ucnm9rXlrW1sb3tVIua2992 tbfBPW5Ua5vc56a0uNG9bkurm93vhrS74T1vQ8ub3veWtLTxvW/Ympvf/26zv/8BPvA0C5zg B7+vvRG+cE7rm+EPv7PDIT7xYkqc4hefqMExvvGRapzjH2enx0E+cloqnOQnV6bIUb7yjFuc 5S/nk8phPnP+ypzmN9c1znVecZfv3OcOsvnPhU7Fng/d6GA+etJzaHKlN/2ITHd61IktdarD uupXJzrWtV4fqG/d60/mk0AeInaHkL0hZmcI2hei9s+oqexuPzvc0y73tdO97WO3O9v1nne+ 493vb/973AM/98HXvfB3B3ziBa94wjPe8PBWuYElzxl2y3zyl//Lum2Oec6TBd2b73zowQXu rktE9Kf/GLmD3nbUt97u2F496+8XQ7LgyfXzJH3sNWL/pJmBRmK0vz0oxx172RekQEDhnu+3 G3xK5p5VnDMQtCS3v2xt5Pf6Q1bjmL9G5/cJI6wzyPlmU6CEYY38QRJJi7bvx20XOchzP+lB 0ESXWrEtI8uJW6mWv34Uctv9QK4786Cgr6i/MjkenBGV6TgKYOE/7uO478ukn5gYRfk92bi/ T1EcmFiY/WtA+vk4CIQR8FMc+rNACCwaBYSODmS/jeMcDJwJ/euWT0HAg8CQBMETh1FBB2RB aVkN2TEa9JnBGTQIgBkS1giVHPSiD9SIqPkRXcEVM8G+8BMKvCiTBwM+JJwfJcRC/3rALeTC HfRC8tLCMOStMSTD2+rCM0TD/zRUw8kyww+5kQvTvjaUpjeEDpSYFVkBCgmRltC4wjD5i9lB jPnzQjZMIBJaDsV4qJ7hjJSYQ2TpCBIKk2opICQ0REohofXQF+/Qpi46wtNJDGjhwM6zQ/U4 MElUD/jQQ0oRxEo0oDOhvih0oFihQS1pEUJEE4nZF9I5lgQCHUikwu2hG1eERdcrRRs5sB2q lk2pP6mZmoHYmTgpv0VpjT/5nk/8npKYCZAIlYWZRumZjcAhHRlRiSbKDFTEvEu8w2RUnosQ QU8piP6YmdaYi/1IHxLEk1SJRnhMxZzBLZK4Qd3Qv3pskWysm3uki0ecvGPMRA2qljn5x+5J QLooQf9QnEEGLJMmgYuayMZx9EhQ1EYZiRBqGcl+nMiObL1StIlTbEdRwUb08RnomEfK6Mjv QZibPKmRsceXDMmeBEVKjEmUNEiVCUj1Qz2GLIpX1ETm4ZYT4Z2P3McZtEkjDCHYgJJqNEmP 5MmQTJvcMZAjlJgPscU/NDB1zIwaa0ne+EQSnA2rOZ16lEGeEZ9UYUSBpBnb4MeP/B5HLEGh bJ4E4sbtM0u66DFldMeTyJ6J0b/0K0CKNElu5EOE7IixgMwjXA/DicRFSRi1+EqceJhFUcjL U8lsMYpYmSFpAUgbgUI8PERnmT9cNBxhND4a/BKoqcJu+RHpo8JipL4F6gv/emS+0cwj+ADK PEJHUgRD+pEYyAzNNBnB4BzM5DlNGSJLyRNOOoyp68TOlYrO7czO5PROqFJJKdFJKdGb8CQn pDyKoojM2avOAyHEQXxP+YvPQWxO94QhGLE9sjFLZKTBKuqau5jP7sAiafkRjESMhClOwRrQ 9MmY+5QWBCXBlWFIdty9K8nHFhLC0OgZWayRzZgKfqmODdUTlZwXe4QrxZg+A/pFm4DCgtkS LeLNZGkKuYAWVgxG1awJhPEV7tDRMsmWhpS/FjWgf8GO1OSWFX0LX5kQzwyVo9hR1qy+BaqV 1qzAy1hRgFTS/KjQg1jKCD0b8Wue9NPF0TAYI3QL/5GEx/ORjGwMUIupxhgMzOfcmDrZlEzi y6ZUzLMciZq0HZURx/T5UoI4EYvxF3DcnQTcSM2cxmk5wk2B0NDoT0QcmzyNR8/0QcFBnxHM U6UhQUq0ydFAwGzsSICczMvAQGMBFrccCd04m+OQSUzdi9cQwW6kScrIRZUxyme8y/2YixQh idrIRlUFkv/AVJJozwOZVAuNUP1kwL0E1GMFSY8cwY48QmCpVsoMU4ipyGwlVGQdkLXkFr3Y SD30SkIVHApsEnEdCVlZUDcRVpURQls9R90gyKI5x+3IneIaT5a8n12FC3Z5y7xUV2h0Uszs RzzpC4UxH6P8G3u8Um+N1f+PFFfjO5iWMEKfpEhSRZ1l2RC/adJoyUohhFYUhI3GBJVfbRu9 qVhlndSoGNSDOJETPNUZPMJFtVZMhcvMPNmT1FbAxImhpFmUPFeNlVmgkNCZ3UiwXFccmVmZ jZRSlZ/Z6JuxwFn4CNiY7AznGkyZyRi02CFH3J5gxYsKAU7JLNh6tYuCUVfz6T1vfcpkqY1q AT97tduB/cSKNRPwo0QgwZGE+ZJbJRfTScEmRQisBdY42VFVVYv/IKDIOM7qUMnv2DE4op43 qdOKvFmL4dlFrYyOyYzF3VkueQ6BocQ5XVVunNtwjZQe3NG2MVaLHRCbzZg6YU7ziFoS2Ri+ Icr/1PUXjeSUyODX6CzN4q1KGtzSVexN3vSWc9kf6SuXpESg6Q3SJpRea6HeJcXF3ETeb8kV KEyX7U1SH5XS2ZRCdLEVbjnSQ1xePWyWEtFO9ISo7pTfiqLf+i2o+MVf3Lvf/c2n/vXfdNLf AO6m8ZSSq2SNSCVgKFLPp0hWZEGOUMKRqOhZ4wvN5Eug6y1E8MRECKQgBa3dUIRQlLRKr0Xa kilQg50QNyFLBS6tZfVSDRLeBs1L+YiU6QhGCd0JcV3UriGLXV3IwWzIyKXEbilbXllNqKGJ 32xF9UA+cQlIUUG+ItnRXEHiF5yQxTViJi0gXSkQufiWyO2qLj0pQ6JE/2bk1Zj8YrjhRjt1 Rkd9WmjkjjYOR/YAXTbl4f44mN8dU9YI0AhTmboUQw5exxg2Y/h4k9CVSXDd2sDNTOBEGPlz SlFtElLF1mrx3G/tlwMaweuBRl4ZmpZ9YRguYxvm2ZLQYtFRy3DVEnfFYqOVY5q1W4791lP+ FVjdn56pW1fNzOdsr36NYSJG5Dl+3ebovY5s4wTW2mlNoE/0XIntyEyu2GGMkN+dm3gUxYGN rwZ2ijTdRI39RPXrmbxtXVY2Db4BZeGt4RbJ42WBZHU9UL6RGDE2q671sUOO5ckclErMWhvU ZnMBzkQEWomc5bGIZhu01HzGrWxR1UsVy1FUqqfBpFwdM2PWBcwNEd72iI3P3dTVEOVbxFaG VY/o8+gJNko8rj/suEyXtM7uXAoN3j11GUJyoWnvxRbTVN8DOt/ndV5zKdzs8+l1CT/JkWlf JOgvJOTbI9FfTmrXE+UyBGDOo+HvbOoF5t+qtmp3Ajmy42q36+rH+2rEC+ux9uqyBmuzFmu0 JuuzZuu0buu1duu4huu5Vuu6fmu7lmu8puu75mvE47aAAAA7 --------------050600090301070309060906-- --------------050900090504030905020007-- From kathleen.moriarty@emc.com Wed Aug 24 03:23:50 2011 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 B8C1721F8B55 for ; Wed, 24 Aug 2011 03:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 fi05p0HqQ8fE for ; Wed, 24 Aug 2011 03:23:49 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3150721F8B35 for ; Wed, 24 Aug 2011 03:23:45 -0700 (PDT) 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 p7OAOrMO002579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 06:24:53 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 24 Aug 2011 06:24:43 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.221.56.108]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7OAOg5J020461; Wed, 24 Aug 2011 06:24:42 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub22.corp.emc.com ([128.221.56.108]) with mapi; Wed, 24 Aug 2011 06:24:42 -0400 From: To: , Date: Wed, 24 Aug 2011 06:24:40 -0400 Thread-Topic: [mile] RFC6045-bis, update per ITU comments and list discussions Thread-Index: AcxiRhOwpyfeTg/5RYOOSuiMzE/LkgAAKFsL Message-ID: References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com> In-Reply-To: <4E54CDEC.9070003@yaanatech.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] RFC6045-bis, update per ITU comments and list discussions 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, 24 Aug 2011 10:23:50 -0000 Thank you Brian and Tony for the comments on the use of LawEnforement. It = seems from these comments, we should use only one indicator for this field,= if others agree/disagree, please post to the list. Tony suggests the use of "Authority". Is this more appropriate than "LawEn= forcement"? Also, Brian raised another question on an enumeration that is in RFC6045 in= RIDPolicy. Should "AcrossNationalBoundaries" be changed to "AcrossJuristi= ctionalBoundaries" or some other indicator for this marker? I also agree that the contact information will be provided, so I think usin= g a more generic marker is appropriate. Is there agreement/disagreement on= this point? Next for the handling of data between countries where you get into privacy = considerations, safe harbor, etc. I believe this will be handled in the ex= tension on data markings from Dr. Katherine Goodier and Gaus Rajnovic. The= y should be able to match up any markers with guidance on how to set the IO= DEF:restriction appropriately for the various markers used so that encrypti= on can be appropriately used at the RID layer with the new guidance. Could= Katherine and/or Gaus confirm? I had a little time and wrote up text to address the PKI questions from Dav= id and will send those out a little later. Thank you! Kathleen ________________________________________ From: Tony Rutkowski [tony@yaanatech.com] Sent: Wednesday, August 24, 2011 6:09 AM To: Brian Trammell Cc: Moriarty, Kathleen; MILE@ietf.org Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussio= ns I'd suggest that anything related to this subject be kept as generic as possible. The capabilities being supported are subject concurrently to many different legal requirements that are global, regional, national, sub-national, and local in nature. The authorities involved consist of a great many kinds of government agencies, including officers of a court in the case of eDiscovery and other kinds of civil proceedings. The ETSI global eWarrant standards work ultimately allowed for multiple generic terms for its interface, as depicted in the diagram below. You should consider the possibility of using only "authority." [cid:part1.09080503.05030907@yaanatech.com] On 8/24/2011 11:57 AM, Brian Trammell wrote: I would generalize this to "across jurisdictional boundaries," though I am = not exactly certain how. For example, EU organizations in countries impleme= nting EU data protection directives are more free to exchange data with eac= h other than with organizations outside (and this in and of itself is subje= ct to exceptions, cf. "EU safe harbor" provisions, or operational exception= s for network security information). So, data could cross the German/Austri= an border, for example, but be subject to far less restriction than crossin= g the German/American border. From david.black@emc.com Wed Aug 24 06:07:21 2011 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 989DE21F8782 for ; Wed, 24 Aug 2011 06:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.311 X-Spam-Level: X-Spam-Status: No, score=-105.311 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, 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 p6jHkkKmbMNo for ; Wed, 24 Aug 2011 06:07:19 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0AA21F8772 for ; Wed, 24 Aug 2011 06:07:19 -0700 (PDT) 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 p7OD8QNV026612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 09:08:26 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 24 Aug 2011 09:08:14 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7OD8DSd029072; Wed, 24 Aug 2011 09:08:13 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Wed, 24 Aug 2011 09:08:13 -0400 From: To: , Date: Wed, 24 Aug 2011 09:08:06 -0400 Thread-Topic: [mile] draft on IODEF extension to support structured cybersecurity information Thread-Index: AcxiOgPZ2GuGQRFeRi2mjxtzZ0AnrAAJAaGw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05896729AD@MX14A.corp.emc.com> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <013601cc6235$3196b1d0$94c41570$@nict.go.jp> <510A8D02-449C-43C3-9D60-2F25C16BC277@tik.ee.ethz.ch> <018f01cc6238$e6fa0f60$b4ee2e20$@nict.go.jp> <5D14417A-40EE-4865-81B5-2D6A10EDCC85@tik.ee.ethz.ch> In-Reply-To: <5D14417A-40EE-4865-81B5-2D6A10EDCC85@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] draft on IODEF extension to support structured cybersecurity information 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, 24 Aug 2011 13:07:21 -0000 I also prefer option 1. Returning to Brian's earlier comment: > In general, I agree: representing embedded information by ENUM as opposed= to by > freeform string is much preferable. However, if the embedded information = is itself > described by an XML Schema, then it may make sense to differentiate the e= mbedded > AdditionalData content not with a new ENUM, but rather by the namespace u= sed by > that schema. You still run into the subordinate namespace versioning prob= lem, > but this is now the job of the creator of the subordinate namespace to do > correctly, which I would assume is the case for the SCAP use case. I'm ok with SpecificationName being an XML namespace reference rather than = an ENUM (both work for me), but I still think the IANA registry of allowed XML name= space references is needed, so that a recipient can prepare in advance for what m= ight be coming. This avoids having to go fetch an XML schema in the middle of inci= dent handling and allows verification in advance that the recipient's automated = tooling can handle the content. Thanks, --David > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, August 24, 2011 4:44 AM > To: Takeshi Takahashi > Cc: Black, David; mile@ietf.org > Subject: Re: [mile] draft on IODEF extension to support structured cybers= ecurity information > > Hi, Take, > > I prefer option 1 as well... > > (This would additionally appear to resolve my previous question.) > > Cheers, > > Brian > > On Aug 24, 2011, at 10:36 AM, Takeshi Takahashi wrote: > > > Hi Brian, > > > > I like the 1st option you kindly raised here. > > I appreciate your assistance. > > > > Let me update the text and come back to the list soon. > > (I will make sure all the comments I've received in this list should be > > reflected.) > > > > Best Regards, > > Take > > > > > > -----Original Message----- > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > Sent: Wednesday, August 24, 2011 10:17 AM > > To: Takeshi Takahashi > > Cc: david.black@emc.com; mile@ietf.org > > Subject: Re: [mile] draft on IODEF extension to support structured > > cybersecurity information > > > > Hi, Take, > > > > To my understanding, there are two possible answers to this last questi= on, > > each with their own disadvantages: > > > > 1. The SpecificationName and SpecificationVersion are present and requi= red, > > and MUST match any version information carried by the enclosed XML name= space > > and schema. This gives you a nice envelope for determining which versio= n of > > the extension you're using, but can lead to inconsistency if improperly > > used. It is unclear what a reader should do when an inconsistency is > > detected. In line with common practice in protocol design (send > > conservatively, accept liberally), I would suggest "writers/senders MUS= T > > ensure the SpecificationName and SpecificationVersion are consistent wi= th > > the contents; if a reader/receiver detects an inconsistency, it SHOULD > > prefer the specification and version derived from the content, and SHOU= LD > > log the inconsistency so a human can correct the problem." But it shoul= d be > > addressed in any case. > > > > 2. The SpecificationName and SpecificationVersion are only present when= that > > information is not derivable from the enclosed XML namespace and schema= . > > This is ugly, because it introduces two ways of doing the same thing... > > > > Best regards, > > > > Brian > > > > On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote: > > > >> Hi David, > >> > >> Thanks for your email. > >> > >> 1) > >>>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > >>>> possible > >> specifications. > >>>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > >>>> ENUM for dtype and FraudType description. > >>> > >>> That sounds like a good approach - each RFC that registers a value > >>> for the > >> ENUM should include a pointer to the XML Schema for that specification > >> as part of making the registration with IANA (the IANA registry entry > >> will reference the RFC for the details). This may help recipients > >> ensure that they have local copies of the XML schemas necessary to > >> parse expected content. > >> > >> Thank you for telling me the IANA issue. I appreciate that. > >> > >> 2) > >>>> So, my assumption here is that a complete CVE (compatible with its > >>>> schema) will be embedded here. > >>> > >>> I don't have a problem with that assumption, but think it should be > >>> stated > >> because that conclusion is not obvious [well, at least not to me ;-) > >> ]. It should be sufficient to state that the embedded element is a > >> complete XML document that is formatted according to the schema > >> referenced by the IANA registration of the ENUM value used for > > SpecificationName (see item 1). > >> > >> I see. I will. Thank you. > >> > >>> My concern is similar to item 1) - how does the recipient parse and > >>> check > >> the version number? > >>> The rules for this need to be precise, otherwise there may be > >>> unexpected > >> string compare results. It'd be good if the version number could be > >> extracted from the XML Schema for the embedded content (and hence > >>> take advantage of the rules in the referenced specification for the > >> syntax of [Specification]Version). > >>> > >>> A simple (silly) example of what can go wrong is that OVAL is > >>> currently at > >> version 5.10 - that's not the same as 5.1, but if it's converted to a > >> number, the result is easy to misparse it as being equivalent to 5.1 ;= -). > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if t= he > > '.' > >> causes problems in some tooling? All of these are easy for a human to > >> sort out, but potential causes of problems in automated tools. > >> > >> Yes, I agree. > >> To clarify this issue, I'll add a sentence "parsers are expected to > >> read the namespace of the embedded structured information and identify > >> specification name and data, whenever such information is available, > >> and parse the embedded data." > >> > >> Then one potential question we might have is, do we need the > >> SpecificationName and SpecificationVersion elements? > >> If the namespace described in the embedded structured information > >> identify the specification name and its version, one might think these > >> elements are useless. > >> However, in my opinion, we still need these elements since some of the > >> embedded information could be non-xml in the future. > >> > >> Thank you. > >> > >> Take > >> > >> -----Original Message----- > >> From: david.black@emc.com [mailto:david.black@emc.com] > >> Sent: Tuesday, August 16, 2011 10:15 AM > >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > >> Subject: RE: [mile] draft on IODEF extension to support structured > >> cybersecurity information > >> > >> Hi Take, > >> > >> Enjoy your vacation, here are some comments to look at when you return= : > >> > >> 1) > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > >>> possible > >> specifications. > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > >>> ENUM for dtype and FraudType description. > >> > >> That sounds like a good approach - each RFC that registers a value for > >> the ENUM should include a pointer to the XML Schema for that > >> specification as part of making the registration with IANA (the IANA > >> registry entry will reference the RFC for the details). This may help > >> recipients ensure that they have local copies of the XML schemas > >> necessary to parse expected content. > >> > >> 2) > >>> So, my assumption here is that a complete CVE (compatible with its > >>> schema) will be embedded here. > >> > >> I don't have a problem with that assumption, but think it should be > >> stated because that conclusion is not obvious [well, at least not to > >> me ;-) ]. It should be sufficient to state that the embedded element > >> is a complete XML document that is formatted according to the schema > >> referenced by the IANA registration of the ENUM value used for > > SpecificationName (see item 1). > >> > >>> 3) > >>> Maybe some text in the draft has caused mis-understanding. > >>> Yes, the latest version of the XCCDF schema is 1.6. > >>> I intended to say that the number of the version element is zero or o= ne. > >>> Most of specifications such as XCCDF etc. have versions while CVE > >>> does > >> not. > >>> Thus the number of this element class is ZERO or ONE. > >> > >> I misread what you wrote, sorry about that. I was looking for the > >> syntax of the contents of the [Specification]Version element, and > >> looked in the wrong place. > >> > >> My concern is similar to item 1) - how does the recipient parse and > >> check the version number? > >> The rules for this need to be precise, otherwise there may be > >> unexpected string compare results. It'd be good if the version number > >> could be extracted from the XML Schema for the embedded content (and > >> hence take advantage of the rules in the referenced specification for > >> the syntax of [Specification]Version). > >> > >> A simple (silly) example of what can go wrong is that OVAL is > >> currently at version 5.10 - that's not the same as 5.1, but if it's > >> converted to a number, the result is easy to misparse it as being > > equivalent to 5.1 ;-). > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if t= he > > '.' > >> causes problems in some tooling? All of these are easy for a human to > >> sort out, but potential causes of problems in automated tools. > >> > >> Thanks, > >> --David > >> > >>> -----Original Message----- > >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > >>> Sent: Sunday, August 14, 2011 9:25 AM > >>> To: Black, David; mile@ietf.org > >>> Subject: RE: [mile] draft on IODEF exstension to support structured > >>> cybersecurity information > >>> > >>> Hi David, > >>> > >>> Thank you for your kind comments. > >>> I agree, I'll change the element class name. > >>> > >>> Regarding the issues you kindly raised in the email, let me describe > >>> my understanding. > >>> > >>> 1) > >>> My assumption was, when parsing the xml data, the parser anyway reads > >>> the namespace described in the embedded xml data and parse the data. > >>> But I agree, it would be better to limit the description of > >>> SpecificationName. > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > >>> possible specifications. > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > >>> ENUM for dtype and FraudType description. > >>> Like the same way, the SpecificationName could use ENUM for > >>> describing specifications, though we do not have that much > >>> specifications to enumerate at this moment. > >>> > >>> 2) > >>> I am not sure whether it is easier for information sender and > >>> receiver to send/receive partial CVE data. > >>> Maybe it would be easier for them to embed/receive/parse a complete > >>> CVE data? > >>> If we send a partial CVE or the other structured data, receiver may > >>> suffer from some parsing problem, as you mentioned. > >>> So, my assumption here is that a complete CVE (compatible with its > >>> schema) will be embedded here. > >>> > >>> 3) > >>> Maybe some text in the draft has caused mis-understanding. > >>> Yes, the latest version of the XCCDF schema is 1.6. > >>> I intended to say that the number of the version element is zero or o= ne. > >>> Most of specifications such as XCCDF etc. have versions while CVE > >>> does > >> not. > >>> Thus the number of this element class is ZERO or ONE. > >>> > >>> Above are my viewpoint, but I might be wrong. > >>> Let me develop the draft based on your kind comments after my vacatio= n. > >>> Please correct me if I am wrong, I would like to welcome feedbacks. > >>> > >>> Thank you. > >>> > >>> Take > >>> > >>> > >>> From: david.black@emc.com [mailto:david.black@emc.com] > >>> Sent: Wednesday, August 10, 2011 8:45 AM > >>> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > >>> Cc: david.black@emc.com > >>> Subject: RE: [mile] draft on IODEF exstension to support structured > >>> cybersecurity information > >>> > >>> Hi Take, > >>> > >>> For clarity I'd suggest not using "Version" as the name of both an > >>> extension attribute and one of the classes in each extension. > >>> Renaming the class to SpecificationVersion would be clearer (so > >>> Version is the attribute with the version of the extension). > >>> > >>> I also have a few questions: > >>> > >>> (1) What strings are valid for SpecificationName? If the recipient > >>> doesn't understand the SpecificationName, the information in the > >>> extension may be unparseable, so this probably needs to be controlled= . > >>> > >>> An IANA registry may be appropriate to list the valid strings and > >>> associate each string with its corresponding specification. > >>> > >>> (2) How does one determine the format for information formatted > >>> according to an external specification? > >>> > >>> For example, I believe that the XSD schema for the CVE list defines a > >>> complete XML document, but I suspect that less than a complete XML > >>> document is intended to be embedded because the proposed extension is > >>> part of an IODEF XML document. > >>> > >>> (3) Why is the [Specification]Version limited to zero or one? > >>> > >>> For example, CAPEC is currently at Release 1.6. > >>> > >>> 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 > >>> ---------------------------------------------------- > >>> > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > >>> Of Takeshi Takahashi > >>> Sent: Monday, August 08, 2011 11:50 PM > >>> To: mile@ietf.org > >>> Subject: Re: [mile] draft on IODEF exstension to support structured > >>> cybersecurity information > >>> > >>> Thank you for those of you who kindly gave me off-line messages . > >>> > >>> Let me share the draft with some minor modifications. > >>> > >>> Sincerely, > >>> Take > >>> > >>> > >>> 2011/8/5 Takeshi Takahashi : > >>>> Dear all, > >>>> > >>>> > >>>> > >>>> The attached is the tentative version of the draft prepared based on > >>>> the comments I've received in this mailing list (Thanks a lot for th= at). > >>>> > >>>> It would be great if you could provide some comments on Clause 4, > >>>> where > >>> the > >>>> IODEF extension is defined. > >>>> > >>>> > >>>> > >>>> As you know, there are many ways to embed structured information > >>>> (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very > >> flexible. > >>>> > >>>> Thus, I would be happy to change and develop the draft further based > >>>> on > >>> your > >>>> comments. > >>>> > >>>> > >>>> > >>>> I would like to welcome any comments on that. > >>>> > >>>> > >>>> > >>>> By the way, I will be on vacation, thus my response might be slow, > >>>> sorry > >>> for > >>>> the inconvenience. > >>>> > >>>> > >>>> > >>>> Take > >>>> > >>>> > >>>> > >>>> PS: I've changed the title of the email. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2011/7/29 > >>>> > >>>>> > >>>> > >>>>> Thank you, the approach sounds good, especially since it is in use > >>>>> today > >>>> > >>>>> by at least the Research and Education ISAC. Do others have > >>>>> opinions on > >>>> > >>>>> the proposal here? > >>>> > >>>>> > >>>> > >>>>> Thanks for writing the first draft Take! > >>>> > >>>>> > >>>> > >>>>> Best regards, > >>>> > >>>>> Kathleen > >>>> > >>>>> ________________________________________ > >>>> > >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > >>>>> Takeshi > >>>> > >>>>> Takahashi [takeshi_takahashi@nict.go.jp] > >>>> > >>>>> Sent: Friday, July 29, 2011 9:20 AM > >>>> > >>>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >>>> > >>>>> Cc: mile@ietf.org > >>>> > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>> > >>>> > >>>>> Thank you, Bob, for the email. > >>>> > >>>>> I also like Tom's suggestion very much. > >>>> > >>>>> Let me work on the "draft" of the draft for a while, then come back > >>>>> to > >>> you > >>>> > >>>>> later. > >>>> > >>>>> > >>>> > >>>>> Take > >>>> > >>>>> > >>>> > >>>>> -----Original Message----- > >>>> > >>>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >>>> > >>>>> Sent: Friday, July 29, 2011 9:10 AM > >>>> > >>>>> To: Kent_Landfield@McAfee.com > >>>> > >>>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >>>> > >>>>> wes@ren-isac.net; mile@ietf.org > >>>> > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>> > >>>> > >>>>> I also like how this is evolving. > >>>> > >>>>> > >>>> > >>>>> I think, as Tom's suggestions pointed, that any and all of the > >>>>> useful > >>>> > >>>>> types > >>>> > >>>>> of information that can help with understanding, diagnosing, and > >>>>> getting > >>>> > >>>>> ahead of an incident should be added but for now we should focus on > >>>>> those > >>>> > >>>>> the most established and well articulated. > >>>> > >>>>> > >>>> > >>>>> This can be the compliance/patch/configuration/platform information > >>>> > >>>>> related > >>>> > >>>>> to the SCAP use case, or event signature/attack pattern/traffic > >>>> > >>>>> characteristics from events, or the vulnerability/threat > >>>>> characterization > >>>> > >>>>> space. > >>>> > >>>>> > >>>> > >>>>> I look forward to Taki's draft to see how he suggests positioning > >>>>> these > >>>> > >>>>> concepts. > >>>> > >>>>> > >>>> > >>>>> Bob > >>>> > >>>>> > >>>> > >>>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >>>> > >>>>>> I like where this is headed. > >>>> > >>>>>> > >>>> > >>>>>> Thanks Takeshi. I look forward to your draft. It will give us > >>> something > >>>> > >>>>> real to discuss. I appreciate you jumping in and getting this start= ed. > >>>> > >>>>>> > >>>> > >>>>>> One question that I am not clear on. What do we envision as the > >>>>>> actual > >>>> > >>>>> set > >>>> > >>>>> of deliverables? From and SCAP related perspective, are we looking > >>>>> at a > >>>> > >>>>> single draft covering all the extensions? > >>>> > >>>>>> > >>>> > >>>>>> Kent > >>>> > >>>>>> > >>>> > >>>>>> Kent Landfield > >>>> > >>>>>> Director Content Strategy, Architecture and Standards > >>>> > >>>>>> > >>>> > >>>>>> McAfee, Inc. > >>>> > >>>>>> 5000 Headquarters Dr. > >>>> > >>>>>> Plano, Texas 75024 > >>>> > >>>>>> > >>>> > >>>>>> Direct: +1.972.963.7096 > >>>> > >>>>>> Mobile: +1.817.637.8026 > >>>> > >>>>>> Web: www.mcafee.com > >>>> > >>>>>> > >>>> > >>>>>> From: Takeshi > >>>> > >>>>>> Takahashi >>>>>> ict.g > >>>> > >>>>>> o.jp>> > >>>> > >>>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 > >>>> > >>>>>> To: > >>>> > >>>>>> "Thomas.Millar@us-cert.gov" >>>>>> mas.M > >>>> > >>>>>> illar@us-cert.gov>, > >>>> > >>>>>> "wes@ren-isac.net" >>>>>> to:we > >>>> > >>>>>> s@ren-isac.net>>, > >>>> > >>>>>> "mile@ietf.org" >>>>>> etf.o > >>>> > >>>>>> rg>> > >>>> > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>>> > >>>> > >>>>>> Thank you for the email, Tom. > >>>> > >>>>>> > >>>> > >>>>>> So, here is what the draft needs to describe (if I understand Wes > >>>>>> and > >>>> > >>>>>> Tom correctly). > >>>> > >>>>>> > >>>> > >>>>>> The draft should define ext-dtype (an attribute of AdditionalData > >>>> > >>>>>> Class) to identify the information type, rather than defining new > >>>> > >>>>>> class under AdditionalData. > >>>> > >>>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, > >>>>>> ext-capec, > >>>> > >>>>>> ext-cvss, ext-cwss, In this way, we could keep the change minimal > >>>>>> and > >>>> > >>>>>> could easily embed various structured information (CVE etc.) in > >>>>>> the > >>>> > >>>>>> EventData.Record.RecordData.AdditionalData field. > >>>> > >>>>>> Then "should" statement should be carefully placed in the text of > >>>> > >>>>>> relevant class. > >>>> > >>>>>> > >>>> > >>>>>> I'll prepare some draft so that we could discuss and advance furth= er. > >>>> > >>>>>> > >>>> > >>>>>> Take > >>>> > >>>>>> > >>>> > >>>>>> > >>>> > >>>>>> > >>>> > >>>>>> -----Original Message----- > >>>> > >>>>>> From: mile-bounces@ietf.org > >>>> > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of > >>>> > >>>>>> Thomas.Millar@us-cert.gov > >>>> > >>>>>> Sent: Thursday, July 28, 2011 6:28 PM > >>>> > >>>>>> To: wes@ren-isac.net; > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>>> > >>>> > >>>>>> I think this approach makes more sense. One of the things I think > >>>> > >>>>>> could be helpful is to have a number of SHOULD statements further > >>>> > >>>>>> describing the possible types of other documents that would be > >>>> > >>>>>> expected to ride under the AdditionalData elements of each class > >>>>>> (not > >>>> > >>>>> just > >>>> > >>>>> EventData). > >>>> > >>>>>> What I'm thinking of looks like this (very unpolished): > >>>> > >>>>>> > >>>> > >>>>>> "The Method Class:AdditionalData class SHOULD contain data > >>>>>> elements > >>>> > >>>>>> that describe the methods, tools or techniques employed to cause > >>>>>> the > >>>> > >>>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning > >>>>>> the > >>>> > >>>>>> method such as CVSS, CWSS, or CCE." > >>>> > >>>>>> > >>>> > >>>>>> "The Expectation Class[...] SHOULD contain data elements which > >>>> > >>>>>> describe configuration changes, detection heuristics, or [* (legal > >>>> > >>>>>> authorization?)] to assist in executing or implementing the > >>>>>> requested > >>>> > >>>>>> action, such as XCCDF, OCIL, OVAL, etc" > >>>> > >>>>>> > >>>> > >>>>>> This could go towards encouraging better or at least more > >>>>>> consistent > >>>> > >>>>>> use of "boundary objects" in the substance of incident reports. I > >>>> > >>>>>> could also go on about greater automation and such but that's > >>>>>> probably > >>>> > >>>>>> out of scope for this e-mail. > >>>> > >>>>>> > >>>> > >>>>>> > >>>> > >>>>>> - Tom Millar, US-CERT > >>>> > >>>>>> > >>>> > >>>>>> thomas.millar@us-cert.gov > >>>> > >>>>>> BB: thomas.millar@dhs.gov / > >>>> > >>>>>> 202-631-1915 > >>>> > >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 > >>>> > >>>>>> -----Original Message----- > >>>> > >>>>>> From: mile-bounces@ietf.org > >>>> > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >>>> > >>>>>> Sent: Thursday, July 28, 2011 11:08 AM > >>>> > >>>>>> To: mile@ietf.org > >>>> > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>>> > >>>> > >>>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >>>> > >>>>>> > >>>> > >>>>>> http://tools.ietf.org/html/rfc5070#section-3.19 > >>>> > >>>>>> > >>>> > >>>>>> i've been sticking other "XML like" records under this (icsg1.1 > >>>>>> data, > >>>> > >>>>>> etc...). > >>>> > >>>>>> > >>>> > >>>>>> pretty easy to do, just generate the "other standards" xml (or > >>>>>> json or > >>>> > >>>>>> whatever), embed it there. turns iodef into a sharing platform for > >>>> > >>>>>> other data-types w/o having to extend it too much. > >>>> > >>>>>> > >>>> > >>>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >>>> > >>>>>> > >>>> > >>>>>> So, maybe we could extend the IODEF as described in Figure 1 of > >>>>>> the > >>>> > >>>>>> attached txt file. (correct me if I'm wrong) We could define > >>>> > >>>>>> Incident.EventData.AdditionalData elements and describe them by > >>>>>> using > >>>> > >>>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >>>> > >>>>>> Regarding OVAL, we might define Incident.AdditionalData element, > >>>>>> but I > >>>> > >>>>>> > >>>> > >>>>>> am not sure at this moment, thus is not described in the figure ye= t. > >>>> > >>>>>> I would like to tackle CAPEC first since I believe Kent would like > >>>>>> to > >>>> > >>>>>> tackle CVE and CAPEC. > >>>> > >>>>>> > >>>> > >>>>>> -- > >>>> > >>>>>> Wes > >>>> > >>>>>> claimid.com/wesyoung > >>>> > >>>>>> soc@ren-isac.net > >>>> > >>>>>> > >>>> > >>>>>> * Wes Young> > >>>> > >>>>>> * 0xDDB6E946 - Unverified(L) > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> . > >>>> > >>>>>> > >>>> > >>>>> > >>>> > >>>>> _______________________________________________ > >>>> > >>>>> mile mailing list > >>>> > >>>>> mile@ietf.org > >>>> > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> -- > >>> Takeshi Takahashi, Ph.D. > >>> +81 80 3490 2971 > >>> http://www.taketaka.com/ > >>> > >>> > >> > >> _______________________________________________ > >> mile mailing list > >> mile@ietf.org > >> https://www.ietf.org/mailman/listinfo/mile > From kathleen.moriarty@emc.com Wed Aug 24 06:47:11 2011 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 6113A21F8B30 for ; Wed, 24 Aug 2011 06:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 hBs9SLy0JS2R for ; Wed, 24 Aug 2011 06:47:10 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id CAF6B21F86F6 for ; Wed, 24 Aug 2011 06:47:09 -0700 (PDT) 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 p7ODmHQ7008040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 09:48:17 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 09:48:04 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.221.56.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7ODm3Gs019067 for ; Wed, 24 Aug 2011 09:48:03 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub14.corp.emc.com ([128.221.56.103]) with mapi; Wed, 24 Aug 2011 09:48:02 -0400 From: To: Date: Wed, 24 Aug 2011 09:43:12 -0400 Thread-Topic: [mile] RFC6045-bis, update per ITU comments and list discussions - Security Considerations Thread-Index: AQHMYmQyl9Aikp3b3U6J0/WhE2rNMA== 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: Re: [mile] RFC6045-bis, update per ITU comments and list discussions - Security Considerations 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, 24 Aug 2011 13:47:11 -0000 Hello, As mentioned in the prior message, I updated the security considerations to= address David's concerns. The new text is provided below for ease of revi= ew. Please provide comments on the new text, prior discussions in the thre= ad, or any other items that come up in your review of RFC6045-bis. Here is the updated text for the first part of the security section: ************************** 7. Security Considerations RID has many security considerations built into the design of the protocol, several of which are described in the following sub- sections. For a complete view of security, considerations need to include the availability, confidentiality, and integrity concerns for the transport, storage, and exchange of information. Authenticated encrypted tunnels between systems accepting RID communications MUST be used to provide confidentiality, integrity, authenticity, and privacy for the data. Encryption and digital signatures are also used at the IOEDF document level through RID options to provide confidentiality, integrity, authenticity, privacy and traceability of the document contents. Trust relationships are based on consortiums and established trust relationships of public key infrastructure (PKI) cross-certifications of consortiums. Trust levels can be established in cross-certification processes where entities compare PKI policies that include the specific management and handling of an entity's PKI and certificates issued under that policy. [RFC3647] defines an Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework that may be used in the comparison of policies to establish trust levels and agreements between entities, an entity and a consortium, and consortia. The agreements SHOULD consider key management practices including the ability to perform path validation on certificates [RFC5280], key distribution techniques [RFC2585], Certificate Authority and Registration Authority management practices. The agreements between entities SHOULD also include a common understanding of the usage of RID security, policy, and privacy options discussed in this section. The formality, requirements, and complexity of the agreements for the certificate policy, practices, and the use of RID options SHOULD be decided by the entities or consortiums creating those agreements. By using RIDPolicy information, TLS, and the XML security features of encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig], RID takes advantage of existing security standards. The standards provide clear methods to ensure that messages are secure, authenticated, and authorized, and that the messages meet policy and privacy guidelines and maintain integrity. As specified in the relevant sections of this document, the XML digital signature [RFC3275] and XML encryption [XMLencrypt] are used in the following cases: XML Digital Signature o The originator of the TraceRequest or Investigation request MUST use a detached signature to sign at least one of the original IP packets included in the RecordItem class data to provide authentication to all upstream participants in the trace of the origin. All IP packets provided by the originator may be signed, and additional packets added by upstream peers in the trace may be signed by the peer adding the data, while maintaining the IP packet and detached signature from the original requestor. This signature MUST be passed to all recipients of the TraceRequest. o If an Investigation request does not include an IP packet, the EventData class instance from each the parties involved in the investigation MUST be signed using a detached signature. The signature MUST only be applied to the data entered or added from each entity to provide a method of authentication on the work added by any party involved in the investigation. The EventData class can be used to extend information about an incident by each CSIRT or SP involved in the investigation. Using this class for the digital signature when an IP Packet is not included provides a method to verify each party contributing to the details of the incident. o For all message types, the full IODEF/RID document MUST be signed using an enveloped signature by the sending peer to provide authentication and integrity to the receiving RID system. XML Encryption o 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. This behavior would be agreed upon between peers or a consortium, or determined on a per-message basis, depending on security requirements. It should be noted that there are cases for transport where the RIDPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6046]. o An Investigation request, or any other message type that may be relayed through RID systems other than the intended destination as a result of trust relationships, may be encrypted for the intended recipient. This may be necessary if the RID network is being used for message transfer, the intermediate parties do not need to have knowledge of the request contents, and a direct communication path does not exist. In that case, the RIDPolicy class is used by intermediate parties and is maintained in clear text. o The action taken in the Result message may be encrypted using the key of the request originator. In that case, the intermediate parties can view the RIDPolicy information and know the trace has been completed and do not need to see the action. If the use of encryption were limited to sections of the message, the History class information would be encrypted. Otherwise, it is RECOMMENDED to encrypt the entire IODEF/RID document, using an enveloped signature, for the originator of the request. The existence of the Result message for an incident would tell any intermediate parties used in the path of the incident investigation that the incident handling has been completed. o The iodef:restriction attribute sets expectations for the privacy of an incident and is defined in section 3.2 of RFC5070. The restriction attribute can be set in any of the RID classes to define restrictions for the complete exchange of an IODEF document (including any extensions) or within specific classes of IODEF or IODEF extensions where more limited restrictions are desired. The restriction attribute is contained in each of the RID classes and MUST be used in accordance with privacy expectations for either sections of the IODEF document or the complete IODEF document. Consortiums and organizations should consider this guidance when creating exchange policies. o Expectations based on restriction setting: * If restriction is set to "private", the class or document MUST be encrypted for the recipient using XML encryption and the public key of the recipient. The use of PKI between entities SHOULD adhere to any applicable certificate policy and practices agreements for the use of RID. * If restriction is set to "need-to-know", the class or document MUST be encrypted to ensure only those with need-to-know access can decrypt the data. The document can either be encrypted for each individual for which access is intended or a single group key may be used. The method used SHOULD adhere to any certificate policy and practices agreements between entities for the use of RID. A group key in this instance refers to a single key (symmetric) that is used to encrypt the block of data. The users with need-to-know access privileges may be given access to the shared key by distributing or providing access to it encrypted with each of their public keys. * If restriction is set to "public", the class or document MUST be sent in clear text. This setting can be critical if certain sections of a document or an entire document are to be shared without restrictions. This provides flexibility within an incident to share out certain information freely where appropriate. * If restriction is set to "default", The information can be shared according to an information disclosure policy pre- arranged by the communicating parties. o Expectations based on placement of the restriction setting: * If restriction is set within one of the RID classes, the restriction applies to the entire IODEF document. * If restriction is set within individual IODEF classes, the restriction applies to the specific IODEF class and the children of that class. The formation of policies is a very important aspect of using a messaging system like RID to exchange potentially sensitive information. Many considerations should be involved for peering parties, and some guidelines to protect the data, systems, and transport are covered in this section. Policies established should provide guidelines for communication methods, security, and fall-back procedures. The security considerations for the storage and exchange of information in RID messaging may include adherence to local, regional, or national regulations in addition to the obligations to protect client information during an investigation. RID Policy is a necessary tool for listing the requirements of messages to provide a method to categorize data elements for proper handling. Controls are also provided for the sending entity to protect messages from third parties through XML encryption. RID provides a method to exchange incident handling request and Report messages to peer networks. Administrators have the ability to base decisions on the available resources and other factors of their network and maintain control of incident investigations within their own network. Thus, RID provides the ability for participating networks to manage their own security controls, leveraging the information listed in RIDPolicy. ************************** Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of kathleen.m= oriarty@emc.com [kathleen.moriarty@emc.com] Sent: Wednesday, August 24, 2011 6:24 AM To: tony@yaanatech.com; trammell@tik.ee.ethz.ch Cc: MILE@ietf.org Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussio= ns Thank you Brian and Tony for the comments on the use of LawEnforement. It = seems from these comments, we should use only one indicator for this field,= if others agree/disagree, please post to the list. Tony suggests the use of "Authority". Is this more appropriate than "LawEn= forcement"? Also, Brian raised another question on an enumeration that is in RFC6045 in= RIDPolicy. Should "AcrossNationalBoundaries" be changed to "AcrossJuristi= ctionalBoundaries" or some other indicator for this marker? I also agree that the contact information will be provided, so I think usin= g a more generic marker is appropriate. Is there agreement/disagreement on= this point? Next for the handling of data between countries where you get into privacy = considerations, safe harbor, etc. I believe this will be handled in the ex= tension on data markings from Dr. Katherine Goodier and Gaus Rajnovic. The= y should be able to match up any markers with guidance on how to set the IO= DEF:restriction appropriately for the various markers used so that encrypti= on can be appropriately used at the RID layer with the new guidance. Could= Katherine and/or Gaus confirm? I had a little time and wrote up text to address the PKI questions from Dav= id and will send those out a little later. Thank you! Kathleen ________________________________________ From: Tony Rutkowski [tony@yaanatech.com] Sent: Wednesday, August 24, 2011 6:09 AM To: Brian Trammell Cc: Moriarty, Kathleen; MILE@ietf.org Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discussio= ns I'd suggest that anything related to this subject be kept as generic as possible. The capabilities being supported are subject concurrently to many different legal requirements that are global, regional, national, sub-national, and local in nature. The authorities involved consist of a great many kinds of government agencies, including officers of a court in the case of eDiscovery and other kinds of civil proceedings. The ETSI global eWarrant standards work ultimately allowed for multiple generic terms for its interface, as depicted in the diagram below. You should consider the possibility of using only "authority." [cid:part1.09080503.05030907@yaanatech.com] On 8/24/2011 11:57 AM, Brian Trammell wrote: I would generalize this to "across jurisdictional boundaries," though I am = not exactly certain how. For example, EU organizations in countries impleme= nting EU data protection directives are more free to exchange data with eac= h other than with organizations outside (and this in and of itself is subje= ct to exceptions, cf. "EU safe harbor" provisions, or operational exception= s for network security information). So, data could cross the German/Austri= an border, for example, but be subject to far less restriction than crossin= g the German/American border. _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Aug 24 07:07:27 2011 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 E686821F8678 for ; Wed, 24 Aug 2011 07:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.479 X-Spam-Level: X-Spam-Status: No, score=-107.479 tagged_above=-999 required=5 tests=[AWL=1.120, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 eNEXgBjFRXZh for ; Wed, 24 Aug 2011 07:07:27 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0431321F85AB for ; Wed, 24 Aug 2011 07:07:26 -0700 (PDT) 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 p7OE8bYR031853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 10:08:37 -0400 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, 24 Aug 2011 10:08:28 -0400 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 p7OE8Iol027735 for ; Wed, 24 Aug 2011 10:08:27 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Wed, 24 Aug 2011 10:08:22 -0400 From: To: Date: Wed, 24 Aug 2011 10:08:14 -0400 Thread-Topic: LawEnforcement and jurisdiction Thread-Index: AcxiRhOwpyfeTg/5RYOOSuiMzE/LkgAAKFsLAAbXupA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@MX14A.corp.emc.com> References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.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 Cc: MILE@ietf.org Subject: [mile] LawEnforcement and jurisdiction 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, 24 Aug 2011 14:07:28 -0000 Hi Kathleen, I have a use case question about your suggested text: > I added the following to the description of the "LawEnforcement" enumerat= ion per David's suggestion: > "If the law enforcement agency resides within a different nation that the= sending entity, the > "AcrossNationalBoundaries" enumeration MUST also be set." How does iteration among cooperating law enforcement agencies work? To build on Brian's example, suppose the Kantonspolizei Z=FCrich sends the = incident to one of the Italian national police forces, who in turn sends th= e incident onward to the US FBI. Among the entity that originated the inci= dent report, and these two EU-resident law enforcement agencies, which one = is responsible for ensuring compliance with EU data protection/privacy requ= irements and setting the appropriate enumeration value to indicate that thi= s has been done? A plausible answer is that the entity that sends the data outside the EU sh= all do this (one of the Italian national police forces in the example), and= the upstream entities should (may?) do this if they have reason to believe= that the incident handling is likely to cross EU boundaries (e.g., trace i= dentifies a source in a US block of IP addresses) and scrubbing the data ea= rly in the incident handling will not compromise handling effectiveness. I think some of this is covered in the draft - "7.6. Privacy Concerns and = System Use Guidelines," e.g., the paragraph that begins with "Intra-consort= ium RID communications raise additional issues, especially when the peering= consortiums reside in different regions or nations", but that doesn't seem= to cover law enforcement agencies. Beyond this, I think Brian's commentary suggests that a single jurisdiction= al ENUM value is insufficient: > I would generalize this to "across jurisdictional boundaries," though I a= m not exactly certain how. > For example, EU organizations in countries implementing EU data protectio= n directives are more free to > exchange data with each other than with organizations outside (and this i= n and of itself is subject to > exceptions, cf. "EU safe harbor" provisions, or operational exceptions fo= r network security > information). So, data could cross the German/Austrian border, for exampl= e, but be subject to far less > restriction than crossing the German/American border. It appears that a value is needed that unambiguously indicates that the inc= ident data complies with requirements for leaving the EU (without use of an= exception), e.g., such a value would assist the German authorities in demo= nstrating incident handling system compliance in an EU data protection/priv= acy audit. Beyond that, the German authorities may need another value to d= ifferentiate data that must stay within Germany (or even the German agency = handling the data) vs. can be sent to Austria - that value would not promis= e compliance with data requirements for leaving the EU. Unfortunately, this is starting to look like an invitation to a tar pit, as= values are likely to be needed for a plethora of national data protection/= privacy laws and regulations. IMHO, IANA is not a good place to maintain a= registry of data protection/privacy laws and regulations. Is some other e= ntity already doing this in a fashion that can be pointed to? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of k= athleen.moriarty@emc.com > Sent: Wednesday, August 24, 2011 6:25 AM > To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > Cc: MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions >=20 > Thank you Brian and Tony for the comments on the use of LawEnforement. I= t seems from these comments, > we should use only one indicator for this field, if others agree/disagree= , please post to the list. >=20 > Tony suggests the use of "Authority". Is this more appropriate than "Law= Enforcement"? >=20 > Also, Brian raised another question on an enumeration that is in RFC6045 = in RIDPolicy. Should > "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries"= or some other indicator for > this marker? >=20 > I also agree that the contact information will be provided, so I think us= ing a more generic marker is > appropriate. Is there agreement/disagreement on this point? >=20 > Next for the handling of data between countries where you get into privac= y considerations, safe > harbor, etc. I believe this will be handled in the extension on data mar= kings from Dr. Katherine > Goodier and Gaus Rajnovic. They should be able to match up any markers w= ith guidance on how to set > the IODEF:restriction appropriately for the various markers used so that = encryption can be > appropriately used at the RID layer with the new guidance. Could Katheri= ne and/or Gaus confirm? >=20 > I had a little time and wrote up text to address the PKI questions from D= avid and will send those out > a little later. >=20 > Thank you! > Kathleen >=20 > ________________________________________ > From: Tony Rutkowski [tony@yaanatech.com] > Sent: Wednesday, August 24, 2011 6:09 AM > To: Brian Trammell > Cc: Moriarty, Kathleen; MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions >=20 > I'd suggest that anything related to this subject be > kept as generic as possible. The capabilities being > supported are subject concurrently to many different > legal requirements that are global, regional, national, > sub-national, and local in nature. The authorities involved > consist of a great many kinds of government agencies, > including officers of a court in the case of eDiscovery and > other kinds of civil proceedings. >=20 > The ETSI global eWarrant standards work ultimately > allowed for multiple generic terms for its interface, > as depicted in the diagram below. You should consider > the possibility of using only "authority." >=20 > [cid:part1.09080503.05030907@yaanatech.com] >=20 >=20 >=20 >=20 > On 8/24/2011 11:57 AM, Brian Trammell wrote: >=20 > I would generalize this to "across jurisdictional boundaries," though I a= m not exactly certain how. > For example, EU organizations in countries implementing EU data protectio= n directives are more free to > exchange data with each other than with organizations outside (and this i= n and of itself is subject to > exceptions, cf. "EU safe harbor" provisions, or operational exceptions fo= r network security > information). So, data could cross the German/Austrian border, for exampl= e, but be subject to far less > restriction than crossing the German/American border. >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Wed Aug 24 07:32:08 2011 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 55B2521F8B36 for ; Wed, 24 Aug 2011 07:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.307 X-Spam-Level: X-Spam-Status: No, score=-7.307 tagged_above=-999 required=5 tests=[AWL=1.292, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 C0kFvH3d+9Pn for ; Wed, 24 Aug 2011 07:32:07 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 14CC121F8B30 for ; Wed, 24 Aug 2011 07:32:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 796F9D9307; Wed, 24 Aug 2011 16:33:16 +0200 (MEST) 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 XIeegfg-wLdL; Wed, 24 Aug 2011 16:33:16 +0200 (MEST) 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 EDD25D9302; Wed, 24 Aug 2011 16:33:15 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@MX14A.corp.emc.com> Date: Wed, 24 Aug 2011 16:33:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@MX14A.corp.emc.com> To: X-Mailer: Apple Mail (2.1084) Cc: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction 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, 24 Aug 2011 14:32:08 -0000 Hi, David, all, I'm sadly not aware of an effort to catalog these; this may have = something to do with the fact that the details get murkier (of course!). = Even within the EU, for example, just implementing 95/46/EC (data = protection) doesn't necessarily mean you're allowed to re-forward data, = or even to forward data in the first place, as the member states are = free to implement the directive in any way in which they see fit, and = one state may be more restrictive than another. My personal preference = in this area would be for a URI for a document that explains the = restriction in lawyer-readable terms, but then you need a consortium to = maintain that... Information sharing among law enforcement agencies is even trickier, and = rather outside my expertise. On this point, we're getting into data markings territory.=20 One thing to note is that the use cases for operational RID and LE-RID = are rather different; except in exceptional circumstances (and for their = own networks), LEOs generally do not have operational responsibility for = traffic flows, and I'm not aware of any LEO that steps in on behalf of a = network operator to order another to do something (this seems in the US = anyway like it would require the intervention of a court, in any event). = So LEOs aren't really going to be involved in anything interactive; this = is more for reporting incidents after or well after the fact. So the = big, scary, complicated multijurisdictional forwarding use cases would = seem to be vanishingly rare; the more common case is "I am company X, I = got hacked by gangsters Y, you are the Z State Police, and according to = regulation I have to send you this incident report in a format you can = read so my insurance company will pay me for the costs of resetting = everyone's password." Not that the other case isn't interesting; I just think we can avoid = overthinking things by stepping back and asking what a proposed = mechanism is really going to be used for... Cheers, Brian On Aug 24, 2011, at 4:08 PM, = wrote: > Hi Kathleen, >=20 > I have a use case question about your suggested text: >=20 >> I added the following to the description of the "LawEnforcement" = enumeration per David's suggestion: >> "If the law enforcement agency resides within a different nation that = the sending entity, the >> "AcrossNationalBoundaries" enumeration MUST also be set." >=20 > How does iteration among cooperating law enforcement agencies work? >=20 > To build on Brian's example, suppose the Kantonspolizei Z=FCrich sends = the incident to one of the Italian national police forces, who in turn = sends the incident onward to the US FBI. Among the entity that = originated the incident report, and these two EU-resident law = enforcement agencies, which one is responsible for ensuring compliance = with EU data protection/privacy requirements and setting the appropriate = enumeration value to indicate that this has been done? >=20 > A plausible answer is that the entity that sends the data outside the = EU shall do this (one of the Italian national police forces in the = example), and the upstream entities should (may?) do this if they have = reason to believe that the incident handling is likely to cross EU = boundaries (e.g., trace identifies a source in a US block of IP = addresses) and scrubbing the data early in the incident handling will = not compromise handling effectiveness. >=20 > I think some of this is covered in the draft - "7.6. Privacy Concerns = and System Use Guidelines," e.g., the paragraph that begins with = "Intra-consortium RID communications raise additional issues, especially = when the peering consortiums reside in different regions or nations", = but that doesn't seem to cover law enforcement agencies. >=20 > Beyond this, I think Brian's commentary suggests that a single = jurisdictional ENUM value is insufficient: >=20 >> I would generalize this to "across jurisdictional boundaries," though = I am not exactly certain how. >> For example, EU organizations in countries implementing EU data = protection directives are more free to >> exchange data with each other than with organizations outside (and = this in and of itself is subject to >> exceptions, cf. "EU safe harbor" provisions, or operational = exceptions for network security >> information). So, data could cross the German/Austrian border, for = example, but be subject to far less >> restriction than crossing the German/American border. >=20 > It appears that a value is needed that unambiguously indicates that = the incident data complies with requirements for leaving the EU (without = use of an exception), e.g., such a value would assist the German = authorities in demonstrating incident handling system compliance in an = EU data protection/privacy audit. Beyond that, the German authorities = may need another value to differentiate data that must stay within = Germany (or even the German agency handling the data) vs. can be sent to = Austria - that value would not promise compliance with data requirements = for leaving the EU. >=20 > Unfortunately, this is starting to look like an invitation to a tar = pit, as values are likely to be needed for a plethora of national data = protection/privacy laws and regulations. IMHO, IANA is not a good place = to maintain a registry of data protection/privacy laws and regulations. = Is some other entity already doing this in a fashion that can be pointed = to? >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = Of kathleen.moriarty@emc.com >> Sent: Wednesday, August 24, 2011 6:25 AM >> To: tony@yaanatech.com; trammell@tik.ee.ethz.ch >> Cc: MILE@ietf.org >> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list = discussions >>=20 >> Thank you Brian and Tony for the comments on the use of = LawEnforement. It seems from these comments, >> we should use only one indicator for this field, if others = agree/disagree, please post to the list. >>=20 >> Tony suggests the use of "Authority". Is this more appropriate than = "LawEnforcement"? >>=20 >> Also, Brian raised another question on an enumeration that is in = RFC6045 in RIDPolicy. Should >> "AcrossNationalBoundaries" be changed to = "AcrossJuristictionalBoundaries" or some other indicator for >> this marker? >>=20 >> I also agree that the contact information will be provided, so I = think using a more generic marker is >> appropriate. Is there agreement/disagreement on this point? >>=20 >> Next for the handling of data between countries where you get into = privacy considerations, safe >> harbor, etc. I believe this will be handled in the extension on data = markings from Dr. Katherine >> Goodier and Gaus Rajnovic. They should be able to match up any = markers with guidance on how to set >> the IODEF:restriction appropriately for the various markers used so = that encryption can be >> appropriately used at the RID layer with the new guidance. Could = Katherine and/or Gaus confirm? >>=20 >> I had a little time and wrote up text to address the PKI questions = from David and will send those out >> a little later. >>=20 >> Thank you! >> Kathleen >>=20 >> ________________________________________ >> From: Tony Rutkowski [tony@yaanatech.com] >> Sent: Wednesday, August 24, 2011 6:09 AM >> To: Brian Trammell >> Cc: Moriarty, Kathleen; MILE@ietf.org >> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list = discussions >>=20 >> I'd suggest that anything related to this subject be >> kept as generic as possible. The capabilities being >> supported are subject concurrently to many different >> legal requirements that are global, regional, national, >> sub-national, and local in nature. The authorities involved >> consist of a great many kinds of government agencies, >> including officers of a court in the case of eDiscovery and >> other kinds of civil proceedings. >>=20 >> The ETSI global eWarrant standards work ultimately >> allowed for multiple generic terms for its interface, >> as depicted in the diagram below. You should consider >> the possibility of using only "authority." >>=20 >> [cid:part1.09080503.05030907@yaanatech.com] >>=20 >>=20 >>=20 >>=20 >> On 8/24/2011 11:57 AM, Brian Trammell wrote: >>=20 >> I would generalize this to "across jurisdictional boundaries," though = I am not exactly certain how. >> For example, EU organizations in countries implementing EU data = protection directives are more free to >> exchange data with each other than with organizations outside (and = this in and of itself is subject to >> exceptions, cf. "EU safe harbor" provisions, or operational = exceptions for network security >> information). So, data could cross the German/Austrian border, for = example, but be subject to far less >> restriction than crossing the German/American border. >>=20 >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Aug 24 07:33:07 2011 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 EB40121F8B4B for ; Wed, 24 Aug 2011 07:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.915 X-Spam-Level: X-Spam-Status: No, score=-105.915 tagged_above=-999 required=5 tests=[AWL=0.685, 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 o0iFiifuvoNW for ; Wed, 24 Aug 2011 07:33:06 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5F021F8B36 for ; Wed, 24 Aug 2011 07:33:05 -0700 (PDT) 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 p7OEYFkE029807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 10:34:15 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 10:34:08 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.221.46.114]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7OEY8jd031560 for ; Wed, 24 Aug 2011 10:34:08 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Wed, 24 Aug 2011 10:34:08 -0400 From: To: , Date: Wed, 24 Aug 2011 10:33:45 -0400 Thread-Topic: Digital Signatures Thread-Index: AQHMYmQyl9Aikp3b3U6J0/WhE2rNMJUsCxXw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A3E@MX14A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {1EC8AEE6-56EE-4FCD-9E15-DE299E42B2A1} x-cr-hashedpuzzle: AKvB Aqov Ij5f Iw5u JUPM KRll Ndth OL0q OV3U O0OT O0yI PHc0 Rw8k TJgW TaPn WsVj; 2; awBhAHQAaABsAGUAZQBuAC4AbQBvAHIAaQBhAHIAdAB5AEAAZQBtAGMALgBjAG8AbQA7AG0AaQBsAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {1EC8AEE6-56EE-4FCD-9E15-DE299E42B2A1}; ZABhAHYAaQBkAC4AYgBsAGEAYwBrAEAAZQBtAGMALgBjAG8AbQA=; Wed, 24 Aug 2011 14:33:45 GMT; RABpAGcAaQB0AGEAbAAgAFMAaQBnAG4AYQB0AHUAcgBlAHMA 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] Digital Signatures 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, 24 Aug 2011 14:33:08 -0000 Kathleen, This is looking good - I have a few questions about the number of signature= s per entity and what the signatures cover: > XML Digital Signature > > o The originator of the TraceRequest or Investigation request MUST > use a detached signature to sign at least one of the original IP > packets included in the RecordItem class data to provide > authentication to all upstream participants in the trace of the > origin. All IP packets provided by the originator may be signed, > and additional packets added by upstream peers in the trace may be > signed by the peer adding the data, while maintaining the IP > packet and detached signature from the original requestor. This > signature MUST be passed to all recipients of the TraceRequest. a) What exactly is covered by the signature? It looks like the signature covers a RecordItem instance. b) How many signatures are allowed per entity? Is it "exactly one", or is a signature per packet (RecordItem instance) allowed? If the answer is "exactly one signature", should the containing RecordData instance be signe= d instead of RecordItem? > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. The > signature MUST only be applied to the data entered or added from > each entity to provide a method of authentication on the work > added by any party involved in the investigation. The EventData > class can be used to extend information about an incident by each > CSIRT or SP involved in the investigation. Using this class for > the digital signature when an IP Packet is not included provides a > method to verify each party contributing to the details of the > incident. c) Same question on what is covered by the signature, and in particular: Wh= at is supposed to be signed when EventData instances are nested? I would gues= s that the outermost instance should be signed. d) Same question on number of signatures. Can a single entity add multiple independent (i.e., not nested) EventData instances? If not, then only one signature is possible. e) Nit: in 4th line of quoted text: "applied to the data entered or added from each entity" -> "applied= to the EventData instances originated or added by the signing entity" This avoids a possible misreading of that text to allow signing less than a complete EventData instance. > o For all message types, the full IODEF/RID document MUST be signed > using an enveloped signature by the sending peer to provide > authentication and integrity to the receiving RID system. This is fine ;-). Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of k= athleen.moriarty@emc.com > Sent: Wednesday, August 24, 2011 9:43 AM > To: MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions - Security > Considerations > > Hello, > > As mentioned in the prior message, I updated the security considerations = to address David's concerns. > The new text is provided below for ease of review. Please provide commen= ts on the new text, prior > discussions in the thread, or any other items that come up in your review= of RFC6045-bis. > > Here is the updated text for the first part of the security section: > > ************************** > 7. Security Considerations > > RID has many security considerations built into the design of the > protocol, several of which are described in the following sub- > sections. For a complete view of security, considerations need to > include the availability, confidentiality, and integrity concerns for > the transport, storage, and exchange of information. > > Authenticated encrypted tunnels between systems accepting RID > communications MUST be used to provide confidentiality, integrity, > authenticity, and privacy for the data. Encryption and digital > signatures are also used at the IOEDF document level through RID > options to provide confidentiality, integrity, authenticity, privacy > and traceability of the document contents. Trust relationships are > based on consortiums and established trust relationships of public > key infrastructure (PKI) cross-certifications of consortiums. Trust > levels can be established in cross-certification processes where > entities compare PKI policies that include the specific management > and handling of an entity's PKI and certificates issued under that > policy. [RFC3647] defines an Internet X.509 Public Key > Infrastructure Certificate Policy and Certification Practices > Framework that may be used in the comparison of policies to establish > trust levels and agreements between entities, an entity and a > consortium, and consortia. The agreements SHOULD consider key > management practices including the ability to perform path validation > on certificates [RFC5280], key distribution techniques [RFC2585], > Certificate Authority and Registration Authority management > practices. > > The agreements between entities SHOULD also include a common > understanding of the usage of RID security, policy, and privacy > options discussed in this section. The formality, requirements, and > complexity of the agreements for the certificate policy, practices, > and the use of RID options SHOULD be decided by the entities or > consortiums creating those agreements. > > By using RIDPolicy information, TLS, and the XML security features of > encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig], > RID takes advantage of existing security standards. The standards > provide clear methods to ensure that messages are secure, > authenticated, and authorized, and that the messages meet policy and > privacy guidelines and maintain integrity. > > As specified in the relevant sections of this document, the XML > digital signature [RFC3275] and XML encryption [XMLencrypt] are used > in the following cases: > > XML Digital Signature > > o The originator of the TraceRequest or Investigation request MUST > use a detached signature to sign at least one of the original IP > packets included in the RecordItem class data to provide > authentication to all upstream participants in the trace of the > origin. All IP packets provided by the originator may be signed, > and additional packets added by upstream peers in the trace may be > signed by the peer adding the data, while maintaining the IP > packet and detached signature from the original requestor. This > signature MUST be passed to all recipients of the TraceRequest. > > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. The > signature MUST only be applied to the data entered or added from > each entity to provide a method of authentication on the work > added by any party involved in the investigation. The EventData > class can be used to extend information about an incident by each > CSIRT or SP involved in the investigation. Using this class for > the digital signature when an IP Packet is not included provides a > method to verify each party contributing to the details of the > incident. > > o For all message types, the full IODEF/RID document MUST be signed > using an enveloped signature by the sending peer to provide > authentication and integrity to the receiving RID system. > > XML Encryption > > o 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. This behavior > would be agreed upon between peers or a consortium, or determined > on a per-message basis, depending on security requirements. It > should be noted that there are cases for transport where the > RIDPolicy class needs to be presented in clear text, as detailed > in the transport document [RFC6046]. > > o An Investigation request, or any other message type that may be > relayed through RID systems other than the intended destination as > a result of trust relationships, may be encrypted for the intended > recipient. This may be necessary if the RID network is being used > for message transfer, the intermediate parties do not need to have > knowledge of the request contents, and a direct communication path > does not exist. In that case, the RIDPolicy class is used by > intermediate parties and is maintained in clear text. > > o The action taken in the Result message may be encrypted using the > key of the request originator. In that case, the intermediate > parties can view the RIDPolicy information and know the trace has > been completed and do not need to see the action. If the use of > encryption were limited to sections of the message, the History > class information would be encrypted. Otherwise, it is > RECOMMENDED to encrypt the entire IODEF/RID document, using an > enveloped signature, for the originator of the request. The > existence of the Result message for an incident would tell any > intermediate parties used in the path of the incident > investigation that the incident handling has been completed. > > o The iodef:restriction attribute sets expectations for the privacy > of an incident and is defined in section 3.2 of RFC5070. The > restriction attribute can be set in any of the RID classes to > define restrictions for the complete exchange of an IODEF document > (including any extensions) or within specific classes of IODEF or > IODEF extensions where more limited restrictions are desired. The > restriction attribute is contained in each of the RID classes and > MUST be used in accordance with privacy expectations for either > sections of the IODEF document or the complete IODEF document. > Consortiums and organizations should consider this guidance when > creating exchange policies. > > o Expectations based on restriction setting: > > * If restriction is set to "private", the class or document MUST > be encrypted for the recipient using XML encryption and the > public key of the recipient. The use of PKI between entities > SHOULD adhere to any applicable certificate policy and > practices agreements for the use of RID. > > * If restriction is set to "need-to-know", the class or document > MUST be encrypted to ensure only those with need-to-know access > can decrypt the data. The document can either be encrypted for > each individual for which access is intended or a single group > key may be used. The method used SHOULD adhere to any > certificate policy and practices agreements between entities > for the use of RID. A group key in this instance refers to a > single key (symmetric) that is used to encrypt the block of > data. The users with need-to-know access privileges may be > given access to the shared key by distributing or providing > access to it encrypted with each of their public keys. > > * If restriction is set to "public", the class or document MUST > be sent in clear text. This setting can be critical if certain > sections of a document or an entire document are to be shared > without restrictions. This provides flexibility within an > incident to share out certain information freely where > appropriate. > > * If restriction is set to "default", The information can be > shared according to an information disclosure policy pre- > arranged by the communicating parties. > > o Expectations based on placement of the restriction setting: > > * If restriction is set within one of the RID classes, the > restriction applies to the entire IODEF document. > > * If restriction is set within individual IODEF classes, the > restriction applies to the specific IODEF class and the > children of that class. > > The formation of policies is a very important aspect of using a > messaging system like RID to exchange potentially sensitive > information. Many considerations should be involved for peering > parties, and some guidelines to protect the data, systems, and > transport are covered in this section. Policies established should > provide guidelines for communication methods, security, and fall-back > procedures. > > The security considerations for the storage and exchange of > information in RID messaging may include adherence to local, > regional, or national regulations in addition to the obligations to > protect client information during an investigation. RID Policy is a > necessary tool for listing the requirements of messages to provide a > method to categorize data elements for proper handling. Controls are > also provided for the sending entity to protect messages from third > parties through XML encryption. > > RID provides a method to exchange incident handling request and > Report messages to peer networks. Administrators have the ability to > base decisions on the available resources and other factors of their > network and maintain control of incident investigations within their > own network. Thus, RID provides the ability for participating > networks to manage their own security controls, leveraging the > information listed in RIDPolicy. > ************************** > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of kathleen= .moriarty@emc.com > [kathleen.moriarty@emc.com] > Sent: Wednesday, August 24, 2011 6:24 AM > To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > Cc: MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions > > Thank you Brian and Tony for the comments on the use of LawEnforement. I= t seems from these comments, > we should use only one indicator for this field, if others agree/disagree= , please post to the list. > > Tony suggests the use of "Authority". Is this more appropriate than "Law= Enforcement"? > > Also, Brian raised another question on an enumeration that is in RFC6045 = in RIDPolicy. Should > "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries"= or some other indicator for > this marker? > > I also agree that the contact information will be provided, so I think us= ing a more generic marker is > appropriate. Is there agreement/disagreement on this point? > > Next for the handling of data between countries where you get into privac= y considerations, safe > harbor, etc. I believe this will be handled in the extension on data mar= kings from Dr. Katherine > Goodier and Gaus Rajnovic. They should be able to match up any markers w= ith guidance on how to set > the IODEF:restriction appropriately for the various markers used so that = encryption can be > appropriately used at the RID layer with the new guidance. Could Katheri= ne and/or Gaus confirm? > > I had a little time and wrote up text to address the PKI questions from D= avid and will send those out > a little later. > > Thank you! > Kathleen > > ________________________________________ > From: Tony Rutkowski [tony@yaanatech.com] > Sent: Wednesday, August 24, 2011 6:09 AM > To: Brian Trammell > Cc: Moriarty, Kathleen; MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions > > I'd suggest that anything related to this subject be > kept as generic as possible. The capabilities being > supported are subject concurrently to many different > legal requirements that are global, regional, national, > sub-national, and local in nature. The authorities involved > consist of a great many kinds of government agencies, > including officers of a court in the case of eDiscovery and > other kinds of civil proceedings. > > The ETSI global eWarrant standards work ultimately > allowed for multiple generic terms for its interface, > as depicted in the diagram below. You should consider > the possibility of using only "authority." > > [cid:part1.09080503.05030907@yaanatech.com] > > > > > On 8/24/2011 11:57 AM, Brian Trammell wrote: > > I would generalize this to "across jurisdictional boundaries," though I a= m not exactly certain how. > For example, EU organizations in countries implementing EU data protectio= n directives are more free to > exchange data with each other than with organizations outside (and this i= n and of itself is subject to > exceptions, cf. "EU safe harbor" provisions, or operational exceptions fo= r network security > information). So, data could cross the German/Austrian border, for exampl= e, but be subject to far less > restriction than crossing the German/American border. > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Aug 24 07:35:45 2011 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 5417621F856B for ; Wed, 24 Aug 2011 07:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.937 X-Spam-Level: X-Spam-Status: No, score=-106.937 tagged_above=-999 required=5 tests=[AWL=1.662, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 cEw3e8UiR+ly for ; Wed, 24 Aug 2011 07:35:44 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 13E5621F858D for ; Wed, 24 Aug 2011 07:35:43 -0700 (PDT) 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 p7OEarXQ001325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 10:36:53 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 24 Aug 2011 10:36:47 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7OEZucB011221; Wed, 24 Aug 2011 10:36:47 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Wed, 24 Aug 2011 10:36:36 -0400 From: To: Date: Wed, 24 Aug 2011 10:36:36 -0400 Thread-Topic: [mile] LawEnforcement and jurisdiction Thread-Index: AcxiatQJhPrYLK2xSh+iK6zB3Z16CwAACpLA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A46@MX14A.corp.emc.com> References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@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 Cc: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction 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, 24 Aug 2011 14:35:45 -0000 Hi Brian, I'm fine with declaring law enforcement iteration scenarios as out-of-scope= , although Kathleen should probably add a sentence or two to state that. Thanks, --David > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, August 24, 2011 10:33 AM > To: Black, David > Cc: Moriarty, Kathleen; MILE@ietf.org > Subject: Re: [mile] LawEnforcement and jurisdiction >=20 > Hi, David, all, >=20 > I'm sadly not aware of an effort to catalog these; this may have somethin= g to do with the fact that > the details get murkier (of course!). Even within the EU, for example, ju= st implementing 95/46/EC > (data protection) doesn't necessarily mean you're allowed to re-forward d= ata, or even to forward data > in the first place, as the member states are free to implement the direct= ive in any way in which they > see fit, and one state may be more restrictive than another. My personal = preference in this area would > be for a URI for a document that explains the restriction in lawyer-reada= ble terms, but then you need > a consortium to maintain that... >=20 > Information sharing among law enforcement agencies is even trickier, and = rather outside my expertise. >=20 > On this point, we're getting into data markings territory. >=20 > One thing to note is that the use cases for operational RID and LE-RID ar= e rather different; except in > exceptional circumstances (and for their own networks), LEOs generally do= not have operational > responsibility for traffic flows, and I'm not aware of any LEO that steps= in on behalf of a network > operator to order another to do something (this seems in the US anyway li= ke it would require the > intervention of a court, in any event). So LEOs aren't really going to be= involved in anything > interactive; this is more for reporting incidents after or well after the= fact. So the big, scary, > complicated multijurisdictional forwarding use cases would seem to be van= ishingly rare; the more > common case is "I am company X, I got hacked by gangsters Y, you are the = Z State Police, and according > to regulation I have to send you this incident report in a format you can= read so my insurance company > will pay me for the costs of resetting everyone's password." >=20 > Not that the other case isn't interesting; I just think we can avoid over= thinking things by stepping > back and asking what a proposed mechanism is really going to be used for.= .. >=20 > Cheers, >=20 > Brian >=20 > On Aug 24, 2011, at 4:08 PM, = wrote: >=20 > > Hi Kathleen, > > > > I have a use case question about your suggested text: > > > >> I added the following to the description of the "LawEnforcement" enume= ration per David's > suggestion: > >> "If the law enforcement agency resides within a different nation that = the sending entity, the > >> "AcrossNationalBoundaries" enumeration MUST also be set." > > > > How does iteration among cooperating law enforcement agencies work? > > > > To build on Brian's example, suppose the Kantonspolizei Z=FCrich sends = the incident to one of the > Italian national police forces, who in turn sends the incident onward to = the US FBI. Among the entity > that originated the incident report, and these two EU-resident law enforc= ement agencies, which one is > responsible for ensuring compliance with EU data protection/privacy requi= rements and setting the > appropriate enumeration value to indicate that this has been done? > > > > A plausible answer is that the entity that sends the data outside the E= U shall do this (one of the > Italian national police forces in the example), and the upstream entities= should (may?) do this if > they have reason to believe that the incident handling is likely to cross= EU boundaries (e.g., trace > identifies a source in a US block of IP addresses) and scrubbing the data= early in the incident > handling will not compromise handling effectiveness. > > > > I think some of this is covered in the draft - "7.6. Privacy Concerns = and System Use Guidelines," > e.g., the paragraph that begins with "Intra-consortium RID communications= raise additional issues, > especially when the peering consortiums reside in different regions or na= tions", but that doesn't seem > to cover law enforcement agencies. > > > > Beyond this, I think Brian's commentary suggests that a single jurisdic= tional ENUM value is > insufficient: > > > >> I would generalize this to "across jurisdictional boundaries," though = I am not exactly certain how. > >> For example, EU organizations in countries implementing EU data protec= tion directives are more free > to > >> exchange data with each other than with organizations outside (and thi= s in and of itself is subject > to > >> exceptions, cf. "EU safe harbor" provisions, or operational exceptions= for network security > >> information). So, data could cross the German/Austrian border, for exa= mple, but be subject to far > less > >> restriction than crossing the German/American border. > > > > It appears that a value is needed that unambiguously indicates that the= incident data complies with > requirements for leaving the EU (without use of an exception), e.g., such= a value would assist the > German authorities in demonstrating incident handling system compliance i= n an EU data > protection/privacy audit. Beyond that, the German authorities may need a= nother value to differentiate > data that must stay within Germany (or even the German agency handling th= e data) vs. can be sent to > Austria - that value would not promise compliance with data requirements = for leaving the EU. > > > > Unfortunately, this is starting to look like an invitation to a tar pit= , as values are likely to be > needed for a plethora of national data protection/privacy laws and regula= tions. IMHO, IANA is not a > good place to maintain a registry of data protection/privacy laws and reg= ulations. Is some other > entity already doing this in a fashion that can be pointed to? > > > > Thanks, > > --David > > > > > >> -----Original Message----- > >> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf O= f kathleen.moriarty@emc.com > >> Sent: Wednesday, August 24, 2011 6:25 AM > >> To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > >> Cc: MILE@ietf.org > >> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list disc= ussions > >> > >> Thank you Brian and Tony for the comments on the use of LawEnforement.= It seems from these > comments, > >> we should use only one indicator for this field, if others agree/disag= ree, please post to the list. > >> > >> Tony suggests the use of "Authority". Is this more appropriate than "= LawEnforcement"? > >> > >> Also, Brian raised another question on an enumeration that is in RFC60= 45 in RIDPolicy. Should > >> "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundari= es" or some other indicator > for > >> this marker? > >> > >> I also agree that the contact information will be provided, so I think= using a more generic marker > is > >> appropriate. Is there agreement/disagreement on this point? > >> > >> Next for the handling of data between countries where you get into pri= vacy considerations, safe > >> harbor, etc. I believe this will be handled in the extension on data = markings from Dr. Katherine > >> Goodier and Gaus Rajnovic. They should be able to match up any marker= s with guidance on how to set > >> the IODEF:restriction appropriately for the various markers used so th= at encryption can be > >> appropriately used at the RID layer with the new guidance. Could Kath= erine and/or Gaus confirm? > >> > >> I had a little time and wrote up text to address the PKI questions fro= m David and will send those > out > >> a little later. > >> > >> Thank you! > >> Kathleen > >> > >> ________________________________________ > >> From: Tony Rutkowski [tony@yaanatech.com] > >> Sent: Wednesday, August 24, 2011 6:09 AM > >> To: Brian Trammell > >> Cc: Moriarty, Kathleen; MILE@ietf.org > >> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list disc= ussions > >> > >> I'd suggest that anything related to this subject be > >> kept as generic as possible. The capabilities being > >> supported are subject concurrently to many different > >> legal requirements that are global, regional, national, > >> sub-national, and local in nature. The authorities involved > >> consist of a great many kinds of government agencies, > >> including officers of a court in the case of eDiscovery and > >> other kinds of civil proceedings. > >> > >> The ETSI global eWarrant standards work ultimately > >> allowed for multiple generic terms for its interface, > >> as depicted in the diagram below. You should consider > >> the possibility of using only "authority." > >> > >> [cid:part1.09080503.05030907@yaanatech.com] > >> > >> > >> > >> > >> On 8/24/2011 11:57 AM, Brian Trammell wrote: > >> > >> I would generalize this to "across jurisdictional boundaries," though = I am not exactly certain how. > >> For example, EU organizations in countries implementing EU data protec= tion directives are more free > to > >> exchange data with each other than with organizations outside (and thi= s in and of itself is subject > to > >> exceptions, cf. "EU safe harbor" provisions, or operational exceptions= for network security > >> information). So, data could cross the German/Austrian border, for exa= mple, but be subject to far > less > >> restriction than crossing the German/American border. > >> > >> > >> _______________________________________________ > >> mile mailing 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 kathleen.moriarty@emc.com Wed Aug 24 07:58:35 2011 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 B05D521F8C09 for ; Wed, 24 Aug 2011 07:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.291 X-Spam-Level: X-Spam-Status: No, score=-7.291 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 45zteKKky7vp for ; Wed, 24 Aug 2011 07:58:34 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9B23C21F8BFB for ; Wed, 24 Aug 2011 07:58:34 -0700 (PDT) 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 p7OExhQN026596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 10:59:43 -0400 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, 24 Aug 2011 10:59:29 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.221.56.108]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7OExSkm009985 for ; Wed, 24 Aug 2011 10:59:28 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub22.corp.emc.com ([128.221.56.108]) with mapi; Wed, 24 Aug 2011 10:59:29 -0400 From: To: Date: Wed, 24 Aug 2011 10:59:24 -0400 Thread-Topic: LawEnforcement and jurisdiction Thread-Index: AcxiRhOwpyfeTg/5RYOOSuiMzE/LkgAAKFsLAAbXupAAAhNxxw== Message-ID: References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com> , <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@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: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction 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, 24 Aug 2011 14:58:35 -0000 Hello David, Thank you for the additional comments. Iteration would be handled through the same method as other instances of it= eration with updated contacts and the appropriate use of signatures for tra= cking, etc. One LawEnforcement entity to another would be similar to a Pee= rtoPeer,which is also not listed explicitly in this section as consideratio= ns are covered under other headings. I believe the use cases being raised by both you and Brian fall into the ar= ea that will be addressed by the data classification/marking extensions tha= t include privacy considerations by Dr. Katherine Goodier and Gaus Rajnovic= . At the start of the MILE list, there were three separate options proposed f= or handling markings and restrictions for data privacy laws of various coun= tries. The use cases you are referring to are specific to ones that contai= n privacy information as categorized by a country as the regulations are sp= ecific to personally identifiable information (PII). This may not apply to= all incidents that cross boarders of various countries. If there is no PI= I (according to the definitions in the appropriate regulations - they vary = slightly from one to another having read many of them), then there would no= t be any special handling considerations.=20 If PII exists, then a marking would be used according to the extension to b= e developed specifications. The option I like from the 3 previously propos= ed to the list was that you would list the country code (and state for the = US) for the PII included in the incident. From this, the appropriate consi= derations can be applied to the data according to the requirements of that = country and where the data rests or s transferred to at the point of a deci= sion. The requirements are typically interpreted by the lawyers/compliance= folks of the organization handing the data at the time (as they are respon= sible for mis-handling). It would be important to have this handled at the= SP (SP used generically as in RID-bis) sending the data as there may be ne= w regulations that apply in some situations, like safe-harbour as data goes= from Europe to the US for example as opposed to requirements that may be i= n place between nations in Europe. I believe this is out-of-scope for RID, but the guidance may use options in= cluded in RID like the use of the IODEF:restriction attribute to require en= cryption. Do others have opinions here? Should guidance/markings come in the data cl= assification/marking extension (may have a different name when published)? Thank you, Kathleen ________________________________________ From: Black, David Sent: Wednesday, August 24, 2011 10:08 AM To: Moriarty, Kathleen Cc: MILE@ietf.org Subject: LawEnforcement and jurisdiction Hi Kathleen, I have a use case question about your suggested text: > I added the following to the description of the "LawEnforcement" enumerat= ion per David's suggestion: > "If the law enforcement agency resides within a different nation that the= sending entity, the > "AcrossNationalBoundaries" enumeration MUST also be set." How does iteration among cooperating law enforcement agencies work? To build on Brian's example, suppose the Kantonspolizei Z=FCrich sends the = incident to one of the Italian national police forces, who in turn sends th= e incident onward to the US FBI. Among the entity that originated the inci= dent report, and these two EU-resident law enforcement agencies, which one = is responsible for ensuring compliance with EU data protection/privacy requ= irements and setting the appropriate enumeration value to indicate that thi= s has been done? A plausible answer is that the entity that sends the data outside the EU sh= all do this (one of the Italian national police forces in the example), and= the upstream entities should (may?) do this if they have reason to believe= that the incident handling is likely to cross EU boundaries (e.g., trace i= dentifies a source in a US block of IP addresses) and scrubbing the data ea= rly in the incident handling will not compromise handling effectiveness. I think some of this is covered in the draft - "7.6. Privacy Concerns and = System Use Guidelines," e.g., the paragraph that begins with "Intra-consort= ium RID communications raise additional issues, especially when the peering= consortiums reside in different regions or nations", but that doesn't seem= to cover law enforcement agencies. Beyond this, I think Brian's commentary suggests that a single jurisdiction= al ENUM value is insufficient: > I would generalize this to "across jurisdictional boundaries," though I a= m not exactly certain how. > For example, EU organizations in countries implementing EU data protectio= n directives are more free to > exchange data with each other than with organizations outside (and this i= n and of itself is subject to > exceptions, cf. "EU safe harbor" provisions, or operational exceptions fo= r network security > information). So, data could cross the German/Austrian border, for exampl= e, but be subject to far less > restriction than crossing the German/American border. It appears that a value is needed that unambiguously indicates that the inc= ident data complies with requirements for leaving the EU (without use of an= exception), e.g., such a value would assist the German authorities in demo= nstrating incident handling system compliance in an EU data protection/priv= acy audit. Beyond that, the German authorities may need another value to d= ifferentiate data that must stay within Germany (or even the German agency = handling the data) vs. can be sent to Austria - that value would not promis= e compliance with data requirements for leaving the EU. Unfortunately, this is starting to look like an invitation to a tar pit, as= values are likely to be needed for a plethora of national data protection/= privacy laws and regulations. IMHO, IANA is not a good place to maintain a= registry of data protection/privacy laws and regulations. Is some other e= ntity already doing this in a fashion that can be pointed to? Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of k= athleen.moriarty@emc.com > Sent: Wednesday, August 24, 2011 6:25 AM > To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > Cc: MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions > > Thank you Brian and Tony for the comments on the use of LawEnforement. I= t seems from these comments, > we should use only one indicator for this field, if others agree/disagree= , please post to the list. > > Tony suggests the use of "Authority". Is this more appropriate than "Law= Enforcement"? > > Also, Brian raised another question on an enumeration that is in RFC6045 = in RIDPolicy. Should > "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries"= or some other indicator for > this marker? > > I also agree that the contact information will be provided, so I think us= ing a more generic marker is > appropriate. Is there agreement/disagreement on this point? > > Next for the handling of data between countries where you get into privac= y considerations, safe > harbor, etc. I believe this will be handled in the extension on data mar= kings from Dr. Katherine > Goodier and Gaus Rajnovic. They should be able to match up any markers w= ith guidance on how to set > the IODEF:restriction appropriately for the various markers used so that = encryption can be > appropriately used at the RID layer with the new guidance. Could Katheri= ne and/or Gaus confirm? > > I had a little time and wrote up text to address the PKI questions from D= avid and will send those out > a little later. > > Thank you! > Kathleen > > ________________________________________ > From: Tony Rutkowski [tony@yaanatech.com] > Sent: Wednesday, August 24, 2011 6:09 AM > To: Brian Trammell > Cc: Moriarty, Kathleen; MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions > > I'd suggest that anything related to this subject be > kept as generic as possible. The capabilities being > supported are subject concurrently to many different > legal requirements that are global, regional, national, > sub-national, and local in nature. The authorities involved > consist of a great many kinds of government agencies, > including officers of a court in the case of eDiscovery and > other kinds of civil proceedings. > > The ETSI global eWarrant standards work ultimately > allowed for multiple generic terms for its interface, > as depicted in the diagram below. You should consider > the possibility of using only "authority." > > [cid:part1.09080503.05030907@yaanatech.com] > > > > > On 8/24/2011 11:57 AM, Brian Trammell wrote: > > I would generalize this to "across jurisdictional boundaries," though I a= m not exactly certain how. > For example, EU organizations in countries implementing EU data protectio= n directives are more free to > exchange data with each other than with organizations outside (and this i= n and of itself is subject to > exceptions, cf. "EU safe harbor" provisions, or operational exceptions fo= r network security > information). So, data could cross the German/Austrian border, for exampl= e, but be subject to far less > restriction than crossing the German/American border. > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Aug 24 08:16:10 2011 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 59C7E21F85A1 for ; Wed, 24 Aug 2011 08:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.511 X-Spam-Level: X-Spam-Status: No, score=-107.511 tagged_above=-999 required=5 tests=[AWL=1.088, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 eOEm8D1Y8AvZ for ; Wed, 24 Aug 2011 08:16:09 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 396CA21F8584 for ; Wed, 24 Aug 2011 08:16:08 -0700 (PDT) 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 p7OFHI9v024910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 11:17:18 -0400 Received: from mailhub.lss.emc.com ([10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 11:17:07 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7OFGdii030916 for ; Wed, 24 Aug 2011 11:17:06 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 24 Aug 2011 11:16:45 -0400 From: To: Date: Wed, 24 Aug 2011 11:16:44 -0400 Thread-Topic: LawEnforcement and jurisdiction Thread-Index: AcxiRhOwpyfeTg/5RYOOSuiMzE/LkgAAKFsLAAbXupAAAhNxxwABewUg Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672AAB@MX14A.corp.emc.com> References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com> , <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@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 Cc: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction 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, 24 Aug 2011 15:16:10 -0000 Kathleen, > I believe this is out-of-scope for RID, but the guidance may use options = included in RID like the use > of the IODEF:restriction attribute to require encryption. I believe that at least Brian, you and I are in violent agreement that this= sort of law enforcement iteration scenario is out-of-scope for core RID. Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, August 24, 2011 10:59 AM > To: Black, David > Cc: MILE@ietf.org > Subject: RE: LawEnforcement and jurisdiction >=20 > Hello David, >=20 > Thank you for the additional comments. >=20 > Iteration would be handled through the same method as other instances of = iteration with updated > contacts and the appropriate use of signatures for tracking, etc. One La= wEnforcement entity to > another would be similar to a PeertoPeer,which is also not listed explici= tly in this section as > considerations are covered under other headings. >=20 > I believe the use cases being raised by both you and Brian fall into the = area that will be addressed > by the data classification/marking extensions that include privacy consid= erations by Dr. Katherine > Goodier and Gaus Rajnovic. >=20 > At the start of the MILE list, there were three separate options proposed= for handling markings and > restrictions for data privacy laws of various countries. The use cases y= ou are referring to are > specific to ones that contain privacy information as categorized by a cou= ntry as the regulations are > specific to personally identifiable information (PII). This may not appl= y to all incidents that cross > boarders of various countries. If there is no PII (according to the defi= nitions in the appropriate > regulations - they vary slightly from one to another having read many of = them), then there would not > be any special handling considerations. >=20 > If PII exists, then a marking would be used according to the extension to= be developed specifications. > The option I like from the 3 previously proposed to the list was that you= would list the country code > (and state for the US) for the PII included in the incident. From this, = the appropriate > considerations can be applied to the data according to the requirements o= f that country and where the > data rests or s transferred to at the point of a decision. The requireme= nts are typically interpreted > by the lawyers/compliance folks of the organization handing the data at t= he time (as they are > responsible for mis-handling). It would be important to have this handle= d at the SP (SP used > generically as in RID-bis) sending the data as there may be new regulatio= ns that apply in some > situations, like safe-harbour as data goes from Europe to the US for exam= ple as opposed to > requirements that may be in place between nations in Europe. >=20 > I believe this is out-of-scope for RID, but the guidance may use options = included in RID like the use > of the IODEF:restriction attribute to require encryption. >=20 > Do others have opinions here? Should guidance/markings come in the data = classification/marking > extension (may have a different name when published)? >=20 > Thank you, > Kathleen >=20 > ________________________________________ > From: Black, David > Sent: Wednesday, August 24, 2011 10:08 AM > To: Moriarty, Kathleen > Cc: MILE@ietf.org > Subject: LawEnforcement and jurisdiction >=20 > Hi Kathleen, >=20 > I have a use case question about your suggested text: >=20 > > I added the following to the description of the "LawEnforcement" enumer= ation per David's suggestion: > > "If the law enforcement agency resides within a different nation that t= he sending entity, the > > "AcrossNationalBoundaries" enumeration MUST also be set." >=20 > How does iteration among cooperating law enforcement agencies work? >=20 > To build on Brian's example, suppose the Kantonspolizei Z=FCrich sends th= e incident to one of the > Italian national police forces, who in turn sends the incident onward to = the US FBI. Among the entity > that originated the incident report, and these two EU-resident law enforc= ement agencies, which one is > responsible for ensuring compliance with EU data protection/privacy requi= rements and setting the > appropriate enumeration value to indicate that this has been done? >=20 > A plausible answer is that the entity that sends the data outside the EU = shall do this (one of the > Italian national police forces in the example), and the upstream entities= should (may?) do this if > they have reason to believe that the incident handling is likely to cross= EU boundaries (e.g., trace > identifies a source in a US block of IP addresses) and scrubbing the data= early in the incident > handling will not compromise handling effectiveness. >=20 > I think some of this is covered in the draft - "7.6. Privacy Concerns an= d System Use Guidelines," > e.g., the paragraph that begins with "Intra-consortium RID communications= raise additional issues, > especially when the peering consortiums reside in different regions or na= tions", but that doesn't seem > to cover law enforcement agencies. >=20 > Beyond this, I think Brian's commentary suggests that a single jurisdicti= onal ENUM value is > insufficient: >=20 > > I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. > > For example, EU organizations in countries implementing EU data protect= ion directives are more free > to > > exchange data with each other than with organizations outside (and this= in and of itself is subject > to > > exceptions, cf. "EU safe harbor" provisions, or operational exceptions = for network security > > information). So, data could cross the German/Austrian border, for exam= ple, but be subject to far > less > > restriction than crossing the German/American border. >=20 > It appears that a value is needed that unambiguously indicates that the i= ncident data complies with > requirements for leaving the EU (without use of an exception), e.g., such= a value would assist the > German authorities in demonstrating incident handling system compliance i= n an EU data > protection/privacy audit. Beyond that, the German authorities may need a= nother value to differentiate > data that must stay within Germany (or even the German agency handling th= e data) vs. can be sent to > Austria - that value would not promise compliance with data requirements = for leaving the EU. >=20 > Unfortunately, this is starting to look like an invitation to a tar pit, = as values are likely to be > needed for a plethora of national data protection/privacy laws and regula= tions. IMHO, IANA is not a > good place to maintain a registry of data protection/privacy laws and reg= ulations. Is some other > entity already doing this in a fashion that can be pointed to? >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= kathleen.moriarty@emc.com > > Sent: Wednesday, August 24, 2011 6:25 AM > > To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > > Cc: MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions > > > > Thank you Brian and Tony for the comments on the use of LawEnforement. = It seems from these > comments, > > we should use only one indicator for this field, if others agree/disagr= ee, please post to the list. > > > > Tony suggests the use of "Authority". Is this more appropriate than "L= awEnforcement"? > > > > Also, Brian raised another question on an enumeration that is in RFC604= 5 in RIDPolicy. Should > > "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundarie= s" or some other indicator > for > > this marker? > > > > I also agree that the contact information will be provided, so I think = using a more generic marker > is > > appropriate. Is there agreement/disagreement on this point? > > > > Next for the handling of data between countries where you get into priv= acy considerations, safe > > harbor, etc. I believe this will be handled in the extension on data m= arkings from Dr. Katherine > > Goodier and Gaus Rajnovic. They should be able to match up any markers= with guidance on how to set > > the IODEF:restriction appropriately for the various markers used so tha= t encryption can be > > appropriately used at the RID layer with the new guidance. Could Kathe= rine and/or Gaus confirm? > > > > I had a little time and wrote up text to address the PKI questions from= David and will send those > out > > a little later. > > > > Thank you! > > Kathleen > > > > ________________________________________ > > From: Tony Rutkowski [tony@yaanatech.com] > > Sent: Wednesday, August 24, 2011 6:09 AM > > To: Brian Trammell > > Cc: Moriarty, Kathleen; MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions > > > > I'd suggest that anything related to this subject be > > kept as generic as possible. The capabilities being > > supported are subject concurrently to many different > > legal requirements that are global, regional, national, > > sub-national, and local in nature. The authorities involved > > consist of a great many kinds of government agencies, > > including officers of a court in the case of eDiscovery and > > other kinds of civil proceedings. > > > > The ETSI global eWarrant standards work ultimately > > allowed for multiple generic terms for its interface, > > as depicted in the diagram below. You should consider > > the possibility of using only "authority." > > > > [cid:part1.09080503.05030907@yaanatech.com] > > > > > > > > > > On 8/24/2011 11:57 AM, Brian Trammell wrote: > > > > I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. > > For example, EU organizations in countries implementing EU data protect= ion directives are more free > to > > exchange data with each other than with organizations outside (and this= in and of itself is subject > to > > exceptions, cf. "EU safe harbor" provisions, or operational exceptions = for network security > > information). So, data could cross the German/Austrian border, for exam= ple, but be subject to far > less > > restriction than crossing the German/American border. > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Aug 24 09:19:30 2011 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 91F5621F8C6F for ; Wed, 24 Aug 2011 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 gEc3OZO9d-NS for ; Wed, 24 Aug 2011 09:19:29 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id AB55F21F8C69 for ; Wed, 24 Aug 2011 09:19:28 -0700 (PDT) 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 p7OGKcBr005062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 12:20:38 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 12:20:34 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.221.56.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7OGKXBN021078 for ; Wed, 24 Aug 2011 12:20:33 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub16.corp.emc.com ([128.221.56.105]) with mapi; Wed, 24 Aug 2011 12:20:32 -0400 From: To: , Date: Wed, 24 Aug 2011 12:20:32 -0400 Thread-Topic: Digital Signatures Thread-Index: AQHMYmQyl9Aikp3b3U6J0/WhE2rNMJUsCxXwgAAY1U8= Message-ID: References: , <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A3E@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A3E@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] Digital Signatures 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, 24 Aug 2011 16:19:30 -0000 Hello David, Thank you, again. I will keep my comments in-line to address your questions (and maybe raise = one or two for the list). BTW, I also added RFC5275 as a reference for the use of group keys and asso= ciated requirements. ________________________________________ From: Black, David Sent: Wednesday, August 24, 2011 10:33 AM To: Moriarty, Kathleen; MILE@ietf.org Subject: Digital Signatures Kathleen, This is looking good - I have a few questions about the number of signature= s per entity and what the signatures cover: > XML Digital Signature > > o The originator of the TraceRequest or Investigation request MUST > use a detached signature to sign at least one of the original IP > packets included in the RecordItem class data to provide > authentication to all upstream participants in the trace of the > origin. All IP packets provided by the originator may be signed, > and additional packets added by upstream peers in the trace may be > signed by the peer adding the data, while maintaining the IP > packet and detached signature from the original requestor. This > signature MUST be passed to all recipients of the TraceRequest. a) What exactly is covered by the signature? It looks like the signature covers a RecordItem instance. Yes, it is the RecordItem as that is a way to utilize detached signatures s= o that processing and verification is possible. I added the following text= to ensure this is clear: "It is important to note that only the IPPacket is signed at the RecordItem= level. Since multiple RecordItems may exist within an IODEF document and = may originate from different sources, the signature is applied at the Recor= dItem level to enable the use of an XML detached signature." For anyone following, if you look at an example of how a packet is represen= ted, it may help with the clarification (example from RFC6045): 450000522ad9 0000ff06c41fc0a801020a010102976d0050103e020810d9 4a1350021000ad6700005468616e6b20796f7520666f7220 6361726566756c6c792072656164696e6720746869732052 46432e0a b) How many signatures are allowed per entity? Is it "exactly one", or is a signature per packet (RecordItem instance) allowed? If the answer is "exactly one signature", should the containing RecordData instance be signe= d instead of RecordItem? Actually, you want this at the RecordItem level in case other entities add = in more RecordItems so that you can verify the signatures along the way usi= ng detached signatures. If you use RecordData and additional information i= s added (more RecordItems), the signature breaks for a detached signature. = You could switch to an enveloped signature, but then you would have to fol= low the guidelines in the specification to explicitly state what was signed= (all possible, but not as simple). I think it may be better to leave it at at least one if a packet is include= d. > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. The > signature MUST only be applied to the data entered or added from > each entity to provide a method of authentication on the work > added by any party involved in the investigation. The EventData > class can be used to extend information about an incident by each > CSIRT or SP involved in the investigation. Using this class for > the digital signature when an IP Packet is not included provides a > method to verify each party contributing to the details of the > incident. c) Same question on what is covered by the signature, and in particular: Wh= at is supposed to be signed when EventData instances are nested? I would gues= s that the outermost instance should be signed. I have been thinking more about this and believe it would be better to just= bump this all up to a RecordItem MUST be signed instead of packet to get a= round the problem where there is no packet in an incident. If no RecordIte= ms exist, an NTP timestamp could be used for this purpose. If this is an a= greeable solution, I will make the text updates. d) Same question on number of signatures. Can a single entity add multiple independent (i.e., not nested) EventData instances? If not, then only one signature is possible. e) Nit: in 4th line of quoted text: "applied to the data entered or added from each entity" -> "applied= to the EventData instances originated or added by the signing entity" This avoids a possible misreading of that text to allow signing less than a complete EventData instance. > o For all message types, the full IODEF/RID document MUST be signed > using an enveloped signature by the sending peer to provide > authentication and integrity to the receiving RID system. I can also add a note on the possible use of enveloped signatures over the = entire document where entities are interested in tracking what data came fr= om what entity following the XML Digital Signature guidance. As stated in = the bullet listed above, RID just requires the sending peer to use an envel= oped signature for authentication/integrity. This additional usage would b= e based on peer or consortium agreements and makes sense as a good option t= o include (at least to me) and I would like other opinions. This is fine ;-). Thanks, Kathleen Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of k= athleen.moriarty@emc.com > Sent: Wednesday, August 24, 2011 9:43 AM > To: MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions - Security > Considerations > > Hello, > > As mentioned in the prior message, I updated the security considerations = to address David's concerns. > The new text is provided below for ease of review. Please provide commen= ts on the new text, prior > discussions in the thread, or any other items that come up in your review= of RFC6045-bis. > > Here is the updated text for the first part of the security section: > > ************************** > 7. Security Considerations > > RID has many security considerations built into the design of the > protocol, several of which are described in the following sub- > sections. For a complete view of security, considerations need to > include the availability, confidentiality, and integrity concerns for > the transport, storage, and exchange of information. > > Authenticated encrypted tunnels between systems accepting RID > communications MUST be used to provide confidentiality, integrity, > authenticity, and privacy for the data. Encryption and digital > signatures are also used at the IOEDF document level through RID > options to provide confidentiality, integrity, authenticity, privacy > and traceability of the document contents. Trust relationships are > based on consortiums and established trust relationships of public > key infrastructure (PKI) cross-certifications of consortiums. Trust > levels can be established in cross-certification processes where > entities compare PKI policies that include the specific management > and handling of an entity's PKI and certificates issued under that > policy. [RFC3647] defines an Internet X.509 Public Key > Infrastructure Certificate Policy and Certification Practices > Framework that may be used in the comparison of policies to establish > trust levels and agreements between entities, an entity and a > consortium, and consortia. The agreements SHOULD consider key > management practices including the ability to perform path validation > on certificates [RFC5280], key distribution techniques [RFC2585], > Certificate Authority and Registration Authority management > practices. > > The agreements between entities SHOULD also include a common > understanding of the usage of RID security, policy, and privacy > options discussed in this section. The formality, requirements, and > complexity of the agreements for the certificate policy, practices, > and the use of RID options SHOULD be decided by the entities or > consortiums creating those agreements. > > By using RIDPolicy information, TLS, and the XML security features of > encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig], > RID takes advantage of existing security standards. The standards > provide clear methods to ensure that messages are secure, > authenticated, and authorized, and that the messages meet policy and > privacy guidelines and maintain integrity. > > As specified in the relevant sections of this document, the XML > digital signature [RFC3275] and XML encryption [XMLencrypt] are used > in the following cases: > > XML Digital Signature > > o The originator of the TraceRequest or Investigation request MUST > use a detached signature to sign at least one of the original IP > packets included in the RecordItem class data to provide > authentication to all upstream participants in the trace of the > origin. All IP packets provided by the originator may be signed, > and additional packets added by upstream peers in the trace may be > signed by the peer adding the data, while maintaining the IP > packet and detached signature from the original requestor. This > signature MUST be passed to all recipients of the TraceRequest. > > o If an Investigation request does not include an IP packet, the > EventData class instance from each the parties involved in the > investigation MUST be signed using a detached signature. The > signature MUST only be applied to the data entered or added from > each entity to provide a method of authentication on the work > added by any party involved in the investigation. The EventData > class can be used to extend information about an incident by each > CSIRT or SP involved in the investigation. Using this class for > the digital signature when an IP Packet is not included provides a > method to verify each party contributing to the details of the > incident. > > o For all message types, the full IODEF/RID document MUST be signed > using an enveloped signature by the sending peer to provide > authentication and integrity to the receiving RID system. > > XML Encryption > > o 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. This behavior > would be agreed upon between peers or a consortium, or determined > on a per-message basis, depending on security requirements. It > should be noted that there are cases for transport where the > RIDPolicy class needs to be presented in clear text, as detailed > in the transport document [RFC6046]. > > o An Investigation request, or any other message type that may be > relayed through RID systems other than the intended destination as > a result of trust relationships, may be encrypted for the intended > recipient. This may be necessary if the RID network is being used > for message transfer, the intermediate parties do not need to have > knowledge of the request contents, and a direct communication path > does not exist. In that case, the RIDPolicy class is used by > intermediate parties and is maintained in clear text. > > o The action taken in the Result message may be encrypted using the > key of the request originator. In that case, the intermediate > parties can view the RIDPolicy information and know the trace has > been completed and do not need to see the action. If the use of > encryption were limited to sections of the message, the History > class information would be encrypted. Otherwise, it is > RECOMMENDED to encrypt the entire IODEF/RID document, using an > enveloped signature, for the originator of the request. The > existence of the Result message for an incident would tell any > intermediate parties used in the path of the incident > investigation that the incident handling has been completed. > > o The iodef:restriction attribute sets expectations for the privacy > of an incident and is defined in section 3.2 of RFC5070. The > restriction attribute can be set in any of the RID classes to > define restrictions for the complete exchange of an IODEF document > (including any extensions) or within specific classes of IODEF or > IODEF extensions where more limited restrictions are desired. The > restriction attribute is contained in each of the RID classes and > MUST be used in accordance with privacy expectations for either > sections of the IODEF document or the complete IODEF document. > Consortiums and organizations should consider this guidance when > creating exchange policies. > > o Expectations based on restriction setting: > > * If restriction is set to "private", the class or document MUST > be encrypted for the recipient using XML encryption and the > public key of the recipient. The use of PKI between entities > SHOULD adhere to any applicable certificate policy and > practices agreements for the use of RID. > > * If restriction is set to "need-to-know", the class or document > MUST be encrypted to ensure only those with need-to-know access > can decrypt the data. The document can either be encrypted for > each individual for which access is intended or a single group > key may be used. The method used SHOULD adhere to any > certificate policy and practices agreements between entities > for the use of RID. A group key in this instance refers to a > single key (symmetric) that is used to encrypt the block of > data. The users with need-to-know access privileges may be > given access to the shared key by distributing or providing > access to it encrypted with each of their public keys. > > * If restriction is set to "public", the class or document MUST > be sent in clear text. This setting can be critical if certain > sections of a document or an entire document are to be shared > without restrictions. This provides flexibility within an > incident to share out certain information freely where > appropriate. > > * If restriction is set to "default", The information can be > shared according to an information disclosure policy pre- > arranged by the communicating parties. > > o Expectations based on placement of the restriction setting: > > * If restriction is set within one of the RID classes, the > restriction applies to the entire IODEF document. > > * If restriction is set within individual IODEF classes, the > restriction applies to the specific IODEF class and the > children of that class. > > The formation of policies is a very important aspect of using a > messaging system like RID to exchange potentially sensitive > information. Many considerations should be involved for peering > parties, and some guidelines to protect the data, systems, and > transport are covered in this section. Policies established should > provide guidelines for communication methods, security, and fall-back > procedures. > > The security considerations for the storage and exchange of > information in RID messaging may include adherence to local, > regional, or national regulations in addition to the obligations to > protect client information during an investigation. RID Policy is a > necessary tool for listing the requirements of messages to provide a > method to categorize data elements for proper handling. Controls are > also provided for the sending entity to protect messages from third > parties through XML encryption. > > RID provides a method to exchange incident handling request and > Report messages to peer networks. Administrators have the ability to > base decisions on the available resources and other factors of their > network and maintain control of incident investigations within their > own network. Thus, RID provides the ability for participating > networks to manage their own security controls, leveraging the > information listed in RIDPolicy. > ************************** > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of kathleen= .moriarty@emc.com > [kathleen.moriarty@emc.com] > Sent: Wednesday, August 24, 2011 6:24 AM > To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > Cc: MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions > > Thank you Brian and Tony for the comments on the use of LawEnforement. I= t seems from these comments, > we should use only one indicator for this field, if others agree/disagree= , please post to the list. > > Tony suggests the use of "Authority". Is this more appropriate than "Law= Enforcement"? > > Also, Brian raised another question on an enumeration that is in RFC6045 = in RIDPolicy. Should > "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundaries"= or some other indicator for > this marker? > > I also agree that the contact information will be provided, so I think us= ing a more generic marker is > appropriate. Is there agreement/disagreement on this point? > > Next for the handling of data between countries where you get into privac= y considerations, safe > harbor, etc. I believe this will be handled in the extension on data mar= kings from Dr. Katherine > Goodier and Gaus Rajnovic. They should be able to match up any markers w= ith guidance on how to set > the IODEF:restriction appropriately for the various markers used so that = encryption can be > appropriately used at the RID layer with the new guidance. Could Katheri= ne and/or Gaus confirm? > > I had a little time and wrote up text to address the PKI questions from D= avid and will send those out > a little later. > > Thank you! > Kathleen > > ________________________________________ > From: Tony Rutkowski [tony@yaanatech.com] > Sent: Wednesday, August 24, 2011 6:09 AM > To: Brian Trammell > Cc: Moriarty, Kathleen; MILE@ietf.org > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discuss= ions > > I'd suggest that anything related to this subject be > kept as generic as possible. The capabilities being > supported are subject concurrently to many different > legal requirements that are global, regional, national, > sub-national, and local in nature. The authorities involved > consist of a great many kinds of government agencies, > including officers of a court in the case of eDiscovery and > other kinds of civil proceedings. > > The ETSI global eWarrant standards work ultimately > allowed for multiple generic terms for its interface, > as depicted in the diagram below. You should consider > the possibility of using only "authority." > > [cid:part1.09080503.05030907@yaanatech.com] > > > > > On 8/24/2011 11:57 AM, Brian Trammell wrote: > > I would generalize this to "across jurisdictional boundaries," though I a= m not exactly certain how. > For example, EU organizations in countries implementing EU data protectio= n directives are more free to > exchange data with each other than with organizations outside (and this i= n and of itself is subject to > exceptions, cf. "EU safe harbor" provisions, or operational exceptions fo= r network security > information). So, data could cross the German/Austrian border, for exampl= e, but be subject to far less > restriction than crossing the German/American border. > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From david.black@emc.com Wed Aug 24 10:40:25 2011 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 B280721F8C19 for ; Wed, 24 Aug 2011 10:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 XZ5hS5aufW-D for ; Wed, 24 Aug 2011 10:40:24 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id BB6DE21F8C15 for ; Wed, 24 Aug 2011 10:40:23 -0700 (PDT) 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 p7OHfYQa011933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 13:41:34 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 13:41:19 -0400 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 p7OHfIFb032593 for ; Wed, 24 Aug 2011 13:41:19 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 24 Aug 2011 13:41:18 -0400 From: To: , Date: Wed, 24 Aug 2011 13:41:15 -0400 Thread-Topic: Digital Signatures Thread-Index: AQHMYmQyl9Aikp3b3U6J0/WhE2rNMJUsCxXwgAAY1U+AAB7rQA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672B46@MX14A.corp.emc.com> References: , <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A3E@MX14A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {9C6274CF-0880-4C84-BC3C-47D1EF065CFB} x-cr-hashedpuzzle: BnfZ CEzU CV0r Cbps CmGP Cn2O EGoa EjIn Eum9 FpdF GocU HL5T H1AA IxVF Jf3a KOcz; 1; bQBpAGwAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {9C6274CF-0880-4C84-BC3C-47D1EF065CFB}; ZABhAHYAaQBkAC4AYgBsAGEAYwBrAEAAZQBtAGMALgBjAG8AbQA=; Wed, 24 Aug 2011 17:41:15 GMT;UgBFADoAIABEAGkAZwBpAHQAYQBsACAAUwBpAGcAbgBhAHQAdQByAGUAcwA= 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] Digital Signatures 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, 24 Aug 2011 17:40:25 -0000 More inline @ DLB> ... Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, August 24, 2011 12:21 PM > To: Black, David; MILE@ietf.org > Subject: RE: Digital Signatures > > Hello David, > > Thank you, again. > > I will keep my comments in-line to address your questions (and maybe rais= e one or two for the list). > > BTW, I also added RFC5275 as a reference for the use of group keys and as= sociated requirements. DLB> Are you sure? RFC 5275 is a KEK approach (symmetric key used to encryp= t symmetric key), DLB> whereas the "need-to-know" case for RID restriction describes encrypti= ng a symmetric key with DLB> a public (asymmetric) key. In CMS, I think you may be looking for the= KeyTransRecipientInfo DLB> Type (RFC 5652, Section 6.2.1), but I note that CMS is based on ASN.1,= not XML. > ________________________________________ > From: Black, David > Sent: Wednesday, August 24, 2011 10:33 AM > To: Moriarty, Kathleen; MILE@ietf.org > Subject: Digital Signatures > > Kathleen, > > This is looking good - I have a few questions about the number of signatu= res per > entity and what the signatures cover: > > > XML Digital Signature > > > > o The originator of the TraceRequest or Investigation request MUST > > use a detached signature to sign at least one of the original IP > > packets included in the RecordItem class data to provide > > authentication to all upstream participants in the trace of the > > origin. All IP packets provided by the originator may be signed, > > and additional packets added by upstream peers in the trace may b= e > > signed by the peer adding the data, while maintaining the IP > > packet and detached signature from the original requestor. This > > signature MUST be passed to all recipients of the TraceRequest. > > a) What exactly is covered by the signature? It looks like the signature > covers a RecordItem instance. > > Yes, it is the RecordItem as that is a way to utilize detached signatures= so that processing and > verification is possible. I added the following text to ensure this is c= lear: > > "It is important to note that only the IPPacket is signed at the RecordIt= em level. Since multiple > RecordItems may exist within an IODEF document and may originate from dif= ferent sources, the signature > is applied at the RecordItem level to enable the use of an XML detached s= ignature." > > For anyone following, if you look at an example of how a packet is repres= ented, it may help with the > clarification (example from RFC6045): > 450000522ad9 > 0000ff06c41fc0a801020a010102976d0050103e020810d9 > 4a1350021000ad6700005468616e6b20796f7520666f7220 > 6361726566756c6c792072656164696e6720746869732052 > 46432e0a > > > b) How many signatures are allowed per entity? Is it "exactly one", or i= s > a signature per packet (RecordItem instance) allowed? If the answer is > "exactly one signature", should the containing RecordData instance be sig= ned > instead of RecordItem? > > Actually, you want this at the RecordItem level in case other entities ad= d in more RecordItems so that > you can verify the signatures along the way using detached signatures. I= f you use RecordData and > additional information is added (more RecordItems), the signature breaks = for a detached signature. > You could switch to an enveloped signature, but then you would have to fo= llow the guidelines in the > specification to explicitly state what was signed (all possible, but not = as simple). > > I think it may be better to leave it at at least one if a packet is inclu= ded. DLB> That's fine - please make it explicit in the text that an entity may a= dd more than one signature DLB> up to a signature per RecordItem added by that entity. > > > > o If an Investigation request does not include an IP packet, the > > EventData class instance from each the parties involved in the > > investigation MUST be signed using a detached signature. The > > signature MUST only be applied to the data entered or added from > > each entity to provide a method of authentication on the work > > added by any party involved in the investigation. The EventData > > class can be used to extend information about an incident by each > > CSIRT or SP involved in the investigation. Using this class for > > the digital signature when an IP Packet is not included provides = a > > method to verify each party contributing to the details of the > > incident. > > c) Same question on what is covered by the signature, and in particular: = What > is supposed to be signed when EventData instances are nested? I would gu= ess > that the outermost instance should be signed. > > I have been thinking more about this and believe it would be better to ju= st bump this all up to a > RecordItem MUST be signed instead of packet to get around the problem whe= re there is no packet in an > incident. If no RecordItems exist, an NTP timestamp could be used for th= is purpose. If this is an > agreeable solution, I will make the text updates. DLB> I like this - collapsing the two cases to both sign individual RecordI= tem instances is a simplification. > d) Same question on number of signatures. Can a single entity add multip= le > independent (i.e., not nested) EventData instances? If not, then only on= e > signature is possible. > > e) Nit: in 4th line of quoted text: > > "applied to the data entered or added from each entity" -> "appli= ed to the > EventData instances originated or added by the signing entity" > > This avoids a possible misreading of that text to allow signing less than > a complete EventData instance. > > > o For all message types, the full IODEF/RID document MUST be signed > > using an enveloped signature by the sending peer to provide > > authentication and integrity to the receiving RID system. > > I can also add a note on the possible use of enveloped signatures over th= e entire document where > entities are interested in tracking what data came from what entity follo= wing the XML Digital > Signature guidance. As stated in the bullet listed above, RID just requi= res the sending peer to use > an enveloped signature for authentication/integrity. This additional usa= ge would be based on peer or > consortium agreements and makes sense as a good option to include (at lea= st to me) and I would like > other opinions. > > This is fine ;-). > > > Thanks, > Kathleen > > > > Thanks, > --David > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= kathleen.moriarty@emc.com > > Sent: Wednesday, August 24, 2011 9:43 AM > > To: MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions - Security > > Considerations > > > > Hello, > > > > As mentioned in the prior message, I updated the security consideration= s to address David's > concerns. > > The new text is provided below for ease of review. Please provide comm= ents on the new text, prior > > discussions in the thread, or any other items that come up in your revi= ew of RFC6045-bis. > > > > Here is the updated text for the first part of the security section: > > > > ************************** > > 7. Security Considerations > > > > RID has many security considerations built into the design of the > > protocol, several of which are described in the following sub- > > sections. For a complete view of security, considerations need to > > include the availability, confidentiality, and integrity concerns fo= r > > the transport, storage, and exchange of information. > > > > Authenticated encrypted tunnels between systems accepting RID > > communications MUST be used to provide confidentiality, integrity, > > authenticity, and privacy for the data. Encryption and digital > > signatures are also used at the IOEDF document level through RID > > options to provide confidentiality, integrity, authenticity, privacy > > and traceability of the document contents. Trust relationships are > > based on consortiums and established trust relationships of public > > key infrastructure (PKI) cross-certifications of consortiums. Trust > > levels can be established in cross-certification processes where > > entities compare PKI policies that include the specific management > > and handling of an entity's PKI and certificates issued under that > > policy. [RFC3647] defines an Internet X.509 Public Key > > Infrastructure Certificate Policy and Certification Practices > > Framework that may be used in the comparison of policies to establis= h > > trust levels and agreements between entities, an entity and a > > consortium, and consortia. The agreements SHOULD consider key > > management practices including the ability to perform path validatio= n > > on certificates [RFC5280], key distribution techniques [RFC2585], > > Certificate Authority and Registration Authority management > > practices. > > > > The agreements between entities SHOULD also include a common > > understanding of the usage of RID security, policy, and privacy > > options discussed in this section. The formality, requirements, and > > complexity of the agreements for the certificate policy, practices, > > and the use of RID options SHOULD be decided by the entities or > > consortiums creating those agreements. > > > > By using RIDPolicy information, TLS, and the XML security features o= f > > encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig], > > RID takes advantage of existing security standards. The standards > > provide clear methods to ensure that messages are secure, > > authenticated, and authorized, and that the messages meet policy and > > privacy guidelines and maintain integrity. > > > > As specified in the relevant sections of this document, the XML > > digital signature [RFC3275] and XML encryption [XMLencrypt] are used > > in the following cases: > > > > XML Digital Signature > > > > o The originator of the TraceRequest or Investigation request MUST > > use a detached signature to sign at least one of the original IP > > packets included in the RecordItem class data to provide > > authentication to all upstream participants in the trace of the > > origin. All IP packets provided by the originator may be signed, > > and additional packets added by upstream peers in the trace may b= e > > signed by the peer adding the data, while maintaining the IP > > packet and detached signature from the original requestor. This > > signature MUST be passed to all recipients of the TraceRequest. > > > > o If an Investigation request does not include an IP packet, the > > EventData class instance from each the parties involved in the > > investigation MUST be signed using a detached signature. The > > signature MUST only be applied to the data entered or added from > > each entity to provide a method of authentication on the work > > added by any party involved in the investigation. The EventData > > class can be used to extend information about an incident by each > > CSIRT or SP involved in the investigation. Using this class for > > the digital signature when an IP Packet is not included provides = a > > method to verify each party contributing to the details of the > > incident. > > > > o For all message types, the full IODEF/RID document MUST be signed > > using an enveloped signature by the sending peer to provide > > authentication and integrity to the receiving RID system. > > > > XML Encryption > > > > o 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. This behavio= r > > would be agreed upon between peers or a consortium, or determined > > on a per-message basis, depending on security requirements. It > > should be noted that there are cases for transport where the > > RIDPolicy class needs to be presented in clear text, as detailed > > in the transport document [RFC6046]. > > > > o An Investigation request, or any other message type that may be > > relayed through RID systems other than the intended destination a= s > > a result of trust relationships, may be encrypted for the intende= d > > recipient. This may be necessary if the RID network is being use= d > > for message transfer, the intermediate parties do not need to hav= e > > knowledge of the request contents, and a direct communication pat= h > > does not exist. In that case, the RIDPolicy class is used by > > intermediate parties and is maintained in clear text. > > > > o The action taken in the Result message may be encrypted using the > > key of the request originator. In that case, the intermediate > > parties can view the RIDPolicy information and know the trace has > > been completed and do not need to see the action. If the use of > > encryption were limited to sections of the message, the History > > class information would be encrypted. Otherwise, it is > > RECOMMENDED to encrypt the entire IODEF/RID document, using an > > enveloped signature, for the originator of the request. The > > existence of the Result message for an incident would tell any > > intermediate parties used in the path of the incident > > investigation that the incident handling has been completed. > > > > o The iodef:restriction attribute sets expectations for the privacy > > of an incident and is defined in section 3.2 of RFC5070. The > > restriction attribute can be set in any of the RID classes to > > define restrictions for the complete exchange of an IODEF documen= t > > (including any extensions) or within specific classes of IODEF or > > IODEF extensions where more limited restrictions are desired. Th= e > > restriction attribute is contained in each of the RID classes and > > MUST be used in accordance with privacy expectations for either > > sections of the IODEF document or the complete IODEF document. > > Consortiums and organizations should consider this guidance when > > creating exchange policies. > > > > o Expectations based on restriction setting: > > > > * If restriction is set to "private", the class or document MUST > > be encrypted for the recipient using XML encryption and the > > public key of the recipient. The use of PKI between entities > > SHOULD adhere to any applicable certificate policy and > > practices agreements for the use of RID. > > > > * If restriction is set to "need-to-know", the class or document > > MUST be encrypted to ensure only those with need-to-know acces= s > > can decrypt the data. The document can either be encrypted fo= r > > each individual for which access is intended or a single group > > key may be used. The method used SHOULD adhere to any > > certificate policy and practices agreements between entities > > for the use of RID. A group key in this instance refers to a > > single key (symmetric) that is used to encrypt the block of > > data. The users with need-to-know access privileges may be > > given access to the shared key by distributing or providing > > access to it encrypted with each of their public keys. > > > > * If restriction is set to "public", the class or document MUST > > be sent in clear text. This setting can be critical if certai= n > > sections of a document or an entire document are to be shared > > without restrictions. This provides flexibility within an > > incident to share out certain information freely where > > appropriate. > > > > * If restriction is set to "default", The information can be > > shared according to an information disclosure policy pre- > > arranged by the communicating parties. > > > > o Expectations based on placement of the restriction setting: > > > > * If restriction is set within one of the RID classes, the > > restriction applies to the entire IODEF document. > > > > * If restriction is set within individual IODEF classes, the > > restriction applies to the specific IODEF class and the > > children of that class. > > > > The formation of policies is a very important aspect of using a > > messaging system like RID to exchange potentially sensitive > > information. Many considerations should be involved for peering > > parties, and some guidelines to protect the data, systems, and > > transport are covered in this section. Policies established should > > provide guidelines for communication methods, security, and fall-bac= k > > procedures. > > > > The security considerations for the storage and exchange of > > information in RID messaging may include adherence to local, > > regional, or national regulations in addition to the obligations to > > protect client information during an investigation. RID Policy is a > > necessary tool for listing the requirements of messages to provide a > > method to categorize data elements for proper handling. Controls ar= e > > also provided for the sending entity to protect messages from third > > parties through XML encryption. > > > > RID provides a method to exchange incident handling request and > > Report messages to peer networks. Administrators have the ability t= o > > base decisions on the available resources and other factors of their > > network and maintain control of incident investigations within their > > own network. Thus, RID provides the ability for participating > > networks to manage their own security controls, leveraging the > > information listed in RIDPolicy. > > ************************** > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of kathle= en.moriarty@emc.com > > [kathleen.moriarty@emc.com] > > Sent: Wednesday, August 24, 2011 6:24 AM > > To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > > Cc: MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions > > > > Thank you Brian and Tony for the comments on the use of LawEnforement. = It seems from these > comments, > > we should use only one indicator for this field, if others agree/disagr= ee, please post to the list. > > > > Tony suggests the use of "Authority". Is this more appropriate than "L= awEnforcement"? > > > > Also, Brian raised another question on an enumeration that is in RFC604= 5 in RIDPolicy. Should > > "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundarie= s" or some other indicator > for > > this marker? > > > > I also agree that the contact information will be provided, so I think = using a more generic marker > is > > appropriate. Is there agreement/disagreement on this point? > > > > Next for the handling of data between countries where you get into priv= acy considerations, safe > > harbor, etc. I believe this will be handled in the extension on data m= arkings from Dr. Katherine > > Goodier and Gaus Rajnovic. They should be able to match up any markers= with guidance on how to set > > the IODEF:restriction appropriately for the various markers used so tha= t encryption can be > > appropriately used at the RID layer with the new guidance. Could Kathe= rine and/or Gaus confirm? > > > > I had a little time and wrote up text to address the PKI questions from= David and will send those > out > > a little later. > > > > Thank you! > > Kathleen > > > > ________________________________________ > > From: Tony Rutkowski [tony@yaanatech.com] > > Sent: Wednesday, August 24, 2011 6:09 AM > > To: Brian Trammell > > Cc: Moriarty, Kathleen; MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions > > > > I'd suggest that anything related to this subject be > > kept as generic as possible. The capabilities being > > supported are subject concurrently to many different > > legal requirements that are global, regional, national, > > sub-national, and local in nature. The authorities involved > > consist of a great many kinds of government agencies, > > including officers of a court in the case of eDiscovery and > > other kinds of civil proceedings. > > > > The ETSI global eWarrant standards work ultimately > > allowed for multiple generic terms for its interface, > > as depicted in the diagram below. You should consider > > the possibility of using only "authority." > > > > [cid:part1.09080503.05030907@yaanatech.com] > > > > > > > > > > On 8/24/2011 11:57 AM, Brian Trammell wrote: > > > > I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. > > For example, EU organizations in countries implementing EU data protect= ion directives are more free > to > > exchange data with each other than with organizations outside (and this= in and of itself is subject > to > > exceptions, cf. "EU safe harbor" provisions, or operational exceptions = for network security > > information). So, data could cross the German/Austrian border, for exam= ple, but be subject to far > less > > restriction than crossing the German/American border. > > > > > > _______________________________________________ > > mile mailing 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 Aug 25 06:05:47 2011 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 CECE921F8519 for ; Thu, 25 Aug 2011 06:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.305 X-Spam-Level: X-Spam-Status: No, score=-5.305 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFdqA0DWsDLD for ; Thu, 25 Aug 2011 06:05:38 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id CA60321F84DC for ; Thu, 25 Aug 2011 06:05:37 -0700 (PDT) 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 p7PD6o7J016058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 09:06:50 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 25 Aug 2011 09:06:37 -0400 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 p7PD6aDW016184; Thu, 25 Aug 2011 09:06:36 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Thu, 25 Aug 2011 09:06:36 -0400 From: To: , Date: Thu, 25 Aug 2011 09:06:35 -0400 Thread-Topic: Digital Signatures Thread-Index: AQHMYmQyl9Aikp3b3U6J0/WhE2rNMJUsCxXwgAAY1U+AAB7rQIABQxk3 Message-ID: References: , <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A3E@MX14A.corp.emc.com> , <7C4DFCE962635144B8FAE8CA11D0BF1E0589672B46@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672B46@MX14A.corp.emc.com> 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="_002_AE31510960917D478171C79369B660FA0E051CE82EMX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] Digital Signatures 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, 25 Aug 2011 13:05:47 -0000 --_002_AE31510960917D478171C79369B660FA0E051CE82EMX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Thank you to those who have provided comments so far on RFC6045-bis. The a= ttached version of RFC6045 addresses the comments and how they were agreed = to on the list. I temporarily removed the reference to RFC5275 and just li= sted an example of how one might distribute a shared key. RFC5275 does cov= er "groups to support distribution of encrypted content using symmetric cry= ptographic algorithms", which is relevant. I will look into this one issue= further. The outstanding items include: A change back to the RFC2119 key words (MUST instead of shall, etc.). The= ITU-T version of this will use shall and the terms normally used in that b= ody. Adding back in types of attacks section from RFC6045. Please review and provide any additional comments. The changes from RFC6045 are the following: 1. Text changes that do not change the context of the work per ITU-T edit = requests for ease of translation into other languages (would like the docum= ents to match). A few sections were dropped as there was not much added va= lue (from my perspective). The numbering of sections has also changed slig= htly. 2. Change of using a specific RecordItem instance of an IP Packet for the = authentication in the multi-hop use case. This allows for the multi-hop au= thentication to be possible in incident types that may not include an IP pa= cket (social engineering, etc.). This is required to support the new IODEF= extensions and types of exchanges requested ob the list. 3. Addition of the "LawEnforcement" enumeration. 4. Increased the specificity of guidance for the use of XML encryption and= digital signatures for each message type and int he security section. Als= o added a few more references for this purpose. 5. The option for a star topology to distribute RID messages as this would= be relevant for an organization/provider that would distribute incident re= ports to clients. Please post any comments or feedback to the list. Thank you! Kathleen ________________________________________ From: Black, David Sent: Wednesday, August 24, 2011 1:41 PM To: Moriarty, Kathleen; MILE@ietf.org Subject: RE: Digital Signatures More inline @ DLB> ... Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Wednesday, August 24, 2011 12:21 PM > To: Black, David; MILE@ietf.org > Subject: RE: Digital Signatures > > Hello David, > > Thank you, again. > > I will keep my comments in-line to address your questions (and maybe rais= e one or two for the list). > > BTW, I also added RFC5275 as a reference for the use of group keys and as= sociated requirements. DLB> Are you sure? RFC 5275 is a KEK approach (symmetric key used to encryp= t symmetric key), DLB> whereas the "need-to-know" case for RID restriction describes encrypti= ng a symmetric key with DLB> a public (asymmetric) key. In CMS, I think you may be looking for the= KeyTransRecipientInfo DLB> Type (RFC 5652, Section 6.2.1), but I note that CMS is based on ASN.1,= not XML. > ________________________________________ > From: Black, David > Sent: Wednesday, August 24, 2011 10:33 AM > To: Moriarty, Kathleen; MILE@ietf.org > Subject: Digital Signatures > > Kathleen, > > This is looking good - I have a few questions about the number of signatu= res per > entity and what the signatures cover: > > > XML Digital Signature > > > > o The originator of the TraceRequest or Investigation request MUST > > use a detached signature to sign at least one of the original IP > > packets included in the RecordItem class data to provide > > authentication to all upstream participants in the trace of the > > origin. All IP packets provided by the originator may be signed, > > and additional packets added by upstream peers in the trace may b= e > > signed by the peer adding the data, while maintaining the IP > > packet and detached signature from the original requestor. This > > signature MUST be passed to all recipients of the TraceRequest. > > a) What exactly is covered by the signature? It looks like the signature > covers a RecordItem instance. > > Yes, it is the RecordItem as that is a way to utilize detached signatures= so that processing and > verification is possible. I added the following text to ensure this is c= lear: > > "It is important to note that only the IPPacket is signed at the RecordIt= em level. Since multiple > RecordItems may exist within an IODEF document and may originate from dif= ferent sources, the signature > is applied at the RecordItem level to enable the use of an XML detached s= ignature." > > For anyone following, if you look at an example of how a packet is repres= ented, it may help with the > clarification (example from RFC6045): > 450000522ad9 > 0000ff06c41fc0a801020a010102976d0050103e020810d9 > 4a1350021000ad6700005468616e6b20796f7520666f7220 > 6361726566756c6c792072656164696e6720746869732052 > 46432e0a > > > b) How many signatures are allowed per entity? Is it "exactly one", or i= s > a signature per packet (RecordItem instance) allowed? If the answer is > "exactly one signature", should the containing RecordData instance be sig= ned > instead of RecordItem? > > Actually, you want this at the RecordItem level in case other entities ad= d in more RecordItems so that > you can verify the signatures along the way using detached signatures. I= f you use RecordData and > additional information is added (more RecordItems), the signature breaks = for a detached signature. > You could switch to an enveloped signature, but then you would have to fo= llow the guidelines in the > specification to explicitly state what was signed (all possible, but not = as simple). > > I think it may be better to leave it at at least one if a packet is inclu= ded. DLB> That's fine - please make it explicit in the text that an entity may a= dd more than one signature DLB> up to a signature per RecordItem added by that entity. > > > > o If an Investigation request does not include an IP packet, the > > EventData class instance from each the parties involved in the > > investigation MUST be signed using a detached signature. The > > signature MUST only be applied to the data entered or added from > > each entity to provide a method of authentication on the work > > added by any party involved in the investigation. The EventData > > class can be used to extend information about an incident by each > > CSIRT or SP involved in the investigation. Using this class for > > the digital signature when an IP Packet is not included provides = a > > method to verify each party contributing to the details of the > > incident. > > c) Same question on what is covered by the signature, and in particular: = What > is supposed to be signed when EventData instances are nested? I would gu= ess > that the outermost instance should be signed. > > I have been thinking more about this and believe it would be better to ju= st bump this all up to a > RecordItem MUST be signed instead of packet to get around the problem whe= re there is no packet in an > incident. If no RecordItems exist, an NTP timestamp could be used for th= is purpose. If this is an > agreeable solution, I will make the text updates. DLB> I like this - collapsing the two cases to both sign individual RecordI= tem instances is a simplification. > d) Same question on number of signatures. Can a single entity add multip= le > independent (i.e., not nested) EventData instances? If not, then only on= e > signature is possible. > > e) Nit: in 4th line of quoted text: > > "applied to the data entered or added from each entity" -> "appli= ed to the > EventData instances originated or added by the signing entity" > > This avoids a possible misreading of that text to allow signing less than > a complete EventData instance. > > > o For all message types, the full IODEF/RID document MUST be signed > > using an enveloped signature by the sending peer to provide > > authentication and integrity to the receiving RID system. > > I can also add a note on the possible use of enveloped signatures over th= e entire document where > entities are interested in tracking what data came from what entity follo= wing the XML Digital > Signature guidance. As stated in the bullet listed above, RID just requi= res the sending peer to use > an enveloped signature for authentication/integrity. This additional usa= ge would be based on peer or > consortium agreements and makes sense as a good option to include (at lea= st to me) and I would like > other opinions. > > This is fine ;-). > > > Thanks, > Kathleen > > > > Thanks, > --David > > > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= kathleen.moriarty@emc.com > > Sent: Wednesday, August 24, 2011 9:43 AM > > To: MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions - Security > > Considerations > > > > Hello, > > > > As mentioned in the prior message, I updated the security consideration= s to address David's > concerns. > > The new text is provided below for ease of review. Please provide comm= ents on the new text, prior > > discussions in the thread, or any other items that come up in your revi= ew of RFC6045-bis. > > > > Here is the updated text for the first part of the security section: > > > > ************************** > > 7. Security Considerations > > > > RID has many security considerations built into the design of the > > protocol, several of which are described in the following sub- > > sections. For a complete view of security, considerations need to > > include the availability, confidentiality, and integrity concerns fo= r > > the transport, storage, and exchange of information. > > > > Authenticated encrypted tunnels between systems accepting RID > > communications MUST be used to provide confidentiality, integrity, > > authenticity, and privacy for the data. Encryption and digital > > signatures are also used at the IOEDF document level through RID > > options to provide confidentiality, integrity, authenticity, privacy > > and traceability of the document contents. Trust relationships are > > based on consortiums and established trust relationships of public > > key infrastructure (PKI) cross-certifications of consortiums. Trust > > levels can be established in cross-certification processes where > > entities compare PKI policies that include the specific management > > and handling of an entity's PKI and certificates issued under that > > policy. [RFC3647] defines an Internet X.509 Public Key > > Infrastructure Certificate Policy and Certification Practices > > Framework that may be used in the comparison of policies to establis= h > > trust levels and agreements between entities, an entity and a > > consortium, and consortia. The agreements SHOULD consider key > > management practices including the ability to perform path validatio= n > > on certificates [RFC5280], key distribution techniques [RFC2585], > > Certificate Authority and Registration Authority management > > practices. > > > > The agreements between entities SHOULD also include a common > > understanding of the usage of RID security, policy, and privacy > > options discussed in this section. The formality, requirements, and > > complexity of the agreements for the certificate policy, practices, > > and the use of RID options SHOULD be decided by the entities or > > consortiums creating those agreements. > > > > By using RIDPolicy information, TLS, and the XML security features o= f > > encryption [XMLencrypt] and digital signatures [RFC3275], [XMLsig], > > RID takes advantage of existing security standards. The standards > > provide clear methods to ensure that messages are secure, > > authenticated, and authorized, and that the messages meet policy and > > privacy guidelines and maintain integrity. > > > > As specified in the relevant sections of this document, the XML > > digital signature [RFC3275] and XML encryption [XMLencrypt] are used > > in the following cases: > > > > XML Digital Signature > > > > o The originator of the TraceRequest or Investigation request MUST > > use a detached signature to sign at least one of the original IP > > packets included in the RecordItem class data to provide > > authentication to all upstream participants in the trace of the > > origin. All IP packets provided by the originator may be signed, > > and additional packets added by upstream peers in the trace may b= e > > signed by the peer adding the data, while maintaining the IP > > packet and detached signature from the original requestor. This > > signature MUST be passed to all recipients of the TraceRequest. > > > > o If an Investigation request does not include an IP packet, the > > EventData class instance from each the parties involved in the > > investigation MUST be signed using a detached signature. The > > signature MUST only be applied to the data entered or added from > > each entity to provide a method of authentication on the work > > added by any party involved in the investigation. The EventData > > class can be used to extend information about an incident by each > > CSIRT or SP involved in the investigation. Using this class for > > the digital signature when an IP Packet is not included provides = a > > method to verify each party contributing to the details of the > > incident. > > > > o For all message types, the full IODEF/RID document MUST be signed > > using an enveloped signature by the sending peer to provide > > authentication and integrity to the receiving RID system. > > > > XML Encryption > > > > o 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. This behavio= r > > would be agreed upon between peers or a consortium, or determined > > on a per-message basis, depending on security requirements. It > > should be noted that there are cases for transport where the > > RIDPolicy class needs to be presented in clear text, as detailed > > in the transport document [RFC6046]. > > > > o An Investigation request, or any other message type that may be > > relayed through RID systems other than the intended destination a= s > > a result of trust relationships, may be encrypted for the intende= d > > recipient. This may be necessary if the RID network is being use= d > > for message transfer, the intermediate parties do not need to hav= e > > knowledge of the request contents, and a direct communication pat= h > > does not exist. In that case, the RIDPolicy class is used by > > intermediate parties and is maintained in clear text. > > > > o The action taken in the Result message may be encrypted using the > > key of the request originator. In that case, the intermediate > > parties can view the RIDPolicy information and know the trace has > > been completed and do not need to see the action. If the use of > > encryption were limited to sections of the message, the History > > class information would be encrypted. Otherwise, it is > > RECOMMENDED to encrypt the entire IODEF/RID document, using an > > enveloped signature, for the originator of the request. The > > existence of the Result message for an incident would tell any > > intermediate parties used in the path of the incident > > investigation that the incident handling has been completed. > > > > o The iodef:restriction attribute sets expectations for the privacy > > of an incident and is defined in section 3.2 of RFC5070. The > > restriction attribute can be set in any of the RID classes to > > define restrictions for the complete exchange of an IODEF documen= t > > (including any extensions) or within specific classes of IODEF or > > IODEF extensions where more limited restrictions are desired. Th= e > > restriction attribute is contained in each of the RID classes and > > MUST be used in accordance with privacy expectations for either > > sections of the IODEF document or the complete IODEF document. > > Consortiums and organizations should consider this guidance when > > creating exchange policies. > > > > o Expectations based on restriction setting: > > > > * If restriction is set to "private", the class or document MUST > > be encrypted for the recipient using XML encryption and the > > public key of the recipient. The use of PKI between entities > > SHOULD adhere to any applicable certificate policy and > > practices agreements for the use of RID. > > > > * If restriction is set to "need-to-know", the class or document > > MUST be encrypted to ensure only those with need-to-know acces= s > > can decrypt the data. The document can either be encrypted fo= r > > each individual for which access is intended or a single group > > key may be used. The method used SHOULD adhere to any > > certificate policy and practices agreements between entities > > for the use of RID. A group key in this instance refers to a > > single key (symmetric) that is used to encrypt the block of > > data. The users with need-to-know access privileges may be > > given access to the shared key by distributing or providing > > access to it encrypted with each of their public keys. > > > > * If restriction is set to "public", the class or document MUST > > be sent in clear text. This setting can be critical if certai= n > > sections of a document or an entire document are to be shared > > without restrictions. This provides flexibility within an > > incident to share out certain information freely where > > appropriate. > > > > * If restriction is set to "default", The information can be > > shared according to an information disclosure policy pre- > > arranged by the communicating parties. > > > > o Expectations based on placement of the restriction setting: > > > > * If restriction is set within one of the RID classes, the > > restriction applies to the entire IODEF document. > > > > * If restriction is set within individual IODEF classes, the > > restriction applies to the specific IODEF class and the > > children of that class. > > > > The formation of policies is a very important aspect of using a > > messaging system like RID to exchange potentially sensitive > > information. Many considerations should be involved for peering > > parties, and some guidelines to protect the data, systems, and > > transport are covered in this section. Policies established should > > provide guidelines for communication methods, security, and fall-bac= k > > procedures. > > > > The security considerations for the storage and exchange of > > information in RID messaging may include adherence to local, > > regional, or national regulations in addition to the obligations to > > protect client information during an investigation. RID Policy is a > > necessary tool for listing the requirements of messages to provide a > > method to categorize data elements for proper handling. Controls ar= e > > also provided for the sending entity to protect messages from third > > parties through XML encryption. > > > > RID provides a method to exchange incident handling request and > > Report messages to peer networks. Administrators have the ability t= o > > base decisions on the available resources and other factors of their > > network and maintain control of incident investigations within their > > own network. Thus, RID provides the ability for participating > > networks to manage their own security controls, leveraging the > > information listed in RIDPolicy. > > ************************** > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of kathle= en.moriarty@emc.com > > [kathleen.moriarty@emc.com] > > Sent: Wednesday, August 24, 2011 6:24 AM > > To: tony@yaanatech.com; trammell@tik.ee.ethz.ch > > Cc: MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions > > > > Thank you Brian and Tony for the comments on the use of LawEnforement. = It seems from these > comments, > > we should use only one indicator for this field, if others agree/disagr= ee, please post to the list. > > > > Tony suggests the use of "Authority". Is this more appropriate than "L= awEnforcement"? > > > > Also, Brian raised another question on an enumeration that is in RFC604= 5 in RIDPolicy. Should > > "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundarie= s" or some other indicator > for > > this marker? > > > > I also agree that the contact information will be provided, so I think = using a more generic marker > is > > appropriate. Is there agreement/disagreement on this point? > > > > Next for the handling of data between countries where you get into priv= acy considerations, safe > > harbor, etc. I believe this will be handled in the extension on data m= arkings from Dr. Katherine > > Goodier and Gaus Rajnovic. They should be able to match up any markers= with guidance on how to set > > the IODEF:restriction appropriately for the various markers used so tha= t encryption can be > > appropriately used at the RID layer with the new guidance. Could Kathe= rine and/or Gaus confirm? > > > > I had a little time and wrote up text to address the PKI questions from= David and will send those > out > > a little later. > > > > Thank you! > > Kathleen > > > > ________________________________________ > > From: Tony Rutkowski [tony@yaanatech.com] > > Sent: Wednesday, August 24, 2011 6:09 AM > > To: Brian Trammell > > Cc: Moriarty, Kathleen; MILE@ietf.org > > Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions > > > > I'd suggest that anything related to this subject be > > kept as generic as possible. The capabilities being > > supported are subject concurrently to many different > > legal requirements that are global, regional, national, > > sub-national, and local in nature. The authorities involved > > consist of a great many kinds of government agencies, > > including officers of a court in the case of eDiscovery and > > other kinds of civil proceedings. > > > > The ETSI global eWarrant standards work ultimately > > allowed for multiple generic terms for its interface, > > as depicted in the diagram below. You should consider > > the possibility of using only "authority." > > > > [cid:part1.09080503.05030907@yaanatech.com] > > > > > > > > > > On 8/24/2011 11:57 AM, Brian Trammell wrote: > > > > I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. > > For example, EU organizations in countries implementing EU data protect= ion directives are more free > to > > exchange data with each other than with organizations outside (and this= in and of itself is subject > to > > exceptions, cf. "EU safe harbor" provisions, or operational exceptions = for network security > > information). So, data could cross the German/Austrian border, for exam= ple, but be subject to far > less > > restriction than crossing the German/American border. > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile --_002_AE31510960917D478171C79369B660FA0E051CE82EMX06Acorpemcc_ Content-Type: text/rtf; name="draft-moriarty-mile-rfc6045-bis-00.rtf" Content-Description: draft-moriarty-mile-rfc6045-bis-00.rtf Content-Disposition: attachment; filename="draft-moriarty-mile-rfc6045-bis-00.rtf"; size=163998; creation-date="Thu, 25 Aug 2011 09:04:42 GMT"; modification-date="Thu, 25 Aug 2011 09:04:42 GMT" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcY29jb2FydGYxMTM4XGNvY29hc3VicnRmMTAwCntcZm9u dHRibFxmMFxmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyO30Ke1xjb2xvcnRibDtccmVkMjU1XGdy ZWVuMjU1XGJsdWUyNTU7fQpcbWFyZ2wxNDQwXG1hcmdyMTQ0MFx2aWV3dzE3OTIwXHZpZXdoOTgw MFx2aWV3a2luZDAKXGRlZnRhYjcyMApccGFyZFxwYXJkZWZ0YWI3MjAKClxmMFxmczI2IFxjZjAg SW5kaXZpZHVhbCBTdWJtaXNzaW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEsuIE1vcmlhcnR5XApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFTUNcCkludGVuZGVkIHN0YXR1czogSW5mb3Jt YXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyNSwgMjAxMVwKRXhwaXJl czogRmVicnVhcnkgMjYsIDIwMTJcClwKXAogICAgICAgICAgICAgICAgIFJlYWwtdGltZSBJbnRl ci1uZXR3b3JrIERlZmVuc2UgKFJJRClcCiAgICAgICAgICAgICAgICAgZHJhZnQtbW9yaWFydHkt bWlsZS1yZmM2MDQ1LWJpcy0wMC50eHRcClwKQWJzdHJhY3RcClwKICAgVGhpcyBkb2N1bWVudCBw cm92aWRlcyBtaW5vciB1cGRhdGVzIHRvIFJlYWwtdGltZSBJbnRlci1uZXR3b3JrXAogICBEZWZl bnNlIChSSUQpIFtSRkM2MDQ1XS4gIE5ldHdvcmsgc2VjdXJpdHkgaW5jaWRlbnRzLCBzdWNoIGFz IHN5c3RlbVwKICAgY29tcHJvbWlzZXMsIHdvcm1zLCB2aXJ1c2VzLCBwaGlzaGluZyBpbmNpZGVu dHMsIGFuZCBkZW5pYWwgb2ZcCiAgIHNlcnZpY2UsIHR5cGljYWxseSByZXN1bHQgaW4gdGhlIGxv c3Mgb2Ygc2VydmljZSwgZGF0YSwgYW5kIHJlc291cmNlc1wKICAgYm90aCBodW1hbiBhbmQgc3lz dGVtLiAgTmV0d29yayBwcm92aWRlcnMgYW5kIENvbXB1dGVyIFNlY3VyaXR5XAogICBJbmNpZGVu dCBSZXNwb25zZSBUZWFtcyBuZWVkIHRvIGJlIGVxdWlwcGVkIGFuZCByZWFkeSB0byBhc3Npc3Qg aW5cCiAgIGNvbW11bmljYXRpbmcgYW5kIHRyYWNpbmcgc2VjdXJpdHkgaW5jaWRlbnRzIHdpdGgg dG9vbHMgYW5kXAogICBwcm9jZWR1cmVzIGluIHBsYWNlIGJlZm9yZSB0aGUgb2NjdXJyZW5jZSBv ZiBhbiBhdHRhY2suICBSZWFsLXRpbWVcCiAgIEludGVyLW5ldHdvcmsgRGVmZW5zZSAoUklEKSBv dXRsaW5lcyBhIHByb2FjdGl2ZSBpbnRlci1uZXR3b3JrXAogICBjb21tdW5pY2F0aW9uIG1ldGhv ZCB0byBmYWNpbGl0YXRlIHNoYXJpbmcgaW5jaWRlbnQgaGFuZGxpbmcgZGF0YVwKICAgd2hpbGUg aW50ZWdyYXRpbmcgZXhpc3RpbmcgZGV0ZWN0aW9uLCB0cmFjaW5nLCBzb3VyY2UgaWRlbnRpZmlj YXRpb24sXAogICBhbmQgbWl0aWdhdGlvbiBtZWNoYW5pc21zIGZvciBhIGNvbXBsZXRlIGluY2lk ZW50IGhhbmRsaW5nIHNvbHV0aW9uLlwKICAgQ29tYmluaW5nIHRoZXNlIGNhcGFiaWxpdGllcyBp biBhIGNvbW11bmljYXRpb24gc3lzdGVtIHByb3ZpZGVzIGEgd2F5XAogICB0byBhY2hpZXZlIGhp Z2hlciBzZWN1cml0eSBsZXZlbHMgb24gbmV0d29ya3MuICBQb2xpY3kgZ3VpZGVsaW5lcyBmb3Jc CiAgIGhhbmRsaW5nIGluY2lkZW50cyBhcmUgcmVjb21tZW5kZWQgYW5kIGNhbiBiZSBhZ3JlZWQg dXBvbiBieSBhXAogICBjb25zb3J0aXVtIHVzaW5nIHRoZSBzZWN1cml0eSByZWNvbW1lbmRhdGlv bnMgYW5kIGNvbnNpZGVyYXRpb25zLlwKXApTdGF0dXMgb2YgdGhpcyBNZW1vXApcCiAgIFRoaXMg SW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGVc CiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuXApcCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nXAogICBU YXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZVwKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC1cCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLlwKXAogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHNcCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55XAogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZVwKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg IndvcmsgaW4gcHJvZ3Jlc3MuIlwKXAogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJl IG9uIEZlYnJ1YXJ5IDI2LCAyMDEyLlwKXApDb3B5cmlnaHQgTm90aWNlXApcCiAgIENvcHlyaWdo dCAoYykgMjAxMSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZVwK XApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAg ICAgICAgICAgICAgIFtQYWdlIDFdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLlwKXAogICBUaGlzIGRvY3VtZW50 IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsXAogICBQcm92 aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzXAogICAoaHR0cDovL3RydXN0ZWUuaWV0 Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2ZcCiAgIHB1YmxpY2F0 aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50c1wKICAg Y2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMg d2l0aCByZXNwZWN0XAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJh Y3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdFwKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBM aWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mXAogICB0aGUgVHJ1c3Qg TGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXNcCiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS5cClwKXApUYWJsZSBvZiBD b250ZW50c1wKXAogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDRcCiAgICAgMS4xLiAgTm9ybWF0aXZlIGFuZCBJbmZv cm1hdGl2ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNVwKICAgICAxLjIuICBU ZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA2XAogICAyLiAgQ29tbXVuaWNhdGlvbiBiZXR3ZWVuIENTSVJUcyBhbmQgU2VydmljZSBQcm92 aWRlcnMgLiAuIC4gLiAuIC4gIDZcCiAgICAgMi4xLiAgSW50ZXItbmV0d29yayBQcm92aWRlciBS SUQgTWVzc2FnaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOFwKICAgICAyLjIuICBSSUQgQ29t bXVuaWNhdGlvbiBUb3BvbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwXAog ICAgIDIuMy4gIE1lc3NhZ2UgRm9ybWF0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTFcCiAgICAgMi40LiAgUklEIERhdGEgVHlwZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMVwKICAgICAgIDIuNC4xLiAgQm9vbGVhbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExXAogICAgIDIu NS4gIFJJRCBNZXNzYWdlIFR5cGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTFcCiAgIDMuICBJT0RFRi1SSUQgU2NoZW1hIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMlwKICAgICAzLjEuICBSSURQb2xpY3kgQ2xhc3MgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0XAogICAgIDMuMi4gIFJl cXVlc3RTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTlcCiAgICAgMy4zLiAgSW5jaWRlbnRTb3VyY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyMVwKICAgICAzLjQuICBSSUQgTmFtZSBTcGFjZXMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyXAogICA0LiAgUklEIE1lc3NhZ2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjJcCiAg ICAgNC4xLiAgVHJhY2VSZXF1ZXN0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyM1wKICAgICA0LjIuICBSZXF1ZXN0QXV0aG9yaXphdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0XAogICAgIDQuMy4gIFJlc3VsdCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjVcCiAgICAgNC40 LiAgSW52ZXN0aWdhdGlvbiBSZXF1ZXN0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyN1wKICAgICA0LjUuICBSZXBvcnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5XAogICAgIDQuNi4gIEluY2lkZW50UXVlcnkgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzBcCiAgIDUuICBSSUQgQ29t bXVuaWNhdGlvbiBFeGNoYW5nZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAz MVwKICAgICA1LjEuICBVcHN0cmVhbSBUcmFjZSBDb21tdW5pY2F0aW9uIEZsb3cgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDMxXAogICAgICAgNS4xLjEuICBSSUQgVHJhY2VSZXF1ZXN0IEV4YW1w bGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzNcCiAgICAgICA1LjEuMi4gIFJlcXVl c3RBdXRob3JpemF0aW9uIE1lc3NhZ2UgRXhhbXBsZSAuIC4gLiAuIC4gLiAuIC4gLiAzNlwKICAg ICAgIDUuMS4zLiAgUmVzdWx0IE1lc3NhZ2UgRXhhbXBsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDM3XAogICAgIDUuMi4gIEludmVzdGlnYXRpb24gUmVxdWVzdCBDb21tdW5pY2F0 aW9uIEZsb3cgLiAuIC4gLiAuIC4gLiAuIC4gNDBcCiAgICAgICA1LjIuMS4gIEludmVzdGlnYXRp b24gUmVxdWVzdCBFeGFtcGxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MVwKICAgICAgIDUu Mi4yLiAgUmVxdWVzdEF1dGhvcml6YXRpb24gTWVzc2FnZSBFeGFtcGxlIC4gLiAuIC4gLiAuIC4g LiAuIDQyXAogICAgIDUuMy4gIFJlcG9ydCBDb21tdW5pY2F0aW9uIEZsb3cgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDNcCiAgICAgICA1LjMuMS4gIFJlcG9ydCBFeGFtcGxlIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NFwKICAgICA1LjQuICBJbmNp ZGVudFF1ZXJ5IENvbW11bmljYXRpb24gRmxvdyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ1 XApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEy ICAgICAgICAgICAgICAgW1BhZ2UgMl1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAg ICAgIDUuNC4xLiAgSW5jaWRlbnRRdWVyeSBFeGFtcGxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDQ2XAogICA2LiAgUklEIFNjaGVtYSBEZWZpbml0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDdcCiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MVwKICAgICA3LjEu ICBNZXNzYWdlIFRyYW5zcG9ydCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDU1XAogICAgIDcuMi4gIE1lc3NhZ2UgRGVsaXZlcnkgUHJvdG9jb2wgLSBJbnRlZ3JpdHkg YW5kXAogICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNTVcCiAgICAgNy4zLiAgVHJhbnNwb3J0IENvbW11bmljYXRpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NlwKICAgICA3LjQuICBBdXRoZW50 aWNhdGlvbiBvZiBSSUQgUHJvdG9jb2wgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU3XAog ICAgICAgNy40LjEuICBNdWx0aS1Ib3AgVHJhY2VSZXF1ZXN0IEF1dGhlbnRpY2F0aW9uICAuIC4g LiAuIC4gLiAuIC4gNThcCiAgICAgNy41LiAgQ29uc29ydGl1bXMgYW5kIFB1YmxpYyBLZXkgSW5m cmFzdHJ1Y3R1cmVzIC4gLiAuIC4gLiAuIC4gLiA1OVwKICAgICA3LjYuICBQcml2YWN5IENvbmNl cm5zIGFuZCBTeXN0ZW0gVXNlIEd1aWRlbGluZXMgLiAuIC4gLiAuIC4gLiAuIDYwXAogICA4LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNjVcCiAgIDkuICBTdW1tYXJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NVwKICAgMTAuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY2XAogICAgIDEwLjEuIE5v cm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NjZcCiAgICAgMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA2N1wKICAgQXV0aG9yJ3MgQWRkcmVzcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY3XApcClwKXApcClwKXApcClwKXApc ClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcCk1vcmlhcnR5 ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgICBb UGFnZSAzXVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1i aXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAoxLiAgSW50cm9kdWN0aW9uXApc CiAgIFNpbmNlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIFJJRCBbUkZDNjA0NV0sIHRoZSBJbnRlcm5h dGlvbmFsXAogICBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24gKElUVSkgaGFzIGluY29ycG9yYXRl ZCBSRkM2MDQ1IGluIHRoZSBzZXQgb2ZcCiAgIHByb3RvY29scyBmb3IgQ3liZXJzZWN1cml0eSBF eGNoYW5nZSAoQ1lCRVgpIGluIFN0dWR5IEdyb3VwIDE3XAogICBleHBhbmRpbmcgdGhlIHVzZSBh bmQgaW50ZXJlc3QgaW4gdGhpcyB3b3JrLiAgRWRpdHMgcmVmbGVjdGVkIGluIHRoaXNcCiAgIHVw ZGF0ZWQgdmVyc2lvbiBvZiBSRkM2MDQ1IGFyZSBhIHJlZmxlY3Rpb24gb2YgdGhlIElUVS1UIHJl dmlldyBhbmRcCiAgIGZ1cnRoZXIgcmVjb21tZW5kYXRpb25zIGZyb20gSVRFRiBwYXJ0aWNpcGFu dHMuICBUaGUgc2NoZW1hIHJlbWFpbnNcCiAgIHRoZSBzYW1lIHdpdGggdGhlIGV4Y2VwdGlvbiBv ZiBhbiB1cGRhdGUgZm9yIGEgcHJldmlvdXNseSByZXBvcnRlZFwKICAgZXJyYXRhLiAgR3VpZGFu Y2UgaGFzIGltcHJvdmVkIGZvciB0aGUgaGFuZGxpbmcgb2YgcHJpdmFjeSBhbmQgb3RoZXJcCiAg IGRhdGEgbWFya2VycyB0byBlbnN1cmUgdGhlIGNvbnNpc3RlbnQgYXBwbGljYXRpb24gb2Ygc2Vj dXJpdHlcCiAgIGNvbnRyb2xzIGluIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMuXApcCiAgIE9y Z2FuaXphdGlvbnMgcmVxdWlyZSBoZWxwIGZyb20gb3RoZXIgcGFydGllcyB0byBpZGVudGlmeSBp bmNpZGVudHMsXAogICBtaXRpZ2F0ZSBtYWxpY2lvdXMgYWN0aXZpdHkgdGFyZ2V0aW5nIHRoZWly IGNvbXB1dGluZyByZXNvdXJjZXMsIGFuZFwKICAgdG8gZ2FpbiBpbnNpZ2h0IGludG8gcG90ZW50 aWFsIHRocmVhdHMgdGhyb3VnaCB0aGUgc2hhcmluZyBvZlwKICAgaW5mb3JtYXRpb24uICBUaGlz IGNvb3JkaW5hdGlvbiBtaWdodCBlbnRhaWwgd29ya2luZyB3aXRoIGEgc2VydmljZVwKICAgcHJv dmlkZXIgKFNQKSB0byBmaWx0ZXIgYXR0YWNrIHRyYWZmaWMsIHdvcmtpbmcgd2l0aCBhIFNQIHRv IHJlc29sdmVcCiAgIGEgY29uZmlndXJhdGlvbiBpc3N1ZSB1bmludGVudGlvbmFsbHkgY2F1c2lu ZyBwcm9ibGVtcywgY29udGFjdGluZyBhXAogICByZW1vdGUgc2l0ZSB0byB0YWtlIGRvd24gYSBi b3QtIG5ldHdvcmssIG9yIHNoYXJpbmcgd2F0Y2gtbGlzdHMgb2ZcCiAgIGtub3duIG1hbGljaW91 cyBJUCBhZGRyZXNzZXMgaW4gYSBjb25zb3J0aXVtLlwKXAogICBJbmNpZGVudCBoYW5kbGluZyBp bnZvbHZlcyB0aGUgZGV0ZWN0aW9uLCByZXBvcnRpbmcsIGlkZW50aWZpY2F0aW9uLFwKICAgYW5k IG1pdGlnYXRpb24gb2YgYW4gaW5jaWRlbnQsIHdoZXRoZXIgaXQgYmUgYSBiZW5pZ24gY29uZmln dXJhdGlvblwKICAgaXNzdWUsIElUIGluY2lkZW50LCBhbiBpbmZyYWN0aW9uIHRvIGEgc2Vydmlj ZSBsZXZlbCBhZ3JlZW1lbnQgKFNMQSksXAogICBzeXN0ZW0gY29tcHJvbWlzZSwgc29jaWFsbHkg ZW5naW5lZXJlZCBwaGlzaGluZyBhdHRhY2ssIG9yIGEgZGVuaWFsLVwKICAgb2Ytc2VydmljZSAo RG9TKSBhdHRhY2ssIGV0Yy4uICBXaGVuIGFuIGluY2lkZW50IGlzIGRldGVjdGVkLCB0aGVcCiAg IHJlc3BvbnNlIG1heSBpbmNsdWRlIHNpbXBseSBmaWxpbmcgYSByZXBvcnQsIG5vdGlmaWNhdGlv biB0byB0aGVcCiAgIHNvdXJjZSBvZiB0aGUgaW5jaWRlbnQsIGEgcmVxdWVzdCB0byBhIFNQIGZv ciByZXNvbHV0aW9uL21pdGlnYXRpb24sXAogICBvciBhIHJlcXVlc3QgdG8gbG9jYXRlIHRoZSBz b3VyY2UuICBPbmUgb2YgdGhlIG1vcmUgZGlmZmljdWx0IGNhc2VzXAogICBpcyB0aGF0IGluIHdo aWNoIHRoZSBzb3VyY2Ugb2YgYW4gYXR0YWNrIGlzIHVua25vd24sIHJlcXVpcmluZyB0aGVcCiAg IGFiaWxpdHkgdG8gdHJhY2UgdGhlIGF0dGFjayB0cmFmZmljIGl0ZXJhdGl2ZWx5IHVwc3RyZWFt IHRocm91Z2ggdGhlXAogICBuZXR3b3JrIGZvciB0aGUgcG9zc2liaWxpdHkgb2YgYW55IGZ1cnRo ZXIgYWN0aW9ucyB0byB0YWtlIHBsYWNlLiAgSW5cCiAgIGNhc2VzIHdoZW4gYWNjdXJhdGUgcmVj b3JkcyBvZiBhbiBhY3RpdmUgc2Vzc2lvbiBiZXR3ZWVuIHRoZSB0YXJnZXRcCiAgIG9yIHZpY3Rp bSBzeXN0ZW0gYW5kIHRoZSBzb3VyY2Ugb3IgYXR0YWNraW5nIHN5c3RlbSBhcmUgYXZhaWxhYmxl LFwKICAgdGhlIHNvdXJjZSBpcyBlYXN5IHRvIGlkZW50aWZ5LlwKXAogICBSZWFsLXRpbWUgaW50 ZXItbmV0d29yayBkZWZlbnNlIChSSUQpIG91dGxpbmVzIGEgcHJvYWN0aXZlIGludGVyLVwKICAg bmV0d29yayBjb21tdW5pY2F0aW9uIG1ldGhvZCB0byBmYWNpbGl0YXRlIHNoYXJpbmcgaW5jaWRl bnQgaGFuZGxpbmdcCiAgIGRhdGEgd2hpbGUgaW50ZWdyYXRpbmcgZXhpc3RpbmcgZGV0ZWN0aW9u LCB0cmFjaW5nLCBzb3VyY2VcCiAgIGlkZW50aWZpY2F0aW9uLCBhbmQgbWl0aWdhdGlvbiBtZWNo YW5pc21zIGZvciBhIGNvbXBsZXRlIGluY2lkZW50XAogICBoYW5kbGluZyBzb2x1dGlvbi4gIFJJ RCBwcm92aWRlcyBhIHNlY3VyZSBtZXRob2QgdG8gY29tbXVuaWNhdGVcCiAgIGluY2lkZW50IGlu Zm9ybWF0aW9uLCBlbmFibGluZyB0aGUgZXhjaGFuZ2Ugb2YgaW5jaWRlbnQgb2JqZWN0XAogICBk ZXNjcmlwdGlvbiBhbmQgZXhjaGFuZ2UgZm9ybWF0IChJT0RFRikgW1JGQzUwNzBdIGV4dGVuc2li bGUgbWFya3VwXAogICBsYW5ndWFnZSAoWE1MKSBkb2N1bWVudHMuICBSSUQgY29uc2lkZXJzIHNl Y3VyaXR5LCBwb2xpY3ksIGFuZFwKICAgcHJpdmFjeSBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgZXhj aGFuZ2Ugb2YgcG90ZW50aWFsbHkgc2Vuc2l0aXZlXAogICBpbmZvcm1hdGlvbiwgZW5hYmxpbmcg c2VydmljZSBwcm92aWRlcnMgb3Igb3JnYW5pemF0aW9ucyB0aGUgb3B0aW9uc1wKICAgdG8gbWFr ZSBhcHByb3ByaWF0ZSBkZWNpc2lvbnMgYWNjb3JkaW5nIHRvIHRoZWlyIHBvbGljaWVzLiAgUklE XApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEy ICAgICAgICAgICAgICAgW1BhZ2UgNF1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAg aW5jbHVkZXMgcHJvdmlzaW9ucyBmb3IgY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHksIGFuZFwK ICAgYXV0aGVudGljYXRpb24uXApcCiAgIFRoZSBkYXRhIGluIFJJRCBtZXNzYWdlcyBpcyByZXBy ZXNlbnRlZCBpbiBhbiBYTUwgW1hNTDEuMF0gZG9jdW1lbnRcCiAgIHVzaW5nIHRoZSBJT0RFRiBh bmQgUklELiAgQnkgZm9sbG93aW5nIHRoaXMgbW9kZWwsIGludGVncmF0aW9uIHdpdGhcCiAgIG90 aGVyIGFzcGVjdHMgZm9yIGluY2lkZW50IGhhbmRsaW5nIGlzIHNpbXBsaWZpZWQuICBNZXRob2Rz IGFyZVwKICAgaW5jb3Jwb3JhdGVkIGludG8gdGhlIGNvbW11bmljYXRpb24gc3lzdGVtIHRvIGlu ZGljYXRlIHdoYXQgYWN0aW9uc1wKICAgbmVlZCB0byBiZSB0YWtlbiBjbG9zZXN0IHRvIHRoZSBz b3VyY2UgaW4gb3JkZXIgdG8gaGFsdCBvciBtaXRpZ2F0ZVwKICAgdGhlIGVmZmVjdHMgb2YgdGhl IGluY2lkZW50IG9yIGF0dGFjayBhdCBoYW5kLiAgUklEIGlzIGludGVuZGVkIHRvXAogICBwcm92 aWRlIGEgbWV0aG9kIHRvIGNvbW11bmljYXRlIHRoZSByZWxldmFudCBpbmZvcm1hdGlvbiBiZXR3 ZWVuXAogICBjb21wdXRlciBzZWN1cml0eSBpbmNpZGVudCByZXNwb25zZSB0ZWFtcyAoQ1NJUlRz KSB3aGlsZSBiZWluZ1wKICAgY29tcGF0aWJsZSB3aXRoIGEgdmFyaWV0eSBvZiBleGlzdGluZyBh bmQgcG9zc2libGUgZnV0dXJlIGRldGVjdGlvblwKICAgdHJhY2luZyBhbmQgcmVzcG9uc2UgYXBw cm9hY2hlcy4gIEluY2lkZW50cyBtYXkgYmUgZXh0ZW5kZWQgdG9cCiAgIGluY2x1ZGUgSW5mb3Jt YXRpb24gVGVjaG5vbG9neSAoSVQpIGluY2lkZW50cywgd2hlcmUgUklEIGVuYWJsZXMgdGhlXAog ICBjb21tdW5pY2F0aW9uIGJldHdlZW4gb3Igd2l0aGluIHByb3ZpZGVycyBmb3Igbm9uLXNlY3Vy aXR5IElUXAogICBpbmNpZGVudHMuXApcCiAgIFNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbnNpZGVy YXRpb25zIGFyZSBvZiBoaWdoIGNvbmNlcm4gc2luY2VcCiAgIHBvdGVudGlhbGx5IHNlbnNpdGl2 ZSBpbmZvcm1hdGlvbiBtYXkgYmUgcGFzc2VkIHRocm91Z2ggUklEIG1lc3NhZ2VzLlwKICAgUklE IG1lc3NhZ2luZyB0YWtlcyBhZHZhbnRhZ2Ugb2YgWE1MIHNlY3VyaXR5IGFuZCBwcml2YWN5IHBv bGljeVwKICAgaW5mb3JtYXRpb24gc2V0IGluIHRoZSBSSUQgc2NoZW1hLiAgVGhlIFJJRCBzY2hl bWEgYWN0cyBhcyBhbiBYTUxcCiAgIGVudmVsb3BlIHRvIHN1cHBvcnQgdGhlIGNvbW11bmljYXRp b24gb2YgSU9ERUYgZG9jdW1lbnRzIGZvclwKICAgZXhjaGFuZ2luZyBvciB0cmFjaW5nIGluZm9y bWF0aW9uIHJlZ2FyZGluZyBpbmNpZGVudHMuICBSSUQgbWVzc2FnZXNcCiAgIGFyZSBlbmNhcHN1 bGF0ZWQgZm9yIHRyYW5zcG9ydCwgd2hpY2ggaXMgZGVmaW5lZCBpbiBhIHNlcGFyYXRlXAogICBk b2N1bWVudCBbUkZDNjA0Nl0gW1JGQzYwNDZdLiAgVGhlIGF1dGhlbnRpY2F0aW9uLCBpbnRlZ3Jp dHksIGFuZFwKICAgYXV0aG9yaXphdGlvbiBmZWF0dXJlcyBSSUQgYW5kIFJJRCB0cmFuc3BvcnQg b2ZmZXIgYXJlIHVzZWQgdG9cCiAgIGFjaGlldmUgYSBuZWNlc3NhcnkgbGV2ZWwgb2Ygc2VjdXJp dHkuXApcCiAgIENvb3JkaW5hdGluZyB3aXRoIG90aGVyIENTSVJUcyBpcyBub3Qgc3RyaWN0bHkg YSB0ZWNobmljYWwgcHJvYmxlbS5cCiAgIFRoZXJlIGFyZSBudW1lcm91cyBwcm9jZWR1cmFsLCB0 cnVzdCwgYW5kIGxlZ2FsIGNvbnNpZGVyYXRpb25zIHRoYXRcCiAgIG1pZ2h0IHByZXZlbnQgYW4g b3JnYW5pemF0aW9uIGZyb20gc2hhcmluZyBpbmZvcm1hdGlvbi4gIFJJRCBwcm92aWRlc1wKICAg aW5mb3JtYXRpb24gYW5kIG9wdGlvbnMgdGhhdCBjYW4gYmUgdXNlZCBieSBvcmdhbml6YXRpb25z IHdobyBtdXN0XAogICB0aGVuIGFwcGx5IHRoZWlyIG93biBwb2xpY2llcyBmb3Igc2hhcmluZyBp bmZvcm1hdGlvbi4gIE9yZ2FuaXphdGlvbnNcCiAgIG11c3QgZGV2ZWxvcCBwb2xpY2llcyBhbmQg cHJvY2VkdXJlcyBmb3IgdGhlIHVzZSBvZiB0aGUgUklEIHByb3RvY29sXAogICBhbmQgSU9ERUYu XApcCjEuMS4gIE5vcm1hdGl2ZSBhbmQgSW5mb3JtYXRpdmVcClwKICAgVGhlIFhNTCBzY2hlbWEg W1hNTHNjaGVtYV0gYW5kIHRyYW5zcG9ydCByZXF1aXJlbWVudHMgY29udGFpbmVkIGluXAogICB0 aGlzIGRvY3VtZW50IGFyZSBub3JtYXRpdmU7IGFsbCBvdGhlciBpbmZvcm1hdGlvbiBwcm92aWRl ZCBpc1wKICAgaW50ZW5kZWQgYXMgaW5mb3JtYXRpdmUuICBNb3JlIHNwZWNpZmljYWxseSwgdGhl IGZvbGxvd2luZyBzZWN0aW9uc1wKICAgb2YgdGhpcyBkb2N1bWVudCBhcmUgaW50ZW5kZWQgYXMg aW5mb3JtYXRpdmU6IFNlY3Rpb25zIDEsIDIsIGFuZCAzO1wKICAgYW5kIHRoZSBzdWItc2VjdGlv bnMgb2YgNCBpbmNsdWRpbmcgdGhlIGludHJvZHVjdGlvbiB0byA0LCA0LjEsIGFuZFwKICAgNC4y LiAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50IGFyZSBub3JtYXRpdmU6 IFRoZSBzdWItXAogICBzZWN0aW9ucyBvZiA0IGluY2x1ZGluZyA0LjMsIDQuNCwgYW5kIDQuNTsg U2VjdGlvbiA1OyBhbmQgU2VjdGlvbiA2LlwKXApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDVdXApc cGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAg ICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCjEuMi4gIFRlcm1pbm9sb2d5XApcCiAgIFRoZSBr ZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg Tk9UIixcCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzXAogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS5cClwKXAoyLiAgQ29tbXVuaWNhdGlvbiBiZXR3ZWVu IENTSVJUcyBhbmQgU2VydmljZSBQcm92aWRlcnNcClwKICAgTm90ZTogVGhlIEludHJvZHVjdGlv biwgYW5kIFN1Yi1zZWN0aW9ucyA0LjEgYW5kIDQuMiwgYXJlXAogICBpbmZvcm1hdGl2ZSwgd2l0 aCB0aGUgZXhjZXB0aW9uIG9mIHJlZmVyZW5jZXMgdG8gSU9ERUYvUklEIFRyYW5zcG9ydFwKICAg UkZDNjA0NiBbUkZDNjA0Nl0uICBTdWItc2VjdGlvbnMgNC4zLCA0LjQsIGFuZCA0LjUgYXJlIG5v cm1hdGl2ZS5cClwKICAgRXhwZWRpdGluZyB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIENTSVJU cyBhbmQgc2VydmljZSBwcm92aWRlcnNcCiAgIChTUCkgaXMgZXNzZW50aWFsIHdoZW4gcmVzcG9u ZGluZyB0byBhIHNlY3VyaXR5LXJlbGF0ZWQgaW5jaWRlbnQsXAogICB3aGljaCBtYXkgY3Jvc3Mg bmV0d29yayBhY2Nlc3MgcG9pbnRzIChJbnRlcm5ldCBiYWNrYm9uZXMgb3IgY2xvdWRcCiAgIGlu ZnJhc3RydWN0dXJlcykgYmV0d2VlbiBzZXJ2aWNlIG9yIG5ldHdvcmsgcHJvdmlkZXJzLiAgQXMg YSByZXN1bHRcCiAgIG9mIHRoZSB1cmdlbmN5IGludm9sdmVkIGluIHRoaXMgaW50ZXItc2Vydmlj ZSBwcm92aWRlciBzZWN1cml0eVwKICAgaW5jaWRlbnQgY29tbXVuaWNhdGlvbiwgdGhlcmUgbXVz dCBiZSBhbiBlZmZlY3RpdmUgc3lzdGVtIGluIHBsYWNlIHRvXAogICBmYWNpbGl0YXRlIHRoZSBp bnRlcmFjdGlvbi4gIFRoaXMgY29tbXVuaWNhdGlvbiBwb2xpY3kgb3IgbWV0aG9kXAogICBzaG91 bGQgaW52b2x2ZSBtdWx0aXBsZSBtZWFucyBvZiBjb21tdW5pY2F0aW9uIHRvIGF2b2lkIGEgc2lu Z2xlXAogICBwb2ludCBvZiBmYWlsdXJlLiAgRW1haWwgaXMgb25lIHdheSB0byB0cmFuc2ZlciBp bmZvcm1hdGlvbiBhYm91dCB0aGVcCiAgIGluY2lkZW50LCBwYWNrZXQgdHJhY2VzLCBldGMuICBI b3dldmVyLCBlbWFpbCBtYXkgbm90IGJlIHJlY2VpdmVkIGluXAogICBhIHRpbWVseSBmYXNoaW9u IG9yIGJlIGFjdGVkIHVwb24gd2l0aCB0aGUgc2FtZSB1cmdlbmN5IGFzIGEgcGhvbmVcCiAgIGNh bGwgb3Igb3RoZXIgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gbGlrZSBSSUQuXApcCiAgIEEgdGVj aG5pY2FsIHNvbHV0aW9uIHRvIHRyYWNlIHRyYWZmaWMgYWNyb3NzIGEgc2luZ2xlIHNlcnZpY2Ug b3JcCiAgIG5ldHdvcmsgcHJvdmlkZXIgbWF5IGluY2x1ZGUgaG9tZWdyb3duIG9yIGNvbW1lcmNp YWwgc3lzdGVtcyBmb3JcCiAgIHdoaWNoIFJJRCBtZXNzYWdpbmcgbXVzdCBhY2NvbW1vZGF0ZSB0 aGUgaW5wdXQgcmVxdWlyZW1lbnRzLiAgVGhlXAogICBpbmNpZGVudCBoYW5kbGluZyBzeXN0ZW0g dXNlZCBvbiB0aGUgc2VydmljZSBvciBuZXR3b3JrIHByb3ZpZGVyJ3NcCiAgIGJhY2tib25lIGJ5 IHRoZSBDU0lSVCB0byBjb29yZGluYXRlIHRoZSB0cmFjZSBhY3Jvc3MgdGhlIHNpbmdsZVwKICAg bmV0d29yayByZXF1aXJlcyBhIG1ldGhvZCB0byBhY2NlcHQgYW5kIHByb2Nlc3MgYW5kIHJlbGF5 IFJJRFwKICAgbWVzc2FnZXMgdG8gdGhlIHN5c3RlbSwgYXMgd2VsbCBhcyB0byB3YWl0IGZvciBy ZXNwb25zZXMgZnJvbSB0aGVcCiAgIHN5c3RlbSB0byBjb250aW51ZSB0aGUgUklEIHJlcXVlc3Qg cHJvY2VzcyBhcyBhcHByb3ByaWF0ZS4gIEluIHRoaXNcCiAgIHNjZW5hcmlvLCBlYWNoIHNlcnZp Y2Ugb3IgbmV0d29yayBwcm92aWRlciB3b3VsZCBtYWludGFpbiBpdHMgb3duXAogICBzeXN0ZW0g Y2FwYWJsZSBvZiBjb21tdW5pY2F0aW5nIHZpYSBSSUQgYW5kIGludGVncmF0ZSB3aXRoIGFcCiAg IG1hbmFnZW1lbnQgc3RhdGlvbiB1c2VkIGZvciBtb25pdG9yaW5nIGFuZCBhbmFseXNpcy4gIEFu IGFsdGVybmF0aXZlXAogICBmb3IgcHJvdmlkZXJzIGxhY2tpbmcgc3VmZmljaWVudCByZXNvdXJj ZXMgbWF5IGJlIHRvIGhhdmUgYSBuZXV0cmFsXAogICB0aGlyZCBwYXJ0eSB3aXRoIGFjY2VzcyB0 byB0aGUgcHJvdmlkZXIncyBuZXR3b3JrIHJlc291cmNlcyB3aG8gY291bGRcCiAgIGJlIHVzZWQg dG8gcGVyZm9ybSB0aGUgaW5jaWRlbnQgaGFuZGxpbmcgZnVuY3Rpb25zLiAgVGhpcyBjb3VsZCBi ZSBhXAogICBmdW5jdGlvbiBvZiBhIGNlbnRyYWwgb3JnYW5pemF0aW9uIG9wZXJhdGluZyBhcyBh IENTSVJUIGZvciBjb3VudHJpZXNcCiAgIGFzIGEgd2hvbGUgb3Igd2l0aGluIGEgY29uc29ydGl1 bSB0aGF0IG1heSBiZSBhYmxlIHRvIHByb3ZpZGVcCiAgIGNlbnRyYWxpemVkIHJlc291cmNlcy4g IEFuIGV4YW1wbGUgb2YgYSBjb25zb3J0aXVtIG1pZ2h0IGluY2x1ZGUgdGhlXAogICBjbG91ZCBz ZXJ2aWNlIHByb3ZpZGVycy5cClwKICAgQ29uc29ydGl1bXMgd291bGQgY29uc2lzdCBvZiBhIGdy b3VwIG9mIHNlcnZpY2UgKG5ldHdvcmssIGNsb3VkLFwKICAgZXRjLikgcHJvdmlkZXJzIGFuZC9v ciBDU0lSVHMgdGhhdCBhZ3JlZSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgUklEXAogICBjb21tdW5p Y2F0aW9uIHByb3RvY29sIHdpdGggYW4gYWdyZWVkLXVwb24gcG9saWN5IGFuZCBjb21tdW5pY2F0 aW9uXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAy MDEyICAgICAgICAgICAgICAgW1BhZ2UgNl1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwK ICAgcHJvdG9jb2wgZmFjaWxpdGF0aW5nIHRoZSBzZWN1cmUgdHJhbnNwb3J0IG9mIElPREVGL1JJ RCBYTUxcCiAgIGRvY3VtZW50cy4gIFRyYW5zcG9ydCBmb3IgUklEIG1lc3NhZ2VzIGlzIHNwZWNp ZmllZCBpbiB0aGUgSU9ERUYvUklEXAogICBUcmFuc3BvcnQgW1gucmlkZF0gUmVjb21tZW5kYXRp b24uXApcCiAgIE9uZSBnb2FsIG9mIFJJRCBpcyB0byBwcmV2ZW50IHRoZSBuZWVkIHRvIHBlcm1p dCBhY2Nlc3MgdG8gb3RoZXJcCiAgIG5ldHdvcmtzJyBlcXVpcG1lbnQgdGhyb3VnaCB0aGUgdXNl IG9mIGEgc3RhbmRhcmQgbWVzc2FnaW5nIG1lY2hhbmlzbVwKICAgdG8gZW5hYmxlIHRoZSBjb21t dW5pY2F0aW9uIG9mIGluY2lkZW50IGhhbmRsaW5nIGluZm9ybWF0aW9uIHRvIG90aGVyXAogICBw cm92aWRlcnMgaW4gYSBjb25zb3J0aXVtIG9yIGluIG5laWdoYm9yaW5nIG5ldHdvcmtzLiAgVGhl IHRoaXJkXAogICBwYXJ0eSBtZW50aW9uZWQgYWJvdmUgbWF5IGJlIHVzZWQgaW4gdGhpcyB0ZWNo bmljYWwgc29sdXRpb24gdG9cCiAgIGFzc2lzdCBpbiBmYWNpbGl0YXRpbmcgaW5jaWRlbnQgaGFu ZGxpbmcgYW5kIHBvc3NpYmx5IHRyYWNlYmFja1wKICAgdGhyb3VnaCBzbWFsbGVyIHByb3ZpZGVy cy4gIFRoZSBSSUQgbWVzc2FnaW5nIG1lY2hhbmlzbSBtYXkgYmUgYVwKICAgbG9naWNhbCBvciBw aHlzaWNhbCBvdXQtb2YtYmFuZCBuZXR3b3JrIHRvIGVuc3VyZSB0aGF0IHRoZVwKICAgY29tbXVu aWNhdGlvbiBpcyBzZWN1cmUgYW5kIHVuYWZmZWN0ZWQgYnkgdGhlIHN0YXRlIG9mIHRoZSBuZXR3 b3JrXAogICB1bmRlciBhdHRhY2suICBUaGUgdHdvIG1hbmFnZW1lbnQgbWV0aG9kcyB3b3VsZCBh Y2NvbW1vZGF0ZSB0aGUgbmVlZHNcCiAgIG9mIGxhcmdlciBwcm92aWRlcnMgdG8gbWFpbnRhaW4g ZnVsbCBtYW5hZ2VtZW50IG9mIHRoZWlyIG5ldHdvcmssIGFuZFwKICAgdGhlIHRoaXJkLXBhcnR5 IG9wdGlvbiBjb3VsZCBiZSBhdmFpbGFibGUgdG8gc21hbGxlciBwcm92aWRlcnMgd2hvXAogICBs YWNrIHRoZSBuZWNlc3NhcnkgaHVtYW4gcmVzb3VyY2VzIHRvIHBlcmZvcm0gaW5jaWRlbnQgaGFu ZGxpbmdcCiAgIG9wZXJhdGlvbnMuICBUaGUgZmlyc3QgbWV0aG9kIGVuYWJsZXMgdGhlIGluZGl2 aWR1YWwgcHJvdmlkZXJzIHRvXAogICBpbnZvbHZlIHRoZWlyIG5ldHdvcmsgb3BlcmF0aW9ucyBz dGFmZiB0byBhdXRob3JpemUgdGhlIGNvbnRpbnVhbmNlXAogICBvZiBhIHRyYWNlIG9yIG90aGVy IG5lY2Vzc2FyeSByZXNwb25zZSB0byBhIFJJRCBjb21tdW5pY2F0aW9uIHJlcXVlc3RcCiAgIHRo cm91Z2ggdGhlaXIgbmV0d29yayB2aWEgYSBub3RpZmljYXRpb24gYW5kIGFsZXJ0aW5nIHN5c3Rl bS5cClwKICAgVGhlIG5ldHdvcmsgdXNlZCBmb3IgdGhlIGNvbW11bmljYXRpb24gc2hvdWxkIGNv bnNpc3Qgb2Ygb3V0LW9mLWJhbmRcCiAgIG9yIHByb3RlY3RlZCBjaGFubmVscyAoZGlyZWN0IGNv bW11bmljYXRpb24gbGlua3MpIG9yIGVuY3J5cHRlZFwKICAgY2hhbm5lbHMgZGVkaWNhdGVkIHRv IHRoZSB0cmFuc3BvcnQgb2YgUklEIG1lc3NhZ2VzLiAgVGhlXAogICBjb21tdW5pY2F0aW9uIGxp bmtzIHdvdWxkIGJlIGRpcmVjdCBjb25uZWN0aW9ucyBiZXR3ZWVuIHBlZXJzIHdob1wKICAgaGF2 ZSBhZ3JlZWQtdXBvbiB1c2UgYW5kIGFidXNlIHBvbGljaWVzIHRocm91Z2ggYSBjb25zb3J0aXVt LlwKICAgQ29uc29ydGl1bXMgbWlnaHQgYmUgbGlua2VkIHRocm91Z2ggcG9saWN5IGNvbXBhcmlz b25zIGFuZCBhZGRpdGlvbmFsXAogICBhZ3JlZW1lbnRzIHRvIGZvcm0gYSBsYXJnZXIgd2ViIG9y IGl0ZXJhdGl2ZSBuZXR3b3JrIG9mIHBlZXJzIHRoYXRcCiAgIGNvcnJlbGF0ZXMgdG8gdGhlIHRy YWZmaWMgcGF0aHMgYXZhaWxhYmxlIG92ZXIgdGhlIGxhcmdlciB3ZWIgb2ZcCiAgIG5ldHdvcmtz IG9yIGJhc2VkIG9uIHJlZ2lvbnMgYW5kIGxvZ2ljYWwgZ3JvdXBzLiAgQ29udGFjdFwKICAgaW5m b3JtYXRpb24sIElQIGFkZHJlc3NlcyBvZiBSSUQgc3lzdGVtcywgYW5kIG90aGVyIGluZm9ybWF0 aW9uIG11c3RcCiAgIGJlIGNvb3JkaW5hdGVkIGJldHdlZW4gYmlsYXRlcmFsIHBlZXJzIGJ5IGEg Y29uc29ydGl1bSBhbmQgbWF5IHVzZVwKICAgZXhpc3RpbmcgZGF0YWJhc2VzLCBzdWNoIGFzIHRo ZSByb3V0aW5nIGFyYml0ZXIuICBUaGUgc2VjdXJpdHksXAogICBjb25maWd1cmF0aW9uLCBhbmQg Y29uZmlkZW5jZSByYXRpbmcgc2NoZW1lcyBvZiB0aGUgUklEIG1lc3NhZ2luZ1wKICAgcGVlcnMg bXVzdCBiZSBuZWdvdGlhdGVkIGJ5IHBlZXJzIGFuZCBtdXN0IG1lZXQgY2VydGFpbiBvdmVyYWxs XAogICByZXF1aXJlbWVudHMgb2YgdGhlIGZ1bGx5IGNvbm5lY3RlZCBuZXR3b3JrIChJbnRlcm5l dCwgZ292ZXJubWVudCxcCiAgIGVkdWNhdGlvbiwgZXRjLikgdGhyb3VnaCB0aGUgcGVlcmluZyBh bmQvb3IgYSBjb25zb3J0aXVtLWJhc2VkXAogICBhZ3JlZW1lbnQuXApcCiAgIFJJRCBtZXNzYWdp bmcgZXN0YWJsaXNoZWQgd2l0aCBjbGllbnRzIG9mIGFuIHByb3ZpZGVyIG1heSBiZVwKICAgbmVn b3RpYXRlZCBpbiBhIGNvbnRyYWN0IGFzIHBhcnQgb2YgYSB2YWx1ZS1hZGRlZCBzZXJ2aWNlIG9y IHRocm91Z2hcCiAgIGEgc2VydmljZSBsZXZlbCBhZ3JlZW1lbnQgKFNMQSkuICBGdXJ0aGVyIGRp c2N1c3Npb24gaXMgYmV5b25kIHRoZVwKICAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBhbmQgbWF5 IGJlIG1vcmUgYXBwcm9wcmlhdGVseSBoYW5kbGVkIGluXAogICBwZWVyaW5nIG9yIHNlcnZpY2Ug bGV2ZWwgYWdyZWVtZW50cy5cClwKICAgUHJvY2VkdXJlcyBmb3IgaW5jaWRlbnQgaGFuZGxpbmcg bmVlZCB0byBiZSBlc3RhYmxpc2hlZCBhbmQgd2VsbFwKICAga25vd24gYnkgYW55b25lIHRoYXQg bWF5IGJlIGludm9sdmVkIGluIGluY2lkZW50IHJlc3BvbnNlLiAgVGhlXApcClwKXApNb3JpYXJ0 eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICAg W1BhZ2UgN11cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUt YmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgcHJvY2VkdXJlcyBzaG91 bGQgYWxzbyBjb250YWluIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIGludGVybmFsXAogICBlc2Nh bGF0aW9uIHByb2NlZHVyZXMsIGFzIHdlbGwgYXMgZm9yIGV4dGVybmFsIGFzc2lzdGFuY2UgZ3Jv dXBzIHN1Y2hcCiAgIGFzIGEgQ1NJUlQsIENFUlQgQ29vcmRpbmF0aW9uIENlbnRlciAoQ0VSVC9D QyksIEdsb2JhbCBJbmZvcm1hdGlvblwKICAgQXNzdXJhbmNlIENlcnRpZmljYXRpb24gKEdJQUMp LCBhbmQgdGhlIEZCSSBvciBvdGhlciBhc3Npc3RpbmdcCiAgIGdvdmVybm1lbnQgb3JnYW5pemF0 aW9uIGluIHRoZSBjb3VudHJ5IG9mIHRoZSBpbnZlc3RpZ2F0aW9uLlwKXAoyLjEuICBJbnRlci1u ZXR3b3JrIFByb3ZpZGVyIFJJRCBNZXNzYWdpbmdcClwKICAgUklEIHByb3ZpZGVzIGEgc3RhbmRh cmQgcHJvdG9jb2wgYW5kIGZvcm1hdCBpcyByZXF1aXJlZCB0byBlbnN1cmVcCiAgIGludGVyLW9w ZXJhYmlsaXR5IGJldHdlZW4gdmVuZG9ycyBmb3IgdGhlIGltcGxlbWVudGF0aW9uIG9mIGFuXAog ICBpbmNpZGVudCBtZXNzYWdpbmcgbWVjaGFuaXNtLiAgVGhlIG1lc3NhZ2VzIHdvdWxkIGhhdmUg dG8gbWVldFwKICAgc2V2ZXJhbCByZXF1aXJlbWVudHMgaW4gb3JkZXIgdG8gYmUgbWVhbmluZ2Z1 bCBhcyB0aGV5IHRyYXZlcnNlXAogICBtdWx0aXBsZSBuZXR3b3Jrcy4gIFJJRCBwcm92aWRlcyB0 aGUgZnJhbWV3b3JrIG5lY2Vzc2FyeSBmb3JcCiAgIGNvbW11bmljYXRpb24gYmV0d2VlbiBuZXR3 b3JrcyBpbnZvbHZlZCBpbiB0aGUgaW5jaWRlbnQgaGFuZGxpbmcsXAogICBwb3NzaWJsZSB0cmFj ZWJhY2ssIGFuZCBtaXRpZ2F0aW9uIG9mIGEgc2VjdXJpdHkgaW5jaWRlbnQuICBTZXZlcmFsXAog ICBtZXNzYWdlIHR5cGVzIGRlc2NyaWJlZCBpbiBjbGF1c2UgOS4yIGFyZSBuZWNlc3NhcnkgdG8g ZmFjaWxpdGF0ZSB0aGVcCiAgIGhhbmRsaW5nIG9mIGEgc2VjdXJpdHkgaW5jaWRlbnQuICBUaGUg bWVzc2FnZSB0eXBlcyBpbmNsdWRlIHRoZVwKICAgUmVwb3J0LCBJbmNpZGVudFF1ZXJ5LCBUcmFj ZVJlcXVlc3QsIFJlcXVlc3RBdXRob3JpemF0aW9uLCBSZXN1bHQsXAogICBhbmQgdGhlIEludmVz dGlnYXRpb24gcmVxdWVzdCBtZXNzYWdlLlwKXAogICBUaGUgUmVwb3J0IG1lc3NhZ2UgaXMgdXNl ZCB3aGVuIGFuIGluY2lkZW50IGlzIHRvIGJlIGZpbGVkIG9uIGEgUklEXAogICBzeXN0ZW0gb3Ig YXNzb2NpYXRlZCBkYXRhYmFzZSwgd2hlcmUgbm8gZnVydGhlciBhY3Rpb24gaXMgcmVxdWlyZWQu XAogICBBbiBJbmNpZGVudFF1ZXJ5IG1lc3NhZ2UgaXMgdXNlZCB0byByZXF1ZXN0IGluZm9ybWF0 aW9uIG9uIGFcCiAgIHBhcnRpY3VsYXIgaW5jaWRlbnQuICBBIFRyYWNlUmVxdWVzdCBtZXNzYWdl IGlzIHVzZWQgd2hlbiB0aGUgc291cmNlXAogICBvZiB0aGUgdHJhZmZpYyBtYXkgaGF2ZSBiZWVu IHNwb29mZWQuICBJbiB0aGF0IGNhc2UsIGVhY2ggbmV0d29ya1wKICAgcHJvdmlkZXIgaW4gdGhl IHVwc3RyZWFtIHBhdGggd2hvIHJlY2VpdmVzIGEgVHJhY2VSZXF1ZXN0IHdpbGwgaXNzdWVcCiAg IGEgdHJhY2UgYWNyb3NzIHRoZSBuZXR3b3JrIHRvIGRldGVybWluZSB0aGUgdXBzdHJlYW0gc291 cmNlIG9mIHRoZVwKICAgdHJhZmZpYy4gIFRoZSBSZXF1ZXN0QXV0aG9yaXphdGlvbiBhbmQgUmVz dWx0IG1lc3NhZ2VzIGFyZSB1c2VkIHRvXAogICBjb21tdW5pY2F0ZSB0aGUgc3RhdHVzIGFuZCBy ZXN1bHQgb2YgYSBUcmFjZVJlcXVlc3Qgb3IgSW52ZXN0aWdhdGlvblwKICAgcmVxdWVzdC4gIFRo ZSBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgbWVzc2FnZSB3b3VsZCBvbmx5IGludm9sdmUgdGhlXAog ICBzeXN0ZW1zIGFjY2VwdGluZyBSSUQgY29tbXVuaWNhdGlvbiBhbG9uZyB0aGUgcGF0aCB0byB0 aGUgc291cmNlIG9mXAogICB0aGUgdHJhZmZpYyBhbmQgbm90IHRoZSB1c2Ugb2YgbmV0d29yayB0 cmFjZSBzeXN0ZW1zLiAgVGhlXAogICBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgbGV2ZXJhZ2VzIHRo ZSBiaWxhdGVyYWwgcmVsYXRpb25zaGlwcyBvciBhXAogICBjb25zb3J0aXVtJ3MgaW50ZXJjb25u ZWN0aW9ucyB0byBtaXRpZ2F0ZSBvciBzdG9wIHByb2JsZW1hdGljIHRyYWZmaWNcCiAgIGNsb3Nl IHRvIHRoZSBzb3VyY2UuICBSb3V0ZXMgY291bGQgZGV0ZXJtaW5lIHRoZSBmYXN0ZXN0IHBhdGgg dG8gYVwKICAga25vd24gc291cmNlIElQIGFkZHJlc3MgaW4gdGhlIGNhc2Ugb2YgYW4gSW52ZXN0 aWdhdGlvbiByZXF1ZXN0LiAgQVwKICAgbWVzc2FnZSBzZW50IGJldHdlZW4gUklEIHN5c3RlbXMg Zm9yIGEgVHJhY2VSZXF1ZXN0IG9yIGFuXAogICBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgdG8gc3Rv cCB0cmFmZmljIGF0IHRoZSBzb3VyY2UgdGhyb3VnaCBhXAogICBib3JkZXJpbmcgbmV0d29yayB3 b3VsZCByZXF1aXJlIHRoZSBpbmZvcm1hdGlvbiBlbnVtZXJhdGVkIGJlbG93OlwKXAogICAxLiAg RW5vdWdoIGluZm9ybWF0aW9uIHRvIGVuYWJsZSB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9ycyB0 byBtYWtlIGFcCiAgICAgICBkZWNpc2lvbiBhYm91dCB0aGUgaW1wb3J0YW5jZSBvZiBjb250aW51 aW5nIHRoZSB0cmFjZS5cClwKICAgMi4gIFRoZSBpbmNpZGVudCBvciBJUCBwYWNrZXQgaW5mb3Jt YXRpb24gbmVlZGVkIHRvIGNhcnJ5IG91dCB0aGVcCiAgICAgICB0cmFjZSBvciBpbnZlc3RpZ2F0 aW9uLlwKXAogICAzLiAgQ29udGFjdCBpbmZvcm1hdGlvbiBvZiB0aGUgb3JpZ2luIG9mIHRoZSBS SUQgY29tbXVuaWNhdGlvbi4gIFRoZVwKICAgICAgIGNvbnRhY3QgaW5mb3JtYXRpb24gY291bGQg YmUgcHJvdmlkZWQgdGhyb3VnaCB0aGUgQXV0b25vbW91c1wKXApcClwKTW9yaWFydHkgICAgICAg ICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDhd XApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAg ICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgICBTeXN0ZW0gTnVtYmVyIChBU04p IFtSRkMxOTMwXSBvciBOZXR3b3JrIEluZm9ybWF0aW9uIENlbnRlciAoTklDKVwKICAgICAgIGhh bmRsZSBpbmZvcm1hdGlvbiBsaXN0ZWQgaW4gdGhlIFJlZ2lzdHJ5IGZvciBJbnRlcm5ldCBOdW1i ZXJzIG9yXAogICAgICAgb3RoZXIgSW50ZXJuZXQgZGF0YWJhc2VzLlwKXAogICA0LiAgTmV0d29y ayBwYXRoIGluZm9ybWF0aW9uIHRvIGhlbHAgcHJldmVudCBhbnkgcm91dGluZyBsb29wc1wKICAg ICAgIHRocm91Z2ggdGhlIG5ldHdvcmsgZnJvbSBwZXJwZXR1YXRpbmcgYSB0cmFjZS4gIElmIGEg UklEIHN5c3RlbVwKICAgICAgIHJlY2VpdmVzIGEgVHJhY2VSZXF1ZXN0IGNvbnRhaW5pbmcgaXRz IG93biBpbmZvcm1hdGlvbiBpbiB0aGVcCiAgICAgICBwYXRoLCB0aGUgdHJhY2UgbXVzdCBjZWFz ZSBhbmQgdGhlIFJJRCBzeXN0ZW0gc2hvdWxkIGdlbmVyYXRlIGFuXAogICAgICAgYWxlcnQgdG8g aW5mb3JtIHRoZSBuZXR3b3JrIG9wZXJhdGlvbnMgc3RhZmYgdGhhdCBhIHRyYWNpbmcgbG9vcFwK ICAgICAgIGV4aXN0cy5cClwKICAgNS4gIEEgdW5pcXVlIGlkZW50aWZpZXIgZm9yIGEgc2luZ2xl IGF0dGFjay4gIFRoaXMgaWRlbnRpZmllciBzaG91bGRcCiAgICAgICBiZSB1c2VkIHRvIGNvcnJl bGF0ZSB0cmFjZXMgdG8gbXVsdGlwbGUgc291cmNlcyBpbiBhIEREb1MgYXR0YWNrLlwKXAogICBV c2Ugb2YgdGhlIGNvbW11bmljYXRpb24gbmV0d29yayBhbmQgdGhlIFJJRCBwcm90b2NvbCBtdXN0 IGJlIGZvclwKICAgcHJlLWFwcHJvdmVkLCBhdXRob3JpemVkIHB1cnBvc2VzIG9ubHkuICBJdCBp cyB0aGUgcmVzcG9uc2liaWxpdHkgb2ZcCiAgIGVhY2ggcGFydGljaXBhdGluZyBwYXJ0eSB0byBh ZGhlcmUgdG8gZ3VpZGVsaW5lcyBzZXQgZm9ydGggaW4gYm90aCBhXAogICBnbG9iYWwgdXNlIHBv bGljeSBlc3RhYmxpc2hlZCB0aHJvdWdoIHRoZSBwZWVyaW5nIGFncmVlbWVudHMgZm9yIGVhY2hc CiAgIGJpbGF0ZXJhbCBwZWVyIG9yIGFncmVlZC11cG9uIGNvbnNvcnRpdW0gZ3VpZGVsaW5lcy4g IFRoZSBwdXJwb3NlIG9mXAogICBzdWNoIHBvbGljaWVzIGlzIHRvIGF2b2lkIGFidXNlIG9mIHRo ZSBzeXN0ZW07IHRoZSBwb2xpY2llcyBzaGFsbCBiZVwKICAgZGV2ZWxvcGVkIGJ5IGEgY29uc29y dGl1bSBvZiBwYXJ0aWNpcGF0aW5nIGVudGl0aWVzLiAgVGhlIGdsb2JhbFwKICAgcG9saWN5IG1h eSBiZSBkZXBlbmRlbnQgb24gdGhlIGRvbWFpbiBpdCBvcGVyYXRlcyB1bmRlcjsgZm9yIGV4YW1w bGUsXAogICBhIGdvdmVybm1lbnQgbmV0d29yayBvciBhIGNvbW1lcmNpYWwgbmV0d29yayBzdWNo IGFzIHRoZSBJbnRlcm5ldFwKICAgd291bGQgYWRoZXJlIHRvIGRpZmZlcmVudCBndWlkZWxpbmVz IHRvIGFkZHJlc3MgdGhlIGluZGl2aWR1YWxcCiAgIGNvbmNlcm5zLiAgUHJpdmFjeSBpc3N1ZXMg bXVzdCBiZSBjb25zaWRlcmVkIGluIHB1YmxpYyBuZXR3b3JrcyBzdWNoXAogICBhcyB0aGUgSW50 ZXJuZXQuICBQcml2YWN5IGlzc3VlcyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBzZWN1cml0eVwKICAg Y29uc2lkZXJhdGlvbnMgY2xhdXNlLCBhbG9uZyB3aXRoIG90aGVyIHJlcXVpcmVtZW50cyB0aGF0 IG11c3QgYmVcCiAgIGFncmVlZCB1cG9uIGJ5IHBhcnRpY2lwYXRpbmcgZW50aXRpZXMuXApcCiAg IFJJRCByZXF1ZXN0cyBzaGFsbCBiZSBsZWdpdGltYXRlIGluY2lkZW50cyBhbmQgbm90IHVzZWQg Zm9yIHB1cnBvc2VzXAogICBzdWNoIGFzIHNhYm90YWdlIG9yIGNlbnNvcnNoaXAuICBBbiBleGFt cGxlIG9mIHN1Y2ggYWJ1c2Ugb2YgdGhlXAogICBzeXN0ZW0gd291bGQgaW5jbHVkZSBhIHJlcXVl c3QgdG8gcmF0ZS1saW1pdCBsZWdpdGltYXRlIHRyYWZmaWMgdG9cCiAgIHByZXZlbnQgaW5mb3Jt YXRpb24gZnJvbSBiZWluZyBzaGFyZWQgYmV0d2VlbiB1c2VycyBvbiB0aGUgSW50ZXJuZXRcCiAg IChyZXN0cmljdGluZyBhY2Nlc3MgdG8gb25saW5lIHZlcnNpb25zIG9mIHBhcGVycykgb3IgcmVz dHJpY3RpbmdcCiAgIGFjY2VzcyBmcm9tIGEgY29tcGV0aXRvcidzIHByb2R1Y3QgaW4gb3JkZXIg dG8gc2Fib3RhZ2UgYSBidXNpbmVzcy5cClwKICAgVGhlIFJJRCBzeXN0ZW0gc2hvdWxkIGJlIGNv bmZpZ3VyYWJsZSB0byBlaXRoZXIgcmVxdWlyZSB1c2VyIGlucHV0IG9yXAogICBhdXRvbWF0aWNh bGx5IGNvbnRpbnVlIHRyYWNlcy4gIFRoaXMgZmVhdHVyZSB3b3VsZCBlbmFibGUgYSBuZXR3b3Jr XAogICBtYW5hZ2VyIHRvIGFzc2VzcyB0aGUgYXZhaWxhYmxlIHJlc291cmNlcyBiZWZvcmUgY29u dGludWluZyBhblwKICAgaW52ZXN0aWdhdGlvbiBvciB0cmFjZS4gIElmIHRoZSBDb25maWRlbmNl IHJhdGluZyAocHJvdmlkZWQgaW4gSU9ERUYpXAogICBpcyBsb3csIGl0IG1heSBub3QgYmUgaW4g dGhlIHByb3ZpZGVyJ3MgYmVzdCBpbnRlcmVzdCB0byBjb250aW51ZSB0aGVcCiAgIGludmVzdGln YXRpb24gb3IgdHJhY2UuICBUaGUgQ29uZmlkZW5jZSByYXRpbmdzIG11c3QgYWRoZXJlIHRvIHRo ZVwKICAgc3BlY2lmaWNhdGlvbnMgZm9yIHNlbGVjdGluZyB0aGUgcGVyY2VudGFnZSB1c2VkIHRv IGF2b2lkIGFidXNlIG9mXAogICB0aGUgc3lzdGVtLiAgVHJhY2VSZXF1ZXN0cyBtdXN0IGJlIGlz c3VlZCBieSBhdXRob3JpemVkIGluZGl2aWR1YWxzXAogICBmcm9tIHRoZSBpbml0aWF0aW5nIENT SVJULCBzZXQgZm9ydGggaW4gcG9saWN5IGd1aWRlbGluZXMgZXN0YWJsaXNoZWRcCiAgIHRocm91 Z2ggcGVlcmluZyBvciBhIFNMQS5cClwKXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBF eHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgOV1cClxwYWdlIFwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDExXApcClwKMi4yLiAgUklEIENvbW11bmljYXRpb24gVG9wb2xvZ3lcClwK ICAgVGhlIG1vc3QgYmFzaWMgdG9wb2xvZ3kgZm9yIGNvbW11bmljYXRpbmcgUklEIHN5c3RlbXMg d291bGQgYmUgYVwKICAgZGlyZWN0IGNvbm5lY3Rpb24gb3IgYSBiaWxhdGVyYWwgcmVsYXRpb25z aGlwIGFzIGlsbHVzdHJhdGVkIGJlbG93LlwKXAogICAgICAgICAgICBfX19fX19fX19fXyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fXAogICAgICAgICAgICB8ICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8XAogICAg ICAgICAgICB8ICBSSUQgICAgfF9fX19fX19fX18tLS0tLS0tLS0tLS0tX19fX19fX19fX198ICBS SUQgICB8XAogICAgICAgICAgICB8X19fX19fX19ffCAgICAgICAgICB8IFNQIEJvcmRlciB8ICAg ICAgICAgICB8X19fX19fX198XAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0t LS0tLS0tLS0tXApcCiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogRGlyZWN0IFBlZXIg VG9wb2xvZ3lcClwKICAgV2l0aGluIHRoZSBjb25zb3J0aXVtIG1vZGVsLCBzZXZlcmFsIHRvcG9s b2dpZXMgbWlnaHQgYmUgYWdyZWVkIHVwb25cCiAgIGFuZCB1c2VkLiAgT25lIHdvdWxkIGxldmVy YWdlIGJpbGF0ZXJhbCBuZXR3b3JrIHBlZXJpbmcgcmVsYXRpb25zaGlwc1wKICAgb2YgdGhlIG1l bWJlcnMgb2YgdGhlIGNvbnNvcnRpdW0uICBUaGUgcGVlcnMgZm9yIFJJRCB3b3VsZCBtYXRjaCB0 aGF0XAogICBvZiByb3V0aW5nIHBlZXJzLCBhbmQgdGhlIGxvZ2ljYWwgbmV0d29yayBib3JkZXJz IHdvdWxkIGJlIHVzZWQuXAogICBUaGlzIGFwcHJvYWNoIG1heSBiZSBuZWNlc3NhcnkgZm9yIGFu IGl0ZXJhdGl2ZSB0cmFjZSB3aGVyZSB0aGVcCiAgIHNvdXJjZSBpcyB1bmtub3duLiAgVGhlIG1v ZGVsIHdvdWxkIGxvb2sgbGlrZSB0aGUgYWJvdmUgZGlhZ3JhbTtcCiAgIGhvd2V2ZXIsIHRoZXJl IG1heSBiZSBhbiBleHRlbnNpdmUgbnVtYmVyIG9mIGludGVyY29ubmVjdGlvbnMgb2ZcCiAgIGJp bGF0ZXJhbCByZWxhdGlvbnNoaXBzIGZvcm1lZC4gIEFsc28gd2l0aGluIGEgY29uc29ydGl1bSBt b2RlbCwgaXRcCiAgIG1heSBiZSB1c2VmdWwgdG8gZXN0YWJsaXNoIGFuIGludGVncmF0ZWQgbWVz aCBvZiBuZXR3b3JrcyB0byBwYXNzIFJJRFwKICAgbWVzc2FnZXMuICBUaGlzIG1heSBiZSBiZW5l ZmljaWFsIHdoZW4gdGhlIHNvdXJjZSBhZGRyZXNzIGlzIGtub3duLFwKICAgYW5kIGFuIGludGVy Y29ubmVjdGlvbiBtYXkgcHJvdmlkZSBhIGZhc3RlciByb3V0ZSB0byByZWFjaCB0aGVcCiAgIGNs b3Nlc3QgdXBzdHJlYW0gcGVlciB0byB0aGUgc291cmNlIG9mIHRoZSBhdHRhY2sgdHJhZmZpYyBp ZiBkaXJlY3RcCiAgIGNvbW11bmljYXRpb24gYmV0d2VlbiBTUHMgaXMgbm90IHBvc3NpYmxlLiAg QW4gZXhhbXBsZSBpcyBpbGx1c3RyYXRlZFwKICAgYmVsb3cuXApcCiAgICAgICBfX19fX19fICAg ICAgICAgICAgICAgICAgICAgX19fX19fXyAgICAgICAgICAgICAgICAgICAgIF9fX19fX19cCiAg ICAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwgICAgIHxcCiAgICAgX198IFJJRCB8X19fXy0tLS0tLS0tLS0tLS1fX19ffCBSSUQgfF9f X18tLS0tLS0tLS0tLS0tX19fX3wgUklEIHxfX1wKICAgICAgIHxfX19fX3wgICAgfCBTUCBCb3Jk ZXIgfCAgICB8X19fX198ICAgIHwgU1AgQm9yZGVyIHwgICAgfF9fX19ffFwKICAgICAgICAgIHwg ICAgICAgLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0gICAgICAgfFwK ICAgICAgICAgIHxfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19ffFwKXAogICAgICBEaXJlY3QgY29ubmVjdGlvbiB0byBuZXR3b3JrIHRoYXQgaXMg bm90IGFuIGltbWVkaWF0ZSBuZXR3b3JrIHBlZXJcClwKICAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgMjogTWVzaCBQZWVyIFRvcG9sb2d5XApcCiAgIEJ5IHVzaW5nIGEgZnVsbHkgbWVzaGVk IG1vZGVsIGluIGEgY29uc29ydGl1bSwgYnJvYWRjYXN0aW5nIFJJRFwKICAgcmVxdWVzdHMgd291 bGQgYmUgcG9zc2libGUsIGJ1dCBub3QgYWR2aXNhYmxlLiAgQnkgYnJvYWRjYXN0aW5nIGFcCiAg IHJlcXVlc3QsIFJJRCBwZWVycyB0aGF0IG1heSBub3QgaGF2ZSBjYXJyaWVkIHRoZSBhdHRhY2sg dHJhZmZpYyBvblwKICAgdGhlaXIgbmV0d29yayB3b3VsZCBiZSBhc2tlZCB0byBwZXJmb3JtIGEg dHJhY2UgZm9yIHRoZSBwb3RlbnRpYWwgb2ZcCiAgIGRlY3JlYXNpbmcgdGhlIHRpbWUgaW4gd2hp Y2ggdGhlIHRydWUgc291cmNlIHdhcyBpZGVudGlmaWVkLiAgQXMgYVwKICAgcmVzdWx0LCBtYW55 IG5ldHdvcmtzIHdvdWxkIGhhdmUgdXRpbGl6ZWQgdW5uZWNlc3NhcnkgcmVzb3VyY2VzIGZvciBh XAogICBUcmFjZVJlcXVlc3QgdGhhdCBtYXkgaGF2ZSBhbHNvIGJlZW4gdW5uZWNlc3NhcnkuXApc CiAgIEEgc3RhciB0b3BvbG9neSBtYXkgYmUgZGVzaXJhYmxlIGluIGluc3RhbmNlcyB3aGVyZSBh IHBlZXIgbWF5IGJlIGFcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDEwXVwKXHBhZ2UgXApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0 IDIwMTFcClwKXAogICBwcm92aWRlciBvZiBpbmNpZGVudCBpbmZvcm1hdGlvbi4gIFRoaXMgd291 bGQgcmVxdWlyZSB0cnVzdFwKICAgcmVsYXRpb25zaGlwcyB0byBiZSBlc3RhYmxpc2hlZCBiZXR3 ZWVuIHRoZSBwcm92aWRlciBvZiBpbmZvcm1hdGlvblwKICAgYW5kIGVhY2ggb2YgdGhlIGNvbnN1 bWVycyBvZiB0aGF0IGluZm9ybWF0aW9uLiAgRXhhbXBsZXMgbWF5IGluY2x1ZGVcCiAgIGNvdW50 cnkgbGV2ZWwgQ1NJUlRzIG9yIHNlcnZpY2UgcHJvdmlkZXJzIGRpc3RyaWJ1dGluZyBpbmNpZGVu dFwKICAgaW5mb3JtYXRpb24gdG8gb3JnYW5pemF0aW9ucy5cClwKMi4zLiAgTWVzc2FnZSBGb3Jt YXRzXApcCiAgIFNlY3Rpb24gNC4zLjIgZGVzY3JpYmVzIHRoZSBzaXggUklEIG1lc3NhZ2UgdHlw ZXMsIHdoaWNoIGxldmVyYWdlIHRoZVwKICAgSU9ERUYgbW9kZWwgW1JGQzUwNzBdLiAgVGhlIG1l c3NhZ2VzIGFyZSBnZW5lcmF0ZWQgYW5kIHJlY2VpdmVkIG9uXAogICBkZXNpZ25hdGVkIHN5c3Rl bXMgZm9yIFJJRCBjb21tdW5pY2F0aW9uIG9uIHRoZSBwcm92aWRlcidzIG5ldHdvcmsuXAogICBU aGUgbWVzc2FnZXMgbWF5IG9yaWdpbmF0ZSBmcm9tIElPREVGIGRvY3VtZW50cyBmcm9tIGludHJ1 c2lvblwKICAgZGV0ZWN0aW9uIHNlcnZlcnMsIENTSVJUcywgYW5hbHlzdHMsIGV0Yy4gIEEgUklE IG1lc3NhZ2UgdXNlcyB0aGVcCiAgIElPREVGIGRvY3VtZW50IHdpdGggdGhlIFJJRCBleHRlbnNp b24sIHdoaWNoIGlzIGVuY2Fwc3VsYXRlZCBmb3JcCiAgIHRyYW5zcG9ydCBbUkZDNjA0Nl0uICBF YWNoIFJJRCBtZXNzYWdlIHR5cGUsIGFsb25nIHdpdGggYW4gZXhhbXBsZSxcCiAgIGlzIGRlc2Ny aWJlZCBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLiAgVGhlIElPREVGLVJJRCBzY2hlbWEgaXNc CiAgIGludHJvZHVjZWQgaW4gU2VjdGlvbiA5IHRvIHN1cHBvcnQgdGhlIFJJRCBtZXNzYWdlIHR5 cGVzIGluIGNsYXVzZVwKICAgOC4yLiAgVGhlIHRlcm0gc2VydmljZSBwcm92aWRlciAoU1ApLCB1 c2VkIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnNcCiAgIHNob3VsZCBiZSBpbnRlcnByZXRlZCBh cyBhbnkgdHlwZSBvZiBzZXJ2aWNlIHByb3ZpZGVyIG9yIENTSVJUIHRoYXRcCiAgIG1heSBiZSBp bnZvbHZlZCBpbiBSSUQgY29tbXVuaWNhdGlvbnMuXApcCjIuNC4gIFJJRCBEYXRhIFR5cGVzXApc CiAgIFJJRCBpcyBkZXJpdmVkIGZyb20gdGhlIElPREVGIGRhdGEgbW9kZWwgYW5kIGluaGVyaXRz IGFsbCBvZiB0aGUgZGF0YVwKICAgdHlwZXMgZGVmaW5lZCBpbiB0aGUgSU9ERUYgbW9kZWwuICBP bmUgZGF0YSB0eXBlIGlzIGFkZGVkIGJ5IFJJRDpcCiAgIEJPT0xFQU4uXApcCjIuNC4xLiAgQm9v bGVhblwKXAogICBBIGJvb2xlYW4gdmFsdWUgaXMgcmVwcmVzZW50ZWQgYnkgdGhlIEJPT0xFQU4g ZGF0YSB0eXBlLlwKXAogICBUaGUgQk9PTEVBTiBkYXRhIHR5cGUgaXMgaW1wbGVtZW50ZWQgYXMg InhzOmJvb2xlYW4iIFtYTUxzY2hlbWFdIGluXAogICB0aGUgc2NoZW1hLlwKXAoyLjUuICBSSUQg TWVzc2FnZSBUeXBlc1wKXAogICBUaGUgc2l4IFJJRCBtZXNzYWdlIHR5cGVzIGFyZSBhcyBmb2xs b3dzOlwKXAogICAxLiAgVHJhY2VSZXF1ZXN0LiAgVGhpcyBtZXNzYWdlIGlzIHNlbnQgdG8gdGhl IG5leHQgcHJvdmlkZXIgaW4gdGhlXAogICAgICAgdXBzdHJlYW0gdHJhY2UuICBJdCBpcyB1c2Vk IHRvIGluaXRpYXRlIGEgVHJhY2VSZXF1ZXN0IG9yIHRvXAogICAgICAgY29udGludWUgYSBUcmFj ZVJlcXVlc3QgdG8gYW4gdXBzdHJlYW0gcHJvdmlkZXIgY2xvc2VyIHRvIHRoZVwKICAgICAgIHNv dXJjZSBhZGRyZXNzIG9mIHRoZSBvcmlnaW4gb2YgdGhlIHNlY3VyaXR5IGluY2lkZW50LiAgVGhl XAogICAgICAgVHJhY2VSZXF1ZXN0IHdvdWxkIHRyaWdnZXIgYSB0cmFjZWJhY2sgb24gdGhlIG5l dHdvcmsgdG8gbG9jYXRlXAogICAgICAgdGhlIHNvdXJjZSBvZiB0aGUgYXR0YWNrIHRyYWZmaWMu XApcCiAgIDIuICBSZXF1ZXN0QXV0aG9yaXphdGlvbi4gIFRoaXMgbWVzc2FnZSBpcyBzZW50IHRv IHRoZSBpbml0aWF0aW5nIFJJRFwKICAgICAgIHN5c3RlbSBmcm9tIGVhY2ggb2YgdGhlIHVwc3Ry ZWFtIHByb3ZpZGVycycgUklEIHN5c3RlbXMgdG9cCiAgICAgICBwcm92aWRlIGluZm9ybWF0aW9u IG9uIHRoZSByZXF1ZXN0IHN0YXR1cyBpbiB0aGUgY3VycmVudCBuZXR3b3JrLlwKXApcClwKTW9y aWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAg ICAgW1BhZ2UgMTFdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2 MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIDMuICBSZXN1bHQu ICBUaGlzIG1lc3NhZ2UgaXMgc2VudCB0byB0aGUgaW5pdGlhdGluZyBDU0lSVCB0aHJvdWdoIHRo ZVwKICAgICAgIG5ldHdvcmsgb2YgUklEIHN5c3RlbXMgaW4gdGhlIHBhdGggb2YgdGhlIHRyYWNl IGFzIG5vdGlmaWNhdGlvblwKICAgICAgIHRoYXQgdGhlIHNvdXJjZSBvZiB0aGUgYXR0YWNrIHdh cyBsb2NhdGVkLiAgVGhlIFJlc3VsdCBtZXNzYWdlIGlzXAogICAgICAgYWxzbyB1c2VkIHRvIHBy b3ZpZGUgdGhlIG5vdGlmaWNhdGlvbiBvZiBhY3Rpb25zIHRha2VuIGZvciBhblwKICAgICAgIElu dmVzdGlnYXRpb24gcmVxdWVzdC5cClwKICAgNC4gIEludmVzdGlnYXRpb24uICBUaGlzIG1lc3Nh Z2UgdHlwZSBpcyB1c2VkIHdoZW4gdGhlIHNvdXJjZSBvZiB0aGVcCiAgICAgICB0cmFmZmljIGlz IGJlbGlldmVkIG5vdCB0byBiZSBzcG9vZmVkLiAgVGhlIHB1cnBvc2Ugb2YgdGhlXAogICAgICAg SW52ZXN0aWdhdGlvbiByZXF1ZXN0IG1lc3NhZ2UgaXMgdG8gbGV2ZXJhZ2UgdGhlIGV4aXN0aW5n IHBlZXJcCiAgICAgICByZWxhdGlvbnNoaXBzIGluIG9yZGVyIHRvIG5vdGlmeSB0aGUgbmV0d29y ayBwcm92aWRlciBjbG9zZXN0IHRvXAogICAgICAgdGhlIHNvdXJjZSBvZiB0aGUgdmFsaWQgdHJh ZmZpYyBvZiBhIHNlY3VyaXR5LXJlbGF0ZWQgaW5jaWRlbnRcCiAgICAgICBmb3IgYW55IG5lY2Vz c2FyeSBhY3Rpb25zIHRvIGJlIHRha2VuLlwKXAogICA1LiAgUmVwb3J0LiAgVGhpcyBtZXNzYWdl IGlzIHVzZWQgdG8gcmVwb3J0IGEgc2VjdXJpdHkgaW5jaWRlbnQsIGZvclwKICAgICAgIHdoaWNo IG5vIGFjdGlvbiBpcyByZXF1ZXN0ZWQuICBUaGlzIG1heSBiZSB1c2VkIGZvciB0aGUgcHVycG9z ZVwKICAgICAgIG9mIGNvcnJlbGF0aW5nIGF0dGFjayBpbmZvcm1hdGlvbiBieSBDU0lSVHMsIHNo YXJpbmcgaW5jaWRlbnRcCiAgICAgICBpbmZvcm1hdGlvbiwgc3RhdGlzdGljcyBhbmQgdHJlbmRp bmcgaW5mb3JtYXRpb24sIGV0Yy5cClwKICAgNi4gIEluY2lkZW50UXVlcnkuICBUaGlzIG1lc3Nh Z2UgaXMgdXNlZCB0byByZXF1ZXN0IGluZm9ybWF0aW9uIGFib3V0XAogICAgICAgYW4gaW5jaWRl bnQgb3IgaW5jaWRlbnQgdHlwZSBmcm9tIGEgdHJ1c3RlZCBzeXN0ZW0gY29tbXVuaWNhdGluZ1wK ICAgICAgIHZpYSBSSUQuICBUaGUgcmVzcG9uc2UgaXMgcHJvdmlkZWQgdGhyb3VnaCB0aGUgUmVw b3J0IG1lc3NhZ2UuXApcCiAgIFdoZW4gYW4gYXBwbGljYXRpb24gcmVjZWl2ZXMgYSBSSUQgbWVz c2FnZSwgaXQgbXVzdCBiZSBhYmxlIHRvXAogICBkZXRlcm1pbmUgdGhlIHR5cGUgb2YgbWVzc2Fn ZSBhbmQgcGFyc2UgaXQgYWNjb3JkaW5nbHkuICBUaGUgbWVzc2FnZVwKICAgdHlwZSBpcyBzcGVj aWZpZWQgaW4gdGhlIFJJRFBvbGljeSBjbGFzcy4gIFRoZSBSSURQb2xpY3kgY2xhc3MgbWF5XAog ICBhbHNvIGJlIHVzZWQgYnkgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCB0byBmYWNpbGl0YXRlIHRo ZVwKICAgY29tbXVuaWNhdGlvbiBvZiBzZWN1cml0eSBpbmNpZGVudCBkYXRhIHRvIHRyYWNlLCBp bnZlc3RpZ2F0ZSwgcXVlcnksXAogICBvciByZXBvcnQgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHNl Y3VyaXR5IGluY2lkZW50cy5cClwKXAozLiAgSU9ERUYtUklEIFNjaGVtYVwKXAogICBUaGVyZSBh cmUgdGhyZWUgY2xhc3NlcyBpbmNsdWRlZCBpbiB0aGUgUklEIGV4dGVuc2lvbiByZXF1aXJlZCB0 b1wKICAgZmFjaWxpdGF0ZSBSSUQgY29tbXVuaWNhdGlvbnMuICBUaGUgUmVxdWVzdFN0YXR1cyBj bGFzcyBpcyB1c2VkIHRvXAogICBpbmRpY2F0ZSB0aGUgYXBwcm92YWwgc3RhdHVzIG9mIGEgVHJh Y2VSZXF1ZXN0IG9yIEludmVzdGlnYXRpb25cCiAgIHJlcXVlc3Q7IHRoZSBJbmNpZGVudFNvdXJj ZSBjbGFzcyBpcyB1c2VkIHRvIHJlcG9ydCB3aGV0aGVyIG9yIG5vdCBhXAogICBzb3VyY2Ugd2Fz IGZvdW5kIGFuZCB0byBpZGVudGlmeSB0aGUgc291cmNlIGhvc3Qocykgb3IgbmV0d29yayhzKTtc CiAgIGFuZCB0aGUgUklEUG9saWN5IGNsYXNzIHByb3ZpZGVzIGluZm9ybWF0aW9uIG9uIHRoZSBh Z3JlZWQtdXBvblwKICAgcG9saWNpZXMgYW5kIHNwZWNpZmllcyB0aGUgdHlwZSBvZiBjb21tdW5p Y2F0aW9uIG1lc3NhZ2UgYmVpbmcgdXNlZC5cClwKICAgVGhlIFJJRCBzY2hlbWEgYWN0cyBhcyBh biBlbnZlbG9wZSBmb3IgdGhlIElPREVGIHNjaGVtYSB0byBmYWNpbGl0YXRlXAogICBSSUQgY29t bXVuaWNhdGlvbnMuICBUaGUgaW50ZW50IGluIG1haW50YWluaW5nIGEgc2VwYXJhdGUgc2NoZW1h IGFuZFwKICAgbm90IHVzaW5nIHRoZSBBZGRpdGlvbmFsRGF0YSBleHRlbnNpb24gb2YgSU9ERUYg aXMgdGhlIGZsZXhpYmlsaXR5IG9mXAogICBzZW5kaW5nIG1lc3NhZ2VzIGJldHdlZW4gUklEIGhv c3RzLiAgU2luY2UgUklEIGlzIGEgc2VwYXJhdGUgc2NoZW1hXAogICB0aGF0IGluY2x1ZGVzIHRo ZSBJT0RFRiBzY2hlbWEsIHRoZSBSSUQgaW5mb3JtYXRpb24gYWN0cyBhcyBhblwKICAgZW52ZWxv cGUsIGFuZCB0aGVuIHRoZSBSSURQb2xpY3kgY2xhc3MgY2FuIGJlIGVhc2lseSBleHRyYWN0ZWQg Zm9yXAogICB1c2UgYnkgdGhlIHRyYW5zcG9ydCBwcm90b2NvbC5cClwKXApcClwKTW9yaWFydHkg ICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1Bh Z2UgMTJdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJp cyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIFRoZSBzZWN1cml0eSByZXF1 aXJlbWVudHMgb2Ygc2VuZGluZyBpbmNpZGVudCBpbmZvcm1hdGlvbiBhY3Jvc3MgdGhlXAogICBu ZXR3b3JrIGluY2x1ZGUgdGhlIHVzZSBvZiBlbmNyeXB0aW9uLiAgVGhlIFJJRFBvbGljeSBpbmZv cm1hdGlvbiBpc1wKICAgbm90IHJlcXVpcmVkIHRvIGJlIGVuY3J5cHRlZCwgc28gc2VwYXJhdGlu ZyBvdXQgdGhpcyBkYXRhIGZyb20gdGhlXAogICBJT0RFRiBleHRlbnNpb24gcmVtb3ZlcyB0aGUg bmVlZCBmb3IgZGVjcnlwdGluZyBhbmQgcGFyc2luZyB0aGVcCiAgIGVudGlyZSBJT0RFRiBhbmQg UklEIGRvY3VtZW50IHRvIGRldGVybWluZSBob3cgaXQgc2hvdWxkIGJlIGhhbmRsZWRcCiAgIGF0 IGVhY2ggUklEIGhvc3QuXApcCiAgIFRoZSBwdXJwb3NlIG9mIHRoZSBSSURQb2xpY3kgY2xhc3Mg aXMgdG8gc3BlY2lmeSB0aGUgbWVzc2FnZSB0eXBlIGZvclwKICAgdGhlIHJlY2VpdmluZyBob3N0 LCBmYWNpbGl0YXRlIHRoZSBwb2xpY3kgbmVlZHMgb2YgUklELCBhbmQgcHJvdmlkZVwKICAgcm91 dGluZyBpbmZvcm1hdGlvbiBpbiB0aGUgZm9ybSBvZiBhbiBJUCBhZGRyZXNzIG9mIHRoZSBkZXN0 aW5hdGlvblwKICAgUklEIHN5c3RlbS5cClwKICAgVGhlIHBvbGljeSBpbmZvcm1hdGlvbiBhbmQg Z3VpZGVsaW5lcyBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNi42LlwKICAgVGhlIHBvbGljeSBp cyBkZWZpbmVkIGJldHdlZW4gUklEIHBlZXJzIGFuZCB3aXRoaW4gb3IgYmV0d2VlblwKICAgY29u c29ydGl1bXMuICBUaGUgUklEUG9saWN5IGlzIG1lYW50IHRvIGJlIGEgdG9vbCB0byBmYWNpbGl0 YXRlIHRoZVwKICAgZGVmaW5lZCBwb2xpY2llcy4gIFRoaXMgTVVTVCBiZSB1c2VkIGluIGFjY29y ZGFuY2Ugd2l0aCBwb2xpY3kgc2V0XAogICBiZXR3ZWVuIGNsaWVudHMsIHBlZXJzLCBjb25zb3J0 aXVtcywgYW5kL29yIHJlZ2lvbnMuICBTZWN1cml0eSxcCiAgIHByaXZhY3ksIGFuZCBjb25maWRl bnRpYWxpdHkgTVVTVCBiZSBjb25zaWRlcmVkIGFzIHNwZWNpZmllZCBpbiB0aGlzXAogICBkb2N1 bWVudC5cClwKICAgVGhlIFJJRCBzY2hlbWEgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOlwKXAogICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rXAogICAgICAgICAgIHwgICAgICAgIFJJRCAgICAg ICB8XAogICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rXAogICAgICAgICAgIHwgQU5ZICAg ICAgICAgICAgICB8XAogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8PD4tLS1cezAuLjFc fS0tLS1bIFJJRFBvbGljeSAgICAgIF1cCiAgICAgICAgICAgfCBFTlVNIHJlc3RyaWN0aW9uIHxc CiAgICAgICAgICAgfCBFTlVNIHR5cGUgICAgICAgIHw8Pi0tLVx7MC4uMVx9LS0tLVsgUmVxdWVz dFN0YXR1cyAgXVwKICAgICAgICAgICB8IFNUUklORyBtZWFuaW5nICAgfFwKICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgfDw+LS0tXHswLi4xXH0tLS0tWyBJbmNpZGVudFNvdXJjZSBdXAog ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rXApcCiAgICAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgMzogVGhlIFJJRCBTY2hlbWFcClwKICAgVGhlIGFnZ3JlZ2F0ZSBjbGFzc2VzIHRo YXQgY29uc3RpdHV0ZSB0aGUgUklEIHNjaGVtYSBpbiB0aGUgaW9kZWYtcmlkXAogICBuYW1lc3Bh Y2UgYXJlIGFzIGZvbGxvd3M6XApcCiAgIFJJRFBvbGljeVwKXAogICAgICBaZXJvIG9yIE9uZS4g VGhlIFJJRFBvbGljeSBjbGFzcyBpcyB1c2VkIGJ5IGFsbCBtZXNzYWdlIHR5cGVzIHRvXAogICAg ICBmYWNpbGl0YXRlIHBvbGljeSBhZ3JlZW1lbnRzIGJldHdlZW4gcGVlcnMsIGNvbnNvcnRpdW1z LCBvclwKICAgICAgZmVkZXJhdGlvbnMsIGFzIHdlbGwgYXMgdG8gcHJvcGVybHkgcm91dGUgbWVz c2FnZXMuXApcCiAgIFJlcXVlc3RTdGF0dXNcClwKICAgICAgWmVybyBvciBPbmUuIFRoZSBSZXF1 ZXN0U3RhdHVzIGNsYXNzIGlzIHVzZWQgb25seSBpblwKICAgICAgUmVxdWVzdEF1dGhvcml6YXRp b24gbWVzc2FnZXMgdG8gcmVwb3J0IGJhY2sgdG8gdGhlIENTSVJUIG9yIFNQXApcClwKXApNb3Jp YXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAg ICBbUGFnZSAxM11cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYw NDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAgb3JpZ2luYXRp bmcgdGhlIFJJRCB0cmFjZSB3aWxsIGJlIGNvbnRpbnVlZCBieSBlYWNoIFJJRCBzeXN0ZW1cCiAg ICAgIHRoYXQgcmVjZWl2ZWQgYSBUcmFjZVJlcXVlc3QgaW4gdGhlIHBhdGggdG8gdGhlIHNvdXJj ZSBvZiB0aGVcCiAgICAgIHRyYWZmaWMuXApcCiAgIEluY2lkZW50U291cmNlXApcCiAgICAgIFpl cm8gb3IgT25lLiBUaGUgSW5jaWRlbnRTb3VyY2UgY2xhc3MgaXMgdXNlZCBpbiB0aGUgUmVzdWx0 XAogICAgICBtZXNzYWdlIG9ubHkuICBUaGUgSW5jaWRlbnRTb3VyY2UgcHJvdmlkZXMgdGhlIGlu Zm9ybWF0aW9uIG9uIHRoZVwKICAgICAgaWRlbnRpZmllZCBzb3VyY2UgaG9zdCBvciBuZXR3b3Jr IG9mIGFuIGF0dGFjayB0cmFjZSBvclwKICAgICAgaW52ZXN0aWdhdGlvbi5cClwKICAgRWFjaCBv ZiB0aGUgdGhyZWUgbGlzdGVkIGNsYXNzZXMgbWF5IGJlIHRoZSBvbmx5IGNsYXNzIGluY2x1ZGVk IGluXAogICB0aGUgUklEIGNsYXNzLCBoZW5jZSB0aGUgb3B0aW9uIGZvciB6ZXJvIG9yIG9uZS4g IEluIHNvbWUgY2FzZXMsXAogICBSSURQb2xpY3kgTUFZIGJlIHRoZSBvbmx5IGNsYXNzIGluIHRo ZSBSSUQgZGVmaW5pdGlvbiB3aGVuIHVzZWQgYnlcCiAgIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wg W1JGQzYwNDZdLCBhcyB0aGF0IGluZm9ybWF0aW9uIHNob3VsZCBiZSBhc1wKICAgc21hbGwgYXMg cG9zc2libGUgYW5kIG1heSBub3QgYmUgZW5jcnlwdGVkLiAgVGhlIFJlcXVlc3RTdGF0dXNcCiAg IG1lc3NhZ2UgTVVTVCBiZSBhYmxlIHRvIHN0YW5kIGFsb25lIHdpdGhvdXQgdGhlIG5lZWQgZm9y IGFuIElPREVGXAogICBkb2N1bWVudCB0byBmYWNpbGl0YXRlIHRoZSBjb21tdW5pY2F0aW9uLCBs aW1pdGluZyB0aGUgZGF0YVwKICAgdHJhbnNwb3J0ZWQgdG8gdGhlIHJlcXVpcmVkIGVsZW1lbnRz IHBlciBbUkZDNjA0Nl0uXApcCjMuMS4gIFJJRFBvbGljeSBDbGFzc1wKXAogICBUaGUgUklEUG9s aWN5IGNsYXNzIGZhY2lsaXRhdGVzIHRoZSBkZWxpdmVyeSBvZiBSSUQgbWVzc2FnZXMgYW5kIGlz XAogICBhbHNvIHJlZmVyZW5jZWQgZm9yIHRyYW5zcG9ydCBpbiB0aGUgdHJhbnNwb3J0IGRvY3Vt ZW50IFtSRkM2MDQ2XS5cClwKICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rXAog ICAgICAgICAgfCBSSURQb2xpY3kgICAgICAgICAgICAgIHxcCiAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tK1wKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8XAog ICAgICAgICAgfCBFTlVNIHJlc3RyaWN0aW9uICAgICAgIHw8Pi0tLS0tLS0tLS0tLS1bIE5vZGUg ICAgICAgICBdXAogICAgICAgICAgfCBFTlVNIE1zZ1R5cGUgICAgICAgICAgIHxcCiAgICAgICAg ICB8IEVOVU0gTXNnRGVzdGluYXRpb24gICAgfDw+LS0tXHswLi4xXH0tLS0tWyBJbmNpZGVudElE ICAgXVwKICAgICAgICAgIHwgRU5VTSBleHQtTXNnVHlwZSAgICAgICB8XAogICAgICAgICAgfCBF TlVNIGV4dC1Nc2dEZXN0aW5hdGlvbnw8Pi0tLVx7MS4uKlx9LS0tLVsgUG9saWN5UmVnaW9uIF1c CiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfFwKICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICB8PD4tLS1cezEuLipcfS0tLS1bIFRyYWZmaWNUeXBlICBdXAogICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxcCiAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tK1wKXAogICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA0OiBUaGUgUklE UG9saWN5IENsYXNzXApcCiAgIFRoZSBhZ2dyZWdhdGUgZWxlbWVudHMgdGhhdCBjb25zdGl0dXRl IHRoZSBSSURQb2xpY3kgY2xhc3MgYXJlIGFzXAogICBmb2xsb3dzOlwKXAogICBOb2RlXApcCiAg ICAgIE9uZS4gVGhlIE5vZGUgY2xhc3MgaXMgdXNlZCB0byBpZGVudGlmeSBhIGhvc3Qgb3IgbmV0 d29yayBkZXZpY2UsXAogICAgICBpbiB0aGlzIGNhc2UgdG8gaWRlbnRpZnkgdGhlIHN5c3RlbSBj b21tdW5pY2F0aW5nIFJJRCBtZXNzYWdlcy5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDE0XVwKXHBhZ2Ug XApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAg ICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICBUaGUgYmFzZSBkZWZpbml0aW9uIG9mIHRoaXMg Y2xhc3MgaXMgcmV1c2VkIGZyb20gdGhlIElPREVGXAogICAgICBzcGVjaWZpY2F0aW9uIFtSRkM1 MDcwXSwgU2VjdGlvbiAzLjE2LlwKXAogICBJbmNpZGVudElEXApcCiAgICAgIFplcm8gb3Igb25l LiAgR2xvYmFsIHJlZmVyZW5jZSBwb2ludGluZyBiYWNrIHRvIHRoZSBJbmNpZGVudElEXAogICAg ICBkZWZpbmVkIGluIHRoZSBJT0RFRiBkYXRhIG1vZGVsLiAgVGhlIEluY2lkZW50SUQgaW5jbHVk ZXMgdGhlIG5hbWVcCiAgICAgIG9mIHRoZSBDU0lSVCwgYW4gaW5jaWRlbnQgbnVtYmVyLCBhbmQg YW4gaW5zdGFuY2Ugb2YgdGhhdFwKICAgICAgaW5jaWRlbnQuICBUaGUgaW5zdGFuY2UgbnVtYmVy IGlzIGFwcGVuZGVkIHdpdGggYSBkYXNoIHNlcGFyYXRpbmdcCiAgICAgIHRoZSB2YWx1ZXMgYW5k IGlzIHVzZWQgaW4gY2FzZXMgZm9yIHdoaWNoIGl0IG1heSBiZSBkZXNpcmFibGUgdG9cCiAgICAg IGdyb3VwIGluY2lkZW50cy4gIEV4YW1wbGVzIG9mIGluY2lkZW50cyB0aGF0IG1heSBiZSBncm91 cGVkIHdvdWxkXAogICAgICBiZSBib3RuZXRzLCBwb2x5bW9ycGhpYyBhdHRhY2tzLCBERG9TIGF0 dGFja3MsIG11bHRpcGxlIGhvcHMgb2ZcCiAgICAgIGNvbXByb21pc2VkIHN5c3RlbXMgZm91bmQg ZHVyaW5nIGFuIGludmVzdGlnYXRpb24sIGV0Yy5cClwKICAgUG9saWN5UmVnaW9uXApcCiAgICAg IE9uZSBvciBtYW55LiAgUkVRVUlSRUQuICBUaGUgdmFsdWVzIGZvciB0aGUgYXR0cmlidXRlICJy ZWdpb24iIGFyZVwKICAgICAgdXNlZCB0byBkZXRlcm1pbmUgd2hhdCBwb2xpY3kgYXJlYSBtYXkg cmVxdWlyZSBjb25zaWRlcmF0aW9uXAogICAgICBiZWZvcmUgYSB0cmFjZSBjYW4gYmUgYXBwcm92 ZWQuICBUaGUgUG9saWN5UmVnaW9uIG1heSBpbmNsdWRlXAogICAgICBtdWx0aXBsZSBzZWxlY3Rp b25zIGZyb20gdGhlIGF0dHJpYnV0ZSBsaXN0IGluIG9yZGVyIHRvIGZpdCBhbGxcCiAgICAgIHBv c3NpYmxlIHBvbGljeSBjb25zaWRlcmF0aW9ucyB3aGVuIGNyb3NzaW5nIHJlZ2lvbnMsIGNvbnNv cnRpdW1zLFwKICAgICAgb3IgbmV0d29ya3MuXApcCiAgIHJlZ2lvblwKXAogICAgICBPbmUuIEVO VU0uXApcCiAgICAgIDEuICBDbGllbnRUb1NQLiAgQW4gZW50ZXJwcmlzZSBpbml0aWF0ZWQgdGhl IHJlcXVlc3QgdG8gdGhlaXJcCiAgICAgICAgICBzZXJ2aWNlIHByb3ZpZGVyLlwKXAogICAgICAy LiAgU1BUb0NsaWVudC4gIEFuIHNlcnZpY2UgcHJvdmlkZXIgcGFzc2VkIGEgUklEIHJlcXVlc3Qg b3JcCiAgICAgICAgICByZXBvcnQgdG8gYSBjbGllbnQgb3IgYW4gZW50ZXJwcmlzZSBiYXNlZCBv biByZXF1ZXN0ZWRcCiAgICAgICAgICBzZXJ2aWNlcyBvciBzZXJ2aWNlIGxldmVsIGFncmVlbWVu dHMuXApcCiAgICAgIDMuICBJbnRyYUNvbnNvcnRpdW0uICBJbmNpZGVudCBpbmZvcm1hdGlvbiB0 aGF0IHNob3VsZCBoYXZlIG5vXAogICAgICAgICAgcmVzdHJpY3Rpb25zIHdpdGhpbiB0aGUgYm91 bmRhcmllcyBvZiBhIGNvbnNvcnRpdW0gd2l0aCB0aGVcCiAgICAgICAgICBhZ3JlZWQtdXBvbiB1 c2UgYW5kIGFidXNlIGd1aWRlbGluZXMuXApcCiAgICAgIDQuICBQZWVyVG9QZWVyLiAgSW5jaWRl bnQgaW5mb3JtYXRpb24gdGhhdCBzaG91bGQgaGF2ZSBub1wKICAgICAgICAgIHJlc3RyaWN0aW9u cyBiZXR3ZWVuIHR3byBwZWVycyBidXQgbWF5IHJlcXVpcmUgZnVydGhlclwKICAgICAgICAgIGV2 YWx1YXRpb24gYmVmb3JlIGNvbnRpbnVhbmNlIGJleW9uZCB0aGF0IHBvaW50IHdpdGggdGhlXAog ICAgICAgICAgYWdyZWVkLXVwb24gdXNlIGFuZCBhYnVzZSBndWlkZWxpbmVzLlwKXAogICAgICA1 LiAgQmV0d2VlbkNvbnNvcnRpdW1zLiAgSW5jaWRlbnQgaW5mb3JtYXRpb24gdGhhdCBzaG91bGQg aGF2ZSBub1wKICAgICAgICAgIHJlc3RyaWN0aW9ucyBiZXR3ZWVuIGNvbnNvcnRpdW1zIHRoYXQg aGF2ZSBlc3RhYmxpc2hlZCBhZ3JlZWQtXAogICAgICAgICAgdXBvbiB1c2UgYW5kIGFidXNlIGd1 aWRlbGluZXMuXApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTVdXApccGFnZSBcCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3Qg MjAxMVwKXApcCiAgICAgIDYuICBBY3Jvc3NOYXRpb25hbEJvdW5kYXJpZXMuICBUaGlzIHNlbGVj dGlvbiBtdXN0IGJlIHNldCBpZiB0aGVcCiAgICAgICAgICBtZXNzYWdlIHR5cGUgd2lsbCBjcm9z cyBuYXRpb25hbCBib3VuZGFyaWVzLiAgVGhlcmUgY291bGQgYmVcCiAgICAgICAgICBpbnN0YW5j ZXMgb2YgVHJhY2VSZXF1ZXN0IG1lc3NhZ2VzIHdoZXJlIHRoYXQgbWF5IG5vdCBiZSBrbm93blwK ICAgICAgICAgIGluIGFkdmFuY2UsIGJ1dCBzaG91bGQgYmUga25vd24gYXQgdGhlIGluc3RhbmNl IHdoZXJlXAogICAgICAgICAgYm91bmRhcmllcyBhcmUgY3Jvc3NlZCBkdXJpbmcgdGhlIGludmVz dGlnYXRpb24uICBUaGlzIG11c3RcCiAgICAgICAgICBhbHNvIGJlIHNldCBpZiB0aGUgc2VjdXJp dHkgcmVxdWlyZW1lbnRzIG9mIHRoZSByZXF1ZXN0IGlzXAogICAgICAgICAgYmFzZWQgdXBvbiBy ZWd1bGF0aW9ucyBvZiBhIHNwZWNpZmljIG5hdGlvbiB0aGF0IG1heSBub3QgYXBwbHlcCiAgICAg ICAgICB0byBhbGwgbmF0aW9ucy4gIFRoZSBzdHJpY3RlciByZXF1aXJlbWVudHMgc2hvdWxkIGJl IHVwaGVsZC5cCiAgICAgICAgICBUaGlzIGlzIGRpZmZlcmVudCBmcm9tIHRoZSAiQmV0d2VlbkNv bnNvcnRpdW1zIiBzZXR0aW5nIHNpbmNlXAogICAgICAgICAgaXQgbWF5IGJlIHBvc3NpYmxlIHRv IGhhdmUgbXVsdGlwbGUgbmF0aW9ucyBhcyBtZW1iZXJzIG9mIHRoZVwKICAgICAgICAgIHNhbWUg Y29uc29ydGl1bSwgYW5kIHRoaXMgb3B0aW9uIG11c3QgYmUgc2VsZWN0ZWQgaWYgdGhlXAogICAg ICAgICAgdHJhZmZpYyBpcyBvZiBhIHR5cGUgdGhhdCBtYXkgaGF2ZSBkaWZmZXJlbnQgcmVzdHJp Y3Rpb25zIGluXAogICAgICAgICAgb3RoZXIgbmF0aW9ucy5cClwKICAgICAgNy4gIExhd0VuZm9y Y2VtZW50LiAgVGhpcyBvcHRpb24gaXMgdXNlZCB3aGVuIGluY2lkZW50IGluZm9ybWF0aW9uXAog ICAgICAgICAgaXMgZXhjaGFuZ2VkIHdpdGggTGF3RW5mb3JjZW1lbnQsIGxvY2FsIGdvdmVybm1l bnQsIG9yIG90aGVyXAogICAgICAgICAgYXV0aG9yaXRpZXMgYXNzaXN0aW5nIHdpdGggYW4gaW52 ZXN0aWdhdGlvbi4gIElmIHRoZSBsYXdcCiAgICAgICAgICBlbmZvcmNlbWVudCBhZ2VuY3kgcmVz aWRlcyB3aXRoaW4gYSBkaWZmZXJlbnQgbmF0aW9uIHRoYXQgdGhlXAogICAgICAgICAgc2VuZGlu ZyBlbnRpdHksIHRoZSAiQWNyb3NzTmF0aW9uYWxCb3VuZGFyaWVzIiBlbnVtZXJhdGlvblwKICAg ICAgICAgIE1VU1QgYWxzbyBiZSBzZXQuXApcCiAgICAgIDguICBleHQtdmFsdWUuICBBbiBlc2Nh cGUgdmFsdWUgdXNlZCB0byBleHRlbmQgdGhpcyBhdHRyaWJ1dGUuXAogICAgICAgICAgU2VlIElP REVGIFtSRkM1MDcwXSwgU2VjdGlvbiA1LjEuXApcCiAgIFRyYWZmaWNUeXBlXApcCiAgICAgIE9u ZSBvciBtYW55LiAgUkVRVUlSRUQuICBUaGUgdmFsdWVzIGZvciB0aGUgYXR0cmlidXRlICJ0eXBl IiBhcmVcCiAgICAgIG1lYW50IHRvIGFzc2lzdCBpbiBkZXRlcm1pbmluZyBpZiBhIHRyYWNlIGlz IGFwcHJvcHJpYXRlIGZvciB0aGVcCiAgICAgIFNQIChwcm92aWRlcikgcmVjZWl2aW5nIHRoZSBy ZXF1ZXN0IHRvIGNvbnRpbnVlIHRoZSB0cmFjZS5cCiAgICAgIE11bHRpcGxlIHZhbHVlcyBtYXkg YmUgc2VsZWN0ZWQgZm9yIHRoaXMgZWxlbWVudDsgaG93ZXZlciwgd2hlcmVcCiAgICAgIHBvc3Np YmxlLCBpdCBzaG91bGQgYmUgcmVzdHJpY3RlZCB0byBvbmUgdmFsdWUgdGhhdCB3b3VsZCBtb3N0 XAogICAgICBhY2N1cmF0ZWx5IGRlc2NyaWJlIHRoZSB0cmFmZmljIHR5cGUuXApcCiAgIHR5cGVc ClwKICAgICAgT25lLiBFTlVNLlwKXAogICAgICAxLiAgQXR0YWNrLiAgVGhpcyBvcHRpb24gc2hv dWxkIG9ubHkgYmUgc2VsZWN0ZWQgaWYgdGhlIHRyYWZmaWMgaXNcCiAgICAgICAgICByZWxhdGVk IHRvIGEgbmV0d29yay1iYXNlZCBhdHRhY2suICBUaGUgdHlwZSBvZiBhdHRhY2sgTVVTVFwKICAg ICAgICAgIGFsc28gYmUgbGlzdGVkIGluIG1vcmUgZGV0YWlsIGluIHRoZSBJT0RFRiBNZXRob2Qg YW5kIEltcGFjdFwKICAgICAgICAgIGNsYXNzZXMgZm9yIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiB0 byBhc3Npc3QgaW4gZGV0ZXJtaW5pbmcgaWZcCiAgICAgICAgICB0aGUgdHJhY2UgY2FuIGJlIGNv bnRpbnVlZCAoW1JGQzUwNzBdLCBTZWN0aW9ucyAzLjkgYW5kXAogICAgICAgICAgMy4xMC4xKS5c ClwKICAgICAgMi4gIE5ldHdvcmsuICBUaGlzIG9wdGlvbiBNVVNUIG9ubHkgYmUgc2VsZWN0ZWQg d2hlbiB0aGUgdHJhY2UgaXNcCiAgICAgICAgICByZWxhdGVkIHRvIG5ldHdvcmsgdHJhZmZpYyBv ciByb3V0aW5nIGlzc3Vlcy5cClwKXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBp cmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxNl1cClxwYWdlIFwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDExXApcClwKICAgICAgMy4gIENvbnRlbnQuICBUaGlzIGNhdGVnb3J5IE1VU1Qg YmUgdXNlZCBvbmx5IGluIHRoZSBjYXNlIGluIHdoaWNoXAogICAgICAgICAgdGhlIHJlcXVlc3Qg aXMgcmVsYXRlZCB0byB0aGUgY29udGVudCBhbmQgcmVnaW9uYWxcCiAgICAgICAgICByZXN0cmlj dGlvbnMgb24gYWNjZXNzaW5nIHRoYXQgdHlwZSBvZiBjb250ZW50IGV4aXN0LiAgVGhpcyBpc1wK ICAgICAgICAgIG5vdCBtYWxpY2lvdXMgdHJhZmZpYyBidXQgbWF5IGluY2x1ZGUgZGV0ZXJtaW5p bmcgd2hhdCBzb3VyY2VzXAogICAgICAgICAgb3IgZGVzdGluYXRpb25zIGFjY2Vzc2VkIGNlcnRh aW4gbWF0ZXJpYWxzIGF2YWlsYWJsZSBvbiB0aGVcCiAgICAgICAgICBJbnRlcm5ldCwgaW5jbHVk aW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIG5ld3MsIHRlY2hub2xvZ3ksIG9yXAogICAgICAgICAg aW5hcHByb3ByaWF0ZSBjb250ZW50LlwKXAogICAgICA0LiAgT2ZmaWNpYWxCdXNpbmVzcy4gIFRo aXMgb3B0aW9uIE1VU1QgYmUgdXNlZCBpZiB0aGUgaW5jaWRlbnRcCiAgICAgICAgICBpbmZvcm1h dGlvbiBpcyByZXF1ZXN0ZWQgYnkgb3IgYWZmaWxpYXRlZCB3aXRoIGFueSBnb3Zlcm5tZW50XAog ICAgICAgICAgb3Igb3RoZXIgb2ZmaWNpYWwgYnVzaW5lc3MgcmVxdWVzdC4gIFRoaXMgd291bGQg YmUgdXNlZCBkdXJpbmdcCiAgICAgICAgICBhbiBpbnZlc3RpZ2F0aW9uIGJ5IGdvdmVybm1lbnQg YXV0aG9yaXRpZXMgb3Igb3RoZXIgZ292ZXJubWVudFwKICAgICAgICAgIGluY2lkZW50IGludmVz dGlnYXRpb25zIHRvIHRyYWNrIHN1c3BlY3RlZCBjcmltaW5hbCBvciBvdGhlclwKICAgICAgICAg IGFjdGl2aXRpZXMuXApcCiAgICAgIDUuICBPdGhlci4gIElmIHRoaXMgb3B0aW9uIGlzIHNlbGVj dGVkLCBhIGRlc2NyaXB0aW9uIG9mIHRoZVwKICAgICAgICAgIHRyYWZmaWMgdHlwZSBNVVNUIGJl IHByb3ZpZGVkIHNvIHRoYXQgcG9saWN5IGRlY2lzaW9ucyBjYW4gYmVcCiAgICAgICAgICBtYWRl IHRvIGNvbnRpbnVlIG9yIHN0b3AgdGhlIGludmVzdGlnYXRpb24uICBUaGUgaW5mb3JtYXRpb25c CiAgICAgICAgICBzaG91bGQgYmUgcHJvdmlkZWQgaW4gdGhlIElPREVGIG1lc3NhZ2UgaW4gdGhl IEV4cGVjdGF0aW9uXAogICAgICAgICAgY2xhc3Mgb3IgaW4gdGhlIEhpc3RvcnkgY2xhc3MgdXNp bmcgYSBIaXN0b3J5SXRlbSBsb2cuXApcCiAgICAgIDYuICBleHQtdmFsdWUuICBBbiBlc2NhcGUg dmFsdWUgdXNlZCB0byBleHRlbmQgdGhpcyBhdHRyaWJ1dGUuXAogICAgICAgICAgU2VlIElPREVG IFtSRkM1MDcwXSwgU2VjdGlvbiA1LjEuXApcCiAgIFRoZSBSSURQb2xpY3kgY2xhc3MgaGFzIGZp dmUgYXR0cmlidXRlczpcClwKICAgICAgcmVzdHJpY3Rpb25cClwKICAgICAgICAgT1BUSU9OQUwu ICBFTlVNLiAgVGhpcyBhdHRyaWJ1dGUgaW5kaWNhdGVzIHRoZSBkaXNjbG9zdXJlXAogICAgICAg ICBndWlkZWxpbmVzIHRvIHdoaWNoIHRoZSBzZW5kZXIgZXhwZWN0cyB0aGUgcmVjaXBpZW50IHRv IGFkaGVyZS5cCiAgICAgICAgIFRoaXMgZ3VpZGVsaW5lIHByb3ZpZGVzIG5vIHJlYWwgc2VjdXJp dHkgc2luY2UgaXQgaXMgdGhlIGNob2ljZVwKICAgICAgICAgb2YgdGhlIHJlY2lwaWVudCBvZiB0 aGUgZG9jdW1lbnQgdG8gaG9ub3IgaXQuICBUaGlzIGF0dHJpYnV0ZVwKICAgICAgICAgZm9sbG93 cyB0aGUgc2FtZSBndWlkZWxpbmVzIGFzICJyZXN0cmljdGlvbiIgdXNlZCBpbiBJT0RFRi5cClwK ICAgICAgTXNnVHlwZVwKXAogICAgICAgICBSRVFVSVJFRC4gIEVOVU0uICBUaGUgdHlwZSBvZiBS SUQgbWVzc2FnZSBzZW50LiAgVGhlIHNpeCB0eXBlc1wKICAgICAgICAgb2YgbWVzc2FnZXMgYXJl IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMy4yIGFuZCBjYW4gYmUgbm90ZWQgYXNcCiAgICAgICAg IG9uZSBvZiB0aGUgc2l4IHNlbGVjdGlvbnMgYmVsb3cuXApcCiAgICAgIFwKXAogICAgICAxLiAg VHJhY2VSZXF1ZXN0LiAgVGhpcyBtZXNzYWdlIG1heSBiZSB1c2VkIHRvIGluaXRpYXRlIGFcCiAg ICAgICAgICBUcmFjZVJlcXVlc3Qgb3IgdG8gY29udGludWUgYSBUcmFjZVJlcXVlc3QgdG8gYW4g dXBzdHJlYW1cCiAgICAgICAgICBuZXR3b3JrIGNsb3NlciB0byB0aGUgc291cmNlIGFkZHJlc3Mg b2YgdGhlIG9yaWdpbiBvZiB0aGVcCiAgICAgICAgICBzZWN1cml0eSBpbmNpZGVudC5cClwKXApc ClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAg ICAgICAgICAgICBbUGFnZSAxN11cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgICAg Mi4gIFJlcXVlc3RBdXRob3JpemF0aW9uLiAgVGhpcyBtZXNzYWdlIGlzIHNlbnQgdG8gdGhlIGlu aXRpYXRpbmdcCiAgICAgICAgICBSSUQgc3lzdGVtIGZyb20gZWFjaCBvZiB0aGUgdXBzdHJlYW0g UklEIHN5c3RlbXMgdG8gcHJvdmlkZVwKICAgICAgICAgIGluZm9ybWF0aW9uIG9uIHRoZSByZXF1 ZXN0IHN0YXR1cyBpbiB0aGUgY3VycmVudCBuZXR3b3JrLlwKXAogICAgICAzLiAgUmVzdWx0LiAg VGhpcyBtZXNzYWdlIGluZGljYXRlcyB0aGF0IHRoZSBzb3VyY2Ugb2YgdGhlIGF0dGFja1wKICAg ICAgICAgIHdhcyBsb2NhdGVkIGFuZCB0aGUgbWVzc2FnZSBpcyBzZW50IHRvIHRoZSBpbml0aWF0 aW5nIFJJRFwKICAgICAgICAgIHN5c3RlbSB0aHJvdWdoIHRoZSBSSUQgc3lzdGVtcyBpbiB0aGUg cGF0aCBvZiB0aGUgdHJhY2UuXApcCiAgICAgIDQuICBJbnZlc3RpZ2F0aW9uLiAgVGhpcyBtZXNz YWdlIHR5cGUgaXMgdXNlZCB3aGVuIHRoZSBzb3VyY2Ugb2ZcCiAgICAgICAgICB0aGUgdHJhZmZp YyBpcyBiZWxpZXZlZCB0byBiZSB2YWxpZC4gIFRoZSBwdXJwb3NlIG9mIHRoZVwKICAgICAgICAg IEludmVzdGlnYXRpb24gcmVxdWVzdCBpcyB0byBsZXZlcmFnZSB0aGUgZXhpc3RpbmcgcGVlciBv clwKICAgICAgICAgIGNvbnNvcnRpdW0gcmVsYXRpb25zaGlwcyBpbiBvcmRlciB0byBub3RpZnkg dGhlIG5ldHdvcmsgb3JcCiAgICAgICAgICBzZXJ2aWNlIHByb3ZpZGVyIGNsb3Nlc3QgdG8gdGhl IHNvdXJjZSBvZiB0aGUgdmFsaWQgdHJhZmZpY1wKICAgICAgICAgIHRoYXQgc29tZSBldmVudCBv Y2N1cnJlZCwgd2hpY2ggbWF5IGJlIGEgc2VjdXJpdHktcmVsYXRlZFwKICAgICAgICAgIGluY2lk ZW50LlwKXAogICAgICA1LiAgUmVwb3J0LiAgVGhpcyBtZXNzYWdlIGlzIHVzZWQgdG8gcmVwb3J0 IGEgc2VjdXJpdHkgaW5jaWRlbnQsXAogICAgICAgICAgZm9yIHdoaWNoIG5vIGFjdGlvbiBpcyBy ZXF1ZXN0ZWQgaW4gdGhlIElPREVGIEV4cGVjdGF0aW9uXAogICAgICAgICAgY2xhc3MuICBUaGlz IG1heSBiZSB1c2VkIGZvciB0aGUgcHVycG9zZSBvZiBjb3JyZWxhdGluZyBhdHRhY2tcCiAgICAg ICAgICBpbmZvcm1hdGlvbiBieSBDU0lSVHMsIHN0YXRpc3RpY3MgYW5kIHRyZW5kaW5nIGluZm9y bWF0aW9uLFwKICAgICAgICAgIGV0Yy5cClwKICAgICAgNi4gIEluY2lkZW50UXVlcnkuICBUaGlz IG1lc3NhZ2UgaXMgdXNlZCB0byByZXF1ZXN0IGluZm9ybWF0aW9uXAogICAgICAgICAgZnJvbSBh IHRydXN0ZWQgUklEIHN5c3RlbSBhYm91dCBhbiBpbmNpZGVudCBvciBpbmNpZGVudCB0eXBlLlwK XAogICAgICBBZGRpdGlvbmFsbHksIHRoZXJlIGlzIGFuIGV4dGVuc2lvbiBhdHRyaWJ1dGUgdG8g YWRkIG5ld1wKICAgICAgZW51bWVyYXRlZCB2YWx1ZXM6XApcCiAgICAgICAgIGV4dC12YWx1ZS4g IEFuIGVzY2FwZSB2YWx1ZSB1c2VkIHRvIGV4dGVuZCB0aGlzIGF0dHJpYnV0ZS4gIFNlZVwKICAg ICAgICAgSU9ERUYgW1JGQzUwNzBdLCBTZWN0aW9uIDUuMS5cClwKICAgICAgTXNnRGVzdGluYXRp b25cClwKICAgICAgICAgUkVRVUlSRUQuICBFTlVNLiAgVGhlIGRlc3RpbmF0aW9uIHJlcXVpcmVk IGF0IHRoaXMgbGV2ZWwgbWF5XAogICAgICAgICBlaXRoZXIgYmUgdGhlIFJJRCBtZXNzYWdpbmcg c3lzdGVtIGludGVuZGVkIHRvIHJlY2VpdmUgdGhlXAogICAgICAgICByZXF1ZXN0LCBvciwgaW4g dGhlIGNhc2Ugb2YgYW4gSW52ZXN0aWdhdGlvbiByZXF1ZXN0LCB0aGVcCiAgICAgICAgIHNvdXJj ZSBvZiB0aGUgaW5jaWRlbnQuICBJbiB0aGUgY2FzZSBvZiBhbiBJbnZlc3RpZ2F0aW9uXAogICAg ICAgICByZXF1ZXN0LCB0aGUgUklEIHN5c3RlbSB0aGF0IGNhbiBoZWxwIHN0b3Agb3IgbWl0aWdh dGUgdGhlXAogICAgICAgICB0cmFmZmljIG1heSBub3QgYmUga25vd24sIGFuZCB0aGUgbWVzc2Fn ZSBtYXkgaGF2ZSB0byB0cmF2ZXJzZVwKICAgICAgICAgUklEIG1lc3NhZ2luZyBzeXN0ZW1zIGJ5 IGZvbGxvd2luZyB0aGUgcm91dGluZyBwYXRoIHRvIHRoZSBSSURcCiAgICAgICAgIHN5c3RlbSBj bG9zZXN0IHRvIHRoZSBzb3VyY2Ugb2YgdGhlIGF0dGFjayB0cmFmZmljLiAgVGhlIE5vZGVcCiAg ICAgICAgIGVsZW1lbnQgbGlzdHMgZWl0aGVyIHRoZSBSSUQgc3lzdGVtIG9yIHRoZSBJUCBhZGRy ZXNzIG9mIHRoZVwKICAgICAgICAgc291cmNlLCBhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIHZhbHVl IGluIHRoZSBOb2RlIGVsZW1lbnQgaXNcCiAgICAgICAgIGRldGVybWluZWQgYnkgdGhlIE1zZ0Rl c3RpbmF0aW9uIGVsZW1lbnQuXApcCiAgICAgICAgIDEuICBSSURTeXN0ZW0uICBUaGUgYWRkcmVz cyBsaXN0ZWQgaW4gdGhlIE5vZGUgZWxlbWVudCBvZiB0aGVcCiAgICAgICAgICAgICBSSURQb2xp Y3kgY2xhc3MgaXMgdGhlIG5leHQgdXBzdHJlYW0gUklEIHN5c3RlbSB0aGF0IHdpbGxcCiAgICAg ICAgICAgICByZWNlaXZlIHRoZSBSSUQgbWVzc2FnZS5cClwKXApcCk1vcmlhcnR5ICAgICAgICAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDE4XVwK XHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAg ICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICAgICAyLiAgU291cmNlT2ZJbmNpZGVu dC4gIFRoZSBhZGRyZXNzIGxpc3RlZCBpbiB0aGUgTm9kZSBlbGVtZW50XAogICAgICAgICAgICAg b2YgdGhlIFJJRFBvbGljeSBjbGFzcyBpcyB0aGUgaW5jaWRlbnQgc291cmNlLiAgVGhlIElQXAog ICAgICAgICAgICAgYWRkcmVzcyBpcyB1c2VkIHRvIGRldGVybWluZSB0aGUgcGF0aCBvZiBzeXN0 ZW1zIGFjY2VwdGluZ1wKICAgICAgICAgICAgIFJJRCBjb21tdW5pY2F0aW9ucyB0aGF0IHdpbGwg YmUgdXNlZCB0byBmaW5kIHRoZSBjbG9zZXN0XAogICAgICAgICAgICAgUklEIHN5c3RlbSB0byB0 aGUgc291cmNlIG9mIGFuIGF0dGFjayBpbiB3aGljaCB0aGUgSVBcCiAgICAgICAgICAgICBhZGRy ZXNzIHVzZWQgYnkgdGhlIHNvdXJjZSBpcyBiZWxpZXZlZCB0byBiZSB2YWxpZCBhbmQgYW5cCiAg ICAgICAgICAgICBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgbWVzc2FnZSBpcyB1c2VkLiAgVGhpcyBp cyBub3QgdG8gYmVcCiAgICAgICAgICAgICBjb25mdXNlZCB3aXRoIHRoZSBJbmNpZGVudFNvdXJj ZSBjbGFzcywgYXMgdGhlIGRlZmluZWRcCiAgICAgICAgICAgICB2YWx1ZSBoZXJlIGlzIGZyb20g YW4gaW5pdGlhbCB0cmFjZSBvciBJbnZlc3RpZ2F0aW9uXAogICAgICAgICAgICAgcmVxdWVzdCwg bm90IHRoZSBzb3VyY2UgdXNlZCBpbiBhIFJlc3VsdCBtZXNzYWdlLlwKXAogICAgICAgICAzLiAg ZXh0LXZhbHVlLiAgQW4gZXNjYXBlIHZhbHVlIHVzZWQgdG8gZXh0ZW5kIHRoaXMgYXR0cmlidXRl LlwKICAgICAgICAgICAgIFNlZSBJT0RFRiBbUkZDNTA3MF0sIFNlY3Rpb24gNS4xLlwKXAogICAg ICBNc2dUeXBlLWV4dFwKXAogICAgICAgICBPUFRJT05BTC4gIFNUUklORy4gIEEgbWVhbnMgYnkg d2hpY2ggdG8gZXh0ZW5kIHRoZSBNc2dUeXBlXAogICAgICAgICBhdHRyaWJ1dGUuICBTZWUgSU9E RUYgW1JGQzUwNzBdLCBTZWN0aW9uIDUuMS5cClwKICAgICAgTXNnRGVzdGluYXRpb24tZXh0XApc CiAgICAgICAgIE9QVElPTkFMLiAgU1RSSU5HLiAgQSBtZWFucyBieSB3aGljaCB0byBleHRlbmQg dGhlXAogICAgICAgICBNc2dEZXN0aW5hdGlvbiBhdHRyaWJ1dGUuICBTZWUgSU9ERUYgW1JGQzUw NzBdLCBTZWN0aW9uIDUuMVwKXAozLjIuICBSZXF1ZXN0U3RhdHVzXApcCiAgIFRoZSBSZXF1ZXN0 U3RhdHVzIGNsYXNzIGlzIGFuIGFnZ3JlZ2F0ZSBjbGFzcyBpbiB0aGUgUklEIGNsYXNzLlwKXAog ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLStc CiAgICAgICAgICAgICAgICAgICAgICAgfCBSZXF1ZXN0U3RhdHVzICAgICAgICAgICAgICAgICAg fFwKICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rXAogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHxcCiAgICAgICAgICAgICAgICAgICAgICAgfCBFTlVNIHJlc3RyaWN0aW9uICAgICAgICAg ICAgICAgfFwKICAgICAgICAgICAgICAgICAgICAgICB8IEVOVU0gQXV0aG9yaXphdGlvblN0YXR1 cyAgICAgICB8XAogICAgICAgICAgICAgICAgICAgICAgIHwgRU5VTSBKdXN0aWZpY2F0aW9uICAg ICAgICAgICAgIHxcCiAgICAgICAgICAgICAgICAgICAgICAgfCBTVFJJTkcgZXh0LUF1dGhvcml6 YXRpb25TdGF0dXMgfFwKICAgICAgICAgICAgICAgICAgICAgICB8IFNUUklORyBleHQtSnVzdGlm aWNhdGlvbiAgICAgICB8XAogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHxcCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tK1wKXAogICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNTogVGhl IFJlcXVlc3RTdGF0dXMgQ2xhc3NcClwKICAgVGhlIFJlcXVlc3RTdGF0dXMgY2xhc3MgaGFzIGZp dmUgYXR0cmlidXRlczpcClwKICAgICAgcmVzdHJpY3Rpb25cClwKICAgICAgICAgT1BUSU9OQUwu ICBFTlVNLiAgVGhpcyBhdHRyaWJ1dGUgaW5kaWNhdGVzIHRoZSBkaXNjbG9zdXJlXAogICAgICAg ICBndWlkZWxpbmVzIHRvIHdoaWNoIHRoZSBzZW5kZXIgZXhwZWN0cyB0aGUgcmVjaXBpZW50IHRv IGFkaGVyZS5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg MjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDE5XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFc ClwKXAogICAgICAgICBUaGlzIGd1aWRlbGluZSBwcm92aWRlcyBubyByZWFsIHNlY3VyaXR5IHNp bmNlIGl0IGlzIHRoZSBjaG9pY2VcCiAgICAgICAgIG9mIHRoZSByZWNpcGllbnQgb2YgdGhlIGRv Y3VtZW50IHRvIGhvbm9yIGl0LiAgVGhpcyBhdHRyaWJ1dGVcCiAgICAgICAgIGZvbGxvd3MgdGhl IHNhbWUgZ3VpZGVsaW5lcyBhcyAicmVzdHJpY3Rpb24iIHVzZWQgaW4gSU9ERUYuXApcCiAgICAg IEF1dGhvcml6YXRpb25TdGF0dXNcClwKICAgICAgICAgUkVRVUlSRUQuICBFTlVNLiAgVGhlIGxp c3RlZCB2YWx1ZXMgYXJlIHVzZWQgdG8gcHJvdmlkZSBhXAogICAgICAgICByZXNwb25zZSB0byB0 aGUgcmVxdWVzdGluZyBDU0lSVCBvZiB0aGUgc3RhdHVzIG9mIGFcCiAgICAgICAgIFRyYWNlUmVx dWVzdCBpbiB0aGUgY3VycmVudCBuZXR3b3JrLlwKXAogICAgICAgICAxLiAgQXBwcm92ZWQuICBU aGUgdHJhY2Ugd2FzIGFwcHJvdmVkIGFuZCB3aWxsIGJlZ2luIGluIHRoZVwKICAgICAgICAgICAg IGN1cnJlbnQgU1AuXApcCiAgICAgICAgIDIuICBEZW5pZWQuICBUaGUgdHJhY2Ugd2FzIGRlbmll ZCBpbiB0aGUgY3VycmVudCBTUC4gIFRoZSBuZXh0XAogICAgICAgICAgICAgY2xvc2VzdCBTUCBj YW4gdXNlIHRoaXMgbWVzc2FnZSB0byBmaWx0ZXIgdHJhZmZpYyBmcm9tIHRoZVwKICAgICAgICAg ICAgIHVwc3RyZWFtIFNQIHVzaW5nIHRoZSBleGFtcGxlIHBhY2tldCB0byBoZWxwIG1pdGlnYXRl IHRoZVwKICAgICAgICAgICAgIGVmZmVjdHMgb2YgdGhlIGF0dGFjayBhcyBjbG9zZSB0byB0aGUg c291cmNlIGFzIHBvc3NpYmxlLlwKICAgICAgICAgICAgIFRoZSBSZXF1ZXN0QXV0aG9yaXphdGlv biBtZXNzYWdlIG11c3QgYmUgcGFzc2VkIGJhY2sgdG8gdGhlXAogICAgICAgICAgICAgb3JpZ2lu YXRvciBhbmQgYSBSZXN1bHQgbWVzc2FnZSB1c2VkIGZyb20gdGhlIGNsb3Nlc3QgU1AgdG9cCiAg ICAgICAgICAgICB0aGUgc291cmNlIHRvIGluZGljYXRlIGFjdGlvbnMgdGFrZW4gaW4gdGhlIElP REVGIEhpc3RvcnlcCiAgICAgICAgICAgICBjbGFzcy5cClwKICAgICAgICAgMy4gIFBlbmRpbmcu ICBBd2FpdGluZyBhcHByb3ZhbDsgYSB0aW1lb3V0IHBlcmlvZCBoYXMgYmVlblwKICAgICAgICAg ICAgIHJlYWNoZWQsIHdoaWNoIHJlc3VsdGVkIGluIHRoaXMgUGVuZGluZyBzdGF0dXMgYW5kXAog ICAgICAgICAgICAgUmVxdWVzdEF1dGhvcml6YXRpb24gbWVzc2FnZSBiZWluZyBnZW5lcmF0ZWQu XApcCiAgICAgICAgIDQuICBleHQtdmFsdWUuICBBbiBlc2NhcGUgdmFsdWUgdXNlZCB0byBleHRl bmQgdGhpcyBhdHRyaWJ1dGUuXAogICAgICAgICAgICAgU2VlIElPREVGIFtSRkM1MDcwXSwgU2Vj dGlvbiA1LjEuXApcCiAgICAgICAgIEp1c3RpZmljYXRpb25cClwKICAgICAgICAgICAgT1BUSU9O QUwuICBFTlVNLiAgUHJvdmlkZXMgYSByZWFzb24gZm9yIGEgRGVuaWVkIG9yIFBlbmRpbmdcCiAg ICAgICAgICAgIG1lc3NhZ2UuXApcCiAgICAgICAgIFwKXAogICAgICAgICAxLiAgU3lzdGVtUmVz b3VyY2UuICBBIHJlc291cmNlIGlzc3VlIGV4aXN0cyBvbiB0aGUgc3lzdGVtc1wKICAgICAgICAg ICAgIHRoYXQgd291bGQgYmUgaW52b2x2ZWQgaW4gdGhlIHJlcXVlc3QuXApcCiAgICAgICAgIDIu ICBBdXRoZW50aWNhdGlvbi4gIFRoZSBlbnZlbG9wZWQgZGlnaXRhbCBzaWduYXR1cmUgW1JGQzMy NzVdXAogICAgICAgICAgICAgZmFpbGVkIHRvIHZhbGlkYXRlLlwKXAogICAgICAgICAzLiAgQXV0 aGVudGljYXRpb25PcmlnaW4uICBUaGUgZGV0YWNoZWQgZGlnaXRhbCBzaWduYXR1cmUgZm9yXAog ICAgICAgICAgICAgdGhlIG9yaWdpbmFsIHJlcXVlc3RvciBvbiB0aGUgUmVjb3JkSXRlbSBlbnRy eSBmYWlsZWQgdG9cCiAgICAgICAgICAgICB2YWxpZGF0ZS5cClwKICAgICAgICAgNC4gIEVuY3J5 cHRpb24uICBVbmFibGUgdG8gZGVjcnlwdCB0aGUgcmVxdWVzdC5cClwKXApcClwKTW9yaWFydHkg ICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1Bh Z2UgMjBdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJp cyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgICAgIDUuICBPdGhlci4g IFRoZXJlIHdlcmUgb3RoZXIgcmVhc29ucyB0aGlzIHJlcXVlc3QgY291bGQgbm90IGJlXAogICAg ICAgICAgICAgcHJvY2Vzc2VkLlwKXAogICAgICAgICA2LiAgZXh0LXZhbHVlLiAgQW4gZXNjYXBl IHZhbHVlIHVzZWQgdG8gZXh0ZW5kIHRoaXMgYXR0cmlidXRlLlwKICAgICAgICAgICAgIFNlZSBJ T0RFRiBbUkZDNTA3MF0sIFNlY3Rpb24gNS4xLlwKXAogICAgICAgICBBdXRob3JpemF0aW9uU3Rh dHVzLWV4dFwKXAogICAgICAgICAgICBPUFRJT05BTC4gIFNUUklORy4gIEEgbWVhbnMgYnkgd2hp Y2ggdG8gZXh0ZW5kIHRoZVwKICAgICAgICAgICAgQXV0aG9yaXphdGlvblN0YXR1cyBhdHRyaWJ1 dGUuICBTZWUgSU9ERUYgW1JGQzUwNzBdLCBTZWN0aW9uXAogICAgICAgICAgICA1LjEuXApcCiAg ICAgICAgIEp1c3RpZmljYXRpb24tZXh0XApcCiAgICAgICAgICAgIE9QVElPTkFMLiAgU1RSSU5H LiAgQSBtZWFucyBieSB3aGljaCB0byBleHRlbmQgdGhlXAogICAgICAgICAgICBKdXN0aWZpY2F0 aW9uIGF0dHJpYnV0ZS4gIFNlZSBJT0RFRiBbUkZDNTA3MF0sIFNlY3Rpb24gNS4xLlwKXAozLjMu ICBJbmNpZGVudFNvdXJjZVwKXAogICBUaGUgSW5jaWRlbnRTb3VyY2UgY2xhc3MgaXMgYW4gYWdn cmVnYXRlIGNsYXNzIGluIHRoZSBSSUQgY2xhc3MuXApcCiAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLStcCiAgICAgICAgICB8IEluY2lkZW50U291cmNlICAgIHxcCiAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLStcCiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHxcCiAgICAg ICAgICB8IEVOVU0gcmVzdHJpY3Rpb24gIHxcCiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg IHw8Pi0tLS0tLS0tLS0tLS1bIFNvdXJjZUZvdW5kICAgIF1cCiAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgIHxcCiAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHw8Pi0tLVx7MC4uKlx9 LS0tLVsgTm9kZSAgICAgICAgICAgXVwKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfFwK ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tK1wKXAogICAgICAgICAgICAgICAgICAgIEZp Z3VyZSA2OiBUaGUgSW5jaWRlbnRTb3VyY2UgQ2xhc3NcClwKICAgVGhlIGVsZW1lbnRzIHRoYXQg Y29uc3RpdHV0ZSB0aGUgSW5jaWRlbnRTb3VyY2UgY2xhc3MgZm9sbG93OlwKXAogICAgICBTb3Vy Y2VGb3VuZFwKXAogICAgICAgICBPbmUuIEJPT0xFQU4uICBUaGUgU291cmNlIGNsYXNzIGluZGlj YXRlcyBpZiBhIHNvdXJjZSB3YXNcCiAgICAgICAgIGlkZW50aWZpZWQuICBJZiB0aGUgc291cmNl IHdhcyBpZGVudGlmaWVkLCBpdCBpcyBsaXN0ZWQgaW4gdGhlXAogICAgICAgICBOb2RlIGVsZW1l bnQgb2YgdGhpcyBjbGFzcy5cClwKICAgICAgICAgVHJ1ZS4gIFNvdXJjZSBvZiBpbmNpZGVudCB3 YXMgaWRlbnRpZmllZC5cClwKICAgICAgICAgRmFsc2UuICBTb3VyY2Ugb2YgaW5jaWRlbnQgd2Fz IG5vdCBpZGVudGlmaWVkLlwKXApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjFdXApccGFnZSBcCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAg ICBBdWd1c3QgMjAxMVwKXApcCiAgICAgIE5vZGVcClwKICAgICAgICAgT25lLiBUaGUgTm9kZSBj bGFzcyBpcyB1c2VkIHRvIGlkZW50aWZ5IGEgaG9zdCBvciBuZXR3b3JrXAogICAgICAgICBkZXZp Y2UsIGluIHRoaXMgY2FzZSB0byBpZGVudGlmeSB0aGUgc3lzdGVtIGNvbW11bmljYXRpbmcgUklE XAogICAgICAgICBtZXNzYWdlcy5cClwKICAgICAgICAgVGhlIGJhc2UgZGVmaW5pdGlvbiBvZiB0 aGlzIGNsYXNzIGlzIHJldXNlZCBmcm9tIHRoZSBJT0RFRlwKICAgICAgICAgc3BlY2lmaWNhdGlv biBbUkZDNTA3MF0sIFNlY3Rpb24gMy4xNi5cClwKICAgICAgVGhlIEluY2lkZW50U291cmNlIGNs YXNzIGhhcyBvbmUgYXR0cmlidXRlOlwKXAogICAgICByZXN0cmljdGlvblwKXAogICAgICAgICBP UFRJT05BTC4gIEVOVU0uICBUaGlzIGF0dHJpYnV0ZSBpbmRpY2F0ZXMgdGhlIGRpc2Nsb3N1cmVc CiAgICAgICAgIGd1aWRlbGluZXMgdG8gd2hpY2ggdGhlIHNlbmRlciBleHBlY3RzIHRoZSByZWNp cGllbnQgdG8gYWRoZXJlLlwKICAgICAgICAgVGhpcyBndWlkZWxpbmUgcHJvdmlkZXMgbm8gcmVh bCBzZWN1cml0eSBzaW5jZSBpdCBpcyB0aGUgY2hvaWNlXAogICAgICAgICBvZiB0aGUgcmVjaXBp ZW50IG9mIHRoZSBkb2N1bWVudCB0byBob25vciBpdC4gIFRoaXMgYXR0cmlidXRlXAogICAgICAg ICBmb2xsb3dzIHRoZSBzYW1lIGd1aWRlbGluZXMgYXMgInJlc3RyaWN0aW9uIiB1c2VkIGluIElP REVGLlwKXAozLjQuICBSSUQgTmFtZSBTcGFjZXNcClwKICAgVGhlIFJJRCBzY2hlbWEgZGVjbGFy ZXMgYSBuYW1lc3BhY2Ugb2YgImlvZGVmLXJpZC0xLjAiIGFuZCByZWdpc3RlcnNcCiAgIGl0IHBl ciBbWE1MbmFtZXNdLiAgRWFjaCBJT0RFRi1SSUQgZG9jdW1lbnQgTVVTVCB1c2UgdGhlXAogICAi aW9kZWYtcmlkLTEuMCIgbmFtZXNwYWNlIGluIHRoZSB0b3AtbGV2ZWwgZWxlbWVudCBSSUQtRG9j dW1lbnQuICBJdFwKICAgY2FuIGJlIHJlZmVyZW5jZWQgYXMgZm9sbG93czpcClwKICAgPFJJRC1E b2N1bWVudCB2ZXJzaW9uPSIxLjAwIiBsYW5nPSJlbi1VUyJcCiAgICAgIHhtbG5zOmlvZGVmLXJp ZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi1yaWQtMS4wIlwKICAgICAgeHNpOnNjaGVt YUxvY2F0aW9uPWh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L1wK ICAgICAgc2NoZW1hL2lvZGVmLXJpZC0xLjAueHNkIj5cClwKXAo0LiAgUklEIE1lc3NhZ2VzXApc CiAgIFRoZSBJT0RFRiBtb2RlbCBpcyBmb2xsb3dlZCBhcyBzcGVjaWZpZWQgaW4gW1JGQzUwNzBd IGZvciBlYWNoIG9mIHRoZVwKICAgUklEIG1lc3NhZ2UgdHlwZXMuICBUaGUgUklEIHNjaGVtYSBp cyB1c2VkIGluIGNvbWJpbmF0aW9uIHdpdGggSU9ERUZcCiAgIGRvY3VtZW50cyB0byBmYWNpbGl0 YXRlIFJJRCBjb21tdW5pY2F0aW9ucy4gIEVhY2ggbWVzc2FnZSB0eXBlIHZhcmllc1wKICAgc2xp Z2h0bHkgaW4gZm9ybWF0IGFuZCBwdXJwb3NlOyBoZW5jZSwgdGhlIHJlcXVpcmVtZW50cyB2YXJ5 IGFuZCBhcmVcCiAgIHNwZWNpZmllZCBmb3IgZWFjaC4gIEFsbCBjbGFzc2VzLCBlbGVtZW50cywg YXR0cmlidXRlcywgZXRjLiwgdGhhdFwKICAgYXJlIGRlZmluZWQgaW4gdGhlIElPREVGLURvY3Vt ZW50IGFyZSB2YWxpZCBpbiB0aGUgY29udGV4dCBvZiBhIFJJRFwKICAgbWVzc2FnZTsgaG93ZXZl ciwgc29tZSBsaXN0ZWQgYXMgb3B0aW9uYWwgaW4gSU9ERUYgYXJlIG1hbmRhdG9yeSBmb3JcCiAg IFJJRCBhcyBsaXN0ZWQgZm9yIGVhY2ggbWVzc2FnZSB0eXBlLiAgVGhlIElPREVGIG1vZGVsIE1V U1QgYmUgZnVsbHlcCiAgIGltcGxlbWVudGVkIHRvIGVuc3VyZSBwcm9wZXIgcGFyc2luZyBvZiBh bGwgUklEIG1lc3NhZ2VzLlwKXAogICBOb3RlOiBUaGUgaW1wbGVtZW50YXRpb24gb2YgUklEIG1h eSBhdXRvbWF0ZSB0aGUgYWJpbGl0eSB0byBmaWxsIGluXAogICB0aGUgY29udGVudCByZXF1aXJl ZCBmb3IgZWFjaCBtZXNzYWdlIHR5cGUgZnJvbSBwYWNrZXQgaW5wdXQsXAogICBpbmNpZGVudCBk YXRhLCBzaXR1YXRpb25hbCBhd2FyZW5lc3MgaW5mb3JtYXRpb24sIG9yIGRlZmF1bHQgdmFsdWVz XAogICBzdWNoIGFzIHRoYXQgdXNlZCBpbiB0aGUgRXZlbnREYXRhIGNsYXNzLlwKXApcClwKTW9y aWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAg ICAgW1BhZ2UgMjJdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2 MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCjQuMS4gIFRyYWNlUmVx dWVzdFwKXAogICBEZXNjcmlwdGlvbjogVGhpcyBtZXNzYWdlIG9yIGRvY3VtZW50IGlzIHNlbnQg dG8gdGhlIG5ldHdvcmtcCiAgIG1hbmFnZW1lbnQgc3RhdGlvbiBuZXh0IGluIHRoZSB1cHN0cmVh bSB0cmFjZSBvbmNlIHRoZSB1cHN0cmVhbVwKICAgc291cmNlIG9mIHRoZSB0cmFmZmljIGhhcyBi ZWVuIGlkZW50aWZpZWQuICBUaGUgZm9sbG93aW5nIGluZm9ybWF0aW9uXAogICBpcyByZXF1aXJl ZCBmb3IgVHJhY2VSZXF1ZXN0IG1lc3NhZ2VzIGFuZCBpcyBwcm92aWRlZCB0aHJvdWdoOlwKXAog ICBSSUQgSW5mb3JtYXRpb246XApcCiAgICAgIFJJRFBvbGljeVwKXAogICAgICAgICBSSUQgbWVz c2FnZSB0eXBlLCBJbmNpZGVudElELCBhbmQgZGVzdGluYXRpb24gcG9saWN5XAogICAgICAgICBp bmZvcm1hdGlvblwKXAogICBJT0RFRiBJbmZvcm1hdGlvbjpcClwKICAgICAgVGltZSBTdGFtcHMg KERldGVjdFRpbWUsIFN0YXJ0VGltZSwgRW5kVGltZSwgUmVwb3J0VGltZSkuXApcCiAgICAgIElu Y2lkZW50IElkZW50aWZpZXIgKEluY2lkZW50IGNsYXNzLCBJbmNpZGVudElEKS5cClwKICAgICAg Q29uZmlkZW5jZSByYXRpbmcgb2Ygc2VjdXJpdHkgaW5jaWRlbnQgKEltcGFjdCBhbmQgQ29uZmlk ZW5jZVwKICAgICAgY2xhc3MpLlwKXAogICAgICBTeXN0ZW0gY2xhc3MgaXMgdXNlZCB0byBsaXN0 IGJvdGggdGhlIFNvdXJjZSBhbmQgRGVzdGluYXRpb24uXApcCiAgICAgIEV4cGVjdGF0aW9uIGNs YXNzIHNob3VsZCBiZSB1c2VkIHRvIHJlcXVlc3QgYW55IHNwZWNpZmljIGFjdGlvbnNcCiAgICAg IHRvIGJlIHRha2VuIGNsb3NlIHRvIHRoZSBzb3VyY2UuXApcCiAgICAgIFBhdGggaW5mb3JtYXRp b24gb2YgbmVzdGVkIFJJRCBzeXN0ZW1zLCBiZWdpbm5pbmcgd2l0aCB0aGUgcmVxdWVzdFwKICAg ICAgb3JpZ2luYXRvciB1c2VkIGluIHRoZSB0cmFjZSB1c2luZyBJT0RFRiBFdmVudERhdGEgd2l0 aCBjYXRlZ29yeVwKICAgICAgc2V0IHRvICJpbmZyYXN0cnVjdHVyZSIuXApcCiAgICAgIEV2ZW50 LCBSZWNvcmQsIGFuZCBSZWNvcmRJdGVtIGNsYXNzZXMgdG8gaW5jbHVkZSBleGFtcGxlIHBhY2tl dHNcCiAgICAgIGFuZCBvdGhlciBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBpbmNpZGVudC4g IE5vdGU6IEV2ZW50XAogICAgICBpbmZvcm1hdGlvbiBpbmNsdWRlZCBoZXJlIHJlcXVpcmVzIGEg c2Vjb25kIGluc3RhbmNlIG9mIEV2ZW50RGF0YVwKICAgICAgaW4gYWRkaXRpb24gdG8gdGhhdCB1 c2VkIHRvIGNvbnZleSBzZXJ2aWNlL25ldHdvcmsgcHJvdmlkZXIgKFNQKVwKICAgICAgcGF0aCBj b250YWN0IGluZm9ybWF0aW9uLlwKXAogICBTdGFuZGFyZHMgZm9yIGVuY3J5cHRpb24gYW5kIGRp Z2l0YWwgc2lnbmF0dXJlcyBbUkZDMzI3NV0sIFtYTUxzaWddOlwKXAogICAgICBEaWdpdGFsIHNp Z25hdHVyZSBmcm9tIGluaXRpYXRpbmcgQ1NJUlQgb3IgcHJvdmlkZXIgc3lzdGVtIHNlbmRpbmdc CiAgICAgIHRoZSBSSUQgbWVzc2FnZSwgcGFzc2VkIHRvIGFsbCBzeXN0ZW1zIGluIHVwc3RyZWFt IHRyYWNlIHVzaW5nIGFcCiAgICAgIGRldGFjaGVkIFhNTCBkaWdpdGFsIHNpZ25hdHVyZSBvbiBh IFJlY29yZEl0ZW0gZW50cnkuXApcCiAgICAgIERpZ2l0YWwgc2lnbmF0dXJlIG9mIHNlbmRpbmcg Q1NJUlQgb3IgU1AgZm9yIGF1dGhlbnRpY2l0eSBvZiB0aGVcCiAgICAgIFJJRCBtZXNzYWdlLCBm cm9tIHRoZSBDU0lSVCBvciBwcm92aWRlciBjcmVhdGluZyB0aGlzIG1lc3NhZ2VcCiAgICAgIHVz aW5nIGFuIGVudmVsb3BlZCBYTUwgZGlnaXRhbCBzaWduYXR1cmUgb24gdGhlIElPREVGIGRvY3Vt ZW50LlwKXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2 LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyM11cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApc ClwKICAgICAgWE1MIGVuY3J5cHRpb24gYXMgcmVxdWlyZWQgYnkgcG9saWN5LCBhZ3JlZW1lbnRz LCBhbmQgZGF0YVwKICAgICAgbWFya2Vycy5cClwKICAgQSBERG9TIGF0dGFjayBjYW4gaGF2ZSBt YW55IHNvdXJjZXMsIHJlc3VsdGluZyBpbiBtdWx0aXBsZSB0cmFjZXMgdG9cCiAgIGxvY2F0ZSB0 aGUgc291cmNlcyBvZiB0aGUgYXR0YWNrLiAgSXQgbWF5IGJlIHZhbGlkIHRvIGNvbnRpbnVlXAog ICBtdWx0aXBsZSB0cmFjZXMgZm9yIGEgc2luZ2xlIGF0dGFjay4gIFRoZSBwYXRoIGluZm9ybWF0 aW9uIHdvdWxkXAogICBlbmFibGUgdGhlIGFkbWluaXN0cmF0b3JzIHRvIGRldGVybWluZSBpZiB0 aGUgZXhhY3QgdHJhY2UgaGFkIGFscmVhZHlcCiAgIHBhc3NlZCB0aHJvdWdoIGEgc2luZ2xlIG5l dHdvcmsuICBUaGUgSW5jaWRlbnQgSWRlbnRpZmllciBtdXN0IGFsc29cCiAgIGJlIHVzZWQgdG8g aWRlbnRpZnkgbXVsdGlwbGUgVHJhY2VSZXF1ZXN0cyBmcm9tIGEgc2luZ2xlIGluY2lkZW50LlwK ICAgSWYgYSBzaW5nbGUgVHJhY2VSZXF1ZXN0IHJlc3VsdHMgaW4gZGl2ZXJnZW50IHBhdGhzIG9m IFRyYWNlUmVxdWVzdHMsXAogICBhIHNlcGFyYXRlIGluc3RhbmNlIG51bWJlciBNVVNUIGJlIHVz ZWQgdW5kZXIgdGhlIHNhbWUgSW5jaWRlbnRJRC5cCiAgIFRoZSBJbmNpZGVudElEIGluc3RhbmNl IG51bWJlciBvZiBJT0RFRiBjYW4gYmUgdXNlZCB0byBjb3JyZWxhdGVcCiAgIHJlbGF0ZWQgaW5j aWRlbnQgZGF0YSB0aGF0IGlzIHBhcnQgb2YgYSBsYXJnZXIgaW5jaWRlbnQuXApcCjQuMi4gIFJl cXVlc3RBdXRob3JpemF0aW9uXApcCiAgIERlc2NyaXB0aW9uOiBUaGlzIG1lc3NhZ2UgaXMgc2Vu dCB0byB0aGUgaW5pdGlhdGluZyBSSUQgc3lzdGVtIGZyb21cCiAgIHRoZSBuZXh0IHVwc3RyZWFt IHByb3ZpZGVyJ3MgYXBwbGljYXRpb24gb3Igc3lzdGVtIGRlc2lnbmF0ZWQgZm9yXAogICBhY2Nl cHRpbmcgUklEIGNvbW11bmljYXRpb25zIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gb24gdGhlIHJl cXVlc3RcCiAgIHN0YXR1cyBpbiB0aGUgY3VycmVudCBuZXR3b3JrLlwKXAogICBUaGUgZm9sbG93 aW5nIGluZm9ybWF0aW9uIGlzIHJlcXVpcmVkIGZvciBSZXF1ZXN0QXV0aG9yaXphdGlvblwKICAg bWVzc2FnZXMgYW5kIGlzIHByb3ZpZGVkIHRocm91Z2g6XApcCiAgIFJJRCBJbmZvcm1hdGlvbjpc ClwKICAgICAgUklEUG9saWN5XApcCiAgICAgICAgIFJJRCBtZXNzYWdlIHR5cGUsIEluY2lkZW50 SUQsIGFuZCBkZXN0aW5hdGlvbiBwb2xpY3lcCiAgICAgICAgIGluZm9ybWF0aW9uXApcCiAgICAg IFJlcXVlc3RTdGF0dXMgY2xhc3M6XApcCiAgICAgICAgIFN0YXR1cyBvZiBUcmFjZVJlcXVlc3Rc ClwKICAgU3RhbmRhcmRzIGZvciBlbmNyeXB0aW9uIGFuZCBkaWdpdGFsIHNpZ25hdHVyZXMgW1JG QzMyNzVdLCBbWE1Mc2lnXTpcClwKICAgICAgRGlnaXRhbCBzaWduYXR1cmUgb2YgcmVzcG9uZGlu ZyBDU0lSVCBvciBwcm92aWRlciBmb3IgYXV0aGVudGljaXR5XAogICAgICBvZiBUcmFjZSBTdGF0 dXMgTWVzc2FnZSwgZnJvbSB0aGUgQ1NJUlQgb3IgcHJvdmlkZXIgY3JlYXRpbmcgdGhpc1wKICAg ICAgbWVzc2FnZSB1c2luZyBhbiBlbnZlbG9wZWQgWE1MIGRpZ2l0YWwgc2lnbmF0dXJlLlwKXAog ICAgICBYTUwgZW5jcnlwdGlvbiBhcyByZXF1aXJlZCBieSBwb2xpY3ksIGFncmVlbWVudHMsIGFu ZCBkYXRhXAogICAgICBtYXJrZXJzLlwKXAogICBBIG1lc3NhZ2UgaXMgc2VudCBiYWNrIHRvIHRo ZSBpbml0aWF0aW5nIENTSVJUIG9yIHByb3ZpZGVyJ3Mgc3lzdGVtXAogICBhY2NlcHRpbmcgUklE IGNvbW11bmljYXRpb25zIG9mIHRoZSB0cmFjZSBhcyBzdGF0dXMgbm90aWZpY2F0aW9uLlwKICAg VGhpcyBtZXNzYWdlIHZlcmlmaWVzIHRoYXQgdGhlIG5leHQgUklEIHN5c3RlbSBpbiB0aGUgcGF0 aCBoYXNcCiAgIHJlY2VpdmVkIHRoZSBtZXNzYWdlIGZyb20gdGhlIHByZXZpb3VzIHN5c3RlbSBp biB0aGUgcGF0aC4gIFRoaXNcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDI0XVwKXHBhZ2UgXApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVn dXN0IDIwMTFcClwKXAogICBtZXNzYWdlIGFsc28gdmVyaWZpZXMgdGhhdCB0aGUgdHJhY2UgaXMg bm93IGNvbnRpbnVpbmcsIGhhcyBzdG9wcGVkLFwKICAgb3IgaXMgcGVuZGluZyBpbiB0aGUgbmV4 dCB1cHN0cmVhbSBDU0lSVCBvciBwcm92aWRlcidzIFJJRCBzeXN0ZW0uXAogICBUaGUgUGVuZGlu ZyBzdGF0dXMgd291bGQgYmUgYXV0b21hdGljYWxseSBnZW5lcmF0ZWQgYWZ0ZXIgYSAyLW1pbnV0 ZVwKICAgdGltZW91dCB3aXRob3V0IHN5c3RlbS1wcmVkZWZpbmVkIG9yIGFkbWluaXN0cmF0b3Ig YWN0aW9uIHRha2VuIHRvXAogICBhcHByb3ZlIG9yIGRpc2FwcHJvdmUgdGhlIHRyYWNlIGNvbnRp bnVhbmNlLiAgSWYgYSBSZXF1ZXN0IGlzIGRlbmllZCxcCiAgIHRoZSBvcmlnaW5hdG9yIGFuZCBz ZW5kaW5nIHBlZXIgKGlmIHRoZXkgYXJlIG5vdCB0aGUgc2FtZSkgc2hhbGwgYm90aFwKICAgcmVj ZWl2ZSB0aGUgbWVzc2FnZS4gIFRoaXMgZW5hYmxlcyB0aGUgc2VuZGluZyBwZWVyIHRoZSBvcHRp b24gdG9cCiAgIHRha2UgYWN0aW9uIHRvIHN0b3Agb3IgbWl0aWdhdGUgdGhlIHRyYWZmaWMgYXMg Y2xvc2UgdG8gdGhlIHNvdXJjZSBhc1wKICAgcG9zc2libGUuXApcCjQuMy4gIFJlc3VsdFwKXAog ICBEZXNjcmlwdGlvbjogVGhpcyBtZXNzYWdlIGluZGljYXRlcyB0aGF0IHRoZSB0cmFjZSBvciBp bnZlc3RpZ2F0aW9uXAogICBoYXMgYmVlbiBjb21wbGV0ZWQgYW5kIHByb3ZpZGVzIHRoZSByZXN1 bHQuICBUaGUgUmVzdWx0IG1lc3NhZ2VcCiAgIGluY2x1ZGVzIGluZm9ybWF0aW9uIG9uIHdoZXRo ZXIgb3Igbm90IGEgc291cmNlIHdhcyBmb3VuZCBhbmQgdGhlXAogICBzb3VyY2UgaW5mb3JtYXRp b24gdGhyb3VnaCB0aGUgSW5jaWRlbnRTb3VyY2UgY2xhc3MuICBUaGUgUmVzdWx0XAogICBpbmZv cm1hdGlvbiBzaGFsbCBnbyBiYWNrIHRvIHRoZSBvcmlnaW5hdGluZyBSSUQgc3lzdGVtIHRoYXQg YmVnYW5cCiAgIHRoZSBpbnZlc3RpZ2F0aW9uIG9yIHRyYWNlLiAgQW4gcHJvdmlkZXIgbWF5IHVz ZSBhbnkgbnVtYmVyIG9mXAogICBpbmNpZGVudCBoYW5kbGluZyBkYXRhIHNvdXJjZXMgdG8gYXNj ZXJ0YWluIHRoZSB0cnVlIHNvdXJjZSBvZiBhblwKICAgYXR0YWNrLiAgQWxsIG9mIHRoZSBwb3Nz aWJsZSBpbmZvcm1hdGlvbiBzb3VyY2VzIG1heSBvciBtYXkgbm90IGJlXAogICByZWFkaWx5IHRp ZWQgaW50byB0aGUgUklEIGNvbW11bmljYXRpb25zIHN5c3RlbS5cClwKICAgVGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCBmb3IgUmVzdWx0IG1lc3NhZ2VzIGFuZCB3aWxsIGJl XAogICBwcm92aWRlZCB0aHJvdWdoOlwKXAogICAgICBSSUQgSW5mb3JtYXRpb246XApcCiAgICAg ICAgIFJJRFBvbGljeVwKXAogICAgICAgICAgICBSSUQgbWVzc2FnZSB0eXBlLCBJbmNpZGVudElE LCBhbmQgZGVzdGluYXRpb24gcG9saWN5XAogICAgICAgICAgICBpbmZvcm1hdGlvblwKXAogICAg ICAgICBJbmNpZGVudCBTb3VyY2VcClwKICAgICAgICAgICAgVGhlIEluY2lkZW50U291cmNlIGNs YXNzIG9mIHRoZSBSSUQgc2NoZW1hIGlzIHVzZWQgdG8gbm90ZVwKICAgICAgICAgICAgaWYgYSBz b3VyY2Ugd2FzIGlkZW50aWZpZWQgYW5kIHByb3ZpZGUgdGhlIHNvdXJjZVwKICAgICAgICAgICAg YWRkcmVzcyhlcykuXApcCiAgICAgIElPREVGIEluZm9ybWF0aW9uOlwKXAogICAgICAgICBUaW1l IFN0YW1wcyAoRGV0ZWN0VGltZSwgU3RhcnRUaW1lLCBFbmRUaW1lLCBSZXBvcnRUaW1lKS5cClwK ICAgICAgICAgSW5jaWRlbnQgSWRlbnRpZmllciAoSW5jaWRlbnQgY2xhc3MsIEluY2lkZW50SUQp LlwKXAogICAgICAgICAgICBUcmFjZSBudW1iZXIgLSB1c2VkIGZvciBtdWx0aXBsZSB0cmFjZXMg b2YgYSBzaW5nbGVcCiAgICAgICAgICAgIGluY2lkZW50OyBtdXN0IGJlIG5vdGVkLlwKXApcClwK XApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDI1XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICAg ICBDb25maWRlbmNlIHJhdGluZyBvZiBzZWN1cml0eSBpbmNpZGVudCAoSW1wYWN0IGFuZCBDb25m aWRlbmNlXAogICAgICAgICBjbGFzcykuXApcCiAgICAgICAgIFN5c3RlbSBjbGFzcyBpcyB1c2Vk IHRvIGxpc3QgYm90aCB0aGUgU291cmNlIGFuZCBEZXN0aW5hdGlvblwKICAgICAgICAgSW5mb3Jt YXRpb24gdXNlZCBpbiB0aGUgYXR0YWNrIGFuZCBtdXN0IG5vdGUgaWYgdGhlIHRyYWZmaWMgaXNc CiAgICAgICAgIHNwb29mZWQsIHRodXMgcmVxdWlyaW5nIGFuIHVwc3RyZWFtIFRyYWNlUmVxdWVz dCBpbiBSSUQuXApcCiAgICAgICAgIEhpc3RvcnkgY2xhc3MgImF0eXBlIiBhdHRyaWJ1dGUgaXMg dXNlZCB0byBub3RlIGFueSBhY3Rpb25zXAogICAgICAgICB0YWtlbi5cClwKICAgICAgICAgSGlz dG9yeSBjbGFzcyBhbHNvIG5vdGVzIGFueSBvdGhlciBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uXAog ICAgICAgICBpbmNsdWRpbmcgbm90ZXMgYWJvdXQgdGhlIGNvbmZpZGVuY2UgbGV2ZWwgb3IgcmF0 aW5nIG9mIHRoZVwKICAgICAgICAgcmVzdWx0IGluZm9ybWF0aW9uLlwKXAogICAgICAgICBQYXRo IGluZm9ybWF0aW9uIG9mIG5lc3RlZCBSSUQgc3lzdGVtcywgYmVnaW5uaW5nIHdpdGggdGhlXAog ICAgICAgICByZXF1ZXN0IG9yaWdpbmF0b3IgdXNlZCBpbiB0aGUgdHJhY2UgdXNpbmcgSU9ERUYg RXZlbnREYXRhIHdpdGhcCiAgICAgICAgIGNhdGVnb3J5IHNldCB0byAiaW5mcmFzdHJ1Y3R1cmUi LiAgVGhlIGxhc3QgU1AgbGlzdGVkIGlzIHRoZSBTUFwKICAgICAgICAgdGhhdCBsb2NhdGVkIHRo ZSBzb3VyY2Ugb2YgdGhlIHRyYWZmaWMgKHRoZSBwcm92aWRlciBzZW5kaW5nXAogICAgICAgICB0 aGUgUmVzdWx0IG1lc3NhZ2UpLlwKXAogICAgICAgICBFdmVudCwgUmVjb3JkLCBhbmQgUmVjb3Jk SXRlbSBjbGFzc2VzIHRvIGluY2x1ZGUgZXhhbXBsZVwKICAgICAgICAgcGFja2V0cyBhbmQgb3Ro ZXIgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgaW5jaWRlbnRcCiAgICAgICAgIChvcHRpb25h bCkuICBOb3RlOiBFdmVudCBpbmZvcm1hdGlvbiBpbmNsdWRlZCBoZXJlIHJlcXVpcmVzIGFcCiAg ICAgICAgIHNlY29uZCBpbnN0YW5jZSBvZiBFdmVudERhdGEgaW4gYWRkaXRpb24gdG8gdGhhdCB1 c2VkIHRvIGNvbnZleVwKICAgICAgICAgU1AgcGF0aCBjb250YWN0IGluZm9ybWF0aW9uLlwKXAog ICAgICBTdGFuZGFyZHMgZm9yIGVuY3J5cHRpb24gYW5kIGRpZ2l0YWwgc2lnbmF0dXJlcyBbUkZD MzI3NV06XApcCiAgICAgICAgIERpZ2l0YWwgc2lnbmF0dXJlIG9mIHNvdXJjZSBDU0lSVCBvciBw cm92aWRlciBmb3IgYXV0aGVudGljaXR5XAogICAgICAgICBvZiBSZXN1bHQgbWVzc2FnZSwgZnJv bSB0aGUgQ1NJUlQgb3IgcHJvdmlkZXIgY3JlYXRpbmcgdGhpc1wKICAgICAgICAgbWVzc2FnZSB1 c2luZyBhbiBlbnZlbG9wZWQgWE1MIGRpZ2l0YWwgc2lnbmF0dXJlLlwKXAogICAgICAgICBYTUwg ZW5jcnlwdGlvbiBhcyByZXF1aXJlZCBieSBwb2xpY3ksIGFncmVlbWVudHMsIGFuZCBkYXRhXAog ICAgICAgICBtYXJrZXJzLlwKXAogICBBIG1lc3NhZ2UgaXMgc2VudCBiYWNrIHRvIHRoZSBpbml0 aWF0aW5nIENTSVJUIG9yIHByb3ZpZGVyJ3MgUklEXAogICBzeXN0ZW0gdG8gbm90aWZ5IHRoZSBD U0lSVCB0aGF0IHRoZSBzb3VyY2UgaGFzIGJlZW4gbG9jYXRlZC4gIFRoZVwKICAgYWN0dWFsIHNv dXJjZSBpbmZvcm1hdGlvbiBtYXkgb3IgbWF5IG5vdCBiZSBpbmNsdWRlZCwgZGVwZW5kaW5nIG9u XAogICB0aGUgcG9saWN5IG9mIHRoZSBuZXR3b3JrIGluIHdoaWNoIHRoZSBjbGllbnQgb3IgaG9z dCBpcyBhdHRhY2hlZC5cCiAgIEFueSBhY3Rpb24gdGFrZW4gYnkgdGhlIFNQIHRvIGFjdCB1cG9u IHRoZSBkaXNjb3Zlcnkgb2YgdGhlIHNvdXJjZSBvZlwKICAgYSB0cmFjZSBzaG91bGQgYmUgaW5j bHVkZWQuICBUaGUgU1AgbWF5IGJlIGFibGUgdG8gYXV0b21hdGUgdGhlXAogICBhZGp1c3RtZW50 IG9mIGZpbHRlcnMgYXQgdGhlaXIgYm9yZGVyIHJvdXRlciB0byBibG9jayBvdXRib3VuZCBhY2Nl c3NcCiAgIGZvciB0aGUgbWFjaGluZShzKSBkaXNjb3ZlcmVkIGFzIGEgcGFydCBvZiB0aGUgYXR0 YWNrLiAgVGhlIGZpbHRlcnNcCiAgIG1heSBiZSBjb21wcmVoZW5zaXZlIGVub3VnaCB0byBibG9j ayBhbGwgSW50ZXJuZXQgYWNjZXNzIHVudGlsIHRoZVwKICAgaG9zdCBoYXMgdGFrZW4gdGhlIGFw cHJvcHJpYXRlIGFjdGlvbiB0byByZXNvbHZlIGFueSBzZWN1cml0eSBpc3N1ZXNcCiAgIG9yIHRv IHJhdGUtbGltaXQgdGhlIGluZ3Jlc3MgdHJhZmZpYyBhcyBjbG9zZSB0byB0aGUgc291cmNlIGFz XAogICBwb3NzaWJsZS5cClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjZdXApccGFnZSBcCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1 c3QgMjAxMVwKXApcCiAgIFNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGRpc2N1 c3NlZCBpbiBTZWN0aW9uIDYgc2hhbGwgYmVcCiAgIHRha2VuIGludG8gYWNjb3VudC5cClwKICAg Tm90ZTogVGhlIEhpc3RvcnkgY2xhc3MgaGFzIGJlZW4gZXhwYW5kZWQgaW4gSU9ERUYgdG8gYWNj b21tb2RhdGUgYWxsXAogICBvZiB0aGUgcG9zc2libGUgYWN0aW9ucyB0YWtlbiBhcyBhIHJlc3Vs dCBvZiBhIFJJRCBUcmFjZVJlcXVlc3Qgb3JcCiAgIEludmVzdGlnYXRpb24gcmVxdWVzdCB1c2lu ZyB0aGUgImlvZGVmOmF0eXBlIiwgb3IgYWN0aW9uIHR5cGUsXAogICBhdHRyaWJ1dGUuICBUaGUg SGlzdG9yeSBjbGFzcyBzaG91bGQgYmUgdXNlZCB0byBub3RlIGFsbCBhY3Rpb25zXAogICB0YWtl biBjbG9zZSB0byB0aGUgc291cmNlIG9mIGEgdHJhY2Ugb3IgaW5jaWRlbnQgdXNpbmcgdGhlIG1v c3RcCiAgIGFwcHJvcHJpYXRlIG9wdGlvbiBmb3IgdGhlIHR5cGUgb2YgYWN0aW9uIGFsb25nIHdp dGggYSBkZXNjcmlwdGlvbi5cCiAgIFRoZSAiYXR5cGUiIGF0dHJpYnV0ZSBpbiB0aGUgRXhwZWN0 YXRpb24gY2xhc3MgY2FuIGFsc28gYmUgdXNlZCB0b1wKICAgcmVxdWVzdCBhbiBhcHByb3ByaWF0 ZSBhY3Rpb24gd2hlbiBhIFRyYWNlUmVxdWVzdCBvciBJbnZlc3RpZ2F0aW9uXAogICByZXF1ZXN0 IGlzIG1hZGUuXApcCjQuNC4gIEludmVzdGlnYXRpb24gUmVxdWVzdFwKXAogICBEZXNjcmlwdGlv bjogVGhpcyBtZXNzYWdlIHR5cGUgaXMgdXNlZCB3aGVuIHRoZSBzb3VyY2Ugb2YgdGhlIHRyYWZm aWNcCiAgIGlzIGJlbGlldmVkIG5vdCB0byBiZSBzcG9vZmVkLiAgVGhlIHB1cnBvc2Ugb2YgdGhl IEludmVzdGlnYXRpb25cCiAgIHJlcXVlc3QgbWVzc2FnZSBpcyB0byBsZXZlcmFnZSB0aGUgZXhp c3RpbmcgYmlsYXRlcmFsIHBlZXJcCiAgIHJlbGF0aW9uc2hpcHMgaW4gb3JkZXIgdG8gbm90aWZ5 IHRoZSBuZXR3b3JrIHByb3ZpZGVyIGNsb3Nlc3QgdG8gdGhlXAogICBzb3VyY2Ugb2YgdGhlIHZh bGlkIHRyYWZmaWMgdGhhdCBzb21lIGV2ZW50IG9jY3VycmVkLCB3aGljaCBtYXkgYmUgYVwKICAg c2VjdXJpdHktcmVsYXRlZCBpbmNpZGVudC5cClwKICAgVGhlIGZvbGxvd2luZyBpbmZvcm1hdGlv biBpcyByZXF1aXJlZCBmb3IgSW52ZXN0aWdhdGlvbiByZXF1ZXN0XAogICBtZXNzYWdlcyBhbmQg aXMgcHJvdmlkZWQgdGhyb3VnaDpcClwKICAgICAgUklEIEluZm9ybWF0aW9uOlwKXAogICAgICAg ICBSSUQgUG9saWN5XApcCiAgICAgICAgICAgIFJJRCBtZXNzYWdlIHR5cGUsIEluY2lkZW50SUQs IGFuZCBkZXN0aW5hdGlvbiBwb2xpY3lcCiAgICAgICAgICAgIGluZm9ybWF0aW9uXApcCiAgICAg IElPREVGIEluZm9ybWF0aW9uOlwKXAogICAgICAgICBUaW1lIFN0YW1wcyAoRGV0ZWN0VGltZSwg U3RhcnRUaW1lLCBFbmRUaW1lLCBSZXBvcnRUaW1lKS5cClwKICAgICAgICAgSW5jaWRlbnQgSWRl bnRpZmllciAoSW5jaWRlbnQgY2xhc3MsIEluY2lkZW50SUQpLlwKXAogICAgICAgICAgICBUcmFj ZSBudW1iZXIgLSB1c2VkIGZvciBtdWx0aXBsZSB0cmFjZXMgb2YgYSBzaW5nbGVcCiAgICAgICAg ICAgIGluY2lkZW50OyBtdXN0IGJlIG5vdGVkLlwKXAogICAgICAgICBDb25maWRlbmNlIHJhdGlu ZyBvZiBzZWN1cml0eSBpbmNpZGVudCAoSW1wYWN0IGFuZCBDb25maWRlbmNlXAogICAgICAgICBj bGFzcykuXApcCiAgICAgICAgIFN5c3RlbSBjbGFzcyBpcyB1c2VkIHRvIGxpc3QgYm90aCB0aGUg U291cmNlIGFuZCBEZXN0aW5hdGlvblwKICAgICAgICAgSW5mb3JtYXRpb24gdXNlZCBpbiB0aGUg YXR0YWNrIGFuZCBtdXN0IG5vdGUgaWYgdGhlIHRyYWZmaWMgaXNcCiAgICAgICAgIHNwb29mZWQs IHRodXMgcmVxdWlyaW5nIGFuIHVwc3RyZWFtIFRyYWNlUmVxdWVzdCBpbiBSSUQuXApcClwKXApc Ck1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAg ICAgICAgIFtQYWdlIDI3XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg UkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICAgICBF eHBlY3RhdGlvbiBjbGFzcyBzaG91bGQgYmUgdXNlZCB0byByZXF1ZXN0IGFueSBzcGVjaWZpY1wK ICAgICAgICAgYWN0aW9ucyB0byBiZSB0YWtlbiBjbG9zZSB0byB0aGUgc291cmNlLlwKXAogICAg ICAgICBQYXRoIGluZm9ybWF0aW9uIG9mIG5lc3RlZCBzeXN0ZW1zIGNvbW11bmljYXRpbmcgdmlh IFJJRFwKICAgICAgICAgbWVzc2FnZXMsIGJlZ2lubmluZyB3aXRoIHRoZSByZXF1ZXN0IG9yaWdp bmF0b3IgdXNlZCBpbiB0aGVcCiAgICAgICAgIHRyYWNlIHVzaW5nIElPREVGIEV2ZW50RGF0YSB3 aXRoIGNhdGVnb3J5IHNldCB0b1wKICAgICAgICAgImluZnJhc3RydWN0dXJlIi5cClwKICAgICAg ICAgRXZlbnQsIFJlY29yZCwgYW5kIFJlY29yZEl0ZW0gY2xhc3NlcyB0byBpbmNsdWRlIGV4YW1w bGVcCiAgICAgICAgIHBhY2tldHMgYW5kIG90aGVyIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhl IGluY2lkZW50LiAgTm90ZTpcCiAgICAgICAgIEV2ZW50IGluZm9ybWF0aW9uIGluY2x1ZGVkIGhl cmUgcmVxdWlyZXMgYSBzZWNvbmQgaW5zdGFuY2Ugb2ZcCiAgICAgICAgIEV2ZW50RGF0YSBpbiBh ZGRpdGlvbiB0byB0aGF0IHVzZWQgdG8gY29udmV5IFNQIHBhdGggY29udGFjdFwKICAgICAgICAg aW5mb3JtYXRpb24uXApcCiAgICAgIFN0YW5kYXJkcyBmb3IgZW5jcnlwdGlvbiBhbmQgZGlnaXRh bCBzaWduYXR1cmVzIFtSRkMzMjc1XTpcClwKICAgICAgICAgRGlnaXRhbCBzaWduYXR1cmUgZnJv bSBpbml0aWF0aW5nIHN5c3RlbSBzZW5kaW5nIHRoZSBSSURcCiAgICAgICAgIG1lc3NhZ2UsIHBh c3NlZCB0byBhbGwgc3lzdGVtcyBpbnZvbHZlZCBpbiB0aGUgaW52ZXN0aWdhdGlvblwKICAgICAg ICAgdXNpbmcgYSBkZXRhY2hlZCBYTUwgZGlnaXRhbCBzaWduYXR1cmUgb24gYSBSZWNvcmRJdGVt IGVudHJ5LlwKXAogICAgICAgICBEaWdpdGFsIHNpZ25hdHVyZSBvZiBzZW5kaW5nIENTSVJUIG9y IFNQIGZvciBhdXRoZW50aWNpdHkgb2ZcCiAgICAgICAgIHRoZSBSSUQgbWVzc2FnZSwgZnJvbSB0 aGUgQ1NJUlQgb3IgcHJvdmlkZXIgc2VuZGluZyB0aGlzXAogICAgICAgICBtZXNzYWdlIHVzaW5n IGFuIGVudmVsb3BlZCBYTUwgZGlnaXRhbCBzaWduYXR1cmUgb24gdGhlIElPREVGXAogICAgICAg ICBkb2N1bWVudC5cClwKICAgICAgICAgWE1MIGVuY3J5cHRpb24gYXMgcmVxdWlyZWQgYnkgcG9s aWN5LCBhZ3JlZW1lbnRzLCBhbmQgZGF0YVwKICAgICAgICAgbWFya2Vycy5cClwKICAgU2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgd291bGQgaW5jbHVkZSB0aGUgYWJpbGl0eSB0byBlbmNyeXB0XAog ICBbWE1MZW5jcnlwdF0gdGhlIGNvbnRlbnRzIG9mIHRoZSBJbnZlc3RpZ2F0aW9uIHJlcXVlc3Qg bWVzc2FnZSB1c2luZ1wKICAgdGhlIHB1YmxpYyBrZXkgb2YgdGhlIGRlc3RpbmF0aW9uIFJJRCBz eXN0ZW0uICBUaGUgaW5jaWRlbnQgbnVtYmVyXAogICB3b3VsZCBpbmNyZWFzZSBhcyBpZiBpdCB3 ZXJlIGEgVHJhY2VSZXF1ZXN0IG1lc3NhZ2UgaW4gb3JkZXIgdG9cCiAgIGVuc3VyZSB1bmlxdWVu ZXNzIHdpdGhpbiB0aGUgc3lzdGVtLiAgVGhlIHJlbGF5aW5nIHBlZXJzIHdvdWxkIGFsc29cCiAg IGFwcGVuZCB0aGVpciBBdXRvbm9tb3VzIFN5c3RlbSAoQVMpIG9yIFJJRCBzeXN0ZW0gaW5mb3Jt YXRpb24gYXMgdGhlXAogICByZXF1ZXN0IG1lc3NhZ2Ugd2FzIHJlbGF5ZWQgYWxvbmcgdGhlIHdl YiBvZiBuZXR3b3JrIHByb3ZpZGVycyBzb1wKICAgdGhhdCB0aGUgUmVzdWx0IG1lc3NhZ2UgY291 bGQgdXRpbGl6ZSB0aGUgc2FtZSBwYXRoIGFzIHRoZSBzZXQgb2ZcCiAgIHRydXN0IHJlbGF0aW9u c2hpcHMgZm9yIHRoZSByZXR1cm4gbWVzc2FnZSwgdGh1cyBpbmRpY2F0aW5nIGFueVwKICAgYWN0 aW9ucyB0YWtlbi4gIFRoZSByZXF1ZXN0IHdvdWxkIGFsc28gYmUgcmVjb3JkZWQgaW4gdGhlIHN0 YXRlXAogICB0YWJsZXMgb2YgYm90aCB0aGUgaW5pdGlhdGluZyBhbmQgZGVzdGluYXRpb24gU1Ag UklEIHN5c3RlbXMuICBUaGVcCiAgIGRlc3RpbmF0aW9uIFNQIGlzIHJlc3BvbnNpYmxlIGZvciBh bnkgYWN0aW9ucyB0YWtlbiBhcyBhIHJlc3VsdCBvZlwKICAgdGhlIHJlcXVlc3QgaW4gYWRoZXJl bmNlIHRvIGFueSBzZXJ2aWNlIGxldmVsIGFncmVlbWVudHMgb3IgaW50ZXJuYWxcCiAgIHBvbGlj aWVzLiAgVGhlIFNQIHNob3VsZCBjb25maXJtIHRoYXQgdGhlIHRyYWZmaWMgYWN0dWFsbHkgb3Jp Z2luYXRlZFwKICAgZnJvbSB0aGUgc3VzcGVjdGVkIHN5c3RlbSBiZWZvcmUgdGFraW5nIGFueSBh Y3Rpb24gYW5kIGNvbmZpcm0gdGhlXAogICByZWFzb24gZm9yIHRoZSByZXF1ZXN0LiAgVGhlIHJl cXVlc3QgbWF5IGJlIHNlbnQgZGlyZWN0bHkgdG8gYSBrbm93blwKICAgUklEIHN5c3RlbSBvciBy b3V0ZWQgYnkgdGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBhdHRhY2sgdXNpbmcgdGhlXAogICBt ZXNzYWdlIGRlc3RpbmF0aW9uIG9mIFJJRFBvbGljeSwgU291cmNlT2ZJbmNpZGVudC4gIE5vdGU6 IEFsbFwKICAgaW50ZXJtZWRpYXRlIHBhcnRpZXMgbXVzdCBiZSBhYmxlIHRvIHZpZXcgUklEUG9s aWN5IGluZm9ybWF0aW9uIGluXAogICBvcmRlciB0byBwcm9wZXJseSBkaXJlY3QgUklEIG1lc3Nh Z2VzLlwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwg MjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjhdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApc CjQuNS4gIFJlcG9ydFwKXAogICBEZXNjcmlwdGlvbjogVGhpcyBtZXNzYWdlIG9yIGRvY3VtZW50 IGlzIHNlbnQgdG8gYSBSSUQgc3lzdGVtIHRvXAogICBwcm92aWRlIGEgcmVwb3J0IG9mIGEgc2Vj dXJpdHkgaW5jaWRlbnQuICBUaGlzIG1lc3NhZ2UgZG9lcyBub3RcCiAgIHJlcXVpcmUgYW55IGFj dGlvbnMgdG8gYmUgdGFrZW4sIGV4Y2VwdCB0byBmaWxlIHRoZSByZXBvcnQgb24gdGhlXAogICBy ZWNlaXZpbmcgUklEIHN5c3RlbSBvciBhc3NvY2lhdGVkIGRhdGFiYXNlLlwKXAogICBUaGUgZm9s bG93aW5nIGluZm9ybWF0aW9uIGlzIHJlcXVpcmVkIGZvciBSZXBvcnQgbWVzc2FnZXMgYW5kIHdp bGwgYmVcCiAgIHByb3ZpZGVkIHRocm91Z2g6XApcCiAgICAgIFJJRCBJbmZvcm1hdGlvbjpcClwK ICAgICAgICAgUklEIFBvbGljeSBSSUQgbWVzc2FnZSB0eXBlLCBJbmNpZGVudElELCBhbmQgZGVz dGluYXRpb24gcG9saWN5XAogICAgICAgICBpbmZvcm1hdGlvblwKXAogICAgICBUaGUgZm9sbG93 aW5nIGRhdGEgaXMgcmVjb21tZW5kZWQgaWYgYXZhaWxhYmxlIGFuZCBjYW4gYmUgcHJvdmlkZWRc CiAgICAgIHRocm91Z2g6XApcCiAgICAgIElPREVGIEluZm9ybWF0aW9uOlwKXAogICAgICAgICBU aW1lIFN0YW1wcyAoRGV0ZWN0VGltZSwgU3RhcnRUaW1lLCBFbmRUaW1lLCBSZXBvcnRUaW1lKS5c ClwKICAgICAgICAgSW5jaWRlbnQgSWRlbnRpZmllciAoSW5jaWRlbnQgY2xhc3MsIEluY2lkZW50 SUQpLiAgVHJhY2UgbnVtYmVyXAogICAgICAgICAtIHVzZWQgZm9yIG11bHRpcGxlIHRyYWNlcyBv ZiBhIHNpbmdsZSBpbmNpZGVudDsgbXVzdCBiZSBub3RlZC5cClwKICAgICAgICAgQ29uZmlkZW5j ZSByYXRpbmcgb2Ygc2VjdXJpdHkgaW5jaWRlbnQgKEltcGFjdCBhbmQgQ29uZmlkZW5jZVwKICAg ICAgICAgY2xhc3MpLlwKXAogICAgICAgICBTeXN0ZW0gY2xhc3MgaXMgdXNlZCB0byBsaXN0IGJv dGggdGhlIFNvdXJjZSBhbmQgRGVzdGluYXRpb25cCiAgICAgICAgIEluZm9ybWF0aW9uIHVzZWQg aW4gdGhlIGF0dGFjay5cClwKICAgICAgICAgRXZlbnQsIFJlY29yZCwgYW5kIFJlY29yZEl0ZW0g Y2xhc3NlcyB0byBpbmNsdWRlIGV4YW1wbGVcCiAgICAgICAgIHBhY2tldHMgYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIGluY2lkZW50XAogICAgICAgICAob3B0aW9uYWwpLlwK XAogICAgICBTdGFuZGFyZHMgZm9yIGVuY3J5cHRpb24gYW5kIGRpZ2l0YWwgc2lnbmF0dXJlcyBb UkZDMzI3NV06XApcCiAgICAgICAgIERpZ2l0YWwgc2lnbmF0dXJlIGZyb20gaW5pdGlhdGluZyBS SUQgc3lzdGVtLCBwYXNzZWQgdG8gYWxsXAogICAgICAgICBzeXN0ZW1zIHJlY2VpdmluZyB0aGUg cmVwb3J0IHVzaW5nIGFuIGVudmVsb3BlZCBYTUwgZGlnaXRhbFwKICAgICAgICAgc2lnbmF0dXJl LlwKXAogICAgICAgICBYTUwgZW5jcnlwdGlvbiBhcyByZXF1aXJlZCBieSBwb2xpY3ksIGFncmVl bWVudHMsIGFuZCBkYXRhXAogICAgICAgICBtYXJrZXJzLlwKXAogICBTZWN1cml0eSBjb25zaWRl cmF0aW9ucyB3b3VsZCBpbmNsdWRlIHRoZSBhYmlsaXR5IHRvIGVuY3J5cHRcCiAgIFtYTUxlbmNy eXB0XSB0aGUgY29udGVudHMgb2YgdGhlIFJlcG9ydCBtZXNzYWdlIHVzaW5nIHRoZSBwdWJsaWMg a2V5XAogICBvZiB0aGUgZGVzdGluYXRpb24gUklEIHN5c3RlbS4gIFNlbmRlcnMgb2YgYSBSZXBv cnQgbWVzc2FnZSBzaG91bGRcCiAgIG5vdGUgdGhhdCB0aGUgaW5mb3JtYXRpb24gbWF5IGJlIHVz ZWQgdG8gY29ycmVsYXRlIHNlY3VyaXR5IGluY2lkZW50XApcClwKXApNb3JpYXJ0eSAgICAgICAg ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyOV1c ClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgaW5mb3JtYXRpb24gZm9yIHRoZSBwdXJw b3NlIG9mIHRyZW5kaW5nLCBwYXR0ZXJuIGRldGVjdGlvbiwgZXRjLiwgYW5kXAogICBtYXkgYmUg c2hhcmVkIHdpdGggb3RoZXIgcGFydGllcyB1bmxlc3Mgb3RoZXJ3aXNlIGFncmVlZCB1cG9uIHdp dGhcCiAgIHRoZSByZWNlaXZpbmcgUklEIHN5c3RlbS4gIFRoZXJlZm9yZSwgc2VuZGluZyBwYXJ0 aWVzIG9mIGEgUmVwb3J0XAogICBtZXNzYWdlIG1heSBvYmZ1c2NhdGUgb3IgcmVtb3ZlIGRlc3Rp bmF0aW9uIGFkZHJlc3NlcyBvciBvdGhlclwKICAgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGJlZm9y ZSBzZW5kaW5nIGEgUmVwb3J0IG1lc3NhZ2UuICBBIFJlcG9ydFwKICAgbWVzc2FnZSBtYXkgYmUg c2VudCBlaXRoZXIgdG8gZmlsZSBhbiBpbmNpZGVudCByZXBvcnQgb3IgaW4gcmVzcG9uc2VcCiAg IHRvIGFuIEluY2lkZW50UXVlcnksIGFuZCBkYXRhIHNlbnNpdGl2aXR5IG11c3QgYmUgY29uc2lk ZXJlZCBpbiBib3RoXAogICBjYXNlcy4gIFRoZSBTUCBwYXRoIGluZm9ybWF0aW9uIGlzIG5vdCBu ZWNlc3NhcnkgZm9yIHRoaXMgbWVzc2FnZSwgYXNcCiAgIGl0IHdpbGwgYmUgY29tbXVuaWNhdGVk IGRpcmVjdGx5IGJldHdlZW4gdHdvIHRydXN0ZWQgUklEIHN5c3RlbXMuXApcCjQuNi4gIEluY2lk ZW50UXVlcnlcClwKICAgRGVzY3JpcHRpb246IFRoZSBJbmNpZGVudFF1ZXJ5IG1lc3NhZ2UgaXMg dXNlZCB0byByZXF1ZXN0IGluY2lkZW50XAogICBpbmZvcm1hdGlvbiBmcm9tIGEgdHJ1c3RlZCBS SUQgc3lzdGVtLiAgVGhlIHJlcXVlc3QgY2FuIGluY2x1ZGUgdGhlXAogICBpbmNpZGVudCBudW1i ZXIsIGlmIGtub3duLCBvciBkZXRhaWxlZCBpbmZvcm1hdGlvbiBhYm91dCB0aGVcCiAgIGluY2lk ZW50LiAgSWYgdGhlIGluY2lkZW50IG51bWJlciBpcyBrbm93biwgdGhlIFJlcG9ydCBtZXNzYWdl XAogICBjb250YWluaW5nIHRoZSBpbmNpZGVudCBpbmZvcm1hdGlvbiBjYW4gZWFzaWx5IGJlIHJl dHVybmVkIHRvIHRoZVwKICAgdHJ1c3RlZCByZXF1ZXN0b3IgdXNpbmcgYXV0b21hdGVkIG1ldGhv ZHMuICBJZiBhbiBleGFtcGxlIHBhY2tldCBvclwKICAgb3RoZXIgdW5pcXVlIGluZm9ybWF0aW9u IGlzIGluY2x1ZGVkIGluIHRoZSBJbmNpZGVudFF1ZXJ5LCB0aGUgcmV0dXJuXAogICByZXBvcnQg bWF5IGJlIGF1dG9tYXRlZDsgb3RoZXJ3aXNlLCBhbmFseXN0IGludGVydmVudGlvbiBtYXkgYmVc CiAgIHJlcXVpcmVkLlwKXAogICBUaGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIG11c3QgYmUgdXNl ZCBmb3IgYW4gSW5jaWRlbnRRdWVyeSBtZXNzYWdlXAogICBhbmQgaXMgcHJvdmlkZWQgdGhyb3Vn aDpcClwKICAgICAgUklEIEluZm9ybWF0aW9uOlwKXAogICAgICAgICBSSUQgUG9saWN5XApcCiAg ICAgICAgICAgIFJJRCBtZXNzYWdlIHR5cGUsIEluY2lkZW50SUQsIGFuZCBkZXN0aW5hdGlvbiBw b2xpY3lcCiAgICAgICAgICAgIGluZm9ybWF0aW9uXApcCiAgICAgIElPREVGIEluZm9ybWF0aW9u IChvcHRpb25hbCk6XApcCiAgICAgICAgIFRpbWUgU3RhbXBzIChEZXRlY3RUaW1lLCBTdGFydFRp bWUsIEVuZFRpbWUsIFJlcG9ydFRpbWUpLlwKXAogICAgICAgICBJbmNpZGVudCBJZGVudGlmaWVy IChJbmNpZGVudCBjbGFzcywgSW5jaWRlbnRJRCkuXApcCiAgICAgICAgICAgIFRyYWNlIG51bWJl ciAtIHVzZWQgZm9yIG11bHRpcGxlIHRyYWNlcyBvZiBhIHNpbmdsZVwKICAgICAgICAgICAgaW5j aWRlbnQ7IG11c3QgYmUgbm90ZWQuXApcCiAgICAgICAgIENvbmZpZGVuY2UgcmF0aW5nIG9mIHNl Y3VyaXR5IGluY2lkZW50IChJbXBhY3QgYW5kIENvbmZpZGVuY2VcCiAgICAgICAgIGNsYXNzKS5c ClwKICAgICAgICAgU3lzdGVtIGNsYXNzIGlzIHVzZWQgdG8gbGlzdCBib3RoIHRoZSBTb3VyY2Ug YW5kIERlc3RpbmF0aW9uXAogICAgICAgICBJbmZvcm1hdGlvbiB1c2VkIGluIHRoZSBhdHRhY2su XApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwg MjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzBdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApc CiAgICAgICAgIEV2ZW50LCBSZWNvcmQsIGFuZCBSZWNvcmRJdGVtIGNsYXNzZXMgdG8gaW5jbHVk ZSBleGFtcGxlXAogICAgICAgICBwYWNrZXRzIGFuZCBvdGhlciBpbmZvcm1hdGlvbiByZWxhdGVk IHRvIHRoZSBpbmNpZGVudFwKICAgICAgICAgKG9wdGlvbmFsKS5cClwKICAgICAgU3RhbmRhcmRz IGZvciBlbmNyeXB0aW9uIGFuZCBkaWdpdGFsIHNpZ25hdHVyZXMgW1JGQzMyNzVdOlwKXAogICAg ICAgICBEaWdpdGFsIHNpZ25hdHVyZSBmcm9tIHRoZSBDU0lSVCBvciBTUCBpbml0aWF0aW5nIHRo ZSBSSURcCiAgICAgICAgIG1lc3NhZ2UsIHBhc3NlZCB0byBhbGwgc3lzdGVtcyByZWNlaXZpbmcg dGhlIEluY2lkZW50UXVlcnlcCiAgICAgICAgIHVzaW5nIGFuIGVudmVsb3BlZCBYTUwgZGlnaXRh bCBzaWduYXR1cmUuXApcCiAgICAgICAgIFhNTCBlbmNyeXB0aW9uIGFzIHJlcXVpcmVkIGJ5IHBv bGljeSwgYWdyZWVtZW50cywgYW5kIGRhdGFcCiAgICAgICAgIG1hcmtlcnMuXApcCiAgIFRoZSBw cm9wZXIgcmVzcG9uc2UgdG8gdGhlIEluY2lkZW50UXVlcnkgbWVzc2FnZSBpcyBhIFJlcG9ydCBt ZXNzYWdlLlwKICAgTXVsdGlwbGUgaW5jaWRlbnRzIG1heSBiZSByZXR1cm5lZCBmb3IgYSBzaW5n bGUgcXVlcnkgaWYgYW4gaW5jaWRlbnRcCiAgIHR5cGUgaXMgcmVxdWVzdGVkLiAgSW4gdGhpcyBj YXNlLCB0aGUgcmVjZWl2aW5nIHN5c3RlbSB3b3VsZCBzZW5kIGFuXAogICBJT0RFRiBkb2N1bWVu dCBjb250YWluaW5nIG11bHRpcGxlIGluY2lkZW50cyBvciBhbGwgaW5zdGFuY2VzIG9mIGFuXAog ICBpbmNpZGVudC4gIFRoZSBzeXN0ZW0gc2VuZGluZyB0aGUgcmVwbHkgbWF5IHByZS1zZXQgYSBs aW1pdCB0byB0aGVcCiAgIG51bWJlciBvZiBkb2N1bWVudHMgcmV0dXJuZWQgaW4gb25lIHJlcG9y dC4gIFRoZSByZWNvbW1lbmRlZCBsaW1pdCBpc1wKICAgNSwgdG8gcHJldmVudCB0aGUgZG9jdW1l bnRzIGZyb20gYmVjb21pbmcgdG9vIGxhcmdlLiAgT3RoZXIgdHJhbnNmZXJcCiAgIG1ldGhvZHMg bWF5IGJlIHN1aXRlZCBiZXR0ZXIgdGhhbiBSSUQgZm9yIGxhcmdlIHRyYW5zZmVycyBvZiBkYXRh LlwKICAgVGhlIENvbmZpZGVuY2UgcmF0aW5nIG1heSBiZSB1c2VkIGluIHRoZSBJbmNpZGVudFF1 ZXJ5IG1lc3NhZ2UgdG9cCiAgIHNlbGVjdCBvbmx5IGluY2lkZW50cyB3aXRoIGFuIGVxdWFsIG9y IGhpZ2hlciBDb25maWRlbmNlIHJhdGluZyB0aGFuXAogICB3aGF0IGlzIHNwZWNpZmllZC4gIFRo aXMgbWF5IGJlIHVzZWQgZm9yIGNhc2VzIHdoZW4gaW5mb3JtYXRpb24gaXNcCiAgIGdhdGhlcmVk IG9uIGEgdHlwZSBvZiBpbmNpZGVudCBidXQgbm90IG9uIHNwZWNpZmljcyBhYm91dCBhIHNpbmds ZVwKICAgaW5jaWRlbnQuICBTb3VyY2UgYW5kIERlc3RpbmF0aW9uIEluZm9ybWF0aW9uIG1heSBu b3QgYmUgbmVlZGVkIGlmXAogICB0aGUgSW5jaWRlbnRRdWVyeSBpcyBpbnRlbmRlZCB0byBnYXRo ZXIgZGF0YSBhYm91dCBhIHNwZWNpZmljIHR5cGUgb2ZcCiAgIGluY2lkZW50IGFzIHdlbGwuXApc ClwKNS4gIFJJRCBDb21tdW5pY2F0aW9uIEV4Y2hhbmdlc1wKXAogICBUaGUgZm9sbG93aW5nIHNl Y3Rpb24gb3V0bGluZXMgdGhlIGNvbW11bmljYXRpb24gZmxvd3MgZm9yIFJJRCBhbmRcCiAgIGFs c28gcHJvdmlkZXMgZXhhbXBsZXMgb2YgbWVzc2FnZXMuXApcCiAgIE5vdGU6IEZvciBlYWNoIGV4 YW1wbGUgbGlzdGVkIGJlbG93LCBbUkZDNTczNV0gYWRkcmVzc2VzIHdlcmUgdXNlZC5cCiAgIEFz c3VtZSB0aGF0IGVhY2ggSVAgYWRkcmVzcyBsaXN0ZWQgaXMgYWN0dWFsbHkgYSBzZXBhcmF0ZSBu ZXR3b3JrXAogICByYW5nZSBoZWxkIGJ5IGRpZmZlcmVudCBTUHMuICBBZGRyZXNzZXMgd2VyZSB1 c2VkIGZyb20gLzI3IG5ldHdvcmtcCiAgIHJhbmdlcy5cClwKNS4xLiAgVXBzdHJlYW0gVHJhY2Ug Q29tbXVuaWNhdGlvbiBGbG93XApcCiAgIFRoZSBkaWFncmFtIGJlbG93IG91dGxpbmVzIHRoZSBS SUQgVHJhY2VSZXF1ZXN0IGNvbW11bmljYXRpb24gZmxvd1wKICAgYmV0d2VlbiBSSUQgc3lzdGVt cyBvbiBkaWZmZXJlbnQgbmV0d29ya3MgdHJhY2luZyBhbiBhdHRhY2suICBTUC0xLFwKICAgU1At MiwgU1AtMyByZXByZXNlbnQgc2VydmljZSBvciBuZXR3b3JrIHByb3ZpZGVycyB0aGF0IGFyZSBp bnZvbHZlZFwKICAgaW4gdGhlIGV4YW1wbGUgdHJhY2UgY29tbXVuaWNhdGlvbiBmbG93LlwKXApc ClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIg ICAgICAgICAgICAgIFtQYWdlIDMxXVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAg QXR0YWNrIERlc3QgICAgICBTUC0xICAgICAgICAgICAgU1AtMiAgICAgICAgU1AtMyAgICAgICAg QXR0YWNrIFNyY1wKXAogICAgMS4gQXR0YWNrICAgIHwgIEF0dGFja1wKICAgICAgIHJlcG9ydGVk ICB8ICBkZXRlY3RlZFwKXAogICAgMi4gICAgICAgICAgICAgIEluaXRpYXRlIHRyYWNlXApcCiAg ICAzLiAgICAgICAgICAgICAgTG9jYXRlIG9yaWdpblwKICAgICAgICAgICAgICAgICAgICB0aHJv dWdoXAogICAgICAgICAgICAgICAgICAgIHVwc3RyZWFtIFNQXApcCiAgICA0LiAgICAgICAgICAg ICAgby0tLVRyYWNlUmVxdWVzdC0tLS0tPlwKXAogICAgNS4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBUcmFjZVwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5pdGlh dGVkXApcCiAgICA2LiAgICAgICAgICAgICAgPC1SZXF1ZXN0QXV0aG9yaXphdGlvbi1vXApcCiAg ICA3LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExvY2F0ZSBvcmlnaW5cCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRocm91Z2hcCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHVwc3RyZWFtIFNQXApcCiAgICA4LiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG8tLS1UcmFjZVJlcXVlc3QtLS0+XApcCiAgICA5LiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRyYWNlIEluaXRpYXRlZFwKXAogICAgMTAuICAg ICAgICAgICAgIDwtLS0tLS0tLS0tUmVxdWVzdEF1dGhvcml6YXRpb24tLS0tb1wKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS1SZXF1ZXN0QXV0aC0tLW9cClwKICAgIDEx LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTG9jYXRlIGF0dGFj a1wKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc291 cmNlIG9uIG5ldHdvcmsgICBYXApcCiAgICAxMi4gICAgICAgICAgICAgPC0tLS0tLS0tLS0tLVJl c3VsdC0tLS0tLS0tLS0tLS0tLS1vXApcCiAgICAgICAgICAgICAgICAgRmlndXJlIDc6IFRyYWNl UmVxdWVzdCBDb21tdW5pY2F0aW9uIEZsb3dcClwKICAgQmVmb3JlIGEgdHJhY2UgaXMgaW5pdGlh dGVkLCB0aGUgUklEIHN5c3RlbSBzaG91bGQgdmVyaWZ5IGlmIGFuXAogICBpbnN0YW5jZSBvZiB0 aGUgdHJhY2Ugb3IgYSBzaW1pbGFyIHJlcXVlc3QgaXMgbm90IGFjdGl2ZS4gIFRoZSB0cmFjZXNc CiAgIG1heSBiZSByZXNvdXJjZSBpbnRlbnNpdmU7IHRoZXJlZm9yZSwgcHJvdmlkZXJzIG5lZWQg dG8gYmUgYWJsZSB0b1wKICAgZGV0ZWN0IHBvdGVudGlhbCBhYnVzZSBvZiB0aGUgc3lzdGVtIG9y IHVuaW50ZW50aW9uYWwgcmVzb3VyY2VcCiAgIGRyYWlucy4gIEluZm9ybWF0aW9uIHN1Y2ggYXMg dGhlIFNvdXJjZSBhbmQgRGVzdGluYXRpb24gSW5mb3JtYXRpb24sXAogICBhc3NvY2lhdGVkIHBh Y2tldHMsIGFuZCB0aGUgaW5jaWRlbnQgbWF5IGJlIGRlc2lyYWJsZSB0byBtYWludGFpbiBmb3Jc CiAgIGEgcGVyaW9kIG9mIHRpbWUgZGV0ZXJtaW5lZCBieSBhZG1pbmlzdHJhdG9ycy5cClwKICAg VGhlIGNvbW11bmljYXRpb24gZmxvdyBkZW1vbnN0cmF0ZXMgdGhhdCBhIFJlcXVlc3RBdXRob3Jp emF0aW9uXAogICBtZXNzYWdlIGlzIHNlbnQgdG8gYm90aCB0aGUgZG93bnN0cmVhbSBwZWVyIGFu ZCB0aGUgb3JpZ2luYWxcCiAgIHJlcXVlc3Rvci4gIElmIGEgVHJhY2VSZXF1ZXN0IGlzIGRlbmll ZCwgdGhlIGRvd25zdHJlYW0gcGVlciBoYXMgdGhlXAogICBvcHRpb24gdG8gdGFrZSBhbiBhY3Rp b24gYW5kIHJlc3BvbmQgd2l0aCBhIFJlc3VsdCBtZXNzYWdlLiAgVGhlXApcClwKXApNb3JpYXJ0 eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBb UGFnZSAzMl1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUt YmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgb3JpZ2luYXRvciBvZiB0 aGUgcmVxdWVzdCBtYXkgZm9sbG93IHVwIHdpdGggdGhlIGRvd25zdHJlYW0gcGVlciBvZlwKICAg dGhlIFNQIGludm9sdmVkIHVzaW5nIGFuIEludmVzdGlnYXRpb24gcmVxdWVzdCB0byBlbnN1cmUg dGhhdCBhblwKICAgYWN0aW9uIGlzIHRha2VuIGlmIG5vIHJlc3BvbnNlIGlzIHJlY2VpdmVkLiAg Tm90aGluZyBwcmVjbHVkZXMgdGhlXAogICBvcmlnaW5hdG9yIG9mIHRoZSByZXF1ZXN0IGZyb20g aW5pdGlhdGluZyBhIG5ldyBUcmFjZVJlcXVlc3RcCiAgIGJ5cGFzc2luZyB0aGUgU1AgdGhhdCBk ZW5pZWQgdGhlIHJlcXVlc3QsIGlmIGEgdHJhY2UgaXMgbmVlZGVkIGJleW9uZFwKICAgdGhhdCBw b2ludC4gIEFub3RoZXIgb3B0aW9uIG1heSBiZSBmb3IgdGhlIGluaXRpYXRvciB0byBzZW5kIGFu XAogICBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgdG8gYW4gU1AgdXBzdHJlYW0gb2YgdGhlIFNQIHRo YXQgZGVuaWVkIHRoZVwKICAgcmVxdWVzdCBpZiBlbm91Z2ggaW5mb3JtYXRpb24gd2FzIGdhdGhl cmVkIHRvIGRpc2Nlcm4gdGhlIHRydWUgc291cmNlXAogICBvZiB0aGUgYXR0YWNrIHRyYWZmaWMg ZnJvbSB0aGUgaW5jaWRlbnQgaGFuZGxpbmcgaW5mb3JtYXRpb24uXApcCjUuMS4xLiAgUklEIFRy YWNlUmVxdWVzdCBFeGFtcGxlXApcCiAgIFRoZSBleGFtcGxlIGxpc3RlZCBpcyBvZiBhIFRyYWNl UmVxdWVzdCBiYXNlZCBvbiB0aGUgaW5jaWRlbnQgcmVwb3J0XAogICBleGFtcGxlIGZyb20gdGhl IElPREVGIGRvY3VtZW50LiAgVGhlIFJJRCBleHRlbnNpb24gY2xhc3NlcyB3ZXJlXAogICBpbmNs dWRlZCBhcyBhcHByb3ByaWF0ZSBmb3IgYSBUcmFjZVJlcXVlc3QgbWVzc2FnZSB1c2luZyB0aGVc CiAgIFJJRFBvbGljeSBjbGFzcy4gIFRoZSBleGFtcGxlIGdpdmVuIGlzIHRoYXQgb2YgYSBDU0lS VCByZXBvcnRpbmcgYVwKICAgRG9TIGF0dGFjayBpbiBwcm9ncmVzcyB0byB0aGUgdXBzdHJlYW0g U1AuICBUaGUgcmVxdWVzdCBhc2tzIHRoZSBuZXh0XAogICBTUCB0byBjb250aW51ZSB0aGUgdHJh Y2UgYW5kIGhhdmUgdGhlIHRyYWZmaWMgbWl0aWdhdGVkIGNsb3NlciB0byB0aGVcCiAgIHNvdXJj ZSBvZiB0aGUgdHJhZmZpYy5cClwKICAgSW4gdGhlIGZvbGxvd2luZyBleGFtcGxlLCB1c2Ugb2Yg W1hNTHNpZ10gdG8gZ2VuZXJhdGUgZGlnaXRhbFwKICAgc2lnbmF0dXJlcyBkb2VzIG5vdCBjdXJy ZW50bHkgcHJvdmlkZSBkaWdlc3QgYWxnb3JpdGhtIGFnaWxpdHksIGFzXAogICBbWE1Mc2lnXSBv bmx5IHN1cHBvcnRzIFNIQS0xLiAgQSBmdXR1cmUgdmVyc2lvbiBvZiBbWE1Mc2lnXSBtYXlcCiAg IHN1cHBvcnQgYWRkaXRpb25hbCBkaWdlc3QgYWxnb3JpdGhtcyB0byBzdXBwb3J0IGRpZ2VzdCBh bGdvcml0aG1cCiAgIGFnaWxpdHkuXApcCiAgPGlvZGVmLXJpZDpSSUQgeG1sbnM6aW9kZWYtcmlk PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0xLjAiXAogICAgICAgICAgICAgICAg IHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCI+XAogICAgPGlv ZGVmLXJpZDpSSURQb2xpY3kgTXNnVHlwZT0iVHJhY2VSZXF1ZXN0IlwKICAgICAgICAgICAgICAg ICAgICAgICAgIE1zZ0Rlc3RpbmF0aW9uPSJSSURTeXN0ZW0iPlwKICAgICAgPGlvZGVmLXJpZDpQ b2xpY3lSZWdpb24gcmVnaW9uPSJJbnRyYUNvbnNvcnRpdW0iLz5cCiAgICAgIDxpb2RlZjpOb2Rl PlwKICAgICAgICA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1hZGRyIj4xOTIuMC4yLjM8 L2lvZGVmOkFkZHJlc3M+XAogICAgICA8L2lvZGVmOk5vZGU+XAogICAgICA8aW9kZWYtcmlkOlRy YWZmaWNUeXBlIHR5cGU9IkF0dGFjayIvPlwKICAgICAgPGlvZGVmOkluY2lkZW50SUQgbmFtZT0i Q0VSVC1GT1ItT1VSLURPTUFJTiI+XAogICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjA3LTFc CiAgICAgIDwvaW9kZWY6SW5jaWRlbnRJRD5cCiAgICA8L2lvZGVmLXJpZDpSSURQb2xpY3k+XAog IDwvaW9kZWYtcmlkOlJJRD5cClwKXAogIDwhLS0gSU9ERUYtRG9jdW1lbnQgYWNjb21wYW5pZWQg YnkgdGhlIGFib3ZlIFJJRCAtLT5cClwKICA8aW9kZWY6SU9ERUYtRG9jdW1lbnQgdmVyc2lvbj0i MS4wMCJcCiAgICAgICAgICAgICAgICAgICAgICAgIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOmlvZGVmLTEuMCI+XAogICAgPGlvZGVmOkluY2lkZW50IHJlc3RyaWN0aW9uPSJu ZWVkLXRvLWtub3ciIHB1cnBvc2U9InRyYWNlYmFjayI+XAogICAgICA8aW9kZWY6SW5jaWRlbnRJ RCBuYW1lPSJDRVJULUZPUi1PVVItRE9NQUlOIj5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDMzXVwKXHBh Z2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAg ICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjA3 LTFcCiAgICAgIDwvaW9kZWY6SW5jaWRlbnRJRD5cCiAgICAgIDxpb2RlZjpEZXRlY3RUaW1lPjIw MDQtMDItMDJUMjI6NDk6MjQrMDA6MDA8L2lvZGVmOkRldGVjdFRpbWU+XAogICAgICA8aW9kZWY6 U3RhcnRUaW1lPjIwMDQtMDItMDJUMjI6MTk6MjQrMDA6MDA8L2lvZGVmOlN0YXJ0VGltZT5cCiAg ICAgIDxpb2RlZjpSZXBvcnRUaW1lPjIwMDQtMDItMDJUMjM6MjA6MjQrMDA6MDA8L2lvZGVmOlJl cG9ydFRpbWU+XAogICAgICA8aW9kZWY6RGVzY3JpcHRpb24+SG9zdCBpbnZvbHZlZCBpbiBEb1Mg YXR0YWNrPC9pb2RlZjpEZXNjcmlwdGlvbj5cCiAgICAgIDxpb2RlZjpBc3Nlc3NtZW50PlwKICAg ICAgICA8aW9kZWY6SW1wYWN0IHNldmVyaXR5PSJsb3ciIGNvbXBsZXRpb249ImZhaWxlZCIgdHlw ZT0iZG9zIi8+XAogICAgICA8L2lvZGVmOkFzc2Vzc21lbnQ+XAogICAgICA8aW9kZWY6Q29udGFj dCByb2xlPSJjcmVhdG9yIiB0eXBlPSJvcmdhbml6YXRpb24iPlwKICAgICAgICA8aW9kZWY6Q29u dGFjdE5hbWU+Q29uc3RpdHVlbmN5LWNvbnRhY3QgZm9yIDE5Mi4wLjIuMzVcCiAgICAgICAgPC9p b2RlZjpDb250YWN0TmFtZT5cCiAgICAgICAgPGlvZGVmOkVtYWlsPkNvbnN0aXR1ZW5jeS1jb250 YWN0QDE5Mi4wLjIuMzU8L2lvZGVmOkVtYWlsPlwKICAgICAgPC9pb2RlZjpDb250YWN0PlwKICAg ICAgPGlvZGVmOkV2ZW50RGF0YT5cCiAgICAgICAgPGlvZGVmOkZsb3c+XAogICAgICAgICAgPGlv ZGVmOlN5c3RlbSBjYXRlZ29yeT0ic291cmNlIj5cCiAgICAgICAgICAgIDxpb2RlZjpOb2RlPlwK ICAgICAgICAgICAgICA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1hZGRyIj4xOTIuMC4y LjM1XAogICAgICAgICAgICAgIDwvaW9kZWY6QWRkcmVzcz5cCiAgICAgICAgICAgIDwvaW9kZWY6 Tm9kZT5cCiAgICAgICAgICAgIDxpb2RlZjpTZXJ2aWNlPlwKICAgICAgICAgICAgICA8aW9kZWY6 cG9ydD4zODc2NTwvaW9kZWY6cG9ydD5cCiAgICAgICAgICAgIDwvaW9kZWY6U2VydmljZT5cCiAg ICAgICAgICA8L2lvZGVmOlN5c3RlbT5cCiAgICAgICAgICA8aW9kZWY6U3lzdGVtIGNhdGVnb3J5 PSJ0YXJnZXQiPlwKICAgICAgICAgICAgPGlvZGVmOk5vZGU+XAogICAgICAgICAgICAgIDxpb2Rl ZjpBZGRyZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiPjE5Mi4wLjIuNjdcCiAgICAgICAgICAgICAg PC9pb2RlZjpBZGRyZXNzPlwKICAgICAgICAgICAgPC9pb2RlZjpOb2RlPlwKICAgICAgICAgICAg PGlvZGVmOlNlcnZpY2U+XAogICAgICAgICAgICAgIDxpb2RlZjpwb3J0PjgwPC9pb2RlZjpwb3J0 PlwKICAgICAgICAgICAgPC9pb2RlZjpTZXJ2aWNlPlwKICAgICAgICAgIDwvaW9kZWY6U3lzdGVt PlwKICAgICAgICA8L2lvZGVmOkZsb3c+XAogICAgICAgIDxpb2RlZjpFeHBlY3RhdGlvbiBzZXZl cml0eT0iaGlnaCIgYWN0aW9uPSJyYXRlLWxpbWl0LWhvc3QiPlwKICAgICAgICAgIDxpb2RlZjpE ZXNjcmlwdGlvbj5cCiAgICAgICAgICAgIFJhdGUtbGltaXQgdHJhZmZpYyBjbG9zZSB0byBzb3Vy Y2VcCiAgICAgICAgICA8L2lvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAgICA8L2lvZGVmOkV4cGVj dGF0aW9uPlwKICAgICAgICA8aW9kZWY6UmVjb3JkPlwKICAgICAgICAgIDxpb2RlZjpSZWNvcmRE YXRhPlwKICAgICAgICAgICAgPGlvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAgICAgICAgICBUaGUg SVB2NCBwYWNrZXQgaW5jbHVkZWQgd2FzIHVzZWQgaW4gdGhlIGRlc2NyaWJlZCBhdHRhY2tcCiAg ICAgICAgICAgIDwvaW9kZWY6RGVzY3JpcHRpb24+XAogICAgICAgICAgICA8aW9kZWY6UmVjb3Jk SXRlbSBkdHlwZT0iaXB2NC1wYWNrZXQiPjQ1MDAwMDUyMmFkOVwKICAgICAgICAgICAgICAgMDAw MGZmMDZjNDFmYzBhODAxMDIwYTAxMDEwMjk3NmQwMDUwMTAzZTAyMDgxMGQ5XAogICAgICAgICAg ICAgICA0YTEzNTAwMjEwMDBhZDY3MDAwMDU0Njg2MTZlNmIyMDc5NmY3NTIwNjY2ZjcyMjBcClwK XApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDM0XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICAg ICAgICAgICA2MzYxNzI2NTY2NzU2YzZjNzkyMDcyNjU2MTY0Njk2ZTY3MjA3NDY4Njk3MzIwNTJc CiAgICAgICAgICAgICAgIDQ2NDMyZTBhXAogICAgICAgICAgICA8L2lvZGVmOlJlY29yZEl0ZW0+ XAogICAgICAgICAgPC9pb2RlZjpSZWNvcmREYXRhPlwKICAgICAgICA8L2lvZGVmOlJlY29yZD5c CiAgICAgIDwvaW9kZWY6RXZlbnREYXRhPlwKICAgICAgPGlvZGVmOkhpc3Rvcnk+XAogICAgICAg IDxpb2RlZjpIaXN0b3J5SXRlbT5cCiAgICAgICAgICA8aW9kZWY6RGF0ZVRpbWU+MjAwMS0wOS0x NFQwODoxOTowMSswMDowMDwvaW9kZWY6RGF0ZVRpbWU+XAogICAgICAgICAgPGlvZGVmOkluY2lk ZW50SUQgbmFtZT0iQ1NJUlQtRk9SLU9VUi1ET01BSU4iPlwKICAgICAgICAgICAgQ1NJUlQtRk9S LU9VUi1ET01BSU4jMjA3LTFcCiAgICAgICAgICA8L2lvZGVmOkluY2lkZW50SUQ+XAogICAgICAg ICAgPGlvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAgICAgICAgTm90aWZpY2F0aW9uIHNlbnQgdG8g bmV4dCB1cHN0cmVhbSBTUCBjbG9zZXIgdG8gMTkyLjAuMi4zNVwKICAgICAgICAgIDwvaW9kZWY6 RGVzY3JpcHRpb24+XAogICAgICAgIDwvaW9kZWY6SGlzdG9yeUl0ZW0+XAogICAgICA8L2lvZGVm Okhpc3Rvcnk+XAogICAgPC9pb2RlZjpJbmNpZGVudD5cCiAgPC9pb2RlZjpJT0RFRi1Eb2N1bWVu dD5cClwKICA8IS0tIERpZ2l0YWwgc2lnbmF0dXJlIGFjY29tcGFuaWVkIGJ5IGFib3ZlIFJJRCBh bmQgSU9ERUYgLS0+XApcCiAgPEVudmVsb3BlIHhtbG5zPSJ1cm46ZW52ZWxvcGUiXAogICAgICAg ICAgICB4bWxuczppb2RlZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiXAogICAg ICAgICAgICB4bWxuczppb2RlZi1yaWQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtcmlk LTEuMCI+XAogICAgPGlvZGVmOklPREVGLURvY3VtZW50PlwKICAgICAgPGlvZGVmOkluY2lkZW50 PlwKICAgICAgICA8aW9kZWY6RXZlbnREYXRhPlwKICAgICAgICAgIDxpb2RlZjpSZWNvcmQ+XAog ICAgICAgICAgICA8aW9kZWY6UmVjb3JkRGF0YT5cCiAgICAgICAgICAgICAgPGlvZGVmOlJlY29y ZEl0ZW0gdHlwZT0iaXB2NC1wYWNrZXQiPjQ1MDAwMDUyMmFkOVwKICAgICAgICAgICAgICAgMDAw MGZmMDZjNDFmYzBhODAxMDIwYTAxMDEwMjk3NmQwMDUwMTAzZTAyMDgxMGQ5XAogICAgICAgICAg ICAgICA0YTEzNTAwMjEwMDBhZDY3MDAwMDU0Njg2MTZlNmIyMDc5NmY3NTIwNjY2ZjcyMjBcCiAg ICAgICAgICAgICAgIDYzNjE3MjY1NjY3NTZjNmM3OTIwNzI2NTYxNjQ2OTZlNjcyMDc0Njg2OTcz MjA1MlwKICAgICAgICAgICAgICAgNDY0MzJlMGFcCiAgICAgICAgICAgICAgPC9pb2RlZjpSZWNv cmRJdGVtPlwKICAgICAgICAgICAgPC9pb2RlZjpSZWNvcmREYXRhPlwKICAgICAgICAgIDwvaW9k ZWY6UmVjb3JkPlwKICAgICAgICA8L2lvZGVmOkV2ZW50RGF0YT5cCiAgICAgIDwvaW9kZWY6SW5j aWRlbnQ+XAogICAgPC9pb2RlZjpJT0RFRi1Eb2N1bWVudD5cCiAgICA8U2lnbmF0dXJlIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj5cCiAgICAgIDxTaWduZWRJbmZv PlwKICAgICAgICA8Q2Fub25pY2FsaXphdGlvbk1ldGhvZFwKICAgICAgICAgICBBbGdvcml0aG09 Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvXAogICAgICAgICAgICBSRUMteG1sLWMxNG4tMjAw MTAzMTUjV2l0aENvbW1lbnRzIi8+XAogICAgICAgIDxTaWduYXR1cmVNZXRob2RcCiAgICAgICAg ICAgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZHNhLXNoYTEi Lz5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIw MTIgICAgICAgICAgICAgIFtQYWdlIDM1XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAog ICAgICAgIDxSZWZlcmVuY2UgVVJJPSIiPlwKICAgICAgICAgIDxUcmFuc2Zvcm1zPlwKICAgICAg ICAgICAgPFRyYW5zZm9ybSBBbGdvcml0aG09XAogICAgICAgICAgICAgImh0dHA6Ly93d3cudzMu b3JnLzIwMDAvMDkveG1sZHNpZyNlbnZlbG9wZWQtc2lnbmF0dXJlIi8+XAogICAgICAgICAgPC9U cmFuc2Zvcm1zPlwKICAgICAgICAgIDxEaWdlc3RNZXRob2RcCiAgICAgICAgICAgICBBbGdvcml0 aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIi8+XAogICAgICAgICAg PERpZ2VzdFZhbHVlPktpSTUrNlNuRkFzNDI5Vk53c29KakhQcGxtbz08L0RpZ2VzdFZhbHVlPlwK ICAgICAgICA8L1JlZmVyZW5jZT5cCiAgICAgIDwvU2lnbmVkSW5mbz5cCiAgICAgIDxTaWduYXR1 cmVWYWx1ZT5cCiAgICAgICAgVnZ5WHFDempvVzBtMk5keE5lVG9YUWNxY1NNODBXK0pNVytLbjAx Y1MzejNLUXdDUGVzd3pnPT1cCiAgICAgIDwvU2lnbmF0dXJlVmFsdWU+XAogICAgICA8S2V5SW5m bz5cCiAgICAgICAgPEtleVZhbHVlPlwKICAgICAgICAgIDxEU0FLZXlWYWx1ZT5cCiAgICAgICAg ICAgIDxQPi9LYUN6bzRTeXJvbTc4ejNFUTVTYmJCNHNGN2V5ODBldEtJSTg2NFdGNjRCODF1UnBI NXQ5alwKICAgICAgICAgICAgICAgUVR4ZUV1MEltYnpSTXF6VkRaa1ZHOXhEN25OMWt1Rnc9PTwv UD5cCiAgICAgICAgICAgIDxRPmxpN2R6RGFjdW82N0pnN210cUVtMlRSdU9NVT08L1E+XAogICAg ICAgICAgICA8Rz5aNFJ4c25xYzlFN3BHa25GRkgyeHFhcnlSUEJhUTAxa2hwTWRMUlFuRzU0MUF3 dHgvWFBhRjVcCiAgICAgICAgICAgICAgIEJwc3k0cE5XTU9IQ0JpTlUwTm9ncHNRVzVRdm5sTXBB PT08L0c+XAogICAgICAgICAgICA8WT5WRldURDRJL2FLbmk0WWhEeVl4QUpvem1qMWlBelBMdzlX d2Q1QitaOUo1RTdsSGpjQUorYnNcCiAgICAgICAgICAgICAgIEhpZlR5WWRuaityb0d6eTRvMDlZ bnRZRDh6bmVRN2x3PT08L1k+XAogICAgICAgICAgPC9EU0FLZXlWYWx1ZT5cCiAgICAgICAgPC9L ZXlWYWx1ZT5cCiAgICAgIDwvS2V5SW5mbz5cCiAgICA8L1NpZ25hdHVyZT5cCiAgPC9FbnZlbG9w ZT5cClwKXAo1LjEuMi4gIFJlcXVlc3RBdXRob3JpemF0aW9uIE1lc3NhZ2UgRXhhbXBsZVwKXAog ICBUaGUgZXhhbXBsZSBSZXF1ZXN0QXV0aG9yaXphdGlvbiBtZXNzYWdlIGlzIGluIHJlc3BvbnNl IHRvIHRoZVwKICAgVHJhY2VSZXF1ZXN0IG1lc3NhZ2UgbGlzdGVkIGFib3ZlLiAgVGhlIFNQIHRo YXQgcmVjZWl2ZWQgdGhlIHJlcXVlc3RcCiAgIGlzIHJlc3BvbmRpbmcgdG8gYXBwcm92ZSB0aGUg dHJhY2UgY29udGludWFuY2UgaW4gdGhlaXIgbmV0d29yay5cClwKXApcClwKXApcClwKXApcClwK XApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwg MjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzZdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApc CiAgIDxpb2RlZi1yaWQ6UklEIHhtbG5zOmlvZGVmLXJpZD0idXJuOmlldGY6cGFyYW1zOnhtbDpu czppb2RlZi1yaWQtMS4wIlwKICAgICAgICAgICAgICAgICAgeG1sbnM6aW9kZWY9InVybjppZXRm OnBhcmFtczp4bWw6bnM6aW9kZWYtMS4wIj5cCiAgICAgPGlvZGVmLXJpZDpSSURQb2xpY3kgTXNn VHlwZT0iUmVxdWVzdEF1dGhvcml6YXRpb24iXAogICAgICAgICAgICAgICAgICAgICAgICAgIE1z Z0Rlc3RpbmF0aW9uPSJSSURTeXN0ZW0iPlwKICAgICAgIDxpb2RlZi1yaWQ6UG9saWN5UmVnaW9u IHJlZ2lvbj0iSW50cmFDb25zb3J0aXVtIi8+XAogICAgICAgPGlvZGVmOk5vZGU+XAogICAgICAg ICA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1hZGRyIj4xOTIuMC4yLjY3PC9pb2RlZjpB ZGRyZXNzPlwKICAgICAgIDwvaW9kZWY6Tm9kZT5cCiAgICAgICA8aW9kZWYtcmlkOlRyYWZmaWNU eXBlIHR5cGU9IkF0dGFjayIvPlwKICAgICAgIDxpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNFUlQt Rk9SLU9VUi1ET01BSU4iPlwKICAgICAgICAgQ0VSVC1GT1ItT1VSLURPTUFJTiMyMDctMVwKICAg ICAgIDwvaW9kZWY6SW5jaWRlbnRJRD5cCiAgICAgPC9pb2RlZi1yaWQ6UklEUG9saWN5PlwKICAg ICA8aW9kZWYtcmlkOlJlcXVlc3RTdGF0dXMgQXV0aG9yaXphdGlvblN0YXR1cz0iQXBwcm92ZWQi Lz5cCiAgIDwvaW9kZWYtcmlkOlJJRD48L3NlY3Rpb24+XApcCjUuMS4zLiAgUmVzdWx0IE1lc3Nh Z2UgRXhhbXBsZVwKXAogICBUaGUgZXhhbXBsZSBSZXN1bHQgbWVzc2FnZSBpcyBpbiByZXNwb25z ZSB0byB0aGUgVHJhY2VSZXF1ZXN0IGxpc3RlZFwKICAgYWJvdmUuICBUaGlzIG1lc3NhZ2UgdHlw ZSBvbmx5IGNvbWVzIGFmdGVyIGEgUmVxdWVzdEF1dGhvcml6YXRpb25cCiAgIHdpdGhpbiB0aGUg VHJhY2VSZXF1ZXN0IGZsb3cgb2YgbWVzc2FnZXMuICBJdCBtYXkgYmUgYSBkaXJlY3RcCiAgIHJl c3BvbnNlIHRvIGFuIEludmVzdGlnYXRpb24gcmVxdWVzdC4gIFRoaXMgbWVzc2FnZSBwcm92aWRl c1wKICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNvdXJjZSBvZiB0aGUgYXR0YWNrIGFuZCB0aGUg YWN0aW9ucyB0YWtlbiB0b1wKICAgbWl0aWdhdGUgdGhlIHRyYWZmaWMuXApcCiAgPGlvZGVmLXJp ZDpSSUQgeG1sbnM6aW9kZWYtcmlkPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0x LjAiXAogICAgICAgICAgICAgICAgIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z OmlvZGVmLTEuMCI+XAogICAgPGlvZGVmLXJpZDpSSURQb2xpY3kgTXNnVHlwZT0iUmVzdWx0IlwK ICAgICAgICAgICAgICAgICAgICAgICAgIE1zZ0Rlc3RpbmF0aW9uPSJSSURTeXN0ZW0iPlwKICAg ICAgPGlvZGVmLXJpZDpQb2xpY3lSZWdpb24gcmVnaW9uPSJJbnRyYUNvbnNvcnRpdW0iLz5cCiAg ICAgIDxpb2RlZjpOb2RlPlwKICAgICAgICA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1h ZGRyIj4xOTIuMC4yLjY3PC9pb2RlZjpBZGRyZXNzPlwKICAgICAgPC9pb2RlZjpOb2RlPlwKICAg ICAgPGlvZGVmLXJpZDpUcmFmZmljVHlwZSB0eXBlPSJBdHRhY2siLz5cCiAgICAgIDxpb2RlZjpJ bmNpZGVudElEIG5hbWU9IkNFUlQtRk9SLU9VUi1ET01BSU4iPlwKICAgICAgICBDRVJULUZPUi1P VVItRE9NQUlOIzIwNy0xXAogICAgICA8L2lvZGVmOkluY2lkZW50SUQ+XAogICAgPC9pb2RlZi1y aWQ6UklEUG9saWN5PlwKICAgIDxpb2RlZi1yaWQ6SW5jaWRlbnRTb3VyY2U+XAogICAgICA8aW9k ZWYtcmlkOlNvdXJjZUZvdW5kPnRydWU8L2lvZGVmLXJpZDpTb3VyY2VGb3VuZD5cCiAgICAgIDxp b2RlZjpOb2RlPlwKICAgICAgICA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1hZGRyIj4x OTIuMC4yLjM3PC9pb2RlZjpBZGRyZXNzPlwKICAgICAgPC9pb2RlZjpOb2RlPlwKICAgIDwvaW9k ZWYtcmlkOkluY2lkZW50U291cmNlPlwKICA8L2lvZGVmLXJpZDpSSUQ+XApcCiAgPCEtLSBJT0RF Ri1Eb2N1bWVudCBhY2NvbXBhbmllZCBieSB0aGUgYWJvdmUgUklEIC0tPlwKXApcClwKXApNb3Jp YXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAg ICBbUGFnZSAzN11cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYw NDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICA8aW9kZWY6SU9ERUYt RG9jdW1lbnQgdmVyc2lvbj0iMS4wMCJcCiAgICAgICAgICAgICAgICAgICAgICAgIHhtbG5zOmlv ZGVmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCI+XAogICAgPGlvZGVmOkluY2lk ZW50IHJlc3RyaWN0aW9uPSJuZWVkLXRvLWtub3ciIHB1cnBvc2U9InRyYWNlYmFjayI+XAogICAg ICA8aW9kZWY6SW5jaWRlbnRJRCBuYW1lPSJDRVJULUZPUi1PVVItRE9NQUlOIj5cCiAgICAgICAg Q0VSVC1GT1ItT1VSLURPTUFJTiMyMDctMVwKICAgICAgPC9pb2RlZjpJbmNpZGVudElEPlwKICAg ICAgPGlvZGVmOkRldGVjdFRpbWU+MjAwNC0wMi0wMlQyMjo0OToyNCswMDowMDwvaW9kZWY6RGV0 ZWN0VGltZT5cCiAgICAgIDxpb2RlZjpTdGFydFRpbWU+MjAwNC0wMi0wMlQyMjoxOToyNCswMDow MDwvaW9kZWY6U3RhcnRUaW1lPlwKICAgICAgPGlvZGVmOlJlcG9ydFRpbWU+MjAwNC0wMi0wMlQy MzoyMDoyNCswMDowMDwvaW9kZWY6UmVwb3J0VGltZT5cCiAgICAgIDxpb2RlZjpEZXNjcmlwdGlv bj5Ib3N0IGludm9sdmVkIGluIERvUyBhdHRhY2s8L2lvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAg PGlvZGVmOkFzc2Vzc21lbnQ+XAogICAgICAgIDxpb2RlZjpJbXBhY3Qgc2V2ZXJpdHk9ImxvdyIg Y29tcGxldGlvbj0iZmFpbGVkIiB0eXBlPSJkb3MiLz5cCiAgICAgIDwvaW9kZWY6QXNzZXNzbWVu dD5cCiAgICAgIDxpb2RlZjpDb250YWN0IHJvbGU9ImNyZWF0b3IiIHR5cGU9Im9yZ2FuaXphdGlv biI+XAogICAgICAgIDxpb2RlZjpDb250YWN0TmFtZT5Db25zdGl0dWVuY3ktY29udGFjdCBmb3Ig MTkyLjAuMi4zNVwKICAgICAgICA8L2lvZGVmOkNvbnRhY3ROYW1lPlwKICAgICAgICA8aW9kZWY6 RW1haWw+Q29uc3RpdHVlbmN5LWNvbnRhY3RAMTkyLjAuMi4zNTwvaW9kZWY6RW1haWw+XAogICAg ICA8L2lvZGVmOkNvbnRhY3Q+XAogICAgICA8aW9kZWY6RXZlbnREYXRhPlwKICAgICAgICA8aW9k ZWY6Q29udGFjdCByb2xlPSJhZG1pbiIgdHlwZT0ib3JnYW5pemF0aW9uIj5cCiAgICAgICAgICA8 aW9kZWY6Q29udGFjdE5hbWU+QWRtaW4tY29udGFjdCBmb3IgMTkyLjAuMi4zNVwKICAgICAgICAg IDwvaW9kZWY6Q29udGFjdE5hbWU+XAogICAgICAgICAgPGlvZGVmOkVtYWlsPkFkbWluLWNvbnRh Y3RAMTAuMS4xLjI8L2lvZGVmOkVtYWlsPlwKICAgICAgICA8L2lvZGVmOkNvbnRhY3Q+XAogICAg ICAgIDxpb2RlZjpGbG93PlwKICAgICAgICAgIDxpb2RlZjpTeXN0ZW0gY2F0ZWdvcnk9ImludGVy bWVkaWF0ZSI+XAogICAgICAgICAgICA8aW9kZWY6Tm9kZT5cCiAgICAgICAgICAgICAgPGlvZGVm OkFkZHJlc3MgY2F0ZWdvcnk9ImlwdjQtYWRkciI+MTkyLjAuMi4zNVwKICAgICAgICAgICAgICA8 L2lvZGVmOkFkZHJlc3M+XAogICAgICAgICAgICA8L2lvZGVmOk5vZGU+XAogICAgICAgICAgPC9p b2RlZjpTeXN0ZW0+XAogICAgICAgIDwvaW9kZWY6Rmxvdz5cCiAgICAgICAgPGlvZGVmOkV2ZW50 RGF0YT5cCiAgICAgICAgICA8aW9kZWY6Q29udGFjdCByb2xlPSJhZG1pbiIgdHlwZT0ib3JnYW5p emF0aW9uIj5cCiAgICAgICAgICAgIDxpb2RlZjpDb250YWN0TmFtZT5BZG1pbi1jb250YWN0IGZv ciAxOTIuMC4yLjNcCiAgICAgICAgICAgIDwvaW9kZWY6Q29udGFjdE5hbWU+XAogICAgICAgICAg ICA8aW9kZWY6RW1haWw+QWRtaW4tY29udGFjdEAxOTIuMC4yLjM8L2lvZGVmOkVtYWlsPlwKICAg ICAgICAgIDwvaW9kZWY6Q29udGFjdD5cCiAgICAgICAgICA8aW9kZWY6Rmxvdz5cCiAgICAgICAg ICAgIDxpb2RlZjpTeXN0ZW0gY2F0ZWdvcnk9ImludGVybWVkaWF0ZSI+XAogICAgICAgICAgICAg IDxpb2RlZjpOb2RlPlwKICAgICAgICAgICAgICAgIDxpb2RlZjpBZGRyZXNzIGNhdGVnb3J5PSJp cHY0LWFkZHIiPjE5Mi4wLjIuM1wKICAgICAgICAgICAgICAgIDwvaW9kZWY6QWRkcmVzcz5cCiAg ICAgICAgICAgICAgPC9pb2RlZjpOb2RlPlwKICAgICAgICAgICAgPC9pb2RlZjpTeXN0ZW0+XAog ICAgICAgICAgPC9pb2RlZjpGbG93PlwKICAgICAgICA8L2lvZGVmOkV2ZW50RGF0YT5cCiAgICAg IDwvaW9kZWY6RXZlbnREYXRhPlwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzhdXApccGFnZSBcCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBB dWd1c3QgMjAxMVwKXApcCiAgICAgIDxpb2RlZjpFdmVudERhdGE+XAogICAgICAgIDxpb2RlZjpG bG93PlwKICAgICAgICAgIDxpb2RlZjpTeXN0ZW0gY2F0ZWdvcnk9InNvdXJjZSI+XAogICAgICAg ICAgICA8aW9kZWY6Tm9kZT5cCiAgICAgICAgICAgICAgPGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9 ImlwdjQtYWRkciI+MTkyLjAuMi4zNVwKICAgICAgICAgICAgICA8L2lvZGVmOkFkZHJlc3M+XAog ICAgICAgICAgICA8L2lvZGVmOk5vZGU+XAogICAgICAgICAgICA8aW9kZWY6U2VydmljZT5cCiAg ICAgICAgICAgICAgPGlvZGVmOnBvcnQ+Mzg3NjU8L2lvZGVmOnBvcnQ+XAogICAgICAgICAgICA8 L2lvZGVmOlNlcnZpY2U+XAogICAgICAgICAgPC9pb2RlZjpTeXN0ZW0+XAogICAgICAgICAgPGlv ZGVmOlN5c3RlbSBjYXRlZ29yeT0idGFyZ2V0Ij5cCiAgICAgICAgICAgIDxpb2RlZjpOb2RlPlwK ICAgICAgICAgICAgICA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1hZGRyIj4xOTIuMC4y LjY3XAogICAgICAgICAgICAgIDwvaW9kZWY6QWRkcmVzcz5cCiAgICAgICAgICAgIDwvaW9kZWY6 Tm9kZT5cCiAgICAgICAgICAgIDxpb2RlZjpTZXJ2aWNlPlwKICAgICAgICAgICAgICA8aW9kZWY6 cG9ydD44MDwvaW9kZWY6cG9ydD5cCiAgICAgICAgICAgIDwvaW9kZWY6U2VydmljZT5cCiAgICAg ICAgICA8L2lvZGVmOlN5c3RlbT5cCiAgICAgICAgPC9pb2RlZjpGbG93PlwKICAgICAgICA8aW9k ZWY6RXhwZWN0YXRpb24gc2V2ZXJpdHk9ImhpZ2giIGFjdGlvbj0icmF0ZS1saW1pdC1ob3N0Ij5c CiAgICAgICAgICA8aW9kZWY6RGVzY3JpcHRpb24+XAogICAgICAgICAgICBSYXRlLWxpbWl0IHRy YWZmaWMgY2xvc2UgdG8gc291cmNlXAogICAgICAgICAgPC9pb2RlZjpEZXNjcmlwdGlvbj5cCiAg ICAgICAgPC9pb2RlZjpFeHBlY3RhdGlvbj5cCiAgICAgICAgPGlvZGVmOlJlY29yZD5cCiAgICAg ICAgICA8aW9kZWY6UmVjb3JkRGF0YT5cCiAgICAgICAgICAgIDxpb2RlZjpEZXNjcmlwdGlvbj5c CiAgICAgICAgICAgICAgVGhlIElQdjQgcGFja2V0IGluY2x1ZGVkIHdhcyB1c2VkIGluIHRoZSBk ZXNjcmliZWQgYXR0YWNrXAogICAgICAgICAgICA8L2lvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAg ICAgICAgPGlvZGVmOlJlY29yZEl0ZW0gZHR5cGU9ImlwdjQtcGFja2V0Ij40NTAwMDA1MjJhZDlc CiAgICAgICAgICAgIDAwMDBmZjA2YzQxZmMwYTgwMTAyMGEwMTAxMDI5NzZkMDA1MDEwM2UwMjA4 MTBkOVwKICAgICAgICAgICAgNGExMzUwMDIxMDAwYWQ2NzAwMDA1NDY4NjE2ZTZiMjA3OTZmNzUy MDY2NmY3MjIwXAogICAgICAgICAgICA2MzYxNzI2NTY2NzU2YzZjNzkyMDcyNjU2MTY0Njk2ZTY3 MjA3NDY4Njk3MzIwNTJcCiAgICAgICAgICAgIDQ2NDMyZTBhXAogICAgICAgICAgICA8L2lvZGVm OlJlY29yZEl0ZW0+XAogICAgICAgICAgPC9pb2RlZjpSZWNvcmREYXRhPlwKICAgICAgICA8L2lv ZGVmOlJlY29yZD5cCiAgICAgIDwvaW9kZWY6RXZlbnREYXRhPlwKICAgICAgPGlvZGVmOkhpc3Rv cnk+XAogICAgICAgIDxpb2RlZjpIaXN0b3J5SXRlbT5cCiAgICAgICAgICA8aW9kZWY6RGF0ZVRp bWU+MjAwNC0wMi0wMlQyMjo1MzowMSswMDowMDwvaW9kZWY6RGF0ZVRpbWU+XAogICAgICAgICAg PGlvZGVmOkluY2lkZW50SUQgbmFtZT0iQ1NJUlQtRk9SLU9VUi1ET01BSU4iPlwKICAgICAgICAg ICAgQ1NJUlQtRk9SLU9VUi1ET01BSU4jMjA3LTFcCiAgICAgICAgICA8L2lvZGVmOkluY2lkZW50 SUQ+XAogICAgICAgICAgPGlvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAgICAgICAgTm90aWZpY2F0 aW9uIHNlbnQgdG8gbmV4dCB1cHN0cmVhbSBTUCBjbG9zZXIgdG8gMTkyLjAuMi4zNVwKXApcClwK TW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAg ICAgICAgW1BhZ2UgMzldXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBS RkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgICAgICA8 L2lvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAgICA8L2lvZGVmOkhpc3RvcnlJdGVtPlwKICAgICAg ICA8aW9kZWY6SGlzdG9yeUl0ZW0gYWN0aW9uPSJyYXRlLWxpbWl0LWhvc3QiPlwKICAgICAgICAg IDxpb2RlZjpEYXRlVGltZT4yMDA0LTAyLTAyVDIzOjA3OjIxKzAwOjAwPC9pb2RlZjpEYXRlVGlt ZT5cCiAgICAgICAgICA8aW9kZWY6SW5jaWRlbnRJRCBuYW1lPSJDU0lSVC1GT1ItU1AzIj5cCiAg ICAgICAgICAgIENTSVJULUZPUi1TUDMjMzI5MS0xXAogICAgICAgICAgPC9pb2RlZjpJbmNpZGVu dElEPlwKICAgICAgICAgIDxpb2RlZjpEZXNjcmlwdGlvbj5cCiAgICAgICAgICAgIEhvc3QgcmF0 ZS1saW1pdGVkIGZvciAyNCBob3Vyc1wKICAgICAgICAgIDwvaW9kZWY6RGVzY3JpcHRpb24+XAog ICAgICAgIDwvaW9kZWY6SGlzdG9yeUl0ZW0+XAogICAgICA8L2lvZGVmOkhpc3Rvcnk+XAogICAg PC9pb2RlZjpJbmNpZGVudD5cCiAgPC9pb2RlZjpJT0RFRi1Eb2N1bWVudD5cClwKNS4yLiAgSW52 ZXN0aWdhdGlvbiBSZXF1ZXN0IENvbW11bmljYXRpb24gRmxvd1wKXAogICBUaGUgZGlhZ3JhbSBi ZWxvdyBvdXRsaW5lcyB0aGUgUklEIEludmVzdGlnYXRpb24gcmVxdWVzdFwKICAgY29tbXVuaWNh dGlvbiBmbG93IGJldHdlZW4gUklEIHN5c3RlbXMgb24gZGlmZmVyZW50IG5ldHdvcmtzIGZvciBh XAogICBzZWN1cml0eSBpbmNpZGVudCB3aXRoIGEga25vd24gc291cmNlIGFkZHJlc3MuICBUaGUg cHJvcGVyIHJlc3BvbnNlXAogICB0byBhbiBJbnZlc3RpZ2F0aW9uIHJlcXVlc3QgaXMgYSBSZXN1 bHQgbWVzc2FnZS4gIElmIHRoZXJlIGlzIGFcCiAgIHByb2JsZW0gd2l0aCB0aGUgcmVxdWVzdCwg c3VjaCBhcyBhIGZhaWx1cmUgdG8gdmFsaWRhdGUgdGhlIGRpZ2l0YWxcCiAgIHNpZ25hdHVyZSBv ciBkZWNyeXB0IHRoZSByZXF1ZXN0LCBhIFJlcXVlc3RBdXRob3JpemF0aW9uIG1lc3NhZ2UgaXNc CiAgIHNlbnQgdG8gdGhlIHJlcXVlc3Rvci4gIFRoZSBSZXF1ZXN0QXV0aG9yaXphdGlvbiBtZXNz YWdlIHNob3VsZFwKICAgcHJvdmlkZSB0aGUgcmVhc29uIHdoeSB0aGUgbWVzc2FnZSBjb3VsZCBu b3QgYmUgcHJvY2Vzc2VkLlwKXAogICAgICAgIEF0dGFjayBEZXN0ICAgICAgU1AtMSAgICAgICAg ICAgICAgU1AtMiAgICAgICAgQXR0YWNrIFNyY1wKXAogICAgICAgIDEuIEF0dGFjayAgICB8ICBB dHRhY2tcCiAgICAgICAgICAgcmVwb3J0ZWQgIHwgIGRldGVjdGVkXApcCiAgICAgICAgMi4gICAg ICAgICAgICAgIERldGVybWluZSBzb3VyY2VcCiAgICAgICAgICAgICAgICAgICAgICAgIG9mIHNl Y3VyaXR5IGluY2lkZW50XApcCiAgICAgICAgMy4gICAgICAgICAgICAgIG8tLS1JbnZlc3RpZ2F0 aW9uLS0tLT5cClwKICAgICAgICA0LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlc2Vh cmNoXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5jaWRlbnQgYW5k XAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGV0ZXJtaW5lIGFwcHJv cHJpYXRlXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9ucyB0 byB0YWtlXApcCiAgICAgICAgNS4gICAgICAgICAgICAgIDwtLS0tLS0tUmVzdWx0LS0tLS0tLW9c ClwKXAogICAgICAgICAgICAgICAgRmlndXJlIDg6IEludmVzdGlnYXRpb24gQ29tbXVuaWNhdGlv biBGbG93XApcClwKXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0MF1cClxwYWdlIFwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDExXApcClwKNS4yLjEuICBJbnZlc3RpZ2F0aW9uIFJlcXVlc3QgRXhhbXBsZVwKXAogICBUaGUg Zm9sbG93aW5nIGV4YW1wbGUgb25seSBpbmNsdWRlcyB0aGUgUklELXNwZWNpZmljIGRldGFpbHMu ICBUaGVcCiAgIElPREVGIGFuZCBzZWN1cml0eSBtZWFzdXJlcyBhcmUgc2ltaWxhciB0byB0aGUg VHJhY2VSZXF1ZXN0XAogICBpbmZvcm1hdGlvbiwgd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgdGhl IHNvdXJjZSBpcyBrbm93biBhbmQgdGhlXAogICByZWNlaXZpbmcgUklEIHN5c3RlbSBpcyBrbm93 biB0byBiZSBjbG9zZSB0byB0aGUgc291cmNlLiAgVGhlIHNvdXJjZVwKICAga25vd24gaXMgaW5k aWNhdGVkIGluIHRoZSBJT0RFRiBkb2N1bWVudCwgd2hpY2ggYWxsb3dzIGZvciBpbmNpZGVudFwK ICAgc291cmNlcyB0byBiZSBsaXN0ZWQgYXMgc3Bvb2ZlZCwgaWYgYXBwcm9wcmlhdGUuXApcCiAg PGlvZGVmLXJpZDpSSUQgeG1sbnM6aW9kZWYtcmlkPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlv ZGVmLXJpZC0xLjAiXAogICAgICAgICAgICAgICAgIHhtbG5zOmlvZGVmPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOmlvZGVmLTEuMCI+XAogICAgPGlvZGVmLXJpZDpSSURQb2xpY3kgTXNnVHlwZT0i SW52ZXN0aWdhdGlvbiJcCiAgICAgICAgICAgICAgICAgICAgICAgICBNc2dEZXN0aW5hdGlvbj0i U291cmNlT2ZJbmNpZGVudCI+XAogICAgICA8aW9kZWYtcmlkOlBvbGljeVJlZ2lvbiByZWdpb249 IlBlZXJUb1BlZXIiLz5cCiAgICAgIDxpb2RlZjpOb2RlPlwKICAgICAgICA8aW9kZWY6QWRkcmVz cyBjYXRlZ29yeT0iaXB2NC1hZGRyIj4xOTIuMC4yLjk4PC9pb2RlZjpBZGRyZXNzPlwKICAgICAg PC9pb2RlZjpOb2RlPlwKICAgICAgPGlvZGVmLXJpZDpUcmFmZmljVHlwZSB0eXBlPSJBdHRhY2si Lz5cCiAgICAgIDxpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNFUlQtRk9SLU9VUi1ET01BSU4iPlwK ICAgICAgICBDRVJULUZPUi1PVVItRE9NQUlOIzIwOC0xXAogICAgICA8L2lvZGVmOkluY2lkZW50 SUQ+XAogICAgPC9pb2RlZi1yaWQ6UklEUG9saWN5PlwKICA8L2lvZGVmLXJpZDpSSUQ+XApcCiAg PCEtLSBJT0RFRi1Eb2N1bWVudCBhY2NvbXBhbmllZCBieSB0aGUgYWJvdmUgUklEIC0tPlwKXAog IDxpb2RlZjpJT0RFRi1Eb2N1bWVudCB2ZXJzaW9uPSIxLjAwIlwKICAgICAgICAgICAgICAgICAg ICAgICAgeG1sbnM6aW9kZWY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtMS4wIj5cCiAg ICA8aW9kZWY6SW5jaWRlbnQgcmVzdHJpY3Rpb249Im5lZWQtdG8ta25vdyIgcHVycG9zZT0ib3Ro ZXIiPlwKICAgICAgPGlvZGVmOkluY2lkZW50SUQgbmFtZT0iQ0VSVC1GT1ItT1VSLURPTUFJTiI+ XAogICAgICAgIENFUlQtRk9SLU9VUi1ET01BSU4jMjA4LTFcCiAgICAgIDwvaW9kZWY6SW5jaWRl bnRJRD5cCiAgICAgIDxpb2RlZjpEZXRlY3RUaW1lPjIwMDQtMDItMDVUMDg6MTM6MzMrMDA6MDA8 L2lvZGVmOkRldGVjdFRpbWU+XAogICAgICA8aW9kZWY6U3RhcnRUaW1lPjIwMDQtMDItMDVUMDg6 MTM6MzErMDA6MDA8L2lvZGVmOlN0YXJ0VGltZT5cCiAgICAgIDxpb2RlZjpFbmRUaW1lPjIwMDQt MDItMDVUMDg6MTM6MzMrMDA6MDA8L2lvZGVmOkVuZFRpbWU+XAogICAgICA8aW9kZWY6UmVwb3J0 VGltZT4yMDA0LTAyLTA1VDA4OjEzOjM1KzAwOjAwPC9pb2RlZjpSZXBvcnRUaW1lPlwKICAgICAg PGlvZGVmOkRlc2NyaXB0aW9uPkhvc3QgaW52b2x2ZWQgaW4gRG9TIGF0dGFjazwvaW9kZWY6RGVz Y3JpcHRpb24+XAogICAgICA8aW9kZWY6QXNzZXNzbWVudD5cCiAgICAgICAgPGlvZGVmOkltcGFj dCBzZXZlcml0eT0ibG93IiBjb21wbGV0aW9uPSJmYWlsZWQiIHR5cGU9InJlY29uIi8+XAogICAg ICA8L2lvZGVmOkFzc2Vzc21lbnQ+XAogICAgICA8aW9kZWY6Q29udGFjdCByb2xlPSJjcmVhdG9y IiB0eXBlPSJvcmdhbml6YXRpb24iPlwKICAgICAgICA8aW9kZWY6Q29udGFjdE5hbWU+Q29uc3Rp dHVlbmN5LWNvbnRhY3QgZm9yIDE5Mi4wLjIuMzVcCiAgICAgICAgPC9pb2RlZjpDb250YWN0TmFt ZT5cCiAgICAgICAgPGlvZGVmOkVtYWlsPkNvbnN0aXR1ZW5jeS1jb250YWN0QDEwLjEuMS4yPC9p b2RlZjpFbWFpbD5cCiAgICAgIDwvaW9kZWY6Q29udGFjdD5cCiAgICAgIDxpb2RlZjpFdmVudERh dGE+XAogICAgICAgIDxpb2RlZjpGbG93PlwKICAgICAgICAgIDxpb2RlZjpTeXN0ZW0gY2F0ZWdv cnk9InNvdXJjZSI+XApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0MV1cClxwYWdlIFwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDExXApcClwKICAgICAgICAgICAgPGlvZGVmOk5vZGU+XAogICAgICAgICAgICAgIDxpb2RlZjpB ZGRyZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiPjE5Mi4wLjIuMzVcCiAgICAgICAgICAgICAgPC9p b2RlZjpBZGRyZXNzPlwKICAgICAgICAgICAgPC9pb2RlZjpOb2RlPlwKICAgICAgICAgICAgPGlv ZGVmOlNlcnZpY2U+XAogICAgICAgICAgICAgIDxpb2RlZjpwb3J0PjQxNDIxPC9pb2RlZjpwb3J0 PlwKICAgICAgICAgICAgPC9pb2RlZjpTZXJ2aWNlPlwKICAgICAgICAgIDwvaW9kZWY6U3lzdGVt PlwKICAgICAgICAgIDxpb2RlZjpTeXN0ZW0gY2F0ZWdvcnk9InRhcmdldCI+XAogICAgICAgICAg ICA8aW9kZWY6Tm9kZT5cCiAgICAgICAgICAgICAgPGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9Imlw djQtYWRkciI+MTkyLjAuMi42N1wKICAgICAgICAgICAgICA8L2lvZGVmOkFkZHJlc3M+XAogICAg ICAgICAgICA8L2lvZGVmOk5vZGU+XAogICAgICAgICAgICA8aW9kZWY6U2VydmljZT5cCiAgICAg ICAgICAgICAgPGlvZGVmOnBvcnQ+ODA8L2lvZGVmOnBvcnQ+XAogICAgICAgICAgICA8L2lvZGVm OlNlcnZpY2U+XAogICAgICAgICAgPC9pb2RlZjpTeXN0ZW0+XAogICAgICAgIDwvaW9kZWY6Rmxv dz5cCiAgICAgICAgPGlvZGVmOkV4cGVjdGF0aW9uIHNldmVyaXR5PSJoaWdoIiBhY3Rpb249Imlu dmVzdGlnYXRlIj5cCiAgICAgICAgICA8aW9kZWY6RGVzY3JpcHRpb24+XAogICAgICAgICAgICBJ bnZlc3RpZ2F0ZSB3aGV0aGVyIHNvdXJjZSBoYXMgYmVlbiBjb21wcm9taXNlZFwKICAgICAgICAg IDwvaW9kZWY6RGVzY3JpcHRpb24+XAogICAgICAgIDwvaW9kZWY6RXhwZWN0YXRpb24+XAogICAg ICA8L2lvZGVmOkV2ZW50RGF0YT5cCiAgICAgIDxpb2RlZjpIaXN0b3J5PlwKICAgICAgICA8aW9k ZWY6SGlzdG9yeUl0ZW0+XAogICAgICAgICAgPGlvZGVmOkRhdGVUaW1lPjIwMDQtMDItMDVUMDg6 MTk6MDErMDA6MDA8L2lvZGVmOkRhdGVUaW1lPlwKICAgICAgICAgIDxpb2RlZjpJbmNpZGVudElE IG5hbWU9IkNTSVJULUZPUi1PVVItRE9NQUlOIj5cCiAgICAgICAgICAgIENTSVJULUZPUi1PVVIt RE9NQUlOIzIwOC0xXAogICAgICAgICAgPC9pb2RlZjpJbmNpZGVudElEPlwKICAgICAgICAgIDxp b2RlZjpEZXNjcmlwdGlvbj5cCiAgICAgICAgICAgIEludmVzdGlnYXRpb24gcmVxdWVzdCBzZW50 IHRvIFNQIGZvciAxOTIuMC4yLjM1XAogICAgICAgICAgPC9pb2RlZjpEZXNjcmlwdGlvbj5cCiAg ICAgICAgPC9pb2RlZjpIaXN0b3J5SXRlbT5cCiAgICAgIDwvaW9kZWY6SGlzdG9yeT5cCiAgICA8 L2lvZGVmOkluY2lkZW50PlwKICA8L2lvZGVmOklPREVGLURvY3VtZW50PlwKXAo1LjIuMi4gIFJl cXVlc3RBdXRob3JpemF0aW9uIE1lc3NhZ2UgRXhhbXBsZVwKXAogICBUaGUgZXhhbXBsZSBSZXF1 ZXN0QXV0aG9yaXphdGlvbiBtZXNzYWdlIGlzIGluIHJlc3BvbnNlIHRvIHRoZVwKICAgSW52ZXN0 aWdhdGlvbiByZXF1ZXN0IGxpc3RlZCBhYm92ZS4gIFRoZSBTUCB0aGF0IHJlY2VpdmVkIHRoZSBy ZXF1ZXN0XAogICB3YXMgdW5hYmxlIHRvIHZhbGlkYXRlIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSB1 c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGVcCiAgIHNlbmRpbmcgUklEIHN5c3RlbS5cClwKXApcClwK XApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAg ICAgICAgICAgICAgW1BhZ2UgNDJdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIDxp b2RlZi1yaWQ6UklEIHhtbG5zOmlvZGVmLXJpZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2Rl Zi1yaWQtMS4wIlwKICAgICAgICAgICAgICAgICAgeG1sbnM6aW9kZWY9InVybjppZXRmOnBhcmFt czp4bWw6bnM6aW9kZWYtMS4wIj5cCiAgICAgPGlvZGVmLXJpZDpSSURQb2xpY3kgTXNnVHlwZT0i UmVxdWVzdEF1dGhvcml6YXRpb24iXAogICAgICAgICAgICAgICAgICAgICAgICAgIE1zZ0Rlc3Rp bmF0aW9uPSJSSURTeXN0ZW0iPlwKICAgICAgIDxpb2RlZi1yaWQ6UG9saWN5UmVnaW9uIHJlZ2lv bj0iSW50cmFDb25zb3J0aXVtIi8+XAogICAgICAgPGlvZGVmOk5vZGU+XAogICAgICAgICA8aW9k ZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NC1hZGRyIj4xOTIuMC4yLjY3PC9pb2RlZjpBZGRyZXNz PlwKICAgICAgIDwvaW9kZWY6Tm9kZT5cCiAgICAgICA8aW9kZWYtcmlkOlRyYWZmaWNUeXBlIHR5 cGU9IkF0dGFjayIvPlwKICAgICAgIDxpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNFUlQtRk9SLU9V Ui1ET01BSU4iPlwKICAgICAgICAgQ0VSVC1GT1ItT1VSLURPTUFJTiMyMDgtMVwKICAgICAgIDwv aW9kZWY6SW5jaWRlbnRJRD5cCiAgICAgPC9pb2RlZi1yaWQ6UklEUG9saWN5PlwKICAgICA8aW9k ZWYtcmlkOlJlcXVlc3RTdGF0dXMgQXV0aG9yaXphdGlvblN0YXR1cz0iRGVuaWVkIlwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSnVzdGlmaWNhdGlvbj0iQXV0aGVudGljYXRpb24iLz5c CiAgIDwvaW9kZWYtcmlkOlJJRD5cClwKNS4zLiAgUmVwb3J0IENvbW11bmljYXRpb24gRmxvd1wK XAogICBUaGUgZGlhZ3JhbSBiZWxvdyBvdXRsaW5lcyB0aGUgUklEIFJlcG9ydCBjb21tdW5pY2F0 aW9uIGZsb3cgYmV0d2VlblwKICAgUklEIHN5c3RlbXMgb24gZGlmZmVyZW50IG5ldHdvcmtzLlwK XAogICAgICAgICAgIFNQLTEgICAgICAgICAgICAgICAgICAgICAgICAgICBTUC0yXApcCiAgICAg ICAgMS4gR2VuZXJhdGUgaW5jaWRlbnQgaW5mb3JtYXRpb25cCiAgICAgICAgICAgYW5kIHByZXBh cmUgUmVwb3J0IG1lc3NhZ2VcClwKICAgICAgICAyLiAgICAgICAgICAgICAgby0tLS0tLS1SZXBv cnQtLS0tLS0tPlwKXAogICAgICAgIDMuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmls ZSByZXBvcnQgaW4gZGF0YWJhc2VcClwKXAogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA5OiBS ZXBvcnQgQ29tbXVuaWNhdGlvbiBGbG93XApcCiAgIFRoZSBSZXBvcnQgY29tbXVuaWNhdGlvbiBm bG93IGlzIHVzZWQgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBvblwKICAgc3BlY2lmaWMgaW5jaWRl bnRzIGRldGVjdGVkIG9uIHRoZSBuZXR3b3JrLiAgSW5jaWRlbnQgaW5mb3JtYXRpb24gbWF5XAog ICBiZSBzaGFyZWQgYmV0d2VlbiBDU0lSVHMgb3IgcGFydGljaXBhdGluZyBSSUQgaG9zdHMgdXNp bmcgdGhpc1wKICAgZm9ybWF0LiAgV2hlbiBhIHJlcG9ydCBpcyByZWNlaXZlZCwgdGhlIFJJRCBz eXN0ZW0gbXVzdCB2ZXJpZnkgdGhhdFwKICAgdGhlIHJlcG9ydCBoYXMgbm90IGFscmVhZHkgYmVl biBmaWxlZC4gIFRoZSBpbmNpZGVudCBudW1iZXIgYW5kXAogICBpbmNpZGVudCBkYXRhLCBzdWNo IGFzIHRoZSBoZXhhZGVjaW1hbCBwYWNrZXQgYW5kIGluY2lkZW50IGNsYXNzXAogICBpbmZvcm1h dGlvbiwgY2FuIGJlIHVzZWQgdG8gY29tcGFyZSB3aXRoIGV4aXN0aW5nIGRhdGFiYXNlIGVudHJp ZXMuXAogICBUaGUgUmVwb3J0IG1lc3NhZ2UgdHlwaWNhbGx5IGRvZXMgbm90IGhhdmUgYSByZXNw b25zZS4gIElmIHRoZXJlIGlzIGFcCiAgIHByb2JsZW0gd2l0aCB0aGUgUmVwb3J0IG1lc3NhZ2Us IHN1Y2ggYXMgYSBmYWlsdXJlIHRvIHZhbGlkYXRlIHRoZVwKICAgZGlnaXRhbCBzaWduYXR1cmUg W1JGQzMyNzVdIG9yIGRlY3J5cHQgdGhlIHJlcXVlc3QsIGFcCiAgIFJlcXVlc3RBdXRob3JpemF0 aW9uIG1lc3NhZ2UgaXMgc2VudCB0byB0aGUgcmVxdWVzdG9yLiAgVGhlXAogICBSZXF1ZXN0QXV0 aG9yaXphdGlvbiBtZXNzYWdlIHNob3VsZCBwcm92aWRlIHRoZSByZWFzb24gd2h5IHRoZVwKICAg bWVzc2FnZSBjb3VsZCBub3QgYmUgcHJvY2Vzc2VkLlwKXApcClwKXApNb3JpYXJ0eSAgICAgICAg ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0M11c ClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKNS4zLjEuICBSZXBvcnQgRXhhbXBsZVwKXAog ICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgb25seSBpbmNsdWRlcyB0aGUgUklELXNwZWNpZmljIGRl dGFpbHMuICBUaGlzXAogICByZXBvcnQgaXMgYW4gdW5zb2xpY2l0ZWQgUmVwb3J0IG1lc3NhZ2Ug dGhhdCBpbmNsdWRlcyBhbiBJUHY0IHBhY2tldC5cCiAgIFRoZSBJT0RFRiBkb2N1bWVudCBhbmQg ZGlnaXRhbCBzaWduYXR1cmUgd291bGQgYmUgc2ltaWxhciB0byB0aGVcCiAgIFRyYWNlUmVxdWVz dCBpbmZvcm1hdGlvbi5cClwKICAgPGlvZGVmLXJpZDpSSUQgeG1sbnM6aW9kZWYtcmlkPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJpZC0xLjAiXAogICAgICAgICAgICAgICAgICB4bWxu czppb2RlZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2RlZi0xLjAiPlwKICAgICA8aW9kZWYt cmlkOlJJRFBvbGljeSBNc2dUeXBlPSJSZXBvcnQiIE1zZ0Rlc3RpbmF0aW9uPSJSSURTeXN0ZW0i PlwKICAgICAgIDxpb2RlZi1yaWQ6UG9saWN5UmVnaW9uIHJlZ2lvbj0iUGVlclRvUGVlciIvPlwK ICAgICAgIDxpb2RlZjpOb2RlPlwKICAgICAgICAgPGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9Imlw djQtYWRkciI+MTkyLjAuMi4xMzA8L2lvZGVmOkFkZHJlc3M+XAogICAgICAgPC9pb2RlZjpOb2Rl PlwKICAgICAgIDxpb2RlZi1yaWQ6VHJhZmZpY1R5cGUgdHlwZT0iQXR0YWNrIi8+XAogICAgICAg PGlvZGVmOkluY2lkZW50SUQgbmFtZT0iQ0VSVC1GT1ItT1VSLURPTUFJTiI+XAogICAgICAgICBD RVJULUZPUi1PVVItRE9NQUlOIzIwOS0xXAogICAgICAgPC9pb2RlZjpJbmNpZGVudElEPlwKICAg ICA8L2lvZGVmLXJpZDpSSURQb2xpY3k+XAogICA8L2lvZGVmLXJpZDpSSUQ+XApcCiAgIDwhLS0g SU9ERUYtRG9jdW1lbnQgYWNjb21wYW5pZWQgYnkgdGhlIGFib3ZlIFJJRCAtLT5cClwKICAgPGlv ZGVmOklPREVGLURvY3VtZW50IHZlcnNpb249IjEuMDAiXAogICAgICAgICAgICAgICAgICAgICAg ICAgeG1sbnM6aW9kZWY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtMS4wIj5cCiAgICAg PGlvZGVmOkluY2lkZW50IHJlc3RyaWN0aW9uPSJuZWVkLXRvLWtub3ciIHB1cnBvc2U9InJlcG9y dGluZyI+XAogICAgICAgPGlvZGVmOkluY2lkZW50SUQgbmFtZT0iQ0VSVC1GT1ItT1VSLURPTUFJ TiI+XAogICAgICAgICBDRVJULUZPUi1PVVItRE9NQUlOIzIwOS0xXAogICAgICAgPC9pb2RlZjpJ bmNpZGVudElEPlwKICAgICAgIDxpb2RlZjpEZXRlY3RUaW1lPjIwMDQtMDItMDVUMTA6MjE6MDgr MDA6MDA8L2lvZGVmOkRldGVjdFRpbWU+XAogICAgICAgPGlvZGVmOlN0YXJ0VGltZT4yMDA0LTAy LTA1VDEwOjIxOjA1KzAwOjAwPC9pb2RlZjpTdGFydFRpbWU+XAogICAgICAgPGlvZGVmOkVuZFRp bWU+MjAwNC0wMi0wNVQxMDozNTowMCswMDowMDwvaW9kZWY6RW5kVGltZT5cCiAgICAgICA8aW9k ZWY6UmVwb3J0VGltZT4yMDA0LTAyLTA1VDEwOjI3OjM4KzAwOjAwPC9pb2RlZjpSZXBvcnRUaW1l PlwKICAgICAgIDxpb2RlZjpEZXNjcmlwdGlvbj5Ib3N0IGlsbGljaXRseSBhY2Nlc3NlZCBhZG1p biBhY2NvdW50XAogICAgICAgPC9pb2RlZjpEZXNjcmlwdGlvbj5cCiAgICAgICA8aW9kZWY6QXNz ZXNzbWVudD5cCiAgICAgICAgIDxpb2RlZjpJbXBhY3Qgc2V2ZXJpdHk9ImhpZ2giIGNvbXBsZXRp b249InN1Y2NlZWRlZCJcCiAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0iYWRtaW4iLz5cCiAg ICAgICAgIDxpb2RlZjpDb25maWRlbmNlIHJhdGluZz0iaGlnaCIvPlwKICAgICAgIDwvaW9kZWY6 QXNzZXNzbWVudD5cCiAgICAgICA8aW9kZWY6Q29udGFjdCByb2xlPSJjcmVhdG9yIiB0eXBlPSJv cmdhbml6YXRpb24iPlwKICAgICAgICAgPGlvZGVmOkNvbnRhY3ROYW1lPkNvbnN0aXR1ZW5jeS1j b250YWN0IGZvciAxOTIuMC4yLjM1XAogICAgICAgICA8L2lvZGVmOkNvbnRhY3ROYW1lPlwKICAg ICAgICAgPGlvZGVmOkVtYWlsPkNvbnN0aXR1ZW5jeS1jb250YWN0QDEwLjEuMS4yPC9pb2RlZjpF bWFpbD5cCiAgICAgICA8L2lvZGVmOkNvbnRhY3Q+XAogICAgICAgPGlvZGVmOkV2ZW50RGF0YT5c CiAgICAgICAgIDxpb2RlZjpGbG93PlwKICAgICAgICAgICA8aW9kZWY6U3lzdGVtIGNhdGVnb3J5 PSJzb3VyY2UiPlwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFy eSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNDRdXApccGFnZSBcCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAx MVwKXApcCiAgICAgICAgICAgICA8aW9kZWY6Tm9kZT5cCiAgICAgICAgICAgICAgIDxpb2RlZjpB ZGRyZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiPjE5Mi4wLjIuMzVcCiAgICAgICAgICAgICAgIDwv aW9kZWY6QWRkcmVzcz5cCiAgICAgICAgICAgICA8L2lvZGVmOk5vZGU+XAogICAgICAgICAgICAg PGlvZGVmOlNlcnZpY2U+XAogICAgICAgICAgICAgICA8aW9kZWY6cG9ydD4zMjgyMTwvaW9kZWY6 cG9ydD5cCiAgICAgICAgICAgICA8L2lvZGVmOlNlcnZpY2U+XAogICAgICAgICAgIDwvaW9kZWY6 U3lzdGVtPlwKICAgICAgICAgICA8aW9kZWY6U3lzdGVtIGNhdGVnb3J5PSJ0YXJnZXQiPlwKICAg ICAgICAgICAgIDxpb2RlZjpOb2RlPlwKICAgICAgICAgICAgICAgPGlvZGVmOkFkZHJlc3MgY2F0 ZWdvcnk9ImlwdjQtYWRkciI+MTkyLjAuMi42N1wKICAgICAgICAgICAgICAgPC9pb2RlZjpBZGRy ZXNzPlwKICAgICAgICAgICAgIDwvaW9kZWY6Tm9kZT5cCiAgICAgICAgICAgICA8aW9kZWY6U2Vy dmljZT5cCiAgICAgICAgICAgICAgIDxpb2RlZjpwb3J0PjIyPC9pb2RlZjpwb3J0PlwKICAgICAg ICAgICAgIDwvaW9kZWY6U2VydmljZT5cCiAgICAgICAgICAgPC9pb2RlZjpTeXN0ZW0+XAogICAg ICAgICA8L2lvZGVmOkZsb3c+XAogICAgICAgPC9pb2RlZjpFdmVudERhdGE+XAogICAgICAgPGlv ZGVmOkhpc3Rvcnk+XAogICAgICAgICA8aW9kZWY6SGlzdG9yeUl0ZW0+XAogICAgICAgICAgIDxp b2RlZjpEYXRlVGltZT4yMDA0LTAyLTA1VDEwOjI4OjAwKzAwOjAwPC9pb2RlZjpEYXRlVGltZT5c CiAgICAgICAgICAgPGlvZGVmOkluY2lkZW50SUQgbmFtZT0iQ1NJUlQtRk9SLU9VUi1ET01BSU4i PlwKICAgICAgICAgICAgIENTSVJULUZPUi1PVVItRE9NQUlOIzIwOS0xXAogICAgICAgICAgIDwv aW9kZWY6SW5jaWRlbnRJRD5cCiAgICAgICAgICAgPGlvZGVmOkRlc2NyaXB0aW9uPlwKICAgICAg ICAgICAgIEluY2lkZW50IHJlcG9ydCBzZW50IHRvIFNQIGZvciAxOTIuMC4yLjM1XAogICAgICAg ICAgIDwvaW9kZWY6RGVzY3JpcHRpb24+XAogICAgICAgICA8L2lvZGVmOkhpc3RvcnlJdGVtPlwK ICAgICAgIDwvaW9kZWY6SGlzdG9yeT5cCiAgICAgPC9pb2RlZjpJbmNpZGVudD5cCiAgIDwvaW9k ZWY6SU9ERUYtRG9jdW1lbnQ+XApcCjUuNC4gIEluY2lkZW50UXVlcnkgQ29tbXVuaWNhdGlvbiBG bG93XApcCiAgIFRoZSBkaWFncmFtIGJlbG93IG91dGxpbmVzIHRoZSBSSUQgSW5jaWRlbnRRdWVy eSBjb21tdW5pY2F0aW9uIGZsb3dcCiAgIGJldHdlZW4gUklEIHN5c3RlbXMgb24gZGlmZmVyZW50 IG5ldHdvcmtzLlwKXApcClwKXApcClwKXApcClwKXApcClwKXApcCk1vcmlhcnR5ICAgICAgICAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQ1XVwK XHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAg ICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICAgICAgIFNQLTEgICAgICAgICAgICAg ICAgICAgICAgICAgICBTUC0yXApcCiAgICAgICAgMS4gR2VuZXJhdGUgYSByZXF1ZXN0IGZvclwK ICAgICAgICAgICBpbmZvcm1hdGlvbiBvbiBhIHNwZWNpZmljXAogICAgICAgICAgIGluY2lkZW50 IG51bWJlciBvciBpbmNpZGVudCB0eXBlXApcCiAgICAgICAgMi4gICAgICAgICAgICAgIG8tLS1J bmNpZGVudFF1ZXJ5LS0tPlwKXAogICAgICAgIDMuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgVmVyaWZ5IHBvbGljeSBpbmZvcm1hdGlvblwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFuZCBkZXRlcm1pbmUgaWYgbWF0Y2hlcyBleGlzdFwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciByZXF1ZXN0ZWQgaW5mb3JtYXRpb25cClwK ICAgICAgICA0LiAgICAgICAgICAgICAgPC0tLS0tLS1SZXBvcnQtLS0tLS1vXApcCiAgICAgICAg NS4gIEFzc29jaWF0ZSByZXBvcnQgdG8gcmVxdWVzdFwKICAgICAgICAgICAgYnkgaW5jaWRlbnQg bnVtYmVyIG9yIHR5cGVcCiAgICAgICAgICAgIGFuZCBmaWxlIHJlcG9ydChzKS5cClwKICAgICAg ICAgICAgICAgIEZpZ3VyZSAxMDogSW5jaWRlbnRRdWVyeSBDb21tdW5pY2F0aW9uIEZsb3dcClwK ICAgVGhlIEluY2lkZW50UXVlcnkgbWVzc2FnZSBjb21tdW5pY2F0aW9uIHJlY2VpdmVzIGEgcmVz cG9uc2Ugb2YgYVwKICAgUmVwb3J0IG1lc3NhZ2UuICBJZiB0aGUgUmVwb3J0IG1lc3NhZ2UgaXMg ZW1wdHksIHRoZSByZXNwb25kaW5nIGhvc3RcCiAgIGRpZCBub3QgaGF2ZSBpbmZvcm1hdGlvbiBh dmFpbGFibGUgdG8gc2hhcmUgd2l0aCB0aGUgcmVxdWVzdG9yLiAgVGhlXAogICBpbmNpZGVudCBu dW1iZXIgYW5kIHJlc3BvbmRpbmcgUklEIHN5c3RlbSwgYXMgd2VsbCBhcyB0aGUgdHJhbnNwb3J0 LFwKICAgYXNzaXN0IGluIHRoZSBhc3NvY2lhdGlvbiBvZiB0aGUgcmVxdWVzdCBhbmQgcmVzcG9u c2Ugc2luY2UgYSByZXBvcnRcCiAgIGNhbiBiZSBmaWxlZCBhbmQgaXMgbm90IGFsd2F5cyBzb2xp Y2l0ZWQuICBJZiB0aGVyZSBpcyBhIHByb2JsZW0gd2l0aFwKICAgdGhlIEluY2lkZW50UXVlcnkg bWVzc2FnZSwgc3VjaCBhcyBhIGZhaWx1cmUgdG8gdmFsaWRhdGUgdGhlIGRpZ2l0YWxcCiAgIHNp Z25hdHVyZSBvciBkZWNyeXB0IHRoZSByZXF1ZXN0LCBhIFJlcXVlc3RBdXRob3JpemF0aW9uIG1l c3NhZ2UgaXNcCiAgIHNlbnQgdG8gdGhlIHJlcXVlc3Rvci4gIFRoZSBSZXF1ZXN0QXV0aG9yaXph dGlvbiBtZXNzYWdlIHNob3VsZFwKICAgcHJvdmlkZSB0aGUgcmVhc29uIHdoeSB0aGUgbWVzc2Fn ZSBjb3VsZCBub3QgYmUgcHJvY2Vzc2VkLlwKXAo1LjQuMS4gIEluY2lkZW50UXVlcnkgRXhhbXBs ZVwKXAogICBUaGUgSW5jaWRlbnRRdWVyeSByZXF1ZXN0IG1heSBiZSByZWNlaXZlZCBpbiBzZXZl cmFsIGZvcm1hdHMgYXMgYVwKICAgcmVzdWx0IG9mIHRoZSB0eXBlIG9mIHF1ZXJ5IGJlaW5nIHBl cmZvcm1lZC4gIElmIHRoZSBpbmNpZGVudCBudW1iZXJcCiAgIGlzIHRoZSBvbmx5IGluZm9ybWF0 aW9uIHByb3ZpZGVkLCB0aGUgSU9ERUYgZG9jdW1lbnQgYW5kIElQIHBhY2tldFwKICAgZGF0YSBt YXkgbm90IGJlIG5lZWRlZCB0byBjb21wbGV0ZSB0aGUgcmVxdWVzdC4gIEhvd2V2ZXIsIGlmIGEg dHlwZVwKICAgb2YgaW5jaWRlbnQgaXMgcmVxdWVzdGVkLCB0aGUgaW5jaWRlbnQgbnVtYmVyIHJl bWFpbnMgTlVMTCwgYW5kIHRoZVwKICAgSVAgcGFja2V0IGRhdGEgd2lsbCBub3QgYmUgaW5jbHVk ZWQgaW4gdGhlIElPREVGIFJlY29yZEl0ZW0gY2xhc3M7XAogICB0aGUgb3RoZXIgaW5jaWRlbnQg aW5mb3JtYXRpb24gaXMgdGhlIG1haW4gc291cmNlIGZvciBjb21wYXJpc29uLiAgSW5cCiAgIHRo ZSBjYXNlIGluIHdoaWNoIGFuIGluY2lkZW50IG51bWJlciBtYXkgbm90IGJlIHRoZSBzYW1lIGJl dHdlZW5cCiAgIENTSVJUcywgdGhlIGluY2lkZW50IG51bWJlciBhbmQvb3IgSVAgcGFja2V0IGlu Zm9ybWF0aW9uIGNhbiBiZVwKICAgcHJvdmlkZWQgYW5kIHVzZWQgZm9yIGNvbXBhcmlzb24gb24g dGhlIHJlY2VpdmluZyBSSUQgc3lzdGVtIHRvXAogICBnZW5lcmF0ZSAoYSkgUmVwb3J0IG1lc3Nh Z2UocykuXApcClwKXApcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQ2XVwKXHBhZ2UgXApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0 IDIwMTFcClwKXAogICA8aW9kZWYtcmlkOlJJRCB4bWxuczppb2RlZi1yaWQ9InVybjppZXRmOnBh cmFtczp4bWw6bnM6aW9kZWYtcmlkLTEuMCJcCiAgICAgICAgICAgICAgICAgIHhtbG5zOmlvZGVm PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLTEuMCI+XAogICAgIDxpb2RlZi1yaWQ6UklE UG9saWN5IE1zZ1R5cGU9IkluY2lkZW50UXVlcnkiXAogICAgICAgICAgICAgICAgICAgICAgICAg IE1zZ0Rlc3RpbmF0aW9uPSJSSURTeXN0ZW0iPlwKICAgICAgIDxpb2RlZi1yaWQ6UG9saWN5UmVn aW9uIHJlZ2lvbj0iUGVlclRvUGVlciIvPlwKICAgICAgIDxpb2RlZjpOb2RlPlwKICAgICAgICAg PGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImlwdjQtYWRkciI+MTkyLjAuMi4zPC9pb2RlZjpBZGRy ZXNzPlwKICAgICAgIDwvaW9kZWY6Tm9kZT5cCiAgICAgICA8aW9kZWYtcmlkOlRyYWZmaWNUeXBl IHR5cGU9IkF0dGFjayIvPlwKICAgICAgIDxpb2RlZjpJbmNpZGVudElEIG5hbWU9IkNFUlQtRk9S LU9VUi1ET01BSU4iPlwKICAgICAgICAgQ0VSVC1GT1ItT1VSLURPTUFJTiMyMTAtMVwKICAgICAg IDwvaW9kZWY6SW5jaWRlbnRJRD5cCiAgICAgPC9pb2RlZi1yaWQ6UklEUG9saWN5PlwKICAgPC9p b2RlZi1yaWQ6UklEPlwKXApcCjYuICBSSUQgU2NoZW1hIERlZmluaXRpb25cClwKIDw/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+XAogPHhzOnNjaGVtYSB4bWxuczppb2RlZi1y aWQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtcmlkLTEuMCJcCiAgeG1sbnM6aW9kZWY9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtMS4wIlwKICB4bWxuczp4cz0iaHR0cDovL3d3 dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiXAogIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8y MDAwLzA5L3htbGRzaWcjIlwKICB0YXJnZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6 bnM6aW9kZWYtcmlkLTEuMCJcCiAgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiIGF0dHJp YnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCI+XAogPHhzOmltcG9ydCBuYW1lc3BhY2U9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6aW9kZWYtMS4wIlwKICBzY2hlbWFMb2NhdGlvbj0iaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy94bWwtcmVnaXN0cnkvXAogIHNjaGVtYS9pb2RlZi1y aWQtMS4wLnhzZCIvPlwKXAogPHhzOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly93d3cudzMub3Jn LzIwMDAvMDkveG1sZHNpZyMiXAogIHNjaGVtYUxvY2F0aW9uPVwKICAiaHR0cDovL3d3dy53My5v cmcvVFIveG1sZHNpZy1jb3JlL3htbGRzaWctY29yZS1zY2hlbWEueHNkIi8+XApcCiA8IS0tICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKipcCiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKipcCiAqKiogIFJlYWwtdGltZSBJbnRlci1uZXR3b3JrIERlZmVu c2UgLSBSSUQgWE1MIFNjaGVtYSAgICAgICAgICAgICAqKipcCiAqKiogICAgTmFtZXNwYWNlIC0g aW9kZWYtcmlkLCBBdWd1c3QgMjAxMSAgICAgICAgICAgICAgICAgICAgICAgICAqKipcCiAqKiog ICAgVGhlIG5hbWVzcGFjZSBpcyBkZWZpbmVkIHRvIHN1cHBvcnQgdHJhbnNwb3J0IG9mIElPREVG ICAgICAqKipcCiAqKiogICAgIGRvY3VtZW50cyBmb3IgZXhjaGFuZ2luZyBpbmNpZGVudCBpbmZv cm1hdGlvbi4gICAgICAgICAgICAqKipcCiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKipcCiAtLT5cCiA8IS0tUklEIGFj dHMgYXMgYW4gZW52ZWxvcGUgZm9yIElPREVGIGRvY3VtZW50cyB0byBzdXBwb3J0IHRoZSBleGNo YW5nZVwKICAgICBvZiBtZXNzYWdlcy0tPlwKIDwhLS1cCiA9PT09PT0gUmVhbC1UaW1lIEludGVy LW5ldHdvcmsgRGVmZW5zZSAtIFJJRCA9PT09PT1cCiA9PT09ICBTdWdnZXN0ZWQgZGVmaW5pdGlv biBmb3IgUklEIG1lc3NhZ2luZyA9PT09PT1cCiAgLS0+XApcClwKXApcCk1vcmlhcnR5ICAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQ3 XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAg ICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogPHhzOmFubm90YXRpb24+XAogICA8eHM6 ZG9jdW1lbnRhdGlvbj5YTUwgU2NoZW1hIHdyYXBwZXIgZm9yIElPREVGPC94czpkb2N1bWVudGF0 aW9uPlwKIDwveHM6YW5ub3RhdGlvbj5cCiA8eHM6ZWxlbWVudCBuYW1lPSJSSUQiIHR5cGU9Imlv ZGVmLXJpZDpSSURUeXBlIi8+XAogICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iUklEVHlwZSI+XAog ICAgIDx4czpzZXF1ZW5jZT5cCiAgICAgICA8eHM6ZWxlbWVudCByZWY9ImlvZGVmLXJpZDpSSURQ b2xpY3kiIG1pbk9jY3Vycz0iMCIvPlwKICAgICAgIDx4czplbGVtZW50IHJlZj0iaW9kZWYtcmlk OlJlcXVlc3RTdGF0dXMiIG1pbk9jY3Vycz0iMCIvPlwKICAgICAgIDx4czplbGVtZW50IHJlZj0i aW9kZWYtcmlkOkluY2lkZW50U291cmNlIiBtaW5PY2N1cnM9IjAiLz5cCiAgICAgPC94czpzZXF1 ZW5jZT5cCiAgIDwveHM6Y29tcGxleFR5cGU+XApcCiA8IS0tVXNlZCBpbiBSZXF1ZXN0QXV0aG9y aXphdGlvbiBNZXNzYWdlIGZvciBSSUQtLT5cClwKIDx4czplbGVtZW50IG5hbWU9IlJlcXVlc3RT dGF0dXMiIHR5cGU9ImlvZGVmLXJpZDpSZXF1ZXN0U3RhdHVzVHlwZSIvPlwKICAgPHhzOmNvbXBs ZXhUeXBlIG5hbWU9IlJlcXVlc3RTdGF0dXNUeXBlIj5cCiAgICAgIDx4czphdHRyaWJ1dGUgbmFt ZT0iQXV0aG9yaXphdGlvblN0YXR1cyIgdXNlPSJyZXF1aXJlZCI+XAogICAgICAgICA8eHM6c2lt cGxlVHlwZT5cCiAgICAgICAgICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOk5NVE9LRU4iPlwK ICAgICAgICAgICA8eHM6d2hpdGVTcGFjZSB2YWx1ZT0iY29sbGFwc2UiLz5cCiAgICAgICAgICAg ICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkFwcHJvdmVkIi8+XAogICAgICAgICAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJEZW5pZWQiLz5cCiAgICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24g dmFsdWU9IlBlbmRpbmciLz5cCiAgICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9ImV4 dC12YWx1ZSIvPlwKICAgICAgICAgICA8L3hzOnJlc3RyaWN0aW9uPlwKICAgICAgICAgPC94czpz aW1wbGVUeXBlPlwKICAgICAgPC94czphdHRyaWJ1dGU+XAogICAgICA8eHM6YXR0cmlidXRlIG5h bWU9ImV4dC1BdXRob3JpemF0aW9uU3RhdHVzIlwKICAgICAgICAgICAgICAgICAgICB0eXBlPSJ4 czpzdHJpbmciIHVzZT0ib3B0aW9uYWwiLz5cCiAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iSnVz dGlmaWNhdGlvbiI+XAogICAgICAgICA8eHM6c2ltcGxlVHlwZT5cCiAgICAgICAgICAgPHhzOnJl c3RyaWN0aW9uIGJhc2U9InhzOk5NVE9LRU4iPlwKICAgICAgICAgICA8eHM6d2hpdGVTcGFjZSB2 YWx1ZT0iY29sbGFwc2UiLz5cCiAgICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlN5 c3RlbVJlc291cmNlIi8+XAogICAgICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJBdXRo ZW50aWNhdGlvbiIvPlwKICAgICAgICAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iQXV0aGVu dGljYXRpb25PcmlnaW4iLz5cCiAgICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkVu Y3J5cHRpb24iLz5cCiAgICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9Ik90aGVyIi8+ XAogICAgICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJleHQtdmFsdWUiLz5cCiAgICAg ICAgICAgPC94czpyZXN0cmljdGlvbj5cCiAgICAgICAgIDwveHM6c2ltcGxlVHlwZT5cCiAgICAg IDwveHM6YXR0cmlidXRlPlwKICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJleHQtSnVzdGlmaWNh dGlvbiJcCiAgICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIiB1c2U9Im9wdGlvbmFs Ii8+XAogICAgIDx4czphdHRyaWJ1dGUgbmFtZT0icmVzdHJpY3Rpb24iIHR5cGU9ImlvZGVmOnJl c3RyaWN0aW9uLXR5cGUiLz5cCiAgIDwveHM6Y29tcGxleFR5cGU+XApcCiA8IS0tSW5jaWRlbnQg U291cmNlIEluZm9ybWF0aW9uIGZvciBSZXN1bHQgTWVzc2FnZS0tPlwKXApcClwKTW9yaWFydHkg ICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1Bh Z2UgNDhdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJp cyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiA8eHM6ZWxlbWVudCBuYW1lPSJJ bmNpZGVudFNvdXJjZSIgdHlwZT0iaW9kZWYtcmlkOkluY2lkZW50U291cmNlVHlwZSIvPlwKICAg PHhzOmNvbXBsZXhUeXBlIG5hbWU9IkluY2lkZW50U291cmNlVHlwZSI+XAogICAgIDx4czpzZXF1 ZW5jZT5cCiAgICAgICA8eHM6ZWxlbWVudCByZWY9ImlvZGVmLXJpZDpTb3VyY2VGb3VuZCIvPlwK ICAgICAgIDx4czplbGVtZW50IHJlZj0iaW9kZWY6Tm9kZSIgbWluT2NjdXJzPSIwIlwKICAgICAg ICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPlwKICAgICA8L3hzOnNlcXVlbmNlPlwKICAgICA8 eHM6YXR0cmlidXRlIG5hbWU9InJlc3RyaWN0aW9uIiB0eXBlPSJpb2RlZjpyZXN0cmljdGlvbi10 eXBlIi8+XAogICA8L3hzOmNvbXBsZXhUeXBlPlwKICAgPHhzOmVsZW1lbnQgbmFtZT0iU291cmNl Rm91bmQiIHR5cGU9InhzOmJvb2xlYW4iLz5cClwKIDwhLS1cCiA9PT09PT0gUmVhbC1UaW1lIElu dGVyLW5ldHdvcmsgRGVmZW5zZSBQb2xpY3kgLSBSSURQb2xpY3kgPT09PT09XAogPT09PT09ICBE ZWZpbml0aW9uIGZvciBSSURQb2xpY3kgZm9yIG1lc3NhZ2luZ1wKICAtLT5cClwKIDx4czphbm5v dGF0aW9uPlwKICA8eHM6ZG9jdW1lbnRhdGlvbj5SSUQgUG9saWN5IHVzZWQgZm9yIHRyYW5zcG9y dCBvZlwKICAgICAgbWVzc2FnZXM8L3hzOmRvY3VtZW50YXRpb24+XAogPC94czphbm5vdGF0aW9u PlwKXAogPCEtLSBSSURQb2xpY3kgaW5mb3JtYXRpb24gd2l0aCBzZXR0aW5nIGluZm9ybWF0aW9u IGxpc3RlZCBpbiBSSURcCiAgICAgIGRvY3VtZW50YXRpb24gLS0+XApcCiA8eHM6ZWxlbWVudCBu YW1lPSJSSURQb2xpY3kiIHR5cGU9ImlvZGVmLXJpZDpSSURQb2xpY3lUeXBlIi8+XAogICA8eHM6 Y29tcGxleFR5cGUgbmFtZT0iUklEUG9saWN5VHlwZSI+XAogICAgIDx4czpzZXF1ZW5jZT5cCiAg ICAgICA8eHM6ZWxlbWVudCByZWY9ImlvZGVmLXJpZDpQb2xpY3lSZWdpb24iIG1heE9jY3Vycz0i dW5ib3VuZGVkIi8+XAogICAgICAgPHhzOmVsZW1lbnQgcmVmPSJpb2RlZjpOb2RlIi8+XAogICAg ICAgPHhzOmVsZW1lbnQgcmVmPSJpb2RlZi1yaWQ6VHJhZmZpY1R5cGUiIG1heE9jY3Vycz0idW5i b3VuZGVkIi8+XAogICAgICAgPHhzOmVsZW1lbnQgcmVmPSJpb2RlZjpJbmNpZGVudElEIiBtaW5P Y2N1cnM9IjAiLz5cCiAgICAgPC94czpzZXF1ZW5jZT5cCiAgICA8eHM6YXR0cmlidXRlIG5hbWU9 Ik1zZ1R5cGUiIHVzZT0icmVxdWlyZWQiPlwKICAgICA8eHM6c2ltcGxlVHlwZT5cCiAgICAgICA8 eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6Tk1UT0tFTiI+XAogICAgICAgPHhzOndoaXRlU3BhY2Ug dmFsdWU9ImNvbGxhcHNlIi8+XAogICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlRyYWNl UmVxdWVzdCIvPlwKICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJSZXF1ZXN0QXV0aG9y aXphdGlvbiIvPlwKICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJSZXN1bHQiLz5cCiAg ICAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iSW52ZXN0aWdhdGlvbiIvPlwKICAgICAgICAg PHhzOmVudW1lcmF0aW9uIHZhbHVlPSJSZXBvcnQiLz5cCiAgICAgICAgIDx4czplbnVtZXJhdGlv biB2YWx1ZT0iSW5jaWRlbnRRdWVyeSIvPlwKICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVl PSJleHQtdmFsdWUiLz5cCiAgICAgICA8L3hzOnJlc3RyaWN0aW9uPlwKICAgICA8L3hzOnNpbXBs ZVR5cGU+XAogICAgPC94czphdHRyaWJ1dGU+XAogICA8eHM6YXR0cmlidXRlIG5hbWU9ImV4dC1N c2dUeXBlIiB0eXBlPSJ4czpzdHJpbmciIHVzZT0ib3B0aW9uYWwiLz5cCiAgIDx4czphdHRyaWJ1 dGUgbmFtZT0iTXNnRGVzdGluYXRpb24iIHVzZT0icmVxdWlyZWQiPlwKXApcClwKTW9yaWFydHkg ICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1Bh Z2UgNDldXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJp cyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgICAgPHhzOnNpbXBsZVR5cGU+ XAogICAgICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOk5NVE9LRU4iPlwKICAgICAgIDx4czp3 aGl0ZVNwYWNlIHZhbHVlPSJjb2xsYXBzZSIvPlwKICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZh bHVlPSJSSURTeXN0ZW0iLz5cCiAgICAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iU291cmNl T2ZJbmNpZGVudCIvPlwKICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJleHQtdmFsdWUi Lz5cCiAgICAgICA8L3hzOnJlc3RyaWN0aW9uPlwKICAgICA8L3hzOnNpbXBsZVR5cGU+XAogICAg PC94czphdHRyaWJ1dGU+XAogICA8eHM6YXR0cmlidXRlIG5hbWU9ImV4dC1Nc2dEZXN0aW5hdGlv biIgdHlwZT0ieHM6c3RyaW5nIlwKICAgICAgICAgICAgICAgICB1c2U9Im9wdGlvbmFsIi8+XAog ICAgPC94czpjb21wbGV4VHlwZT5cCiAgIDx4czplbGVtZW50IG5hbWU9IlBvbGljeVJlZ2lvbiI+ XAogICAgIDx4czpjb21wbGV4VHlwZT5cCiAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0icmVnaW9u IiB1c2U9InJlcXVpcmVkIj5cCiAgICAgICA8eHM6c2ltcGxlVHlwZT5cCiAgICAgICAgPHhzOnJl c3RyaWN0aW9uIGJhc2U9InhzOk5NVE9LRU4iPlwKICAgICAgICA8eHM6d2hpdGVTcGFjZSB2YWx1 ZT0iY29sbGFwc2UiLz5cCiAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkNsaWVudFRv U1AiLz5cCiAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlNQVG9DbGllbnQiLz5cCiAg ICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkludHJhQ29uc29ydGl1bSIvPlwKICAgICAg ICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iUGVlclRvUGVlciIvPlwKICAgICAgICAgIDx4czpl bnVtZXJhdGlvbiB2YWx1ZT0iQmV0d2VlbkNvbnNvcnRpdW1zIi8+XAogICAgICAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJBY3Jvc3NOYXRpb25hbEJvdW5kYXJpZXMiLz5cCiAgICAgICAgICA8 eHM6ZW51bWVyYXRpb24gdmFsdWU9Ikxhd0VuZm9yY2VtZW50Ii8+XAogICAgICAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJleHQtdmFsdWUiLz5cCiAgICAgICAgPC94czpyZXN0cmljdGlvbj5c CiAgICAgICA8L3hzOnNpbXBsZVR5cGU+XAogICAgICA8L3hzOmF0dHJpYnV0ZT5cCiAgICAgIDx4 czphdHRyaWJ1dGUgbmFtZT0iZXh0LXJlZ2lvbiJcCiAgICAgICAgICAgICAgICAgICAgdHlwZT0i eHM6c3RyaW5nIiB1c2U9Im9wdGlvbmFsIi8+XAogICAgIDwveHM6Y29tcGxleFR5cGU+XAogICA8 L3hzOmVsZW1lbnQ+XAogICA8eHM6ZWxlbWVudCBuYW1lPSJUcmFmZmljVHlwZSI+XAogICAgIDx4 czpjb21wbGV4VHlwZT5cCiAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0idHlwZSIgdXNlPSJyZXF1 aXJlZCI+XAogICAgICAgPHhzOnNpbXBsZVR5cGU+XAogICAgICAgIDx4czpyZXN0cmljdGlvbiBi YXNlPSJ4czpOTVRPS0VOIj5cCiAgICAgICAgPHhzOndoaXRlU3BhY2UgdmFsdWU9ImNvbGxhcHNl Ii8+XAogICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJBdHRhY2siLz5cCiAgICAgICAg ICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9Ik5ldHdvcmsiLz5cCiAgICAgICAgICA8eHM6ZW51bWVy YXRpb24gdmFsdWU9IkNvbnRlbnQiLz5cCiAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9 Ik9mZmljaWFsQnVzaW5lc3MiLz5cCiAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9Ik90 aGVyIi8+XAogICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJleHQtdmFsdWUiLz5cCiAg ICAgICAgPC94czpyZXN0cmljdGlvbj5cCiAgICAgICA8L3hzOnNpbXBsZVR5cGU+XAogICAgICA8 L3hzOmF0dHJpYnV0ZT5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDUwXVwKXHBhZ2UgXApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0 IDIwMTFcClwKXAogICAgICA8eHM6YXR0cmlidXRlIG5hbWU9ImV4dC10eXBlIlwKICAgICAgICAg ICAgICAgICAgICB0eXBlPSJ4czpzdHJpbmciIHVzZT0ib3B0aW9uYWwiLz5cCiAgICAgIDx4czph dHRyaWJ1dGUgbmFtZT0icmVzdHJpY3Rpb24iIHR5cGU9ImlvZGVmOnJlc3RyaWN0aW9uLXR5cGUi Lz5cCiAgICAgPC94czpjb21wbGV4VHlwZT5cCiAgIDwveHM6ZWxlbWVudD5cCiA8L3hzOnNjaGVt YT5cClwKXAo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnNcClwKICAgUklEIGhhcyBtYW55IHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGJ1aWx0IGludG8gdGhlIGRlc2lnbiBvZiB0aGVcCiAgIHBy b3RvY29sLCBzZXZlcmFsIG9mIHdoaWNoIGFyZSBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBz dWItXAogICBzZWN0aW9ucy4gIEZvciBhIGNvbXBsZXRlIHZpZXcgb2Ygc2VjdXJpdHksIGNvbnNp ZGVyYXRpb25zIG5lZWQgdG9cCiAgIGluY2x1ZGUgdGhlIGF2YWlsYWJpbGl0eSwgY29uZmlkZW50 aWFsaXR5LCBhbmQgaW50ZWdyaXR5IGNvbmNlcm5zIGZvclwKICAgdGhlIHRyYW5zcG9ydCwgc3Rv cmFnZSwgYW5kIGV4Y2hhbmdlIG9mIGluZm9ybWF0aW9uLlwKXAogICBBdXRoZW50aWNhdGVkIGVu Y3J5cHRlZCB0dW5uZWxzIGJldHdlZW4gc3lzdGVtcyBhY2NlcHRpbmcgUklEXAogICBjb21tdW5p Y2F0aW9ucyBNVVNUIGJlIHVzZWQgdG8gcHJvdmlkZSBjb25maWRlbnRpYWxpdHksIGludGVncml0 eSxcCiAgIGF1dGhlbnRpY2l0eSwgYW5kIHByaXZhY3kgZm9yIHRoZSBkYXRhLiAgRW5jcnlwdGlv biBhbmQgZGlnaXRhbFwKICAgc2lnbmF0dXJlcyBhcmUgYWxzbyB1c2VkIGF0IHRoZSBJT0VERiBk b2N1bWVudCBsZXZlbCB0aHJvdWdoIFJJRFwKICAgb3B0aW9ucyB0byBwcm92aWRlIGNvbmZpZGVu dGlhbGl0eSwgaW50ZWdyaXR5LCBhdXRoZW50aWNpdHksIHByaXZhY3lcCiAgIGFuZCB0cmFjZWFi aWxpdHkgb2YgdGhlIGRvY3VtZW50IGNvbnRlbnRzLiAgVHJ1c3QgcmVsYXRpb25zaGlwcyBhcmVc CiAgIGJhc2VkIG9uIGNvbnNvcnRpdW1zIGFuZCBlc3RhYmxpc2hlZCB0cnVzdCByZWxhdGlvbnNo aXBzIG9mIHB1YmxpY1wKICAga2V5IGluZnJhc3RydWN0dXJlIChQS0kpIGNyb3NzLWNlcnRpZmlj YXRpb25zIG9mIGNvbnNvcnRpdW1zLiAgVHJ1c3RcCiAgIGxldmVscyBjYW4gYmUgZXN0YWJsaXNo ZWQgaW4gY3Jvc3MtY2VydGlmaWNhdGlvbiBwcm9jZXNzZXMgd2hlcmVcCiAgIGVudGl0aWVzIGNv bXBhcmUgUEtJIHBvbGljaWVzIHRoYXQgaW5jbHVkZSB0aGUgc3BlY2lmaWMgbWFuYWdlbWVudFwK ICAgYW5kIGhhbmRsaW5nIG9mIGFuIGVudGl0eSdzIFBLSSBhbmQgY2VydGlmaWNhdGVzIGlzc3Vl ZCB1bmRlciB0aGF0XAogICBwb2xpY3kuICBbUkZDMzY0N10gZGVmaW5lcyBhbiBJbnRlcm5ldCBY LjUwOSBQdWJsaWMgS2V5XAogICBJbmZyYXN0cnVjdHVyZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgYW5k IENlcnRpZmljYXRpb24gUHJhY3RpY2VzXAogICBGcmFtZXdvcmsgdGhhdCBtYXkgYmUgdXNlZCBp biB0aGUgY29tcGFyaXNvbiBvZiBwb2xpY2llcyB0byBlc3RhYmxpc2hcCiAgIHRydXN0IGxldmVs cyBhbmQgYWdyZWVtZW50cyBiZXR3ZWVuIGVudGl0aWVzLCBhbiBlbnRpdHkgYW5kIGFcCiAgIGNv bnNvcnRpdW0sIGFuZCBjb25zb3J0aWEuICBUaGUgYWdyZWVtZW50cyBTSE9VTEQgY29uc2lkZXIg a2V5XAogICBtYW5hZ2VtZW50IHByYWN0aWNlcyBpbmNsdWRpbmcgdGhlIGFiaWxpdHkgdG8gcGVy Zm9ybSBwYXRoIHZhbGlkYXRpb25cCiAgIG9uIGNlcnRpZmljYXRlcyBbUkZDNTI4MF0sIGtleSBk aXN0cmlidXRpb24gdGVjaG5pcXVlcyBbUkZDMjU4NV0sXAogICBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkgYW5kIFJlZ2lzdHJhdGlvbiBBdXRob3JpdHkgbWFuYWdlbWVudFwKICAgcHJhY3RpY2VzLlwK XAogICBUaGUgYWdyZWVtZW50cyBiZXR3ZWVuIGVudGl0aWVzIFNIT1VMRCBhbHNvIGluY2x1ZGUg YSBjb21tb25cCiAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIHVzYWdlIG9mIFJJRCBzZWN1cml0eSwg cG9saWN5LCBhbmQgcHJpdmFjeVwKICAgb3B0aW9ucyBkaXNjdXNzZWQgaW4gdGhpcyBzZWN0aW9u LiAgVGhlIGZvcm1hbGl0eSwgcmVxdWlyZW1lbnRzLCBhbmRcCiAgIGNvbXBsZXhpdHkgb2YgdGhl IGFncmVlbWVudHMgZm9yIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY3ksIHByYWN0aWNlcyxcCiAgIGFu ZCB0aGUgdXNlIG9mIFJJRCBvcHRpb25zIFNIT1VMRCBiZSBkZWNpZGVkIGJ5IHRoZSBlbnRpdGll cyBvclwKICAgY29uc29ydGl1bXMgY3JlYXRpbmcgdGhvc2UgYWdyZWVtZW50cy5cClwKICAgQnkg dXNpbmcgUklEUG9saWN5IGluZm9ybWF0aW9uLCBUTFMsIGFuZCB0aGUgWE1MIHNlY3VyaXR5IGZl YXR1cmVzIG9mXAogICBlbmNyeXB0aW9uIFtYTUxlbmNyeXB0XSBhbmQgZGlnaXRhbCBzaWduYXR1 cmVzIFtSRkMzMjc1XSwgW1hNTHNpZ10sXAogICBSSUQgdGFrZXMgYWR2YW50YWdlIG9mIGV4aXN0 aW5nIHNlY3VyaXR5IHN0YW5kYXJkcy4gIFRoZSBzdGFuZGFyZHNcCiAgIHByb3ZpZGUgY2xlYXIg bWV0aG9kcyB0byBlbnN1cmUgdGhhdCBtZXNzYWdlcyBhcmUgc2VjdXJlLFwKXApcClwKTW9yaWFy dHkgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAg W1BhZ2UgNTFdXApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1 LWJpcyAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIGF1dGhlbnRpY2F0ZWQs IGFuZCBhdXRob3JpemVkLCBhbmQgdGhhdCB0aGUgbWVzc2FnZXMgbWVldCBwb2xpY3kgYW5kXAog ICBwcml2YWN5IGd1aWRlbGluZXMgYW5kIG1haW50YWluIGludGVncml0eS5cClwKICAgQXMgc3Bl Y2lmaWVkIGluIHRoZSByZWxldmFudCBzZWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50LCB0aGUgWE1M XAogICBkaWdpdGFsIHNpZ25hdHVyZSBbUkZDMzI3NV0gYW5kIFhNTCBlbmNyeXB0aW9uIFtYTUxl bmNyeXB0XSBhcmUgdXNlZFwKICAgaW4gdGhlIGZvbGxvd2luZyBjYXNlczpcClwKICAgWE1MIERp Z2l0YWwgU2lnbmF0dXJlXApcCiAgIG8gIFRoZSBvcmlnaW5hdG9yIG9mIHRoZSBUcmFjZVJlcXVl c3Qgb3IgSW52ZXN0aWdhdGlvbiByZXF1ZXN0IE1VU1RcCiAgICAgIHVzZSBhIGRldGFjaGVkIHNp Z25hdHVyZSB0byBzaWduIGF0IGxlYXN0IG9uZSBvZiB0aGUgb3JpZ2luYWxcCiAgICAgIGVsZW1l bnRzIGNvbnRhaW5lZCBpbiB0aGUgUmVjb3JkSXRlbSBjbGFzcyB0byBwcm92aWRlXAogICAgICBh dXRoZW50aWNhdGlvbiB0byBhbGwgdXBzdHJlYW0gcGFydGljaXBhbnRzIGluIHRoZSB0cmFjZSBv ciB0aG9zZVwKICAgICAgaW52b2x2ZWQgaW4gdGhlIGludmVzdGlnYXRpb24uICBBbGwgaW5zdGFu Y2VzIG9mIFJlY29yZEl0ZW1cCiAgICAgIHByb3ZpZGVkIGJ5IHRoZSBvcmlnaW5hdG9yIG1heSBi ZSBpbmRpdmlkdWFsbHkgc2lnbmVkLCBhbmRcCiAgICAgIGFkZGl0aW9uYWwgUmVjb3JkSXRlbSBl bnRyaWVzIGJ5IHVwc3RyZWFtIHBlZXJzIGluIHRoZSB0cmFjZSBvclwKICAgICAgaW52ZXN0aWdh dGlvbiBtYXkgYmUgc2lnbmVkIGJ5IHRoZSBwZWVyIGFkZGluZyB0aGUgZGF0YSwgd2hpbGVcCiAg ICAgIG1haW50YWluaW5nIHRoZSBvcmlnaW5hbCBSZWNvcmRJdGVtIGVudHJ5KHMpIGFuZCBkZXRh Y2hlZFwKICAgICAgc2lnbmF0dXJlKHMpIGZyb20gdGhlIG9yaWdpbmFsIHJlcXVlc3Rvci4gIEl0 IGlzIGltcG9ydGFudCB0byBub3RlXAogICAgICB0aGF0IHRoZSBkYXRhIGlzIHNpZ25lZCBhdCB0 aGUgUmVjb3JkSXRlbSBsZXZlbC4gIFNpbmNlIG11bHRpcGxlXAogICAgICBSZWNvcmRJdGVtcyBt YXkgZXhpc3Qgd2l0aGluIGFuIElPREVGIGRvY3VtZW50IGFuZCBtYXkgb3JpZ2luYXRlXAogICAg ICBmcm9tIGRpZmZlcmVudCBzb3VyY2VzLCB0aGUgc2lnbmF0dXJlIGlzIGFwcGxpZWQgYXQgdGhl IFJlY29yZEl0ZW1cCiAgICAgIGxldmVsIHRvIGVuYWJsZSB0aGUgdXNlIG9mIGFuIFhNTCBkZXRh Y2hlZCBzaWduYXR1cmUuICBUaGlzXAogICAgICBzaWduYXR1cmUgTVVTVCBiZSBwYXNzZWQgdG8g YWxsIHJlY2lwaWVudHMgb2YgdGhlIFRyYWNlUmVxdWVzdCBvclwKICAgICAgSW52ZXN0aWdhdGlv biByZXF1ZXN0LlwKXAogICBvICBJZiBhbiBJbnZlc3RpZ2F0aW9uIG9yIFRyYWNlUmVxdWVzdCBk b2VzIG5vdCBpbmNsdWRlIGEgUmVjb3JkSXRlbVwKICAgICAgZW50cnksIGFuIE5UUCB0aW1lc3Rh bXAgbWF5IGJlIHVzZWQgdG8gZW5zdXJlIHRoZXJlIGlzIGRhdGEgdG8gYmVcCiAgICAgIHNpZ25l ZCBmb3IgdGhlIG11bHRpLWhvcCBhdXRoZW50aWNhdGlvbiB1c2UgY2FzZS5cClwKICAgbyAgRm9y IGFsbCBtZXNzYWdlIHR5cGVzLCB0aGUgZnVsbCBJT0RFRi9SSUQgZG9jdW1lbnQgTVVTVCBiZSBz aWduZWRcCiAgICAgIHVzaW5nIGFuIGVudmVsb3BlZCBzaWduYXR1cmUgYnkgdGhlIHNlbmRpbmcg cGVlciB0byBwcm92aWRlXAogICAgICBhdXRoZW50aWNhdGlvbiBhbmQgaW50ZWdyaXR5IHRvIHRo ZSByZWNlaXZpbmcgUklEIHN5c3RlbS5cClwKICAgbyAgT3B0aW9uYWxseSwgbmVzdGVkIGVudmVs b3BlZCBzaWduYXR1cmVzIE1BWSBiZSB1c2VkIHdoZW5cCiAgICAgIGZvcndhcmRpbmcgZG9jdW1l bnRzIGR1cmluZyBhbiBpbnZlc3RpZ2F0aW9uLiAgSWYgdGhpcyBvcHRpb24gaXNcCiAgICAgIHVz ZWQsIHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNUIGZvbGxvdyB0aGUgZ3VpZGFuY2Ugc3BlY2lmaWVk IGluIHRoZVwKICAgICAgWE1MIERpZ2l0YWwgU2lnbmF0dXJlIFtYTUxzaWddIHNwZWNpZmljYXRp b24gZm9yIHR3byBvciBtb3JlXAogICAgICBlbnZlbG9wZWQgc2lnbmF0dXJlcy5cClwKICAgWE1M IEVuY3J5cHRpb25cClwKICAgbyAgVGhlIElPREVGL1JJRCBkb2N1bWVudCBtYXkgYmUgZW5jcnlw dGVkIHRvIHByb3ZpZGUgYW4gZXh0cmEgbGF5ZXJcCiAgICAgIG9mIHNlY3VyaXR5IGJldHdlZW4g cGVlcnMgc28gdGhhdCB0aGUgbWVzc2FnZSBpcyBub3Qgb25seVwKICAgICAgZW5jcnlwdGVkIGZv ciB0aGUgdHJhbnNwb3J0LCBidXQgYWxzbyB3aGlsZSBzdG9yZWQuICBUaGlzIGJlaGF2aW9yXAog ICAgICB3b3VsZCBiZSBhZ3JlZWQgdXBvbiBiZXR3ZWVuIHBlZXJzIG9yIGEgY29uc29ydGl1bSwg b3IgZGV0ZXJtaW5lZFwKICAgICAgb24gYSBwZXItbWVzc2FnZSBiYXNpcywgZGVwZW5kaW5nIG9u IHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gIEl0XAogICAgICBzaG91bGQgYmUgbm90ZWQgdGhhdCB0 aGVyZSBhcmUgY2FzZXMgZm9yIHRyYW5zcG9ydCB3aGVyZSB0aGVcClwKXApcCk1vcmlhcnR5ICAg ICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdl IDUyXVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMg ICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICAgICBSSURQb2xpY3kgY2xhc3Mg bmVlZHMgdG8gYmUgcHJlc2VudGVkIGluIGNsZWFyIHRleHQsIGFzIGRldGFpbGVkXAogICAgICBp biB0aGUgdHJhbnNwb3J0IGRvY3VtZW50IFtSRkM2MDQ2XS5cClwKICAgbyAgQW4gSW52ZXN0aWdh dGlvbiByZXF1ZXN0LCBvciBhbnkgb3RoZXIgbWVzc2FnZSB0eXBlIHRoYXQgbWF5IGJlXAogICAg ICByZWxheWVkIHRocm91Z2ggUklEIHN5c3RlbXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgZGVz dGluYXRpb24gYXNcCiAgICAgIGEgcmVzdWx0IG9mIHRydXN0IHJlbGF0aW9uc2hpcHMsIG1heSBi ZSBlbmNyeXB0ZWQgZm9yIHRoZSBpbnRlbmRlZFwKICAgICAgcmVjaXBpZW50LiAgVGhpcyBtYXkg YmUgbmVjZXNzYXJ5IGlmIHRoZSBSSUQgbmV0d29yayBpcyBiZWluZyB1c2VkXAogICAgICBmb3Ig bWVzc2FnZSB0cmFuc2ZlciwgdGhlIGludGVybWVkaWF0ZSBwYXJ0aWVzIGRvIG5vdCBuZWVkIHRv IGhhdmVcCiAgICAgIGtub3dsZWRnZSBvZiB0aGUgcmVxdWVzdCBjb250ZW50cywgYW5kIGEgZGly ZWN0IGNvbW11bmljYXRpb24gcGF0aFwKICAgICAgZG9lcyBub3QgZXhpc3QuICBJbiB0aGF0IGNh c2UsIHRoZSBSSURQb2xpY3kgY2xhc3MgaXMgdXNlZCBieVwKICAgICAgaW50ZXJtZWRpYXRlIHBh cnRpZXMgYW5kIGlzIG1haW50YWluZWQgaW4gY2xlYXIgdGV4dC5cClwKICAgbyAgVGhlIGFjdGlv biB0YWtlbiBpbiB0aGUgUmVzdWx0IG1lc3NhZ2UgbWF5IGJlIGVuY3J5cHRlZCB1c2luZyB0aGVc CiAgICAgIGtleSBvZiB0aGUgcmVxdWVzdCBvcmlnaW5hdG9yLiAgSW4gdGhhdCBjYXNlLCB0aGUg aW50ZXJtZWRpYXRlXAogICAgICBwYXJ0aWVzIGNhbiB2aWV3IHRoZSBSSURQb2xpY3kgaW5mb3Jt YXRpb24gYW5kIGtub3cgdGhlIHRyYWNlIGhhc1wKICAgICAgYmVlbiBjb21wbGV0ZWQgYW5kIGRv IG5vdCBuZWVkIHRvIHNlZSB0aGUgYWN0aW9uLiAgSWYgdGhlIHVzZSBvZlwKICAgICAgZW5jcnlw dGlvbiB3ZXJlIGxpbWl0ZWQgdG8gc2VjdGlvbnMgb2YgdGhlIG1lc3NhZ2UsIHRoZSBIaXN0b3J5 XAogICAgICBjbGFzcyBpbmZvcm1hdGlvbiB3b3VsZCBiZSBlbmNyeXB0ZWQuICBPdGhlcndpc2Us IGl0IGlzXAogICAgICBSRUNPTU1FTkRFRCB0byBlbmNyeXB0IHRoZSBlbnRpcmUgSU9ERUYvUklE IGRvY3VtZW50LCB1c2luZyBhblwKICAgICAgZW52ZWxvcGVkIHNpZ25hdHVyZSwgZm9yIHRoZSBv cmlnaW5hdG9yIG9mIHRoZSByZXF1ZXN0LiAgVGhlXAogICAgICBleGlzdGVuY2Ugb2YgdGhlIFJl c3VsdCBtZXNzYWdlIGZvciBhbiBpbmNpZGVudCB3b3VsZCB0ZWxsIGFueVwKICAgICAgaW50ZXJt ZWRpYXRlIHBhcnRpZXMgdXNlZCBpbiB0aGUgcGF0aCBvZiB0aGUgaW5jaWRlbnRcCiAgICAgIGlu dmVzdGlnYXRpb24gdGhhdCB0aGUgaW5jaWRlbnQgaGFuZGxpbmcgaGFzIGJlZW4gY29tcGxldGVk LlwKXAogICBvICBUaGUgaW9kZWY6cmVzdHJpY3Rpb24gYXR0cmlidXRlIHNldHMgZXhwZWN0YXRp b25zIGZvciB0aGUgcHJpdmFjeVwKICAgICAgb2YgYW4gaW5jaWRlbnQgYW5kIGlzIGRlZmluZWQg aW4gc2VjdGlvbiAzLjIgb2YgUkZDNTA3MC4gIFRoZVwKICAgICAgcmVzdHJpY3Rpb24gYXR0cmli dXRlIGNhbiBiZSBzZXQgaW4gYW55IG9mIHRoZSBSSUQgY2xhc3NlcyB0b1wKICAgICAgZGVmaW5l IHJlc3RyaWN0aW9ucyBmb3IgdGhlIGNvbXBsZXRlIGV4Y2hhbmdlIG9mIGFuIElPREVGIGRvY3Vt ZW50XAogICAgICAoaW5jbHVkaW5nIGFueSBleHRlbnNpb25zKSBvciB3aXRoaW4gc3BlY2lmaWMg Y2xhc3NlcyBvZiBJT0RFRiBvclwKICAgICAgSU9ERUYgZXh0ZW5zaW9ucyB3aGVyZSBtb3JlIGxp bWl0ZWQgcmVzdHJpY3Rpb25zIGFyZSBkZXNpcmVkLiAgVGhlXAogICAgICByZXN0cmljdGlvbiBh dHRyaWJ1dGUgaXMgY29udGFpbmVkIGluIGVhY2ggb2YgdGhlIFJJRCBjbGFzc2VzIGFuZFwKICAg ICAgTVVTVCBiZSB1c2VkIGluIGFjY29yZGFuY2Ugd2l0aCBwcml2YWN5IGV4cGVjdGF0aW9ucyBm b3IgZWl0aGVyXAogICAgICBzZWN0aW9ucyBvZiB0aGUgSU9ERUYgZG9jdW1lbnQgb3IgdGhlIGNv bXBsZXRlIElPREVGIGRvY3VtZW50LlwKICAgICAgQ29uc29ydGl1bXMgYW5kIG9yZ2FuaXphdGlv bnMgc2hvdWxkIGNvbnNpZGVyIHRoaXMgZ3VpZGFuY2Ugd2hlblwKICAgICAgY3JlYXRpbmcgZXhj aGFuZ2UgcG9saWNpZXMuXApcCiAgIG8gIEV4cGVjdGF0aW9ucyBiYXNlZCBvbiByZXN0cmljdGlv biBzZXR0aW5nOlwKXAogICAgICAqICBJZiByZXN0cmljdGlvbiBpcyBzZXQgdG8gInByaXZhdGUi LCB0aGUgY2xhc3Mgb3IgZG9jdW1lbnQgTVVTVFwKICAgICAgICAgYmUgZW5jcnlwdGVkIGZvciB0 aGUgcmVjaXBpZW50IHVzaW5nIFhNTCBlbmNyeXB0aW9uIGFuZCB0aGVcCiAgICAgICAgIHB1Ymxp YyBrZXkgb2YgdGhlIHJlY2lwaWVudC4gIFRoZSB1c2Ugb2YgUEtJIGJldHdlZW4gZW50aXRpZXNc CiAgICAgICAgIFNIT1VMRCBhZGhlcmUgdG8gYW55IGFwcGxpY2FibGUgY2VydGlmaWNhdGUgcG9s aWN5IGFuZFwKICAgICAgICAgcHJhY3RpY2VzIGFncmVlbWVudHMgZm9yIHRoZSB1c2Ugb2YgUklE LlwKXAogICAgICAqICBJZiByZXN0cmljdGlvbiBpcyBzZXQgdG8gIm5lZWQtdG8ta25vdyIsIHRo ZSBjbGFzcyBvciBkb2N1bWVudFwKICAgICAgICAgTVVTVCBiZSBlbmNyeXB0ZWQgdG8gZW5zdXJl IG9ubHkgdGhvc2Ugd2l0aCBuZWVkLXRvLWtub3cgYWNjZXNzXAogICAgICAgICBjYW4gZGVjcnlw dCB0aGUgZGF0YS4gIFRoZSBkb2N1bWVudCBjYW4gZWl0aGVyIGJlIGVuY3J5cHRlZCBmb3JcCiAg ICAgICAgIGVhY2ggaW5kaXZpZHVhbCBmb3Igd2hpY2ggYWNjZXNzIGlzIGludGVuZGVkIG9yIGEg c2luZ2xlIGdyb3VwXApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1 YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1M11cClxwYWdlIFwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDExXApcClwKICAgICAgICAga2V5IG1heSBiZSB1c2VkLiAgVGhlIG1ldGhvZCB1c2VkIFNIT1VM RCBhZGhlcmUgdG8gYW55XAogICAgICAgICBjZXJ0aWZpY2F0ZSBwb2xpY3kgYW5kIHByYWN0aWNl cyBhZ3JlZW1lbnRzIGJldHdlZW4gZW50aXRpZXNcCiAgICAgICAgIGZvciB0aGUgdXNlIG9mIFJJ RC4gIEEgZ3JvdXAga2V5IGluIHRoaXMgaW5zdGFuY2UgcmVmZXJzIHRvIGFcCiAgICAgICAgIHNp bmdsZSBrZXkgKHN5bW1ldHJpYykgdGhhdCBpcyB1c2VkIHRvIGVuY3J5cHQgdGhlIGJsb2NrIG9m XAogICAgICAgICBkYXRhLiAgVGhlIHVzZXJzIHdpdGggbmVlZC10by1rbm93IGFjY2VzcyBwcml2 aWxlZ2VzIG1heSBiZVwKICAgICAgICAgZ2l2ZW4gYWNjZXNzIHRvIHRoZSBzaGFyZWQga2V5IHZp YSBhIHNlY3VyZSBkaXN0cmlidXRpb25cCiAgICAgICAgIG1ldGhvZCwgZm9yIGV4YW1wbGUsIHBy b3ZpZGluZyBhY2Nlc3MgdG8gdGhlIHN5bW1ldHJpYyBrZXlcCiAgICAgICAgIGVuY3J5cHRlZCB3 aXRoIGVhY2ggb2YgdXNlcnMgcHVibGljIGtleXMuXApcCiAgICAgICogIElmIHJlc3RyaWN0aW9u IGlzIHNldCB0byAicHVibGljIiwgdGhlIGNsYXNzIG9yIGRvY3VtZW50IE1VU1RcCiAgICAgICAg IGJlIHNlbnQgaW4gY2xlYXIgdGV4dC4gIFRoaXMgc2V0dGluZyBjYW4gYmUgY3JpdGljYWwgaWYg Y2VydGFpblwKICAgICAgICAgc2VjdGlvbnMgb2YgYSBkb2N1bWVudCBvciBhbiBlbnRpcmUgZG9j dW1lbnQgYXJlIHRvIGJlIHNoYXJlZFwKICAgICAgICAgd2l0aG91dCByZXN0cmljdGlvbnMuICBU aGlzIHByb3ZpZGVzIGZsZXhpYmlsaXR5IHdpdGhpbiBhblwKICAgICAgICAgaW5jaWRlbnQgdG8g c2hhcmUgb3V0IGNlcnRhaW4gaW5mb3JtYXRpb24gZnJlZWx5IHdoZXJlXAogICAgICAgICBhcHBy b3ByaWF0ZS5cClwKICAgICAgKiAgSWYgcmVzdHJpY3Rpb24gaXMgc2V0IHRvICJkZWZhdWx0Iiwg VGhlIGluZm9ybWF0aW9uIGNhbiBiZVwKICAgICAgICAgc2hhcmVkIGFjY29yZGluZyB0byBhbiBp bmZvcm1hdGlvbiBkaXNjbG9zdXJlIHBvbGljeSBwcmUtXAogICAgICAgICBhcnJhbmdlZCBieSB0 aGUgY29tbXVuaWNhdGluZyBwYXJ0aWVzLlwKXAogICBvICBFeHBlY3RhdGlvbnMgYmFzZWQgb24g cGxhY2VtZW50IG9mIHRoZSByZXN0cmljdGlvbiBzZXR0aW5nOlwKXAogICAgICAqICBJZiByZXN0 cmljdGlvbiBpcyBzZXQgd2l0aGluIG9uZSBvZiB0aGUgUklEIGNsYXNzZXMsIHRoZVwKICAgICAg ICAgcmVzdHJpY3Rpb24gYXBwbGllcyB0byB0aGUgZW50aXJlIElPREVGIGRvY3VtZW50LlwKXAog ICAgICAqICBJZiByZXN0cmljdGlvbiBpcyBzZXQgd2l0aGluIGluZGl2aWR1YWwgSU9ERUYgY2xh c3NlcywgdGhlXAogICAgICAgICByZXN0cmljdGlvbiBhcHBsaWVzIHRvIHRoZSBzcGVjaWZpYyBJ T0RFRiBjbGFzcyBhbmQgdGhlXAogICAgICAgICBjaGlsZHJlbiBvZiB0aGF0IGNsYXNzLlwKXAog ICBUaGUgZm9ybWF0aW9uIG9mIHBvbGljaWVzIGlzIGEgdmVyeSBpbXBvcnRhbnQgYXNwZWN0IG9m IHVzaW5nIGFcCiAgIG1lc3NhZ2luZyBzeXN0ZW0gbGlrZSBSSUQgdG8gZXhjaGFuZ2UgcG90ZW50 aWFsbHkgc2Vuc2l0aXZlXAogICBpbmZvcm1hdGlvbi4gIE1hbnkgY29uc2lkZXJhdGlvbnMgc2hv dWxkIGJlIGludm9sdmVkIGZvciBwZWVyaW5nXAogICBwYXJ0aWVzLCBhbmQgc29tZSBndWlkZWxp bmVzIHRvIHByb3RlY3QgdGhlIGRhdGEsIHN5c3RlbXMsIGFuZFwKICAgdHJhbnNwb3J0IGFyZSBj b3ZlcmVkIGluIHRoaXMgc2VjdGlvbi4gIFBvbGljaWVzIGVzdGFibGlzaGVkIHNob3VsZFwKICAg cHJvdmlkZSBndWlkZWxpbmVzIGZvciBjb21tdW5pY2F0aW9uIG1ldGhvZHMsIHNlY3VyaXR5LCBh bmQgZmFsbC1iYWNrXAogICBwcm9jZWR1cmVzLiAgU2VlIHNlY3Rpb25zIDcuNSBhbmQgNy42IGZv ciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIG9uXAogICBjb25zb3J0aXVtcyBhbmQgUEtJIGNvbnNp ZGVyYXRpb25zLlwKXAogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBzdG9y YWdlIGFuZCBleGNoYW5nZSBvZlwKICAgaW5mb3JtYXRpb24gaW4gUklEIG1lc3NhZ2luZyBtYXkg aW5jbHVkZSBhZGhlcmVuY2UgdG8gbG9jYWwsXAogICByZWdpb25hbCwgb3IgbmF0aW9uYWwgcmVn dWxhdGlvbnMgaW4gYWRkaXRpb24gdG8gdGhlIG9ibGlnYXRpb25zIHRvXAogICBwcm90ZWN0IGNs aWVudCBpbmZvcm1hdGlvbiBkdXJpbmcgYW4gaW52ZXN0aWdhdGlvbi4gIFJJRCBQb2xpY3kgaXMg YVwKICAgbmVjZXNzYXJ5IHRvb2wgZm9yIGxpc3RpbmcgdGhlIHJlcXVpcmVtZW50cyBvZiBtZXNz YWdlcyB0byBwcm92aWRlIGFcCiAgIG1ldGhvZCB0byBjYXRlZ29yaXplIGRhdGEgZWxlbWVudHMg Zm9yIHByb3BlciBoYW5kbGluZy4gIENvbnRyb2xzIGFyZVwKICAgYWxzbyBwcm92aWRlZCBmb3Ig dGhlIHNlbmRpbmcgZW50aXR5IHRvIHByb3RlY3QgbWVzc2FnZXMgZnJvbSB0aGlyZFwKICAgcGFy dGllcyB0aHJvdWdoIFhNTCBlbmNyeXB0aW9uLlwKXAogICBSSUQgcHJvdmlkZXMgYSBtZXRob2Qg dG8gZXhjaGFuZ2UgaW5jaWRlbnQgaGFuZGxpbmcgcmVxdWVzdCBhbmRcClwKXApcCk1vcmlhcnR5 ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQ YWdlIDU0XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1i aXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBSZXBvcnQgbWVzc2FnZXMg dG8gcGVlciBuZXR3b3Jrcy4gIEFkbWluaXN0cmF0b3JzIGhhdmUgdGhlIGFiaWxpdHkgdG9cCiAg IGJhc2UgZGVjaXNpb25zIG9uIHRoZSBhdmFpbGFibGUgcmVzb3VyY2VzIGFuZCBvdGhlciBmYWN0 b3JzIG9mIHRoZWlyXAogICBuZXR3b3JrIGFuZCBtYWludGFpbiBjb250cm9sIG9mIGluY2lkZW50 IGludmVzdGlnYXRpb25zIHdpdGhpbiB0aGVpclwKICAgb3duIG5ldHdvcmsuICBUaHVzLCBSSUQg cHJvdmlkZXMgdGhlIGFiaWxpdHkgZm9yIHBhcnRpY2lwYXRpbmdcCiAgIG5ldHdvcmtzIHRvIG1h bmFnZSB0aGVpciBvd24gc2VjdXJpdHkgY29udHJvbHMsIGxldmVyYWdpbmcgdGhlXAogICBpbmZv cm1hdGlvbiBsaXN0ZWQgaW4gUklEUG9saWN5LlwKXAo3LjEuICBNZXNzYWdlIFRyYW5zcG9ydFwK XAogICBUaGUgdHJhbnNwb3J0IHNwZWNpZmljYXRpb25zIGFyZSBmdWxseSBkZWZpbmVkIGluIGEg c2VwYXJhdGUgZG9jdW1lbnRcCiAgIFtSRkM2MDQ2XS4gIFRoZSBzcGVjaWZpZWQgdHJhbnNwb3J0 IHByb3RvY29scyBNVVNUIHVzZSBlbmNyeXB0aW9uIHRvXAogICBwcm92aWRlIGFuIGFkZGl0aW9u YWwgbGV2ZWwgb2Ygc2VjdXJpdHkgYW5kIGludGVncml0eSwgd2hpbGVcCiAgIHN1cHBvcnRpbmcg bXV0dWFsIGF1dGhlbnRpY2F0aW9uIHRocm91Z2ggYmktZGlyZWN0aW9uYWwgY2VydGlmaWNhdGVc CiAgIHVzYWdlLiAgQW55IHN1YnNlcXVlbnQgdHJhbnNwb3J0IG1ldGhvZCBkZWZpbmVkIHNob3Vs ZCB0YWtlIGFkdmFudGFnZVwKICAgb2YgZXhpc3Rpbmcgc3RhbmRhcmRzIGZvciBlYXNlIG9mIGlt cGxlbWVudGF0aW9uIGFuZCBpbnRlZ3JhdGlvbiBvZlwKICAgUklEIHN5c3RlbXMuICBTZXNzaW9u IGVuY3J5cHRpb24gZm9yIHRoZSB0cmFuc3BvcnQgb2YgUklEIG1lc3NhZ2VzIGlzXAogICBlbmZv cmNlZCBpbiB0aGUgdHJhbnNwb3J0IHNwZWNpZmljYXRpb24uICBUaGUgcHJpdmFjeSBhbmQgc2Vj dXJpdHlcCiAgIGNvbnNpZGVyYXRpb25zIGFyZSBhZGRyZXNzZWQgZnVsbHkgaW4gUklEIHRvIHBy b3RlY3Qgc2Vuc2l0aXZlXAogICBwb3J0aW9ucyBvZiBkb2N1bWVudHMgYW5kIHByb3ZpZGUgYSBt ZXRob2QgdG8gYXV0aGVudGljYXRlIHRoZVwKICAgbWVzc2FnZXMuICBUaGVyZWZvcmUsIFJJRCBt ZXNzYWdlcyBkbyBub3QgcmVseSBvbiB0aGUgc2VjdXJpdHlcCiAgIHByb3ZpZGVkIGJ5IHRoZSB0 cmFuc3BvcnQgbGF5ZXIgYWxvbmUuICBUaGUgZW5jcnlwdGlvbiByZXF1aXJlbWVudHNcCiAgIGFu ZCBjb25zaWRlcmF0aW9ucyBmb3IgUklEIGFyZSBkaXNjdXNzZWQgYXQgdGhlIGJlZ2lubmluZyBv ZiBTZWN0aW9uXAogICA2IG9mIHRoaXMgZG9jdW1lbnQuXApcCiAgIFhNTCBzZWN1cml0eSBmdW5j dGlvbnMgc3VjaCBhcyB0aGUgZGlnaXRhbCBzaWduYXR1cmUgW1JGQzMyNzVdIGFuZFwKICAgZW5j cnlwdGlvbiBbWE1MZW5jcnlwdF0gcHJvdmlkZSBhIHN0YW5kYXJkcy1iYXNlZCBtZXRob2QgdG8g ZW5jcnlwdFwKICAgYW5kIGRpZ2l0YWxseSBzaWduIFJJRCBtZXNzYWdlcy4gIFJJRCBtZXNzYWdl cyBzcGVjaWZ5IHN5c3RlbSB1c2UgYW5kXAogICBwcml2YWN5IGd1aWRlbGluZXMgdGhyb3VnaCB0 aGUgUklEUG9saWN5IGNsYXNzLiAgQSBwdWJsaWMga2V5XAogICBpbmZyYXN0cnVjdHVyZSAoUEtJ KSBwcm92aWRlcyB0aGUgYmFzZSBmb3IgYXV0aGVudGljYXRpb24gYW5kXAogICBhdXRob3JpemF0 aW9uLCBlbmNyeXB0aW9uLCBhbmQgZGlnaXRhbCBzaWduYXR1cmVzIHRvIGVzdGFibGlzaCB0cnVz dFwKICAgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIG1lbWJlcnMgb2YgYSBSSUQgY29uc29ydGl1bSBv ciBhIHBlZXJpbmdcCiAgIGNvbnNvcnRpdW0uXApcCiAgIFhNTCBzZWN1cml0eSBmdW5jdGlvbnMg c3VjaCBhcyB0aGUgZGlnaXRhbCBzaWduYXR1cmUgW1JGQzMyNzVdIGFuZFwKICAgZW5jcnlwdGlv biBbWE1MZW5jcnlwdF0gY2FuIGJlIHVzZWQgd2l0aGluIHRoZSBjb250ZW50cyBvZiB0aGVcCiAg IG1lc3NhZ2UgZm9yIHByaXZhY3kgYW5kIHNlY3VyaXR5IGluIGNhc2VzIGZvciB3aGljaCBjZXJ0 YWluIGVsZW1lbnRzXAogICBtdXN0IHJlbWFpbiBlbmNyeXB0ZWQgb3Igc2lnbmVkIGFzIHRoZXkg dHJhdmVyc2UgdGhlIHBhdGggb2YgYSB0cmFjZS5cCiAgIEZvciBleGFtcGxlLCB0aGUgZGlnaXRh bCBzaWduYXR1cmUgb24gYSBUcmFjZVJlcXVlc3QgY2FuIGJlIHVzZWQgdG9cCiAgIHZlcmlmeSB0 aGUgaWRlbnRpdHkgb2YgdGhlIHRyYWNlIG9yaWdpbmF0b3IuICBUaGUgdXNlIG9mIHRoZSBYTUxc CiAgIHNlY3VyaXR5IGZlYXR1cmVzIGluIFJJRCBtZXNzYWdpbmcgaXMgaW4gYWNjb3JkYW5jZSB3 aXRoIHRoZVwKICAgc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBJT0RFRiBtb2RlbDsgaG93ZXZlciwg dGhlIHVzZSByZXF1aXJlbWVudHMgbWF5XAogICBkaWZmZXIgc2luY2UgUklEIGFsc28gaW5jb3Jw b3JhdGVzIGNvbW11bmljYXRpb24gb2Ygc2VjdXJpdHkgaW5jaWRlbnRcCiAgIGluZm9ybWF0aW9u LlwKXAo3LjIuICBNZXNzYWdlIERlbGl2ZXJ5IFByb3RvY29sIC0gSW50ZWdyaXR5IGFuZCBBdXRo ZW50aWNhdGlvblwKXAogICBUaGUgUklEIHByb3RvY29sIG11c3QgYmUgYWJsZSB0byBndWFyYW50 ZWUgZGVsaXZlcnkgYW5kIG1lZXQgdGhlXAogICBuZWNlc3Nhcnkgc2VjdXJpdHkgcmVxdWlyZW1l bnRzIG9mIGEgc3RhdGUtb2YtdGhlLWFydCBwcm90b2NvbC4gIEluXApcClwKXApNb3JpYXJ0eSAg ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBbUGFn ZSA1NV1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUtYmlz ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgb3JkZXIgdG8gZ3VhcmFudGVl IGRlbGl2ZXJ5LCBUQ1Agc2hvdWxkIGJlIGNvbnNpZGVyZWQgYXMgdGhlXAogICB1bmRlcmx5aW5n IHByb3RvY29sIHdpdGhpbiB0aGUgY3VycmVudCBuZXR3b3JrIHN0YW5kYXJkIHByYWN0aWNlcy5c ClwKICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgbXVzdCBpbmNsdWRlIHRoZSBpbnRlZ3JpdHks IGF1dGhlbnRpY2F0aW9uLFwKICAgcHJpdmFjeSwgYW5kIGF1dGhvcml6YXRpb24gb2YgdGhlIG1l c3NhZ2VzIHNlbnQgYmV0d2VlbiBzeXN0ZW1zXAogICBjb21tdW5pY2F0aW5nIHZpYSBSSUQuICBU aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFJJRCBzeXN0ZW1zIG11c3QgYmVcCiAgIGF1dGhlbnRp Y2F0ZWQgYW5kIGVuY3J5cHRlZCB0byBlbnN1cmUgdGhlIGludGVncml0eSBvZiB0aGUgbWVzc2Fn ZXNcCiAgIGFuZCB0aGUgUklEIHN5c3RlbXMgaW52b2x2ZWQgaW4gdGhlIHRyYWNlLiAgQW5vdGhl ciBjb25jZXJuIHRoYXRcCiAgIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpcyBhdXRoZW50aWNhdGlv biBmb3IgYSByZXF1ZXN0IHRoYXQgdHJhdmVyc2VzXAogICBtdWx0aXBsZSBuZXR3b3Jrcy4gIElu IHRoaXMgc2NlbmFyaW8sIHN5c3RlbXMgaW4gdGhlIHBhdGggb2YgdGhlXAogICBtdWx0aS1ob3Ag VHJhY2VSZXF1ZXN0IG5lZWQgdG8gYXV0aG9yaXplIGEgdHJhY2UgZnJvbSBub3Qgb25seSB0aGVp clwKICAgbmVpZ2hib3IgbmV0d29yaywgYnV0IGFsc28gZnJvbSB0aGUgaW5pdGlhdGluZyBSSUQg c3lzdGVtIGFzXAogICBkaXNjdXNzZWQgaW4gU2VjdGlvbiA2LjQuICBTZXZlcmFsIG1ldGhvZHMg Y2FuIGJlIHVzZWQgdG8gZW5zdXJlXAogICBpbnRlZ3JpdHkgYW5kIHByaXZhY3kgb2YgdGhlIGNv bW11bmljYXRpb24uXApcCiAgIFRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtIHNlbGVjdGVkIE1VU1Qg Zm9sbG93IHRoZSBkZWZpbmVkIHRyYW5zcG9ydFwKICAgcHJvdG9jb2wgW1JGQzYwNDZdIHdoZW4g dXNpbmcgUklEIG1lc3NhZ2luZyB0byBlbnN1cmUgY29uc2lzdGVuY3lcCiAgIGFtb25nIHRoZSBw ZWVycy4gIENvbnNvcnRpdW1zIG1heSB2YXJ5IHRoZWlyIHNlbGVjdGVkIHRyYW5zcG9ydFwKICAg bWVjaGFuaXNtcyBhbmQgdGh1cyBtdXN0IGRlY2lkZSB1cG9uIGEgbXV0dWFsIHByb3RvY29sIHRv IHVzZSBmb3JcCiAgIHRyYW5zcG9ydCB3aGVuIGNvbW11bmljYXRpbmcgd2l0aCBwZWVycyBpbiBh IG5laWdoYm9yaW5nIGNvbnNvcnRpdW1cCiAgIHVzaW5nIFJJRC4gIFJJRCBzeXN0ZW1zIE1VU1Qg aW1wbGVtZW50IGFuZCBkZXBsb3kgSFRUUFMgYXMgZGVmaW5lZCBpblwKICAgdGhlIHRyYW5zcG9y dCBkb2N1bWVudCBbUkZDNjA0Nl0gYW5kIG9wdGlvbmFsbHkgc3VwcG9ydCBvdGhlclwKICAgcHJv dG9jb2xzIHN1Y2ggYXMgdGhlIEJsb2NrcyBFeHRlbnNpYmxlIEV4Y2hhbmdlIFByb3RvY29sIChC RUVQKS5cCiAgIFJJRCwgdGhlIFhNTCBzZWN1cml0eSBmdW5jdGlvbnMsIGFuZCB0cmFuc3BvcnQg cHJvdG9jb2xzIG11c3RcCiAgIHByb3Blcmx5IGludGVncmF0ZSB3aXRoIGEgcHVibGljIGtleSBp bmZyYXN0cnVjdHVyZSAoUEtJKSBtYW5hZ2VkIGJ5XAogICB0aGUgY29uc29ydGl1bSBvciBvbmUg bWFuYWdlZCBieSBhIHRydXN0ZWQgZW50aXR5LiAgRm9yIHRoZSBJbnRlcm5ldCxcCiAgIGEgZmV3 IG9mIGV4YW1wbGVzIG9mIGV4aXN0aW5nIGVmZm9ydHMgdGhhdCBjb3VsZCBiZSBsZXZlcmFnZWQg dG9cCiAgIHByb3ZpZGUgdGhlIHN1cHBvcnRpbmcgUEtJIGluY2x1ZGUgdGhlIEFtZXJpY2FuIFJl Z2lzdHJ5IGZvciBJbnRlcm5ldFwKICAgTnVtYmVycyAoQVJJTikgYW5kIHRoZSBSZWdpb25hbCBJ bnRlcm5ldCBSZWdpc3RyeSdzIChSSVIncykgUEtJXAogICBoaWVyYXJjaHksIHZlbmRvciBpc3N1 ZWQgY2VydGlmaWNhdGVzLCBvciBhcHByb3ZlZCBpc3N1ZXJzIG9mXAogICBFeHRlbmRlZCBWYWxp ZGF0aW9uIChFVikgQ2VydGlmaWNhdGVzLiAgU2VjdXJpdHkgYW5kIHByaXZhY3lcCiAgIGNvbnNp ZGVyYXRpb25zIHJlbGF0ZWQgdG8gY29uc29ydGl1bXMgYXJlIGRpc2N1c3NlZCBpbiBTZWN0aW9u cyA2LjVcCiAgIGFuZCA2LjYuXApcCjcuMy4gIFRyYW5zcG9ydCBDb21tdW5pY2F0aW9uXApcCiAg IE91dC1vZi1iYW5kIGNvbW11bmljYXRpb25zIGRlZGljYXRlZCB0byBTUCBpbnRlcmFjdGlvbiBm b3IgUklEXAogICBtZXNzYWdpbmcgd291bGQgcHJvdmlkZSBhZGRpdGlvbmFsIHNlY3VyaXR5IGFz IHdlbGwgYXMgZ3VhcmFudGVlZFwKICAgYmFuZHdpZHRoIGR1cmluZyBhIGRlbmlhbC1vZi1zZXJ2 aWNlIGF0dGFjay4gIEZvciBleGFtcGxlLCBhbiBvdXQtb2YtXAogICBiYW5kIGNoYW5uZWwgbWF5 IGNvbnNpc3Qgb2YgbG9naWNhbCBwYXRocyBkZWZpbmVkIG92ZXIgdGhlIGV4aXN0aW5nXAogICBu ZXR3b3JrLiAgT3V0LW9mLWJhbmQgY29tbXVuaWNhdGlvbnMgbWF5IG5vdCBiZSBwb3NzaWJsZSBi ZXR3ZWVuIGFsbFwKICAgbmV0d29yayBwcm92aWRlcnMsIGJ1dCBzaG91bGQgYmUgY29uc2lkZXJl ZCB0byBwcm90ZWN0IHRoZSBuZXR3b3JrXAogICBtYW5hZ2VtZW50IHN5c3RlbXMgdXNlZCBmb3Ig UklEIG1lc3NhZ2luZy4gIE1ldGhvZHMgdG8gcHJvdGVjdCB0aGVcCiAgIGRhdGEgdHJhbnNwb3J0 IG1heSBhbHNvIGJlIHByb3ZpZGVkIHRocm91Z2ggc2Vzc2lvbiBlbmNyeXB0aW9uLlwKXAogICBJ biBvcmRlciB0byBhZGRyZXNzIHRoZSBpbnRlZ3JpdHkgYW5kIGF1dGhlbnRpY2l0eSBvZiBtZXNz YWdlcyxcCiAgIHRyYW5zcG9ydCBlbmNyeXB0aW9uIE1VU1QgYmUgdXNlZCB0byBzZWN1cmUgdGhl IHRyYWZmaWMgc2VudCBiZXR3ZWVuXAogICBSSUQgc3lzdGVtcy4gIFN5c3RlbXMgd2l0aCBwcmVk ZWZpbmVkIHJlbGF0aW9uc2hpcHMgZm9yIFJJRCB3b3VsZFwKXApcClwKTW9yaWFydHkgICAgICAg ICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTZd XApccGFnZSBcCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAg ICAgICAgICAgICAgICBBdWd1c3QgMjAxMVwKXApcCiAgIGluY2x1ZGUgdGhvc2Ugd2hvIHBlZXIg d2l0aGluIGEgY29uc29ydGl1bSB3aXRoIGFncmVlZC11cG9uXAogICBhcHByb3ByaWF0ZSB1c2Ug cmVndWxhdGlvbnMgYW5kIGZvciBwZWVyaW5nIGNvbnNvcnRpdW1zLiAgVHJ1c3RcCiAgIHJlbGF0 aW9uc2hpcHMgbWF5IGFsc28gYmUgZGVmaW5lZCB0aHJvdWdoIGEgYnJpZGdlZCBvciBoaWVyYXJj aGljYWxcCiAgIFBLSSBpbiB3aGljaCBib3RoIHBlZXJzIGJlbG9uZy5cClwKICAgU3lzdGVtcyB1 c2VkIHRvIHNlbmQgYXV0aGVudGljYXRlZCBSSUQgbWVzc2FnZXMgYmV0d2VlbiBuZXR3b3JrcyBN VVNUXAogICB1c2UgYSBzZWN1cmVkIHN5c3RlbSBhbmQgaW50ZXJmYWNlIHRvIGNvbm5lY3QgdG8g YSBib3JkZXIgbmV0d29yaydzXAogICBSSUQgc3lzdGVtcy4gIEVhY2ggY29ubmVjdGlvbiB0byBh IFJJRCBzeXN0ZW0gTVVTVCBtZWV0IHRoZSBzZWN1cml0eVwKICAgcmVxdWlyZW1lbnRzIGFncmVl ZCB1cG9uIHRocm91Z2ggdGhlIGNvbnNvcnRpdW0gcmVndWxhdGlvbnMsIHBlZXJpbmcsXAogICBv ciBTTEFzLiAgVGhlIFJJRCBzeXN0ZW0gTVVTVCBvbmx5IGxpc3RlbiBmb3IgYW5kIHNlbmQgUklE IG1lc3NhZ2VzXAogICBvbiB0aGUgZGVzaWduYXRlZCBwb3J0LCB3aGljaCBhbHNvIE1VU1QgYmUg b3ZlciBhbiBlbmNyeXB0ZWQgdHVubmVsXAogICBtZWV0aW5nIHRoZSBtaW5pbXVtIHJlcXVpcmVt ZW50IG9mIGFsZ29yaXRobXMgYW5kIGtleSBsZW5ndGhzXAogICBlc3RhYmxpc2hlZCBieSB0aGUg Y29uc29ydGl1bSwgcGVlcmluZywgb3IgU0xBLiAgVGhlIHNlbGVjdGVkXAogICBjcnlwdG9ncmFw aGljIGFsZ29yaXRobXMgZm9yIHN5bW1ldHJpYyBlbmNyeXB0aW9uLCBkaWdpdGFsXAogICBzaWdu YXR1cmVzLCBhbmQgaGFzaCBmdW5jdGlvbnMgTVVTVCBtZWV0IG1pbmltdW0gc2VjdXJpdHkgbGV2 ZWxzIG9mXAogICB0aGUgdGltZXMuICBUaGUgZW5jcnlwdGlvbiBzdHJlbmd0aCBNVVNUIGFkaGVy ZSB0byBpbXBvcnQgYW5kIGV4cG9ydFwKICAgcmVndWxhdGlvbnMgb2YgdGhlIGludm9sdmVkIGNv dW50cmllcyBmb3IgZGF0YSBleGNoYW5nZS5cClwKNy40LiAgQXV0aGVudGljYXRpb24gb2YgUklE IFByb3RvY29sXApcCiAgIEluIG9yZGVyIHRvIGVuc3VyZSB0aGUgYXV0aGVudGljaXR5IG9mIHRo ZSBSSUQgbWVzc2FnZXMsIGEgbWVzc2FnZVwKICAgYXV0aGVudGljYXRpb24gc2NoZW1lIGlzIHVz ZWQgdG8gc2VjdXJlIHRoZSBwcm90b2NvbC4gIFhNTCBzZWN1cml0eVwKICAgZnVuY3Rpb25zIHV0 aWxpemVkIGluIFJJRCByZXF1aXJlIGEgdHJ1c3QgY2VudGVyIHN1Y2ggYXMgYSBQS0kgZm9yXAog ICB0aGUgZGlzdHJpYnV0aW9uIG9mIGNyZWRlbnRpYWxzIHRvIHByb3ZpZGUgdGhlIG5lY2Vzc2Fy eSBsZXZlbCBvZlwKICAgc2VjdXJpdHkgZm9yIHRoaXMgcHJvdG9jb2wuICBMYXllcmVkIHRyYW5z cG9ydCBwcm90b2NvbHMgYWxzbyB1dGlsaXplXAogICBlbmNyeXB0aW9uIGFuZCByZWx5IG9uIGEg dHJ1c3QgY2VudGVyLiAgUHVibGljIGtleSBjZXJ0aWZpY2F0ZSBwYWlyc1wKICAgaXNzdWVkIGJ5 IGEgdHJ1c3RlZCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAoQ0EpIE1BWSBiZSB1c2VkIHRvXAog ICBwcm92aWRlIHRoZSBuZWNlc3NhcnkgbGV2ZWwgb2YgYXV0aGVudGljYXRpb24gYW5kIGVuY3J5 cHRpb24gZm9yIHRoZVwKICAgUklEIHByb3RvY29sLiAgVGhlIENBIHVzZWQgZm9yIFJJRCBtZXNz YWdpbmcgbXVzdCBiZSB0cnVzdGVkIGJ5IGFsbFwKICAgaW52b2x2ZWQgcGFydGllcyBhbmQgbWF5 IHRha2UgYWR2YW50YWdlIG9mIHNpbWlsYXIgZWZmb3J0cywgc3VjaCBhc1wKICAgdGhlIEludGVy bmV0MiBmZWRlcmF0ZWQgUEtJIG9yIHRoZSBBUklOL1JJUiBlZmZvcnQgdG8gcHJvdmlkZSBhIFBL SVwKICAgdG8gbmV0d29yayBwcm92aWRlcnMuICBUaGUgUEtJIHVzZWQgZm9yIGF1dGhlbnRpY2F0 aW9uIHdvdWxkIGFsc29cCiAgIHByb3ZpZGUgdGhlIG5lY2Vzc2FyeSBjZXJ0aWZpY2F0ZXMgbmVl ZGVkIGZvciBlbmNyeXB0aW9uIHVzZWQgZm9yIHRoZVwKICAgUklEIHRyYW5zcG9ydCBwcm90b2Nv bCBbUkZDNjA0Nl0uXApcCiAgIFRoZSB1c2Ugb2YgcHJlLXNoYXJlZCBrZXlzIG1heSBiZSBjb25z aWRlcmVkIGZvciBhdXRoZW50aWNhdGlvbi4gIElmXAogICB0aGlzIG9wdGlvbiBpcyBzZWxlY3Rl ZCwgdGhlIHNwZWNpZmljYXRpb25zIHNldCBmb3J0aCBpbiAiUHJlLVNoYXJlZFwKICAgS2V5IENp cGhlcnN1aXRlcyBmb3IgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIiBbUkZDNDI3OV0g TVVTVFwKICAgYmUgZm9sbG93ZWQuXApcCiAgIEhvc3RzIHJlY2VpdmluZyBhIFJJRCBtZXNzYWdl IE1VU1QgYmUgYWJsZSB0byB2ZXJpZnkgdGhhdCB0aGUgc2VuZGVyXAogICBvZiB0aGUgcmVxdWVz dCBpcyB2YWxpZCBhbmQgdHJ1c3RlZC4gIFVzaW5nIGRpZ2l0YWwgc2lnbmF0dXJlcyBvbiBhXAog ICBoYXNoIG9mIHRoZSBSSUQgbWVzc2FnZSB3aXRoIGFuIFguNTA5IHZlcnNpb24gMyBjZXJ0aWZp Y2F0ZSBpc3N1ZWQgYnlcCiAgIGEgdHJ1c3RlZCBwYXJ0eSBNVVNUIGJlIHVzZWQgdG8gYXV0aGVu dGljYXRlIHRoZSByZXF1ZXN0LiAgVGhlIFguNTA5XAogICB2ZXJzaW9uIDMgc3BlY2lmaWNhdGlv bnMgYXMgd2VsbCBhcyB0aGUgZGlnaXRhbCBzaWduYXR1cmVcCiAgIHNwZWNpZmljYXRpb25zIGFu ZCBwYXRoIHZhbGlkYXRpb24gc3RhbmRhcmRzIHNldCBmb3J0aCBpbiBbUkZDNTI4MF1cCiAgIE1V U1QgYmUgZm9sbG93ZWQgaW4gb3JkZXIgdG8gaW50ZXJvcGVyYXRlIHdpdGggYSBQS0kgZGVzaWdu ZWQgZm9yXAogICBzaW1pbGFyIHB1cnBvc2VzLiAgVGhlIElPREVGIHNwZWNpZmljYXRpb24gTVVT VCBiZSBmb2xsb3dlZCBmb3JcClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMg RmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDU3XVwKXHBhZ2UgXApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVn dXN0IDIwMTFcClwKXAogICBkaWdpdGFsIHNpZ25hdHVyZXMgdG8gcHJvdmlkZSB0aGUgYXV0aGVu dGljYXRpb24gYW5kIGludGVncml0eVwKICAgYXNwZWN0cyByZXF1aXJlZCBmb3Igc2VjdXJlIG1l c3NhZ2luZyBiZXR3ZWVuIG5ldHdvcmsgcHJvdmlkZXJzLiAgVGhlXAogICB1c2Ugb2YgZGlnaXRh bCBzaWduYXR1cmVzIGluIFJJRCBYTUwgbWVzc2FnZXMgTVVTVCBmb2xsb3cgdGhlIFdvcmxkXAog ICBXaWRlIFdlYiBDb25zb3J0aXVtIChXM0MpIHJlY29tbWVuZGF0aW9ucyBmb3Igc2lnbmF0dXJl IHN5bnRheCBhbmRcCiAgIHByb2Nlc3Npbmcgd2hlbiBlaXRoZXIgdGhlIFhNTCBlbmNyeXB0aW9u IFtYTUxlbmNyeXB0XSBvciBkaWdpdGFsXAogICBzaWduYXR1cmUgW1hNTHNpZ10sIFtSRkMzMjc1 XSBpcyB1c2VkIHdpdGhpbiBhIGRvY3VtZW50LiAgVHJhbnNwb3J0XAogICBzcGVjaWZpY2F0aW9u cyBhcmUgZGV0YWlsZWQgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBbUkZDNjA0Nl0uXApcCiAgIEl0 IG1pZ2h0IGJlIGhlbHBmdWwgdG8gZGVmaW5lIGFuIGV4dGVuc2lvbiB0byB0aGUgYXV0aGVudGlj YXRpb25cCiAgIHNjaGVtZSB0aGF0IHVzZXMgYXR0cmlidXRlIGNlcnRpZmljYXRlcyBbUkZDNTc1 NV0gaW4gc3VjaCBhIHdheSB0aGF0XAogICBhbiBhcHBsaWNhdGlvbiBjb3VsZCBhdXRvbWF0aWNh bGx5IGRldGVybWluZSB3aGV0aGVyIGh1bWFuXAogICBpbnRlcnZlbnRpb24gaXMgbmVlZGVkIHRv IGF1dGhvcml6ZSBhIHJlcXVlc3Q7IGhvd2V2ZXIsIHRoZVwKICAgc3BlY2lmaWNhdGlvbiBvZiBz dWNoIGFuIGV4dGVuc2lvbiBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuXApcCjcu NC4xLiAgTXVsdGktSG9wIFRyYWNlUmVxdWVzdCBBdXRoZW50aWNhdGlvblwKXAogICBCaWxhdGVy YWwgdHJ1c3QgcmVsYXRpb25zIGJldHdlZW4gbmV0d29yayBwcm92aWRlcnMgZW5zdXJlIHRoZVwK ICAgYXV0aGVudGljaXR5IG9mIHJlcXVlc3RzIGZvciBUcmFjZVJlcXVlc3RzIGZyb20gaW1tZWRp YXRlIHBlZXJzIGluXAogICB0aGUgd2ViIG9mIG5ldHdvcmtzIGZvcm1lZCB0byBwcm92aWRlIHRo ZSB0cmFjZWJhY2sgY2FwYWJpbGl0eS4gIEFcCiAgIG5ldHdvcmsgcHJvdmlkZXIgc2V2ZXJhbCBo b3BzIGludG8gdGhlIHBhdGggb2YgdGhlIFJJRCB0cmFjZSBtdXN0XAogICB0cnVzdCB0aGUgaW5m b3JtYXRpb24gZnJvbSBpdHMgb3duIHRydXN0IHJlbGF0aW9uc2hpcHMgYXMgd2VsbCBhcyB0aGVc CiAgIHByZXZpb3VzIHRydXN0IHJlbGF0aW9uc2hpcHMgaW4gdGhlIGRvd25zdHJlYW0gcGF0aC4g IFRoZSB1c2Ugb2ZcCiAgIG11bHRpLWhvcCBhdXRoZW50aWNhdGlvbiBpbiBhbiBJbnZlc3RpZ2F0 aW9uIHJlcXVlc3QgaXMgdXNlZCB3aGVuIGFuXAogICBJbnZlc3RpZ2F0aW9uIGlzIHNlbnQgdG8g bXVsdGlwbGUgZW50aXRpZXMgb3IgU1BzIGluIGFuIGl0ZXJhdGl2ZVwKICAgbWFubmVyLiAgRm9y IHByYWN0aWNhbCByZWFzb25zLCB0aGUgU1BzIG1heSB3YW50IHRvIHByaW9yaXRpemVcCiAgIGlu Y2lkZW50IGhhbmRsaW5nIGV2ZW50cyBiYXNlZCB1cG9uIHRoZSBpbW1lZGlhdGUgcGVlciBmb3Ig YVwKICAgVHJhY2VSZXF1ZXN0LCB0aGUgb3JpZ2luYXRvciBvZiBhIHJlcXVlc3QsIGFuZCB0aGUg bGlzdGVkIENvbmZpZGVuY2VcCiAgIHJhdGluZyBmb3IgdGhlIGluY2lkZW50LiAgSW4gb3JkZXIg dG8gcHJvdmlkZSBhIGhpZ2hlciBhc3N1cmFuY2VcCiAgIGxldmVsIG9mIHRoZSBhdXRoZW50aWNp dHkgb2YgdGhlIFRyYWNlUmVxdWVzdCwgdGhlIG9yaWdpbmF0aW5nIFJJRFwKICAgc3lzdGVtIGlz IGluY2x1ZGVkIGluIHRoZSBUcmFjZVJlcXVlc3QgYWxvbmcgd2l0aCBjb250YWN0IGluZm9ybWF0 aW9uXAogICBhbmQgdGhlIGluZm9ybWF0aW9uIG9mIGFsbCBSSUQgc3lzdGVtcyBpbiB0aGUgcGF0 aCB0aGUgdHJhY2UgaGFzXAogICB0YWtlbi4gIFRoaXMgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQg dGhyb3VnaCB0aGUgSU9ERUYgRXZlbnREYXRhXAogICBjbGFzcyBuZXN0aW5nIHRoZSBsaXN0IG9m IHN5c3RlbXMgYW5kIGNvbnRhY3RzIGludm9sdmVkIGluIGEgdHJhY2UsXAogICB3aGlsZSBzZXR0 aW5nIHRoZSBjYXRlZ29yeSBhdHRyaWJ1dGUgdG8gImluZnJhc3RydWN0dXJlIi5cClwKICAgQSBz ZWNvbmQgbWVhc3VyZSBNVVNUIGJlIHRha2VuIHRvIGVuc3VyZSB0aGUgaWRlbnRpdHkgb2YgdGhl XAogICBvcmlnaW5hdGluZyBSSUQgc3lzdGVtLiAgVGhlIG9yaWdpbmF0aW5nIFJJRCBzeXN0ZW0g TVVTVCBpbmNsdWRlIGFcCiAgIGRpZ2l0YWwgc2lnbmF0dXJlIGluIHRoZSBUcmFjZVJlcXVlc3Qg c2VudCB0byBhbGwgc3lzdGVtcyBpbiB0aGVcCiAgIHVwc3RyZWFtIHBhdGguICBUaGUgZGlnaXRh bCBzaWduYXR1cmUgZnJvbSB0aGUgUklEIHN5c3RlbSBpc1wKICAgcGVyZm9ybWVkIG9uIHRoZSBS ZWNvcmRJdGVtIGNsYXNzIG9mIHRoZSBJT0RFRiBmb2xsb3dpbmcgdGhlIFhNTFwKICAgZGlnaXRh bCBzaWduYXR1cmUgc3BlY2lmaWNhdGlvbnMgZnJvbSBXM0MgW1hNTHNpZ10gdXNpbmcgYSBkZXRh Y2hlZFwKICAgc2lnbmF0dXJlLiAgVGhlIHNpZ25hdHVyZSBNVVNUIGJlIHBhc3NlZCB0byBhbGwg cGFydGllcyB0aGF0IHJlY2VpdmVcCiAgIGEgVHJhY2VSZXF1ZXN0LCBhbmQgZWFjaCBwYXJ0eSBN VVNUIGJlIGFibGUgdG8gcGVyZm9ybSBmdWxsIHBhdGhcCiAgIHZhbGlkYXRpb24gb24gdGhlIGRp Z2l0YWwgc2lnbmF0dXJlIFtSRkM1MjgwXS4gIEZ1bGwgcGF0aCB2YWxpZGF0aW9uXAogICB2ZXJp ZmllcyB0aGUgY2hhaW5pbmcgcmVsYXRpb25zaGlwIHRvIGEgdHJ1c3RlZCByb290IGFuZCBhbHNv XAogICBwZXJmb3JtcyBhIGNlcnRpZmljYXRlIHJldm9jYXRpb24gY2hlY2suICBJbiBvcmRlciB0 byBhY2NvbW1vZGF0ZVwKICAgdGhhdCByZXF1aXJlbWVudCwgdGhlIFJlY29yZEl0ZW0gZGF0YSBN VVNUIHJlbWFpbiB1bmNoYW5nZWQgYXMgYVwKICAgcmVxdWVzdCBpcyBwYXNzZWQgYWxvbmcgYmV0 d2VlbiBwcm92aWRlcnMgYW5kIGlzIHRoZSBvbmx5IGVsZW1lbnQgZm9yXApcClwKXApNb3JpYXJ0 eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAgICAgICBb UGFnZSA1OF1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJGQzYwNDUt YmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgd2hpY2ggdGhlIHNpZ25h dHVyZSBpcyBhcHBsaWVkLiAgSWYgYWRkaXRpb25hbCBSZWNvcmRJdGVtcyBhcmVcCiAgIGluY2x1 ZGVkIGluIHRoZSBkb2N1bWVudCBhdCB1cHN0cmVhbSBwZWVycywgdGhlIGluaXRpYWwgUmVjb3Jk SXRlbVwKICAgZW50cnkgTVVTVCBzdGlsbCByZW1haW4gd2l0aCB0aGUgZGV0YWNoZWQgc2lnbmF0 dXJlLiAgVGhlIHN1YnNlcXVlbnRcCiAgIFJlY29yZEl0ZW0gZWxlbWVudHMgbWF5IGJlIHNpZ25l ZCBieSB0aGUgcGVlciBhZGRpbmcgdGhlIGluY2lkZW50XAogICBpbmZvcm1hdGlvbiBmb3IgdGhl IGludmVzdGlnYXRpb24uICBBIHNlY29uZCBiZW5lZml0IHRvIHRoaXNcCiAgIHJlcXVpcmVtZW50 IGlzIHRoYXQgdGhlIGludGVncml0eSBvZiB0aGUgZmlsdGVyIHVzZWQgaXMgZW5zdXJlZCBhcyBp dFwKICAgaXMgcGFzc2VkIHRvIHN1YnNlcXVlbnQgU1BzIGluIHRoZSB1cHN0cmVhbSB0cmFjZSBv ZiB0aGUgaW5jaWRlbnQuXAogICBUaGUgdHJ1c3RlZCBQS0kgYWxzbyBwcm92aWRlcyB0aGUga2V5 cyB1c2VkIHRvIGRpZ2l0YWxseSBzaWduIHRoZVwKICAgUmVjb3JkSXRlbSBjbGFzcyBmb3IgVHJh Y2VSZXF1ZXN0IG9yIEludmVzdGlnYXRpb24gdG8gbWVldCB0aGVcCiAgIHJlcXVpcmVtZW50IG9m IGF1dGhlbnRpY2F0aW5nIHRoZSBvcmlnaW5hbCByZXF1ZXN0LiAgQW55IGhvc3QgaW4gdGhlXAog ICBwYXRoIG9mIHRoZSB0cmFjZSBzaG91bGQgYmUgYWJsZSB0byB2ZXJpZnkgdGhlIGRpZ2l0YWwg c2lnbmF0dXJlXAogICB1c2luZyB0aGUgdHJ1c3RlZCBQS0kuXApcCiAgIEluIHRoZSBjYXNlIGlu IHdoaWNoIGFuIGVudGVycHJpc2UgbmV0d29yayB1c2luZyBSSUQgc2VuZHMgYVwKICAgVHJhY2VS ZXF1ZXN0IHRvIGl0cyBwcm92aWRlciwgdGhlIHNpZ25hdHVyZSBmcm9tIHRoZSBlbnRlcnByaXNl XAogICBuZXR3b3JrIE1VU1QgYmUgaW5jbHVkZWQgaW4gdGhlIGluaXRpYWwgcmVxdWVzdC4gIFRo ZSBTUCBtYXkgZ2VuZXJhdGVcCiAgIGEgbmV3IHJlcXVlc3QgdG8gc2VuZCB1cHN0cmVhbSB0byBt ZW1iZXJzIG9mIHRoZSBTUCBjb25zb3J0aXVtIHRvXAogICBjb250aW51ZSB0aGUgaW52ZXN0aWdh dGlvbi4gIElmIHRoZSBvcmlnaW5hbCByZXF1ZXN0IGlzIHNlbnQsIHRoZVwKICAgb3JpZ2luYXRp bmcgU1AsIGFjdGluZyBvbiBiZWhhbGYgb2YgdGhlIGVudGVycHJpc2UgbmV0d29yayB1bmRlclwK ICAgYXR0YWNrLCBNVVNUIGFsc28gZGlnaXRhbGx5IHNpZ24sIHdpdGggYW4gZW52ZWxvcGVkIHNp Z25hdHVyZSwgdGhlXAogICBmdWxsIElPREVGIGRvY3VtZW50IHRvIGFzc3VyZSB0aGUgYXV0aGVu dGljaXR5IG9mIHRoZSBUcmFjZVJlcXVlc3QuXAogICBBbiBTUCB0aGF0IG9mZmVycyBSSUQgYXMg YSBzZXJ2aWNlIG1heSBiZSB1c2luZyBpdHMgb3duIFBLSSB0byBzZWN1cmVcCiAgIFJJRCBjb21t dW5pY2F0aW9ucyBiZXR3ZWVuIGl0cyBSSUQgc3lzdGVtIGFuZCB0aGUgYXR0YWNoZWQgZW50ZXJw cmlzZVwKICAgbmV0d29ya3MuICBTUHMgcGFydGljaXBhdGluZyBpbiB0aGUgdHJhY2UgTVVTVCBi ZSBhYmxlIHRvIGRldGVybWluZVwKICAgdGhlIGF1dGhlbnRpY2l0eSBvZiBSSUQgcmVxdWVzdHMu XApcCjcuNS4gIENvbnNvcnRpdW1zIGFuZCBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlc1wKXAog ICBDb25zb3J0aXVtcyBvZiBTUHMgYXJlIGFuIGlkZWFsIHdheSB0byBlc3RhYmxpc2ggYSBjb21t dW5pY2F0aW9uIHdlYlwKICAgb2YgdHJ1c3QgZm9yIFJJRCBtZXNzYWdpbmcuICBJdCBzaG91bGQg YmUgbm90ZWQgdGhhdCBkaXJlY3RcCiAgIHJlbGF0aW9uc2hpcHMgbWF5IGJlIGlkZWFsIGZvciBz b21lIGNvbW11bmljYXRpb25zLCBzdWNoIGFzIHRob3NlXAogICBiZXR3ZWVuIGEgcHJvdmlkZXIg b2YgaW5jaWRlbnQgaW5mb3JtYXRpb24gYW5kIGEgc3Vic2NyaWJlciBvZiB0aGVcCiAgIGluY2lk ZW50IHJlcG9ydHMuICBUaGUgY29uc29ydGl1bSBjb3VsZCBwcm92aWRlIGNlbnRyYWxpemVkXAog ICByZXNvdXJjZXMsIHN1Y2ggYXMgYSBQS0ksIGFuZCBlc3RhYmxpc2hlZCBndWlkZWxpbmVzIGZv ciB1c2Ugb2YgdGhlXAogICBSSUQgcHJvdG9jb2wuICBUaGUgY29uc29ydGl1bSB3b3VsZCBhbHNv IGFzc2lzdCBpbiBlc3RhYmxpc2hpbmcgdHJ1c3RcCiAgIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiB0 aGUgcGFydGljaXBhdGluZyBTUHMgdG8gYWNoaWV2ZSB0aGUgbmVjZXNzYXJ5XAogICBsZXZlbCBv ZiBjb29wZXJhdGlvbiBhbmQgZXhwZXJpZW5jZS1zaGFyaW5nIGFtb25nIHRoZSBjb25zb3J0aXVt XAogICBlbnRpdGllcy4gIFRoaXMgbWF5IGJlIGVzdGFibGlzaGVkIHRocm91Z2ggUEtJIGNlcnRp ZmljYXRlIHBvbGljeVwKICAgW1JGQzM2NDddIHJldmlld3MgdG8gZGV0ZXJtaW5lIHRoZSBhcHBy b3ByaWF0ZSB0cnVzdCBsZXZlbHMgYmV0d2VlblwKICAgb3JnYW5pemF0aW9ucyBvciBlbnRpdGll cy4gIFRoZSBjb25zb3J0aXVtIG1heSBhbHNvIGJlIHVzZWQgZm9yIG90aGVyXAogICBwdXJwb3Nl cyB0byBiZXR0ZXIgZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIGFtb25nIFNQcyBpbiBhIGNvbW1v blwKICAgYXJlYSAoSW50ZXJuZXQsIHJlZ2lvbiwgZ292ZXJubWVudCwgZWR1Y2F0aW9uLCBwcml2 YXRlIG5ldHdvcmtzLFwKICAgZXRjLikuXApcCiAgIFVzaW5nIGEgUEtJIHRvIGRpc3RyaWJ1dGUg Y2VydGlmaWNhdGVzIHVzZWQgYnkgUklEIHN5c3RlbXMgcHJvdmlkZXNcCiAgIGFuIGFscmVhZHkg ZXN0YWJsaXNoZWQgbWV0aG9kIHRvIGxpbmsgdHJ1c3QgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIFNQ c1wKICAgb2YgY29uc29ydGl1bXMgdGhhdCB3b3VsZCBwZWVyIHdpdGggU1BzIGJlbG9uZ2luZyB0 byBhIHNlcGFyYXRlXAogICBjb25zb3J0aXVtLiAgSW4gb3RoZXIgd29yZHMsIGNvbnNvcnRpdW1z IGNvdWxkIHBlZXIgd2l0aCBvdGhlclwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTldXApccGFnZSBcCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAg ICBBdWd1c3QgMjAxMVwKXApcCiAgIGNvbnNvcnRpdW1zIHRvIGVuYWJsZSBjb21tdW5pY2F0aW9u IG9mIFJJRCBtZXNzYWdlcyBiZXR3ZWVuIHRoZVwKICAgcGFydGljaXBhdGluZyBTUHMuICBUaGUg UEtJIGFsb25nIHdpdGggTWVtb3JhbmR1bXMgb2YgQWdyZWVtZW50IGNvdWxkXAogICBiZSB1c2Vk IHRvIGxpbmsgYm9yZGVyIGRpcmVjdG9yaWVzIHRvIHNoYXJlIHB1YmxpYyBrZXkgaW5mb3JtYXRp b24gaW5cCiAgIGEgYnJpZGdlLCBhIGhpZXJhcmNoeSwgb3IgYSBzaW5nbGUgY3Jvc3MtY2VydGlm aWNhdGlvbiByZWxhdGlvbnNoaXAuXApcCiAgIENvbnNvcnRpdW1zIGFsc28gbmVlZCB0byBlc3Rh Ymxpc2ggZ3VpZGVsaW5lcyBmb3IgZWFjaCBwYXJ0aWNpcGF0aW5nXAogICBTUCB0byBhZGhlcmUg dG8uICBUaGUgUkVDT01NRU5ERUQgZ3VpZGVsaW5lcyBpbmNsdWRlOlwKXAogICBvICBQaHlzaWNh bCBhbmQgbG9naWNhbCBwcmFjdGljZXMgdG8gcHJvdGVjdCBSSUQgc3lzdGVtcztcClwKICAgbyAg TmV0d29yayBhbmQgYXBwbGljYXRpb24gbGF5ZXIgcHJvdGVjdGlvbiBmb3IgUklEIHN5c3RlbXMg YW5kXAogICAgICBjb21tdW5pY2F0aW9ucztcClwKICAgbyAgUHJvcGVyIHVzZSBndWlkZWxpbmVz IGZvciBSSUQgc3lzdGVtcywgbWVzc2FnZXMsIGFuZCByZXF1ZXN0czsgYW5kXApcCiAgIG8gIEEg UEtJIGFuZCBwb2xpY3kgdG8gcHJvdmlkZSBhdXRoZW50aWNhdGlvbiwgaW50ZWdyaXR5LCBhbmRc CiAgICAgIHByaXZhY3kuXApcCiAgIFRoZSBmdW5jdGlvbnMgZGVzY3JpYmVkIGZvciBhIGNvbnNv cnRpdW0ncyByb2xlIHdvdWxkIHBhcmFsbGVsIHRoYXRcCiAgIG9mIGEgUEtJIGZlZGVyYXRpb24u ICBUaGUgUEtJIGZlZGVyYXRpb25zIHRoYXQgY3VycmVudGx5IGV4aXN0IGFyZVwKICAgcmVzcG9u c2libGUgZm9yIGVzdGFibGlzaGluZyBzZWN1cml0eSBndWlkZWxpbmVzIGFuZCBQS0kgdHJ1c3Rc CiAgIG1vZGVscy4gIFRoZSB0cnVzdCBtb2RlbHMgYXJlIHVzZWQgdG8gc3VwcG9ydCBhcHBsaWNh dGlvbnMgdG8gc2hhcmVcCiAgIGluZm9ybWF0aW9uIHVzaW5nIHRydXN0ZWQgbWV0aG9kcyBhbmQg cHJvdG9jb2xzLlwKXAogICBBIFBLSSBjYW4gYWxzbyBwcm92aWRlIHRoZSBzYW1lIGxldmVsIG9m IHNlY3VyaXR5IGZvciBjb21tdW5pY2F0aW9uXAogICBiZXR3ZWVuIGFuIGVuZCBlbnRpdHkgKGVu dGVycHJpc2UsIGVkdWNhdGlvbmFsLCBvciBnb3Zlcm5tZW50XAogICBjdXN0b21lciBuZXR3b3Jr KSBhbmQgdGhlIFNQLiAgVGhlIFBLSSBtYXkgYmUgYSBzdWJvcmRpbmF0ZSBDQSBvciBpblwKICAg dGhlIENBIGhpZXJhcmNoeSBmcm9tIHRoZSBTUCdzIGNvbnNvcnRpdW0gdG8gZXN0YWJsaXNoIHRo ZSB0cnVzdFwKICAgcmVsYXRpb25zaGlwcyBuZWNlc3NhcnkgYXMgdGhlIHJlcXVlc3QgaXMgbWFk ZSB0byBvdGhlciBjb25uZWN0ZWRcCiAgIG5ldHdvcmtzLlwKXAo3LjYuICBQcml2YWN5IENvbmNl cm5zIGFuZCBTeXN0ZW0gVXNlIEd1aWRlbGluZXNcClwKICAgUHJpdmFjeSBpc3N1ZXMgcmFpc2Ug bWFueSBjb25jZXJucyB3aGVuIGluZm9ybWF0aW9uLXNoYXJpbmcgaXNcCiAgIHJlcXVpcmVkIHRv IGFjaGlldmUgdGhlIGdvYWwgb2Ygc3RvcHBpbmcgb3IgbWl0aWdhdGluZyB0aGUgZWZmZWN0cyBv ZlwKICAgYSBzZWN1cml0eSBpbmNpZGVudC4gIFRoZSBSSURQb2xpY3kgY2xhc3MgaXMgdXNlZCB0 byBhdXRvbWF0ZSB0aGVcCiAgIGVuZm9yY2VtZW50IG9mIHRoZSBwcml2YWN5IGNvbmNlcm5zIGxp c3RlZCB3aXRoaW4gdGhpcyBkb2N1bWVudC4gIFRoZVwKICAgcHJpdmFjeSBhbmQgc3lzdGVtIHVz ZSBjb25jZXJucyB0aGF0IE1VU1QgYmUgYWRkcmVzc2VkIGluIHRoZSBSSURcCiAgIHN5c3RlbSBh bmQgb3RoZXIgaW50ZWdyYXRlZCBjb21wb25lbnRzIGluY2x1ZGUgdGhlIGZvbGxvd2luZzpcClwK ICAgTmV0d29yayBQcm92aWRlciBDb25jZXJuczpcClwKICAgbyAgUHJpdmFjeSBvZiBkYXRhIG1v bml0b3JlZCBhbmQvb3Igc3RvcmVkIG9uIElEU3MgZm9yIGF0dGFja1wKICAgICAgZGV0ZWN0aW9u LlwKXAogICBvICBQcml2YWN5IG9mIGRhdGEgbW9uaXRvcmVkIGFuZCBzdG9yZWQgb24gc3lzdGVt cyB1c2VkIHRvIHRyYWNlXAogICAgICB0cmFmZmljIGFjcm9zcyBhIHNpbmdsZSBuZXR3b3JrLlwK XApcClwKXApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEy ICAgICAgICAgICAgICBbUGFnZSA2MF1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgIFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAg Q3VzdG9tZXIgQXR0YWNoZWQgTmV0d29ya3MgUGFydGljaXBhdGluZyBpbiBSSUQgd2l0aCBTUDpc ClwKICAgbyAgQ3VzdG9tZXIgbmV0d29ya3MgbWF5IGluY2x1ZGUgYW4gZW50ZXJwcmlzZSwgZWR1 Y2F0aW9uYWwsXAogICAgICBnb3Zlcm5tZW50LCBvciBvdGhlciBhdHRhY2hlZCBuZXR3b3JrcyB0 byBhbiBTUCBwYXJ0aWNpcGF0aW5nIGluXAogICAgICBSSUQgYW5kIE1VU1QgYmUgbWFkZSBmdWxs eSBhd2FyZSBvZiB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3lcCiAgICAgIGNvbnNpZGVyYXRpb25z IGZvciB1c2luZyBSSUQuXApcCiAgIG8gIEN1c3RvbWVycyBNVVNUIGtub3cgdGhlIHNlY3VyaXR5 IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGluXAogICAgICBwbGFjZSBieSB0aGVpciBTUCBh bmQgdGhlIGNvbnNvcnRpdW0gb2Ygd2hpY2ggdGhlIFNQIGlzIGEgbWVtYmVyLlwKXAogICBvICBD dXN0b21lcnMgTVVTVCB1bmRlcnN0YW5kIHRoYXQgdGhlaXIgZGF0YSBjYW4gYW5kIHdpbGwgYmUg c2VudCB0b1wKICAgICAgb3RoZXIgU1BzIGluIG9yZGVyIHRvIGNvbXBsZXRlIGEgdHJhY2UgdW5s ZXNzIGFuIGFncmVlbWVudCBzdGF0aW5nXAogICAgICBvdGhlcndpc2UgaXMgbWFkZSBpbiB0aGUg c2VydmljZSBsZXZlbCBhZ3JlZW1lbnRzIGJldHdlZW4gdGhlXAogICAgICBjdXN0b21lciBhbmQg U1AuXApcCiAgIFBhcnRpZXMgSW52b2x2ZWQgaW4gdGhlIEF0dGFjazpcClwKICAgbyAgUHJpdmFj eSBvZiB0aGUgaWRlbnRpdHkgb2YgYSBob3N0IGludm9sdmVkIGluIGFuIGF0dGFjay5cClwKICAg byAgUHJpdmFjeSBvZiBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0 aW9uIHVzZWQgZm9yXAogICAgICBjb21tdW5pY2F0aW9uIHB1cnBvc2VzIG92ZXIgdGhlIG1vbml0 b3JlZCBvciBSSUQgY29ubmVjdGVkXAogICAgICBuZXR3b3JrKHMpLlwKXAogICBvICBQcm90ZWN0 aW9uIG9mIGRhdGEgZnJvbSBiZWluZyB2aWV3ZWQgYnkgaW50ZXJtZWRpYXRlIHBhcnRpZXMgaW5c CiAgICAgIHRoZSBwYXRoIG9mIGFuIEludmVzdGlnYXRpb24gcmVxdWVzdCBNVVNUIGJlIGNvbnNp ZGVyZWQuXApcCiAgIENvbnNvcnRpdW0gQ29uc2lkZXJhdGlvbnM6XApcCiAgIG8gIFN5c3RlbSB1 c2UgcmVzdHJpY3RlZCB0byBzZWN1cml0eSBpbmNpZGVudCBoYW5kbGluZyB3aXRoaW4gdGhlXAog ICAgICBsb2NhbCByZWdpb24ncyBkZWZpbml0aW9ucyBvZiBhcHByb3ByaWF0ZSB0cmFmZmljIGZv ciB0aGUgbmV0d29ya1wKICAgICAgbW9uaXRvcmVkIGFuZCBsaW5rZWQgdmlhIFJJRCBpbiBhIHNp bmdsZSBjb25zb3J0aXVtIGFsc28gYWJpZGluZ1wKICAgICAgYnkgdGhlIGNvbnNvcnRpdW0ncyB1 c2UgZ3VpZGVsaW5lcy5cClwKICAgbyAgU3lzdGVtIHVzZSBwcm9oaWJpdGluZyB0aGUgY29uc29y dGl1bSdzIHBhcnRpY2lwYXRpbmcgU1BzIGZyb21cCiAgICAgIGluYXBwcm9wcmlhdGVseSB0cmFj aW5nIG5vbi1hdHRhY2sgdHJhZmZpYyB0byBsb2NhdGUgc291cmNlcyBvclwKICAgICAgbWl0aWdh dGUgdHJhZmZpYyB1bmxhd2Z1bGx5IHdpdGhpbiB0aGUganVyaXNkaWN0aW9uIG9yIHJlZ2lvbi5c ClwKICAgSW50ZXItQ29uc29ydGl1bSBDb25zaWRlcmF0aW9uczpcClwKICAgbyAgU3lzdGVtIHVz ZSBiZXR3ZWVuIHBlZXJpbmcgY29uc29ydGl1bXMgTVVTVCBhbHNvIGFkaGVyZSB0byBhbnlcCiAg ICAgIGdvdmVybm1lbnQgY29tbXVuaWNhdGlvbiByZWd1bGF0aW9ucyB0aGF0IGFwcGx5IGJldHdl ZW4gdGhvc2UgdHdvXAogICAgICByZWdpb25zLCBzdWNoIGFzIGVuY3J5cHRpb24gZXhwb3J0IGFu ZCBpbXBvcnQgcmVzdHJpY3Rpb25zLiAgVGhpc1wKICAgICAgbWF5IGluY2x1ZGUgY29uc29ydGl1 bXMgdGhhdCBhcmUgY2F0ZWdvcml6ZWQgYXNcCiAgICAgICJCZXR3ZWVuQ29uc29ydGl1bXMiIG9y ICJBY3Jvc3NOYXRpb25hbEJvdW5kYXJpZXMiLlwKXAogICBvICBTeXN0ZW0gdXNlIGJldHdlZW4g Y29uc29ydGl1bXMgTVVTVCBOT1QgcmVxdWVzdCB0cmFmZmljIHRyYWNlcyBhbmRcCiAgICAgIGFj dGlvbnMgYmV5b25kIHRoZSBzY29wZSBpbnRlbmRlZCBhbmQgcGVybWl0dGVkIGJ5IGxhdyBvciBp bnRlci1cCiAgICAgIGNvbnNvcnRpdW0gYWdyZWVtZW50cy5cClwKXApcCk1vcmlhcnR5ICAgICAg ICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDYx XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAg ICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBvICBTeXN0ZW0gdXNlIGJldHdlZW4g Y29uc29ydGl1bXMgY2xhc3NpZmllZCBhc1wKICAgICAgIkFjcm9zc05hdGlvbmFsQm91bmRhcmll cyIgTVVTVCByZXNwZWN0IG5hdGlvbmFsIGJvdW5kYXJ5IGlzc3Vlc1wKICAgICAgYW5kIGxpbWl0 IHJlcXVlc3RzIHRvIGFwcHJvcHJpYXRlIHN5c3RlbSB1c2UgYW5kIG5vdCB0byBhY2hpZXZlXAog ICAgICB0aGVpciBvd24gYWdlbmRhIHRvIGxpbWl0IG9yIHJlc3RyaWN0IHRyYWZmaWMgdGhhdCBp cyBvdGhlcndpc2VcCiAgICAgIHBlcm1pdHRlZCB3aXRoaW4gdGhlIGNvdW50cnkgaW4gd2hpY2gg dGhlIHBlZXJpbmcgY29uc29ydGl1bVwKICAgICAgcmVzaWRlcy5cClwKICAgVGhlIHNlY3VyaXR5 IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGxpc3RlZCBhYm92ZSBhcmUgZm9yIHRoZVwKICAg Y29uc29ydGl1bXMsIFNQcywgYW5kIGVudGVycHJpc2VzIHRvIGFncmVlIHVwb24uICBUaGUgYWdy ZWVkLXVwb25cCiAgIHBvbGljaWVzIG1heSBiZSBmYWNpbGl0YXRlZCB0aHJvdWdoIHVzZSBvZiB0 aGUgUklEUG9saWN5IGNsYXNzLiAgU29tZVwKICAgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBhcmUg YWRkcmVzc2VkIHRocm91Z2ggdGhlIFJJRCBndWlkZWxpbmVzIGZvclwKICAgZW5jcnlwdGlvbiBh bmQgZGlnaXRhbCBzaWduYXR1cmVzIGFzIGRlc2NyaWJlZCBhdCB0aGUgYmVnaW5uaW5nIG9mXAog ICBTZWN0aW9uIDYuXApcCiAgIFJJRCBpcyB1c2VmdWwgaW4gZGV0ZXJtaW5pbmcgdGhlIHRydWUg c291cmNlIG9mIGFuIGluY2lkZW50IHRoYXRcCiAgIHRyYXZlcnNlcyBtdWx0aXBsZSBuZXR3b3Jr cyBvciB0byBjb21tdW5pY2F0ZSBzZWN1cml0eSBpbmNpZGVudHMgYW5kXAogICBhdXRvbWF0ZSB0 aGUgcmVzcG9uc2UuICBUaGUgaW5mb3JtYXRpb24gb2J0YWluZWQgZnJvbSB0aGVcCiAgIGludmVz dGlnYXRpb24gbWF5IGRldGVybWluZSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNvdXJjZSBob3N0IG9y IHRoZVwKICAgbmV0d29yayBwcm92aWRlciB1c2VkIGJ5IHRoZSBzb3VyY2Ugb2YgdGhlIHRyYWZm aWMuICBJdCBzaG91bGQgYmVcCiAgIG5vdGVkIHRoYXQgdGhlIHRyYWNlIG1lY2hhbmlzbSB1c2Vk IGFjcm9zcyBhIHNpbmdsZS1uZXR3b3JrIHByb3ZpZGVyXAogICBtYXkgYWxzbyByYWlzZSBwcml2 YWN5IGNvbmNlcm5zIGZvciB0aGUgY2xpZW50cyBvZiB0aGUgbmV0d29yay5cCiAgIE1ldGhvZHMg dGhhdCBtYXkgcmFpc2UgY29uY2VybiBpbmNsdWRlIHRob3NlIHRoYXQgaW52b2x2ZSBzdG9yaW5n XAogICBwYWNrZXRzIGZvciBzb21lIGxlbmd0aCBvZiB0aW1lIGluIG9yZGVyIHRvIHRyYWNlIHBh Y2tldHMgYWZ0ZXIgdGhlXAogICBmYWN0LiAgTW9uaXRvcmluZyBuZXR3b3JrcyBmb3IgaW50cnVz aW9ucyBhbmQgZm9yIHRyYWNpbmdcCiAgIGNhcGFiaWxpdGllcyBhbHNvIHJhaXNlcyBjb25jZXJu cyBmb3IgcG90ZW50aWFsbHkgc2Vuc2l0aXZlIHZhbGlkXAogICB0cmFmZmljIHRoYXQgbWF5IGJl IHRyYXZlcnNpbmcgdGhlIG1vbml0b3JlZCBuZXR3b3JrLiAgSURTcyBhbmRcCiAgIHNpbmdsZS1u ZXR3b3JrIHRyYWNpbmcgYXJlIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQs IGJ1dFwKICAgdGhlIGNvbmNlcm4gc2hvdWxkIGJlIG5vdGVkIGFuZCBhZGRyZXNzZWQgd2l0aGlu IHRoZSB1c2UgZ3VpZGVsaW5lc1wKICAgb2YgdGhlIG5ldHdvcmsuICBTb21lIElEU3MgYW5kIHNp bmdsZS1uZXR3b3JrIHRyYWNlIG1lY2hhbmlzbXNcCiAgIGF0dGVtcHQgdG8gcHJvcGVybHkgYWRk cmVzcyB0aGVzZSBpc3N1ZXMuICBSSUQgaXMgZGVzaWduZWQgdG8gcHJvdmlkZVwKICAgdGhlIGlu Zm9ybWF0aW9uIG5lZWRlZCBieSBhbnkgc2luZ2xlLW5ldHdvcmsgdHJhY2UgbWVjaGFuaXNtLiAg VGhlXAogICBwcm92aWRlcidzIGNob2ljZSBvZiBhIHNpbmdsZSB0cmFjZSBtZWNoYW5pc20gZGVw ZW5kcyBvbiByZXNvdXJjZXMsXAogICBleGlzdGluZyBzb2x1dGlvbnMsIGFuZCBsb2NhbCBsZWdp c2xhdGlvbi4gIFByaXZhY3kgY29uY2VybnMgaW5cCiAgIHJlZ2FyZCB0byB0aGUgc2luZ2xlLW5l dHdvcmsgdHJhY2UgbXVzdCBiZSBkZWFsdCB3aXRoIGF0IHRoZSBjbGllbnQtXAogICB0by1TUCBs ZXZlbCBhbmQgYXJlIG91dCBvZiBzY29wZSBmb3IgUklEIG1lc3NhZ2luZy5cClwKICAgVGhlIGlk ZW50aXR5IG9mIHRoZSB0cnVlIHNvdXJjZSBvZiBhbiBhdHRhY2sgYmVpbmcgdHJhY2VkIHRocm91 Z2ggUklEXAogICBjb3VsZCBiZSBzZW5zaXRpdmUuICBUaGUgdHJ1ZSBpZGVudGl0eSBsaXN0ZWQg aW4gYSBSZXN1bHQgbWVzc2FnZSBjYW5cCiAgIGJlIHByb3RlY3RlZCB0aHJvdWdoIHRoZSB1c2Ug b2YgZW5jcnlwdGlvbiBbWE1MZW5jcnlwdF0gZW52ZWxvcGluZ1wKICAgdGhlIElPREVGIGRvY3Vt ZW50IGFuZCBSSUQgUmVzdWx0IGluZm9ybWF0aW9uLCB1c2luZyB0aGUgcHVibGljXAogICBlbmNy eXB0aW9uIGtleSBvZiB0aGUgb3JpZ2luYXRpbmcgU1AuICBBbHRlcm5hdGl2ZWx5LCB0aGUgYWN0 aW9uXAogICB0YWtlbiBtYXkgYmUgbGlzdGVkIHdpdGhvdXQgdGhlIGlkZW50aXR5IGJlaW5nIHJl dmVhbGVkIHRvIHRoZVwKICAgb3JpZ2luYXRpbmcgU1AuICBUaGUgdWx0aW1hdGUgZ29hbCBvZiB0 aGUgUklEIGNvbW11bmljYXRpb24gc3lzdGVtIGlzXAogICB0byBzdG9wIG9yIG1pdGlnYXRlIGF0 dGFjayB0cmFmZmljLCBub3QgdG8gZW5zdXJlIHRoYXQgdGhlIGlkZW50aXR5XAogICBvZiB0aGUg YXR0YWNrIHRyYWZmaWMgaXMga25vd24gdG8gaW52b2x2ZWQgcGFydGllcy4gIFRoZSBTUCB0aGF0 XAogICBpZGVudGlmaWVzIHRoZSBzb3VyY2Ugc2hvdWxkIGRlYWwgZGlyZWN0bHkgd2l0aCB0aGUg aW52b2x2ZWQgcGFydGllc1wKICAgYW5kIHByb3BlciBhdXRob3JpdGllcyBpbiBvcmRlciB0byBk ZXRlcm1pbmUgdGhlIGd1aWRlbGluZXMgZm9yIHRoZVwKICAgcmVsZWFzZSBvZiBzdWNoIGluZm9y bWF0aW9uLCBpZiBpdCBpcyByZWdhcmRlZCBhcyBzZW5zaXRpdmUuICBJbiBzb21lXApcClwKXApN b3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAgICAg ICAgICBbUGFnZSA2Ml1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFJG QzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgc2l0dWF0aW9u cywgc3lzdGVtcyB1c2VkIGluIGF0dGFja3MgYXJlIGNvbXByb21pc2VkIGJ5IGFuIHVua25vd25c CiAgIHNvdXJjZSBhbmQsIGluIHR1cm4sIGFyZSB1c2VkIHRvIGF0dGFjayBvdGhlciBzeXN0ZW1z LiAgSW4gdGhhdFwKICAgc2l0dWF0aW9uLCB0aGUgcmVwdXRhdGlvbiBvZiBhIGJ1c2luZXNzIG9y IG9yZ2FuaXphdGlvbiBtYXkgYmUgYXRcCiAgIHN0YWtlLCBhbmQgdGhlIGFjdGlvbiB0YWtlbiBt YXkgYmUgdGhlIG9ubHkgYWRkaXRpb25hbCBpbmZvcm1hdGlvblwKICAgcmVwb3J0ZWQgaW4gdGhl IFJlc3VsdCBtZXNzYWdlIHRvIHRoZSBvcmlnaW5hdGluZyBzeXN0ZW0uICBJZiB0aGVcCiAgIHNl Y3VyaXR5IGluY2lkZW50IGlzIGEgbWlub3IgaW5jaWRlbnQsIHN1Y2ggYXMgYSB6b21iaWUgc3lz dGVtIHVzZWRcCiAgIGluIHBhcnQgb2YgYSBsYXJnZS1zY2FsZSBERG9TIGF0dGFjaywgZW5zdXJp bmcgdGhlIHN5c3RlbSBpcyB0YWtlblwKICAgb2ZmIHRoZSBuZXR3b3JrIHVudGlsIGl0IGhhcyBi ZWVuIGZpeGVkIG1heSBiZSBzdWZmaWNpZW50LiAgVGhlXAogICBkZWNpc2lvbiBpcyBsZWZ0IHRv IHRoZSBzeXN0ZW0gdXNlcnMgYW5kIGNvbnNvcnRpdW1zIHRvIGRldGVybWluZVwKICAgYXBwcm9w cmlhdGUgZGF0YSB0byBiZSBzaGFyZWQgZ2l2ZW4gdGhhdCB0aGUgZ29hbCBvZiB0aGVcCiAgIHNw ZWNpZmljYXRpb24gaXMgdG8gcHJvdmlkZSB0aGUgYXBwcm9wcmlhdGUgdGVjaG5pY2FsIG9wdGlv bnMgdG9cCiAgIHJlbWFpbiBjb21wbGlhbnQuICBUaGUgdGV4dHVhbCBkZXNjcmlwdGlvbnMgc2hv dWxkIGluY2x1ZGUgZGV0YWlscyBvZlwKICAgdGhlIGluY2lkZW50IGluIG9yZGVyIHRvIHByb3Rl Y3QgdGhlIHJlcHV0YXRpb24gb2YgdGhlIHVua25vd2luZ1wKICAgYXR0YWNrZXIgYW5kIHByZXZl bnQgdGhlIG5lZWQgZm9yIGFkZGl0aW9uYWwgaW52ZXN0aWdhdGlvbi4gIExvY2FsLFwKICAgc3Rh dGUsIG9yIG5hdGlvbmFsIGxhd3MgbWF5IGRpY3RhdGUgdGhlIGFwcHJvcHJpYXRlIHJlcG9ydGlu ZyBhY3Rpb25cCiAgIGZvciBzcGVjaWZpYyBzZWN1cml0eSBpbmNpZGVudHMuXApcCiAgIFByaXZh Y3kgYmVjb21lcyBhbiBpc3N1ZSB3aGVuZXZlciBzZW5zaXRpdmUgZGF0YSB0cmF2ZXJzZXMgYSBu ZXR3b3JrLlwKICAgRm9yIGV4YW1wbGUsIGlmIGFuIGF0dGFjayBvY2N1cnJlZCBiZXR3ZWVuIGEg c3BlY2lmaWMgc291cmNlIGFuZFwKICAgZGVzdGluYXRpb24sIHRoZW4gZXZlcnkgbmV0d29yayBw cm92aWRlciBpbiB0aGUgcGF0aCBvZiB0aGUgdHJhY2VcCiAgIHdvdWxkIGJlY29tZSBhd2FyZSB0 aGF0IHRoZSBjeWJlciBhdHRhY2sgb2NjdXJyZWQuICBJbiBhIHRhcmdldGVkXAogICBhdHRhY2ss IGl0IG1heSBub3QgYmUgZGVzaXJhYmxlIHRoYXQgaW5mb3JtYXRpb24gYWJvdXQgdHdvIG5hdGlv blwKICAgc3RhdGVzIHRoYXQgYXJlIGJhdHRsaW5nIGEgY3liZXIgd2FyIHdvdWxkIGJlY29tZSBn ZW5lcmFsIGtub3dsZWRnZVwKICAgdG8gYWxsIGludGVybWVkaWF0ZSBwYXJ0aWVzLiAgSG93ZXZl ciwgaXQgaXMgaW1wb3J0YW50IHRvIGFsbG93IHRoZVwKICAgdHJhY2VzIHRvIHRha2UgcGxhY2Ug aW4gb3JkZXIgdG8gaGFsdCB0aGUgYWN0aXZpdHkgc2luY2UgdGhlIGhlYWx0aFwKICAgb2YgdGhl IG5ldHdvcmtzIGluIHRoZSBwYXRoIGNvdWxkIGFsc28gYmUgYXQgc3Rha2UgZHVyaW5nIHRoZSBh dHRhY2suXAogICBUaGlzIHByb3ZpZGVzIGEgc2Vjb25kIGFyZ3VtZW50IGZvciBhbGxvd2luZyB0 aGUgUmVzdWx0IG1lc3NhZ2UgdG9cCiAgIG9ubHkgaW5jbHVkZSBhbiBhY3Rpb24gdGFrZW4gYW5k IG5vdCB0aGUgaWRlbnRpdHkgb2YgdGhlIG9mZmVuZGluZ1wKICAgaG9zdC4gIEluIHRoZSBjYXNl IG9mIGFuIEludmVzdGlnYXRpb24gcmVxdWVzdCwgd2hlcmUgdGhlIG9yaWdpbmF0aW5nXAogICBT UCBpcyBhd2FyZSBvZiB0aGUgU1AgdGhhdCB3aWxsIHJlY2VpdmUgdGhlIHJlcXVlc3QgZm9yIHBy b2Nlc3NpbmcsXAogICB0aGUgZnJlZS1mb3JtIHRleHQgYXJlYXMgb2YgdGhlIGRvY3VtZW50IGNv dWxkIGJlIGVuY3J5cHRlZFwKICAgW1hNTGVuY3J5cHRdIHVzaW5nIHRoZSBwdWJsaWMga2V5IG9m IHRoZSBkZXN0aW5hdGlvbiBTUCB0byBlbnN1cmVcCiAgIHRoYXQgbm8gb3RoZXIgU1AgaW4gdGhl IHBhdGggY2FuIHJlYWQgdGhlIGNvbnRlbnRzLiAgVGhlIGVuY3J5cHRpb25cCiAgIHdvdWxkIGJl IGFjY29tcGxpc2hlZCB0aHJvdWdoIHRoZSBXM0MgW1hNTGVuY3J5cHRdIHNwZWNpZmljYXRpb24g Zm9yXAogICBlbmNyeXB0aW5nIGFuIGVsZW1lbnQuXApcCiAgIEluIHNvbWUgc2l0dWF0aW9ucywg YWxsIG5ldHdvcmsgdHJhZmZpYyBvZiBhIG5hdGlvbiBtYXkgYmUgZ3JhbnRlZFwKICAgdGhyb3Vn aCBhIHNpbmdsZSBuZXR3b3JrIHByb3ZpZGVyLiAgSW4gdGhhdCBzaXR1YXRpb24sIG9wdGlvbnMg bXVzdFwKICAgc3VwcG9ydCBzZW5kaW5nIFJlc3VsdCBtZXNzYWdlcyBmcm9tIGEgZG93bnN0cmVh bSBwZWVyIG9mIHRoYXRcCiAgIG5ldHdvcmsgcHJvdmlkZXIuICBUaGF0IG9wdGlvbiBwcm92aWRl cyBhbiBhZGRpdGlvbmFsIGxldmVsIG9mXAogICBhYnN0cmFjdGlvbiB0byBoaWRlIHRoZSBpZGVu dGl0eSBhbmQgdGhlIFNQIG9mIHRoZSBpZGVudGlmaWVkIHNvdXJjZVwKICAgb2YgdGhlIHRyYWZm aWMuICBMZWdhbCBhY3Rpb24gbWF5IG92ZXJyaWRlIHRoaXMgdGVjaG5pY2FsIGRlY2lzaW9uXAog ICBhZnRlciB0aGUgdHJhY2UgaGFzIHRha2VuIHBsYWNlLCBidXQgdGhhdCBpcyBvdXQgb2YgdGhl IHRlY2huaWNhbFwKICAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC5cClwKICAgUHJpdmFjeSBjb25j ZXJucyB3aGVuIHVzaW5nIGFuIEludmVzdGlnYXRpb24gbWVzc2FnZSB0byByZXF1ZXN0XAogICBh Y3Rpb24gY2xvc2UgdG8gdGhlIHNvdXJjZSBvZiB2YWxpZCBhdHRhY2sgdHJhZmZpYyBuZWVkcyB0 byBiZVwKICAgY29uc2lkZXJlZC4gIEFsdGhvdWdoIHRoZSBpbnRlcm1lZGlhdGUgU1BzIG1heSBy ZWxheSB0aGUgcmVxdWVzdCBpZlwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjNdXApccGFnZSBcCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBB dWd1c3QgMjAxMVwKXApcCiAgIHRoZXJlIGlzIG5vIGRpcmVjdCB0cnVzdCByZWxhdGlvbnNoaXAg dG8gdGhlIGNsb3Nlc3QgU1AgdG8gdGhlXAogICBzb3VyY2UsIHRoZSBpbnRlcm1lZGlhdGUgU1Bz IGRvIG5vdCByZXF1aXJlIHRoZSBhYmlsaXR5IHRvIHNlZSB0aGVcCiAgIGNvbnRlbnRzIG9mIHRo ZSBwYWNrZXQgb3IgdGhlIHRleHQgZGVzY3JpcHRpb24gZmllbGQocykgaW4gdGhlXAogICByZXF1 ZXN0LiAgVGhpcyBtZXNzYWdlIHR5cGUgZG9lcyBub3QgcmVxdWlyZSBhbnkgYWN0aW9uIGJ5IHRo ZVwKICAgaW50ZXJtZWRpYXRlIFJJRCBzeXN0ZW1zLCBleGNlcHQgdG8gcmVsYXkgdGhlIHBhY2tl dCB0byB0aGUgbmV4dCBTUFwKICAgaW4gdGhlIHBhdGguICBUaGVyZWZvcmUsIHRoZSBjb250ZW50 cyBvZiB0aGUgcmVxdWVzdCBtYXkgYmUgZW5jcnlwdGVkXAogICBmb3IgdGhlIGRlc3RpbmF0aW9u IHN5c3RlbS4gIFRoZSBpbnRlcm1lZGlhdGUgU1BzIHdvdWxkIG9ubHkgbmVlZCB0b1wKICAga25v dyBob3cgdG8gZGlyZWN0IHRoZSByZXF1ZXN0IHRvIHRoZSBtYW5hZ2VyIG9mIHRoZSBBU04gaW4g d2hpY2ggdGhlXAogICBzb3VyY2UgSVAgYWRkcmVzcyBiZWxvbmdzLlwKXAogICBUcmFjZXMgbXVz dCBiZSBsZWdpdGltYXRlIHNlY3VyaXR5LXJlbGF0ZWQgaW5jaWRlbnRzIGFuZCBub3QgdXNlZCBm b3JcCiAgIHB1cnBvc2VzIHN1Y2ggYXMgc2Fib3RhZ2Ugb3IgY2Vuc29yc2hpcC4gIEFuIGV4YW1w bGUgb2Ygc3VjaCBhYnVzZSBvZlwKICAgdGhlIHN5c3RlbSB3b3VsZCBpbmNsdWRlIGEgcmVxdWVz dCB0byBibG9jayBvciByYXRlLWxpbWl0IGxlZ2l0aW1hdGVcCiAgIHRyYWZmaWMgdG8gcHJldmVu dCBpbmZvcm1hdGlvbiBmcm9tIGJlaW5nIHNoYXJlZCBiZXR3ZWVuIHVzZXJzIG9uIHRoZVwKICAg SW50ZXJuZXQgKHJlc3RyaWN0aW5nIGFjY2VzcyB0byBvbmxpbmUgdmVyc2lvbnMgb2YgcGFwZXJz KSBvclwKICAgcmVzdHJpY3RpbmcgYWNjZXNzIGZyb20gYSBjb21wZXRpdG9yJ3MgcHJvZHVjdCBp biBvcmRlciB0byBzYWJvdGFnZSBhXAogICBidXNpbmVzcy5cClwKICAgSW50cmEtY29uc29ydGl1 bSBSSUQgY29tbXVuaWNhdGlvbnMgcmFpc2UgYWRkaXRpb25hbCBpc3N1ZXMsXAogICBlc3BlY2lh bGx5IHdoZW4gdGhlIHBlZXJpbmcgY29uc29ydGl1bXMgcmVzaWRlIGluIGRpZmZlcmVudCByZWdp b25zXAogICBvciBuYXRpb25zLiAgVHJhY2VSZXF1ZXN0cywgSW52ZXN0aWdhdGlvbiByZXF1ZXN0 cywgYW5kIHJlcXVlc3RlZFwKICAgYWN0aW9ucyB0byBtaXRpZ2F0ZSBvciBzdG9wIHRyYWZmaWMg bXVzdCBhZGhlcmUgdG8gdGhlIGFwcHJvcHJpYXRlXAogICB1c2UgZ3VpZGVsaW5lcyBhbmQgeWV0 IHByZXZlbnQgYWJ1c2Ugb2YgdGhlIHN5c3RlbS4gIEZpcnN0LCB0aGVcCiAgIHBlZXJpbmcgY29u c29ydGl1bXMgTVVTVCBpZGVudGlmeSB0aGUgdHlwZXMgb2YgdHJhZmZpYyB0aGF0IGNhbiBiZVwK ICAgdHJhY2VkIGJldHdlZW4gdGhlIGJvcmRlcnMgb2YgdGhlIHBhcnRpY2lwYXRpbmcgU1BzIG9m IGVhY2hcCiAgIGNvbnNvcnRpdW0uICBUaGUgdHJhZmZpYyB0cmFjZWQgc2hvdWxkIGJlIGxpbWl0 ZWQgdG8gc2VjdXJpdHktXAogICBpbmNpZGVudC1yZWxhdGVkIHRyYWZmaWMuICBTZWNvbmQsIHRo ZSB0cmFjZXMgcGVybWl0dGVkIHdpdGhpbiBvbmVcCiAgIGNvbnNvcnRpdW0gaWYgcGFzc2VkIHRv IGEgcGVlcmluZyBjb25zb3J0aXVtIG1heSBpbmZyaW5nZSB1cG9uIHRoZVwKICAgcGVlcmluZyBj b25zb3J0aXVtJ3MgZnJlZWRvbSBvZiBpbmZvcm1hdGlvbiBsYXdzLiAgQW4gZXhhbXBsZSB3b3Vs ZFwKICAgYmUgYSBjb25zb3J0aXVtIGluIG9uZSBjb3VudHJ5IHBlcm1pdHRpbmcgYSB0cmFjZSBv ZiB0cmFmZmljXAogICBjb250YWluaW5nIG9iamVjdGlvbmFibGUgbWF0ZXJpYWwsIG91dGxhd2Vk IHdpdGhpbiB0aGF0IGNvdW50cnkuICBUaGVcCiAgIFJJRCB0cmFjZSBtYXkgYmUgYSB2YWxpZCB1 c2Ugb2YgdGhlIHN5c3RlbSB3aXRoaW4gdGhlIGNvbmZpbmVzIG9mXAogICB0aGF0IGNvdW50cnkn cyBuZXR3b3JrIGJvcmRlcjsgaG93ZXZlciwgaXQgbWF5IG5vdCBiZSBwZXJtaXR0ZWQgdG9cCiAg IGNvbnRpbnVlIGFjcm9zcyBuZXR3b3JrIGJvdW5kYXJpZXMgd2hlcmUgc3VjaCBjb250ZW50IGlz IHBlcm1pdHRlZFwKICAgdW5kZXIgbGF3LiAgQnkgY29udGludWluZyB0aGUgdHJhY2UgaW4gYW5v dGhlciBjb3VudHJ5J3MgbmV0d29yaywgdGhlXAogICB0cmFjZSBhbmQgcmVzcG9uc2UgY291bGQg aGF2ZSB0aGUgZWZmZWN0IG9mIGltcHJvcGVybHkgcmVzdHJpY3RpbmdcCiAgIGFjY2VzcyB0byBk YXRhLiAgQSBjb250aW51ZWQgdHJhY2UgaW50byBhIHNlY29uZCBjb3VudHJ5IG1heSBicmVha1wK ICAgdGhlIGxhd3MgYW5kIHJlZ3VsYXRpb25zIG9mIHRoYXQgbmF0aW9uLiAgQW55IHN1Y2ggdHJh Y2VzIE1VU1QgY2Vhc2VcCiAgIGF0IHRoZSBjb3VudHJ5J3MgYm9yZGVyLlwKXAogICBUaGUgcHJp dmFjeSBjb25jZXJucyBsaXN0ZWQgaW4gdGhpcyBzZWN0aW9uIGFkZHJlc3MgaXNzdWVzIGFtb25n IHRoZVwKICAgdHJ1c3RlZCBwYXJ0aWVzIGludm9sdmVkIGluIGEgdHJhY2Ugd2l0aGluIGFuIFNQ LCBhIFJJRCBjb25zb3J0aXVtLFwKICAgYW5kIHBlZXJpbmcgUklEIGNvbnNvcnRpdW1zLiAgRGF0 YSB1c2VkIGZvciBSSUQgY29tbXVuaWNhdGlvbnMgbXVzdFwKICAgYWxzbyBiZSBwcm90ZWN0ZWQg ZnJvbSBwYXJ0aWVzIHRoYXQgYXJlIG5vdCB0cnVzdGVkLiAgVGhpcyBwcm90ZWN0aW9uXAogICBp cyBwcm92aWRlZCB0aHJvdWdoIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiBvZiBk b2N1bWVudHMgYXNcCiAgIHRoZXkgdHJhdmVyc2UgdGhlIHBhdGggb2YgdHJ1c3RlZCBzZXJ2ZXJz LiAgRWFjaCBSSUQgc3lzdGVtIE1VU1RcCiAgIHBlcmZvcm0gYSBiaS1kaXJlY3Rpb25hbCBhdXRo ZW50aWNhdGlvbiB3aGVuIHNlbmRpbmcgYSBSSUQgbWVzc2FnZVwKICAgYW5kIHVzZSB0aGUgcHVi bGljIGVuY3J5cHRpb24ga2V5IG9mIHRoZSB1cHN0cmVhbSBvciBkb3duc3RyZWFtIHBlZXJcClwK XApcCk1vcmlhcnR5ICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDY0XVwKXHBhZ2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgUkZDNjA0NS1iaXMgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICB0byBz ZW5kIGEgbWVzc2FnZSBvciBkb2N1bWVudCBvdmVyIHRoZSBuZXR3b3JrLiAgVGhpcyBtZWFucyB0 aGF0IHRoZVwKICAgZG9jdW1lbnQgaXMgZGVjcnlwdGVkIGFuZCByZS1lbmNyeXB0ZWQgYXQgZWFj aCBSSUQgc3lzdGVtIHZpYSBUTFNcCiAgIG92ZXIgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBbUkZD NjA0Nl0uICBUaGUgUklEIG1lc3NhZ2VzIG1heSBiZVwKICAgZGVjcnlwdGVkIGF0IGVhY2ggUklE IHN5c3RlbSBpbiBvcmRlciB0byBwcm9wZXJseSBwcm9jZXNzIHRoZSByZXF1ZXN0XAogICBvciBy ZWxheSB0aGUgaW5mb3JtYXRpb24uICBUb2RheSdzIHByb2Nlc3NpbmcgcG93ZXIgaXMgbW9yZSB0 aGFuXAogICBzdWZmaWNpZW50IHRvIGhhbmRsZSB0aGUgbWluaW1hbCBidXJkZW4gb2YgZW5jcnlw dGluZyBhbmQgZGVjcnlwdGluZ1wKICAgcmVsYXRpdmVseSBzbWFsbCB0eXBpY2FsIFJJRCBtZXNz YWdlcy5cClwKXAo4LiAgSUFOQSBDb25zaWRlcmF0aW9uc1wKXAogICBUaGlzIGRvY3VtZW50IHVz ZXMgVVJOcyB0byBkZXNjcmliZSBYTUwgbmFtZXNwYWNlcyBhbmQgWE1MIHNjaGVtYXNcCiAgIFtY TUxzY2hlbWFdIGNvbmZvcm1pbmcgdG8gYSByZWdpc3RyeSBtZWNoYW5pc20gZGVzY3JpYmVkIGlu XAogICBbUkZDMzY4OF0uXApcCiAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0IGZvciB0aGUgaW9kZWYt cmlkIG5hbWVzcGFjZTpcClwKICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmlvZGVmLXJp ZC0xLjBcClwKICAgUmVnaXN0cmFudCBDb250YWN0OiBTZWUgdGhlICJBdXRob3IncyBBZGRyZXNz IiBzZWN0aW9uIG9mIHRoaXNcCiAgIGRvY3VtZW50LlwKXAogICBYTUw6IE5vbmUuICBOYW1lc3Bh Y2UgVVJJcyBkbyBub3QgcmVwcmVzZW50IGFuIFhNTCBzcGVjaWZpY2F0aW9uLlwKXAogICBSZWdp c3RyYXRpb24gcmVxdWVzdCBmb3IgdGhlIGlvZGVmLXJpZCBYTUwgc2NoZW1hOlwKXAogICBVUkk6 IHVybjppZXRmOnBhcmFtczp4bWw6c2NoZW1hOmlvZGVmLXJpZC0xLjBcClwKICAgUmVnaXN0cmFu dCBDb250YWN0OiBTZWUgdGhlICJBdXRob3IncyBBZGRyZXNzIiBzZWN0aW9uIG9mIHRoaXNcCiAg IGRvY3VtZW50LlwKXAogICBYTUw6IFNlZSBTZWN0aW9uIDUsICJSSUQgU2NoZW1hIERlZmluaXRp b24iLCBvZiB0aGlzIGRvY3VtZW50LlwKXApcCjkuICBTdW1tYXJ5XApcCiAgIFNlY3VyaXR5IGlu Y2lkZW50cyBoYXZlIGFsd2F5cyBiZWVuIGRpZmZpY3VsdCB0byB0cmFjZSBhcyBhIHJlc3VsdCBv ZlwKICAgdGhlIHNwb29mZWQgc291cmNlcywgcmVzb3VyY2UgbGltaXRhdGlvbnMsIGFuZCBiYW5k d2lkdGggdXRpbGl6YXRpb25cCiAgIHByb2JsZW1zLiAgSW5jaWRlbnQgcmVzcG9uc2UgaXMgb2Z0 ZW4gc2xvdyBldmVuIHdoZW4gdGhlIElQIGFkZHJlc3NcCiAgIGlzIGtub3duIHRvIGJlIHZhbGlk IGJlY2F1c2Ugb2YgdGhlIHJlc291cmNlcyByZXF1aXJlZCB0byBub3RpZnkgdGhlXAogICByZXNw b25zaWJsZSBwYXJ0eSBvZiB0aGUgYXR0YWNrIGFuZCB0aGVuIHRvIHN0b3Agb3IgbWl0aWdhdGUg dGhlXAogICBhdHRhY2sgdHJhZmZpYy4gIE1ldGhvZHMgdG8gaWRlbnRpZnkgYW5kIHRyYWNlIGF0 dGFja3MgbmVhciByZWFsIHRpbWVcCiAgIGFyZSBlc3NlbnRpYWwgdG8gdGh3YXJ0aW5nIGF0dGFj ayBhdHRlbXB0cy4gIE5ldHdvcmsgcHJvdmlkZXJzIG5lZWRcCiAgIHBvbGljaWVzIGFuZCBhdXRv bWF0ZWQgbWV0aG9kcyB0byBjb21iYXQgdGhlIGhhY2tlcidzIGVmZm9ydHMuICBTUHNcCiAgIG5l ZWQgYXV0b21hdGVkIG1vbml0b3JpbmcgYW5kIHJlc3BvbnNlIGNhcGFiaWxpdGllcyB0byBpZGVu dGlmeSBhbmRcCiAgIHRyYWNlIGF0dGFja3MgcXVpY2tseSB3aXRob3V0IHJlc291cmNlLWludGVu c2l2ZSBzaWRlIGVmZmVjdHMuXAogICBJbnRlZ3JhdGlvbiB3aXRoIGEgY2VudHJhbGl6ZWQgY29t bXVuaWNhdGlvbiBzeXN0ZW0gdG8gY29vcmRpbmF0ZSB0aGVcCiAgIGRldGVjdGlvbiwgdHJhY2lu ZywgYW5kIGlkZW50aWZpY2F0aW9uIG9mIGF0dGFjayBzb3VyY2VzIG9uIGEgc2luZ2xlXApcClwK XApNb3JpYXJ0eSAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI2LCAyMDEyICAgICAg ICAgICAgICBbUGFnZSA2NV1cClxwYWdlIFwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg IFJGQzYwNDUtYmlzICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDExXApcClwKICAgbmV0d29y ayBpcyBlc3NlbnRpYWwuICBSSUQgcHJvdmlkZXMgYSB3YXkgdG8gaW50ZWdyYXRlIFNQIHJlc291 cmNlc1wKICAgZm9yIGVhY2ggYXNwZWN0IG9mIGF0dGFjayBkZXRlY3Rpb24sIHRyYWNpbmcsIGFu ZCBzb3VyY2VcCiAgIGlkZW50aWZpY2F0aW9uIGFuZCBleHRlbmRzIHRoZSBjb21tdW5pY2F0aW9u IGNhcGFiaWxpdGllcyBhbW9uZ1wKICAgbmV0d29yayBwcm92aWRlcnMuICBUaGUgY29tbXVuaWNh dGlvbiBpcyBhY2NvbXBsaXNoZWQgdGhyb3VnaCB0aGUgdXNlXAogICBvZiBmbGV4aWJsZSBJT0RF RiBYTUwtYmFzZWQgZG9jdW1lbnRzIHBhc3NlZCBiZXR3ZWVuIElIU3Mgb3IgUklEXAogICBzeXN0 ZW1zLiAgQSBUcmFjZVJlcXVlc3Qgb3IgSW52ZXN0aWdhdGlvbiByZXF1ZXN0IGlzIGNvbW11bmlj YXRlZCB0b1wKICAgYW4gdXBzdHJlYW0gU1AgYW5kIG1heSByZXN1bHQgaW4gYW4gdXBzdHJlYW0g dHJhY2Ugb3IgaW4gYW4gYWN0aW9uIHRvXAogICBzdG9wIG9yIG1pdGlnYXRlIHRoZSBhdHRhY2sg dHJhZmZpYy4gIFRoZSBtZXNzYWdlcyBhcmUgY29tbXVuaWNhdGVkXAogICBhbW9uZyBwZWVycyB3 aXRoIHNlY3VyaXR5IGluaGVyZW50IHRvIHRoZSBSSUQgbWVzc2FnaW5nIHNjaGVtZVwKICAgcHJv dmlkZWQgdGhyb3VnaCBleGlzdGluZyBzdGFuZGFyZHMgc3VjaCBhcyBYTUwgZW5jcnlwdGlvbiBh bmRcCiAgIGRpZ2l0YWwgc2lnbmF0dXJlcy4gIFBvbGljeSBpbmZvcm1hdGlvbiBpcyBjYXJyaWVk IGluIHRoZSBSSUQgbWVzc2FnZVwKICAgaXRzZWxmIHRocm91Z2ggdGhlIHVzZSBvZiB0aGUgUklE UG9saWN5LiAgUklEIHByb3ZpZGVzIHRoZSB0aW1lbHlcCiAgIGNvbW11bmljYXRpb24gYW1vbmcg U1BzLCB3aGljaCBpcyBlc3NlbnRpYWwgZm9yIGluY2lkZW50IGhhbmRsaW5nLlwKXApcCjEwLiAg UmVmZXJlbmNlc1wKXAoxMC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXNcClwKICAgW1JGQzIxMTld ICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGVcCiAg ICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2gg MTk5Ny5cClwKICAgW1JGQzI1ODVdICBIb3VzbGV5LCBSLiBhbmQgUC4gSG9mZm1hbiwgIkludGVy bmV0IFguNTA5IFB1YmxpYyBLZXlcCiAgICAgICAgICAgICAgSW5mcmFzdHJ1Y3R1cmUgT3BlcmF0 aW9uYWwgUHJvdG9jb2xzOiBGVFAgYW5kIEhUVFAiLFwKICAgICAgICAgICAgICBSRkMgMjU4NSwg TWF5IDE5OTkuXApcCiAgIFtSRkMzMjc1XSAgRWFzdGxha2UsIEQuLCBSZWFnbGUsIEouLCBhbmQg RC4gU29sbywgIihFeHRlbnNpYmxlIE1hcmt1cFwKICAgICAgICAgICAgICBMYW5ndWFnZSkgWE1M LVNpZ25hdHVyZSBTeW50YXggYW5kIFByb2Nlc3NpbmciLCBSRkMgMzI3NSxcCiAgICAgICAgICAg ICAgTWFyY2ggMjAwMi5cClwKICAgW1JGQzM2ODhdICBNZWFsbGluZywgTS4sICJUaGUgSUVURiBY TUwgUmVnaXN0cnkiLCBCQ1AgODEsIFJGQyAzNjg4LFwKICAgICAgICAgICAgICBKYW51YXJ5IDIw MDQuXApcCiAgIFtSRkM0Mjc5XSAgRXJvbmVuLCBQLiBhbmQgSC4gVHNjaG9mZW5pZywgIlByZS1T aGFyZWQgS2V5IENpcGhlcnN1aXRlc1wKICAgICAgICAgICAgICBmb3IgVHJhbnNwb3J0IExheWVy IFNlY3VyaXR5IChUTFMpIiwgUkZDIDQyNzksXAogICAgICAgICAgICAgIERlY2VtYmVyIDIwMDUu XApcCiAgIFtSRkM1MDcwXSAgRGFueWxpdywgUi4sIE1laWplciwgSi4sIGFuZCBZLiBEZW1jaGVu a28sICJUaGUgSW5jaWRlbnRcCiAgICAgICAgICAgICAgT2JqZWN0IERlc2NyaXB0aW9uIEV4Y2hh bmdlIEZvcm1hdCIsIFJGQyA1MDcwLFwKICAgICAgICAgICAgICBEZWNlbWJlciAyMDA3LlwKXAog ICBbUkZDNTI3NV0gIFR1cm5lciwgUy4sICJDTVMgU3ltbWV0cmljIEtleSBNYW5hZ2VtZW50IGFu ZFwKICAgICAgICAgICAgICBEaXN0cmlidXRpb24iLCBSRkMgNTI3NSwgSnVuZSAyMDA4LlwKXAog ICBbUkZDNTI4MF0gIENvb3BlciwgRC4sIFNhbnRlc3NvbiwgUy4sIEZhcnJlbGwsIFMuLCBCb2V5 ZW4sIFMuLFwKICAgICAgICAgICAgICBIb3VzbGV5LCBSLiwgYW5kIFcuIFBvbGssICJJbnRlcm5l dCBYLjUwOSBQdWJsaWMgS2V5XAogICAgICAgICAgICAgIEluZnJhc3RydWN0dXJlIENlcnRpZmlj YXRlIGFuZCBDZXJ0aWZpY2F0ZSBSZXZvY2F0aW9uIExpc3RcCiAgICAgICAgICAgICAgKENSTCkg UHJvZmlsZSIsIFJGQyA1MjgwLCBNYXkgMjAwOC5cClwKXApcCk1vcmlhcnR5ICAgICAgICAgICAg ICAgIEV4cGlyZXMgRmVicnVhcnkgMjYsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDY2XVwKXHBh Z2UgXApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgUkZDNjA0NS1iaXMgICAgICAgICAg ICAgICAgICAgQXVndXN0IDIwMTFcClwKXAogICBbUkZDNTc1NV0gIEZhcnJlbGwsIFMuLCBIb3Vz bGV5LCBSLiwgYW5kIFMuIFR1cm5lciwgIkFuIEludGVybmV0XAogICAgICAgICAgICAgIEF0dHJp YnV0ZSBDZXJ0aWZpY2F0ZSBQcm9maWxlIGZvciBBdXRob3JpemF0aW9uIixcCiAgICAgICAgICAg ICAgUkZDIDU3NTUsIEphbnVhcnkgMjAxMC5cClwKICAgW1JGQzYwNDVdICBNb3JpYXJ0eSwgSy4s ICJSZWFsLXRpbWUgSW50ZXItbmV0d29yayBEZWZlbnNlIChSSUQpIixcCiAgICAgICAgICAgICAg UkZDIDYwNDUsIE5vdmVtYmVyIDIwMTAuXApcCiAgIFtSRkM2MDQ2XSAgTW9yaWFydHksIEsuIGFu ZCBCLiBUcmFtbWVsbCwgIlRyYW5zcG9ydCBvZiBSZWFsLXRpbWVcCiAgICAgICAgICAgICAgSW50 ZXItbmV0d29yayBEZWZlbnNlIChSSUQpIE1lc3NhZ2VzIiwgUkZDIDYwNDYsXAogICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMTAuXApcCjEwLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzXApcCiAg IFtSRkMxOTMwXSAgSGF3a2luc29uLCBKLiBhbmQgVC4gQmF0ZXMsICJHdWlkZWxpbmVzIGZvciBj cmVhdGlvbixcCiAgICAgICAgICAgICAgc2VsZWN0aW9uLCBhbmQgcmVnaXN0cmF0aW9uIG9mIGFu IEF1dG9ub21vdXMgU3lzdGVtIChBUykiLFwKICAgICAgICAgICAgICBCQ1AgNiwgUkZDIDE5MzAs IE1hcmNoIDE5OTYuXApcCiAgIFtSRkMyODI3XSAgRmVyZ3Vzb24sIFAuIGFuZCBELiBTZW5pZSwg Ik5ldHdvcmsgSW5ncmVzcyBGaWx0ZXJpbmc6XAogICAgICAgICAgICAgIERlZmVhdGluZyBEZW5p YWwgb2YgU2VydmljZSBBdHRhY2tzIHdoaWNoIGVtcGxveSBJUCBTb3VyY2VcCiAgICAgICAgICAg ICAgQWRkcmVzcyBTcG9vZmluZyIsIEJDUCAzOCwgUkZDIDI4MjcsIE1heSAyMDAwLlwKXAogICBb UkZDMzY0N10gIENob2toYW5pLCBTLiwgRm9yZCwgVy4sIFNhYmV0dCwgUi4sIE1lcnJpbGwsIEMu LCBhbmQgUy5cCiAgICAgICAgICAgICAgV3UsICJJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5IElu ZnJhc3RydWN0dXJlIENlcnRpZmljYXRlXAogICAgICAgICAgICAgIFBvbGljeSBhbmQgQ2VydGlm aWNhdGlvbiBQcmFjdGljZXMgRnJhbWV3b3JrIiwgUkZDIDM2NDcsXAogICAgICAgICAgICAgIE5v dmVtYmVyIDIwMDMuXApcCiAgIFtSRkMzOTE3XSAgUXVpdHRlaywgSi4sIFpzZWJ5LCBULiwgQ2xh aXNlLCBCLiwgYW5kIFMuIFphbmRlcixcCiAgICAgICAgICAgICAgIlJlcXVpcmVtZW50cyBmb3Ig SVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKSIsXAogICAgICAgICAgICAgIFJGQyAz OTE3LCBPY3RvYmVyIDIwMDQuXApcCiAgIFtSRkM1NzM1XSAgQ290dG9uLCBNLiBhbmQgTC4gVmVn b2RhLCAiU3BlY2lhbCBVc2UgSVB2NCBBZGRyZXNzZXMiLFwKICAgICAgICAgICAgICBCQ1AgMTUz LCBSRkMgNTczNSwgSmFudWFyeSAyMDEwLlwKXAogICBBY2tub3dsZWRnZW1lbnRzXApcCiAgIE1h bnkgdGhhbmtzIHRvIGNvd29ya2VycyBhbmQgdGhlIEludGVybmV0IGNvbW11bml0eSBmb3IgcmV2 aWV3aW5nIGFuZFwKICAgY29tbWVudGluZyBvbiB0aGUgZG9jdW1lbnQgYXMgd2VsbCBhcyBwcm92 aWRpbmcgcmVjb21tZW5kYXRpb25zIHRvXAogICBzaW1wbGlmeSBhbmQgc2VjdXJlIHRoZSBwcm90 b2NvbDogUm9iZXJ0IEsuIEN1bm5pbmdoYW0sIFBoLkQsIEN5bnRoaWFcCiAgIEQuIE1jTGFpbiwg RHIuIFdpbGxpYW0gU3RyZWlsZWluLCBJbGppdHNjaCB2YW4gQmVpam51bSwgU3RldmVcCiAgIEJl bGxvdmluLCBZdXJpIERlbWNoZW5rbywgSmVhbi1GcmFuY29pcyBNb3JmaW4sIFN0ZXBoZW4gTm9y dGhjdXR0LFwKICAgSmVmZnJleSBTY2hpbGxlciwgQnJpYW4gVHJhbW1lbGwsIFJvbWFuIERhbnls aXcsIFRvbnkgVGF1YmVyLCBTYW5kcmFcCiAgIEcuIER5a2VzLCBQaC5ELiwgS2F0aGVyaW5lIEdv b2RpZXIsIFBoLkQuLCBUb255IFJ1dGtvd3NraSwgRGFtaXJcCiAgIFJham5vdmljLCBhbmQgRGF2 aWQgQmxhY2suXApcClwKXApcClwKXApcClwKTW9yaWFydHkgICAgICAgICAgICAgICAgRXhwaXJl cyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjddXApccGFnZSBcCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICBSRkM2MDQ1LWJpcyAgICAgICAgICAgICAgICAgICBB dWd1c3QgMjAxMVwKXApcCkF1dGhvcidzIEFkZHJlc3NcClwKICAgS2F0aGxlZW4gTS4gTW9yaWFy dHlcCiAgIEVNQyBDb3Jwb3JhdGlvblwKICAgMTc2IFNvdXRoIFN0cmVldFwKICAgSG9wa2ludG9u LCBNQVwKICAgVW5pdGVkIFN0YXRlc1wKXAogICBQaG9uZTpcCiAgIEVtYWlsOiBLYXRobGVlbi5N b3JpYXJ0eUBlbWMuY29tXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwK XApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKXApcClwKTW9yaWFydHkgICAgICAg ICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNiwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjhd XApccGFnZSB9 --_002_AE31510960917D478171C79369B660FA0E051CE82EMX06Acorpemcc_-- From kathleen.moriarty@emc.com Fri Aug 26 02:12:00 2011 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 53CC921F8B22 for ; Fri, 26 Aug 2011 02:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siN3FvfscHrX for ; Fri, 26 Aug 2011 02:11:56 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 153C921F8A55 for ; Fri, 26 Aug 2011 02:11:55 -0700 (PDT) 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 p7Q9D9mE014560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2011 05:13:09 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 26 Aug 2011 05:13:03 -0400 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 p7Q9D2rr021981; Fri, 26 Aug 2011 05:13:03 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Fri, 26 Aug 2011 05:13:02 -0400 From: To: , , Date: Fri, 26 Aug 2011 05:13:00 -0400 Thread-Topic: [mile] draft on IODEF extension to support structured cybersecurity information Thread-Index: AcxiOgPZ2GuGQRFeRi2mjxtzZ0AnrAAJAaGwAFwEJX8= Message-ID: References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <013601cc6235$3196b1d0$94c41570$@nict.go.jp> <510A8D02-449C-43C3-9D60-2F25C16BC277@tik.ee.ethz.ch> <018f01cc6238$e6fa0f60$b4ee2e20$@nict.go.jp> <5D14417A-40EE-4865-81B5-2D6A10EDCC85@tik.ee.ethz.ch>, <7C4DFCE962635144B8FAE8CA11D0BF1E05896729AD@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05896729AD@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] draft on IODEF extension to support structured cybersecurity information 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, 26 Aug 2011 09:12:00 -0000 Hello David, I would like to clarify your request, so please let me know if the followin= g would satisfy the request. 1. SCAP and some of the other referenced schemas are maintained outside of = the IETF currently, so namespaces and schemas are defined elsewhere. IANA = maintains a registry of XML schemas referenced by IETF documents (SCAP and = other XML schemas are referenced from the proposed IODEF extension fit into= this group). 2. IANA also registers identifiers that are allocated in IETF-controlled UR= I space (IODEF and IODEF extensions fit into this group). Are you asking for each of the referenced schemes to be registered as descr= ibed by #1 and then following the template, Take will register the IODEF ex= tension following #2 following the guidance in RFC3688? The IANA registrat= ion requests are all handled in the IANA Considerations section of a draft. Registered schemas: http://www.iana.org/assignments/xml-registry/ns.html Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of david.blac= k@emc.com [david.black@emc.com] Sent: Wednesday, August 24, 2011 9:08 AM To: trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp Cc: mile@ietf.org Subject: Re: [mile] draft on IODEF extension to support structured cyb= ersecurity information I also prefer option 1. Returning to Brian's earlier comment: > In general, I agree: representing embedded information by ENUM as opposed= to by > freeform string is much preferable. However, if the embedded information = is itself > described by an XML Schema, then it may make sense to differentiate the e= mbedded > AdditionalData content not with a new ENUM, but rather by the namespace u= sed by > that schema. You still run into the subordinate namespace versioning prob= lem, > but this is now the job of the creator of the subordinate namespace to do > correctly, which I would assume is the case for the SCAP use case. I'm ok with SpecificationName being an XML namespace reference rather than = an ENUM (both work for me), but I still think the IANA registry of allowed XML name= space references is needed, so that a recipient can prepare in advance for what m= ight be coming. This avoids having to go fetch an XML schema in the middle of inci= dent handling and allows verification in advance that the recipient's automated = tooling can handle the content. Thanks, --David > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Wednesday, August 24, 2011 4:44 AM > To: Takeshi Takahashi > Cc: Black, David; mile@ietf.org > Subject: Re: [mile] draft on IODEF extension to support structured cybers= ecurity information > > Hi, Take, > > I prefer option 1 as well... > > (This would additionally appear to resolve my previous question.) > > Cheers, > > Brian > > On Aug 24, 2011, at 10:36 AM, Takeshi Takahashi wrote: > > > Hi Brian, > > > > I like the 1st option you kindly raised here. > > I appreciate your assistance. > > > > Let me update the text and come back to the list soon. > > (I will make sure all the comments I've received in this list should be > > reflected.) > > > > Best Regards, > > Take > > > > > > -----Original Message----- > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > Sent: Wednesday, August 24, 2011 10:17 AM > > To: Takeshi Takahashi > > Cc: david.black@emc.com; mile@ietf.org > > Subject: Re: [mile] draft on IODEF extension to support structured > > cybersecurity information > > > > Hi, Take, > > > > To my understanding, there are two possible answers to this last questi= on, > > each with their own disadvantages: > > > > 1. The SpecificationName and SpecificationVersion are present and requi= red, > > and MUST match any version information carried by the enclosed XML name= space > > and schema. This gives you a nice envelope for determining which versio= n of > > the extension you're using, but can lead to inconsistency if improperly > > used. It is unclear what a reader should do when an inconsistency is > > detected. In line with common practice in protocol design (send > > conservatively, accept liberally), I would suggest "writers/senders MUS= T > > ensure the SpecificationName and SpecificationVersion are consistent wi= th > > the contents; if a reader/receiver detects an inconsistency, it SHOULD > > prefer the specification and version derived from the content, and SHOU= LD > > log the inconsistency so a human can correct the problem." But it shoul= d be > > addressed in any case. > > > > 2. The SpecificationName and SpecificationVersion are only present when= that > > information is not derivable from the enclosed XML namespace and schema= . > > This is ugly, because it introduces two ways of doing the same thing... > > > > Best regards, > > > > Brian > > > > On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote: > > > >> Hi David, > >> > >> Thanks for your email. > >> > >> 1) > >>>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > >>>> possible > >> specifications. > >>>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > >>>> ENUM for dtype and FraudType description. > >>> > >>> That sounds like a good approach - each RFC that registers a value > >>> for the > >> ENUM should include a pointer to the XML Schema for that specification > >> as part of making the registration with IANA (the IANA registry entry > >> will reference the RFC for the details). This may help recipients > >> ensure that they have local copies of the XML schemas necessary to > >> parse expected content. > >> > >> Thank you for telling me the IANA issue. I appreciate that. > >> > >> 2) > >>>> So, my assumption here is that a complete CVE (compatible with its > >>>> schema) will be embedded here. > >>> > >>> I don't have a problem with that assumption, but think it should be > >>> stated > >> because that conclusion is not obvious [well, at least not to me ;-) > >> ]. It should be sufficient to state that the embedded element is a > >> complete XML document that is formatted according to the schema > >> referenced by the IANA registration of the ENUM value used for > > SpecificationName (see item 1). > >> > >> I see. I will. Thank you. > >> > >>> My concern is similar to item 1) - how does the recipient parse and > >>> check > >> the version number? > >>> The rules for this need to be precise, otherwise there may be > >>> unexpected > >> string compare results. It'd be good if the version number could be > >> extracted from the XML Schema for the embedded content (and hence > >>> take advantage of the rules in the referenced specification for the > >> syntax of [Specification]Version). > >>> > >>> A simple (silly) example of what can go wrong is that OVAL is > >>> currently at > >> version 5.10 - that's not the same as 5.1, but if it's converted to a > >> number, the result is easy to misparse it as being equivalent to 5.1 ;= -). > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if t= he > > '.' > >> causes problems in some tooling? All of these are easy for a human to > >> sort out, but potential causes of problems in automated tools. > >> > >> Yes, I agree. > >> To clarify this issue, I'll add a sentence "parsers are expected to > >> read the namespace of the embedded structured information and identify > >> specification name and data, whenever such information is available, > >> and parse the embedded data." > >> > >> Then one potential question we might have is, do we need the > >> SpecificationName and SpecificationVersion elements? > >> If the namespace described in the embedded structured information > >> identify the specification name and its version, one might think these > >> elements are useless. > >> However, in my opinion, we still need these elements since some of the > >> embedded information could be non-xml in the future. > >> > >> Thank you. > >> > >> Take > >> > >> -----Original Message----- > >> From: david.black@emc.com [mailto:david.black@emc.com] > >> Sent: Tuesday, August 16, 2011 10:15 AM > >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > >> Subject: RE: [mile] draft on IODEF extension to support structured > >> cybersecurity information > >> > >> Hi Take, > >> > >> Enjoy your vacation, here are some comments to look at when you return= : > >> > >> 1) > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > >>> possible > >> specifications. > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > >>> ENUM for dtype and FraudType description. > >> > >> That sounds like a good approach - each RFC that registers a value for > >> the ENUM should include a pointer to the XML Schema for that > >> specification as part of making the registration with IANA (the IANA > >> registry entry will reference the RFC for the details). This may help > >> recipients ensure that they have local copies of the XML schemas > >> necessary to parse expected content. > >> > >> 2) > >>> So, my assumption here is that a complete CVE (compatible with its > >>> schema) will be embedded here. > >> > >> I don't have a problem with that assumption, but think it should be > >> stated because that conclusion is not obvious [well, at least not to > >> me ;-) ]. It should be sufficient to state that the embedded element > >> is a complete XML document that is formatted according to the schema > >> referenced by the IANA registration of the ENUM value used for > > SpecificationName (see item 1). > >> > >>> 3) > >>> Maybe some text in the draft has caused mis-understanding. > >>> Yes, the latest version of the XCCDF schema is 1.6. > >>> I intended to say that the number of the version element is zero or o= ne. > >>> Most of specifications such as XCCDF etc. have versions while CVE > >>> does > >> not. > >>> Thus the number of this element class is ZERO or ONE. > >> > >> I misread what you wrote, sorry about that. I was looking for the > >> syntax of the contents of the [Specification]Version element, and > >> looked in the wrong place. > >> > >> My concern is similar to item 1) - how does the recipient parse and > >> check the version number? > >> The rules for this need to be precise, otherwise there may be > >> unexpected string compare results. It'd be good if the version number > >> could be extracted from the XML Schema for the embedded content (and > >> hence take advantage of the rules in the referenced specification for > >> the syntax of [Specification]Version). > >> > >> A simple (silly) example of what can go wrong is that OVAL is > >> currently at version 5.10 - that's not the same as 5.1, but if it's > >> converted to a number, the result is easy to misparse it as being > > equivalent to 5.1 ;-). > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if t= he > > '.' > >> causes problems in some tooling? All of these are easy for a human to > >> sort out, but potential causes of problems in automated tools. > >> > >> Thanks, > >> --David > >> > >>> -----Original Message----- > >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > >>> Sent: Sunday, August 14, 2011 9:25 AM > >>> To: Black, David; mile@ietf.org > >>> Subject: RE: [mile] draft on IODEF exstension to support structured > >>> cybersecurity information > >>> > >>> Hi David, > >>> > >>> Thank you for your kind comments. > >>> I agree, I'll change the element class name. > >>> > >>> Regarding the issues you kindly raised in the email, let me describe > >>> my understanding. > >>> > >>> 1) > >>> My assumption was, when parsing the xml data, the parser anyway reads > >>> the namespace described in the embedded xml data and parse the data. > >>> But I agree, it would be better to limit the description of > >>> SpecificationName. > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > >>> possible specifications. > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > >>> ENUM for dtype and FraudType description. > >>> Like the same way, the SpecificationName could use ENUM for > >>> describing specifications, though we do not have that much > >>> specifications to enumerate at this moment. > >>> > >>> 2) > >>> I am not sure whether it is easier for information sender and > >>> receiver to send/receive partial CVE data. > >>> Maybe it would be easier for them to embed/receive/parse a complete > >>> CVE data? > >>> If we send a partial CVE or the other structured data, receiver may > >>> suffer from some parsing problem, as you mentioned. > >>> So, my assumption here is that a complete CVE (compatible with its > >>> schema) will be embedded here. > >>> > >>> 3) > >>> Maybe some text in the draft has caused mis-understanding. > >>> Yes, the latest version of the XCCDF schema is 1.6. > >>> I intended to say that the number of the version element is zero or o= ne. > >>> Most of specifications such as XCCDF etc. have versions while CVE > >>> does > >> not. > >>> Thus the number of this element class is ZERO or ONE. > >>> > >>> Above are my viewpoint, but I might be wrong. > >>> Let me develop the draft based on your kind comments after my vacatio= n. > >>> Please correct me if I am wrong, I would like to welcome feedbacks. > >>> > >>> Thank you. > >>> > >>> Take > >>> > >>> > >>> From: david.black@emc.com [mailto:david.black@emc.com] > >>> Sent: Wednesday, August 10, 2011 8:45 AM > >>> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > >>> Cc: david.black@emc.com > >>> Subject: RE: [mile] draft on IODEF exstension to support structured > >>> cybersecurity information > >>> > >>> Hi Take, > >>> > >>> For clarity I'd suggest not using "Version" as the name of both an > >>> extension attribute and one of the classes in each extension. > >>> Renaming the class to SpecificationVersion would be clearer (so > >>> Version is the attribute with the version of the extension). > >>> > >>> I also have a few questions: > >>> > >>> (1) What strings are valid for SpecificationName? If the recipient > >>> doesn't understand the SpecificationName, the information in the > >>> extension may be unparseable, so this probably needs to be controlled= . > >>> > >>> An IANA registry may be appropriate to list the valid strings and > >>> associate each string with its corresponding specification. > >>> > >>> (2) How does one determine the format for information formatted > >>> according to an external specification? > >>> > >>> For example, I believe that the XSD schema for the CVE list defines a > >>> complete XML document, but I suspect that less than a complete XML > >>> document is intended to be embedded because the proposed extension is > >>> part of an IODEF XML document. > >>> > >>> (3) Why is the [Specification]Version limited to zero or one? > >>> > >>> For example, CAPEC is currently at Release 1.6. > >>> > >>> 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 > >>> ---------------------------------------------------- > >>> > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > >>> Of Takeshi Takahashi > >>> Sent: Monday, August 08, 2011 11:50 PM > >>> To: mile@ietf.org > >>> Subject: Re: [mile] draft on IODEF exstension to support structured > >>> cybersecurity information > >>> > >>> Thank you for those of you who kindly gave me off-line messages . > >>> > >>> Let me share the draft with some minor modifications. > >>> > >>> Sincerely, > >>> Take > >>> > >>> > >>> 2011/8/5 Takeshi Takahashi : > >>>> Dear all, > >>>> > >>>> > >>>> > >>>> The attached is the tentative version of the draft prepared based on > >>>> the comments I've received in this mailing list (Thanks a lot for th= at). > >>>> > >>>> It would be great if you could provide some comments on Clause 4, > >>>> where > >>> the > >>>> IODEF extension is defined. > >>>> > >>>> > >>>> > >>>> As you know, there are many ways to embed structured information > >>>> (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very > >> flexible. > >>>> > >>>> Thus, I would be happy to change and develop the draft further based > >>>> on > >>> your > >>>> comments. > >>>> > >>>> > >>>> > >>>> I would like to welcome any comments on that. > >>>> > >>>> > >>>> > >>>> By the way, I will be on vacation, thus my response might be slow, > >>>> sorry > >>> for > >>>> the inconvenience. > >>>> > >>>> > >>>> > >>>> Take > >>>> > >>>> > >>>> > >>>> PS: I've changed the title of the email. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2011/7/29 > >>>> > >>>>> > >>>> > >>>>> Thank you, the approach sounds good, especially since it is in use > >>>>> today > >>>> > >>>>> by at least the Research and Education ISAC. Do others have > >>>>> opinions on > >>>> > >>>>> the proposal here? > >>>> > >>>>> > >>>> > >>>>> Thanks for writing the first draft Take! > >>>> > >>>>> > >>>> > >>>>> Best regards, > >>>> > >>>>> Kathleen > >>>> > >>>>> ________________________________________ > >>>> > >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > >>>>> Takeshi > >>>> > >>>>> Takahashi [takeshi_takahashi@nict.go.jp] > >>>> > >>>>> Sent: Friday, July 29, 2011 9:20 AM > >>>> > >>>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > >>>> > >>>>> Cc: mile@ietf.org > >>>> > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>> > >>>> > >>>>> Thank you, Bob, for the email. > >>>> > >>>>> I also like Tom's suggestion very much. > >>>> > >>>>> Let me work on the "draft" of the draft for a while, then come back > >>>>> to > >>> you > >>>> > >>>>> later. > >>>> > >>>>> > >>>> > >>>>> Take > >>>> > >>>>> > >>>> > >>>>> -----Original Message----- > >>>> > >>>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] > >>>> > >>>>> Sent: Friday, July 29, 2011 9:10 AM > >>>> > >>>>> To: Kent_Landfield@McAfee.com > >>>> > >>>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > >>>> > >>>>> wes@ren-isac.net; mile@ietf.org > >>>> > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>> > >>>> > >>>>> I also like how this is evolving. > >>>> > >>>>> > >>>> > >>>>> I think, as Tom's suggestions pointed, that any and all of the > >>>>> useful > >>>> > >>>>> types > >>>> > >>>>> of information that can help with understanding, diagnosing, and > >>>>> getting > >>>> > >>>>> ahead of an incident should be added but for now we should focus on > >>>>> those > >>>> > >>>>> the most established and well articulated. > >>>> > >>>>> > >>>> > >>>>> This can be the compliance/patch/configuration/platform information > >>>> > >>>>> related > >>>> > >>>>> to the SCAP use case, or event signature/attack pattern/traffic > >>>> > >>>>> characteristics from events, or the vulnerability/threat > >>>>> characterization > >>>> > >>>>> space. > >>>> > >>>>> > >>>> > >>>>> I look forward to Taki's draft to see how he suggests positioning > >>>>> these > >>>> > >>>>> concepts. > >>>> > >>>>> > >>>> > >>>>> Bob > >>>> > >>>>> > >>>> > >>>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > >>>> > >>>>>> I like where this is headed. > >>>> > >>>>>> > >>>> > >>>>>> Thanks Takeshi. I look forward to your draft. It will give us > >>> something > >>>> > >>>>> real to discuss. I appreciate you jumping in and getting this start= ed. > >>>> > >>>>>> > >>>> > >>>>>> One question that I am not clear on. What do we envision as the > >>>>>> actual > >>>> > >>>>> set > >>>> > >>>>> of deliverables? From and SCAP related perspective, are we looking > >>>>> at a > >>>> > >>>>> single draft covering all the extensions? > >>>> > >>>>>> > >>>> > >>>>>> Kent > >>>> > >>>>>> > >>>> > >>>>>> Kent Landfield > >>>> > >>>>>> Director Content Strategy, Architecture and Standards > >>>> > >>>>>> > >>>> > >>>>>> McAfee, Inc. > >>>> > >>>>>> 5000 Headquarters Dr. > >>>> > >>>>>> Plano, Texas 75024 > >>>> > >>>>>> > >>>> > >>>>>> Direct: +1.972.963.7096 > >>>> > >>>>>> Mobile: +1.817.637.8026 > >>>> > >>>>>> Web: www.mcafee.com > >>>> > >>>>>> > >>>> > >>>>>> From: Takeshi > >>>> > >>>>>> Takahashi >>>>>> ict.g > >>>> > >>>>>> o.jp>> > >>>> > >>>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 > >>>> > >>>>>> To: > >>>> > >>>>>> "Thomas.Millar@us-cert.gov" >>>>>> mas.M > >>>> > >>>>>> illar@us-cert.gov>, > >>>> > >>>>>> "wes@ren-isac.net" >>>>>> to:we > >>>> > >>>>>> s@ren-isac.net>>, > >>>> > >>>>>> "mile@ietf.org" >>>>>> etf.o > >>>> > >>>>>> rg>> > >>>> > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>>> > >>>> > >>>>>> Thank you for the email, Tom. > >>>> > >>>>>> > >>>> > >>>>>> So, here is what the draft needs to describe (if I understand Wes > >>>>>> and > >>>> > >>>>>> Tom correctly). > >>>> > >>>>>> > >>>> > >>>>>> The draft should define ext-dtype (an attribute of AdditionalData > >>>> > >>>>>> Class) to identify the information type, rather than defining new > >>>> > >>>>>> class under AdditionalData. > >>>> > >>>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, > >>>>>> ext-capec, > >>>> > >>>>>> ext-cvss, ext-cwss, In this way, we could keep the change minimal > >>>>>> and > >>>> > >>>>>> could easily embed various structured information (CVE etc.) in > >>>>>> the > >>>> > >>>>>> EventData.Record.RecordData.AdditionalData field. > >>>> > >>>>>> Then "should" statement should be carefully placed in the text of > >>>> > >>>>>> relevant class. > >>>> > >>>>>> > >>>> > >>>>>> I'll prepare some draft so that we could discuss and advance furth= er. > >>>> > >>>>>> > >>>> > >>>>>> Take > >>>> > >>>>>> > >>>> > >>>>>> > >>>> > >>>>>> > >>>> > >>>>>> -----Original Message----- > >>>> > >>>>>> From: mile-bounces@ietf.org > >>>> > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of > >>>> > >>>>>> Thomas.Millar@us-cert.gov > >>>> > >>>>>> Sent: Thursday, July 28, 2011 6:28 PM > >>>> > >>>>>> To: wes@ren-isac.net; > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>>> > >>>> > >>>>>> I think this approach makes more sense. One of the things I think > >>>> > >>>>>> could be helpful is to have a number of SHOULD statements further > >>>> > >>>>>> describing the possible types of other documents that would be > >>>> > >>>>>> expected to ride under the AdditionalData elements of each class > >>>>>> (not > >>>> > >>>>> just > >>>> > >>>>> EventData). > >>>> > >>>>>> What I'm thinking of looks like this (very unpolished): > >>>> > >>>>>> > >>>> > >>>>>> "The Method Class:AdditionalData class SHOULD contain data > >>>>>> elements > >>>> > >>>>>> that describe the methods, tools or techniques employed to cause > >>>>>> the > >>>> > >>>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning > >>>>>> the > >>>> > >>>>>> method such as CVSS, CWSS, or CCE." > >>>> > >>>>>> > >>>> > >>>>>> "The Expectation Class[...] SHOULD contain data elements which > >>>> > >>>>>> describe configuration changes, detection heuristics, or [* (legal > >>>> > >>>>>> authorization?)] to assist in executing or implementing the > >>>>>> requested > >>>> > >>>>>> action, such as XCCDF, OCIL, OVAL, etc" > >>>> > >>>>>> > >>>> > >>>>>> This could go towards encouraging better or at least more > >>>>>> consistent > >>>> > >>>>>> use of "boundary objects" in the substance of incident reports. I > >>>> > >>>>>> could also go on about greater automation and such but that's > >>>>>> probably > >>>> > >>>>>> out of scope for this e-mail. > >>>> > >>>>>> > >>>> > >>>>>> > >>>> > >>>>>> - Tom Millar, US-CERT > >>>> > >>>>>> > >>>> > >>>>>> thomas.millar@us-cert.gov > >>>> > >>>>>> BB: thomas.millar@dhs.gov / > >>>> > >>>>>> 202-631-1915 > >>>> > >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 > >>>> > >>>>>> -----Original Message----- > >>>> > >>>>>> From: mile-bounces@ietf.org > >>>> > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > >>>> > >>>>>> Sent: Thursday, July 28, 2011 11:08 AM > >>>> > >>>>>> To: mile@ietf.org > >>>> > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > >>>> > >>>>>> > >>>> > >>>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > >>>> > >>>>>> > >>>> > >>>>>> http://tools.ietf.org/html/rfc5070#section-3.19 > >>>> > >>>>>> > >>>> > >>>>>> i've been sticking other "XML like" records under this (icsg1.1 > >>>>>> data, > >>>> > >>>>>> etc...). > >>>> > >>>>>> > >>>> > >>>>>> pretty easy to do, just generate the "other standards" xml (or > >>>>>> json or > >>>> > >>>>>> whatever), embed it there. turns iodef into a sharing platform for > >>>> > >>>>>> other data-types w/o having to extend it too much. > >>>> > >>>>>> > >>>> > >>>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > >>>> > >>>>>> > >>>> > >>>>>> So, maybe we could extend the IODEF as described in Figure 1 of > >>>>>> the > >>>> > >>>>>> attached txt file. (correct me if I'm wrong) We could define > >>>> > >>>>>> Incident.EventData.AdditionalData elements and describe them by > >>>>>> using > >>>> > >>>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > >>>> > >>>>>> Regarding OVAL, we might define Incident.AdditionalData element, > >>>>>> but I > >>>> > >>>>>> > >>>> > >>>>>> am not sure at this moment, thus is not described in the figure ye= t. > >>>> > >>>>>> I would like to tackle CAPEC first since I believe Kent would like > >>>>>> to > >>>> > >>>>>> tackle CVE and CAPEC. > >>>> > >>>>>> > >>>> > >>>>>> -- > >>>> > >>>>>> Wes > >>>> > >>>>>> claimid.com/wesyoung > >>>> > >>>>>> soc@ren-isac.net > >>>> > >>>>>> > >>>> > >>>>>> * Wes Young> > >>>> > >>>>>> * 0xDDB6E946 - Unverified(L) > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> > >>>> > >>>>>> _______________________________________________ > >>>> > >>>>>> mile mailing list > >>>> > >>>>>> mile@ietf.org > >>>> > >>>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>>>> . > >>>> > >>>>>> > >>>> > >>>>> > >>>> > >>>>> _______________________________________________ > >>>> > >>>>> mile mailing list > >>>> > >>>>> mile@ietf.org > >>>> > >>>>> https://www.ietf.org/mailman/listinfo/mile > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> -- > >>> Takeshi Takahashi, Ph.D. > >>> +81 80 3490 2971 > >>> http://www.taketaka.com/ > >>> > >>> > >> > >> _______________________________________________ > >> mile mailing 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 Aug 26 07:30:11 2011 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 BFDB521F8BB3 for ; Fri, 26 Aug 2011 07:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.46 X-Spam-Level: X-Spam-Status: No, score=-105.46 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, 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 nZnsaqm+kbcj for ; Fri, 26 Aug 2011 07:30:07 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4C92121F8B82 for ; Fri, 26 Aug 2011 07:30:07 -0700 (PDT) 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 p7QEUxc6028119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2011 10:31:00 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 26 Aug 2011 10:30:53 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.221.47.158]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7QEUqLc009373; Fri, 26 Aug 2011 10:30:53 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub29.corp.emc.com ([128.221.47.158]) with mapi; Fri, 26 Aug 2011 10:30:52 -0400 From: To: , , Date: Fri, 26 Aug 2011 10:30:51 -0400 Thread-Topic: [mile] draft on IODEF extension to support structured cybersecurity information Thread-Index: AcxiOgPZ2GuGQRFeRi2mjxtzZ0AnrAAJAaGwAFwEJX8ACXZdIA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B12FD98@MX14A.corp.emc.com> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <013601cc6235$3196b1d0$94c41570$@nict.go.jp> <510A8D02-449C-43C3-9D60-2F25C16BC277@tik.ee.ethz.ch> <018f01cc6238$e6fa0f60$b4ee2e20$@nict.go.jp> <5D14417A-40EE-4865-81B5-2D6A10EDCC85@tik.ee.ethz.ch>, <7C4DFCE962635144B8FAE8CA11D0BF1E05896729AD@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] draft on IODEF extension to support structured cybersecurity information 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, 26 Aug 2011 14:30:11 -0000 Hi Kathleen, The concern behind my request is: >> This avoids having to go fetch an XML schema in the middle of incident >> handling and allows verification in advance that the recipient's automat= ed tooling >> can handle the content. As long as that goal is achieved, I'm flexible in how we go about achieving= it. So, assuming that this IODEF extension uses XML namespace references rather= than ENUM values to designate external specifications, I would like to see something similar to= the following where the IANA registration is just the namespace, and the schema is mainta= ined elsewhere: > 1. SCAP and some of the other referenced schemas are maintained outside o= f the IETF currently, so > namespaces and schemas are defined elsewhere. IANA maintains a registry = of XML schemas referenced by > IETF documents (SCAP and other XML schemas are referenced from the propos= ed IODEF extension fit into > this group). However, the existing IANA XML registry (http://www.iana.org/assignments/xm= l-registry/ns.html) appears (IMHO) to be too broad for this purpose - for example, the keyprov = DSKPP namespaces (e.g., for PKCS5 and PKCS12) aren't appropriate, among many other examples.= It also appears that only IETF-defined (and maintained) namespaces are currently registered= in that IANA registry. FWIW, There's also an XML schema registry (http://www.iana.org/assignments/= xml-registry/schema.html) that does not appear to be appropriate, as registering SCAP and other exter= nal schemas there probably gets in the way of external maintenance of those schemas. So, in addition to registering the XML namespaces in the existing registry,= I would like to see creation of a new registry specific to this IODEF extension that lists only= the XML namespaces that are valid to use in this IODEF extension for structured cyber-security= information. > 2. IANA also registers identifiers that are allocated in IETF-controlled = URI space (IODEF and > IODEF extensions fit into this group). Yes, in the same IANA registries. > Are you asking for each of the referenced schemes to be registered as des= cribed by #1 and then > following the template, Take will register the IODEF extension following = #2 following the guidance in > RFC3688? The IANA registration requests are all handled in the IANA Cons= iderations section of a > draft. I believe so, and in addition, I'm asking that the draft create a new IANA = registry that contains only the schemas that are valid for use in this IODEF extension. It may be useful to ask the IETF XML Directorate (http://www.apps.ietf.org/= content/xml-directorate) for guidance on the details of what should be done here. Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Friday, August 26, 2011 5:13 AM > To: Black, David; trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: RE: [mile] draft on IODEF extension to support structured cybers= ecurity information > > Hello David, > > I would like to clarify your request, so please let me know if the follow= ing would satisfy the > request. > > 1. SCAP and some of the other referenced schemas are maintained outside o= f the IETF currently, so > namespaces and schemas are defined elsewhere. IANA maintains a registry = of XML schemas referenced by > IETF documents (SCAP and other XML schemas are referenced from the propos= ed IODEF extension fit into > this group). > > 2. IANA also registers identifiers that are allocated in IETF-controlled = URI space (IODEF and IODEF > extensions fit into this group). > > Are you asking for each of the referenced schemes to be registered as des= cribed by #1 and then > following the template, Take will register the IODEF extension following = #2 following the guidance in > RFC3688? The IANA registration requests are all handled in the IANA Cons= iderations section of a > draft. > > Registered schemas: > http://www.iana.org/assignments/xml-registry/ns.html > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of david.bl= ack@emc.com > [david.black@emc.com] > Sent: Wednesday, August 24, 2011 9:08 AM > To: trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] draft on IODEF extension to support structured c= ybersecurity information > > I also prefer option 1. Returning to Brian's earlier comment: > > > In general, I agree: representing embedded information by ENUM as oppos= ed to by > > freeform string is much preferable. However, if the embedded informatio= n is itself > > described by an XML Schema, then it may make sense to differentiate the= embedded > > AdditionalData content not with a new ENUM, but rather by the namespace= used by > > that schema. You still run into the subordinate namespace versioning pr= oblem, > > but this is now the job of the creator of the subordinate namespace to = do > > correctly, which I would assume is the case for the SCAP use case. > > I'm ok with SpecificationName being an XML namespace reference rather tha= n an ENUM > (both work for me), but I still think the IANA registry of allowed XML na= mespace > references is needed, so that a recipient can prepare in advance for what= might be > coming. This avoids having to go fetch an XML schema in the middle of in= cident > handling and allows verification in advance that the recipient's automate= d tooling > can handle the content. > > Thanks, > --David > > > -----Original Message----- > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > Sent: Wednesday, August 24, 2011 4:44 AM > > To: Takeshi Takahashi > > Cc: Black, David; mile@ietf.org > > Subject: Re: [mile] draft on IODEF extension to support structured cybe= rsecurity information > > > > Hi, Take, > > > > I prefer option 1 as well... > > > > (This would additionally appear to resolve my previous question.) > > > > Cheers, > > > > Brian > > > > On Aug 24, 2011, at 10:36 AM, Takeshi Takahashi wrote: > > > > > Hi Brian, > > > > > > I like the 1st option you kindly raised here. > > > I appreciate your assistance. > > > > > > Let me update the text and come back to the list soon. > > > (I will make sure all the comments I've received in this list should = be > > > reflected.) > > > > > > Best Regards, > > > Take > > > > > > > > > -----Original Message----- > > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > > Sent: Wednesday, August 24, 2011 10:17 AM > > > To: Takeshi Takahashi > > > Cc: david.black@emc.com; mile@ietf.org > > > Subject: Re: [mile] draft on IODEF extension to support structured > > > cybersecurity information > > > > > > Hi, Take, > > > > > > To my understanding, there are two possible answers to this last ques= tion, > > > each with their own disadvantages: > > > > > > 1. The SpecificationName and SpecificationVersion are present and req= uired, > > > and MUST match any version information carried by the enclosed XML na= mespace > > > and schema. This gives you a nice envelope for determining which vers= ion of > > > the extension you're using, but can lead to inconsistency if improper= ly > > > used. It is unclear what a reader should do when an inconsistency is > > > detected. In line with common practice in protocol design (send > > > conservatively, accept liberally), I would suggest "writers/senders M= UST > > > ensure the SpecificationName and SpecificationVersion are consistent = with > > > the contents; if a reader/receiver detects an inconsistency, it SHOUL= D > > > prefer the specification and version derived from the content, and SH= OULD > > > log the inconsistency so a human can correct the problem." But it sho= uld be > > > addressed in any case. > > > > > > 2. The SpecificationName and SpecificationVersion are only present wh= en that > > > information is not derivable from the enclosed XML namespace and sche= ma. > > > This is ugly, because it introduces two ways of doing the same thing.= .. > > > > > > Best regards, > > > > > > Brian > > > > > > On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote: > > > > > >> Hi David, > > >> > > >> Thanks for your email. > > >> > > >> 1) > > >>>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > >>>> possible > > >> specifications. > > >>>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > > >>>> ENUM for dtype and FraudType description. > > >>> > > >>> That sounds like a good approach - each RFC that registers a value > > >>> for the > > >> ENUM should include a pointer to the XML Schema for that specificati= on > > >> as part of making the registration with IANA (the IANA registry entr= y > > >> will reference the RFC for the details). This may help recipients > > >> ensure that they have local copies of the XML schemas necessary to > > >> parse expected content. > > >> > > >> Thank you for telling me the IANA issue. I appreciate that. > > >> > > >> 2) > > >>>> So, my assumption here is that a complete CVE (compatible with its > > >>>> schema) will be embedded here. > > >>> > > >>> I don't have a problem with that assumption, but think it should be > > >>> stated > > >> because that conclusion is not obvious [well, at least not to me ;-) > > >> ]. It should be sufficient to state that the embedded element is a > > >> complete XML document that is formatted according to the schema > > >> referenced by the IANA registration of the ENUM value used for > > > SpecificationName (see item 1). > > >> > > >> I see. I will. Thank you. > > >> > > >>> My concern is similar to item 1) - how does the recipient parse and > > >>> check > > >> the version number? > > >>> The rules for this need to be precise, otherwise there may be > > >>> unexpected > > >> string compare results. It'd be good if the version number could be > > >> extracted from the XML Schema for the embedded content (and hence > > >>> take advantage of the rules in the referenced specification for the > > >> syntax of [Specification]Version). > > >>> > > >>> A simple (silly) example of what can go wrong is that OVAL is > > >>> currently at > > >> version 5.10 - that's not the same as 5.1, but if it's converted to = a > > >> number, the result is easy to misparse it as being equivalent to 5.1= ;-). > > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if= the > > > '.' > > >> causes problems in some tooling? All of these are easy for a human = to > > >> sort out, but potential causes of problems in automated tools. > > >> > > >> Yes, I agree. > > >> To clarify this issue, I'll add a sentence "parsers are expected to > > >> read the namespace of the embedded structured information and identi= fy > > >> specification name and data, whenever such information is available, > > >> and parse the embedded data." > > >> > > >> Then one potential question we might have is, do we need the > > >> SpecificationName and SpecificationVersion elements? > > >> If the namespace described in the embedded structured information > > >> identify the specification name and its version, one might think the= se > > >> elements are useless. > > >> However, in my opinion, we still need these elements since some of t= he > > >> embedded information could be non-xml in the future. > > >> > > >> Thank you. > > >> > > >> Take > > >> > > >> -----Original Message----- > > >> From: david.black@emc.com [mailto:david.black@emc.com] > > >> Sent: Tuesday, August 16, 2011 10:15 AM > > >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > > >> Subject: RE: [mile] draft on IODEF extension to support structured > > >> cybersecurity information > > >> > > >> Hi Take, > > >> > > >> Enjoy your vacation, here are some comments to look at when you retu= rn: > > >> > > >> 1) > > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > >>> possible > > >> specifications. > > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > > >>> ENUM for dtype and FraudType description. > > >> > > >> That sounds like a good approach - each RFC that registers a value f= or > > >> the ENUM should include a pointer to the XML Schema for that > > >> specification as part of making the registration with IANA (the IANA > > >> registry entry will reference the RFC for the details). This may he= lp > > >> recipients ensure that they have local copies of the XML schemas > > >> necessary to parse expected content. > > >> > > >> 2) > > >>> So, my assumption here is that a complete CVE (compatible with its > > >>> schema) will be embedded here. > > >> > > >> I don't have a problem with that assumption, but think it should be > > >> stated because that conclusion is not obvious [well, at least not to > > >> me ;-) ]. It should be sufficient to state that the embedded elemen= t > > >> is a complete XML document that is formatted according to the schema > > >> referenced by the IANA registration of the ENUM value used for > > > SpecificationName (see item 1). > > >> > > >>> 3) > > >>> Maybe some text in the draft has caused mis-understanding. > > >>> Yes, the latest version of the XCCDF schema is 1.6. > > >>> I intended to say that the number of the version element is zero or= one. > > >>> Most of specifications such as XCCDF etc. have versions while CVE > > >>> does > > >> not. > > >>> Thus the number of this element class is ZERO or ONE. > > >> > > >> I misread what you wrote, sorry about that. I was looking for the > > >> syntax of the contents of the [Specification]Version element, and > > >> looked in the wrong place. > > >> > > >> My concern is similar to item 1) - how does the recipient parse and > > >> check the version number? > > >> The rules for this need to be precise, otherwise there may be > > >> unexpected string compare results. It'd be good if the version numb= er > > >> could be extracted from the XML Schema for the embedded content (and > > >> hence take advantage of the rules in the referenced specification fo= r > > >> the syntax of [Specification]Version). > > >> > > >> A simple (silly) example of what can go wrong is that OVAL is > > >> currently at version 5.10 - that's not the same as 5.1, but if it's > > >> converted to a number, the result is easy to misparse it as being > > > equivalent to 5.1 ;-). > > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., if= the > > > '.' > > >> causes problems in some tooling? All of these are easy for a human = to > > >> sort out, but potential causes of problems in automated tools. > > >> > > >> Thanks, > > >> --David > > >> > > >>> -----Original Message----- > > >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > >>> Sent: Sunday, August 14, 2011 9:25 AM > > >>> To: Black, David; mile@ietf.org > > >>> Subject: RE: [mile] draft on IODEF exstension to support structured > > >>> cybersecurity information > > >>> > > >>> Hi David, > > >>> > > >>> Thank you for your kind comments. > > >>> I agree, I'll change the element class name. > > >>> > > >>> Regarding the issues you kindly raised in the email, let me describ= e > > >>> my understanding. > > >>> > > >>> 1) > > >>> My assumption was, when parsing the xml data, the parser anyway rea= ds > > >>> the namespace described in the embedded xml data and parse the data= . > > >>> But I agree, it would be better to limit the description of > > >>> SpecificationName. > > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > >>> possible specifications. > > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) use > > >>> ENUM for dtype and FraudType description. > > >>> Like the same way, the SpecificationName could use ENUM for > > >>> describing specifications, though we do not have that much > > >>> specifications to enumerate at this moment. > > >>> > > >>> 2) > > >>> I am not sure whether it is easier for information sender and > > >>> receiver to send/receive partial CVE data. > > >>> Maybe it would be easier for them to embed/receive/parse a complete > > >>> CVE data? > > >>> If we send a partial CVE or the other structured data, receiver may > > >>> suffer from some parsing problem, as you mentioned. > > >>> So, my assumption here is that a complete CVE (compatible with its > > >>> schema) will be embedded here. > > >>> > > >>> 3) > > >>> Maybe some text in the draft has caused mis-understanding. > > >>> Yes, the latest version of the XCCDF schema is 1.6. > > >>> I intended to say that the number of the version element is zero or= one. > > >>> Most of specifications such as XCCDF etc. have versions while CVE > > >>> does > > >> not. > > >>> Thus the number of this element class is ZERO or ONE. > > >>> > > >>> Above are my viewpoint, but I might be wrong. > > >>> Let me develop the draft based on your kind comments after my vacat= ion. > > >>> Please correct me if I am wrong, I would like to welcome feedbacks. > > >>> > > >>> Thank you. > > >>> > > >>> Take > > >>> > > >>> > > >>> From: david.black@emc.com [mailto:david.black@emc.com] > > >>> Sent: Wednesday, August 10, 2011 8:45 AM > > >>> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > > >>> Cc: david.black@emc.com > > >>> Subject: RE: [mile] draft on IODEF exstension to support structured > > >>> cybersecurity information > > >>> > > >>> Hi Take, > > >>> > > >>> For clarity I'd suggest not using "Version" as the name of both an > > >>> extension attribute and one of the classes in each extension. > > >>> Renaming the class to SpecificationVersion would be clearer (so > > >>> Version is the attribute with the version of the extension). > > >>> > > >>> I also have a few questions: > > >>> > > >>> (1) What strings are valid for SpecificationName? If the recipient > > >>> doesn't understand the SpecificationName, the information in the > > >>> extension may be unparseable, so this probably needs to be controll= ed. > > >>> > > >>> An IANA registry may be appropriate to list the valid strings and > > >>> associate each string with its corresponding specification. > > >>> > > >>> (2) How does one determine the format for information formatted > > >>> according to an external specification? > > >>> > > >>> For example, I believe that the XSD schema for the CVE list defines= a > > >>> complete XML document, but I suspect that less than a complete XML > > >>> document is intended to be embedded because the proposed extension = is > > >>> part of an IODEF XML document. > > >>> > > >>> (3) Why is the [Specification]Version limited to zero or one? > > >>> > > >>> For example, CAPEC is currently at Release 1.6. > > >>> > > >>> 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 > > >>> ---------------------------------------------------- > > >>> > > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behal= f > > >>> Of Takeshi Takahashi > > >>> Sent: Monday, August 08, 2011 11:50 PM > > >>> To: mile@ietf.org > > >>> Subject: Re: [mile] draft on IODEF exstension to support structured > > >>> cybersecurity information > > >>> > > >>> Thank you for those of you who kindly gave me off-line messages . > > >>> > > >>> Let me share the draft with some minor modifications. > > >>> > > >>> Sincerely, > > >>> Take > > >>> > > >>> > > >>> 2011/8/5 Takeshi Takahashi : > > >>>> Dear all, > > >>>> > > >>>> > > >>>> > > >>>> The attached is the tentative version of the draft prepared based = on > > >>>> the comments I've received in this mailing list (Thanks a lot for = that). > > >>>> > > >>>> It would be great if you could provide some comments on Clause 4, > > >>>> where > > >>> the > > >>>> IODEF extension is defined. > > >>>> > > >>>> > > >>>> > > >>>> As you know, there are many ways to embed structured information > > >>>> (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very > > >> flexible. > > >>>> > > >>>> Thus, I would be happy to change and develop the draft further bas= ed > > >>>> on > > >>> your > > >>>> comments. > > >>>> > > >>>> > > >>>> > > >>>> I would like to welcome any comments on that. > > >>>> > > >>>> > > >>>> > > >>>> By the way, I will be on vacation, thus my response might be slow, > > >>>> sorry > > >>> for > > >>>> the inconvenience. > > >>>> > > >>>> > > >>>> > > >>>> Take > > >>>> > > >>>> > > >>>> > > >>>> PS: I've changed the title of the email. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> 2011/7/29 > > >>>> > > >>>>> > > >>>> > > >>>>> Thank you, the approach sounds good, especially since it is in us= e > > >>>>> today > > >>>> > > >>>>> by at least the Research and Education ISAC. Do others have > > >>>>> opinions on > > >>>> > > >>>>> the proposal here? > > >>>> > > >>>>> > > >>>> > > >>>>> Thanks for writing the first draft Take! > > >>>> > > >>>>> > > >>>> > > >>>>> Best regards, > > >>>> > > >>>>> Kathleen > > >>>> > > >>>>> ________________________________________ > > >>>> > > >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > > >>>>> Takeshi > > >>>> > > >>>>> Takahashi [takeshi_takahashi@nict.go.jp] > > >>>> > > >>>>> Sent: Friday, July 29, 2011 9:20 AM > > >>>> > > >>>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > > >>>> > > >>>>> Cc: mile@ietf.org > > >>>> > > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>> > > >>>> > > >>>>> Thank you, Bob, for the email. > > >>>> > > >>>>> I also like Tom's suggestion very much. > > >>>> > > >>>>> Let me work on the "draft" of the draft for a while, then come ba= ck > > >>>>> to > > >>> you > > >>>> > > >>>>> later. > > >>>> > > >>>>> > > >>>> > > >>>>> Take > > >>>> > > >>>>> > > >>>> > > >>>>> -----Original Message----- > > >>>> > > >>>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] > > >>>> > > >>>>> Sent: Friday, July 29, 2011 9:10 AM > > >>>> > > >>>>> To: Kent_Landfield@McAfee.com > > >>>> > > >>>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > > >>>> > > >>>>> wes@ren-isac.net; mile@ietf.org > > >>>> > > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>> > > >>>> > > >>>>> I also like how this is evolving. > > >>>> > > >>>>> > > >>>> > > >>>>> I think, as Tom's suggestions pointed, that any and all of the > > >>>>> useful > > >>>> > > >>>>> types > > >>>> > > >>>>> of information that can help with understanding, diagnosing, and > > >>>>> getting > > >>>> > > >>>>> ahead of an incident should be added but for now we should focus = on > > >>>>> those > > >>>> > > >>>>> the most established and well articulated. > > >>>> > > >>>>> > > >>>> > > >>>>> This can be the compliance/patch/configuration/platform informati= on > > >>>> > > >>>>> related > > >>>> > > >>>>> to the SCAP use case, or event signature/attack pattern/traffic > > >>>> > > >>>>> characteristics from events, or the vulnerability/threat > > >>>>> characterization > > >>>> > > >>>>> space. > > >>>> > > >>>>> > > >>>> > > >>>>> I look forward to Taki's draft to see how he suggests positioning > > >>>>> these > > >>>> > > >>>>> concepts. > > >>>> > > >>>>> > > >>>> > > >>>>> Bob > > >>>> > > >>>>> > > >>>> > > >>>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > > >>>> > > >>>>>> I like where this is headed. > > >>>> > > >>>>>> > > >>>> > > >>>>>> Thanks Takeshi. I look forward to your draft. It will give us > > >>> something > > >>>> > > >>>>> real to discuss. I appreciate you jumping in and getting this sta= rted. > > >>>> > > >>>>>> > > >>>> > > >>>>>> One question that I am not clear on. What do we envision as the > > >>>>>> actual > > >>>> > > >>>>> set > > >>>> > > >>>>> of deliverables? From and SCAP related perspective, are we looki= ng > > >>>>> at a > > >>>> > > >>>>> single draft covering all the extensions? > > >>>> > > >>>>>> > > >>>> > > >>>>>> Kent > > >>>> > > >>>>>> > > >>>> > > >>>>>> Kent Landfield > > >>>> > > >>>>>> Director Content Strategy, Architecture and Standards > > >>>> > > >>>>>> > > >>>> > > >>>>>> McAfee, Inc. > > >>>> > > >>>>>> 5000 Headquarters Dr. > > >>>> > > >>>>>> Plano, Texas 75024 > > >>>> > > >>>>>> > > >>>> > > >>>>>> Direct: +1.972.963.7096 > > >>>> > > >>>>>> Mobile: +1.817.637.8026 > > >>>> > > >>>>>> Web: www.mcafee.com > > >>>> > > >>>>>> > > >>>> > > >>>>>> From: Takeshi > > >>>> > > >>>>>> Takahashi > >>>>>> ict.g > > >>>> > > >>>>>> o.jp>> > > >>>> > > >>>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 > > >>>> > > >>>>>> To: > > >>>> > > >>>>>> "Thomas.Millar@us-cert.gov" > >>>>>> mas.M > > >>>> > > >>>>>> illar@us-cert.gov>, > > >>>> > > >>>>>> "wes@ren-isac.net" > >>>>>> to:we > > >>>> > > >>>>>> s@ren-isac.net>>, > > >>>> > > >>>>>> "mile@ietf.org" > >>>>>> etf.o > > >>>> > > >>>>>> rg>> > > >>>> > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>>> > > >>>> > > >>>>>> Thank you for the email, Tom. > > >>>> > > >>>>>> > > >>>> > > >>>>>> So, here is what the draft needs to describe (if I understand We= s > > >>>>>> and > > >>>> > > >>>>>> Tom correctly). > > >>>> > > >>>>>> > > >>>> > > >>>>>> The draft should define ext-dtype (an attribute of AdditionalDat= a > > >>>> > > >>>>>> Class) to identify the information type, rather than defining ne= w > > >>>> > > >>>>>> class under AdditionalData. > > >>>> > > >>>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, > > >>>>>> ext-capec, > > >>>> > > >>>>>> ext-cvss, ext-cwss, In this way, we could keep the change minima= l > > >>>>>> and > > >>>> > > >>>>>> could easily embed various structured information (CVE etc.) in > > >>>>>> the > > >>>> > > >>>>>> EventData.Record.RecordData.AdditionalData field. > > >>>> > > >>>>>> Then "should" statement should be carefully placed in the text o= f > > >>>> > > >>>>>> relevant class. > > >>>> > > >>>>>> > > >>>> > > >>>>>> I'll prepare some draft so that we could discuss and advance fur= ther. > > >>>> > > >>>>>> > > >>>> > > >>>>>> Take > > >>>> > > >>>>>> > > >>>> > > >>>>>> > > >>>> > > >>>>>> > > >>>> > > >>>>>> -----Original Message----- > > >>>> > > >>>>>> From: mile-bounces@ietf.org > > >>>> > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of > > >>>> > > >>>>>> Thomas.Millar@us-cert.gov > > >>>> > > >>>>>> Sent: Thursday, July 28, 2011 6:28 PM > > >>>> > > >>>>>> To: wes@ren-isac.net; > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>>> > > >>>> > > >>>>>> I think this approach makes more sense. One of the things I thin= k > > >>>> > > >>>>>> could be helpful is to have a number of SHOULD statements furthe= r > > >>>> > > >>>>>> describing the possible types of other documents that would be > > >>>> > > >>>>>> expected to ride under the AdditionalData elements of each class > > >>>>>> (not > > >>>> > > >>>>> just > > >>>> > > >>>>> EventData). > > >>>> > > >>>>>> What I'm thinking of looks like this (very unpolished): > > >>>> > > >>>>>> > > >>>> > > >>>>>> "The Method Class:AdditionalData class SHOULD contain data > > >>>>>> elements > > >>>> > > >>>>>> that describe the methods, tools or techniques employed to cause > > >>>>>> the > > >>>> > > >>>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concerning > > >>>>>> the > > >>>> > > >>>>>> method such as CVSS, CWSS, or CCE." > > >>>> > > >>>>>> > > >>>> > > >>>>>> "The Expectation Class[...] SHOULD contain data elements which > > >>>> > > >>>>>> describe configuration changes, detection heuristics, or [* (leg= al > > >>>> > > >>>>>> authorization?)] to assist in executing or implementing the > > >>>>>> requested > > >>>> > > >>>>>> action, such as XCCDF, OCIL, OVAL, etc" > > >>>> > > >>>>>> > > >>>> > > >>>>>> This could go towards encouraging better or at least more > > >>>>>> consistent > > >>>> > > >>>>>> use of "boundary objects" in the substance of incident reports. = I > > >>>> > > >>>>>> could also go on about greater automation and such but that's > > >>>>>> probably > > >>>> > > >>>>>> out of scope for this e-mail. > > >>>> > > >>>>>> > > >>>> > > >>>>>> > > >>>> > > >>>>>> - Tom Millar, US-CERT > > >>>> > > >>>>>> > > >>>> > > >>>>>> thomas.millar@us-cert.gov > > >>>> > > >>>>>> BB: thomas.millar@dhs.gov / > > >>>> > > >>>>>> 202-631-1915 > > >>>> > > >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 > > >>>> > > >>>>>> -----Original Message----- > > >>>> > > >>>>>> From: mile-bounces@ietf.org > > >>>> > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > > >>>> > > >>>>>> Sent: Thursday, July 28, 2011 11:08 AM > > >>>> > > >>>>>> To: mile@ietf.org > > >>>> > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>>> > > >>>> > > >>>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > > >>>> > > >>>>>> > > >>>> > > >>>>>> http://tools.ietf.org/html/rfc5070#section-3.19 > > >>>> > > >>>>>> > > >>>> > > >>>>>> i've been sticking other "XML like" records under this (icsg1.1 > > >>>>>> data, > > >>>> > > >>>>>> etc...). > > >>>> > > >>>>>> > > >>>> > > >>>>>> pretty easy to do, just generate the "other standards" xml (or > > >>>>>> json or > > >>>> > > >>>>>> whatever), embed it there. turns iodef into a sharing platform f= or > > >>>> > > >>>>>> other data-types w/o having to extend it too much. > > >>>> > > >>>>>> > > >>>> > > >>>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > > >>>> > > >>>>>> > > >>>> > > >>>>>> So, maybe we could extend the IODEF as described in Figure 1 of > > >>>>>> the > > >>>> > > >>>>>> attached txt file. (correct me if I'm wrong) We could define > > >>>> > > >>>>>> Incident.EventData.AdditionalData elements and describe them by > > >>>>>> using > > >>>> > > >>>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > > >>>> > > >>>>>> Regarding OVAL, we might define Incident.AdditionalData element, > > >>>>>> but I > > >>>> > > >>>>>> > > >>>> > > >>>>>> am not sure at this moment, thus is not described in the figure = yet. > > >>>> > > >>>>>> I would like to tackle CAPEC first since I believe Kent would li= ke > > >>>>>> to > > >>>> > > >>>>>> tackle CVE and CAPEC. > > >>>> > > >>>>>> > > >>>> > > >>>>>> -- > > >>>> > > >>>>>> Wes > > >>>> > > >>>>>> claimid.com/wesyoung > > >>>> > > >>>>>> soc@ren-isac.net > > >>>> > > >>>>>> > > >>>> > > >>>>>> * Wes Young> > > >>>> > > >>>>>> * 0xDDB6E946 - Unverified(L) > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> . > > >>>> > > >>>>>> > > >>>> > > >>>>> > > >>>> > > >>>>> _______________________________________________ > > >>>> > > >>>>> mile mailing list > > >>>> > > >>>>> mile@ietf.org > > >>>> > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> -- > > >>> Takeshi Takahashi, Ph.D. > > >>> +81 80 3490 2971 > > >>> http://www.taketaka.com/ > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> mile mailing 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 Aug 26 08:49:34 2011 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 C50CF21F8A35 for ; Fri, 26 Aug 2011 08:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.5 X-Spam-Level: X-Spam-Status: No, score=-105.5 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, 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 vsmG3tfp92lX for ; Fri, 26 Aug 2011 08:49:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E721F88B7 for ; Fri, 26 Aug 2011 08:49:31 -0700 (PDT) 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 p7QFojSB023008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2011 11:50:46 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 26 Aug 2011 11:50:32 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.221.56.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7QFoV7K018400; Fri, 26 Aug 2011 11:50:32 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub15.corp.emc.com ([128.221.56.104]) with mapi; Fri, 26 Aug 2011 11:50:31 -0400 From: To: , , , Date: Fri, 26 Aug 2011 11:50:30 -0400 Thread-Topic: [mile] draft on IODEF extension to support structured cybersecurity information Thread-Index: AcxiOgPZ2GuGQRFeRi2mjxtzZ0AnrAAJAaGwAFwEJX8ACXZdIAAE9BtA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B12FE19@MX14A.corp.emc.com> References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <013601cc6235$3196b1d0$94c41570$@nict.go.jp> <510A8D02-449C-43C3-9D60-2F25C16BC277@tik.ee.ethz.ch> <018f01cc6238$e6fa0f60$b4ee2e20$@nict.go.jp> <5D14417A-40EE-4865-81B5-2D6A10EDCC85@tik.ee.ethz.ch>, <7C4DFCE962635144B8FAE8CA11D0BF1E05896729AD@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B12FD98@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058B12FD98@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] draft on IODEF extension to support structured cybersecurity information 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, 26 Aug 2011 15:49:34 -0000 Small clarification: > I believe so, and in addition, I'm asking that the draft create a new IAN= A registry that contains > only the schemas that are valid for use in this IODEF extension. "schemas" -> "namespace references for the schemas" Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of d= avid.black@emc.com > Sent: Friday, August 26, 2011 10:31 AM > To: Moriarty, Kathleen; trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.g= o.jp > Cc: mile@ietf.org > Subject: Re: [mile] draft on IODEF extension to support structured cybers= ecurity information > > Hi Kathleen, > > The concern behind my request is: > > >> This avoids having to go fetch an XML schema in the middle of incident > >> handling and allows verification in advance that the recipient's autom= ated tooling > >> can handle the content. > > As long as that goal is achieved, I'm flexible in how we go about achievi= ng it. > > So, assuming that this IODEF extension uses XML namespace references rath= er than ENUM values to > designate external specifications, I would like to see something similar = to the following > where the IANA registration is just the namespace, and the schema is main= tained elsewhere: > > > 1. SCAP and some of the other referenced schemas are maintained outside= of the IETF currently, so > > namespaces and schemas are defined elsewhere. IANA maintains a registr= y of XML schemas referenced > by > > IETF documents (SCAP and other XML schemas are referenced from the prop= osed IODEF extension fit into > > this group). > > However, the existing IANA XML registry (http://www.iana.org/assignments/= xml-registry/ns.html) > appears (IMHO) to be too broad for this purpose - for example, the keypro= v DSKPP namespaces > (e.g., for PKCS5 and PKCS12) aren't appropriate, among many other example= s. It also appears > that only IETF-defined (and maintained) namespaces are currently register= ed in that IANA registry. > > FWIW, There's also an XML schema registry (http://www.iana.org/assignment= s/xml-registry/schema.html) > that does not appear to be appropriate, as registering SCAP and other ext= ernal schemas there probably > gets in the way of external maintenance of those schemas. > > So, in addition to registering the XML namespaces in the existing registr= y, I would like to see > creation of a new registry specific to this IODEF extension that lists on= ly the XML namespaces > that are valid to use in this IODEF extension for structured cyber-securi= ty information. > > > 2. IANA also registers identifiers that are allocated in IETF-controlle= d URI space (IODEF and > > IODEF extensions fit into this group). > > Yes, in the same IANA registries. > > > Are you asking for each of the referenced schemes to be registered as d= escribed by #1 and then > > following the template, Take will register the IODEF extension followin= g #2 following the guidance > in > > RFC3688? The IANA registration requests are all handled in the IANA Co= nsiderations section of a > > draft. > > I believe so, and in addition, I'm asking that the draft create a new IAN= A registry that contains > only the schemas that are valid for use in this IODEF extension. > > It may be useful to ask the IETF XML Directorate (http://www.apps.ietf.or= g/content/xml-directorate) > for guidance on the details of what should be done here. > > Thanks, > --David > > > -----Original Message----- > > From: Moriarty, Kathleen > > Sent: Friday, August 26, 2011 5:13 AM > > To: Black, David; trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > > Cc: mile@ietf.org > > Subject: RE: [mile] draft on IODEF extension to support structured cybe= rsecurity information > > > > Hello David, > > > > I would like to clarify your request, so please let me know if the foll= owing would satisfy the > > request. > > > > 1. SCAP and some of the other referenced schemas are maintained outside= of the IETF currently, so > > namespaces and schemas are defined elsewhere. IANA maintains a registr= y of XML schemas referenced > by > > IETF documents (SCAP and other XML schemas are referenced from the prop= osed IODEF extension fit into > > this group). > > > > 2. IANA also registers identifiers that are allocated in IETF-controlle= d URI space (IODEF and IODEF > > extensions fit into this group). > > > > Are you asking for each of the referenced schemes to be registered as d= escribed by #1 and then > > following the template, Take will register the IODEF extension followin= g #2 following the guidance > in > > RFC3688? The IANA registration requests are all handled in the IANA Co= nsiderations section of a > > draft. > > > > Registered schemas: > > http://www.iana.org/assignments/xml-registry/ns.html > > > > Thank you, > > Kathleen > > ________________________________________ > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of david.= black@emc.com > > [david.black@emc.com] > > Sent: Wednesday, August 24, 2011 9:08 AM > > To: trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > > Cc: mile@ietf.org > > Subject: Re: [mile] draft on IODEF extension to support structured = cybersecurity information > > > > I also prefer option 1. Returning to Brian's earlier comment: > > > > > In general, I agree: representing embedded information by ENUM as opp= osed to by > > > freeform string is much preferable. However, if the embedded informat= ion is itself > > > described by an XML Schema, then it may make sense to differentiate t= he embedded > > > AdditionalData content not with a new ENUM, but rather by the namespa= ce used by > > > that schema. You still run into the subordinate namespace versioning = problem, > > > but this is now the job of the creator of the subordinate namespace t= o do > > > correctly, which I would assume is the case for the SCAP use case. > > > > I'm ok with SpecificationName being an XML namespace reference rather t= han an ENUM > > (both work for me), but I still think the IANA registry of allowed XML = namespace > > references is needed, so that a recipient can prepare in advance for wh= at might be > > coming. This avoids having to go fetch an XML schema in the middle of = incident > > handling and allows verification in advance that the recipient's automa= ted tooling > > can handle the content. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > > Sent: Wednesday, August 24, 2011 4:44 AM > > > To: Takeshi Takahashi > > > Cc: Black, David; mile@ietf.org > > > Subject: Re: [mile] draft on IODEF extension to support structured cy= bersecurity information > > > > > > Hi, Take, > > > > > > I prefer option 1 as well... > > > > > > (This would additionally appear to resolve my previous question.) > > > > > > Cheers, > > > > > > Brian > > > > > > On Aug 24, 2011, at 10:36 AM, Takeshi Takahashi wrote: > > > > > > > Hi Brian, > > > > > > > > I like the 1st option you kindly raised here. > > > > I appreciate your assistance. > > > > > > > > Let me update the text and come back to the list soon. > > > > (I will make sure all the comments I've received in this list shoul= d be > > > > reflected.) > > > > > > > > Best Regards, > > > > Take > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > > > Sent: Wednesday, August 24, 2011 10:17 AM > > > > To: Takeshi Takahashi > > > > Cc: david.black@emc.com; mile@ietf.org > > > > Subject: Re: [mile] draft on IODEF extension to support structured > > > > cybersecurity information > > > > > > > > Hi, Take, > > > > > > > > To my understanding, there are two possible answers to this last qu= estion, > > > > each with their own disadvantages: > > > > > > > > 1. The SpecificationName and SpecificationVersion are present and r= equired, > > > > and MUST match any version information carried by the enclosed XML = namespace > > > > and schema. This gives you a nice envelope for determining which ve= rsion of > > > > the extension you're using, but can lead to inconsistency if improp= erly > > > > used. It is unclear what a reader should do when an inconsistency i= s > > > > detected. In line with common practice in protocol design (send > > > > conservatively, accept liberally), I would suggest "writers/senders= MUST > > > > ensure the SpecificationName and SpecificationVersion are consisten= t with > > > > the contents; if a reader/receiver detects an inconsistency, it SHO= ULD > > > > prefer the specification and version derived from the content, and = SHOULD > > > > log the inconsistency so a human can correct the problem." But it s= hould be > > > > addressed in any case. > > > > > > > > 2. The SpecificationName and SpecificationVersion are only present = when that > > > > information is not derivable from the enclosed XML namespace and sc= hema. > > > > This is ugly, because it introduces two ways of doing the same thin= g... > > > > > > > > Best regards, > > > > > > > > Brian > > > > > > > > On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote: > > > > > > > >> Hi David, > > > >> > > > >> Thanks for your email. > > > >> > > > >> 1) > > > >>>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > > >>>> possible > > > >> specifications. > > > >>>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) u= se > > > >>>> ENUM for dtype and FraudType description. > > > >>> > > > >>> That sounds like a good approach - each RFC that registers a valu= e > > > >>> for the > > > >> ENUM should include a pointer to the XML Schema for that specifica= tion > > > >> as part of making the registration with IANA (the IANA registry en= try > > > >> will reference the RFC for the details). This may help recipients > > > >> ensure that they have local copies of the XML schemas necessary to > > > >> parse expected content. > > > >> > > > >> Thank you for telling me the IANA issue. I appreciate that. > > > >> > > > >> 2) > > > >>>> So, my assumption here is that a complete CVE (compatible with i= ts > > > >>>> schema) will be embedded here. > > > >>> > > > >>> I don't have a problem with that assumption, but think it should = be > > > >>> stated > > > >> because that conclusion is not obvious [well, at least not to me ;= -) > > > >> ]. It should be sufficient to state that the embedded element is = a > > > >> complete XML document that is formatted according to the schema > > > >> referenced by the IANA registration of the ENUM value used for > > > > SpecificationName (see item 1). > > > >> > > > >> I see. I will. Thank you. > > > >> > > > >>> My concern is similar to item 1) - how does the recipient parse a= nd > > > >>> check > > > >> the version number? > > > >>> The rules for this need to be precise, otherwise there may be > > > >>> unexpected > > > >> string compare results. It'd be good if the version number could = be > > > >> extracted from the XML Schema for the embedded content (and hence > > > >>> take advantage of the rules in the referenced specification for t= he > > > >> syntax of [Specification]Version). > > > >>> > > > >>> A simple (silly) example of what can go wrong is that OVAL is > > > >>> currently at > > > >> version 5.10 - that's not the same as 5.1, but if it's converted t= o a > > > >> number, the result is easy to misparse it as being equivalent to 5= .1 ;-). > > > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., = if the > > > > '.' > > > >> causes problems in some tooling? All of these are easy for a huma= n to > > > >> sort out, but potential causes of problems in automated tools. > > > >> > > > >> Yes, I agree. > > > >> To clarify this issue, I'll add a sentence "parsers are expected t= o > > > >> read the namespace of the embedded structured information and iden= tify > > > >> specification name and data, whenever such information is availabl= e, > > > >> and parse the embedded data." > > > >> > > > >> Then one potential question we might have is, do we need the > > > >> SpecificationName and SpecificationVersion elements? > > > >> If the namespace described in the embedded structured information > > > >> identify the specification name and its version, one might think t= hese > > > >> elements are useless. > > > >> However, in my opinion, we still need these elements since some of= the > > > >> embedded information could be non-xml in the future. > > > >> > > > >> Thank you. > > > >> > > > >> Take > > > >> > > > >> -----Original Message----- > > > >> From: david.black@emc.com [mailto:david.black@emc.com] > > > >> Sent: Tuesday, August 16, 2011 10:15 AM > > > >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > > > >> Subject: RE: [mile] draft on IODEF extension to support structured > > > >> cybersecurity information > > > >> > > > >> Hi Take, > > > >> > > > >> Enjoy your vacation, here are some comments to look at when you re= turn: > > > >> > > > >> 1) > > > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > > >>> possible > > > >> specifications. > > > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) us= e > > > >>> ENUM for dtype and FraudType description. > > > >> > > > >> That sounds like a good approach - each RFC that registers a value= for > > > >> the ENUM should include a pointer to the XML Schema for that > > > >> specification as part of making the registration with IANA (the IA= NA > > > >> registry entry will reference the RFC for the details). This may = help > > > >> recipients ensure that they have local copies of the XML schemas > > > >> necessary to parse expected content. > > > >> > > > >> 2) > > > >>> So, my assumption here is that a complete CVE (compatible with it= s > > > >>> schema) will be embedded here. > > > >> > > > >> I don't have a problem with that assumption, but think it should b= e > > > >> stated because that conclusion is not obvious [well, at least not = to > > > >> me ;-) ]. It should be sufficient to state that the embedded elem= ent > > > >> is a complete XML document that is formatted according to the sche= ma > > > >> referenced by the IANA registration of the ENUM value used for > > > > SpecificationName (see item 1). > > > >> > > > >>> 3) > > > >>> Maybe some text in the draft has caused mis-understanding. > > > >>> Yes, the latest version of the XCCDF schema is 1.6. > > > >>> I intended to say that the number of the version element is zero = or one. > > > >>> Most of specifications such as XCCDF etc. have versions while CVE > > > >>> does > > > >> not. > > > >>> Thus the number of this element class is ZERO or ONE. > > > >> > > > >> I misread what you wrote, sorry about that. I was looking for the > > > >> syntax of the contents of the [Specification]Version element, and > > > >> looked in the wrong place. > > > >> > > > >> My concern is similar to item 1) - how does the recipient parse an= d > > > >> check the version number? > > > >> The rules for this need to be precise, otherwise there may be > > > >> unexpected string compare results. It'd be good if the version nu= mber > > > >> could be extracted from the XML Schema for the embedded content (a= nd > > > >> hence take advantage of the rules in the referenced specification = for > > > >> the syntax of [Specification]Version). > > > >> > > > >> A simple (silly) example of what can go wrong is that OVAL is > > > >> currently at version 5.10 - that's not the same as 5.1, but if it'= s > > > >> converted to a number, the result is easy to misparse it as being > > > > equivalent to 5.1 ;-). > > > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., = if the > > > > '.' > > > >> causes problems in some tooling? All of these are easy for a huma= n to > > > >> sort out, but potential causes of problems in automated tools. > > > >> > > > >> Thanks, > > > >> --David > > > >> > > > >>> -----Original Message----- > > > >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > > >>> Sent: Sunday, August 14, 2011 9:25 AM > > > >>> To: Black, David; mile@ietf.org > > > >>> Subject: RE: [mile] draft on IODEF exstension to support structur= ed > > > >>> cybersecurity information > > > >>> > > > >>> Hi David, > > > >>> > > > >>> Thank you for your kind comments. > > > >>> I agree, I'll change the element class name. > > > >>> > > > >>> Regarding the issues you kindly raised in the email, let me descr= ibe > > > >>> my understanding. > > > >>> > > > >>> 1) > > > >>> My assumption was, when parsing the xml data, the parser anyway r= eads > > > >>> the namespace described in the embedded xml data and parse the da= ta. > > > >>> But I agree, it would be better to limit the description of > > > >>> SpecificationName. > > > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > > >>> possible specifications. > > > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) us= e > > > >>> ENUM for dtype and FraudType description. > > > >>> Like the same way, the SpecificationName could use ENUM for > > > >>> describing specifications, though we do not have that much > > > >>> specifications to enumerate at this moment. > > > >>> > > > >>> 2) > > > >>> I am not sure whether it is easier for information sender and > > > >>> receiver to send/receive partial CVE data. > > > >>> Maybe it would be easier for them to embed/receive/parse a comple= te > > > >>> CVE data? > > > >>> If we send a partial CVE or the other structured data, receiver m= ay > > > >>> suffer from some parsing problem, as you mentioned. > > > >>> So, my assumption here is that a complete CVE (compatible with it= s > > > >>> schema) will be embedded here. > > > >>> > > > >>> 3) > > > >>> Maybe some text in the draft has caused mis-understanding. > > > >>> Yes, the latest version of the XCCDF schema is 1.6. > > > >>> I intended to say that the number of the version element is zero = or one. > > > >>> Most of specifications such as XCCDF etc. have versions while CVE > > > >>> does > > > >> not. > > > >>> Thus the number of this element class is ZERO or ONE. > > > >>> > > > >>> Above are my viewpoint, but I might be wrong. > > > >>> Let me develop the draft based on your kind comments after my vac= ation. > > > >>> Please correct me if I am wrong, I would like to welcome feedback= s. > > > >>> > > > >>> Thank you. > > > >>> > > > >>> Take > > > >>> > > > >>> > > > >>> From: david.black@emc.com [mailto:david.black@emc.com] > > > >>> Sent: Wednesday, August 10, 2011 8:45 AM > > > >>> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > > > >>> Cc: david.black@emc.com > > > >>> Subject: RE: [mile] draft on IODEF exstension to support structur= ed > > > >>> cybersecurity information > > > >>> > > > >>> Hi Take, > > > >>> > > > >>> For clarity I'd suggest not using "Version" as the name of both a= n > > > >>> extension attribute and one of the classes in each extension. > > > >>> Renaming the class to SpecificationVersion would be clearer (so > > > >>> Version is the attribute with the version of the extension). > > > >>> > > > >>> I also have a few questions: > > > >>> > > > >>> (1) What strings are valid for SpecificationName? If the recipie= nt > > > >>> doesn't understand the SpecificationName, the information in the > > > >>> extension may be unparseable, so this probably needs to be contro= lled. > > > >>> > > > >>> An IANA registry may be appropriate to list the valid strings and > > > >>> associate each string with its corresponding specification. > > > >>> > > > >>> (2) How does one determine the format for information formatted > > > >>> according to an external specification? > > > >>> > > > >>> For example, I believe that the XSD schema for the CVE list defin= es a > > > >>> complete XML document, but I suspect that less than a complete XM= L > > > >>> document is intended to be embedded because the proposed extensio= n is > > > >>> part of an IODEF XML document. > > > >>> > > > >>> (3) Why is the [Specification]Version limited to zero or one? > > > >>> > > > >>> For example, CAPEC is currently at Release 1.6. > > > >>> > > > >>> 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 > > > >>> ---------------------------------------------------- > > > >>> > > > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Beh= alf > > > >>> Of Takeshi Takahashi > > > >>> Sent: Monday, August 08, 2011 11:50 PM > > > >>> To: mile@ietf.org > > > >>> Subject: Re: [mile] draft on IODEF exstension to support structur= ed > > > >>> cybersecurity information > > > >>> > > > >>> Thank you for those of you who kindly gave me off-line messages . > > > >>> > > > >>> Let me share the draft with some minor modifications. > > > >>> > > > >>> Sincerely, > > > >>> Take > > > >>> > > > >>> > > > >>> 2011/8/5 Takeshi Takahashi : > > > >>>> Dear all, > > > >>>> > > > >>>> > > > >>>> > > > >>>> The attached is the tentative version of the draft prepared base= d on > > > >>>> the comments I've received in this mailing list (Thanks a lot fo= r that). > > > >>>> > > > >>>> It would be great if you could provide some comments on Clause 4= , > > > >>>> where > > > >>> the > > > >>>> IODEF extension is defined. > > > >>>> > > > >>>> > > > >>>> > > > >>>> As you know, there are many ways to embed structured information > > > >>>> (e.g. CVE and CAPEC) in IODEF since IODEF is designed to be very > > > >> flexible. > > > >>>> > > > >>>> Thus, I would be happy to change and develop the draft further b= ased > > > >>>> on > > > >>> your > > > >>>> comments. > > > >>>> > > > >>>> > > > >>>> > > > >>>> I would like to welcome any comments on that. > > > >>>> > > > >>>> > > > >>>> > > > >>>> By the way, I will be on vacation, thus my response might be slo= w, > > > >>>> sorry > > > >>> for > > > >>>> the inconvenience. > > > >>>> > > > >>>> > > > >>>> > > > >>>> Take > > > >>>> > > > >>>> > > > >>>> > > > >>>> PS: I've changed the title of the email. > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> 2011/7/29 > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> Thank you, the approach sounds good, especially since it is in = use > > > >>>>> today > > > >>>> > > > >>>>> by at least the Research and Education ISAC. Do others have > > > >>>>> opinions on > > > >>>> > > > >>>>> the proposal here? > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> Thanks for writing the first draft Take! > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> Best regards, > > > >>>> > > > >>>>> Kathleen > > > >>>> > > > >>>>> ________________________________________ > > > >>>> > > > >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf O= f > > > >>>>> Takeshi > > > >>>> > > > >>>>> Takahashi [takeshi_takahashi@nict.go.jp] > > > >>>> > > > >>>>> Sent: Friday, July 29, 2011 9:20 AM > > > >>>> > > > >>>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > > > >>>> > > > >>>>> Cc: mile@ietf.org > > > >>>> > > > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> Thank you, Bob, for the email. > > > >>>> > > > >>>>> I also like Tom's suggestion very much. > > > >>>> > > > >>>>> Let me work on the "draft" of the draft for a while, then come = back > > > >>>>> to > > > >>> you > > > >>>> > > > >>>>> later. > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> Take > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>> > > > >>>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] > > > >>>> > > > >>>>> Sent: Friday, July 29, 2011 9:10 AM > > > >>>> > > > >>>>> To: Kent_Landfield@McAfee.com > > > >>>> > > > >>>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > > > >>>> > > > >>>>> wes@ren-isac.net; mile@ietf.org > > > >>>> > > > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> I also like how this is evolving. > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> I think, as Tom's suggestions pointed, that any and all of the > > > >>>>> useful > > > >>>> > > > >>>>> types > > > >>>> > > > >>>>> of information that can help with understanding, diagnosing, an= d > > > >>>>> getting > > > >>>> > > > >>>>> ahead of an incident should be added but for now we should focu= s on > > > >>>>> those > > > >>>> > > > >>>>> the most established and well articulated. > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> This can be the compliance/patch/configuration/platform informa= tion > > > >>>> > > > >>>>> related > > > >>>> > > > >>>>> to the SCAP use case, or event signature/attack pattern/traffic > > > >>>> > > > >>>>> characteristics from events, or the vulnerability/threat > > > >>>>> characterization > > > >>>> > > > >>>>> space. > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> I look forward to Taki's draft to see how he suggests positioni= ng > > > >>>>> these > > > >>>> > > > >>>>> concepts. > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> Bob > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > > > >>>> > > > >>>>>> I like where this is headed. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> Thanks Takeshi. I look forward to your draft. It will give us > > > >>> something > > > >>>> > > > >>>>> real to discuss. I appreciate you jumping in and getting this s= tarted. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> One question that I am not clear on. What do we envision as th= e > > > >>>>>> actual > > > >>>> > > > >>>>> set > > > >>>> > > > >>>>> of deliverables? From and SCAP related perspective, are we loo= king > > > >>>>> at a > > > >>>> > > > >>>>> single draft covering all the extensions? > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> Kent > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> Kent Landfield > > > >>>> > > > >>>>>> Director Content Strategy, Architecture and Standards > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> McAfee, Inc. > > > >>>> > > > >>>>>> 5000 Headquarters Dr. > > > >>>> > > > >>>>>> Plano, Texas 75024 > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> Direct: +1.972.963.7096 > > > >>>> > > > >>>>>> Mobile: +1.817.637.8026 > > > >>>> > > > >>>>>> Web: www.mcafee.com > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> From: Takeshi > > > >>>> > > > >>>>>> Takahashi > > >>>>>> ict.g > > > >>>> > > > >>>>>> o.jp>> > > > >>>> > > > >>>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 > > > >>>> > > > >>>>>> To: > > > >>>> > > > >>>>>> "Thomas.Millar@us-cert.gov"<= Tho > > > >>>>>> mas.M > > > >>>> > > > >>>>>> illar@us-cert.gov>, > > > >>>> > > > >>>>>> "wes@ren-isac.net" > > >>>>>> to:we > > > >>>> > > > >>>>>> s@ren-isac.net>>, > > > >>>> > > > >>>>>> "mile@ietf.org" > > >>>>>> etf.o > > > >>>> > > > >>>>>> rg>> > > > >>>> > > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> Thank you for the email, Tom. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> So, here is what the draft needs to describe (if I understand = Wes > > > >>>>>> and > > > >>>> > > > >>>>>> Tom correctly). > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> The draft should define ext-dtype (an attribute of AdditionalD= ata > > > >>>> > > > >>>>>> Class) to identify the information type, rather than defining = new > > > >>>> > > > >>>>>> class under AdditionalData. > > > >>>> > > > >>>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, > > > >>>>>> ext-capec, > > > >>>> > > > >>>>>> ext-cvss, ext-cwss, In this way, we could keep the change mini= mal > > > >>>>>> and > > > >>>> > > > >>>>>> could easily embed various structured information (CVE etc.) i= n > > > >>>>>> the > > > >>>> > > > >>>>>> EventData.Record.RecordData.AdditionalData field. > > > >>>> > > > >>>>>> Then "should" statement should be carefully placed in the text= of > > > >>>> > > > >>>>>> relevant class. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> I'll prepare some draft so that we could discuss and advance f= urther. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> Take > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> -----Original Message----- > > > >>>> > > > >>>>>> From: mile-bounces@ietf.org > > > >>>> > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of > > > >>>> > > > >>>>>> Thomas.Millar@us-cert.gov > > > >>>> > > > >>>>>> Sent: Thursday, July 28, 2011 6:28 PM > > > >>>> > > > >>>>>> To: wes@ren-isac.net; > > > >>>> > > > >>>>>> mile@ietf.org > > > >>>> > > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> I think this approach makes more sense. One of the things I th= ink > > > >>>> > > > >>>>>> could be helpful is to have a number of SHOULD statements furt= her > > > >>>> > > > >>>>>> describing the possible types of other documents that would be > > > >>>> > > > >>>>>> expected to ride under the AdditionalData elements of each cla= ss > > > >>>>>> (not > > > >>>> > > > >>>>> just > > > >>>> > > > >>>>> EventData). > > > >>>> > > > >>>>>> What I'm thinking of looks like this (very unpolished): > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> "The Method Class:AdditionalData class SHOULD contain data > > > >>>>>> elements > > > >>>> > > > >>>>>> that describe the methods, tools or techniques employed to cau= se > > > >>>>>> the > > > >>>> > > > >>>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata concernin= g > > > >>>>>> the > > > >>>> > > > >>>>>> method such as CVSS, CWSS, or CCE." > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> "The Expectation Class[...] SHOULD contain data elements which > > > >>>> > > > >>>>>> describe configuration changes, detection heuristics, or [* (l= egal > > > >>>> > > > >>>>>> authorization?)] to assist in executing or implementing the > > > >>>>>> requested > > > >>>> > > > >>>>>> action, such as XCCDF, OCIL, OVAL, etc" > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> This could go towards encouraging better or at least more > > > >>>>>> consistent > > > >>>> > > > >>>>>> use of "boundary objects" in the substance of incident reports= . I > > > >>>> > > > >>>>>> could also go on about greater automation and such but that's > > > >>>>>> probably > > > >>>> > > > >>>>>> out of scope for this e-mail. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> - Tom Millar, US-CERT > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> thomas.millar@us-cert.gov > > > >>>> > > > >>>>>> BB: thomas.millar@dhs.gov / > > > >>>> > > > >>>>>> 202-631-1915 > > > >>>> > > > >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 > > > >>>> > > > >>>>>> -----Original Message----- > > > >>>> > > > >>>>>> From: mile-bounces@ietf.org > > > >>>> > > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > > > >>>> > > > >>>>>> Sent: Thursday, July 28, 2011 11:08 AM > > > >>>> > > > >>>>>> To: mile@ietf.org > > > >>>> > > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> http://tools.ietf.org/html/rfc5070#section-3.19 > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> i've been sticking other "XML like" records under this (icsg1.= 1 > > > >>>>>> data, > > > >>>> > > > >>>>>> etc...). > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> pretty easy to do, just generate the "other standards" xml (or > > > >>>>>> json or > > > >>>> > > > >>>>>> whatever), embed it there. turns iodef into a sharing platform= for > > > >>>> > > > >>>>>> other data-types w/o having to extend it too much. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> So, maybe we could extend the IODEF as described in Figure 1 o= f > > > >>>>>> the > > > >>>> > > > >>>>>> attached txt file. (correct me if I'm wrong) We could define > > > >>>> > > > >>>>>> Incident.EventData.AdditionalData elements and describe them b= y > > > >>>>>> using > > > >>>> > > > >>>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > > > >>>> > > > >>>>>> Regarding OVAL, we might define Incident.AdditionalData elemen= t, > > > >>>>>> but I > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> am not sure at this moment, thus is not described in the figur= e yet. > > > >>>> > > > >>>>>> I would like to tackle CAPEC first since I believe Kent would = like > > > >>>>>> to > > > >>>> > > > >>>>>> tackle CVE and CAPEC. > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> -- > > > >>>> > > > >>>>>> Wes > > > >>>> > > > >>>>>> claimid.com/wesyoung > > > >>>> > > > >>>>>> soc@ren-isac.net > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> * Wes Young> > > > >>>> > > > >>>>>> * 0xDDB6E946 - Unverified(L) > > > >>>> > > > >>>>>> _______________________________________________ > > > >>>> > > > >>>>>> mile mailing list > > > >>>> > > > >>>>>> mile@ietf.org > > > >>>> > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> > > > >>>>>> _______________________________________________ > > > >>>> > > > >>>>>> mile mailing list > > > >>>> > > > >>>>>> mile@ietf.org > > > >>>> > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> _______________________________________________ > > > >>>> > > > >>>>>> mile mailing list > > > >>>> > > > >>>>>> mile@ietf.org > > > >>>> > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>>> _______________________________________________ > > > >>>> > > > >>>>>> mile mailing list > > > >>>> > > > >>>>>> mile@ietf.org > > > >>>> > > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> > > > >>>>>> . > > > >>>> > > > >>>>>> > > > >>>> > > > >>>>> > > > >>>> > > > >>>>> _______________________________________________ > > > >>>> > > > >>>>> mile mailing list > > > >>>> > > > >>>>> mile@ietf.org > > > >>>> > > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> -- > > > >>> Takeshi Takahashi, Ph.D. > > > >>> +81 80 3490 2971 > > > >>> http://www.taketaka.com/ > > > >>> > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mile mailing list > > > >> mile@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mile > > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From turners@ieca.com Fri Aug 26 12:13:14 2011 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 3BC9121F8C17 for ; Fri, 26 Aug 2011 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV59aG9x8wON for ; Fri, 26 Aug 2011 12:13:13 -0700 (PDT) Received: from nm17-vm0.access.bullet.mail.mud.yahoo.com (nm17-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.21]) by ietfa.amsl.com (Postfix) with SMTP id 24BEC21F8BE5 for ; Fri, 26 Aug 2011 12:13:13 -0700 (PDT) Received: from [66.94.237.198] by nm17.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2011 19:14:25 -0000 Received: from [98.139.221.63] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Aug 2011 19:14:24 -0000 Received: from [127.0.0.1] by smtp104.biz.mail.bf1.yahoo.com with NNFMP; 26 Aug 2011 19:14:24 -0000 X-Yahoo-Newman-Id: 862264.94729.bm@smtp104.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1UNCaswVM1n3bTqk3ReSRwAPXmE.T.oUW3FRlTjkmjwxTuX 1RNW3O_gWRB7QjkxdG71KWXGi0YGK0zNLL3EvZuMff58ehheBweIwUE5O8Bf k59ihFBCxNN6cuv5BuyZcWoAuyPIhs.qgxwM8.9ADnn7SgSQPyo5UkZcTgkK p31eWsSu5OOPayXfvuKjsAk_W8NM6mwdPTMVIPb85AFCyfAlDS5W78ij7Hn7 AXTdTqkntJ6cJ8cIoNPIqkIMCc2o5hDPVZ0OrJCj2sCeu6jPQs77M255RAiZ Tnx3N6IEmJMK54zPH51MuI9AuKIEwLA3HIt2Xkgmr2moDzWZNi.Vx2XAy5w_ VH102dXJpsxwqzo6O1eSBVXTG6grNPFAFhQyBxbtsiixA15CH6oRrMTtoU53 mSOfcJvskP7cxDH4QLw-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@71.191.7.147 with plain) by smtp104.biz.mail.bf1.yahoo.com with SMTP; 26 Aug 2011 12:14:24 -0700 PDT Message-ID: <4E57F08F.9020006@ieca.com> Date: Fri, 26 Aug 2011 15:14:23 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mile@ietf.org References: <20110826172014.22072.86166.idtracker@ietfa.amsl.com> In-Reply-To: <20110826172014.22072.86166.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110826172014.22072.86166.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mile] Fwd: I-D Action: draft-takahashi-mile-sci-00.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, 26 Aug 2011 19:13:14 -0000 FYI -------- Original Message -------- Subject: I-D Action: draft-takahashi-mile-sci-00.txt Date: Fri, 26 Aug 2011 10:20:14 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IODEF-extension to support structured cybersecurity information Author(s) : Takeshi Takahashi Kent Landfield Thomas Millar Youki Kadobayashi Filename : draft-takahashi-mile-sci-00.txt Pages : 21 Date : 2011-08-26 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 the following specifications: CAPEC[TM], CEE[TM], CPE[TM], CVE(R), CVRF, CVSS, CWE[TM], CWSS[TM], OVAL(R), and XCCDF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-takahashi-mile-sci-00.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-takahashi-mile-sci-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From turners@ieca.com Sat Aug 27 14:54:31 2011 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 B34F621F8B64 for ; Sat, 27 Aug 2011 14:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+28F5tIx5Xw for ; Sat, 27 Aug 2011 14:54:31 -0700 (PDT) Received: from nm21-vm0.access.bullet.mail.mud.yahoo.com (nm21-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.31]) by ietfa.amsl.com (Postfix) with SMTP id 2DB5121F8B5F for ; Sat, 27 Aug 2011 14:54:31 -0700 (PDT) Received: from [66.94.237.194] by nm21.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2011 21:55:46 -0000 Received: from [98.139.221.60] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2011 21:55:46 -0000 Received: from [127.0.0.1] by smtp101.biz.mail.bf1.yahoo.com with NNFMP; 27 Aug 2011 21:55:46 -0000 X-Yahoo-Newman-Id: 71072.68563.bm@smtp101.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RWmDwGUVM1kCJel3g7rFPPot.tCwjc021i8gg6kM.odAErg .J6F2hGmxn05c0Lf0BzPVzkm5WPMAFJ7o7ZzNA2gn.y9256NqaTGyQjLTUtI SjAULk58Hoje0SX6yI7Bm_XCsZaMHcxl.5jH951OVVvqQGXOVIFsTcT5hQsX 98BocgSHV9SQru8NZkP.CRqZuKhoFAzBzpc6RLGfallNzxg_.Ie1zjUJ943H xpkNSuL15g8cGry9IWiyYyYoUPw1CAcdzuiNNAfp_y6Qqym0gv1P4jgxJ7cb oybxavIeBX9EpuZqUr1HsAaV3P3eDnk.J9yhNdXmnY_wcoGkQx2gLXIA0_mO PXUrgKeHrvGbdyvYdNOx7V3t1mv11MmxLcAgg3Bay88XNZAHzvfRfgIFd2Ts 7cW9NoDKmygaclEBM0w-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.115.62 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 27 Aug 2011 14:55:45 -0700 PDT Message-ID: <4E5967E0.5080607@ieca.com> Date: Sat, 27 Aug 2011 17:55:44 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mile@ietf.org References: <20110826231501.28082.58448.idtracker@ietfa.amsl.com> In-Reply-To: <20110826231501.28082.58448.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110826231501.28082.58448.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------070709050007090803010703" Subject: [mile] Fwd: I-D ACTION:draft-moriarty-mile-rfc6045-bis-00.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, 27 Aug 2011 21:54:31 -0000 This is a multi-part message in MIME format. --------------070709050007090803010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-moriarty-mile-rfc6045-bis-00.txt Date: Fri, 26 Aug 2011 16:15:01 -0700 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : Real-time Inter-network Defense (RID) Author(s) : K. Moriarty Filename : draft-moriarty-mile-rfc6045-bis-00.txt Pages : 70 Date : 2011-08-26 This document provides minor updates to Real-time Inter-network Defense (RID) [RFC6045]. Network 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. Network 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-moriarty-mile-rfc6045-bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070709050007090803010703 Content-Type: Message/External-body; name="draft-moriarty-mile-rfc6045-bis-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-moriarty-mile-rfc6045-bis-00.txt" Content-Type: text/plain Content-ID: <2011-08-26161141.I-D@ietf.org> --------------070709050007090803010703 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070709050007090803010703-- From turners@ieca.com Sat Aug 27 15:57:47 2011 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 CC4AE21F8B54 for ; Sat, 27 Aug 2011 15:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, SARE_OBFU_PART_INA=0.786, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bALPhMeiPw8a for ; Sat, 27 Aug 2011 15:57:47 -0700 (PDT) Received: from nm18-vm0.access.bullet.mail.mud.yahoo.com (nm18-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.23]) by ietfa.amsl.com (Postfix) with SMTP id 325A721F8B51 for ; Sat, 27 Aug 2011 15:57:47 -0700 (PDT) Received: from [66.94.237.126] by nm18.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2011 22:59:02 -0000 Received: from [98.139.221.63] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Aug 2011 22:59:02 -0000 Received: from [127.0.0.1] by smtp104.biz.mail.bf1.yahoo.com with NNFMP; 27 Aug 2011 22:59:02 -0000 X-Yahoo-Newman-Id: 613971.46117.bm@smtp104.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vUAkRRQVM1lNYhqYQQtP9F6D9VN4uAWSRQGoTU.f4_00qqw oC6MO6KTmGiKb3aE75xvGL1ncutP4VcWCU_2ewwjK55AqKYy386MJOeEAnay kYm13LG9Q25Mdrul43ZON3idw3ZTCjDj5Y479TXgOTXWncmrWKJRbUV3.xgR ZMTx47WSLjciXXovG5GYcnRcw0O2EgAb3cUg0mYDmP32l.M0n0go.hi4WD4P MThzIGr2ssc.Dqp9CpYJ8zaImV9CrMZlDQBS7GWtzNIvu_FLNfDTrvnZhnc5 sqiBPhwVfJ5R3UxemQ.bZctaK.F_EJhT_GTRpp2JaRQSG8B546bCFomISSoy 7C4yFIQ8zyt_VhmPKChbBTFt6znBkwHD2dBxx9TEPZpAJqHTAom6jlJXumu5 eJSZFVbySVI8mz6I4XoA- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.115.62 with plain) by smtp104.biz.mail.bf1.yahoo.com with SMTP; 27 Aug 2011 15:59:02 -0700 PDT Message-ID: <4E5976B5.70504@ieca.com> Date: Sat, 27 Aug 2011 18:59:01 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mile@ietf.org References: <20110826231501.28082.58448.idtracker@ietfa.amsl.com> In-Reply-To: <20110826231501.28082.58448.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mile] I-D ACTION:draft-moriarty-mile-rfc6045-bis-00.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, 27 Aug 2011 22:57:47 -0000 Kathleen, Three minor things: 1. If this draft updates RFC 6045 you need to put "Updates: 6045 (once approved)" in the header (and you can replace "Individual Submission" with "Network Working Group"): OLD: Individual Submission K. Moriarty Internet-Draft EMC Intended status: Standards Track August 26, 2011 Expires: February 27, 2012 NEW: Network Working Group K. Moriarty Internet-Draft EMC Updates: 6045 (once approved) August 26, 2011 Intended status: Standards Track Expires: February 27, 2012 2. You need to have a section that tells the readers what changed. This will aid users who don't know how to use the tools pages to see the differences. For those, who are curious, here are the changes: http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/rfc/rfc6045.txt&url2=http://www.ietf.org/id/draft-moriarty-mile-rfc6045-bis-00.txt 3. From the nits checker, I think you can delete the reference == Unused Reference: 'RFC5275' is defined on line 3164, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 3189, but no explicit reference was found in the text == Unused Reference: 'RFC3917' is defined on line 3198, but no explicit reference was found in the text and you need to add these: == Missing Reference: 'XMLschema' is mentioned on line 3089, but not defined == Missing Reference: 'XMLnames' is mentioned on line 1073, but not defined == Missing Reference: 'XMLsig' is mentioned on line 2781, but not defined == Missing Reference: 'XMLencrypt' is mentioned on line 3015, but not defined and one it didn't catch [XML1.0]. spt On 8/26/11 7:15 PM, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Real-time Inter-network Defense (RID) > Author(s) : K. Moriarty > Filename : draft-moriarty-mile-rfc6045-bis-00.txt > Pages : 70 > Date : 2011-08-26 > > This document provides minor updates to Real-time Inter-network > Defense (RID) [RFC6045]. Network 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. Network 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-moriarty-mile-rfc6045-bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From kathleen.moriarty@emc.com Sun Aug 28 12:33:27 2011 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 7D84021F8A7B for ; Sun, 28 Aug 2011 12:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_INA=0.786] 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 naSDbtT37eVf for ; Sun, 28 Aug 2011 12:33:26 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id AC3CE21F87C5 for ; Sun, 28 Aug 2011 12:33:26 -0700 (PDT) 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 p7SJYkGk007288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Aug 2011 15:34:46 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 28 Aug 2011 15:34:34 -0400 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 p7SJYYWQ004608; Sun, 28 Aug 2011 15:34:34 -0400 Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Sun, 28 Aug 2011 15:34:33 -0400 From: To: , Date: Sun, 28 Aug 2011 15:33:53 -0400 Thread-Topic: [mile] I-D ACTION:draft-moriarty-mile-rfc6045-bis-00.txt Thread-Index: AcxlDQIgzPHaOMdLSra4U1o8sJyXhwArGl1D Message-ID: References: <20110826231501.28082.58448.idtracker@ietfa.amsl.com>, <4E5976B5.70504@ieca.com> In-Reply-To: <4E5976B5.70504@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] I-D ACTION:draft-moriarty-mile-rfc6045-bis-00.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, 28 Aug 2011 19:33:27 -0000 Thank you, Sean! I will make the updates in the next revision along with any other edits tha= t may be necessary from comments. Best regards, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Sean Turne= r [turners@ieca.com] Sent: Saturday, August 27, 2011 6:59 PM To: mile@ietf.org Subject: Re: [mile] I-D ACTION:draft-moriarty-mile-rfc6045-bis-00.txt Kathleen, Three minor things: 1. If this draft updates RFC 6045 you need to put "Updates: 6045 (once approved)" in the header (and you can replace "Individual Submission" with "Network Working Group"): OLD: Individual Submission K. Moriarty Internet-Draft EMC Intended status: Standards Track August 26, 2011 Expires: February 27, 2012 NEW: Network Working Group K. Moriarty Internet-Draft EMC Updates: 6045 (once approved) August 26, 2011 Intended status: Standards Track Expires: February 27, 2012 2. You need to have a section that tells the readers what changed. This will aid users who don't know how to use the tools pages to see the differences. For those, who are curious, here are the changes: http://tools.ietf.org//rfcdiff?url1=3Dhttp://www.ietf.org/rfc/rfc6045.txt&u= rl2=3Dhttp://www.ietf.org/id/draft-moriarty-mile-rfc6045-bis-00.txt 3. From the nits checker, I think you can delete the reference =3D=3D Unused Reference: 'RFC5275' is defined on line 3164, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC2827' is defined on line 3189, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3917' is defined on line 3198, but no explic= it reference was found in the text and you need to add these: =3D=3D Missing Reference: 'XMLschema' is mentioned on line 3089, but not defined =3D=3D Missing Reference: 'XMLnames' is mentioned on line 1073, but not defined =3D=3D Missing Reference: 'XMLsig' is mentioned on line 2781, but not defined =3D=3D Missing Reference: 'XMLencrypt' is mentioned on line 3015, but not defined and one it didn't catch [XML1.0]. spt On 8/26/11 7:15 PM, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : Real-time Inter-network Defense (RID) > Author(s) : K. Moriarty > Filename : draft-moriarty-mile-rfc6045-bis-00.txt > Pages : 70 > Date : 2011-08-26 > > This document provides minor updates to Real-time Inter-network > Defense (RID) [RFC6045]. Network 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. Network 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-moriarty-mile-rfc6045-bis-00.tx= t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From takeshi_takahashi@nict.go.jp Mon Aug 29 04:41:49 2011 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 0B86621F8AAF for ; Mon, 29 Aug 2011 04:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB3Vf9M-e1ls for ; Mon, 29 Aug 2011 04:41:45 -0700 (PDT) Received: from ns2.nict.go.jp (unknown [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C06221F8AAA for ; Mon, 29 Aug 2011 04:41:44 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id p7TBgTFJ017886; Mon, 29 Aug 2011 20:42:29 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id p7TBgSBJ003083; Mon, 29 Aug 2011 20:42:28 +0900 (JST) Received: from TakeVAIO (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id p7TBgMWh003080; Mon, 29 Aug 2011 20:42:23 +0900 (JST) From: "Takeshi Takahashi" To: , , , References: <000d01cc5647$62c4c070$284e4150$@go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058959E673@MX14A.corp.emc.com> <006501cc5a85$920bd160$b6237420$@nict.go.jp> <7C4DFCE962635144B8FAE8CA11D0BF1E058960A4E8@MX14A.corp.emc.com> <013601cc6235$3196b1d0$94c41570$@nict.go.jp> <510A8D02-449C-43C3-9D60-2F25C16BC277@tik.ee.ethz.ch> <018f01cc6238$e6fa0f60$b4ee2e20$@nict.go.jp> <5D14417A-40EE-4865-81B5-2D6A10EDCC85@tik.ee.ethz.ch>, <7C4DFCE962635144B8FAE8CA11D0BF1E05896729AD@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B12FD98@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058B12FD98@MX14A.corp.emc.com> Date: Mon, 29 Aug 2011 12:42:23 +0100 Message-ID: <005101cc6640$b9c77b20$2d567160$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0052_01CC6649.1B91D690" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHZoScn83GYsZh9CRcfWQQM2pwT0QIjvf2BAWjmAmcB6FiKgwJkpNeHATuT+tIBYeZvawGNWJpQAq8MOggCVlqa1wECXaIOlIbsY5A= Content-Language: ja Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information 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, 29 Aug 2011 11:41:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0052_01CC6649.1B91D690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all Thank you for your kind comments. As Sean kindly notified, we've submitted our initial draft. Let me summarize the changes I made from the previous version (sheared to this mailing list on 9th August). I hope I have reflected all the comments you have kindly gave us. 1. Attribute name is changed. (Version -> SpecificationVersion) (Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7) 2. Reference to CVRF is added. (Sec. 4.3) 3. The type of SpecificationName element is changed. (ML_STRING -> ENUM) (Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7) 4. Texts are added to clarify that complete information (e.g. CVE information) is embedded. (Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7) "A complete document that is formatted according to the schema referenced by the IANA registration of the ENUM value used for SpecificationName and SpecificationVersion elements." 5. Texts are added to clarify the number of these embedded information elements (e.g., AttackPattern, Vulnerability, Weakness etc.). (Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7) "It is recommended that Assessment class SHOULD contain one or more of the extension elements whenever available." 6. Texts regarding how to parse specification name and version are added. (Sec. 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7) "Writers/senders MUST ensure the SpecificationName and SpecificationVersion are consistent with the contents of the Score; if a reader/receiver detects an inconsistency, it SHOULD prefer the specification and version derived from the content, and SHOULD log the inconsistency so a human can correct the problem." 7. namespace/IANA issue (Sec. 7 of the attached file... not to the one I submitted to IETF secretaries) "The schemata of the embedded structured information are maintained outside of the IETF currently, so namespaces and schemata are defined elsewhere. IANA maintains a registry of XML schemata referenced by IETF documents, so, the schemata of the embedded structured information are referenced from the proposed IODEF extension." Thank you, David and Kathleen, for your kind assistance on this issue. I do not think I have sufficiently addressed the concern you kindly raised yet. Let me study on this issue a bit, then I will query this issue to the experts. If you have any comments on the draft, I would be happy to listen to that. Thank you. Take -----Original Message----- From: david.black@emc.com [mailto:david.black@emc.com] Sent: Friday, August 26, 2011 4:31 PM To: kathleen.moriarty@emc.com; trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp Cc: mile@ietf.org Subject: RE: [mile] draft on IODEF extension to support structured cybersecurity information Hi Kathleen, The concern behind my request is: >> This avoids having to go fetch an XML schema in the middle of >> incident handling and allows verification in advance that the >> recipient's automated tooling can handle the content. As long as that goal is achieved, I'm flexible in how we go about achieving it. So, assuming that this IODEF extension uses XML namespace references rather than ENUM values to designate external specifications, I would like to see something similar to the following where the IANA registration is just the namespace, and the schema is maintained elsewhere: > 1. SCAP and some of the other referenced schemas are maintained > outside of the IETF currently, so namespaces and schemas are defined > elsewhere. IANA maintains a registry of XML schemas referenced by > IETF documents (SCAP and other XML schemas are referenced from the proposed IODEF extension fit into this group). However, the existing IANA XML registry (http://www.iana.org/assignments/xml-registry/ns.html) appears (IMHO) to be too broad for this purpose - for example, the keyprov DSKPP namespaces (e.g., for PKCS5 and PKCS12) aren't appropriate, among many other examples. It also appears that only IETF-defined (and maintained) namespaces are currently registered in that IANA registry. FWIW, There's also an XML schema registry (http://www.iana.org/assignments/xml-registry/schema.html) that does not appear to be appropriate, as registering SCAP and other external schemas there probably gets in the way of external maintenance of those schemas. So, in addition to registering the XML namespaces in the existing registry, I would like to see creation of a new registry specific to this IODEF extension that lists only the XML namespaces that are valid to use in this IODEF extension for structured cyber-security information. > 2. IANA also registers identifiers that are allocated in > IETF-controlled URI space (IODEF and IODEF extensions fit into this group). Yes, in the same IANA registries. > Are you asking for each of the referenced schemes to be registered as > described by #1 and then following the template, Take will register > the IODEF extension following #2 following the guidance in RFC3688? > The IANA registration requests are all handled in the IANA Considerations section of a draft. I believe so, and in addition, I'm asking that the draft create a new IANA registry that contains only the schemas t hat are valid for use in this IODEF extension. It may be useful to ask the IETF XML Directorate (http://www.apps.ietf.org/content/xml-directorate) for guidance on the details of what should be done here. Thanks, --David > -----Original Message----- > From: Moriarty, Kathleen > Sent: Friday, August 26, 2011 5:13 AM > To: Black, David; trammell@tik.ee.ethz.ch; > takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: RE: [mile] draft on IODEF extension to support structured > cybersecurity information > > Hello David, > > I would like to clarify your request, so please let me know if the > following would satisfy the request. > > 1. SCAP and some of the other referenced schemas are maintained > outside of the IETF currently, so namespaces and schemas are defined > elsewhere. IANA maintains a registry of XML schemas referenced by > IETF documents (SCAP and other XML schemas are referenced from the proposed IODEF extension fit into this group). > > 2. IANA also registers identifiers that are allocated in > IETF-controlled URI space (IODEF and IODEF extensions fit into this group). > > Are you asking for each of the referenced schemes to be registered as > described by #1 and then following the template, Take will register > the IODEF extension following #2 following the guidance in RFC3688? > The IANA registration requests are all handled in the IANA Considerations section of a draft. > > Registered schemas: > http://www.iana.org/assignments/xml-registry/ns.html > > Thank you, > Kathleen > ________________________________________ > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > david.black@emc.com [david.black@emc.com] > Sent: Wednesday, August 24, 2011 9:08 AM > To: trammell@tik.ee.ethz.ch; takeshi_takahashi@nict.go.jp > Cc: mile@ietf.org > Subject: Re: [mile] draft on IODEF extension to support structured cybersecurity information > > I also prefer option 1. Returning to Brian's earlier comment: > > > In general, I agree: representing embedded information by ENUM as > > opposed to by freeform string is much preferable. However, if the > > embedded information is itself described by an XML Schema, then it > > may make sense to differentiate the embedded AdditionalData content > > not with a new ENUM, but rather by the namespace used by that > > schema. You still run into the subordinate namespace versioning > > problem, but this is now the job of the creator of the subordinate namespace to do correctly, which I would assume is the case for the SCAP use case. > > I'm ok with SpecificationName being an XML namespace reference rather > than an ENUM (both work for me), but I still think the IANA registry > of allowed XML namespace references is needed, so that a recipient can > prepare in advance for what might be coming. This avoids having to go > fetch an XML schema in the middle of incident handling and allows > verification in advance that the recipient's automated tooling can handle the content. > > Thanks, > --David > > > -----Original Message----- > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > Sent: Wednesday, August 24, 2011 4:44 AM > > To: Takeshi Takahashi > > Cc: Black, David; mile@ietf.org > > Subject: Re: [mile] draft on IODEF extension to support structured > > cybersecurity information > > > > Hi, Take, > > > > I prefer option 1 as well... > > > > (This would additionally appear to resolve my previous question.) > > > > Cheers, > > > > Brian > > > > On Aug 24, 2011, at 10:36 AM, Takeshi Takahashi wrote: > > > > > Hi Brian, > > > > > > I like the 1st option you kindly raised here. > > > I appreciate your assistance. > > > > > > Let me update the text and come back to the list soon. > > > (I will make sure all the comments I've received in this list > > > should be > > > reflected.) > > > > > > Best Regards, > > > Take > > > > > > > > > -----Original Message----- > > > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > > > Sent: Wednesday, August 24, 2011 10:17 AM > > > To: Takeshi Takahashi > > > Cc: david.black@emc.com; mile@ietf.org > > > Subject: Re: [mile] draft on IODEF extension to support structured > > > cybersecurity information > > > > > > Hi, Take, > > > > > > To my understanding, there are two possible answers to this last > > > question, each with their own disadvantages: > > > > > > 1. The SpecificationName and SpecificationVersion are present and > > > required, and MUST match any version information carried by the > > > enclosed XML namespace and schema. This gives you a nice envelope > > > for determining which version of the extension you're using, but > > > can lead to inconsistency if improperly used. It is unclear what a > > > reader should do when an inconsistency is detected. In line with > > > common practice in protocol design (send conservatively, accept > > > liberally), I would suggest "writers/senders MUST ensure the > > > SpecificationName and SpecificationVersion are consistent with the > > > contents; if a reader/receiver detects an inconsistency, it SHOULD > > > prefer the specification and version derived from the content, and > > > SHOULD log the inconsistency so a human can correct the problem." But it should be addressed in any case. > > > > > > 2. The SpecificationName and SpecificationVersion are only present > > > when that information is not derivable from the enclosed XML namespace and schema. > > > This is ugly, because it introduces two ways of doing the same thing... > > > > > > Best regards, > > > > > > Brian > > > > > > On Aug 24, 2011, at 10:09 AM, Takeshi Takahashi wrote: > > > > > >> Hi David, > > >> > > >> Thanks for your email. > > >> > > >> 1) > > >>>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > >>>> possible > > >> specifications. > > >>>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) > > >>>> use ENUM for dtype and FraudType description. > > >>> > > >>> That sounds like a good approach - each RFC that registers a > > >>> value for the > > >> ENUM should include a pointer to the XML Schema for that > > >> specification as part of making the registration with IANA (the > > >> IANA registry entry will reference the RFC for the details). > > >> This may help recipients ensure that they have local copies of > > >> the XML schemas necessary to parse expected content. > > >> > > >> Thank you for telling me the IANA issue. I appreciate that. > > >> > > >> 2) > > >>>> So, my assumption here is that a complete CVE (compatible with > > >>>> its > > >>>> schema) will be embedded here. > > >>> > > >>> I don't have a problem with that assumption, but think it should > > >>> be stated > > >> because that conclusion is not obvious [well, at least not to me > > >> ;-) ]. It should be sufficient to state that the embedded > > >> element is a complete XML document that is formatted according to > > >> the schema referenced by the IANA registration of the ENUM value > > >> used for > > > SpecificationName (see item 1). > > >> > > >> I see. I will. Thank you. > > >> > > >>> My concern is similar to item 1) - how does the recipient parse > > >>> and check > > >> the version number? > > >>> The rules for this need to be precise, otherwise there may be > > >>> unexpected > > >> string compare results. It'd be good if the version number could > > >> be extracted from the XML Schema for the embedded content (and > > >> hence > > >>> take advantage of the rules in the referenced specification for > > >>> the > > >> syntax of [Specification]Version). > > >>> > > >>> A simple (silly) example of what can go wrong is that OVAL is > > >>> currently at > > >> version 5.10 - that's not the same as 5.1, but if it's converted > > >> to a number, the result is easy to misparse it as being equivalent to 5.1 ;-). > > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., > > >> if the > > > '.' > > >> causes problems in some tooling? All of these are easy for a > > >> human to sort out, but potential causes of problems in automated tools. > > >> > > >> Yes, I agree. > > >> To clarify this issue, I'll add a sentence "parsers are expected > > >> to read the namespace of the embedded structured information and > > >> identify specification name and data, whenever such information > > >> is available, and parse the embedded data." > > >> > > >> Then one potential question we might have is, do we need the > > >> SpecificationName and SpecificationVersion elements? > > >> If the namespace described in the embedded structured information > > >> identify the specification name and its version, one might think > > >> these elements are useless. > > >> However, in my opinion, we still need these elements since some > > >> of the embedded information could be non-xml in the future. > > >> > > >> Thank you. > > >> > > >> Take > > >> > > >> -----Original Message----- > > >> From: david.black@emc.com [mailto:david.black@emc.com] > > >> Sent: Tuesday, August 16, 2011 10:15 AM > > >> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > > >> Subject: RE: [mile] draft on IODEF extension to support > > >> structured cybersecurity information > > >> > > >> Hi Take, > > >> > > >> Enjoy your vacation, here are some comments to look at when you return: > > >> > > >> 1) > > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > >>> possible > > >> specifications. > > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) > > >>> use ENUM for dtype and FraudType description. > > >> > > >> That sounds like a good approach - each RFC that registers a > > >> value for the ENUM should include a pointer to the XML Schema for > > >> that specification as part of making the registration with IANA > > >> (the IANA registry entry will reference the RFC for the details). > > >> This may help recipients ensure that they have local copies of > > >> the XML schemas necessary to parse expected content. > > >> > > >> 2) > > >>> So, my assumption here is that a complete CVE (compatible with > > >>> its > > >>> schema) will be embedded here. > > >> > > >> I don't have a problem with that assumption, but think it should > > >> be stated because that conclusion is not obvious [well, at least > > >> not to me ;-) ]. It should be sufficient to state that the > > >> embedded element is a complete XML document that is formatted > > >> according to the schema referenced by the IANA registration of > > >> the ENUM value used for > > > SpecificationName (see item 1). > > >> > > >>> 3) > > >>> Maybe some text in the draft has caused mis-understanding. > > >>> Yes, the latest version of the XCCDF schema is 1.6. > > >>> I intended to say that the number of the version element is zero or one. > > >>> Most of specifications such as XCCDF etc. have versions while > > >>> CVE does > > >> not. > > >>> Thus the number of this element class is ZERO or ONE. > > >> > > >> I misread what you wrote, sorry about that. I was looking for > > >> the syntax of the contents of the [Specification]Version element, > > >> and looked in the wrong place. > > >> > > >> My concern is similar to item 1) - how does the recipient parse > > >> and check the version number? > > >> The rules for this need to be precise, otherwise there may be > > >> unexpected string compare results. It'd be good if the version > > >> number could be extracted from the XML Schema for the embedded > > >> content (and hence take advantage of the rules in the referenced > > >> specification for the syntax of [Specification]Version). > > >> > > >> A simple (silly) example of what can go wrong is that OVAL is > > >> currently at version 5.10 - that's not the same as 5.1, but if > > >> it's converted to a number, the result is easy to misparse it as > > >> being > > > equivalent to 5.1 ;-). > > >> Continuing with that example, is it ok to use 5-10 or 5_10, e.g., > > >> if the > > > '.' > > >> causes problems in some tooling? All of these are easy for a > > >> human to sort out, but potential causes of problems in automated tools. > > >> > > >> Thanks, > > >> --David > > >> > > >>> -----Original Message----- > > >>> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp] > > >>> Sent: Sunday, August 14, 2011 9:25 AM > > >>> To: Black, David; mile@ietf.org > > >>> Subject: RE: [mile] draft on IODEF exstension to support > > >>> structured cybersecurity information > > >>> > > >>> Hi David, > > >>> > > >>> Thank you for your kind comments. > > >>> I agree, I'll change the element class name. > > >>> > > >>> Regarding the issues you kindly raised in the email, let me > > >>> describe my understanding. > > >>> > > >>> 1) > > >>> My assumption was, when parsing the xml data, the parser anyway > > >>> reads the namespace described in the embedded xml data and parse the data. > > >>> But I agree, it would be better to limit the description of > > >>> SpecificationName. > > >>> Maybe we could use ENUM (instead of ML_STRING), and enumerate > > >>> possible specifications. > > >>> For instance, RFC5070 (IODEF) and RFC5901 (phishing extension) > > >>> use ENUM for dtype and FraudType description. > > >>> Like the same way, the SpecificationName could use ENUM for > > >>> describing specifications, though we do not have that much > > >>> specifications to enumerate at this moment. > > >>> > > >>> 2) > > >>> I am not sure whether it is easier for information sender and > > >>> receiver to send/receive partial CVE data. > > >>> Maybe it would be easier for them to embed/receive/parse a > > >>> complete CVE data? > > >>> If we send a partial CVE or the other structured data, receiver > > >>> may suffer from some parsing problem, as you mentioned. > > >>> So, my assumption here is that a complete CVE (compatible with > > >>> its > > >>> schema) will be embedded here. > > >>> > > >>> 3) > > >>> Maybe some text in the draft has caused mis-understanding. > > >>> Yes, the latest version of the XCCDF schema is 1.6. > > >>> I intended to say that the number of the version element is zero or one. > > >>> Most of specifications such as XCCDF etc. have versions while > > >>> CVE does > > >> not. > > >>> Thus the number of this element class is ZERO or ONE. > > >>> > > >>> Above are my viewpoint, but I might be wrong. > > >>> Let me develop the draft based on your kind comments after my vacation. > > >>> Please correct me if I am wrong, I would like to welcome feedbacks. > > >>> > > >>> Thank you. > > >>> > > >>> Take > > >>> > > >>> > > >>> From: david.black@emc.com [mailto:david.black@emc.com] > > >>> Sent: Wednesday, August 10, 2011 8:45 AM > > >>> To: takeshi_takahashi@nict.go.jp; mile@ietf.org > > >>> Cc: david.black@emc.com > > >>> Subject: RE: [mile] draft on IODEF exstension to support > > >>> structured cybersecurity information > > >>> > > >>> Hi Take, > > >>> > > >>> For clarity I'd suggest not using "Version" as the name of both > > >>> an extension attribute and one of the classes in each extension. > > >>> Renaming the class to SpecificationVersion would be clearer (so > > >>> Version is the attribute with the version of the extension). > > >>> > > >>> I also have a few questions: > > >>> > > >>> (1) What strings are valid for SpecificationName? If the > > >>> recipient doesn't understand the SpecificationName, the > > >>> information in the extension may be unparseable, so this probably needs to be controlled. > > >>> > > >>> An IANA registry may be appropriate to list the valid strings > > >>> and associate each string with its corresponding specification. > > >>> > > >>> (2) How does one determine the format for information formatted > > >>> according to an external specification? > > >>> > > >>> For example, I believe that the XSD schema for the CVE list > > >>> defines a complete XML document, but I suspect that less than a > > >>> complete XML document is intended to be embedded because the > > >>> proposed extension is part of an IODEF XML document. > > >>> > > >>> (3) Why is the [Specification]Version limited to zero or one? > > >>> > > >>> For example, CAPEC is currently at Release 1.6. > > >>> > > >>> 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 > > >>> ---------------------------------------------------- > > >>> > > >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > >>> Behalf Of Takeshi Takahashi > > >>> Sent: Monday, August 08, 2011 11:50 PM > > >>> To: mile@ietf.org > > >>> Subject: Re: [mile] draft on IODEF exstension to support > > >>> structured cybersecurity information > > >>> > > >>> Thank you for those of you who kindly gave me off-line messages . > > >>> > > >>> Let me share the draft with some minor modifications. > > >>> > > >>> Sincerely, > > >>> Take > > >>> > > >>> > > >>> 2011/8/5 Takeshi Takahashi : > > >>>> Dear all, > > >>>> > > >>>> > > >>>> > > >>>> The attached is the tentative version of the draft prepared > > >>>> based on the comments I've received in this mailing list (Thanks a lot for that). > > >>>> > > >>>> It would be great if you could provide some comments on Clause > > >>>> 4, where > > >>> the > > >>>> IODEF extension is defined. > > >>>> > > >>>> > > >>>> > > >>>> As you know, there are many ways to embed structured > > >>>> information (e.g. CVE and CAPEC) in IODEF since IODEF is > > >>>> designed to be very > > >> flexible. > > >>>> > > >>>> Thus, I would be happy to change and develop the draft further > > >>>> based on > > >>> your > > >>>> comments. > > >>>> > > >>>> > > >>>> > > >>>> I would like to welcome any comments on that. > > >>>> > > >>>> > > >>>> > > >>>> By the way, I will be on vacation, thus my response might be > > >>>> slow, sorry > > >>> for > > >>>> the inconvenience. > > >>>> > > >>>> > > >>>> > > >>>> Take > > >>>> > > >>>> > > >>>> > > >>>> PS: I've changed the title of the email. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> 2011/7/29 > > >>>> > > >>>>> > > >>>> > > >>>>> Thank you, the approach sounds good, especially since it is in > > >>>>> use today > > >>>> > > >>>>> by at least the Research and Education ISAC. Do others have > > >>>>> opinions on > > >>>> > > >>>>> the proposal here? > > >>>> > > >>>>> > > >>>> > > >>>>> Thanks for writing the first draft Take! > > >>>> > > >>>>> > > >>>> > > >>>>> Best regards, > > >>>> > > >>>>> Kathleen > > >>>> > > >>>>> ________________________________________ > > >>>> > > >>>>> From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf > > >>>>> Of Takeshi > > >>>> > > >>>>> Takahashi [takeshi_takahashi@nict.go.jp] > > >>>> > > >>>>> Sent: Friday, July 29, 2011 9:20 AM > > >>>> > > >>>>> To: 'Martin, Robert A.'; Kent_Landfield@McAfee.com > > >>>> > > >>>>> Cc: mile@ietf.org > > >>>> > > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>> > > >>>> > > >>>>> Thank you, Bob, for the email. > > >>>> > > >>>>> I also like Tom's suggestion very much. > > >>>> > > >>>>> Let me work on the "draft" of the draft for a while, then come > > >>>>> back to > > >>> you > > >>>> > > >>>>> later. > > >>>> > > >>>>> > > >>>> > > >>>>> Take > > >>>> > > >>>>> > > >>>> > > >>>>> -----Original Message----- > > >>>> > > >>>>> From: Martin, Robert A. [mailto:ramartin@mitre.org] > > >>>> > > >>>>> Sent: Friday, July 29, 2011 9:10 AM > > >>>> > > >>>>> To: Kent_Landfield@McAfee.com > > >>>> > > >>>>> Cc: takeshi_takahashi@nict.go.jp; Thomas.Millar@us-cert.gov; > > >>>> > > >>>>> wes@ren-isac.net; mile@ietf.org > > >>>> > > >>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>> > > >>>> > > >>>>> I also like how this is evolving. > > >>>> > > >>>>> > > >>>> > > >>>>> I think, as Tom's suggestions pointed, that any and all of the > > >>>>> useful > > >>>> > > >>>>> types > > >>>> > > >>>>> of information that can help with understanding, diagnosing, > > >>>>> and getting > > >>>> > > >>>>> ahead of an incident should be added but for now we should > > >>>>> focus on those > > >>>> > > >>>>> the most established and well articulated. > > >>>> > > >>>>> > > >>>> > > >>>>> This can be the compliance/patch/configuration/platform > > >>>>> information > > >>>> > > >>>>> related > > >>>> > > >>>>> to the SCAP use case, or event signature/attack > > >>>>> pattern/traffic > > >>>> > > >>>>> characteristics from events, or the vulnerability/threat > > >>>>> characterization > > >>>> > > >>>>> space. > > >>>> > > >>>>> > > >>>> > > >>>>> I look forward to Taki's draft to see how he suggests > > >>>>> positioning these > > >>>> > > >>>>> concepts. > > >>>> > > >>>>> > > >>>> > > >>>>> Bob > > >>>> > > >>>>> > > >>>> > > >>>>> On 7/28/11 10:13 PM, Kent_Landfield@McAfee.com wrote: > > >>>> > > >>>>>> I like where this is headed. > > >>>> > > >>>>>> > > >>>> > > >>>>>> Thanks Takeshi. I look forward to your draft. It will give > > >>>>>> us > > >>> something > > >>>> > > >>>>> real to discuss. I appreciate you jumping in and getting this started. > > >>>> > > >>>>>> > > >>>> > > >>>>>> One question that I am not clear on. What do we envision as > > >>>>>> the actual > > >>>> > > >>>>> set > > >>>> > > >>>>> of deliverables? From and SCAP related perspective, are we > > >>>>> looking at a > > >>>> > > >>>>> single draft covering all the extensions? > > >>>> > > >>>>>> > > >>>> > > >>>>>> Kent > > >>>> > > >>>>>> > > >>>> > > >>>>>> Kent Landfield > > >>>> > > >>>>>> Director Content Strategy, Architecture and Standards > > >>>> > > >>>>>> > > >>>> > > >>>>>> McAfee, Inc. > > >>>> > > >>>>>> 5000 Headquarters Dr. > > >>>> > > >>>>>> Plano, Texas 75024 > > >>>> > > >>>>>> > > >>>> > > >>>>>> Direct: +1.972.963.7096 > > >>>> > > >>>>>> Mobile: +1.817.637.8026 > > >>>> > > >>>>>> Web: www.mcafee.com > > >>>> > > >>>>>> > > >>>> > > >>>>>> From: Takeshi > > >>>> > > >>>>>> Takahashi > >>>>>> hi@n > > >>>>>> ict.g > > >>>> > > >>>>>> o.jp>> > > >>>> > > >>>>>> Date: Thu, 28 Jul 2011 18:21:56 -0500 > > >>>> > > >>>>>> To: > > >>>> > > >>>>>> "Thomas.Millar@us-cert.gov" > > >>>>>> > >>>>>> mas.M > > >>>> > > >>>>>> illar@us-cert.gov>, > > >>>> > > >>>>>> "wes@ren-isac.net" > >>>>>> mail > > >>>>>> to:we > > >>>> > > >>>>>> s@ren-isac.net>>, > > >>>> > > >>>>>> "mile@ietf.org" > >>>>>> le@i > > >>>>>> etf.o > > >>>> > > >>>>>> rg>> > > >>>> > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>>> > > >>>> > > >>>>>> Thank you for the email, Tom. > > >>>> > > >>>>>> > > >>>> > > >>>>>> So, here is what the draft needs to describe (if I understand > > >>>>>> Wes and > > >>>> > > >>>>>> Tom correctly). > > >>>> > > >>>>>> > > >>>> > > >>>>>> The draft should define ext-dtype (an attribute of > > >>>>>> AdditionalData > > >>>> > > >>>>>> Class) to identify the information type, rather than defining > > >>>>>> new > > >>>> > > >>>>>> class under AdditionalData. > > >>>> > > >>>>>> Ext-dtype: ext-cve, ext-cwe, ext-oval, ext-xccdf, ext-cpe, > > >>>>>> ext-capec, > > >>>> > > >>>>>> ext-cvss, ext-cwss, In this way, we could keep the change > > >>>>>> minimal and > > >>>> > > >>>>>> could easily embed various structured information (CVE etc.) > > >>>>>> in the > > >>>> > > >>>>>> EventData.Record.RecordData.AdditionalData field. > > >>>> > > >>>>>> Then "should" statement should be carefully placed in the > > >>>>>> text of > > >>>> > > >>>>>> relevant class. > > >>>> > > >>>>>> > > >>>> > > >>>>>> I'll prepare some draft so that we could discuss and advance further. > > >>>> > > >>>>>> > > >>>> > > >>>>>> Take > > >>>> > > >>>>>> > > >>>> > > >>>>>> > > >>>> > > >>>>>> > > >>>> > > >>>>>> -----Original Message----- > > >>>> > > >>>>>> From: mile-bounces@ietf.org > > >>>> > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of > > >>>> > > >>>>>> Thomas.Millar@us-cert.gov > > >>>> > > >>>>>> Sent: Thursday, July 28, 2011 6:28 PM > > >>>> > > >>>>>> To: wes@ren-isac.net; > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>>> > > >>>> > > >>>>>> I think this approach makes more sense. One of the things I > > >>>>>> think > > >>>> > > >>>>>> could be helpful is to have a number of SHOULD statements > > >>>>>> further > > >>>> > > >>>>>> describing the possible types of other documents that would > > >>>>>> be > > >>>> > > >>>>>> expected to ride under the AdditionalData elements of each > > >>>>>> class (not > > >>>> > > >>>>> just > > >>>> > > >>>>> EventData). > > >>>> > > >>>>>> What I'm thinking of looks like this (very unpolished): > > >>>> > > >>>>>> > > >>>> > > >>>>>> "The Method Class:AdditionalData class SHOULD contain data > > >>>>>> elements > > >>>> > > >>>>>> that describe the methods, tools or techniques employed to > > >>>>>> cause the > > >>>> > > >>>>>> incident, such as CAPEC, CWE, CVE, CVRF, or metadata > > >>>>>> concerning the > > >>>> > > >>>>>> method such as CVSS, CWSS, or CCE." > > >>>> > > >>>>>> > > >>>> > > >>>>>> "The Expectation Class[...] SHOULD contain data elements > > >>>>>> which > > >>>> > > >>>>>> describe configuration changes, detection heuristics, or [* > > >>>>>> (legal > > >>>> > > >>>>>> authorization?)] to assist in executing or implementing the > > >>>>>> requested > > >>>> > > >>>>>> action, such as XCCDF, OCIL, OVAL, etc" > > >>>> > > >>>>>> > > >>>> > > >>>>>> This could go towards encouraging better or at least more > > >>>>>> consistent > > >>>> > > >>>>>> use of "boundary objects" in the substance of incident > > >>>>>> reports. I > > >>>> > > >>>>>> could also go on about greater automation and such but that's > > >>>>>> probably > > >>>> > > >>>>>> out of scope for this e-mail. > > >>>> > > >>>>>> > > >>>> > > >>>>>> > > >>>> > > >>>>>> - Tom Millar, US-CERT > > >>>> > > >>>>>> > > >>>> > > >>>>>> thomas.millar@us-cert.gov > > >>>> > > >>>>>> BB: thomas.millar@dhs.gov / > > >>>> > > >>>>>> 202-631-1915 > > >>>> > > >>>>>> 24x7: soc@us-cert.gov / 888-282-0870 > > >>>> > > >>>>>> -----Original Message----- > > >>>> > > >>>>>> From: mile-bounces@ietf.org > > >>>> > > >>>>>> [mailto:mile-bounces@ietf.org] On Behalf Of Wes Young > > >>>> > > >>>>>> Sent: Thursday, July 28, 2011 11:08 AM > > >>>> > > >>>>>> To: mile@ietf.org > > >>>> > > >>>>>> Subject: Re: [mile] Updated presentation from Side meeting > > >>>> > > >>>>>> > > >>>> > > >>>>>> * PGP Signed by an unverified key: 7/28/2011 at 11:08:06 AM > > >>>> > > >>>>>> > > >>>> > > >>>>>> http://tools.ietf.org/html/rfc5070#section-3.19 > > >>>> > > >>>>>> > > >>>> > > >>>>>> i've been sticking other "XML like" records under this > > >>>>>> (icsg1.1 data, > > >>>> > > >>>>>> etc...). > > >>>> > > >>>>>> > > >>>> > > >>>>>> pretty easy to do, just generate the "other standards" xml > > >>>>>> (or json or > > >>>> > > >>>>>> whatever), embed it there. turns iodef into a sharing > > >>>>>> platform for > > >>>> > > >>>>>> other data-types w/o having to extend it too much. > > >>>> > > >>>>>> > > >>>> > > >>>>>> On Jul 28, 2011, at 10:56 AM, Takeshi Takahashi wrote: > > >>>> > > >>>>>> > > >>>> > > >>>>>> So, maybe we could extend the IODEF as described in Figure 1 > > >>>>>> of the > > >>>> > > >>>>>> attached txt file. (correct me if I'm wrong) We could define > > >>>> > > >>>>>> Incident.EventData.AdditionalData elements and describe them > > >>>>>> by using > > >>>> > > >>>>>> CPE, CVE/CWE, CVSS/CWSS, and CAPEC. > > >>>> > > >>>>>> Regarding OVAL, we might define Incident.AdditionalData > > >>>>>> element, but I > > >>>> > > >>>>>> > > >>>> > > >>>>>> am not sure at this moment, thus is not described in the figure yet. > > >>>> > > >>>>>> I would like to tackle CAPEC first since I believe Kent would > > >>>>>> like to > > >>>> > > >>>>>> tackle CVE and CAPEC. > > >>>> > > >>>>>> > > >>>> > > >>>>>> -- > > >>>> > > >>>>>> Wes > > >>>> > > >>>>>> claimid.com/wesyoung > > >>>> > > >>>>>> soc@ren-isac.net > > >>>> > > >>>>>> > > >>>> > > >>>>>> * Wes Young> > > >>>> > > >>>>>> * 0xDDB6E946 - Unverified(L) > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> > > >>>> > > >>>>>> _______________________________________________ > > >>>> > > >>>>>> mile mailing list > > >>>> > > >>>>>> mile@ietf.org > > >>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>>>> . > > >>>> > > >>>>>> > > >>>> > > >>>>> > > >>>> > > >>>>> _______________________________________________ > > >>>> > > >>>>> mile mailing list > > >>>> > > >>>>> mile@ietf.org > > >>>> > > >>>>> https://www.ietf.org/mailman/listinfo/mile > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> -- > > >>> Takeshi Takahashi, Ph.D. > > >>> +81 80 3490 2971 > > >>> http://www.taketaka.com/ > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> mile mailing list > > >> mile@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mile > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_000_0052_01CC6649.1B91D690 Content-Type: text/plain; name="draft-takahashi-mile-sci-00-ver01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-takahashi-mile-sci-00-ver01.txt" =0A= =0A= =0A= Individual Submission T. Takahashi=0A= Internet-Draft NICT=0A= Intended status: Informational K. Landfield=0A= Expires: February 27, 2012 McAfee=0A= T. Millar=0A= USCERT=0A= Y. Kadobayashi=0A= NICT=0A= Aug 26, 2011=0A= =0A= =0A= IODEF-extension to support structured cybersecurity information=0A= draft-takahashi-mile-sci-00.txt=0A= =0A= Abstract=0A= =0A= This document extends the Incident Object Description Exchange Format=0A= (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched=0A= cybersecurity information exchange among cybersecurity entities by=0A= embedding structured information formatted by the following=0A= specifications: CAPEC[TM], CEE[TM], CPE[TM], CVE(R), CVRF, CVSS,=0A= CWE[TM], CWSS[TM], OVAL(R), and XCCDF.=0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on February 27, 2012.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2011 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 1]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4=0A= 4.1. Scoring . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 4.2. AttackPattern . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4.3. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 7=0A= 4.4. Weakness . . . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 4.5. PlatformID . . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 4.6. EventReport . . . . . . . . . . . . . . . . . . . . . . . 11=0A= 4.7. Remediation . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13=0A= 5.1. Reporting an attack . . . . . . . . . . . . . . . . . . . 13=0A= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15=0A= 6.1. Transport-Specific Concerns . . . . . . . . . . . . . . . 15=0A= 6.2. Using the iodef:restriction Attribute . . . . . . . . . . 16=0A= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16=0A= 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17=0A= 9. Appendix: XML Schema Definition for Extension . . . . . . . . 17=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . . 19=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 2]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 1. Introduction=0A= =0A= Cyber attacks are getting more sophisticated, and their numbers are=0A= increasing day by day. To cope with such situation, incident=0A= information needs to be reported, exchanged, and shared among=0A= organizations. IODEF is one of the tools enabling such exchange, and=0A= is already in use.=0A= =0A= On the other hand, there exist various other activities facilitating=0A= detailed and structured description of cybersecurity information,=0A= major of which includes [CAPEC], [CEE], [CPE], [CVE], [CVRF], [CVSS],=0A= [CWE], [CWSS], [OVAL], and [XCCDF]. Since such structured=0A= description facilitates cybersecurity operations, it would be=0A= beneficial to embed and convey these information inside IODEF=0A= document.=0A= =0A= To enable that, this document extends the IODEF to embed and convey=0A= various structured cybersecurity information, with which=0A= cybersecurity operations can be facilitated. Since IODEF defines a=0A= flexible and extensible format and supports a granular level of=0A= specificity, this document defines an extension to IODEF instead of=0A= defining a new report format. For clarity, and to eliminate=0A= duplication, only the additional structures necessary for describing=0A= the exhange of such structured information are provided.=0A= =0A= =0A= 2. Terminology=0A= =0A= The terminology used in this document follows the one defined in=0A= [RFC5070].=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= =0A= 3. Applicability=0A= =0A= To maintain cybersecurity, organization needs to exchange=0A= cybersecurity information, which includes the following information:=0A= attack pattern, platform information, vulnerability and weakness,=0A= countermeasure instruction, computer event log, and the severity.=0A= =0A= IODEF provides a scheme to exchange such information among interested=0A= parties. However, the detailed common format to describe such=0A= information is not defined in the IODEF base document.=0A= =0A= On the other hand, to describe those information and to faciliate=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 3]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= exchange, a structured format for that is already available. Major=0A= of them are CAPEC, CEE, CPE, CVE, CVRF, CVSS, CWE, CWSS, OVAL, and=0A= XCCDF. By embedding them into the IODEF document, the documnt can=0A= convey more detailed contents to the receivers, and the document can=0A= be easily reused.=0A= =0A= These structured cybersecuriity information facilitates cybersecurity=0A= operation at the receiver side. Since the information is machine-=0A= readable, the data can be processed by computers. That expedites the=0A= automation of cybersecurity operations=0A= =0A= For instance, an organization wishing to report a security incident=0A= wants to describe what vulnerability was exploited. Then the sender=0A= can simply use IODEF, where an CAPEC record is embedded instead of=0A= describing everything in free format text. Receiver can also=0A= identify the needed details of the attack pattern by looking up some=0A= of the xml tags defined by CAPEC. Receiver can accummulate the=0A= attack pattern information (CAPEC record) in its database and could=0A= distribute it to the interested parties if needed, without needing=0A= human interventions.=0A= =0A= =0A= 4. Extension Definition=0A= =0A= This draft extends IODEF to embed structured cybersecurity=0A= information by introducing new classes, with which these information=0A= can be embedded inside IODEF document as element contents of=0A= AdditionalData and RecordItem classes.=0A= =0A= The IODEF Incident element ([RFC5070], Section 3.2) is summarized=0A= below. It is expressed in Unified Modeling Language (UML) syntax as=0A= used in the IODEF specification. The UML representation is for=0A= illustrative purposes only; elements are specified in XML as defined=0A= in Appendix A.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 4]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= +--------------------+=0A= | Incident |=0A= +--------------------+=0A= | ENUM purpose |<>----------[ IncidentID ]=0A= | STRING ext-purpose |<>--{0..1}--[ AlternativeID ]=0A= | ENUM lang |<>--{0..1}--[ RelatedActivity ]=0A= | ENUM restriction |<>--{0..1}--[ DetectTime ]=0A= | |<>--{0..1}--[ StartTime ]=0A= | |<>--{0..1}--[ EndTime ]=0A= | |<>----------[ ReportTime ]=0A= | |<>--{0..*}--[ Description ]=0A= | |<>--{1..*}--[ Assessment ]=0A= | | |<>--[ AdditionalData ]=0A= | | |<>--[ Scoring ]=0A= | |<>--{0..*}--[ Method ]=0A= | | |<>--[ AdditionalData ]=0A= | | |<>--[ AttackPattern ]=0A= | | |<>--[ Vulnerability ]=0A= | | |<>--[ Weakness ]=0A= | |<>--{1..*}--[ Contact ]=0A= | |<>--{0..*}--[ EventData ]=0A= | | |<>--[ Flow ]=0A= | | | |<>--[ System ]=0A= | | | |<>--[ AdditionalData ]=0A= | | | |<>--[ = PlatformID ]=0A= | | |<>--[ Expectation ]=0A= | | |<>--[ Record ]=0A= | | |<>--[ RecordData ]=0A= | | |<>--[ RecordItem ]=0A= | | |<>--[ = EventReport ]=0A= | |<>--{0..1}--[ History ]=0A= | |<>--{0..*}--[ AdditionalData ]=0A= | | |<>--[ Remediation ]=0A= +--------------------+=0A= =0A= This extension defines the following seven elements.=0A= =0A= 4.1. Scoring=0A= =0A= A Scoring consists of an extension to the=0A= Incident.Assessment.AdditionalData element with a dtype of "xml".=0A= The extension describes the scoring of the severity of incidents or=0A= events.=0A= =0A= It is recommended that Assessment class SHOULD contain one or more of=0A= the extension elements whenever available.=0A= =0A= A Scoring class is structured as follows.=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 5]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= +--------------------+=0A= | Scoring |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ SpecificationVersion ]=0A= | |<>--(0..1)--[ Score ]=0A= +--------------------+=0A= =0A= This class has an attribute.=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ENUM. The name of the specification=0A= specifying the format of the Score element. This field contains=0A= one of the following values:=0A= =0A= 1. cvss. common vulnerability scoring system.=0A= =0A= 2. cwss. common weakness scoring system.=0A= =0A= 3. other. This is used to identify not-yet-enumerated=0A= specifications.=0A= =0A= SpecificationVersion: Zero or one. ML_STRING. The version of the=0A= specification specifying the format of the Score element=0A= =0A= Score: Zero or one. ML_STRING. Arbitrary information structured by=0A= the specification identified by SpecificationName and=0A= SpecificationVersion elements.=0A= =0A= Writers/senders MUST ensure the SpecificationName and=0A= SpecificationVersion are consistent with the contents of the Score;=0A= if a reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification and version derived from the content, and SHOULD log=0A= the inconsistency so a human can correct the problem.=0A= =0A= 4.2. AttackPattern=0A= =0A= An AttackPattern consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". The=0A= extension describes attack patterns of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain one or more of the=0A= extension elements whenever available.=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 6]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= An AttackPattern class is structured as follows.=0A= =0A= +--------------------+=0A= | AttackPattern |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ SpecificationVersion ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute.=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= The AttackPattern class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ENUM. The name of the specification=0A= specifying the format of the Record element. This field contains=0A= one of the following values:=0A= =0A= 1. capec. common attack pattern enumeration and classification.=0A= =0A= 2. other. This is used to identify not-yet-enumerated=0A= specifications.=0A= =0A= SpecificationVersion: Zero or one. ML_STRING. The version of the=0A= specification specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. A complete document that is=0A= formatted according to the schema referenced by the IANA=0A= registration of the ENUM value used for SpecificationName and=0A= SpecificationVersion elements.=0A= =0A= Writers/senders MUST ensure the SpecificationName and=0A= SpecificationVersion are consistent with the contents of the Record;=0A= if a reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification and version derived from the content, and SHOULD log=0A= the inconsistency so a human can correct the problem.=0A= =0A= 4.3. Vulnerability=0A= =0A= A Vulnerability consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". The=0A= extension describes the (candidate) vulnerabilities of incidents or=0A= events.=0A= =0A= It is recommended that Method class SHOULD contain one or more of the=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 7]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= extension elements whenever available.=0A= =0A= A Vulnerability element is structured as follows.=0A= =0A= +--------------------+=0A= | Vulnerability |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ SpecificationVersion ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute.=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ENUM. The name of the specification=0A= specifying the format of the Record element. This field contains=0A= one of the following values:=0A= =0A= 1. cve. common vulnerability enumeration.=0A= =0A= 2. cvrf. common vulnerability reporting format.=0A= =0A= 3. other. This is used to identify not-yet-enumerated=0A= specifications.=0A= =0A= SpecificationVersion: Zero or one. ML_STRING. The version of the=0A= specification specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. A complete document that is=0A= formatted according to the schema referenced by the IANA=0A= registration of the ENUM value used for SpecificationName and=0A= SpecificationVersion elements.=0A= =0A= Writers/senders MUST ensure the SpecificationName and=0A= SpecificationVersion are consistent with the contents of the Record;=0A= if a reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification and version derived from the content, and SHOULD log=0A= the inconsistency so a human can correct the problem.=0A= =0A= 4.4. Weakness=0A= =0A= A Weakness consists of an extension to the=0A= Incident.Method.AdditionalData element with a dtype of "xml". The=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 8]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= extension describes the weakness types of incidents or events.=0A= =0A= It is recommended that Method class SHOULD contain one or more of the=0A= extension elements whenever available.=0A= =0A= A Weakness element is structured as follows.=0A= =0A= +--------------------+=0A= | Weakness |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ SpecificationVersion ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute.=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ENUM. The name of the specification=0A= specifying the format of the Record element. This field contains=0A= one of the following values:=0A= =0A= 1. cwe. common weakness enumeration and classification.=0A= =0A= 2. other. This is used to identify not-yet-enumerated=0A= specifications.=0A= =0A= SpecificationVersion: Zero or one. ML_STRING. The version of the=0A= specification specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. A complete document that is=0A= formatted according to the schema referenced by the IANA=0A= registration of the ENUM value used for SpecificationName and=0A= SpecificationVersion elements.=0A= =0A= Writers/senders MUST ensure the SpecificationName and=0A= SpecificationVersion are consistent with the contents of the Record;=0A= if a reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification and version derived from the content, and SHOULD log=0A= the inconsistency so a human can correct the problem.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 9]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 4.5. PlatformID=0A= =0A= A PlatformID consists of an extension to the=0A= Incident.EventData.Flow.System.AdditionalData element with a dtype of=0A= "xml". The extension identifies a software platform.=0A= =0A= It is recommended that System class SHOULD contain one or more of the=0A= extension elements whenever available.=0A= =0A= A PlatformID element is structured as follows.=0A= =0A= +--------------------+=0A= | PlatformID |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ SpecificationVersion ]=0A= | |<>--(1..*)--[ ID ]=0A= +--------------------+=0A= =0A= This class has an attribute.=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ENUM. The name of the specification=0A= specifying the format of the ID element. This field contains one=0A= of the following values:=0A= =0A= 1. cpe. common attack pattern enumeration and classification.=0A= =0A= 2. other. This is used to identify not-yet-enumerated=0A= specifications.=0A= =0A= SpecificationVersion: Zero or one. ML_STRING. The version of the=0A= specification specifying the format of the Score element=0A= =0A= ID: One or more. ML_STRING. An ID that is formatted according to=0A= the rule referenced by the IANA registration of the ENUM value=0A= used for SpecificationName and SpecificationVersion elements.=0A= =0A= Writers/senders MUST ensure the SpecificationName and=0A= SpecificationVersion are consistent with the contents of the ID; if a=0A= reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification and version derived from the content, and SHOULD log=0A= the inconsistency so a human can correct the problem.=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 10]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 4.6. EventReport=0A= =0A= An EventReport consists of an extension to the=0A= Incident.EventData.Record.RecordData.RecordItem element with a dtype=0A= of "xml". The extension embeds structured event reports.=0A= =0A= It is recommended that RecordItem class SHOULD contain one or more of=0A= the extension elements whenever available.=0A= =0A= An EventReport element is structured as follows.=0A= =0A= +--------------------+=0A= | EventRecord |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ SpecificationVersion ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute.=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ENUM. The name of the specification=0A= specifying the format of the Record element. This field contains=0A= one of the following values:=0A= =0A= 1. cee. common attack pattern enumeration and classification.=0A= =0A= 2. other. This is used to identify not-yet-enumerated=0A= specifications.=0A= =0A= SpecificationVersion: Zero or one. ML_STRING. The version of the=0A= specification specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. A complete document that is=0A= formatted according to the schema referenced by the IANA=0A= registration of the ENUM value used for SpecificationName and=0A= SpecificationVersion elements.=0A= =0A= Writers/senders MUST ensure the SpecificationName and=0A= SpecificationVersion are consistent with the contents of the Record;=0A= if a reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification and version derived from the content, and SHOULD log=0A= the inconsistency so a human can correct the problem.=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 11]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 4.7. Remediation=0A= =0A= A Remediation consists of an extension to the Incident.AdditionalData=0A= element with a dtype of "xml". The extension elements describes=0A= incident remediation infomration including instructions.=0A= =0A= It is recommended that Incident class SHOULD contain one or more of=0A= this extension elements whenever available.=0A= =0A= A Remediation class is structured as follows.=0A= =0A= +--------------------+=0A= | Remediation |=0A= +--------------------+=0A= | STRING Version |<>----------[ SpecificationName ]=0A= | |<>--(0..1)--[ SpecificationVersion ]=0A= | |<>--(1..*)--[ Record ]=0A= +--------------------+=0A= =0A= This class has an attribute.=0A= =0A= Version: REQUIRED. STRING. The version shall be the value 1.00, to=0A= be compliant with this document.=0A= =0A= This class is composed of three aggregate classes.=0A= =0A= SpecificationName: One. ENUM. The name of the specification=0A= specifying the format of the Record element. This field contains=0A= one of the following values:=0A= =0A= 1. oval.=0A= =0A= 2. ocil.=0A= =0A= 3. xccdff.=0A= =0A= 4. other. This is used to identify not-yet-enumerated=0A= specifications.=0A= =0A= SpecificationVersion: Zero or one. ML_STRING. The version of the=0A= specification specifying the format of the Score element=0A= =0A= Record: One or more. ML_STRING. A complete document that is=0A= formatted according to the schema referenced by the IANA=0A= registration of the ENUM value used for SpecificationName and=0A= SpecificationVersion elements.=0A= =0A= Writers/senders MUST ensure the SpecificationName and=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 12]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= SpecificationVersion are consistent with the contents of the Record;=0A= if a reader/receiver detects an inconsistency, it SHOULD prefer the=0A= specification and version derived from the content, and SHOULD log=0A= the inconsistency so a human can correct the problem.=0A= =0A= =0A= 5. Examples=0A= =0A= This section provides examples of an incident encoded in the IODEF.=0A= These examples do not necessarily represent the only way to encode a=0A= particular incident.=0A= =0A= 5.1. Reporting an attack=0A= =0A= An example of a CSIRT reporting an attack.=0A= =0A= =0A= =0A= xsi:schemaLocation=3D"urn:ietf:params:xml:schema:iodef-1.0">=0A= =0A= 189493=0A= 2001-09-13T23:19:24+00:00=0A= Incident report in company xx=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= capec=0A= 1.6=0A= [embed data in CAPEC format]=0A= =0A= =0A= cve=0A= [embed data in CVE format]=0A= =0A= =0A= cwe=0A= 5.0=0A= [embed data in CVE format]=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 13]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= Example.com CSIRT=0A= example-com=0A= contact@csirt.example.com=0A= =0A= =0A= =0A= =0A= =0A=
192.0.2.200
=0A= 57=0A= =0A= =0A= =0A= =0A=
192.0.2.16/28
=0A= =0A= =0A= 80=0A= =0A= =0A= =0A= cpe=0A= 2.2=0A= [embed identifier in CPE format]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 2001-09-13T18:11:21+02:00=0A= a Web-server event record=0A= =0A= =0A= cee=0A= 1.0=0A= [embed data in CEE format]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 14]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= 2001-09-14T08:19:01+00:00=0A= Notification sent to=0A= constituency-contact@192.0.2.200=0A= =0A= =0A= =0A= =0A= oval=0A= 5.9=0A= [embed OVAL-structured information here]=0A= =0A= =0A= xccdf=0A= 1.2=0A= [embed XCCDF-structured information here]=0A= =0A= =0A= =0A= =0A= =0A= Figure 1: Example UML Element Diagram=0A= =0A= =0A= 6. Security Considerations=0A= =0A= This document specifies a format for encoding a particular class of=0A= security incidents appropriate for exchange across organizations. As=0A= merely a data representation, it does not directly introduce security=0A= issues. However, it is guaranteed that parties exchanging instances=0A= of this specification will have certain concerns. For this reason,=0A= the underlying message format and transport protocol used MUST ensure=0A= the appropriate degree of confidentiality, integrity, and=0A= authenticity for the specific environment.=0A= =0A= Organizations that exchange data using this document are URGED to=0A= develop operating procedures that document the following areas of=0A= concern.=0A= =0A= [Note: additional text will appear soon]=0A= =0A= 6.1. Transport-Specific Concerns=0A= =0A= The critical security concerns are that phishing activity reports may=0A= be falsified or the PhraudReport may become corrupt during transit.=0A= In areas where transmission security or secrecy is questionable, the=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 15]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= application of a digital signature and/or message encryption on each=0A= report will counteract both of these concerns. We expect that each=0A= exchanging organization will determine the need, and mechanism, for=0A= transport protection.=0A= =0A= 6.2. Using the iodef:restriction Attribute=0A= =0A= In some instances, data values in particular elements may contain=0A= data deemed sensitive by the reporter. Although there are no=0A= general-purpose rules on when to mark certain values as "private" or=0A= "need-to-know" via the iodef:restriction attribute, the reporter is=0A= cautioned not to apply element-level sensitivity markings unless they=0A= believe the receiving party (i.e., the party they are exchanging the=0A= event report data with) has a mechanism to adequately safeguard and=0A= process the data as marked.=0A= =0A= =0A= 7. IANA Considerations=0A= =0A= This document uses URNs to describe XML namespaces and XML schemas=0A= conforming to a registry mechanism described in [RFC3688].=0A= =0A= Registration request for the IODEF My-Extension namespace:=0A= =0A= URI: urn:ietf:params:xml:ns:iodef-msmspecs-1.0=0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: None=0A= =0A= Registration request for the IODEF My-Extension XML schema:=0A= =0A= URI: urn:ietf:params:xml:schema:iodef-msmspecs-1.0=0A= =0A= Registrant Contact: Refer here to the authors' addresses section=0A= of the document.=0A= =0A= XML: Refer here to the XML Schema in the appendix of the document.=0A= =0A= The schemata of the embedded structured information are maintained=0A= outside of the IETF currently, so namespaces and schemata are defined=0A= elsewhere. IANA maintains a registry of XML schemata referenced by=0A= IETF documents, so, the schemata of the embedded structured=0A= information are referenced from the proposed IODEF extension.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 16]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= 8. Acknowledgment=0A= =0A= The following groups and individuals, listed alphabetically,=0A= contributed substantially to this document and should be recognized=0A= for their efforts.=0A= =0A= Black David, EMC=0A= =0A= Robert Martin, MITRE=0A= =0A= Kathleen Moriarty, EMC=0A= =0A= Anthony Rutkowski, Yaana Technology=0A= =0A= Brian Trammell, CERT/NetSA=0A= =0A= =0A= 9. Appendix: XML Schema Definition for Extension=0A= =0A= The XML Schema describing the elements defined in the Extension=0A= Defintion section is given here. Each of the examples in Section 5=0A= should be verified to validate against this schema by automated=0A= tools.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 17]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 18]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Example Schema Diagram=0A= =0A= =0A= 10. References=0A= =0A= 10.1. Normative References=0A= =0A= [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident=0A= Object Description Exchange Format", RFC 5070,=0A= December 2007.=0A= =0A= [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",=0A= RFC 6045, November 2010.=0A= =0A= 10.2. Informative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing=0A= Architecture", RFC 2373, July 1998.=0A= =0A= [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform=0A= Resource Identifiers (URI): Generic Syntax", RFC 2396,=0A= August 1998.=0A= =0A= [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,=0A= April 2001.=0A= =0A= [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the=0A= Internet: Timestamps", RFC 3339, July 2002.=0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 19]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC=0A= Text on Security Considerations", BCP 72, RFC 3552,=0A= July 2003.=0A= =0A= [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,=0A= January 2004.=0A= =0A= [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol=0A= (LDAP): Schema for User Applications", RFC 4519,=0A= June 2006.=0A= =0A= [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an=0A= IANA Considerations Section in RFCs", BCP 26, RFC 5226,=0A= May 2008.=0A= =0A= [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to=0A= Uniform Resource Identifiers (URI) Dynamic Delegation=0A= Discovery System (DDDS) Application (ENUM)", RFC 6116,=0A= March 2011.=0A= =0A= [CVSS] Peter Mell, Karen Scarfone, and Sasha Romanosky, "The=0A= Common Vulnerability Scoring System (CVSS) and Its=0A= Applicability to Federal Agency Systems".=0A= =0A= [CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration=0A= and Classification (CAPEC)".=0A= =0A= [CEE] The MITRE Corporation, "Common Event Expression (CEE)".=0A= =0A= [CPE] Andrew Buttner and Neal Ziring, "Common Platform=0A= Enumeration (CPE) - Specification".=0A= =0A= [CVE] The MITRE Corporation, "Common Vulnerability and Exposures=0A= (CVE)".=0A= =0A= [CVRF] ICASI, "http://www.icasi.org/cvrf".=0A= =0A= [CWE] The MITRE Corporation, "Common Weakness Enumeration=0A= (CWE)".=0A= =0A= [CWSS] The MITRE Corporation, "Common Weakness Scoring System=0A= (CWSS)".=0A= =0A= [OCIL] Maria Casipe and Charles Schmidt, "The Open Checklist=0A= Interactive Language (OCIL) Version 1.1".=0A= =0A= [OVAL] The MITRE Corporation, "Open Vulnerability and Assessment=0A= Language (OVAL)".=0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 20]=0A= =0C=0A= Internet-Draft IODEF-ext-sci Aug 2011=0A= =0A= =0A= [XCCDF] Neal Ziring and Stephen D. Quinn, "Specification for the=0A= Extensible Configuration Checklist Description Format=0A= (XCCDF) version 1.1.4".=0A= =0A= =0A= Authors' Addresses=0A= =0A= Takeshi Takahashi=0A= National Institute of Information and Communications Technology=0A= 4-2-1 Nukui-Kitamachi Koganei=0A= 184-8795 Tokyo=0A= Japan=0A= =0A= Phone: +80 423 27 5862=0A= Email: takeshi_takahashi@nict.go.jp=0A= =0A= =0A= Kent Landfield=0A= McAfee=0A= =0A= Email: Kent_Landfield@McAfee.com=0A= =0A= =0A= Thomas Millar=0A= US CERT=0A= =0A= Email: thomas.millar@us-cert.gov=0A= =0A= =0A= Youki Kadobayashi=0A= National Institute of Information and Communications Technology=0A= 4-2-1 Nukui-Kitamachi Koganei=0A= 184-8795 Tokyo=0A= Japan=0A= =0A= Phone: +80 423 27 5862=0A= Email: youki-k@is.aist-nara.ac.jp=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Takahashi, et al. Expires February 27, 2012 [Page 21]=0A= =0C=0A= ------=_NextPart_000_0052_01CC6649.1B91D690-- From turners@ieca.com Mon Aug 29 07:46:06 2011 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 3415E21F84D1 for ; Mon, 29 Aug 2011 07:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1K0EuKZMFw3 for ; Mon, 29 Aug 2011 07:46:05 -0700 (PDT) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by ietfa.amsl.com (Postfix) with SMTP id BC5A521F84CE for ; Mon, 29 Aug 2011 07:46:05 -0700 (PDT) Received: from [98.139.91.61] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 29 Aug 2011 14:47:29 -0000 Received: from [98.139.91.18] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 29 Aug 2011 14:47:29 -0000 Received: from [127.0.0.1] by omp1018.mail.sp2.yahoo.com with NNFMP; 29 Aug 2011 14:47:29 -0000 X-Yahoo-Newman-Id: 915428.94329.bm@omp1018.mail.sp2.yahoo.com Received: (qmail 30362 invoked from network); 29 Aug 2011 14:47:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314629249; bh=FF1pAo9JZ4ALWGOmhx9m3yYtMHEZGpFzMq64XnIUL6U=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding; b=pazD5pWN9qvrFijZNFErMIDnz78xc8I9e0csHvz3FNOSSR7yavRaSTSqZ4mW/UfXfLZt3izDf5KUZA8U4rWxqeA66K4ygnkX2aOqO2jqaseZoklyhMphs/uUN+ppQs5rk9zXVrHuB6nP5P9j6KrsL6A/4TG+8C81GBNelJYU3us= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dPnZZPwVM1m0VE7eXazBjsGQGf7aLA05H6HWBoMTbQiOp2o T.PSARVZCCWP4FY6w9KQWq1oYd7UvkKifb5SBCXP3l199SwGp78nGQUwUBkO 0XcBSdw8gGQkIEc1WVN9A1jlLjSZIUuMOhztYPGJBHjYo3yENRc5dGbDYrn8 B3pSoh3B4wXt7pmsMdDDupWZz0FiHlT0dUy4yF4ycjV6EKmRtiEAPS5dMGOO luEakF_i7FlPJxOc0xz6_54Yjd5zmTWu2PxhaRAHV8nDo5IFn8a_k.89uHch 7Ak7zV3dpe5tzgZpCPDt3tCDIsCDPW6M_ZpHZIQ0V2sIvRLYTnbIul05LDtg IJ1.BJTDZD.FkH_nHjZPaLvrSTWf8jN4AFyCG4KWEikgomoE6ajtJtvIlOQi YyjBr8.NIOw1MTUqTTTukaOo0PpY2qMeGnl4f X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.231.115.53 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 29 Aug 2011 07:47:29 -0700 PDT Message-ID: <4E5BA67F.4040809@ieca.com> Date: Mon, 29 Aug 2011 10:47:27 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mile@ietf.org References: <20110829094414.11609.57583.idtracker@ietfa.amsl.com> In-Reply-To: <20110829094414.11609.57583.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110829094414.11609.57583.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mile] Fwd: I-D Action: draft-trammell-mile-rfc6046-bis-00.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, 29 Aug 2011 14:46:06 -0000 FYI -------- Original Message -------- Subject: I-D Action: draft-trammell-mile-rfc6046-bis-00.txt Date: Mon, 29 Aug 2011 02:44:14 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transport of Real-time Inter-network Defense (RID) Messages Author(s) : Kathleen M. Moriarty Brian H. Trammell Filename : draft-trammell-mile-rfc6046-bis-00.txt Pages : 7 Date : 2011-08-29 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. This document updates the previous [RFC6046] to change the intended status to Proposed Standard, and to reference the updated RID specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-trammell-mile-rfc6046-bis-00.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-trammell-mile-rfc6046-bis-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Thomas.Millar@us-cert.gov Tue Aug 30 07:18:03 2011 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 81A9B21F8B74 for ; Tue, 30 Aug 2011 07:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 v7UYot9T6eBq for ; Tue, 30 Aug 2011 07:18:02 -0700 (PDT) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [208.73.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id BBC6321F8B67 for ; Tue, 30 Aug 2011 07:18:02 -0700 (PDT) Received: from daphne.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4581B3F214; Tue, 30 Aug 2011 14:19:29 +0000 (UTC) Received: from dabba.bronze.us-cert.gov (dabba.bronze.us-cert.gov [192.168.16.121]) by daphne.brass.us-cert.gov (Postfix) with ESMTP id 375933F20F; Tue, 30 Aug 2011 14:19:29 +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 2CF3D6E456; Tue, 30 Aug 2011 14:19:29 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by needle.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 09:19:28 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Aug 2011 09:19:28 -0500 Message-ID: <5EA5E378841F7043B9815EE1E6FAAB8F0EA62D@hive.bronze.us-cert.gov> In-Reply-To: <5EA5E378841F7043B9815EE1E6FAAB8F0E9D87@hive.bronze.us-cert.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] contemplating data sharing restrictions/markings thread-index: AcwaIrGa65EWKEinRrCDP8sCrujK3gFbethgEeH2J+A= References: <098401cc163d$49834ea0$dc89ebe0$@org><01F2CC27166A334EB9D7F7283BD2D8794374E7C170@GSCMAMP01EX.firmwide.corp.gs.com><0ee401cc19c3$779a2690$66ce73b0$@org><0AB12AFE-60D9-4306-8D9F-BBEA21D29D3C@cloudsecurityalliance.org> <5EA5E378841F7043B9815EE1E6FAAB8F0E9D87@hive.bronze.us-cert.gov> From: To: X-OriginalArrivalTime: 30 Aug 2011 14:19:28.0954 (UTC) FILETIME=[D44069A0:01CC671F] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18354.007 X-TM-AS-Result: No--25.889-5.0-31-1 X-imss-scan-details: No--25.889-5.0-31-1 Cc: idxwg@nicwg.org Subject: Re: [mile] contemplating data sharing restrictions/markings 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, 30 Aug 2011 14:18:03 -0000 So - to restart the conversation about TLP, specifically regarding the work being pursued via MILE: 1. I think there would be value in explicit guidance tying the IODEF Restriction class enumerations (or an explicit extension of the Restriction class) to the TLP colors. This is an example of equivalence that I drafted a while back: TLP Color =3D IODEF Restriction value TLP WHITE =3D 1. public. There are no restrictions placed in the information. TLP AMBER =3D 2. need-to-know. The information may be shared with other parties that are involved in the incident as determined by the recipient of this document (e.g., multiple victim sites can be informed of each other). TLP RED =3D 3. private. The information may not be shared. TLP GREEN =3D 4. default. The information can be shared according to an information disclosure policy pre-arranged by the communicating parties. This leaves a little more wiggle room than most end users/originators would probably be comfortable with, however, and I believe there is room for more detailed guidance to sources/originators on how to use TLP (vice recipient guidance, which seems to be fairly straightforward). So an ID explaining all of this is probably in order. 2. A colleague also brought to my attention the other day that TLP colors are used in certain exchanges as a sort of Chatham House Rule substitute. This can result in confusion if an entire piece of correspondence is marked TLP RED just to ensure the identity of the contact doesn't travel outside of the exchange, while the body contains items of interest that should ostensibly be traveling as TLP GREEN or even TLP WHITE. In IODEF, since Restriction can be set at a fairly granular level as well as at the root, one way to achieve the desired goal could be setting the Contact Class as private/RED and the Incident Class to default/GREEN; I think there would also be value in explaining a couple of use cases like this in any draft that goes forward. 3. To John's points below - there is also a need for more explicit expectations around TLP designators and procedures so that they can be consistently be observed by software. I think this is doable within the bounds of TLP, but from discussions with other US-CERT folks dealing with databases of indicators and signatures of varying sensitivity, there is a long tail of possible audiences/regions/organizations that an originator might share with that becomes difficult to account for, especially when so many trust relationships tend to fluctuate. Do we think these issues can/should be tackled in a single digestible document, or broken up? US lvl 14 civil servant LFCA. - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Thomas.Millar@us-cert.gov Sent: Tuesday, May 31, 2011 8:49 AM To: jhowie@cloudsecurityalliance.org; kathleen.moriarty@emc.com Cc: idxwg@nicwg.org; mile@ietf.org Subject: Re: [mile] contemplating data sharing restrictions/markings I thought TLP was perfect for humans too, until I watched them use it in exercises and then in real world sharing practices. People can't even agree on what RED means - may be one case where the abstraction layer/mnemonic that the colors ostensibly provide is actually an obstacle to understanding the system. BTW John, I missed majordomo yelling at me so your cross-list posting didn't go through. Would you like me to sub you to the IDXWG as well? - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of John Howie Sent: Tuesday, May 24, 2011 10:56 AM To: Cc: ; mile@ietf.org Subject: Re: [mile] contemplating data sharing restrictions/markings Hi Pat, For CloudSIRT (a Cloud Security Alliance initiative) we settled on the four color TLP. I agree that the TLP is somewhat limited, but it is perfect for use by humans. I would say that it is not appropriate for automated systems, as it lacks many of the attributes that you have observed codified into email messages and verbal instructions in an ad hoc fashion. Additionally, automated systems are perfect for controlling the dissemination of information through technologies such as DRM and DLP, both which require the use of attributes or metadata to communicate policy surrounding the information. What this means is you need two systems - one for humans and one for automated systems. There needs to be some parity between the systems, and an easy conversion mechanism. For example, when I read a bulletin from an automated system I want the policy attached to that information translated into the TLP or equivalent system, and I want to be able to easily select policy based on the TLP or equivalent when I create a bulletin (in other words, I do not want to specify a number of attributes I do not fully understand). Regards, John Sent from my iPad. From kathleen.moriarty@emc.com Wed Aug 31 00:10:42 2011 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 9B0C621F8C66 for ; Wed, 31 Aug 2011 00:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 UVZ9i4vMmhEF for ; Wed, 31 Aug 2011 00:10:41 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4121F8C3D for ; Wed, 31 Aug 2011 00:10:40 -0700 (PDT) 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 p7V7C8Wv007727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2011 03:12:08 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 31 Aug 2011 03:11:49 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.221.47.158]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7V7Blg9021004; Wed, 31 Aug 2011 03:11:47 -0400 Received: from mx06a.corp.emc.com ([169.254.1.159]) by mxhub29.corp.emc.com ([128.221.47.158]) with mapi; Wed, 31 Aug 2011 03:11:44 -0400 From: To: , Date: Wed, 31 Aug 2011 03:11:46 -0400 Thread-Topic: [mile] contemplating data sharing restrictions/markings Thread-Index: AcwaIrGa65EWKEinRrCDP8sCrujK3gFbethgEeH2J+AAJQM34A== Message-ID: References: <098401cc163d$49834ea0$dc89ebe0$@org><01F2CC27166A334EB9D7F7283BD2D8794374E7C170@GSCMAMP01EX.firmwide.corp.gs.com><0ee401cc19c3$779a2690$66ce73b0$@org><0AB12AFE-60D9-4306-8D9F-BBEA21D29D3C@cloudsecurityalliance.org> <5EA5E378841F7043B9815EE1E6FAAB8F0E9D87@hive.bronze.us-cert.gov>, <5EA5E378841F7043B9815EE1E6FAAB8F0EA62D@hive.bronze.us-cert.gov> In-Reply-To: <5EA5E378841F7043B9815EE1E6FAAB8F0EA62D@hive.bronze.us-cert.gov> 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: idxwg@nicwg.org Subject: Re: [mile] contemplating data sharing restrictions/markings 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, 31 Aug 2011 07:10:42 -0000 Thank you, Tom. I agree and think a guidance document for handling TLP is = needed. I like the mapping that you provided to the restriction class. Th= is usage is consistent with RID guidance in terms of how you decide to encr= ypt portions of an IODEF document or the entire document based on the restr= ictions set. By using the restriction class and building on RID guidance, = we can maintain a consistent rule set for users and developers (your though= ts align with RID in this usage). In reviewing the definitions for CloudSIRT's TLP, they also include groups = of users who may receive the incident information. This could easily be do= ne through guidance mapping to the RIDPolicy elements. The data privacy marking specification may add some additional markers that= may or may not be applicable to TLP as well (I think we can keep them sepa= rate - but be able to use them together). Could we have a volunteer to build out a guidance document for the use of T= LP? =20 Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Thomas.Mil= lar@us-cert.gov [Thomas.Millar@us-cert.gov] Sent: Tuesday, August 30, 2011 10:19 AM To: mile@ietf.org Cc: idxwg@nicwg.org Subject: Re: [mile] contemplating data sharing restrictions/markings So - to restart the conversation about TLP, specifically regarding the work being pursued via MILE: 1. I think there would be value in explicit guidance tying the IODEF Restriction class enumerations (or an explicit extension of the Restriction class) to the TLP colors. This is an example of equivalence that I drafted a while back: TLP Color =3D IODEF Restriction value TLP WHITE =3D 1. public. There are no restrictions placed in the information. TLP AMBER =3D 2. need-to-know. The information may be shared with other parties that are involved in the incident as determined by the recipient of this document (e.g., multiple victim sites can be informed of each other). TLP RED =3D 3. private. The information may not be shared. TLP GREEN =3D 4. default. The information can be shared according to an information disclosure policy pre-arranged by the communicating parties. This leaves a little more wiggle room than most end users/originators would probably be comfortable with, however, and I believe there is room for more detailed guidance to sources/originators on how to use TLP (vice recipient guidance, which seems to be fairly straightforward). So an ID explaining all of this is probably in order. 2. A colleague also brought to my attention the other day that TLP colors are used in certain exchanges as a sort of Chatham House Rule substitute. This can result in confusion if an entire piece of correspondence is marked TLP RED just to ensure the identity of the contact doesn't travel outside of the exchange, while the body contains items of interest that should ostensibly be traveling as TLP GREEN or even TLP WHITE. In IODEF, since Restriction can be set at a fairly granular level as well as at the root, one way to achieve the desired goal could be setting the Contact Class as private/RED and the Incident Class to default/GREEN; I think there would also be value in explaining a couple of use cases like this in any draft that goes forward. 3. To John's points below - there is also a need for more explicit expectations around TLP designators and procedures so that they can be consistently be observed by software. I think this is doable within the bounds of TLP, but from discussions with other US-CERT folks dealing with databases of indicators and signatures of varying sensitivity, there is a long tail of possible audiences/regions/organizations that an originator might share with that becomes difficult to account for, especially when so many trust relationships tend to fluctuate. Do we think these issues can/should be tackled in a single digestible document, or broken up? US lvl 14 civil servant LFCA. - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Thomas.Millar@us-cert.gov Sent: Tuesday, May 31, 2011 8:49 AM To: jhowie@cloudsecurityalliance.org; kathleen.moriarty@emc.com Cc: idxwg@nicwg.org; mile@ietf.org Subject: Re: [mile] contemplating data sharing restrictions/markings I thought TLP was perfect for humans too, until I watched them use it in exercises and then in real world sharing practices. People can't even agree on what RED means - may be one case where the abstraction layer/mnemonic that the colors ostensibly provide is actually an obstacle to understanding the system. BTW John, I missed majordomo yelling at me so your cross-list posting didn't go through. Would you like me to sub you to the IDXWG as well? - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of John Howie Sent: Tuesday, May 24, 2011 10:56 AM To: Cc: ; mile@ietf.org Subject: Re: [mile] contemplating data sharing restrictions/markings Hi Pat, For CloudSIRT (a Cloud Security Alliance initiative) we settled on the four color TLP. I agree that the TLP is somewhat limited, but it is perfect for use by humans. I would say that it is not appropriate for automated systems, as it lacks many of the attributes that you have observed codified into email messages and verbal instructions in an ad hoc fashion. Additionally, automated systems are perfect for controlling the dissemination of information through technologies such as DRM and DLP, both which require the use of attributes or metadata to communicate policy surrounding the information. What this means is you need two systems - one for humans and one for automated systems. There needs to be some parity between the systems, and an easy conversion mechanism. For example, when I read a bulletin from an automated system I want the policy attached to that information translated into the TLP or equivalent system, and I want to be able to easily select policy based on the TLP or equivalent when I create a bulletin (in other words, I do not want to specify a number of attributes I do not fully understand). Regards, John Sent from my iPad. _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From inacio@cert.org Wed Aug 31 05:27:19 2011 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 7F7D621F8853 for ; Wed, 31 Aug 2011 05:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 ihW7FnZ7Mp7l for ; Wed, 31 Aug 2011 05:27:18 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0421F8862 for ; Wed, 31 Aug 2011 05:27:17 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1294) with ESMTP id p7VCSf8x028697; Wed, 31 Aug 2011 08:28:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1314793721; bh=VGqv6C/bj80UupX4+0zkMVhvWwk6Bc0PY344N2tiVfA=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=MMw3Ancz/ORP7VDsv2OybVzg8afg5yMdpkKXwpO/jBc0eUPlIPnsorJgFV11YakKH j6bQkAPzteFzbk5u4dk0lbFTI6N/68tBLiddR76yZshBVCrfCmX2n8+m7813nNQ6gs 5r+ePESs7gVXusns0+5qxuBt9l8Id3P4Gpf4uMGA= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1348) with ESMTP id p7VCSf4K003814; Wed, 31 Aug 2011 08:28:41 -0400 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Wed, 31 Aug 2011 08:28:40 -0400 From: Chris Inacio To: " " Date: Wed, 31 Aug 2011 08:28:49 -0400 Thread-Topic: [mile] LawEnforcement and jurisdiction Thread-Index: Acxn2YRQ9VmhrWH1T2qvBniKh13u4w== Message-ID: <468FF8D9-BD53-4E30-8E0B-95ED3B5D7DA8@cert.org> References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com> <594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com> , <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672AAB@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672AAB@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 Cc: "MILE@ietf.org" Subject: Re: [mile] LawEnforcement and jurisdiction 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, 31 Aug 2011 12:27:19 -0000 I have a quick thought exercise question related to PII. IP addresses in the US are *not* PII. IP addresses in the EU *are* PII. =20 If an incident gets generated in the US, and it gets shared into the EU, wh= at is the state of the IP addresses with regards to PII? How does it change when: we geolocate the IP addresses to both be in the US? we geolocate an IP address to be in the EU? If one address is in the US and one in the EU, when an EU entity wants to s= hare information back to the US on the incident, do they have to drop the I= P address? I used IP addresses as a straw man, but it could be virtually any data elem= ent, right? IETF defines protocols. But to get the protocol right, we obviously need t= o understand how to use it. I would argue a separate definition related to= IODEF data types that can map jurisdiction & data type to handling require= ments would be a good plan. Something that could inform on wether a datum i= s PII in jurisdiction or might be considered sensitive and require encrypti= on, etc. Thoughts? Complaints? Chris Inacio On Aug 24, 2011, at 11:16 AM, w= rote: > Kathleen, >=20 >> I believe this is out-of-scope for RID, but the guidance may use options= included in RID like the use >> of the IODEF:restriction attribute to require encryption. >=20 > I believe that at least Brian, you and I are in violent agreement that th= is sort of law enforcement > iteration scenario is out-of-scope for core RID. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Wednesday, August 24, 2011 10:59 AM >> To: Black, David >> Cc: MILE@ietf.org >> Subject: RE: LawEnforcement and jurisdiction >>=20 >> Hello David, >>=20 >> Thank you for the additional comments. >>=20 >> Iteration would be handled through the same method as other instances of= iteration with updated >> contacts and the appropriate use of signatures for tracking, etc. One L= awEnforcement entity to >> another would be similar to a PeertoPeer,which is also not listed explic= itly in this section as >> considerations are covered under other headings. >>=20 >> I believe the use cases being raised by both you and Brian fall into the= area that will be addressed >> by the data classification/marking extensions that include privacy consi= derations by Dr. Katherine >> Goodier and Gaus Rajnovic. >>=20 >> At the start of the MILE list, there were three separate options propose= d for handling markings and >> restrictions for data privacy laws of various countries. The use cases = you are referring to are >> specific to ones that contain privacy information as categorized by a co= untry as the regulations are >> specific to personally identifiable information (PII). This may not app= ly to all incidents that cross >> boarders of various countries. If there is no PII (according to the def= initions in the appropriate >> regulations - they vary slightly from one to another having read many of= them), then there would not >> be any special handling considerations. >>=20 >> If PII exists, then a marking would be used according to the extension t= o be developed specifications. >> The option I like from the 3 previously proposed to the list was that yo= u would list the country code >> (and state for the US) for the PII included in the incident. From this,= the appropriate >> considerations can be applied to the data according to the requirements = of that country and where the >> data rests or s transferred to at the point of a decision. The requirem= ents are typically interpreted >> by the lawyers/compliance folks of the organization handing the data at = the time (as they are >> responsible for mis-handling). It would be important to have this handl= ed at the SP (SP used >> generically as in RID-bis) sending the data as there may be new regulati= ons that apply in some >> situations, like safe-harbour as data goes from Europe to the US for exa= mple as opposed to >> requirements that may be in place between nations in Europe. >>=20 >> I believe this is out-of-scope for RID, but the guidance may use options= included in RID like the use >> of the IODEF:restriction attribute to require encryption. >>=20 >> Do others have opinions here? Should guidance/markings come in the data= classification/marking >> extension (may have a different name when published)? >>=20 >> Thank you, >> Kathleen >>=20 >> ________________________________________ >> From: Black, David >> Sent: Wednesday, August 24, 2011 10:08 AM >> To: Moriarty, Kathleen >> Cc: MILE@ietf.org >> Subject: LawEnforcement and jurisdiction >>=20 >> Hi Kathleen, >>=20 >> I have a use case question about your suggested text: >>=20 >>> I added the following to the description of the "LawEnforcement" enumer= ation per David's suggestion: >>> "If the law enforcement agency resides within a different nation that t= he sending entity, the >>> "AcrossNationalBoundaries" enumeration MUST also be set." >>=20 >> How does iteration among cooperating law enforcement agencies work? >>=20 >> To build on Brian's example, suppose the Kantonspolizei Z=FCrich sends t= he incident to one of the >> Italian national police forces, who in turn sends the incident onward to= the US FBI. Among the entity >> that originated the incident report, and these two EU-resident law enfor= cement agencies, which one is >> responsible for ensuring compliance with EU data protection/privacy requ= irements and setting the >> appropriate enumeration value to indicate that this has been done? >>=20 >> A plausible answer is that the entity that sends the data outside the EU= shall do this (one of the >> Italian national police forces in the example), and the upstream entitie= s should (may?) do this if >> they have reason to believe that the incident handling is likely to cros= s EU boundaries (e.g., trace >> identifies a source in a US block of IP addresses) and scrubbing the dat= a early in the incident >> handling will not compromise handling effectiveness. >>=20 >> I think some of this is covered in the draft - "7.6. Privacy Concerns a= nd System Use Guidelines," >> e.g., the paragraph that begins with "Intra-consortium RID communication= s raise additional issues, >> especially when the peering consortiums reside in different regions or n= ations", but that doesn't seem >> to cover law enforcement agencies. >>=20 >> Beyond this, I think Brian's commentary suggests that a single jurisdict= ional ENUM value is >> insufficient: >>=20 >>> I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. >>> For example, EU organizations in countries implementing EU data protect= ion directives are more free >> to >>> exchange data with each other than with organizations outside (and this= in and of itself is subject >> to >>> exceptions, cf. "EU safe harbor" provisions, or operational exceptions = for network security >>> information). So, data could cross the German/Austrian border, for exam= ple, but be subject to far >> less >>> restriction than crossing the German/American border. >>=20 >> It appears that a value is needed that unambiguously indicates that the = incident data complies with >> requirements for leaving the EU (without use of an exception), e.g., suc= h a value would assist the >> German authorities in demonstrating incident handling system compliance = in an EU data >> protection/privacy audit. Beyond that, the German authorities may need = another value to differentiate >> data that must stay within Germany (or even the German agency handling t= he data) vs. can be sent to >> Austria - that value would not promise compliance with data requirements= for leaving the EU. >>=20 >> Unfortunately, this is starting to look like an invitation to a tar pit,= as values are likely to be >> needed for a plethora of national data protection/privacy laws and regul= ations. IMHO, IANA is not a >> good place to maintain a registry of data protection/privacy laws and re= gulations. Is some other >> entity already doing this in a fashion that can be pointed to? >>=20 >> Thanks, >> --David >>=20 >>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= kathleen.moriarty@emc.com >>> Sent: Wednesday, August 24, 2011 6:25 AM >>> To: tony@yaanatech.com; trammell@tik.ee.ethz.ch >>> Cc: MILE@ietf.org >>> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions >>>=20 >>> Thank you Brian and Tony for the comments on the use of LawEnforement. = It seems from these >> comments, >>> we should use only one indicator for this field, if others agree/disagr= ee, please post to the list. >>>=20 >>> Tony suggests the use of "Authority". Is this more appropriate than "L= awEnforcement"? >>>=20 >>> Also, Brian raised another question on an enumeration that is in RFC604= 5 in RIDPolicy. Should >>> "AcrossNationalBoundaries" be changed to "AcrossJuristictionalBoundarie= s" or some other indicator >> for >>> this marker? >>>=20 >>> I also agree that the contact information will be provided, so I think = using a more generic marker >> is >>> appropriate. Is there agreement/disagreement on this point? >>>=20 >>> Next for the handling of data between countries where you get into priv= acy considerations, safe >>> harbor, etc. I believe this will be handled in the extension on data m= arkings from Dr. Katherine >>> Goodier and Gaus Rajnovic. They should be able to match up any markers= with guidance on how to set >>> the IODEF:restriction appropriately for the various markers used so tha= t encryption can be >>> appropriately used at the RID layer with the new guidance. Could Kathe= rine and/or Gaus confirm? >>>=20 >>> I had a little time and wrote up text to address the PKI questions from= David and will send those >> out >>> a little later. >>>=20 >>> Thank you! >>> Kathleen >>>=20 >>> ________________________________________ >>> From: Tony Rutkowski [tony@yaanatech.com] >>> Sent: Wednesday, August 24, 2011 6:09 AM >>> To: Brian Trammell >>> Cc: Moriarty, Kathleen; MILE@ietf.org >>> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list discu= ssions >>>=20 >>> I'd suggest that anything related to this subject be >>> kept as generic as possible. The capabilities being >>> supported are subject concurrently to many different >>> legal requirements that are global, regional, national, >>> sub-national, and local in nature. The authorities involved >>> consist of a great many kinds of government agencies, >>> including officers of a court in the case of eDiscovery and >>> other kinds of civil proceedings. >>>=20 >>> The ETSI global eWarrant standards work ultimately >>> allowed for multiple generic terms for its interface, >>> as depicted in the diagram below. You should consider >>> the possibility of using only "authority." >>>=20 >>> [cid:part1.09080503.05030907@yaanatech.com] >>>=20 >>>=20 >>>=20 >>>=20 >>> On 8/24/2011 11:57 AM, Brian Trammell wrote: >>>=20 >>> I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. >>> For example, EU organizations in countries implementing EU data protect= ion directives are more free >> to >>> exchange data with each other than with organizations outside (and this= in and of itself is subject >> to >>> exceptions, cf. "EU safe harbor" provisions, or operational exceptions = for network security >>> information). So, data could cross the German/Austrian border, for exam= ple, but be subject to far >> less >>> restriction than crossing the German/American border. >>>=20 >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From Thomas.Millar@us-cert.gov Wed Aug 31 09:48:21 2011 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 B97E221F8D74 for ; Wed, 31 Aug 2011 09:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=1.372, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 AzQumTE75TGO for ; Wed, 31 Aug 2011 09:48:20 -0700 (PDT) Received: from daphne.brass.us-cert.gov (daphne.brass.us-cert.gov [208.73.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id 571DD21F8D56 for ; Wed, 31 Aug 2011 09:48:19 -0700 (PDT) Received: from daphne.brass.us-cert.gov (localhost.localdomain [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 0ABFD3F1B9; Wed, 31 Aug 2011 16:49:50 +0000 (UTC) Received: from yabba.bronze.us-cert.gov (yabba.bronze.us-cert.gov [192.168.2.22]) by daphne.brass.us-cert.gov (Postfix) with ESMTP id D0AAD3F18B; Wed, 31 Aug 2011 16:49:49 +0000 (UTC) Received: from rubicon.bronze.us-cert.gov (unknown [192.168.2.160]) by yabba.bronze.us-cert.gov (Postfix) with ESMTP id A6DFC30066; Wed, 31 Aug 2011 16:49:49 +0000 (UTC) Received: from hive.bronze.us-cert.gov ([192.168.16.108]) by rubicon.bronze.us-cert.gov with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Aug 2011 12:49:49 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Aug 2011 11:49:48 -0500 Message-ID: <5EA5E378841F7043B9815EE1E6FAAB8F0EA66A@hive.bronze.us-cert.gov> In-Reply-To: <468FF8D9-BD53-4E30-8E0B-95ED3B5D7DA8@cert.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mile] LawEnforcement and jurisdiction Thread-Index: Acxn2YRQ9VmhrWH1T2qvBniKh13u4wAIqaGQ References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com><594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com>, <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@MX14A.corp.emc.com><7C4DFCE962635144B8FAE8CA11D0BF1E0589672AAB@MX14A.corp.emc.com> <468FF8D9-BD53-4E30-8E0B-95ED3B5D7DA8@cert.org> From: To: , X-OriginalArrivalTime: 31 Aug 2011 16:49:49.0617 (UTC) FILETIME=[FF661A10:01CC67FD] X-TM-AS-Product-Ver: IMSS-7.1.0.1224-6.8.0.1017-18356.006 X-TM-AS-Result: No--31.853-5.0-31-1 X-imss-scan-details: No--31.853-5.0-31-1 Cc: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction 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, 31 Aug 2011 16:48:21 -0000 I don't think I agree that any of this is in the scope of a transport = protocol or exchange format. Recipients on either end are trusted to = know what to do with different types of information when they process = it; it sounds like what you're describing puts the workload of = estimating recipient's sensitivity and privacy on the originator, which = seems impossible to get consistently right, even if we could get every = sovereign participant to submit their data sensitivity markings, rules = and regulations with some form of centralized registry. The US government is currently in the midst of a multi-year project just = to try and identify and consolidate all the statutorily supported = definitions of "sensitive but unclassified" information and consolidate = guidance on how all those identified categories can be protected - and = still none of it carries any weight with our national sunshine laws. We = are chasing a moving target before we've even begun. I truly believe the best (only?) engineering solution here is to provide = the basics and punt the details to the implementers and their local = requirements. - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870=20 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of = Chris Inacio Sent: Wednesday, August 31, 2011 8:29 AM To: Cc: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction I have a quick thought exercise question related to PII. IP addresses in the US are *not* PII. IP addresses in the EU *are* PII. = =20 If an incident gets generated in the US, and it gets shared into the EU, = what is the state of the IP addresses with regards to PII? How does it change when: we geolocate the IP addresses to both be in the US? we geolocate an IP address to be in the EU? If one address is in the US and one in the EU, when an EU entity wants = to share information back to the US on the incident, do they have to = drop the IP address? I used IP addresses as a straw man, but it could be virtually any data = element, right? IETF defines protocols. But to get the protocol right, we obviously = need to understand how to use it. I would argue a separate definition = related to IODEF data types that can map jurisdiction & data type to = handling requirements would be a good plan. Something that could inform = on wether a datum is PII in jurisdiction or might be considered = sensitive and require encryption, etc. Thoughts? Complaints? Chris Inacio On Aug 24, 2011, at 11:16 AM, = wrote: > Kathleen, >=20 >> I believe this is out-of-scope for RID, but the guidance may use=20 >> options included in RID like the use of the IODEF:restriction = attribute to require encryption. >=20 > I believe that at least Brian, you and I are in violent agreement that = > this sort of law enforcement iteration scenario is out-of-scope for = core RID. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Wednesday, August 24, 2011 10:59 AM >> To: Black, David >> Cc: MILE@ietf.org >> Subject: RE: LawEnforcement and jurisdiction >>=20 >> Hello David, >>=20 >> Thank you for the additional comments. >>=20 >> Iteration would be handled through the same method as other instances = >> of iteration with updated contacts and the appropriate use of=20 >> signatures for tracking, etc. One LawEnforcement entity to another=20 >> would be similar to a PeertoPeer,which is also not listed explicitly = in this section as considerations are covered under other headings. >>=20 >> I believe the use cases being raised by both you and Brian fall into=20 >> the area that will be addressed by the data classification/marking=20 >> extensions that include privacy considerations by Dr. Katherine = Goodier and Gaus Rajnovic. >>=20 >> At the start of the MILE list, there were three separate options=20 >> proposed for handling markings and restrictions for data privacy laws = >> of various countries. The use cases you are referring to are=20 >> specific to ones that contain privacy information as categorized by a = >> country as the regulations are specific to personally identifiable=20 >> information (PII). This may not apply to all incidents that cross=20 >> boarders of various countries. If there is no PII (according to the = definitions in the appropriate regulations - they vary slightly from one = to another having read many of them), then there would not be any = special handling considerations. >>=20 >> If PII exists, then a marking would be used according to the = extension to be developed specifications. >> The option I like from the 3 previously proposed to the list was that = >> you would list the country code (and state for the US) for the PII=20 >> included in the incident. From this, the appropriate considerations=20 >> can be applied to the data according to the requirements of that=20 >> country and where the data rests or s transferred to at the point of=20 >> a decision. The requirements are typically interpreted by the=20 >> lawyers/compliance folks of the organization handing the data at the=20 >> time (as they are responsible for mis-handling). It would be=20 >> important to have this handled at the SP (SP used generically as in = RID-bis) sending the data as there may be new regulations that apply in = some situations, like safe-harbour as data goes from Europe to the US = for example as opposed to requirements that may be in place between = nations in Europe. >>=20 >> I believe this is out-of-scope for RID, but the guidance may use=20 >> options included in RID like the use of the IODEF:restriction = attribute to require encryption. >>=20 >> Do others have opinions here? Should guidance/markings come in the=20 >> data classification/marking extension (may have a different name when = published)? >>=20 >> Thank you, >> Kathleen >>=20 >> ________________________________________ >> From: Black, David >> Sent: Wednesday, August 24, 2011 10:08 AM >> To: Moriarty, Kathleen >> Cc: MILE@ietf.org >> Subject: LawEnforcement and jurisdiction >>=20 >> Hi Kathleen, >>=20 >> I have a use case question about your suggested text: >>=20 >>> I added the following to the description of the "LawEnforcement" = enumeration per David's suggestion: >>> "If the law enforcement agency resides within a different nation=20 >>> that the sending entity, the "AcrossNationalBoundaries" enumeration = MUST also be set." >>=20 >> How does iteration among cooperating law enforcement agencies work? >>=20 >> To build on Brian's example, suppose the Kantonspolizei Z=FCrich = sends=20 >> the incident to one of the Italian national police forces, who in=20 >> turn sends the incident onward to the US FBI. Among the entity that=20 >> originated the incident report, and these two EU-resident law=20 >> enforcement agencies, which one is responsible for ensuring = compliance with EU data protection/privacy requirements and setting the = appropriate enumeration value to indicate that this has been done? >>=20 >> A plausible answer is that the entity that sends the data outside the = >> EU shall do this (one of the Italian national police forces in the=20 >> example), and the upstream entities should (may?) do this if they=20 >> have reason to believe that the incident handling is likely to cross=20 >> EU boundaries (e.g., trace identifies a source in a US block of IP = addresses) and scrubbing the data early in the incident handling will = not compromise handling effectiveness. >>=20 >> I think some of this is covered in the draft - "7.6. Privacy = Concerns and System Use Guidelines," >> e.g., the paragraph that begins with "Intra-consortium RID=20 >> communications raise additional issues, especially when the peering=20 >> consortiums reside in different regions or nations", but that doesn't = seem to cover law enforcement agencies. >>=20 >> Beyond this, I think Brian's commentary suggests that a single=20 >> jurisdictional ENUM value is >> insufficient: >>=20 >>> I would generalize this to "across jurisdictional boundaries," = though I am not exactly certain how. >>> For example, EU organizations in countries implementing EU data=20 >>> protection directives are more free >> to >>> exchange data with each other than with organizations outside (and=20 >>> this in and of itself is subject >> to >>> exceptions, cf. "EU safe harbor" provisions, or operational=20 >>> exceptions for network security information). So, data could cross=20 >>> the German/Austrian border, for example, but be subject to far >> less >>> restriction than crossing the German/American border. >>=20 >> It appears that a value is needed that unambiguously indicates that=20 >> the incident data complies with requirements for leaving the EU=20 >> (without use of an exception), e.g., such a value would assist the=20 >> German authorities in demonstrating incident handling system=20 >> compliance in an EU data protection/privacy audit. Beyond that, the=20 >> German authorities may need another value to differentiate data that = must stay within Germany (or even the German agency handling the data) = vs. can be sent to Austria - that value would not promise compliance = with data requirements for leaving the EU. >>=20 >> Unfortunately, this is starting to look like an invitation to a tar=20 >> pit, as values are likely to be needed for a plethora of national=20 >> data protection/privacy laws and regulations. IMHO, IANA is not a=20 >> good place to maintain a registry of data protection/privacy laws and = regulations. Is some other entity already doing this in a fashion that = can be pointed to? >>=20 >> Thanks, >> --David >>=20 >>=20 >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf = >>> Of kathleen.moriarty@emc.com >>> Sent: Wednesday, August 24, 2011 6:25 AM >>> To: tony@yaanatech.com; trammell@tik.ee.ethz.ch >>> Cc: MILE@ietf.org >>> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list=20 >>> discussions >>>=20 >>> Thank you Brian and Tony for the comments on the use of=20 >>> LawEnforement. It seems from these >> comments, >>> we should use only one indicator for this field, if others = agree/disagree, please post to the list. >>>=20 >>> Tony suggests the use of "Authority". Is this more appropriate than = "LawEnforcement"? >>>=20 >>> Also, Brian raised another question on an enumeration that is in=20 >>> RFC6045 in RIDPolicy. Should "AcrossNationalBoundaries" be changed=20 >>> to "AcrossJuristictionalBoundaries" or some other indicator >> for >>> this marker? >>>=20 >>> I also agree that the contact information will be provided, so I=20 >>> think using a more generic marker >> is >>> appropriate. Is there agreement/disagreement on this point? >>>=20 >>> Next for the handling of data between countries where you get into=20 >>> privacy considerations, safe harbor, etc. I believe this will be=20 >>> handled in the extension on data markings from Dr. Katherine Goodier = >>> and Gaus Rajnovic. They should be able to match up any markers with = >>> guidance on how to set the IODEF:restriction appropriately for the = various markers used so that encryption can be appropriately used at the = RID layer with the new guidance. Could Katherine and/or Gaus confirm? >>>=20 >>> I had a little time and wrote up text to address the PKI questions=20 >>> from David and will send those >> out >>> a little later. >>>=20 >>> Thank you! >>> Kathleen >>>=20 >>> ________________________________________ >>> From: Tony Rutkowski [tony@yaanatech.com] >>> Sent: Wednesday, August 24, 2011 6:09 AM >>> To: Brian Trammell >>> Cc: Moriarty, Kathleen; MILE@ietf.org >>> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list=20 >>> discussions >>>=20 >>> I'd suggest that anything related to this subject be kept as generic = >>> as possible. The capabilities being supported are subject=20 >>> concurrently to many different legal requirements that are global,=20 >>> regional, national, sub-national, and local in nature. The=20 >>> authorities involved consist of a great many kinds of government=20 >>> agencies, including officers of a court in the case of eDiscovery=20 >>> and other kinds of civil proceedings. >>>=20 >>> The ETSI global eWarrant standards work ultimately allowed for=20 >>> multiple generic terms for its interface, as depicted in the diagram = >>> below. You should consider the possibility of using only=20 >>> "authority." >>>=20 >>> [cid:part1.09080503.05030907@yaanatech.com] >>>=20 >>>=20 >>>=20 >>>=20 >>> On 8/24/2011 11:57 AM, Brian Trammell wrote: >>>=20 >>> I would generalize this to "across jurisdictional boundaries," = though I am not exactly certain how. >>> For example, EU organizations in countries implementing EU data=20 >>> protection directives are more free >> to >>> exchange data with each other than with organizations outside (and=20 >>> this in and of itself is subject >> to >>> exceptions, cf. "EU safe harbor" provisions, or operational=20 >>> exceptions for network security information). So, data could cross=20 >>> the German/Austrian border, for example, but be subject to far >> less >>> restriction than crossing the German/American border. >>>=20 >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Aug 31 10:05:26 2011 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 8F2FD21F8DC9 for ; Wed, 31 Aug 2011 10:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.408 X-Spam-Level: X-Spam-Status: No, score=-7.408 tagged_above=-999 required=5 tests=[AWL=1.191, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 7QzUvTXqMmXX for ; Wed, 31 Aug 2011 10:05:25 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E670321F8DB8 for ; Wed, 31 Aug 2011 10:05:24 -0700 (PDT) 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 p7VH038l026643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2011 13:00:03 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 31 Aug 2011 12:59:56 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.221.46.115]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7VGxspj029477; Wed, 31 Aug 2011 12:59:54 -0400 Received: from mx06a.corp.emc.com ([169.254.1.159]) by mxhub07.corp.emc.com ([128.221.46.115]) with mapi; Wed, 31 Aug 2011 12:59:54 -0400 From: To: , , Date: Wed, 31 Aug 2011 12:55:24 -0400 Thread-Topic: [mile] LawEnforcement and jurisdiction Thread-Index: Acxn2YRQ9VmhrWH1T2qvBniKh13u4wAIqaGQAACkv0I= Message-ID: References: , <7C4DFCE962635144B8FAE8CA11D0BF1E05896727AB@MX14A.corp.emc.com><594D9D1F-342E-47BF-BFB4-538F9BB1C07E@tik.ee.ethz.ch>, <4E54CDEC.9070003@yaanatech.com>, <7C4DFCE962635144B8FAE8CA11D0BF1E0589672A1A@MX14A.corp.emc.com><7C4DFCE962635144B8FAE8CA11D0BF1E0589672AAB@MX14A.corp.emc.com> <468FF8D9-BD53-4E30-8E0B-95ED3B5D7DA8@cert.org>, <5EA5E378841F7043B9815EE1E6FAAB8F0EA66A@hive.bronze.us-cert.gov> In-Reply-To: <5EA5E378841F7043B9815EE1E6FAAB8F0EA66A@hive.bronze.us-cert.gov> 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: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction 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, 31 Aug 2011 17:05:26 -0000 I agree with Chris that we need to look at how a protocol is used to get it= right. The proposals so far are providing options that can be consistent = in implementations, where policies (outside of implementations - but allow = for options in implementations) may be applied to the options provided in t= he API or even in the applications. As such, having options in IODEF and RID to enable actions to take place (l= ike encryption of an entire document or section of a document or leaving ou= t data elements) is required in the data format and the API (RID and Transp= ort for RID). Any more thoughts, agreements, disagreements? Thank you, Kathleen ________________________________________ From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of Thomas.Mil= lar@us-cert.gov [Thomas.Millar@us-cert.gov] Sent: Wednesday, August 31, 2011 12:49 PM To: inacio@cert.org; Black, David Cc: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction I don't think I agree that any of this is in the scope of a transport proto= col or exchange format. Recipients on either end are trusted to know what t= o do with different types of information when they process it; it sounds li= ke what you're describing puts the workload of estimating recipient's sensi= tivity and privacy on the originator, which seems impossible to get consist= ently right, even if we could get every sovereign participant to submit the= ir data sensitivity markings, rules and regulations with some form of centr= alized registry. The US government is currently in the midst of a multi-year project just to= try and identify and consolidate all the statutorily supported definitions= of "sensitive but unclassified" information and consolidate guidance on ho= w all those identified categories can be protected - and still none of it c= arries any weight with our national sunshine laws. We are chasing a moving = target before we've even begun. I truly believe the best (only?) engineering solution here is to provide th= e basics and punt the details to the implementers and their local requireme= nts. - Tom Millar, US-CERT thomas.millar@us-cert.gov BB: thomas.millar@dhs.gov / 202-631-1915 24x7: soc@us-cert.gov / 888-282-0870 -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Chr= is Inacio Sent: Wednesday, August 31, 2011 8:29 AM To: Cc: MILE@ietf.org Subject: Re: [mile] LawEnforcement and jurisdiction I have a quick thought exercise question related to PII. IP addresses in the US are *not* PII. IP addresses in the EU *are* PII. If an incident gets generated in the US, and it gets shared into the EU, wh= at is the state of the IP addresses with regards to PII? How does it change when: we geolocate the IP addresses to both be in the US? we geolocate an IP address to be in the EU? If one address is in the US and one in the EU, when an EU entity wants to s= hare information back to the US on the incident, do they have to drop the I= P address? I used IP addresses as a straw man, but it could be virtually any data elem= ent, right? IETF defines protocols. But to get the protocol right, we obviously need t= o understand how to use it. I would argue a separate definition related to= IODEF data types that can map jurisdiction & data type to handling require= ments would be a good plan. Something that could inform on wether a datum i= s PII in jurisdiction or might be considered sensitive and require encrypti= on, etc. Thoughts? Complaints? Chris Inacio On Aug 24, 2011, at 11:16 AM, w= rote: > Kathleen, > >> I believe this is out-of-scope for RID, but the guidance may use >> options included in RID like the use of the IODEF:restriction attribute = to require encryption. > > I believe that at least Brian, you and I are in violent agreement that > this sort of law enforcement iteration scenario is out-of-scope for core = RID. > > Thanks, > --David > >> -----Original Message----- >> From: Moriarty, Kathleen >> Sent: Wednesday, August 24, 2011 10:59 AM >> To: Black, David >> Cc: MILE@ietf.org >> Subject: RE: LawEnforcement and jurisdiction >> >> Hello David, >> >> Thank you for the additional comments. >> >> Iteration would be handled through the same method as other instances >> of iteration with updated contacts and the appropriate use of >> signatures for tracking, etc. One LawEnforcement entity to another >> would be similar to a PeertoPeer,which is also not listed explicitly in = this section as considerations are covered under other headings. >> >> I believe the use cases being raised by both you and Brian fall into >> the area that will be addressed by the data classification/marking >> extensions that include privacy considerations by Dr. Katherine Goodier = and Gaus Rajnovic. >> >> At the start of the MILE list, there were three separate options >> proposed for handling markings and restrictions for data privacy laws >> of various countries. The use cases you are referring to are >> specific to ones that contain privacy information as categorized by a >> country as the regulations are specific to personally identifiable >> information (PII). This may not apply to all incidents that cross >> boarders of various countries. If there is no PII (according to the def= initions in the appropriate regulations - they vary slightly from one to an= other having read many of them), then there would not be any special handli= ng considerations. >> >> If PII exists, then a marking would be used according to the extension t= o be developed specifications. >> The option I like from the 3 previously proposed to the list was that >> you would list the country code (and state for the US) for the PII >> included in the incident. From this, the appropriate considerations >> can be applied to the data according to the requirements of that >> country and where the data rests or s transferred to at the point of >> a decision. The requirements are typically interpreted by the >> lawyers/compliance folks of the organization handing the data at the >> time (as they are responsible for mis-handling). It would be >> important to have this handled at the SP (SP used generically as in RID-= bis) sending the data as there may be new regulations that apply in some si= tuations, like safe-harbour as data goes from Europe to the US for example = as opposed to requirements that may be in place between nations in Europe. >> >> I believe this is out-of-scope for RID, but the guidance may use >> options included in RID like the use of the IODEF:restriction attribute = to require encryption. >> >> Do others have opinions here? Should guidance/markings come in the >> data classification/marking extension (may have a different name when pu= blished)? >> >> Thank you, >> Kathleen >> >> ________________________________________ >> From: Black, David >> Sent: Wednesday, August 24, 2011 10:08 AM >> To: Moriarty, Kathleen >> Cc: MILE@ietf.org >> Subject: LawEnforcement and jurisdiction >> >> Hi Kathleen, >> >> I have a use case question about your suggested text: >> >>> I added the following to the description of the "LawEnforcement" enumer= ation per David's suggestion: >>> "If the law enforcement agency resides within a different nation >>> that the sending entity, the "AcrossNationalBoundaries" enumeration MUS= T also be set." >> >> How does iteration among cooperating law enforcement agencies work? >> >> To build on Brian's example, suppose the Kantonspolizei Z=FCrich sends >> the incident to one of the Italian national police forces, who in >> turn sends the incident onward to the US FBI. Among the entity that >> originated the incident report, and these two EU-resident law >> enforcement agencies, which one is responsible for ensuring compliance w= ith EU data protection/privacy requirements and setting the appropriate enu= meration value to indicate that this has been done? >> >> A plausible answer is that the entity that sends the data outside the >> EU shall do this (one of the Italian national police forces in the >> example), and the upstream entities should (may?) do this if they >> have reason to believe that the incident handling is likely to cross >> EU boundaries (e.g., trace identifies a source in a US block of IP addre= sses) and scrubbing the data early in the incident handling will not compro= mise handling effectiveness. >> >> I think some of this is covered in the draft - "7.6. Privacy Concerns a= nd System Use Guidelines," >> e.g., the paragraph that begins with "Intra-consortium RID >> communications raise additional issues, especially when the peering >> consortiums reside in different regions or nations", but that doesn't se= em to cover law enforcement agencies. >> >> Beyond this, I think Brian's commentary suggests that a single >> jurisdictional ENUM value is >> insufficient: >> >>> I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. >>> For example, EU organizations in countries implementing EU data >>> protection directives are more free >> to >>> exchange data with each other than with organizations outside (and >>> this in and of itself is subject >> to >>> exceptions, cf. "EU safe harbor" provisions, or operational >>> exceptions for network security information). So, data could cross >>> the German/Austrian border, for example, but be subject to far >> less >>> restriction than crossing the German/American border. >> >> It appears that a value is needed that unambiguously indicates that >> the incident data complies with requirements for leaving the EU >> (without use of an exception), e.g., such a value would assist the >> German authorities in demonstrating incident handling system >> compliance in an EU data protection/privacy audit. Beyond that, the >> German authorities may need another value to differentiate data that mus= t stay within Germany (or even the German agency handling the data) vs. can= be sent to Austria - that value would not promise compliance with data req= uirements for leaving the EU. >> >> Unfortunately, this is starting to look like an invitation to a tar >> pit, as values are likely to be needed for a plethora of national >> data protection/privacy laws and regulations. IMHO, IANA is not a >> good place to maintain a registry of data protection/privacy laws and re= gulations. Is some other entity already doing this in a fashion that can b= e pointed to? >> >> Thanks, >> --David >> >> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >>> Of kathleen.moriarty@emc.com >>> Sent: Wednesday, August 24, 2011 6:25 AM >>> To: tony@yaanatech.com; trammell@tik.ee.ethz.ch >>> Cc: MILE@ietf.org >>> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list >>> discussions >>> >>> Thank you Brian and Tony for the comments on the use of >>> LawEnforement. It seems from these >> comments, >>> we should use only one indicator for this field, if others agree/disagr= ee, please post to the list. >>> >>> Tony suggests the use of "Authority". Is this more appropriate than "L= awEnforcement"? >>> >>> Also, Brian raised another question on an enumeration that is in >>> RFC6045 in RIDPolicy. Should "AcrossNationalBoundaries" be changed >>> to "AcrossJuristictionalBoundaries" or some other indicator >> for >>> this marker? >>> >>> I also agree that the contact information will be provided, so I >>> think using a more generic marker >> is >>> appropriate. Is there agreement/disagreement on this point? >>> >>> Next for the handling of data between countries where you get into >>> privacy considerations, safe harbor, etc. I believe this will be >>> handled in the extension on data markings from Dr. Katherine Goodier >>> and Gaus Rajnovic. They should be able to match up any markers with >>> guidance on how to set the IODEF:restriction appropriately for the vari= ous markers used so that encryption can be appropriately used at the RID la= yer with the new guidance. Could Katherine and/or Gaus confirm? >>> >>> I had a little time and wrote up text to address the PKI questions >>> from David and will send those >> out >>> a little later. >>> >>> Thank you! >>> Kathleen >>> >>> ________________________________________ >>> From: Tony Rutkowski [tony@yaanatech.com] >>> Sent: Wednesday, August 24, 2011 6:09 AM >>> To: Brian Trammell >>> Cc: Moriarty, Kathleen; MILE@ietf.org >>> Subject: Re: [mile] RFC6045-bis, update per ITU comments and list >>> discussions >>> >>> I'd suggest that anything related to this subject be kept as generic >>> as possible. The capabilities being supported are subject >>> concurrently to many different legal requirements that are global, >>> regional, national, sub-national, and local in nature. The >>> authorities involved consist of a great many kinds of government >>> agencies, including officers of a court in the case of eDiscovery >>> and other kinds of civil proceedings. >>> >>> The ETSI global eWarrant standards work ultimately allowed for >>> multiple generic terms for its interface, as depicted in the diagram >>> below. You should consider the possibility of using only >>> "authority." >>> >>> [cid:part1.09080503.05030907@yaanatech.com] >>> >>> >>> >>> >>> On 8/24/2011 11:57 AM, Brian Trammell wrote: >>> >>> I would generalize this to "across jurisdictional boundaries," though I= am not exactly certain how. >>> For example, EU organizations in countries implementing EU data >>> protection directives are more free >> to >>> exchange data with each other than with organizations outside (and >>> this in and of itself is subject >> to >>> exceptions, cf. "EU safe harbor" provisions, or operational >>> exceptions for network security information). So, data could cross >>> the German/Austrian border, for example, but be subject to far >> less >>> restriction than crossing the German/American border. >>> >>> >>> _______________________________________________ >>> mile mailing 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