From rdd@cert.org Fri Jan 3 06:43:37 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4A1ADFC9 for ; Fri, 3 Jan 2014 06:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEiFZ24q-XV4 for ; Fri, 3 Jan 2014 06:43:34 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 09B801ADFC8 for ; Fri, 3 Jan 2014 06:43:33 -0800 (PST) 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/1408) with ESMTP id s03EhHTm000337; Fri, 3 Jan 2014 09:43:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1388760197; bh=hx+bde9XLxNCXHP6Km4QZb0jSd1CmVKMyM0avQQI7mc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=aFRQYXTQbJmWK3GKhGhPVT4lVLczgaBc7Vz5ljf34vk5efxg/ORjfX78iLP8JCbx1 TUVC05TkgD400r4q0r42tdQUua941h0KI3BZoyLndGkZSEGZAB9FnaeRKSl4v95oaS tO54qLbW9ahEZMSO6H5hPgO9zxo785QFKuIyWpPg= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s03EhHRY027734; Fri, 3 Jan 2014 09:43:17 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Fri, 3 Jan 2014 09:43:15 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgAA2w8gAAA8aTEAAGjNQAAHVf1gABNk8IAAAQ1DAAArwj+AHQBhoKA= Date: Fri, 3 Jan 2014 14:43:14 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C01481@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Jan 2014 14:43:38 -0000 Hello all and Happy New Year! I wanted to revisit this old thread and bring closure to Dave's question si= nce we're tracking it as Issue #29 (http://trac.tools.ietf.org/wg/mile/trac= /ticket/29). Any thoughts? Roman > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of > Waltermire, David A. > Sent: Thursday, August 08, 2013 3:36 PM > To: Moriarty, Kathleen; Neil Hare-Brown; Panos Kampanakis (pkampana) > Cc: mile@ietf.org > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) >=20 > RFC6545 assumes encapsulation of IODEF in RID. What if IODEF is used > outside of RID? How would the "seal" get addressed then? >=20 > Dave >=20 > > -----Original Message----- > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > Of Moriarty, Kathleen > > Sent: Wednesday, August 07, 2013 6:44 PM > > To: Neil Hare-Brown; Panos Kampanakis (pkampana) > > Cc: mile@ietf.org > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Hi Neil, > > > > Thanks for chiming in. The 'seal' is covered in RID RFC6545 section > > 9.1 through the use of object level security triggered by the > > restriction attribute setting. If you want to discuss that more, we > > can start a new thread so folks can continue on the hash information in= the > data model. > > > > Thanks! > > Kathleen > > ________________________________________ > > From: Neil Hare-Brown [NeilHB@blackthorn.com] > > Sent: Wednesday, August 07, 2013 6:13 PM > > To: Panos Kampanakis (pkampana) > > Cc: Harrington, Christopher; Moriarty, Kathleen; Roman D. Danyliw; > > mile@ietf.org > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > Agreed > > > > There should also be a feature that is a sealing hash (of hashes) so > > that an evidential bundle is maintained as inviolate. > > > > Rgds > > > > Neil HB > > > > On 7 Aug 2013, at 21:48, "Panos Kampanakis (pkampana)" > > wrote: > > > > >> Can this be applied more than once per file depending on which type > > >> of > > hash you are checking? I can have a digitally signed executable where > > the > > MD5 hash of the file is Valid but the signing cert (or CA) is revoked. > > Another common scenario is to attach digital signature from a > > legitimately signed file to a malicious file hoping that the receiving > > party will just see a signature from a trusted CA and not re-compute > > the signature. There is one threat actor we track who uses this fairly > frequently. How would those be handled? > > > > > > Agreed. I think the schema currently can support multiple signatures > > > per > > file. So, IMO that can be done. Put MD5 and PKI sigs for the same > > filename in the same IODEF. Using the watchlist attricbutes the > > predicate AND logic can be enforced also. > > > > > >> Another area of possible concern is required fields. If the > > >> indicator is a file > > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. > > > I've never seen a file hash provided as an indicator without the hash= type. > > > For any ds:Signature references there should be a ds:Reference, when > > these are file hashes. I don't think the hash type would be required > > for ds:KeyInfo as this never used as an indicator by itself, unlike fil= e hash. > > > > > > I agree. I think type should be required in the HashSigDetails. > > > > > > Panos > > > > > > > > > -----Original Message----- > > > From: Harrington, Christopher > > > [mailto:Christopher.Harrington@emc.com] > > > Sent: Wednesday, August 07, 2013 10:03 AM > > > To: Moriarty, Kathleen; Panos Kampanakis (pkampana); Roman D. > > > Danyliw; mile@ietf.org > > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > > > * PGP - S/MIME Signed by an unverified key: 8/7/2013 at 10:03:29 AM > > > > > > To me this is a bit confusing when HashInformation is used to > > > describe both > > the hash of a file (MD5, SHA-1, etc.) and the PKI / PGP hashes. I see > > there is a Boolean for Valid: > > > > > > | BOOL valid |<>--{0..*}--[ds:Signature] > > > > > > Can this be applied more than once per file depending on which type > > > of > > hash you are checking? I can have a digitally signed executable where > > the > > MD5 hash of the file is Valid but the signing cert (or CA) is revoked. > > Another common scenario is to attach digital signature from a > > legitimately signed file to a malicious file hoping that the receiving > > party will just see a signature from a trusted CA and not re-compute > > the signature. There is one threat actor we track who uses this fairly > frequently. How would those be handled? > > > > > > Another area of possible concern is required fields. If the > > > indicator is a file > > hash then the hashing algorithm (MD5, SHA-1, etc.) should be required. > > > I've never seen a file hash provided as an indicator without the hash= type. > > > For any ds:Signature references there should be a ds:Reference, when > > these are file hashes. I don't think the hash type would be required > > for ds:KeyInfo as this never used as an indicator by itself, unlike fil= e hash. > > > > > > > > > Thanks, > > > > > > --Chris > > > > > > Christopher Harrington > > > Consulting Security Engineer > > > GSO - Critical Incident Response Center EMC - Where Information > > > Lives > > > 174 Middlesex Turnpike > > > Bedford, MA 01730 > > > 781-515-5862 (work) > > > 603-583-1585 (cell) > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > > Of Moriarty, Kathleen > > > Sent: Wednesday, August 07, 2013 9:16 AM > > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > > > Thanks, Panos! > > > > > > Others - please chime in on the questions for this message and the > > > scope > > message for IODEF v2. > > > > > > Thank you! > > > Kathleen > > > ________________________________________ > > > From: Panos Kampanakis (pkampana) [pkampana@cisco.com] > > > Sent: Wednesday, August 07, 2013 9:15 AM > > > To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org > > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > > > Thanks Katheleen. > > > > > > Two quick answers. Agreed on the rest. > > > > > > KM> I am not following why the ContactMeansType is part of this > > > KM> question > > > PK> I put it in there as an example of an existing place in 5070 > > > PK> were the > > > same methodology is used. Just to make cleared that what we had in > > > there > > seemed correct as it is in other places. > > > > > > KM> do we need to have filename outside of the container in case > > > KM> there is no > > > signature? > > > PK> Sound good. > > > > > > Panos > > > > > > > > > > > > -----Original Message----- > > > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > > > Sent: Wednesday, August 07, 2013 9:06 AM > > > To: Panos Kampanakis (pkampana); Roman D. Danyliw; mile@ietf.org > > > Subject: RE: Clarity on HashInformation (or HashSigDetails) > > > > > > Hi Roman, Panos, & others, > > > > > > Thanks for starting this discussion. I'll answer below with KM> and > > > with my > > chair hat off as a participant. > > > > > > Others - please chime in and a +1 on sections if appropriate is good > > > to let us > > know there is agreement - or providing more detailed input otherwise. > > > > > > Thank you, > > > Kathleen > > > ________________________________________ > > > From: mile-bounces@ietf.org [mile-bounces@ietf.org] On Behalf Of > > > Panos Kampanakis (pkampana) [pkampana@cisco.com] > > > Sent: Tuesday, August 06, 2013 11:28 PM > > > To: Roman D. Danyliw; mile@ietf.org > > > Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) > > > > > > Hi Roman, > > > > > > Comments inline, search for PK> > > > > > > > > > -----Original Message----- > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf > > > Of Roman D. Danyliw > > > Sent: Tuesday, August 06, 2013 4:33 PM > > > To: mile@ietf.org > > > Subject: [mile] Clarity on HashInformation (or HashSigDetails) > > > > > > Hello! > > > > > > I had a few questions about the HashInformation (HashSigDetails) > > > class that > > I wanted to discuss. > > > > > > (1) What's the correct name of the class? > > > > > > The diagram and text in 3.19.1, RecordData, calls it HashInformation. > > > There is no such class further defined in the text. However, there > > > is a Section > > > 3.21 named Hash Sig Details. Section 4.4 of > > > draft-ietf-mile-iodef-guidance-01 refers to a HashInformation class o= f > type > > > HashSigDetails. As an aside, the draft-ietf-mile-iodef-guidance-01= also > > > references that this class was derived from RFC5901 but only > > > ds:Reference > > is. > > > > > > The schema, the authoritative source, says " > name=3D"HashInformation" type=3D"HashSigDetails" minOccurs=3D"0" > > > maxOccurs=3D"unbounded"/>". > > > > > > Unless someone disagrees, I think there are a few typos in Section > > > 3.21 and > > HashInformation is the class name. > > > > > > PK> I think this class is like the ContactMeansType or IncidentID > > > PK> class in > > > 5060. > > > HashInformation is of type HashSigDetails... the text should be corre= cted. > > > > > > KM> I would follow the schema and correct the text of the document. > > > KM> There > > > are 3 interoperable implementations (may be more) that use this > > > schema > > and the schema was authoritative. > > > > > > > > > > > > > > > > > The class ContactMeansType is of type ContactMeansType which can > > consist of attributes and elements. > > > > > > I understand that the extra type " HashSigDetails " can be removed > > > and the > > "HashInformation" class contain the attributes and elements though. > > > In other words I think it would indeed simplify the chema a little. > > > > > > KM> I am not following why the ContactMeansType is part of this > > question? > > > > > > =3D=3D=3D=3D=3D > > > (2) What is the purpose of HashInformation@valid? > > > > > > There is no text in the document on this attribute. Comments in the > > schema read as follows: > > > > > > > > type=3D"xs:boolean" > > > use=3D"optional"> > > > > > > What's the scope of this validity? A subset of possible items includ= es: > > > ** the ds:Signature is valid on the HashInformation/FileName? > > > ** The certificate chain in a given instance > > > HashInformation/ds:KeyInfo is correct > > > > > > PK> I am not sure about the point of the validity since I don't see > > > PK> why an > > > invalid sig would be carried in IODEF. > > > KM> If you have an incident that involves a digital signature that > > > KM> does not > > > validate, you will want to mark it as not validating or not being val= id. > > > Take for instance recent problems with digitally signatures on code. > > > If > > there was an attack that compromised a certificate or CA, then the > > signature is no longer valid and may be something to look for on a > > system that can check digital signature validity. There are a few > > recent examples where a cert was used when it was valid to sign code, b= ut > was revoked later. > > > > > > =3D=3D=3D=3D=3D > > > (3) Convention in separating multi-word enumerated values? > > > > > > The HashInformation@type attribute has a number of multi-word > > enumerated values separated by an underscore and the "ext-value" using > > a hyphen. > > > Key@registrationaction also uses an underscore in the enumerated > values. > > > The use of an underscore for multi-word enumerated value is not > > consistent with use of the hyphen elsewhere in the schema. It's a > > nit, but would make the schema look consistent. Is there a reason not > > to have this consistency? > > > > > > PK> Sounds goos to me. > > > KM> Please correct it to make it consistent, thanks. > > > > > > =3D=3D=3D=3D=3D > > > (4) What's the difference between a HashInformation@type=3D"*_ds" and > > HashInformation@type=3D"*_ds_watchlist"? > > > > > > For the @type values of {PKI_email_ds, PKI_file_ds, PGP_email_ds, > > > PGP_file_ds, file_hash, email_hash} there is a corresponding > > > enumerated value with the same name but an "_watchlist" appended to > > > it (i.e., {PKI_email_ds_watchlist, PKI_file_ds_watchlist, > > > PGP_email_ds_watchlist, PGP_file_ds_watchlist, file_hash_watchlist, > > > email_hash_watchlist}). The language in Section 4.4 of > > > draft-ietf-mile-iodef-guidance-01 suggests this is to create > > > predicate logic. If that's the case, just as in the case of email > > > thread about IP watchlists (see, > > > http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) > > > could > > the parsing logic rules please be explained. Regardless of the > > clarity provided in the guidance document, I feel like we're missing > > adequate description in the data model. > > > > > > Are the following two equivalent: > > > > > > > > type=3D"file_hash">foo-file > > > > > type=3D"file_hash_watchlist">foo- > > file > > ion> > > > > > > PK> I think the watchlist names were addede for the predicate logic > > > PK> that you > > > mentioned, unless I am mistaken. > > > PK> I will try to address your last email about predicate logic soon. > > > KM> I agree with Panos, this was for the predicate logic. > > > > > > =3D=3D=3D=3D=3D > > > (5) What are the types of FileName and FileSize? > > > > > > The type of FileName and FileSize are not defined in the text. I'd > > > propose > > the following: > > > > > > FileName =3D STRING (Section 2.3) > > > FileSize =3D INTEGER (Section 2.1), size of the file in bytes > > > > > > The schema says: > > > minOccurs=3D"0" > > > maxOccurs=3D"unbounded"/> > > > > > > > > maxOccurs=3D"unbounded"/> > > > > > > ** Do we need ML_STRING for FileName? > > > PK> IMO yes > > > ** The schema comments suggest measuring files in Kb. If we do > > > that, > > how do we represent file sizes less than a Kb? > > > PK> I suggest PositiveFloatType or xs:float and the number expressin= g > KB. > > > KM> +1 > > > > > > =3D=3D=3D=3D=3D > > > (6) What HashInformation@type should be used to convey a TLS > > certificate? > > > > > > From > > > http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, > > it was indicated that a TLS certificate or certificate chain could be > > provided as an indicator. Let's say it was related to a web-server. > > What enumerate value should be used for the @type? > > > > > > PK> I was under the impression that ds:Signature or ds:KeyInfo with > > > PK> ds:Reference could express certs for XML sigs in > > > PK> http://www.w3.org/2000/09/xmldsig# > > > KM> +1. The thinking was to use KeyInfo as you can refernce this > > > KM> +and other > > > points directly within the W3C schema and it is already in a number > > > of > > libraries. The other reason for using this is that it would be > > maintained by the W3C and experts in that area. As their work > > evolves, we can continue to point to it and have up-to-date > > capabilities without having to keep up on their developments or re-work > the wheel. > > > > > > =3D=3D=3D=3D=3D > > > (7) What is the minimum contents of HashInformation? > > > > > > Under the present definition of the HashInformation class, the > > > following > > blank definition is legal: > > > > > > > > > > > > > > > All the attributes and elements are optional in the schema and no > > > further > > parsing logic is defined in the text. Do we want to make any of > > contents mandatory? > > > I think type should be required and either Signature or Reference > > > should > > also exist once. > > > > > > > > > ** Does the choice of a particular @type value mandate a particular > > > set of classes be used? For example, if @type=3D"PKI_email_ds" is > > > set, can any guidance about whether ds:Reference, ds:Signature, or > > > ds:KeyInfo > > > PK> I think we can't be sure about it. > > > KM> +1. In working through examples, I think we had come up with > > > KM> +reasons to > > > use a few options. This may depend on just needing the hash > > > information > > > (ds:Reference) or in other cases, you want the CA chaining > > > information, so > > you use ds:KeyInfo, or if you have even more detail, you start from > > ds:Signature. > > > ** If any of the values of @type with email in them are chosen, and > > > a > > FileName is provided, what does that mean? For example: > > > > > > my- > file > > > ... > > > > > > > > > PK> I think that should be illegal. Only file ds should have filename= s. > > > Maybe for email we can have the "Filename" depict the email subject. > > > KM> +1 - except - do we need to have filename outside of the > > > KM> +container in > > > case there is no signature? > > > > > > > > > =3D=3D=3D=3D > > > (8) Is the HashInformation the only way to list file indicators? > > > > > > What is the preferred way to list a given set of file names (not > > > hashes) as > > indicators? Is the following the preferred method? > > > > > > > > > > > > my-file1 > > > > > > > > > my-file2 > > > > > > my-file3 > > > > > > > > > > > > It strikes me if we do that, the text describing the HashInformation > > > class, > > "[t]his class are [sic] the hash and signature details that are needed > > for providing context for indicators" would need to be revised. > > > > > > PK> A text revision would clarify it a little, but I think it can be = done. > > > KM> +1 > > > > > > PK> Panos > > > KM> Thank you, Kathleen > > > > > > Roman > > > _______________________________________________ > > > mile mailing 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 > > > > > > > > > * Christopher Harrington > > > * Issuer: RSA Security LLC - Unverified > > > _______________________________________________ > > > mile mailing list > > > mile@ietf.org > > > https://www.ietf.org/mailman/listinfo/mile > > > > This email and any attachments are confidential and may also be > > privileged. If you are not the named recipient, please notify the > > sender immediately, and do not disclose the contents to another > > person, use it for any purpose, or store, or copy the information in > > any medium. Please also destroy and delete the message from your > computer. > > > > _______________________________________________ > > mile mailing 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 tim.freestone@deep-secure.com Fri Jan 3 08:56:59 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D354D1ADFD7 for ; Fri, 3 Jan 2014 08:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX2SBppjJ97m for ; Fri, 3 Jan 2014 08:56:56 -0800 (PST) Received: from mx3.a4mail.net (mx3.a4mail.net [94.185.132.7]) by ietfa.amsl.com (Postfix) with ESMTP id 28C3C1ADF8A for ; Fri, 3 Jan 2014 08:56:56 -0800 (PST) X-ASG-Debug-ID: 1388768206-06180b6b2619bce0001-Q78J5t Received: from A4HUB03.a4mail.net ([172.20.0.128]) by mx3.a4mail.net with ESMTP id Cye2WLA92ujKDb1Y (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 03 Jan 2014 16:56:46 +0000 (GMT) X-Barracuda-Envelope-From: tim.freestone@deep-secure.com X-ASG-Whitelist: Client Received: from A4MBX02.a4mail.net ([fe80::b479:3944:9cdc:3dc9]) by A4HUB03.a4mail.net ([fe80::c81c:c092:d733:52c3%11]) with mapi id 14.02.0247.003; Fri, 3 Jan 2014 16:56:46 +0000 From: Tim Freestone X-Barracuda-Apparent-Source-IP: fe80::b479:3944:9cdc:3dc9 To: "mile@ietf.org" Thread-Topic: Document reviews X-ASG-Orig-Subj: Document reviews Thread-Index: Ac8IpBtrPHYWJK+YSRuUsmxBbiV/ZQ== Date: Fri, 3 Jan 2014 16:56:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [217.39.63.68] Content-Type: multipart/related; boundary="_007_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_"; type="multipart/alternative" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.20.0.128] X-Barracuda-Start-Time: 1388768206 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.a4mail.net:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at a4mail.net X-Barracuda-BRTS-Status: 1 Subject: [mile] Document reviews X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Jan 2014 16:57:00 -0000 --_007_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_ Content-Type: multipart/alternative; boundary="_000_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_" --_000_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have reviewed the following 2 documents: - The Incident Object Description Exchange Format v2 (draft-ietf-m= ile-rfc5070-bis-02) - IODEF Usage Guidance (draft-ietf-mile-iodef-guidance-02) - See my comments below. Note that I don't have any CSIRT experience or backg= round and am looking at IODEF more from a security point of view in terms o= f how we can help to ensure the data transmitted is valid and so not leakin= g sensitive information or letting in malicious data which could compromise= the CSIRT. draft-ietf-mile-rfc5070-bis-02: Section 1.4: 5th bullet typo - complementary Section 2.6: Should this be "A hexadecimal byte is encoded..."? Section 3.2: Incident Class. The Indicator-set-id attribute does not appea= r in the diagram Section 3.8: For the Additional Data Class which allows any data to be tran= sferred - may want some mechanism to prevent the contents of the data from = being executed automatically? Section 3.11.1: Reference Class. The diagram does not show the 4 attributes= for this Class Section 3.12: Assessment Class. The diagram only shows 2 of the 4 attribute= s for this class Section 3.13.1: History Item Class. The diagram does not show the indicator= -set-id or indicator-uid attributes Section 3.14: EventData Class. The diagram does not show the indicator-set-= id attribute Section 3.14.2: typo "related" -> "relate" Section 3.15: Expectation Class. The diagram does not show the indicator-ui= d or indicator-set-id attributes Section 3.18.1: Counter Class. The diagram shows 5 attributes, but the word= s indicate there are 3 attributes and then describe 4 (leaving out "meaning= ") Section 3.18.2: Address Class. The diagram does not show the indicator-uid = attribute Section 3.19: Service Class - typo "a a" Section 3.19: Service Class. The diagram does not show the indicator-uid or= indicator-set-id attributes Section 3.21.1: RecordData Class. The diagram does not show the indicator-u= id or indicator-set-id attributes Section 3.21.2: RecordPattern Class. The text indicates 4 attributes, but d= escribes 6 Section 7: Examples have the IODEF-Document Version as 1.0 not 2.0 Section 7: Is it worth including an example with some of the new fields for= this version? Section 8: The IODEF Schema indicates that Service Class has been extended = by email address, email subject and x-mailer, but these are not described i= n the text (section 3.19) Section 8: The Service Class schema shows elements for Email Subject and X-= Mailer as well as EmailDetails which is the same set of elements? Section 12.2: Reference [18] could be RFC 6545 and Reference [19] could be = RFC 6546 now? General: The extensibility in the data model increases the risk of data lea= kage or inbound malicious data through the extensions mechanism. Is it poss= ible that over time, profiles defining what can and can't be sent will be d= efined for use between CSIRTS to ensure that only the expected data is tran= sferred? draft-ietf-mile-iodef-guidance-02: Sections 3 and 4 look like they will be useful once complete. I am quite in= terested in the Restrictions section (section 4.6) Are there any reports of the interworking done in section 5.2 that can be r= eferenced? It would be useful to list the modules in section 5.4 that are available an= d whether they are open source Having example IODEF data in Appendix A is good Kind Regards, Tim Freestone, Solutions Architect Deep-Secure Ltd. Direct +44 (0)1684 212 703 Mobile +44 (0)7884 588 757 Office +44 (0)1684 217070 Email tim.freestone@deep-secure.com Address 1 Nimrod House, Sandy's Road, Malvern, WR14 1JJ www.Deep-Secure.com [Description: cid:image002.png@01CB4F5A.42BCEE00] [Description: Description: twitter_32] = [Description: Description: linkedin_32] [Description: Description: youtube_32] The information contained in this e-mail message, and any attachment theret= o, is confidential and may not be disclosed without our express permission.= If you are not the intended recipient or an employee or agent responsible = for delivering this message to the intended recipient, you are hereby notif= ied that you have received this message in error and that any review, disse= mination, distribution or copying of this message, or any attachment theret= o, in whole or in part, is strictly prohibited. If you have received this m= essage in error, please immediately notify us by telephone, fax or e-mail a= nd delete the message and all of its attachments. Thank you. --_000_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have reviewed the following 2 documents:

-     &= nbsp;    The Incident Object Description Exchange Format v2 = (draft-ietf-mile-rfc5070-bis-02)

-     &= nbsp;    IODEF Usage Guidance (draft-ietf-mile-iodef-guidanc= e-02)

-     &= nbsp;     

See my comments below. Note that I don’t have = any CSIRT experience or background and am looking at IODEF more from a secu= rity point of view in terms of how we can help to ensure the data transmitt= ed is valid and so not leaking sensitive information or letting in malicious data which could compromise the CSIRT.=

 

draft-ietf-mile-rfc5070-bis-02:=

Section 1.4: 5th bullet typo – complementary

Section 2.6: Should this be “A hexadecimal byt= e is encoded…”?

Section 3.2: Incident Class. The  Indicator-set= -id attribute does not appear in the diagram

Section 3.8: For the Additional Data Class which all= ows any data to be transferred – may want some mechanism to prevent t= he contents of the data from being executed automatically?

Section 3.11.1: Reference Class. The diagram does no= t show the 4 attributes for this Class

Section 3.12: Assessment Class. The diagram only sho= ws 2 of the 4 attributes for this class

Section 3.13.1: History Item Class. The diagram does= not show the indicator-set-id or indicator-uid attributes

Section 3.14: EventData Class. The diagram does not = show the indicator-set-id attribute

Section 3.14.2:  typo “related” -&g= t; “relate”

Section 3.15: Expectation Class. The diagram does no= t show the indicator-uid or indicator-set-id attributes

Section 3.18.1: Counter Class. The diagram shows 5 a= ttributes, but the words indicate there are 3 attributes and then describe = 4 (leaving out “meaning”)

Section 3.18.2: Address Class. The diagram does not = show the indicator-uid attribute

Section 3.19: Service Class – typo “a a&= #8221;

Section 3.19: Service Class. The diagram does not sh= ow the indicator-uid or indicator-set-id attributes

Section 3.21.1: RecordData Class. The diagram does n= ot show the indicator-uid or indicator-set-id attributes

Section 3.21.2: RecordPattern Class. The text indica= tes 4 attributes, but describes 6

Section 7: Examples have the IODEF-Document Version = as 1.0 not 2.0

Section 7: Is it worth including an example with som= e of the new fields for this version?

Section 8: The IODEF Schema indicates that Service C= lass has been extended by email address, email subject and x-mailer, but th= ese are not described in the text (section 3.19)

Section 8: The Service Class schema shows elements f= or Email Subject and X-Mailer as well as EmailDetails which is the same set= of elements?

Section 12.2: Reference [18] could be RFC 6545 and R= eference [19] could be RFC 6546 now?

General: The extensibility in the data model increas= es the risk of data leakage or inbound malicious data through the extension= s mechanism. Is it possible that over time, profiles defining what can and = can’t be sent will be defined for use between CSIRTS to ensure that only the expected data is transferred?

 

draft-ietf-mile-iodef-guidance-02:<= /u>

Sections 3 and 4 look like they will be useful once = complete. I am quite interested in the Restrictions section (section 4.6)

Are there any reports of the interworking done in se= ction 5.2 that can be referenced?

It would be useful to list the modules in section 5.= 4 that are available and whether they are open source

Having example IODEF data in Appendix A is good=

 

 

Kind Regards,

Tim Freestone, Solutions Architect=

Deep-Secure Ltd.

Direct    +44 (0)1684 212 703<= o:p>

Mobile  +44 (0)7884 588 757<= /p>

Office    +44 (0)1684 217070

Email      tim.fr= eestone@deep-secure.com
Address  1 N= imrod House, Sandy’s Road, Malvern, WR14 1JJ
www.Deep-Secure.com


3D"Description:

 

&= nbsp;

3D"Description:= &nb= sp; 3D"Description:   <= span style=3D"color:blue;mso-fareast-language:EN-GB;text-decoration:none"><= img border=3D"0" width=3D"43" height=3D"43" id=3D"Picture_x0020_4" src=3D"c= id:image004.png@01CF08A4.C9416A80" alt=3D"Description: Description: youtube= _32">

&nbs= p;

The information contained in this e-mail message, and any attachment there= to, is confidential and may not be disclosed without our express permission. If you are not the intended recipient or an employee o= r agent responsible for delivering this message to the intended recipient, = you are hereby notified that you have received this message in error and th= at any review, dissemination, distribution or copying of this message, or any attachment thereto, in whole or in part= , is strictly prohibited. If you have received this message in error, pleas= e immediately notify us by telephone, fax or e-mail and delete the message = and all of its attachments. Thank you.

 

--_000_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_-- --_007_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=19522; creation-date="Fri, 03 Jan 2014 16:56:44 GMT"; modification-date="Fri, 03 Jan 2014 16:56:44 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAANsAAABNCAYAAAAvvBEeAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAEvCSURBVHja 7X13XFTXtr/35r77bnv33fJyUzSJsUZjLDF2Y8VeUbGg2HtLjDFoNLHEgooFFRURQURAOgwwjAMM jIBDryMMMHRGGZgzjWEggPu31pnCYRhkLDe/JNc/vp+Bmb3Xbuu711r77LN3t6NHj3YjhPQGDP2p 0NwFXkDmMMA/sC1MwHd/6yT930zTdgZI+yepVDpULJE8ExJARUXFJ5D+DUtlm0KtVg+USLouqzNU SCTDJBLqo07a8dsKqfQTyQvKNshvbm7uC7J+Y0b+/0E/DbNEDtYB0mJf/e5F++qXCOykXhqKqlWn Z7RWnLvQWnH+YqeoAkjOXzCLJ4CaLiDVo/bcs2FI15U8LLPa8XwrFcZq1dbX+zIVHRXix5YWd0Vi UmsFpKHbAJ9KQXJrS2vrTXMKY0aB/h4Sygq/4erWeu36jWfiuosrfjadOHk66crV6zw//8BQTgxv M8h425KBiIvj777lflvbVTld1QHqqvby9t1k0o7/8gsIvAm/N+vr+cLyPW571rFYrBFM+WKxuI+X l0/WDdebFsuBzx8dHM4KoL5cqO/XQL5B/wlkGyqNjiXlW3eQ1DffIendP+iANEAWQNj9ffLIBPmA IoDYDEoApYDyd98nFYBKPaoYf5uC+Rvmwbylelnmyih6611SPnockZWWJaFSMWdyRW1dTPFSW2O7 0uBTbLeGqOWK+/h7V50jFlcMdrvl8fTwkWPkyNHjXeAHcvTYcXLK4SxxOO1ITp9xJBedLhPXm+7l bDbnGyjvv59B6jeA1PyTp87Qcrouq/M6nHI4Q5yv3YhgyheJRP998dLlnOMnTr2UfGwfnf/48RlM +Xw+fwW21XLZhr46A311ljieu0Cgn1UxMbwvfu1kG1wRGNxSuGotSQGFTO3ZpwMyALk9e5M8PQx/ 5wMKAUV6GP4uBpR+0JuUAcrNoAJQ2QkqOsmDsko+0MlmllX0Xk9SMXIMeVxQECcyIVtNRSW7cMEi Y7vws2DRUiJ7/DjcIrJVVAxy97itQSU9cdLhuYB5EKhQTpeukMDgEC6U2b8zsoWGht0/c/bcc5dj CpRx2flqsCnZLl2+koyK/TKyT546jW1qPnLkmBVTPpcbY3Ph4qUXk3tCB5R9+crVp9yYmJ2/WrJB jDS4LCCwpdBuHUnp0ZOkfti3DaCgWe9/SPJM8AggAhSZQAwofe9DUs5ABaASUAWoBkj0eMz429x3 1fo8lXoZTJlYhthQLlrO4SNIWU5uB7JVl5SyS+Zbk8z3dO1K6QH1XmRDaiurLCabh+cdzUkgzClQ VCMM/zu0ByozWrRTJukx/xXn6yQ8kp2n1Wr/ZY5sLFYEx/H8xfbl6IGKjIS9aAGuXr9BbnncZpmS DVzb5DOO5zvUC8l50ULZTpeddXByntmObDExNli/DnUH+WcdL7SvO1hAB+wjZj/qgf132/NOM7il n/8qyaYFspV4+7YU2q5qTzYgWnYPsAQffUzEg4aS4kFDaJQCKgFV+k/D348BNR+3QQqoBcgAVCeQ g1wmOksn08uSfty+DCyzesAgIgXrVZybl2pKttICEbt4/kKSB2TL+rAPTbaChYuJpKTMIrJVANnu ePloUCHPgqIi8G9Ufk+vu/U+vvfUTHjeuau+fOVak/M1F2N6Zr6r8H10bOwVc2SLiGRzUBGZedC9 cr15S+t0+QoL8t8B3O0KTleu3mWx2QtNyXbthmvy+QtO7epz6cpVcuOmW+kZx3NelsiGicT75i2P OwkJCe3iq5i4OJsrztc6tPnK1WvgHrrnGOoO+b0cLzjdu3PXR3rj5q2nmKdd3wKwj8DtdvpVkk0K ZCu6c7dFtHxlG9nQovXuR/K/P0oKwljKRz6+eUJvXyHikRnkm4HIBP+2NHe9hUW8uPzKyuqjTALh 30V5eezieTqy5QHZ0MLlAzHLC4stJttdH18NKv05sDoIVFhvb59CiqI+JkT7YXNzcy8DJBJJTy6X OxziL9Ald2MeA1DOnTt3mysqJCNMyQZc41wCq8FMD4r3Y1pGxtqXHWQk2w1Xt2QkM7MdXt6+VbjS +rLy4+L4NkgSZt0vOoHrHBTC7mSV+N3sbOFkzzte4eA6dugn/4AgMaT5y6+ObBVAtnwPz5aCZbYk VU+2rPd7kYLPJ5FHucICNSGjoOV/eBa4/5+RRsgfzS11CzOy2IVzFxjJhp+F4FYWP8q3mGy+9/w0 aMlQURFXr14nYLnOd5VXkJa20f2251NDPgTKQaVkRUScNCUbh3Of4wyyDWkv0y7bFXFaWtofXwXZ brq5J6NiG+XD375+AYJXoURxfL6Ny42bhNnWS5evkmvX3NY/K59QKPzXTTePEie9e4lwAtxyvy2F dv/tV0m2XLdbLY+WriApEAtloFJCLFRoNYNkCZJjf6kNQzJlJaewi+bMb082sHT5ObkWk83PP1CD inkZXB6Ei6sbul9nLKlDbGzc+Ruutwgz/9XrLuSOl7cAyv8zk2z3uTGc6y43Gelu4EJHob29/Ssh m4eHZ7JOZpt8P/8gmKfIH16abEl8G3AvjbJp+TCpwGeXVvmeX0AA9qkhH044gMcuLi7/+6sjG1im wVkuN1uENstJOpAtV0+2ginTSEp8Ap+5nP5LI1tKQhJbPHseETHIJgJLl5uWaTHZAgKDNag4znq4 unkQZ+drjpbUAVzN7t4+vjJmfvz79p272gSBYASTbNyYWA7EZ8Z0111cwTK4vDLLdvv23eTrYH0M 8tESBQaHvBLLxk9Ksrnlcdsom64/XZbr+q7yhrLC/cHqtmv3r5ZsIiBbxvUbLY+WLCO5BqXUk03A i/9Fk+0h/wG7GMhWDO0q0JOtYO58kpWaajHZgoJDNKgABtzy8CTXXFwdLazDbyBuoZXJkB+V/CZ4 EkFBrOlMsoEV5Li5exBmWe7ut5sSEpLWwO/dAR9YgH90RjbPu97JSGZmPfz8AirFYvF4yNfDQvl/ 7YxsHrfvtKs7lnXtmmuXli04NCzS7VZbuyG2hM+bv17LlnPjZkshWLY8BtlEQLa0B4kdyCaRUqPz q6quPyor9xSWlFmAkleAzuVjPfIqK29WSKXjmbtCkEypSQ9py4bP4oqgXY/0lk2YnmUx2ULCwjQ3 QHEM8Lxzl7i63nK0tINDWRH773r70kpEy4BP/F8gSLnAJFtcHJ/j4ellLAfTocLeueP9YxgrQsUK Z6ufhUh2lDqKE12QkZG7wBzZvH3uJeNEwZSPSu4fENjMCo/sUj476r6aGx2TIZVK+5jKT0oS2Hje 8SbMfoK4i3h4eD3TspWVVU0GN13rysjnChMT1BViNvGvk2yP3DxaiiBmM5ANn6MVT51OspNT+Ka7 MoQ5wsia805EuvMLUvvFV6SuC8j27H0+fGn+u07L2PUloU47krysbL7p0n92aiq7BMhlIFshfs6z JiKLYzbpIFB0jRsojgFeQBRQUovJlpKW8b1fQBDBmMYgw+eeP4mOjXNmki2en8C5c9eHMMtCIEFM v+sM/oHBJCw88oQ5svn4BSaD+2qxLFPcBAQFhxJxaWmHXR5JAoHNXZ977dLfvuMFdYkIAcvZHdzp tyUSyTsIw98pKWkroW9LcIIxbW9EZFQZ1YkV/cUvkIhu32kpXmZL8np8QJMNY5xSq+nkUXpWO7L5 gYLmJD2MlI4cS2r++Tape7sHkZniLf3nO+8RWff3CQUy26MnoSA2pN7vBPgbpjHJh7JomXQZ3dvK e/Mdohj8Kcl5kNCBbPnZ2exyIFtxDx3ZkHSl862JOD/fYrKxIiI17uAiGeDt64cKYTHZcoXC7wNB SVGJDDLu+QcSbgzvMpNsfH4iBxWWWdbzAkkcFBrxnTmy+QUGJSOZX0Y+ThoiUdEeMyuvNli2aXok NxBUGcKKUISEsZQ6hCv9g0KU2AdYH2a/3PK4gyukJCY27pIle1d/kc/Zir28W8TLV5FcUOp8g1Ja zSDFOXkdyCZKSw+vmzCF1L7fi9R+2Lc9euo+6/r0J3V9P2qP/gMBH5O6jxCDugam7TewoxyQ3a7M D3oT+cgxpCA5pcMOkmJhPrt63kJSyiBb2UJ8zia2jGxS6aAIdpQGlcYAVAYPT+/nIFv+9yGhLIIz uEEGWqAYHr8d2RISkziosMyyEGhJ7/kH0Yr+LGAaVgSbhEdFHTdHNv+g4GQks6l8/K4r2QagfLBs W8yRDcljKtvTy5smVAdAm/A30/T4G5ARCC2e8qt8qA3menCpj29Lie0q2rIV6pWyfNpMUl4g6kC2 kpyccMUkq45kA4tU2/0DUgd568BC6dCL1PXsQ+qQgAb06k9kvQF9PjKLOvitrle/9nmAULQsg1y6 rPdJ7bsAsHLyIcNJSXpGB7JViIrYNfgQu3tPUmJo1/PsIAGysaM4Gi9QAgP8QemAABaTTQhkA3eJ MGWgpePFtydbYqKAA/FLu3Q+YEXv+QVQUB7fy9vnmQBFfRDGCuelpKRMMke24OCQZF8gs0H2Xb18 sDxPupKNuOvt84AbHcsGt/BNU/lpaRk2ATCBMOv+vMCJBmXw+Ql7fo1Eo8mGeyMr7vm3lK5cTR4B 2QwWoHrGbPJYXNIhZqvKF4UrJ09rTzZ0/YZ+RrRgRRoRc/HTmjSAYjcsXNIG66WkYdEy0rC4Cyxa qkvLyK8F0rTJxs8FRDsbMGMOaYHY7XFJaYppXR+XlrGlIKMcJoFyIH0RtK960RJSW2XZ3kh87SPq frQGXUcDkCjevvcsJltCQtK3EEcRpgwkX3pGxnUm2ZIEyZyAoBBjGiRCcCirVZifv93Pz++3lqAz 1wvJBi5cMlong3wgMViqqEKxWDLkZeVnZOTaBNH94tcOSKBnAfsS86HFZEfd1wLRvvm1Eo0mG+76 rw4IailftZqIGGSTANlqyys6kO2JuCRcNWV6G9mAaLKJU0ndg0S5rLJKQJVVPJSVlgkQdaUVgroy E8B3tfBbZ6hDlJnPZ5BrCmWdLEWj1dibbteqraxmy4BsFXqylUD7nixeSuSPn1hMNk50jMYHFNOA oNAwAhbCYrJFcO47AWmM+dENBSVrEQgE60zJFhgSZkxHu4YBgaVgSf7nVTxng7gpGWIlo3x0Ze/H xCW/CiWiycaou4FM+F0oTCymwMknPILdGhgUmnU/OvYBL45/qKKi4tNfM9GMlq3KP7ClEshWxCDb 4+mzibS0vAPZHhcWhyunMCwbuHLKffaEevo0Ct/Zwrdv/3/A3HM2fMUGyValJ1sZfD5ZZEMoyWOL yRYdE6dhxi2oLBCfWPqc7U/sKK4ILRZTRlh4RGtaWtooJtmSk9M4GK8Y0uCsD25lkYuLy59eBdlA uZNR+Znyo2N5r2QHCZIN+4XZRmwzxLvnsrOFU+H3aUzk5uZPKysrm4ITycu82f6LIxvu+q/0C2ip XGlnJFsJkO3J9FlEUizu0o3EGE2x/1siU9VH/tweaj8uLWXXLYAYDUhWAWRDd1L6nG5kbBxfEwiK Y0B4RBRaBYvIlp2duwpcxlZm/mBQ+OhoXgml1b7HJFtqWjqHBTO+IR0uqsBnMbhvf3kVZAPFTw4F MhvrERpOeDz+KyFbbm6uTXhEW93RNcT6+wUE2P6nEMlispX53GupsG0jW1kPHdkqRYUdFkjKcoVt CyS9+9ELFopv9pNapZL9c5qlkEyVxcXsWoj1JN17kio92Wqsl5An5eUWky0unq8J0scWiMio+0C2 oBNd5RWLy6yAqNWo4O3yszlEkJLmblJXmmxgfYzpMK6DT1G3bt1++yrIBjFRsl6mTj4QOz4+IeVV jFmuUGgTEdlWd5xQsN2hoaHrX5PMdDXS26elYsUqmmzFqJRItmmzSPmjgg5kE2fhauRUmmz0Ujyu Du7dRx7LZD87spUVFIFlA7JBe6oZZHts4Wokko3/IEGD7p0B4ZFRhBcXf99cW7Vabfcisdg2PT3L CxdWIoBYGK8x80OM0gDu02emZIM8HCSyIR26ZZCfEonFk1+abODec+7HJGPdDfJxUSKWF5dHUdTf XgXZTOuO8kMj2K/JZvqcreSud0v5ipU02Ur1ZHs8bSYpyRN2IFthema4HBdEwAIi2WRAtid79pJq qbQd2Yif3xtlT6SbS4uKggsys4ILshjI1CMrpz2M35tLa/I/jcxgUXpmcGlpafATqXSjKdlK8gvY MiDbY2iPBNqFsZsE3MrK4hILyUYNepCQpEErwASbw30az0+ISEpKDkpMEgQnJDwM4nCjQ4CEFfEP EkgcP4EmpWExAIF/xz1IJOkZWb5mJoY3MjOzOEBQ03JIDC9eCnFjcHQML4gbzQvuCpAuWJCS6iuW SHoyLdv9mNhkJARTPhCiFRcouDFxgZbIRvDi+SFZOTmnmO6nEMjGrDsSDSeaCPZrsnUgG748Wr58 JSkGspUZLdtMUpyd04Fs+cmp4XKwbHW9+urI9kFvUrPna1JZU9OObNLm5uFlaemN2m27iHblGqJd v0mPzUS7cSvRbtlO6N+Y2Lxd9xumMWDNBtJgu4Y0rNRjqa3+EcFy3WOBedak6cu9pDAnT2D6nK0o T8ium29NavRkq4bPyvmLSImFL492RjZUJiABATfRCPw/EsiBv5mmR3BjeCRRIMhUq9W9LCUbAgkS wyinK8Tw+CQ5NZ2Iior2M8kWbZ5sdL1in0M+L/4BWMR4PLrg3ddkewGy4XatMiCbuIdu1a4ClLLG aiYRZWV3IJswKTlcPplBtp59wbJ9TSoeP25HtgqtdkJpWHgLNWo8kY8cS+Sj4XPM50Q+YQqRQ8wn nzSNyCebAL/D3z6frEuLeQDU8FGEGvKZDoOHE6r/IEL1+5hQfQbQZFd8NprkJiTGm5KtIDuHJpvU hGzifJHFZEt4KNDoFKc90HKZwtzv+HfiwxSSkCTIBgX9oBOX943MnBwOKr4l5TwLLAA/IYmAO3uS SbaY2PhkKOCl5UcAYe9zY5UJaWkMsolswEIaZSKpkXxsNuc12Zhkw43I+e63W0qWrjCSrRJjnKkz SF5aegeyZfETw6nJVjqy9QNl79WPSL78ipRWV7cjm1itHl8cGt5EgRwKyEOB60kBganpswk1Yw6h Zs0j1NwFhJozXwf8e/Y83W+YBtMCMQ2QjRpHZCPG6jBsJJENGkajDkgnHzeJZMY/iHMyIVteRga7 dt5C+lngY2iXhCabNSkUPrKIbBDPDE4SJP9ojmydAV0/VGpE/IMkUPxEkpaW6QXxX+9nxJdvZOXm 8qJj48jzlGV2EgAAsUmxWHy6TT5YNl5cqjmyPS/QeoPbqUxISOhukF9UJF6BVs+UbBEc7sbXJDMh 26Nb7jTZcA8hkg1PtaqaMp1kC5I7kC2NF0+TTYZk6z+QJlv1ri9JcUVlO7KVqtWTRMGhRDFuIm15 FOMnEQWQBhdXFFYziALcVMX0WUQJ5ELg3/R3+NtEK11azAtWUTFiDFGAdZMDueRg2WTDRxvJJvvo E0JButQYXgey4a7/2rk6sj2BdmHsVvUcb2prtdoPUtMyqtMysmjX7JlIyyCYTufKxTUmPkym0jMy I6uqqlZbsJjzm/z8glsZWTldl2NhPUorKrYyyZaSmpb5KuSnpmcSiAl/xJ37Ri+momIi/0FiC/6G aVL0dUhIaHtw/xp6suXedGspsVluJFu1nmzpiUkdyJYcHRsuA8LoyPaxjmy79xBRaVl7N7K5uXfe Q8Hj2lNniPTb74j08DEdjp0gdSdOARyIzOEsoRwcCXX6HPx9Rv/9KVJ77GRb+oOHdfkBNfYHiWSF HZF9NobIkHRItgGDabIl3+d2IFvGw2S2FCwm7qWs+bAvTbZKIJ8w07L32XSzdukkYX7+2czs3Gci O1d4tqSswjFXKFwpEAiGUmr1wOcZCLCib+U9KjjWVTldIVeY75ifX7QLXUemfCD9gnyRyPFl5UNf OFZJJJtNNxLk54uWCfPb5D8qKPyB0mrffk2yDmS7RZOt7BWSDVEmkcwpqKyKLCivjM4vK+caICqr YKCcAd13zLT5+H+5Do+qqrhZKWk1VavXE+qTT3VkGzjkBciWYzHZXuM1Xq0bCTFbGbiRuDueJlsP IJuZl0eRbOnxfJ0biQ+0PxpEqN79IWb7mpRUVv4kz9nEUmmA5MgPhBrURjb5+MkkPTa+A9ly0tPp mI1JNnQjRbnC12R7jZ+ebPTLox6eLWXLbI2743EhQWo1kzxKz+j48mhiUrgcF0j0ZMPXZZ7s/YaA FftJyFb+uMb/CU22Ye3IlvMgscMrNsKsLHadnmxSPdkkeJSdhS+PvsZr/Bues3m1lC9b2Z5s02aS QnPP2VLTwuVTp7UjW803B0iVVBr+U1S4UloXUHP0OP0IQIauJMRsigmTSf7D5Dizz9kWLDKSjW7X gsWkvLDwNdle46cnG27XEt/1bqlY3pFspcJHHchWnJkZrgQXs41sH5G6nV+QSoXyIRB3HGD084DS w8z3Y6HsDi8qPpbLA6jjp9pWI2myTSFFqelxHY8f1+0gMZIN3ORa68WkSix+KbJRFPWuWCwem5Ag GM3l8owQCNJGSySS0XjV1C9h8PHU4YqKilGCtLQxXF5bO7Bd8P1YXI19AZm/eUV1+82vkmzlPvda qm3t6FdQyvUPf2unzSIVZt/Uzg1XWs1oI1v/QaRu7ARS7er2tCo6tqU6Ora5Oia2RRLLA8S1SHh6 xPNbJPwHOjxIaKlOSNQhUQ/9//ibJD6+pTYzq6W2tjYBj1ljVliqUgUoT50xIdtUUpqZ3fFN7aIi NqUnWw1Ntg9IHe6NLC97brLh60OlpaVrMjKzI/kJiaIHCUkt3BheS9T9aCOiob0PEh82PxSkZmfn 5jpKpNL+XcnNzhZ+mit8FJEnfBSdmyvkvgjyhPkx+fkF/kD0fpa0paysbHLeo0feiUkPUxKTBE2x vPgWDjfG2A5sV0Liwxb4rUwgSL1TWlZm19Vx4HjMnUhU6JKWnhmbkprOBUQLH+Xfl0qlcy2pE5B7 FbYlOSU1GvOnZ2bFFonFF0Qi0e9NynkjVyjc+uiRKDonL6/LPsvJE0bnwGdCUsqhbGH+xidPnkzH V5+6qg9MNG8WFhYfe5lxQYhERZEwMfc3kk3i599Ss3K1kWxVSLZOXrGpfPRIRzb9aiRNOFx+x9hp zAQi/3wKUQCUU2YQ5fTZgDlEOXchUc5fRJSLbIjSZjlRgRVVrVpHVHbriXLNBhqq1Rvo/1XLVxHl 4qVECfWRpWcQJSGzmZ0gU6t1ZPt4qJFsqolTSUWu0OwtNtTCxR3IJq2sfC6ywYD3BpIlJT4U0A+M ccsS7vbAh9CmwO/j+Ikk8WEyESSnyoRFRbs6U1RcPk9Nz+AKUtIJkPQlICBp6VkkX1R0+1ntwHP9 s3PyQuIfJLRi/eIfJNL1NdeW+/ptXChfkJJKsrNzcAfMiM5kJwgE/XmQHuUa6oXP9VLTM10s6WPo qxB8TmfIq5fTCBNIOy+hQiIZCOOgZZZjCXBXTZIghd63mpGVnQ9E3gf9/1Zn9RGKROOSoAwc75cZ G+yDzMxsV5ps+IpNTUBQS43dGlLCIFsd/fJoqdmXR1XTTMgGRKOByv/pKB2GjybU2In0sjy9ewR3 koC1pHeJAOTzFhGF9VKiWLRMB2sb+M4afptPqFlziXzmHFILlhLI1u7iPXlDQ4DK4SxNMsNDbdXE KUSSb/5+NsXCJaS2RxvZZPjyqIX3s+kVtFdCYlIGdhy9BYnDNX4icJsS7swwfM9Mg0r7MDmVPCoo vNYJ2f5LkJLGx3QGeS8KHigRWDi/TpVHKBqSKEiuSIL6GOrLrHNXoCeQJEF1VZVkmzn5XG5cX0in ZspGxY7nJ1y2pJ/j4h/cQ3Ib8qKcGF48JRQK/95+4hMPhcmiiTkGlsDQDlpunG7/KJAuHcb3Q7Pk FwjGRMfEPXc5psB+A8v6kCYbvqldGxTSIrVbayQbbteqmzGbyCorO5BNVlIWrjZatoFtZEPFxwUL fOCs31ZFjZvUtuXKsFVr5lzd1qx5Cwk137o98Dv8bcYcINtcIgP3RmNCNnVTU4Dm7Dki6/dxO7LV Fhd3IBslecxWg5WsxY3VGItC+yi0mlKpRWSjjzBPS2PhrIhbkJiIjXtAHsCsh2RDJeE/SKI71zRd 1P0YnFWbREVFNubJlspDy2Kaz0BkS8FPeEjy8h4FdeKifRb/IKkkJi6+QzmGrVVIeGyngfjm0mE7 YaaXgbxh5sgG+dQoy5AePQBwuS9ZQjYgpS+9mZtRJ6ivzAzZhgCJG8z2NRDpfjSvQ98gwcy1B+sH k12OuYNnkWwwLo3myuF0Uo45oNeRmZX9oAPZxN3bNiIj2aiKjmSrK6+Iapg6nVD//Beh3u5OqHff J/LuPYni/T469P6IKD4arAOQUDlsBFF+OpIoPxtNlGM+J0qwdkogoRIIqJw0lSgnW+mAfwNplOMn 6dJNmU5UySkEyDaP2QkqIFvDaUci6zvQuDeSJluRObJJ2PWLl9Fkw72R1WjZnoNs4DbNAgVoYXY4 7v1DpUxIeijIyslzZ3NjrFPSMr6EWTIKFOspKitzYCKiOLQCgwuTaRordEY2LE+n9Pfr4X+LAJah vqio+ISZ2OOfqWnpRbGgWIZ9i4Z2oNKgmwTuZBOgMDKK6xvPTyyEeI1WRGZ6Qx6dgqbeN13A6JRs /ASLyMaL53cgW3SsZWTDeqFi01Yo6r7atG8gbTOQihj2hjLzYftz8/J8zbjFY7jRsY3myqGtlply zIGf+FADAfz3HdzIYj3ZyumYbTaprehw4M9vFArlvUZolNLxPFFeuEiUFy/pcMlZh8tXifKqixGq GzeJytVNh5vuRHXrNlG5G+BJVB4MGL6/5UE0IWFEVi0pgMmgL7MTFEA29cnTOrJB3FbXdwBNticF RR3IVltdzVaB22jc9Q/tq30ONxJIdMrwbpoBsaAQ4K6FQf4Ox2NXSSRzUlLTRDioprvl0SpIJE8W mZINOMtjpscBhUFuAj//CDcuri+Xy7UIMBP3pSjqjx0XYHL3mbYBQceW8Ql1EMRfqqiQDNNqdSu/ BMhZVlZmnZ6RmYT56LMoTd5swIUgiGnane3IgjqEszmogMa0SJ44C8kG/eqLdTLkRTncmFgzZBMN gb5sYL6xoLe6lSkZGbPZbF4vZr+w2ezeeN4L9idMIk+YZejag5MCv47Sat81JRuMS2O7coBkEMeV pGVnTzct5xnj0s8wyerJFkiTrYjxPlsNkK3GJGbTK8iHdYQsBdj8OwGx2jK1CdGMMRsu/QPZ6gZ8 oiPb55OJpCDfbMwmh5ithvHyqBTIJrPwwJ/wSPZZHBxUOJ3ScYBs/DK86KKzPGq1uh/EFBU4y7bl i9LFPXF8W1OygYXkMdNG6l5hyX8VGwSAQO/yHySIUWEM8g1l8OL4xUCyT5/hQv/r0aP8OFxEMbyj ZnhXD/sEYp7rTOvGYnH7siKj1Myy0DoDCSwkG88XrYYhr86KxMgSEjqSDUjcQL9OpE+rfzWpy2u8 YDKaCHFnnWl/YLmlpWV27ciWIBgD49LILAcnzIzs7MMvvPSPZHviH9jyZNUaUsh4UxvPIKkpKfnZ 3WIj02h0ZMMDXfHkZCTbuAmk6tGjDmR7XFHBpoBshje1K4xkk3RJNvj9jzCL5dKv9+uPYEMlZUWy Y7pcvSwqWoVuHV4CpHvJNJ5e+UvPzDxvcvnHfyUkJPFQrqEMHNz73BghzMYvfapWfr5oOQdiRtNj 5KJjec1FpaUzLIhZ3waXMYHNiW53tAP2SXxCIrrF/91GNlbfUFakmtlf+njWIrJxo3m+OOkY8qIc sCxmLRuQuMHw9jsCPYOQsIhTlpQDbuMxJFsoIz+Wm52b2+7duzggG4xLI7McHMu0jOzvXopseEir 4XQtMYNspkv/PxOy+SvxzQE82QvJ1rs/xIATSKWZpX9JaSl9lB0+zJa0O12r0hKy/Q7cmHuo/HiO iAGc+9E/FpeUHLfgudEIYX7+6tzc3JUZgNz8fDuJRDLTlGxgeXjMMnBwo6K4QtNd+y+ClLQ0d4wv mPWPgLIEyWkhlj40hnYMhli0xricDfHqQ3pFM7aEeXcckg3kq1EpDWWhEkMfWkQ2kOeLk44hL8qB upslG57jgqQ3pKXbGMw6bUk5QaERiwyThjE/lJudnb2uHdniEsbAuDQy00WDBQWyHXopspX7+rVU mjldq7qw+GdHNqqpyVcJlo0mG94F0KsvTbaKnFwzz9lKdAf+mJyuZelztvvR0SeiYCDp49kYR9HF gHuUnJx6TSwWD34Zd48mGz+Bx8JTr/Rl4BFw4RFReGf3Sx1hh/WKiuIE0yd26WXjyVdsNuepWFy6 9nlkAeE+EYmKThQUFJx59KjgTEFh4VmYPL5gvmYTFMTqC2WoQ6B/DOVF6hZhLCIb9LNvBKOuKAcm BnAjEzqQDSa8hmA8yYtRDnxaZNmSU1Nv4pGBQfr8OKZIttLS0g3tyRY3BsalkVkOTIK40HXq5cjm c68d2QznRpoeZacfxHefEDKt7KeHVQUhix8rVcWyHbt1ZAMXEu8FUI79nJRm53QgG/Mou4oXOMoO 3LA9EDfQ5/vjOfRM6FapOI0wc8clPnx4FQLqBXifm7kDY59FNojjeHjsm1E2DmxIWCu4LPfBitwE q+L+LICr6wEKcNB0cQSsaE+oGoXyDLIDg0IJKLVKq6X+9aonQSQblKFGJTaUh2dssi0kG66EIgmM dQ0Ow1OTO5ANTP4Q6PuGQEa76AklJMyhqzIkUulocNGr8LBaZn+jPHwr35RsMC6Nge36D4kdVfcg McmTn5h4q6uxARf8FkzIf2u3XYt5lB2SDW/qfGxmuxa6HjXSuttSmAkkjudJ9fmLOlxwItUXL+ng dNkIyaUrRHLZ2QRXieSqC5FcQ9xoD/z+6nVdGtN8TlfI46vXiPS7w6R2yPC2m3KAbIrR40lxhvmL NZBs1fr39JBs1RjDlZVZ+qb226CwZTjweEuLKfAIb727Q5/zCMpSy43lPUx8KHAE93FSV3sksW+j eXE8HHxT2RizWPJA1fCMDNybdkcQgIvXGyxDve6GG51M/JsXx5eYW0l9ebIF9YUy1NgnhvLoOJfN sYhsrMgoX3TZ2uqKd81FdCSbUDQkPJLTcI/RLnocwiKKhcL8vXh/HFjudgCr/IUgJeUCxK9SdAcN +fAoeHTbkwTJ8aZuNQ/IBuPSyOw/Q1mRFj7QxlgSQolD7chWAmQrBbIVMo4fr8KNyObOjczJ46in ziDyN98h8nfe0+Hd94gC8irwdOT3PiQKPIQHlFvRsy9R9IKYqvcAouwzsA19PybK/oOI8qPB7dEP vuvLSNdnAA3Fh/1oWXKQi0fn0fsyDVdIQX3lo8aSYjO32JQViNi18xfRzw2RbPgmehkeR15SYvEO EnGReH3UfW4LdvqzLonw9dMNRBAMJh66Exgc+hSsXm1ycoqrVCod0inZYuN4OLt2dQnFsxAWzsab TA+2UxYerxcoi8rX5Ox9/8Ag13/HJl8kG5ShRoU0lIeKHR7JtoxsEZG+9H0Bxv4MIMFh4WbJBpNa A/NOAQTeY2DYIWIOOHkhgQ3pvXUXl+ACjqKq6snUDs/9eHFjAoNDGn1NynkeYBmZ2bnO7cgmvuvT Igay5TPIVgpkEwvNnBuZlh4unzBZd0UUKLARhnvZDOg3QLedi4Zu/yS9n9FiDIE8n7Td1Ubf1wYy +7bd/YYnMtP3swHZCs3s+i8pKGDXANlwwQcfaRT30N3PZum5kQYUFRXtiuHF1eNMja4EPQDQkXi3 mXcnwOuZ8KYYdKVieXFSiHHmmiVbNI+HbmoHGSDfV38RR1dgAdlwo60p2aCuKqynQSZ9A4+376VX TTSEN5ANylBjuw3loUsZHh5pUXngGfhi3xry6q6zCjNDNuEQSNtgrs/vPgOm6YDYT+/H8O7nFxVN MvuQnccbExAU1MjsP2Pd9JNBl4B0mZmZV41kM16GuGIlEbYj2wxSnGfmMsRUINu4ifSujNr3ezPQ S3ePGm7j6m0AWCBcosfYCp+L9dMB3xTAbVZIpnbA7/A340WIA/T4SCfLIBPLQILjEeg9PiTyT0eS /E4uQ3wy35omm9hwGSLe11b8/K/YqNXqQSlpaVcjI6NSQCnU/m2XbNADcKeTe8fueHnrCBERqYJZ eaQp2cBq8pCU7fJ5++KlGuYvEjQDiFme5otEG0zJBnVU4f3dBrlonSH91X8L2byD+t719lFjXxjK wzgnLCzcIrIFh7F8sX7G++Og3oGBwR3IlpYmHBISEtZgtq87gbl0IaGslqycPBcYgz93RjYYg0Zm /2E+wyQI/z/talxwXNOys1e1I1uRp1eLePlK+jJE5s2jhVkdXx4tyMiOkc9ZQJ/XSF9qyIT+okMK CEIBWWj0R3xMqAGDAJ+0YeDgjsC3B5hp8NgFzIsy+g3QAWQzy5KhuzplOslPTU8xJZsoL49dZXrz 6AI8pPXFXx6FfL/PzhZ9FsPjrWRzOC6hrMh0cANVwbjIATMzEsX0Rk0Ezoac6JhYyP9PJtnYUfd5 OIDMtDDIrXx+gqunt98UT0/vKZ7encPDy2sqn5+E8eEfTQL8XuDWqpk3fKICALnzu3pd5sXI5t0X ylJjGYbycCIKsZBsgSGhPj73AtrdWgrkM0s2sNANnfVxZ+6caVq8CRYfuTxMTvEw69ayeWOgPo3M /sO/2VHcWh6Pv9Hd03PSs8YFERAaasU8OZomWyGDbG13as8gBSaHtIJ2/Ka0rGxvWTy/uRw6ptTP DOD7MoQfIpCU+TMRZERpJyhrB0ZelOWnk13KKLscOrMsNu4pBMbfmd7PVpCd1+FObZpsolf3pjYq eVpa2gcQM22HuOBKaFi4FGOP2553290XTd9JDe0A5RnJJFskO4qHBGXeQw3pCi155+qZD9ZFFb2g LmrTe65DWeFKiqL+51WTzQ3Iduv2HTXWn3nHt+89y67Xuut9z8fLu+1OcSSDj5+/WbJBfNbAbBP2 M7qGURxuJi8uPtWI+Aep3BheSnAI6xHG0yiz/R3enkjopmxh9gRzZLvr69eIeZh3ocMkePKFl/7N kU0ISllihmzGJVRCJlUQMgsw82eAWU8ImWqGBDTZSuctoEmGZCvEdr1isplxNwcmJCSdBzdDfcv9 Nrl5y8MIdEUEKSlfM8kWHs7moYIa0njAoMJMLBSLxX942UnAx9c/+jYoi0G2G9QHZucGgUAw6Hmt uZ+f319dXFz+R4+/mt4bh2Rzu3VbjQpsKA/LDg4NY3X1OESr1f4rNDRMfMu9LS/2HRBIxupAtrQh oPQNzH7VTSIRqKt/wT41g79n5Obu8AsIrm83Jm7utEuYmPiwwwNxFos9Bqx0oxsjPbqFELsfeimy FXvdpWM2A9nyUDkhZis0ucD+lwT6DBKhEMi20Ei2fPgspmO2rs/6xxdGg0NDfwgICDrlh/ALOMXh xpyCuGuiZTsiuN973vF+esPVjdC4cZOO7Zi74LFvw8IieahkhnSoAGDpHgHZ/vyyfRDGYnuiwhvr AEAy8x8k3rJUhlZL9eTx4lJdb96qdLlxsxyBf3t43Aln7nLBvZFQlhp+a1deUFCIHNr5TEsKfTrM 3z/wR2Y+lAOTjjzBZAcJks33nn8DMy220cXVrctrvGLj+Ec979x9ysxLx9RmbpJlsVhjoK8ame3B 8YuJ4b3c3kixt09L0YpVJKcd2XDpPz/+l3wwTqlIFFk235omWwG0KxcXSugL7LtejeRyuW+53fLQ +IH76qO/4xrdwODg0DqJRDK266Vwdi8gjgaUk1x3cSXXrt+gLduDhKQrTLKBi8NDgmEaBA4qWJ+8 V7FdKy6OvwsV0SAbgfXBh88VUuknlsjg8/l3vLx86EnADa2j3vr6BwQXUYw4USQSfwT904TtZJZ3 082jmcOJmfesMh4+TL6GMk3zBgeHSU2vtBIA2UDpG5jp3MGaXr9+o8uH2n4s1idAHq1hTNryupwx Rzawgo3MtDh+QLbvX4psZb73Wops7UgaKGOunmzFuIOktDz+l0o0RFV5ZUQ5kAtjUHoSgcmkBP63 ZAcJDPKfvX38ypyvuZArV6/TuOx8jXZvQsMj8GyUvz4rP5vLXQQK+iPmpwH54f8WLjdmHZNsQcEh PJiViSEdKpznXe/iV/HgGaxjH6+73jVXQSazHjhbh0dGxZs7UImJCA5nKS54YB5j/mvX6QkhJJTl xXQP4e9/hISxcq+BUjLLwv/9AoNFuJprdiuYRDIeXDlFuzKwr4DUAUFBd0yfCQoEaUPu3PVuaKuP C53W2flal3sj/YKCBrm6uTcw+8PVzQPH9oyZHTFjIG0jM63HbS98u+DF3Uh8ebTcP6ClaNUakgJk y0Sl/OBDkv/pCFIlSK5VEBKoIsRfDVBZAMVPBAvqESDJzn5cNG4CyXv/QyPZSnFvpAXX/OLewqDQ UH8kwqUrV41wuuxMz/KBwSERppcaGpCdLezn5e1DK54hHxIVlFzD4nI/ZpLNPyCIhwPKLAPktwIp vf38ghZBrGQZAgKW4AlZpsoZHMo6d8OkDZegDTijgyWKY7N5Y0xXMmEC/geXG30GLTPWu33eqxD7 eRJuTIy1absfJCY6YvyE8pn9hXEPO4pTLJVKB5tsvZoQFh4pMW0/AurcyuPxFpmWAfHmkNt3vBqY aa/fcMNyuiQbm80eDJa54XK7vDfxswPZoO/HwNg3MtuPE66np5eQzebs8vUNWGjZ2ATZ8Ph8XC3+ LQ744Mrg0JaiNetpsqV+2FdHOFDQoumzSd2x40R24hQNhQlUAPXxNtQDNCZogDRaQOMLAvOiDFO5 9cfbl600qZv8hxOkdO4Cktezt45oBsu2ZCmhnjyxaIEkKSllKbo35y84kQsXL7WD3gVR+fsHeHA4 3EMpaWmHYBAOhYSE+ru735ZegUFipscBBvcnWQwWk0k2P/8AHv5mKt/gUuGnJUB356bbLSkM8Psm seeHGPs4XbrSTv75C5fIVZitQdHrwYLngRJd8/D0OgiuErp0RTRBgSim9cLvYIZPE1MdY0pwrwdC DFTJLOsiXZYTXRa4tDW379y9DG7yQfj7Big+bdFMy8C+u+vtEydid3SlkWzQ7w3M9LSMC05dkg3y DjaX9/zFS2bI5jcG6tx40ekyMU2PfWPpuOjjZG1CQsJHNNmqQ1ktxWs3GMmGyEblfPc9kvN/b5Gc f/6L5P7zLZIPKGSgCFACKPvHW6RcjwpAFUDCwGNI8wRQo4f0n2+T2mfAkA7zPDaRhbIrGeVh2SX6 urTV7V90XfPe6dFGNEAWkK1w6QqiksksPYPkD34BgWE4qzmeu0DOIc5fpD/xf4MSoZXwvONFcKHj irNOeRwNaQFnHc/TZEgSCDaYPtT28fXnoXIa0iIc9fKZ33UFrAuU0+jg5NThhVuweEuh/NZ29dKX QRMCFIpWInAvsT34v7k64P8YA/L5Cas6jRP5/NU4QRnSM/NiHVEBXfXl4P+mafATiE9y83PnmI9D BUPQOjHrdfmKM+btkmwssGwwuZjkhbE9f7ED2cCtGAOkbzTt5xcZF5w8wMJ9SpPtMSuiRbxuYzuy IXIYimoAPvQuxGdWDBTjazm40ZeBSnwzGg/ZMYPHXcBcniq9TGYZ+KKr2KQuRfo6mtYbJw9sX+Ey W1JPURYv/eNO/uDg0Cc4o585e84sTp9xJA4A/DT9DYmGcV5cHD/Y3Hatu96+8Tggncm2FFjO6bPn 1MePH+/TSQz5FRCq4SIQ+3lln0b5oGQ4qQiSU91M3U7TVWCIB4+ie4bKZq5POutD7Acg0tOkpKQv OpPP4yUMBWuhZebFyQH6v0uyeXp6D4b2N2BfMfOePuvYgWye3t5jIG3jqxgXmExbwVIOxc4Z8oQV /rQYYjbBm++Q5O4fGJECyOj+PsllIAcgBIgAhSYofvd9UgooY6AcUAGoBFQBqi1AlR6V+rzlJjJL AMVmyhfp65ZrgiwAtgXbJ1q4hGiVSvbzrLJCrDEMgvIwnJVxZjvlcIacPHWanDp91vg3/T/8bfjf AX7Dgbx23UUb/+CBm7kFDyQbuG0JqJSY/uVAk73Vydm504NhuTFx1u4ed3IwjkIl6LQdjP9R9mVn Ooaq5cXF7bH0/T0eL+4bsKZS9AqM5TD6p93fUAZ6BDAplaelpW3uyhWEcXjKbPsF6GfoQ6cu68Tl fYquebu8YNnByl8y85xtAlr7Uy89Lmdp1zuIxfoMB3ygpqiINIBpLxo/iRRPntYBZYDqyVZGVOk/ nwBqGZDqP+sAeNONYlJHKBlQAdQMMH8zl5fSy2aWZUCNSd0MKAeI9e3A9qlBsVuam0Ofd+c7HgHA 4XDWQCyRDG5LM7oGSDxUWiYMMQe4STIfH19fCPLHPnubk5/1bc875Tfd3KWAJy+KWx63a0NDwx6A sv7fs8qDuOqfXl5+O8HVy4HJ4Gn7dlzQ4zytwLoV1FtPwLLfzM7O/uR5V98EgrQRkZHsCFBwNZZj cKkNMLhYrjfdqCgONyA7WzSgK5kURf3Jx+eek7vHbamrm3sN4p5fgCQmLs7OgrxvBQWH3gPrWWPM e89fwuVyV5tZyX3Pz88/CMcF073ouEBZspBQVrZYLHmXXnUDOJGWltjmOor3Y11dBzSa+c6AZhM8 67eXxbPkdla/xnb5KB5pbuZBe2e9xMPy34lE4lFcbszWM2ccN2GgHxwSyg8MCo5xdr72naur2yaB IGWdREK9+xwycefD/74k/vY8GxBw8sAH9BFszjZwwTZ5+9y7ExIaFh8YHMI9f97paw8Pz825ubmr mHs5XxTgiveNi0vY4OR0eYuPj793cCjrAVh098vO1+i+0mq1PV5gHJht/+u/K6++X194XLSE/N1w VgtT6G/+U/Dv2K3yS34e+VO34z/1BqH/uAa/xmu8JttrvMZrsr3Ga7zGa7K9xmv8UslG2du/r3Zw GvRT3fpI+vX7L8ra5iutk/OIn0NnUDOte0onzez/k7WfkN8qV67fQW3cOelVyVRu3DybWrN2ndbT 81219YrPiMl7ZxbU6Q2t/eFP1NY2/X5OikrNtflAOnB4n1fa/2lp/1Tv2fcdNXBc9y7TQj9Cn4zQ Ojl1f2myEYr6q3LZqkJq6szHFJf7vz9VJ9YNH12pPnhk589hQJULlx5TzFsU8CrO2bdYiSbPyJPN sT76quQpZi9wlk2cFqN1c/9KaWNb2OziOcCSfGo3z/HS9dtpZVZ/+z1fPtf61s/pql3qc6vDtUNG 4vHtv9WcOb/gVchsFgj6KZavbpX+5c1RnaXRHDk+j3Jw+JPW3v4d1ZLlRU3evvteimyoXE1uHnPk cxcR1ZQZRH3k5CY98/+oOXnmqx+P/HBJGxQ0mkpL+6tm74E96q++Oa51cOjexOZ82cTm0vvktEGh y5uuuc7SOrm838Ri2zcdPLxb6+1n3czi9m04fPyC9uCRQyQh7R06LYs1qvnwsbPqfQf21w0dWaS2 /26DoR7NHO7GZm/fLfXfHTmrdb62t9nPb3j9V984aJycNhmWjLVe3tath487aY8cW43PvfDQFs2e fRvr9x+6CNa5B+Gm/a/m6InjDUdPXGxms3vDbDTux+9/uKg9dvxUc0JCb1oGl/tWw0mH0/XfHz3Z HBCwtYmfNBfK3QhW9gvtEYe3m/yC9mkdHL+o37ffsdk7aLC+fn/TfHdsu+rr/Wea3D13alzcjO9p EQe/P2vPX/6m2f7bixpXt/W0heBw1je5udsqd+7ZpTl09AjRv3UMZb+j2WO/HyaZo/LPp+ZR0+ca B1C7e/ebmlOnT6p2fXVOe9xxGLaviRuzQ+vmYY2zsPa7I/ZEq/0/bULCe81szjdNLu7bmg8edtK6 uCyhyTZlhgP1+ZSIZk/Pfprrbu5ELKY3Jqt371vean/oEpBwI1iu96D8A43fHbkA6Qa1pmTM0m7Y +kRjuyZT6+i0SuPkvEnr6k6/JAm/D2k8DH1nf/AbGL838a1nULjdTSdPzlZ9se+8+tjJ+SaW8R9N x05uaQGdaQoIoO8TgDLXNh847KQ+cMS4i1/j7DL7R/hOuffAl9Thw+9pff3siUTyJtS3j9bDcx/l 4vIXGOcNTW6eW4Fch5o8vL/Sunt+03Dr9lXF3EWtqv2H7jQHBJ1pCgqit3ZBvv+BfAe0Dk7Gjdha p8urWmHc1ddc6LvxtN7eI0BHzoNuHNGKxT2aRaJeisUraiTd/jBM6+m7uMnTm26L2slpNOj2do3z NXvVHOsfG789Et7M56/Turi5wOSFt9K8oT52fHnzd0ectOed1qBeNvN4o5p8/b6Cuu5vRN3lcunj C0GH95FDRy+BLg3RVSoh4RNQoDtKaxuWYv3mYOW6zQ9wVqNW2B1WLLSpaVy/hdXs5b1dteOLgHrb NbUwG/irjx+foP7KXqb+5lv6ojflpm0c2YhxruC6TCBLbIlm49ZmzR1vV8US29SGLTt4Grt1ecqN 29hQqalq2zV1DRu3S6EcSjN6IlEfOLhGP1C/V3+9X9hivYwo127OV82YRxTLVymVK1bnaRfaEFQE 7Xlna7nNysqG7bvDlEttpZrjJ7+rP/zDPZXtGlX96k0szcHDU5WLlrmrFi8vbti4LayJw1mgOXvu euPOPZx6u3U1qi0744lQ2FO+eDm/fsnyKtWm7UVk6UqiOefkVv+V/U2Fja2veuKkT5tmLSBg6UXK WQvKlLZrq4lI9KF6/8EA1VxrpdJuQ1LrvMVEPn2Oh3HmdXQeqtq2m6XZtOO+2nY10bq6rVTt+PJ6 0+wFRLFuc44ab1ldsPgaDMI/lCvXCuttVtYoFi9PUQ4d2ULNnLvHqIT7DsxVrdkQpl63OUm+xLau NSN3tmrvN8XYfqXdOgH0SU39nn0CIPSs1hVrCLSnVWWzUlAPfaY547RKYTXrODVpWrj6D3/pBfVW NsfFDQcrdUU+0aqkwXZNvHrrjhNaT6/j2p17YuptbOPlNsuzYFL8tt5qlkI1fmq1epndvrrBn51Q rtnIB8UdLJ82p7B+9YYs+F6qsFubjRMFNXJ8ptrGVqZcu6mUmjpLq16/eXybG7v1gHqJraphzcYw zYGDdmqny7sUS1ZUNuz4Mky+1Fap3L3HFhR1e8PyVUSzal2Kym69X92IMVMVq9b9CBPhoKaIiLny BUsaKCurd+TL7fIItnH3V7Ea+4MByvWbOfXfHwunhoxolc9ZmFj/zbfRigU2Wpjg3wSltn66dhPo iPMYWqcPHrYGUmq1azdGgaU+pvHzm6tYtkqjWrdJqF68vFK1eZuwOUEwhlq8QiL93d+HyBcuC1NY L/Wmva2Bw+xV+w6Uqr7a5yofNqpZZb0sr+Guz1ml7Rqp9M33+tTvtT+tWr6qVb1h60PVgsUNyrXr d6oPH99NbFYR0IFa9YIldcpV6x6Bro+AsjQtazeFKPfY2+oG+PDxr4FUpap1mxPV+w/xqWlzGsDE 9pcvWHRJNXGaGGZmvPT79/IVqxNh0Ms1l6/NwV0PoESlqm27wukZdfHye7U9+15Qz5w7Tj5haj0o +TQgzEblpGmNQCAn1frNoXKr2Y1QmTDF7IWl4Lb2UDu7DFeOmfQEyLbeQDbVxm3JSuxkQv5Q99nY O4pZCzj4t2L+EoFi8bIzCutlfqqZc4tV337voFpuVwTkyK7/9vvM+qUrldrLzstwk6x89sIYaqLV Q7W9PX24Tmtu7kLVXvtT8mmzY2SfTylVbt1tp5g1XwtWcyjRkneVNitbNQe+v6TetN1ZPnXWbcrK eqh84nSZevveAc0OjgPw70a/oDOKqbNq1d8d3oEy5fMXhcsmzXBlzOh/BWu3W7581Xn1qM8pmLgO Srv9drZ8/pJKtIj1R0+cqR04NFZ95NgO+cx5zeApjCNOTr+TfTo6i5o+/xuGO99d63DGXjFnobNs 1PgGzTXXbTAppUOfcegZdf3mebLREyj11p0LZaMnqqDvFtP9b7smVjFzvg/0l4N80nSWtNvv+ihm LijTenp/D+W1aLbvnmYsQyL5WHPgu33yqTPcZIM/U1OTJvVUrFzLrpu1gD5aoPa93scUi5ZFyRct uySfbZ2NM7fWz28iZTW7RW1/cLO0Z7/7YHkdcIeE0na1XLnjSy+DbPns+T9ops6mlDv3LqbHbcmK TKhXhurQEQfV0pW18sUruAoMV6xmGd+slnT7XX/5HGtpMzdhAFiq6dTnUyupuXPfUiyAMV+0zBd3 xqjXbLxKTZlxV33ccaAcDAA13KoHxlHU9DkSzbGTJ5TbdvrK5y2KMxyUpNy9d3P91Fmk4fS5C2ht les3hUJ7clE/qMNHhsmnz23WOF0+Il+yvBzJRk2w8gLQ1zE/+etb21EPMaajZi2oUNofntqM99/N Xiipm289U77ARqmyP0if+a9Ys+GkfOb8Us0Jh0vyz8ZVgCc1QLl991TQNUrj6DhXO2/Rj+rjJzej 8aJ3jshX2PHB9WiATHGK+YvjFZ9Pfao8eHgXcXD4I8w8Lqq5i+rVazd/Ay7av1QzF1wHt0eudbq2 X7V1d6Vq+276aln5yrWBtb36X6AmWX2uXGIrwe+kHw3aogLi1h8/GV1/6AhLfejoFcXcxb51oyeE 0tYA3D/ZqAklDDfy96qtO1JU278Q0L/PmHtZvWaDj06Z1kZBw09QI8b7aFZvrKr/4WRE47eHA8Gt 20fShH3Uazf5qGbOq1d/f/SY9vCRtxQr1rAVM+YrNMeOf6Ncu0Go3LAlFWbDS7LJM4V1o8atAVKV G+Oc9Vsa1QcOX1Zv2ekMgwBkmzkUSPxE6+TZvVu3br8Bi53Z6B8UAiR+2sri6Ny1NRu9ZdNm3zTG PHvtv4K+qwGlPSWfNDNHOX2uvfS3f5oLFr+QnmldXA/IBg2PQBccLE+RIR6qm2D1EPrTXt/+38jt 1l+B2bpEuWrtEZgwqtClU27ank5NmUmfeNzM5Y2lxk9+DMpnLRszUSLu1o0+GEixcvUZ2eTpAYoZ 83Rk+91f+gDxihs8fUJUYBVJhdT4prR6xxeJ0L4CsLSn6oaMrJH06tUTvBUOkIm+Dqn2/T5HFSvX xytW2MXI12+O19ftj9TYSaXq/d8eqxs0nKN196APLlJt3ikBsoUxiNyjfs2m84rpc2Sqg997UhOn Z6vXbCqEySay6dvv7mkcHPfLrZfKKZtlyw15Krp16wPkk2rT0no0s3ljZOOnlpO///1viqUrU6Dd W+g6b9h6XTF99l1w8T8BUj2hBg6kL59Xbd3lhpYT+qwW3Oy17eLQnXsO1S9ZoVSt3xIE+pMJdXKh x4Ki3oN4ljRcvxmiXLRcTJNt4nQfatb8G7TeTZ97UrltVwq4/W/CmFdQB4+MA7L1gnKrlYttluBE DbIn6VxV56+AN5Tm1NnbtX0+5tHlHjk+AnVBa2X1lmbft25PV6wmIH9bNwygWxYvJ6rV66sMe7iU C23uw2wq1Li4Lmg6c95KuW5jtXLpqvvNrIjt4JNaUROn5avtvw1Sbv8iUjFzXhn4o182LLRpkb7T 8yK4RJOUS1fWEy73T9prLrbgqhCYRQ+AWR/bymLN0pxxPNQw17pVbbdmg2LdlrNkyiyitP9uUxvZ dgqhA4X4v2zG3FtQLxZdp+V2idSCxWfR1VPZ2FKa7Tung9+/QMvljQI3yK7J02sRzHjF6u1fpGmv uS5tgngKOlSrBLdOPn/xUyj/a+jYH2TjJku0zi6LFHOtm9WbdtxTfX3grGrs5Fb1Dyev1m/e5Saf Mc9PajVzOFhqDbhRH6Iyy8ZOqmwKitgL7lgmzJCi+pOnz9VPm6Ogxk0yniciX2bnpZg1T6zdaz9O Pm5yFfTD93W//7u1cv2Wx2gZ1Jedj4MVSdBcdp6nnr2QaPbtd1FDvzROmIZ3je83km3qzBQgEhf8 /wNqcKM1Due3gmuWJp84rUK5cs109bZdfOWipY+bHBxnUeOmNKmWr7yh2bx9gWreYiW4uddgQrkA aWOAbP1AORQQC60GEinrt+3iKLfumdXk7bdLu2odUS5Y4qTevnu7bMjIFunwcb0VazdHK61mPaB2 7+5e16u/g9x6GU+5Z++X9fOXEO0Zx13K+Tbfy6fPa2jy8Jou++QzAcQv32O7VJt2qMHKsQ3111y+ PAPjMeWSFUmKtZtyYOb3A1lidDW1rq7LmoXCUeii1s9dVKXevXeZBkIDyv7gRLAqP0L7DsFEe5sa PvZpUwTHCsYgSzlTZ/XrN27zkE+bFaT1CxoC7SLK2dY7wNX8E7hvA6lxk38EUiggbuveFq85jWy9 5jpXtefrCJh8SpVf7XeST5kl16xZP0f9tb2/YvZ8rdY3YBUQVSH9w9+HgQW9ql66SqM+fmaXYra1 TGG3PgfjevmMudB3X5xpjomZLMc+nmvzuWL1xiKwbvFN9gdnwaT4GPQuEHT8UN2AYTl6so2HtPXq g4fHEAfHsfUr12bVDRvl2U06aVJ/UOgg5cGDO4wzwr6DC1RbdgQpN2w+rhw+OgLcADYOGliRYGrw yAjFwqVRWjfv0dRxh6HKCdM48vFTYhs374itGzdpLWVnN0i5bbcP8fP7M7oRDUeOn5V/OoYr7z84 VLlm/SE06Zovvr4hGzgsWrlwCad+/SaO5uQZK/1g/Q7860sImmB2a3bCbPUtPYPt3nOKsltvB27W ++oNWwLren3EAqsYCW6UtfrA99cVI8dHySZMDYKGjlYutbugHDqaBRNERBMnZibMUlcUw0ZHqFfY 3ZcvXOKBFlXj7rFFNXtBuGrTtpj6eYtbQfEOQudsV9qt/VptZ9dbuWWnL/H0/JeoW7ffw6C7AanH Nnt6DlAsWuqvWLkuqmHdJjm4Z0Y3Esg9Uzlj3n2IjVgNazbw1CvtFkn7DRwNZKZX9bQeHrbUzPln 0BVU/XDqvGLUhCRw0WIbt+yIVq9dv9DY9/YH1ik+nxINgx8LVpIDrsgs1ebtKWApC6kR48JUVnN4 oKCz1Q6Oo2XjpzSAu5kkGzgkSr1hWwChtD2gjWuh3ceoXsPfVa7f6gPx6fvqPXsXqSZN49X2/jiy /sy5CPUl5+uyoSMilYuXcaj5S0IkVlb/h0pfP+pzHliSXTAL2yk2bj+Fp2KBa31ZMWZijHL81Cj1 xu3W9LjMXniuydt3KbZLaX/IR3342HeGyVJz9vxNasSYKOW0OVFad/f1JDu7HxDuft17fULUU2fd bwoK3QFWYmz96vWxsgGDueBms7Rs9ifqr/ZdUgwZwQPSBIB++TXx+EsUm7afpcCC02XuO7gbYt39 6JLD9zepoSM5MKHhAtJ/Q9hTpfry60Dm6qly524b5bjJHOX4yVGa747QrwYp5i0+pRg5jqOymh2n PHgEF9feBN3wpd555wOtp+enYPnug9fAa9i6I0a5Zdc5lA3hy0n18LExEOfuBT54aHsNfFvr5jYW ygylPh0VpVi6it0cxOqrPuawELyli/QYOjoOgL73AiM0vnHk+HD1uIlByr3207pcrvTr1u2NZ/1P dzK4Ws+UATMgu1u335nk+e3LLC1jPVCGpfVklof1hZhiNSjM4YZvD58Bd1WjtrEb0+XyuN3aSWAV D2tveZyEIF6jtNv4ZYd62dhY/NjAkvZjDAJuZEldz37bYAIzthdiv0lgcRuo4cPfZfaDpWPp10n/ EzP1x7TdLBwrerO3mfrAd2+Ylkn/z9AdPwvbYRxPF5e/qTZs9VQuX4Ux8Giz9TbRTWJGf7vSZbqe jL5/FhdM4dSt23/9R+8gISLRf6v37fdSL1yaplq8PBUs9tddPVujXaQjxw+rl6zIUFovTVPvP+QN 8cnff4IH378Ha+SmnG49k/m91sVzsGLLziBquNXf/lN3ZGgdHceoFy1P0ri47PjF7SB5jdf4RU2a P6OH7pbg/wEbUqLbHTnAxwAAAABJRU5ErkJggg== --_007_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=3172; creation-date="Fri, 03 Jan 2014 16:56:45 GMT"; modification-date="Fri, 03 Jan 2014 16:56:45 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACsAAAArCAYAAADhXXHAAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAvkSURBVFhH xVlLkFVHGf7v+zVzufOCy8yQYniMhCghMYXEpCpQYrSClAvdWO5dZGO5sSw3yC4LXagrl7rRcpOF VbEiEglWUYBICiFIGAZmeAzzYB73fe+55+H3/X36cmccYChi2VPNOff06e6vv/7+Rx/iJ06cEFuO Hz8e+/57P3/7raPvfHd8+9jBhO9tiQRB3BcJgs5bj7+JbOCdx42DvhH2j8RizZVa7e7E7amP3v/9 H/54+le/uASM2i1ux79afHHo1xcuHh3fNvqdLfnePVGJDPoSzfiBj9vIRrBuAOrjXwmCQMHGIpLs yWXHBl/a887YT348+va3j/32p187dBqAHQULRrPvnTx9eMfoCz/cXhza34Nn5YYjbTaa9T52Ftvy 3KshtZglKpJIpVKZvkRsIJHJvVSvVtPv/uZ3VZm9fVbBvvGDd8e3DvYfGx0a3J/E74VKXZo+Nv// VOpeU1peUnoSicjwQP+RA29+5bMfHfvZZQV75OjRlwu9va9k4hGptVxptF3xw5Wuh9eyiK0zzWD/ yfw/26pJU63ZlCjG39JXyJertX07Xv7yl+KQQPKXfzuzPRmPb3WabQXq4iVO3r21drs9PPfDdugL 70X0N/uwxAAcW7mq77NBNX3b2Nl6uy2DmaQkAn8g25PbQ2bT4rR6fN9P8wUXFUalILoLsRhhBJKN xSQXj0k6GgG4qLTxft3zpYbaRuWC0PTchXhaGMV13FgiFe8n2ETbdWMeQJAdXr2Que7Z7LPeeFyK 6ZQMJuOSiZFDMIs+5bYnS9iV+ZYjdRcyCrDc5wTM7i6q43lRsIiZQYILZlyygpV4ZBY10jUTGSWz vYm4jGRSsjmVlHhXO3ybFNCWAeMxAL/neVJFXU8Sz4KfWFzM2/bdiA9lqoEFgK9gMYG+QL66wgCl QSADyQQYTSjQMl662RBZwXUkJbIrI5LC3m9JpaQKlitg18EMa+VAEjYKOED/NpjyPCBGJwVLcB4a CIpgWe2AZJXPydwAtj4ZjUoVHS5VRM6sCLZeZDeAtvtE9uRgAJBGP95baEWk5EK9GCAW6omGA3Wo BUUBmgb6pBJESCDlqWZtwPoEigfUpYIFw1YGBEtrj4Mio1GRO02Rf5REJupYCCauY6wsEA2nRWgF 1DUZjoij8rGSUbug0aCq5PCboB+HOYhSBqwBxgEGTu75cFccgJasA0EgYYQlGwRLNuKwfJYSmH0I RrkQslMDWP7mlWDpKcZ6slLMpNUNGTM07zsYf7HVkpl6U1YcdEIDtb1eiYWYKFG+aJjFn4cHLjWr gHXDtL8Ba9i3hZvCan0x79mKmKKFu5KGxlnXK3kaYzQmE5WqLAMw2aMLXOudKQOLiSs1msVshlHj CTyf03cBVXmYrbCF2Fs2gOEhWZ2CwblM0dYg1KXjnwTwkHka67ZcVl3e9ZWKMp2IGiNalTIpJk+N n9yGMvB1e1w0MCB4qBYsAaqW9VnINt0JqoNKGXCQGXjvD5egV5Bpd8NiJlAadAYv7ocRvpIXKWAb CHi+0ZSlVhPze/+l3wCYiItBhwszzOLFJiTQhLthPPaxEssO71zQaNg2T9VDECy3Bmxxs5eo46p5 pWP1IVp17gSM62cwSgfXI/Ae9CyURALXCkJrDNTS4DqLRI8WAk1LvUroDTgIfWwDYOOcCWCNHsOI pmAf7S+ZUmetFOIegHnfpE+0q+yyGd7yOb3GApDuzIq8WYAhoiEN7XLONgAxo6Wx6WLx5zDnAKYW HACLSb5DzTrowEmjYNF0Asu6hdTyIyXqerjA8BHlpsyh2sRy7dGCWqYJFRIiA5jVroUktQCIhsQI 4sPQuJucz9eBsYiQgdDPukJ96Au4Bh4Ypv8LV0njom4tXF5VBhZcKIc+AEkAhWFmdWmF77yOzP4N aDarXjCQZRhXqe3o+LpSeAATmOCDYyQLeLQtlIELngjSeAJe8VvzLrN+DkT30gHLBWNgMstFu3ht N0LuN6DDEQQGFi6mu3BjUgC4He0MzywEOttoSMVxoNeoMUyyymXgB6OdDVI+AoSRAVqVVV0FKpmk CNiBzfQGdMwhAA5mZcDl0N30YaSDYIx6NJytLt1u38HOTVcbMlkuyUylBr1SI9y9MByHXQOcAJRE 9QZWs8TRkYHRi66BnoE7EG6FnZCDklWe0SxY3pA5W54U9udqDfnn/IJMrJTghcAYvAEZJDnd2R5Z UPK4dBsUiFuBETAdMC0/ZId6sRJ5pFoT1cJkSK9VUM3A8PQCK6fngauq8fiE8W041jm7LRM2Y5ml eZoU0VJNusNqJ9UjC50zJqCDpiRzcKxMXMg/U0ACn0JycxGZWBF63NQ54K8HPSLFnpy8VtysTN4q V9QbJMMkaVUPiFYjJzOvjoGpa1pd14KtOa6UW23JJ1MwkIhsBahWDVEJYHtBzQI08f4ikhywO46U MclF2N2hpFCzeLYDbcVUQr7Q36eJEQPRZKmMNJXnPsbb1Qd/2oqRpTUwyoBGxYawdouPKWMZlrsI yx0GK8PpiOxD2PxrySTf2ZDJT5EbMOxugQvLYAHWhfFKN0d39VUY4Tf7jSGObcrLZG+P3AO7TfhT pqHdCaPxWEiu1O+GBqbBqSMBkx90inbwpQKwD6o12dlXkJ5kUg5g0kMIrx8uwwWBzT7Igj52keki qhoYUYZMMTQzDt2EXPjeNoBNAlx/Oik5hFy6L9Vl6NuN0SAw0b8zE0TnkJNHzlcbVeSPnA8HqMJx T8J6dxQ2yTi2cCf2/3ubEUIxyKmyyBxkQOYY2rnUruWaozmeMxzfBvPTwMXjShLuKokMLAHQ9AZM igLc25mDAL63k+11ZGB4VNrDRKY7fWeiwmTiTqkin8zOS186LUPImA5sMn2GoN8LAMxkRkOw1V3o v3jh8yRQv4B394JVk/tG8G3AfFThQCrFbgtDNFPiQvSdoKDPyGqYtHT7O/WlqHQ3VxceKtiDo1sl j6PL6wUAgNG8Bg1fh2aXMS9ZXXtQdICC+eyrCLeH0Qc2qhY+V6vJCtJEIxujTasg9bOh8pn0dU4K JnKFHoHBVk92jwonR6iWErR7/t59cdy2vDpcVIMbQTT41pDI19FOXaqK1kQFPuMY9AgMHtzBO6WS 3IVxVXFaSNF1qRs0NNoAoTutIRj5irbY1VgjY4q4zrlIH4H5WbBx9u6MzNcb8sXBQdle6JXNuTT0 BzewgVLBd6zJ5ZJcnpuDJ4B+CADkdGd2CouEhcZO3SvYaERTXuVCsy76tTXMKAbmm+HaFrF1lQdz Mluuyki+B2CzkseXmsR6zj0kmpw18E1hoVaXabA6gzNYC26R/taGVDOPkaQhrJOQm48cNNcI4jPB EKiGwG4XYtniALjn4Y7pGzU3pVtZljSO37Tsp33jYvZGwDzvcQ6eEsINsziVTILleRNEYi7muIZZ 32m2cMwJ2rFYNMPVa1LxhO3k4CbU4njM+I17ft/iV7+nFet/owDJY4w943X3U1Z1I7EQkgj+XKfR JNj2woP7S4XhYqlQLObjibY0oSl24IDrle6FEDDf4m48aYF2HI1RxpZ0yd15S/hEP7LEQWsSwYem 1Ww0Ggt37swRbOvmhXOTfcPD00NjO7fl4fR5UqghtPL80wlDT6Nsg+1PXpBZMIH29PZKDuF4eX6+ /eD21N3lGzduKbNTH398ozg2/kl+c/HF0R07Bzb190scFu9gW226uEEsz/1aFAfINL7kZDIZqZXL /vSVKxM3z527BObux/G/ID6+fs9cO/mXM77XLrYPHX5rZNeuzblcTtKa3yKNWLtXzw1p/QGozyhY 5XVpdja4e+3a1KenTp6a+vvZ8+ixYjPPUvn+9OWrH/w5W15crI3u3btvcGR0MJFOp9TVrckV/hdY TXpIY/KCRqVWn5+emrl/5V8Xpy5e+Miv12/Shi1YmvFMfXHu7PUP/rRw6/y5K1t3j49m8oUs3AYi NEt3avL5wwWnOmjbdfzq/PzK3OTEbb9a/TceTaIuUQEKNvwfvBrlgJ8NZ3HhwfTiQh/uEfXDUT5/ fI8bkbkMv+08DOsK8KlP/A/+yzuZaNBbhgAAAABJRU5ErkJggg== --_007_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=2971; creation-date="Fri, 03 Jan 2014 16:56:45 GMT"; modification-date="Fri, 03 Jan 2014 16:56:45 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACsAAAArCAYAAADhXXHAAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAsbSURBVFhH vVlJbBxZGf6rV3fb7aXdjuPEzuIsThhNyIxA5DBAIiE0DHACxIEDV8RlxIWrlRtHpLkjDUgcQMyF IyKKgpRMklEWEiZO7NhZ8L52271VdVXxfa/eq65ut5MoY/GSUlV1vXrv+7/3/csrJy5fviymTU5O xuWbv/h+9juXfjo+cerCWC45nLUk4Xu+76GT5Yddwwvf2v1b9JcYbsxr7MprHu1jxSzL8mOWlDyr Nr22+fL51MwVufq3v8iXV+8AoxoiEQL99OFQ7Fef/PDCudM/OTU2cmYgLYWE52d8141ZvuWrCTrg 6oC/pdde77T/7otvWQDrxWOpM4Pdx5dHCx/dPXlsdObhR59OTv72KgDbCiwYzQ798neXDk2Mf/zu qePnT+Z7xN8uiu00pLEHyFfz+ZZPYUEsFktmspnMgfzAoBtLvuOXq11PP/z1Dka8HjA7fvH08LHD Pz53Yuz8kZ6UVFZXZXOnFlL5mpV+S2QdJKUlksTcuVxWzhd6rPLRke9tVC88nvz9x/cDsN+6+PVc of+9Q30ZqZXLsl2uiu35WHb8+38h1dipN6fRwMpWJIe5Rw8N925ul87d6hp/NwEJpAZ+88mxbFdq RBqOlGBVzXbFimnXwMtRXb6Nbt+UejM2/FkqNgADS2agR/KZ5KD05c6Q2a5MQnos3+uq1B1xHBeW gdW41xGki4Ec1xcOGIdDJGEUTi193xTcXv1IDsf3ARiOI3DyuCQSeYJN+g0n7rieYtR1XUgAzEZ8 P7QYkFwADR5Z0sC1i/cScdxBLypk7FNzCbgREx9ODkfHMnsJgo25nocfABKWcHIb91GwFIQLDRNM Tyoh1DbP6+W6LGxXpeJ4koyz1/4wHJID4lyArdkNxglLORikqpa/BmGDLvxHCvCa6iRIGjTUk5YP jg/L+dG8dIHO1XJNrs0sy/3FTSnD0AT0EDXyq5DM2T0BFoAlNrYALEAasBbB4mAYMBmnivsMwI0j /l46dVCODubUyxOQRaPhyXyxLI9WipJJJiRBOXwVlPpdzs21chz6EaO9Buv7cCpQXocFFqnHEQW7 A5Gnscz5TFr6MqkQCs3Jd6cknYhJFQMiZYoHdvcLLMOmcnjiwWIrZj2wY0N3BqzHhxEHowR2ECmW oc8Szv3ZtAJMp5xb25bFYlU5m433fMhH1RFt7LYb8Lrwzec86EsOsAkwBGBx7biNACwiAZ0s2vgS 2b09vy7dd+bka8O9yqGWSjW5MrMoc5s7ik0a5NER9UQMbal4XN3TH2yMi8cSB2UpvJ9OxtV1EEVa zTEyYMp36FSgQIF1ANDIANTsAss4yonmNnakWH4ut3JpOFhM1sq2zCNwO5iNMiFQNqV1XDZwX4Xm GDMz6F+AjJI42/CBYq0h65W6As2DoS+KV4FFSWfHtAwg4MDBAJCsVnDEYUEgg2ZjIqDj5KHXw70Z 6UbYoj5H+nGOW/Jsq6IAnYLjjeQyKEYsqQPQZtWWaciEYL4xOigTQ71K8xuVmjxcLsq/l7ZgcA3g LegewTpCrpIJ7mtWsOJ0t6A2wBIxexVrdelOwG2gC05uGo3IpWJytjAoP3t/XA4jBbKR7StTL+UP t2eQnhPy4dnD8u0TI5ICezv1hjxe3JAbz1bkCKLID945InlonfKhIUs7VfnX9KL89f4zebxaUqtC AoxWeU2Stry68pNQBhRtHcu1BbAuLEzHWMQEjZjLeJYCmL5MUt4bG5QCKiLTniyuQ0ZIIpjsGIyY ONgfPjvY0yWnh/thXLcM9mRaVutAb1YOdmeUA/357qzMbZUhpTjSdwCYXlMGoSWAduAvjGNh8U3L WDy4sDqLFUlieY3465BFzQUjYJIsm1ZndsE9Y20s5kkV73PyFByHS1gAoKG+LPo0ZAmxuDudlFxX M/QdwLMfgfHp1aJMr5dgtK98wQdDnKuM8Ori3uTxAKxyfoxOhtHJdXxJYkJqjc5F53M8qBnPo/mf QlFpmEmE8VU91PLBe2RoBaXetcfzMoUsd7TQKxcnRmUUTCuHQhsb7JET0DIddBPSaXgxNabNMpEj JLRxJs4GGyM9ETo2GL7gdDYqKhAsLhjzYKGndmLNxldogMfCB8YwVBkQ7FWCg312Z1b+eGNKXixv SR+0WwHLP3//pPRDImxdqaT0I0qQNafmiIsJFRJGFov1S8hmUwbtKHyUia4FlskASzUw7bPiaouH NAAlHA70JfORgZZLFfkHWL0xuyTQmMyD5eszC/LB+HAIlt0ZPVRshyEeaxJdFEVoUfMGMlBbTXRW zPHQUxrGORCPDjWgCq3QrIcQQ73Sg00rVuuygjClGpyToIqIrZs4oo2Rx8XqwGIc0HtossET9A7A EiQnMUd7dmchzKND1udEHjMTwFLbgW51M8ZyfKyKBZfGYqFPh2Qc6l3jCIAF2HSyCaNBqNsQcNR2 TtQMZ1EsZJK6xXa9ha1mn8Bxzfh0WB57dI4QZsASMK4hjyZYLr+yYLcuA+ZZkEcVGQwWRAguF1hr ex7Y3cZUx/E5VHRuM4/+Ta+WBmt0GpVCxHY14WvY6NBBySaUlwbUFlGCUbFqURmGUjKGBviacdaw 2gmYHkilwsjenNdqSfU7fBR9zmdNEEE/VaC07e+DW2OYXtyo1tS1rrpCzlqcLMIklhp5RcVRHqYl EIeZ6xmLmW6TSJf8zTRWWAGwJhD1DuqPaGMZGeCl3JoZq305I5qNWrR7zen12LihRKzJIII4e5Tr NlIsSsCALvVxYhuhKou0yn0c+7IcjLaybcsaivgiQ5pSly+b6NegE6oW9ZnWJBQBq61V7LbV+qyU wNyjpU357IsnKA271ZCsBW4i4JeZcjHZtZl5tYnMICuxaH6KnL9cxGcqss1yFaenayX5+71ZmUZG CwjHexiD26IwTISa1ZiYydACsLw2tZn2/JaNCSqxKsDcfrEiDxfW8Z1Ap0RMxnKviqSwg/Ofbj1R slDfcvCM2x5V+OiMxBWYWd+W/34+BSno4M8V4zcL1tDhVyCzsq1y0czS8hCtDiORjmQFg9ax7PUd bt70YHyHVRF2tWRpGxkryHTaeE7OZ5H0Sak4NYwR3TpBs6iaAgyhAnEReLTGZhyMLmyBLtM5CJvN ZpaFk0YcSHUwNvFMYMkWiWoAER+gg2Kn0dLCsNoWX4mcEkAtHX7kUDMqXRlPjIq8ffK2+9ApIsA7 Iun0nv4tXMQIWEMQcWmCCNnT20cHH7+wgcKb0OCeSeAVc+7bI+PglAcPYrQrNVVGytbChuQLRek/ 0CsOdFevqsJj15LvG5pXDERGWYHxM1waNS9Zt6tVWVtaJti6PHvwVAaGn8vQ2Jjk8kHnKkIOz6G3 RCfYK/d2AtHq0UGPTt6uvZKnOITf0y+S7RMprjqy8uKllOZnA2afP3wihbG70ls4KyPj+HBbgKPg q4tj65jbDq4TgL3Y6mSYeT/yjFWb8nxoNNMNVrEprZQ8eflkWmYf3MHo8wn8FcTD1+8F+c+ta4hP BwHwuzJy/IB0wzIyq4ri1kwShoD2OTuS+IZgud4EG4NG6TdbKz6AYp9+85/y4t5NgN0yMaQotfX7 8uX1rGxjTzx68pzkDxUkmQo+aoWp0LBnMou+7xzD9Yq/IVgTT1Ve36nI2ssFWZj5Ql5MXRHPnsFg FQOWXxEWpFa6LtOfr8rcvQcyfHxUsthL849Twa5td2sH+Spcr3VOHdhdfIUrbWzJ6rM5zPsIrz3F sUEFKLD6L3hlJQe4ljRqizL/aADX/DIRTQ+vnXIfOtCr4d2ypo8t4COZ8j+FwS4ugdbilwAAAABJ RU5ErkJggg== --_007_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=3305; creation-date="Fri, 03 Jan 2014 16:56:45 GMT"; modification-date="Fri, 03 Jan 2014 16:56:45 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACsAAAArCAYAAADhXXHAAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAxpSURBVFhH vVlZcxTnFT29zIz20Y4kJNkSmwBjcKVCmcQp4zhOxaF4Sp78J/gBfnD5B/jZz3nwS54cHnAlTiiX KzY2OMYQBEYLSEIrEtpmV285937dw6AFuyqWG7pm1DP9fec737nn3tvjvv/++0iO9957z/nwww9/ f+HChT8PDAy8yusHeLo8o+qX9u+NFQ9d5vGIx9WPPvror8T3LU+dX4Do8eabb3a98847F1pbW//U 1NQ0wkudPOt52j8z2DSPIZL1x0uXLvW/9dZbf3nttdc+I+AtBUtGG3jxja6urkvZbPbM/pH3o0ZO 2bZdX1dX18Hz5PDwcN0nn3ySv379+pcK9t133z1KRi/WAo2in2PndwdvgYoworDa29t/d/r06fsf fPDBLQX79ttvnybYV5JbgyDYkwLLMqPULma3az+Kw+d8ScYkw8hkMi2u6748ODh4yqUE0hcvXnwx k0n3JvdGu8UTiU4GSMCGYQjHcapT+r6fMPL/YlUybA0XwPM8kcSIMFu3tbXVxInrEhC7SUC2Rhgv lUoKmjfrKwcC79dBGRh67aeSkIwj43Feh+y2C9gUGXESicoXonCnXm3HhjA3OzuLYrGIvr4+dHR0 YGFhASsrK6C20N/fD9dxIYzLOLI4maxWJsl7+c4PHZFtwPK7Nk9XwMqbKhsKdpfgsqgfOXK5TUyM TyjDqVQKY2P3sbq6BgaBamz7odLhQoUA3Vp+Z685tt8ruOIxLb63NMDC0OcAAvjpuePGwNdJhUE5 5ufn0djYoK/NLS1oa2vF+voa5ubmVRoHyXxbRxvyhTzyuRxcN6UykUXa1Hk22wLXdhAqMbs7TxSZ xcunAjwGa/6oPbeD9XyPq3TR29OLgf4BjN67ixs3bug9J06e5EKBO3fuqCREwwLw8JHD2NjYwMzM IzQ0NIA+jpnpGTRwkadePgU34xCIyG53Sdh2fD3eaQUr2xLKNsVbFYiwt6MNZH2Bbn33gW58+91N SmAMZ86cQXtbOwHNEOwohg8dQn19AKbLKiNLS0u8Vi82pNeF1RMnjiPKGGkYdncegkmPeDExszWs BpSCnDvu5QJ4MXQttLRm0djUqNstshBneLz8GGtra2jNZlVnIofFxUUwdSNkoG1VKvDIeKlcRqYu o8GnO8m59gq20DLMBvGuV2sD0WsQmgH22pYgYrJgwKTJbrYlS4ayaG5u1gHFIcQtRJfCvjAm14zF 2eB/LoKerNFNAAJSSHnOfMkihPmqZmUSodyce69UbYiMqLXFriH3JjZVKBRQyOcIzIa8lwUJozle S6VcBlsOOWo4RRP6oRgRAmgBhlkuSo4dMhDK5dztkO21CNKX5MDtzBNQmWBo2AygRr0+8XBKGS4y 6gcGB9Un19bXGXQV0Nmx8uQJGpspDSFFvPh55MQ4ZNerYCNubxB4CIThmPJd0UogSEbhmeH2t3Z2 wsmk4XKrh44cwdTcHEbHx1EplXHs6FEcHhlRq7o/+QCPn6ygkUDr6QSt1HlkMtNzdzKkLANappw1 zIJsBGSGFxUsMw8/fRqkBElWQyelrxE1eYRA2js70NXRqex08v2vzr2KngcPldnh4SF0d3WSUQ/n zv4Sa6vDaKAjiMe2tbXp5FtkTHYq4nxJRMd1kkqLAtOxngFr3IHbLysVsHGarIKNR7Bo8M7SIjJr qzjED0e4In99Ff7490i7Dk5wMaeaWK9LsC7OYmt2mvJowlkmDWvoBTDDw2Jy2CK4yuoTBLQymi5Y DRGAVHqSms2eapGkehV2awLMiN0EmGqWLGsOT8w2xQKlVEF6Ygx1N67BfTRD8QewCapOFiZplN9l Kjd9BcfwPZ8YXDitbbC6uhG1d8BtaQW9DA6ti7BR4eIq3QcQtPK6gVhl2KR8cY7Yi5MMpm5QY10i g+oh288/MovzyNz8D1z6acAo98mYgHT8LTTMz8BeWhDhmAnq6cFZ6pIO4K4swVlfQdjJCrSDLV1H OxwCT1PrqaACn6RsSU0hFiiBVBPccRGjgEWTTzOYSEBtycjBHKQr4uTCHrc/NTUJR1g6ew7uCy8i InuYm0XwzytwpidhpbhxlRKi3j5Yv36dbPP+v18GJidhlyvA5gaChQzL/07YZDTT2AxXiGpqRkTG IVmylqi4LJXaRY6n1hWbdJJVDFajg1C8lBblFDYheFjPAH0HOfk6wtHvGCll+K0dynIoLHHr3YFB RM0t8L8fRcjdcDfWERXz8Du7EWbq4M6y1kin4Pb1w+7tZbAZoFbsqYYqcYs4UT0DVnO0eJ859RD2 tdCgvxKhWy7CmbiDkAVJ2N3HrZ+H/cVnOnlw7jzCuUcIuZ02t9nOF+CTYf+3f4Dd2IJo/B43idH9 ylkE/UOIJseQGrunnYZ1dEQjX2JAYiEhyZJd1fLVJCqTbuOUt6PqEhXIguPPddXM71a5xPxaAApF jUF75ASiE6cR3WZqpTxAeYTSUfCfOzxMy/AQsp5g9gBePAxn8AWyyvcLc4hyBURMLlrMKFjOkbiP KbyNZhk5RgaKd5cSUVoU/tMcrh7ML6YbENU1UAvGhtCUVQ0i24qosQk2X0HJRI+5C6srek9Iq4iO HGNPkub9GTLdAHdoCDZLTXtxyYAVkAS1A2wszxrN0stqKiABZzQbl49xX6UtMr3JtMqxtcmqJXhY tIApGCW+xhqy2EFELMhZDADdPWQ2ZbqGfB4Rvdpi1SbDmNrCVHu2zJ0wK6qVLKa6jQPMaCK5aKov A1aYld0xeZwSioVs3sspujJ/yDbKfSYl64Ik2KjJiCWXWrBeZ9AvLsBjLWyxnwtYpUl3JY4jAabZ LAaru6qafSYpCCBTfD9TdcVg1eT5WZlScL0ygXsys9YIEd/bjNqI2cijDFLS4VKzkaRl1gyhz6KF bpJ0vSFrXJ9FjU2AHj8XF/DiGkEkoOVpDbNPe7eqdRn2ks42Er+LWTT9T4QKrxUINuVzIg7uEGIk 9QRTsOux8qJvRkeOw3eZROi9wnTqQA+s/hTCqYcIpqdU4053N1wWPRGLnvL9URS3fKZf09rIPJbM HfedUnyL54s8qpqVEJPeQG1LS8Q43cbqC50IW8z9RSeNDAe3Z6Zh3fwGoH/63FJ3YhypQfop3SGg 9wYEJ+SkWbg4rLA8JhPvxtda56Z+cx4u25pg7C7KtK7SwBCzYaMC0uSjWcwEthCmmGI51HQKSS9m ACf9fey08JllSl29iKbHEd25hXBhCTa3W4qbci4P3PveOAZLTbE3malw/RofodTzOyzInyyppgv0 YjZkzIgL3JkQHn03ZMdh7iWLqn11dyMdiQK1z5pHnvqFRLPid0kVI9UbJ/eZlcpnfoGA2cp5NIWI DmBxAouMs/xHuLJIbcoiObr4qcwgQcOO2KIb2JRH5KYRbW4i2uBJ+wtfOg5v5CQCgpc5kiI73tCa 5wumI1RmuQI9kqh7lll+gQNJ1JaOjcBjuedw+9WiqNXIY5LQVxq/gBUmYr1Lgyn9F3saebaESDxW amI6RCipuPcgMyFrDVnU9udkqoLYZXS8+CFHYlN6KfbbZ56uiI5Y//nSlR4+DPbbhjU1cqFeonj3 x07KtFiYdoycXppGqV8lUQgYASlZMXbF5EUCTtsosTup/OJ0G1YqFY9B5Vm2JZWzySbbDwEXN4m6 11rAynZLx/r0y6ZINIfZvOQPc9WwrqyYUyJdNRofcZLQ+JLFyVwMo0KhVBYZeHzwsMonLRu9PT0t 2tuzhzLPpWTkGiTCQrV63PbZNsBVjDveCOIEmgRTnAmTNWnc0BrJvkv5iJ2V2cjxgeCSgK1cu3Zt 8mDfwWn2TQMtUljH3Wno1/K0g+t9usCCnlKRhyPyTIJPc7zJBw8e8enPA2X26tWrY8eOHbvZ29tz /NChQx3S0EklL63JXo929gkpgdr6YKSuvg65zc3w9u1b4yTzW/6CM+fyV5CQT7/nr1y58jkZ7Xnj /PnX+UCtW54QJuXZT/Vw+IcWKPoUsFLs8NFTdHf07tSnn/7jX59//u+vee96khQ2pqenb12+fLlh eflx4aWTJ18+2N/XmcnUs/00yWK/Dy19TEka5XK54vT01Pzt725/89VXX13NF4sTnL+YgGXawTz1 8eXHH/9t+doXX/736MjRfv4o0mBZjsTnttDeB+hx8cLdDZeWltfv37/3MJ/P3+NMkzxXRQEKNv4F ryBy4J+lpeXlBZ5tfJ/8aLcP6PYcUvyG+Rus3PVcJz4hE/8DoDIPqE3mn50AAAAASUVORK5CYII= --_007_D051DA3EDFF6294D9CBD8DDAEF9BE6F62FA2D90CA4MBX02a4mailne_-- From athiasjerome@gmail.com Sat Jan 4 02:59:08 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BC61AD34C for ; Sat, 4 Jan 2014 02:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.698 X-Spam-Level: **** X-Spam-Status: No, score=4.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxcKB85di_lv for ; Sat, 4 Jan 2014 02:59:06 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 842AA1ADE84 for ; Sat, 4 Jan 2014 02:59:06 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so16198652pde.41 for ; Sat, 04 Jan 2014 02:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=l/qy8b6dhQ/J1OHGZN4VeviG1s07xW1pHgJ0PSPL55o=; b=ttRQq2L7iUT9zrF55zm8lIMd+8msesnQx6hdyM+/q8ujNRNffO3/jB1mBkQvpBYsW4 IlKhP9OjCGuow8ilM1JpBkNyJt5X8tS3PfmrJhqVP21VWM4VQNrPkyJd3Td+DbvU8b57 Jd6JaS0efNm8+v+mwnIqQPyGYBYJe9kQTwthQ3vufXOgkKx3eaNTAl5zqQysn7mrLneK y0h/Sm+aMWy/Y84AAoZxxxOyYS0sRTo0zcsaejJZALqYpoZRK4u1AEAbvHByDMhUhZjA fYQC3hgjPp6WbZOHt8ugjq2XFMXuhv6QoNtSyn9GL1vhXSMc5am1ByoRbSIFnztRB4Zm iBFQ== MIME-Version: 1.0 X-Received: by 10.68.136.66 with SMTP id py2mr12256863pbb.112.1388833139028; Sat, 04 Jan 2014 02:58:59 -0800 (PST) Received: by 10.68.195.104 with HTTP; Sat, 4 Jan 2014 02:58:58 -0800 (PST) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54BF7D9C@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54BF7D9C@marathon> Date: Sat, 4 Jan 2014 14:58:58 +0400 Message-ID: From: Jerome Athias To: "Roman D. Danyliw" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mile@ietf.org" Subject: Re: [mile] Call for WG Reviews of RFC5070-bis X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jan 2014 10:59:08 -0000 Hi, Happy New Year comments in line [JA] 2013/12/20 Roman D. Danyliw : > Hi Jerome, > > Thanks for the thorough review! Comments inline ... > >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Jerome Athias >> Sent: Monday, December 16, 2013 11:13 AM >> To: Moriarty, Kathleen >> Cc: mile@ietf.org >> Subject: Re: [mile] Call for WG Reviews of RFC5070-bis >> >> Hi, >> >> after a quick review, here are some notes: >> >> Nice work! >> >> >> The attributes are sometimes missing into the figures. >> Examples: >> 3.11.1. >> and in many cases the (new) indicator-uid and indicator-set-id (3.12., 3= .15., >> 3.18.2., 3.19., 3.21.1., ...) > > Concur. Good catch. This will be fixed. > >> Sometimes the sentence "The X class has no attributes." is missing, i.e.= : 3.18. > > Concur. This will be fixed. > >> In 3.4, should >> "activity described the IODEF document" >> be >> "activity described in the IODEF document" >> ? > > Concur. Your text "activity described in the IODEF document" is the bett= er language to use > >> In 3.9.1 should >> "A means by which" >> be >> "A mean by which" (or meaning) >> ? > > Disagree. The "A means by which" is the standard language used by all of= the ext-* attribute write-ups. [JA] Sorry for my bad english > >> Is the word "STRING" missing in 3.22.1. for KeyName and Value? > > Concur. STRING is missing. > >> Is Value a full path? (if so, maybe it should be clarified) (I will revi= ew later the >> registry action default enumeration) > > Did you mean is KeyName a full path? I'm not sure what a full path is fo= r a registry value (i.e., the Value class). [JA] For a Hive, I could list the root folder, the Registry Path (as opposed to the File Path), keys, subkeys, values (without speaking about Cells) Here I think that it is the Registry Path > >> I would review the relationships between FileName and FileSize in 3.23. >> HashInformation Class > > Concur. This came up as an issue and is tracked in Ticket #20 (http://tr= ac.tools.ietf.org/wg/mile/trac/ticket/20). While identified, it is not yet= resolved. > >> (I would prefer to have ProtoCode and ProtoType to be ProtocolCode and >> ProtocolType) > > I see how this change would be cleaner. Balanced against the backward co= mpatibility of IODEF-v1, do you think it's worth the change? [JA] Probably not, backward compatibility is important > >> Maybe the virtual enumeration (3.17. System Class) could have also >> "unknown" > > Concur. "unknown" will be added. > >> I would double-check the description of duration in 3.18.1. > > Could you please be a little more specific? Is the text clumsy, not clear= in some way, or both? [JA] I should come back with more details > >> Could we discuss the possibility to extend the Application (and so >> OperatingSystem) Class?, with: >> name >> lang >> or/and an extension mechanism > > Do you have a specific proposal in mind, or is the list above data you'd = like to see represented? [JA] I should come back with more details > > How does this list match against the Platform class in draft-ietf-mile-sc= i-12? > >> Contact Class >> It should be difficult to use a RACI matrix (if needed) with the actual = roles >> enumeration > > Could you provide an example of where the current approach would break? [JA] Use case: use of a RACI matrix for notification/alert (who is Notified?), prioritization > >> Cardinality of 0..1 between Incident and AlternativeID (I would have to >> investigate further, but it could lead to some issues while consolidatin= g >> information for the same incident described by 2+ >> parties) > > Could you provide an example of where the current cardinality wouldn't be= adequate? While an Incident can only have 0..1 AlternativeIDs, an Alterna= tiveID has many IncidentIDs potentially from many organizations. [JA] I need to double-check my implementation > >> I like to use a ConfidenceReason when describing/exchanging a Confidence >> NB: It also helps for making automated choices at a parser level And als= o for >> automation, > > Can you clarify (or provide an example of) of your thinking about "Confid= enceReason"? Is there a need to document why a particular confidence value= was chosen? [JA] Examples: verified manually, or captured by 3 different sensors, or same result with 5 different tools > >> "asset" or "system" could be useful in the type enumeration of >> 3.9. Contact class > > Can you clarify (or provide an example of) what it would mean to have a C= ontact@type=3D"system"? Is it to convey contact information at the asset l= evel? If so, a System and Contact class can already be represented grouped= together with an EventData class. [JA] I need to double-check. Example scenario: Contact a virtual patch system to create and apply a WAF rule > >> >> I will try to review the XML part (is everything documented? >> EMailDetails (should maybe be EmailDetails), DomainData, >> HashSigDetails...) >> >> I will think about the user-agent >> (and maybe come with some thoughts about predictability next year) >> >> >> My 2c for now >> >> Best regards >> /JA > > We're very appreciative for this feedback Jerome! > > Roman > >> 2013/12/13 Moriarty, Kathleen : >> > Hello, >> > >> > RFC5070-bis will move to working group last call as scheduled in Janua= ry. >> Reviews prior to last call are extremely important to ensure the WG has >> addressed any major concerns in the draft. Please take the time to revi= ew >> the draft that will result in an IODEF v2.0. Reviews and discussion of = reviews >> should all be posted to mile@ietf.org. If something is more sensitive, = please >> send it to the editors and copy Brian and myself so that we see the acti= vity >> and interest. >> > >> > This will be the easiest time to get your requested changes in as we c= an >> allow for detailed discussions that may be necessary. Reviews will be >> encouraged during last call as well within a 2 week period in January. >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis >> > >> > Thank you! >> > Kathleen >> > >> > -----Original Message----- >> > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >> > Of Roman D. Danyliw >> > Sent: Saturday, October 19, 2013 9:11 PM >> > To: mile@ietf.org >> > Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-02.txt >> > >> > Hello! >> > >> > A new version of 5070bis has been published as -02. The following is = a list >> of the changes: >> > >> > ** (schema) Added Contact/ContactTitle to describe the title of the >> > contact (Issue #35) >> > ** (schema) Added System/AssetId to represent an opaque asset >> > identifier (Issue #33) >> > ** (schema) Added RelatedActivity/{ThreadActor, Campaign, Confidence, >> > Description, AdditionalData} (Issue #31 and partial #22) >> > ** (schema) Changed cardinality of Incident/RelatedActivity to be >> > 0..many in Incident (needed for Issue #31) >> > ** (schema) Added System@virtual to convey whether a device is >> > physical or virtual (Issue #16) >> > ** (schema) Added Incident@purpose=3D{watch} (Issue #17) >> > ** (schema) Added System@ownership to describe asset ownership >> (Issue >> > #34) >> > ** (schema) Various fixes to schema to make it valid >> > ** (editorial) Minor spelling fixes >> > >> > Roman >> > >> > -----Original Message----- >> > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf >> > Of internet-drafts@ietf.org >> > Sent: Saturday, October 19, 2013 9:09 PM >> > To: i-d-announce@ietf.org >> > Cc: mile@ietf.org >> > Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-02.txt >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Managed Incident Lightweight Exchang= e >> Working Group of the IETF. >> > >> > Title : The Incident Object Description Exchange For= mat v2 >> > Author(s) : Roman Danyliw >> > Paul Stoecker >> > Filename : draft-ietf-mile-rfc5070-bis-02.txt >> > Pages : 112 >> > Date : 2013-10-19 >> > >> > Abstract: >> > The Incident Object Description Exchange Format (IODEF) defines a >> > data representation that provides a framework for sharing informati= on >> > commonly exchanged by Computer Security Incident Response Teams >> > (CSIRTs) about computer security incidents. This document describe= s >> > the information model for the IODEF and provides an associated data >> > model specified with XML Schema. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-02 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-02 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ie= tf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > mile mailing list >> > mile@ietf.org >> > https://www.ietf.org/mailman/listinfo/mile >> > _______________________________________________ >> > mile mailing list >> > mile@ietf.org >> > https://www.ietf.org/mailman/listinfo/mile >> > >> > _______________________________________________ >> > mile mailing list >> > mile@ietf.org >> > https://www.ietf.org/mailman/listinfo/mile >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile From athiasjerome@gmail.com Sat Jan 4 03:08:09 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6C1ADE85 for ; Sat, 4 Jan 2014 03:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF3dbwEj55bB for ; Sat, 4 Jan 2014 03:08:07 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BA8891ADE84 for ; Sat, 4 Jan 2014 03:08:07 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id md12so16519728pbc.19 for ; Sat, 04 Jan 2014 03:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sGE8hUy5x+0IVNq0MpFgcLKOHT9nOrRlspH7LXy1CPI=; b=uoot7p18SspwIyk1qEridQ/Gpi81x5QCw4J0+wUFNj0uchdmCl+OU3rcRyl6hc7act pdXLyaOeCslkdDRxZzOcuo6AFFkY/B4G6aVNOXQtloFlINYkMHh+w4UguZrmkDGU+VGc jcmd53/SOrc2lIGOdjh0M6pltJPwbQRWhrXLZCUdhicum8kWv1ZT8s/lUNeOJ/DIMeDu Pzq24euW+WkYAepDADqJJis6H3FTk5MfHgNNJFCGEMVCliQeZX1mlC47mUmvM86RiZBb Czx2wfXV+YTcYPlGjnFN/IfEYVfKA14herYXyV7VwXPnfw09O20XQux6hRGql7kOFJmU j9BQ== MIME-Version: 1.0 X-Received: by 10.68.164.4 with SMTP id ym4mr57457494pbb.53.1388833680307; Sat, 04 Jan 2014 03:08:00 -0800 (PST) Received: by 10.68.195.104 with HTTP; Sat, 4 Jan 2014 03:08:00 -0800 (PST) Date: Sat, 4 Jan 2014 15:08:00 +0400 Message-ID: From: Jerome Athias To: "mile@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [mile] Cyber Security Research Paper XORCISM X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Jan 2014 11:08:09 -0000 Hi all, Happy Safe New Year. For your information, I shared the following document before describing my implementation. Any feedback welcome. https://github.com/athiasjerome/XORCISM/blob/master/Documentation/XORCISM_Overview_Concepts.docx Thank you Best regards From internet-drafts@ietf.org Tue Jan 7 18:40:38 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C1F1AE29C; Tue, 7 Jan 2014 18:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C_a-sjFOTTj; Tue, 7 Jan 2014 18:40:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6C11AE293; Tue, 7 Jan 2014 18:40:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140108024037.5767.98575.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 18:40:37 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-03.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-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, 08 Jan 2014 02:40:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-03.txt Pages : 113 Date : 2014-01-07 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rdd@cert.org Tue Jan 7 18:44:45 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC531AE29F for ; Tue, 7 Jan 2014 18:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RO43O47Af5o for ; Tue, 7 Jan 2014 18:44:43 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id A4E771AE2A0 for ; Tue, 7 Jan 2014 18:44:43 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s082iYLZ026635 for ; Tue, 7 Jan 2014 21:44:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389149074; bh=3UCAZLG/5T97EQ4ES2jz+bLI7A+NmvUkpdpuiCnVeaY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=PgHVUqFyqfOsVoGsZ5vXe2zgewT/Bq/3skboUMNcjLSEJMCtCU5+22X2wrjK/LjsJ oYyJRdY4TcW+amMl7X7Of9Y+XLrWCL1LFENructGFwR4CygLS3rGimD2+62rRkhjip VIuG7oqYgBQeTFkNtV6aK4fyjs7gVIgGJbKQgJL0= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s082iYTs009047 for ; Tue, 7 Jan 2014 21:44:34 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Tue, 7 Jan 2014 21:44:34 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-03.txt Thread-Index: AQHPDBsCPOPs6zm3wkKLyD9AxsaTHpp6HgGw Date: Wed, 8 Jan 2014 02:44:34 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C067CA@marathon> References: <20140108024037.5767.98575.idtracker@ietfa.amsl.com> In-Reply-To: <20140108024037.5767.98575.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-03.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2014 02:44:45 -0000 The -03 draft has the following changes: ** (editorial) Minor formatting changes to the schema ** (editorial) Addressed many issues from Jerome Athias's review (http://ww= w.ietf.org/mail-archive/web/mile/current/msg01252.html) =20 ** (editorial) Addressed many issues from Tim Freestone's review (http://ww= w.ietf.org/mail-archive/web/mile/current/msg01263.html) ** (schema) Added System@virtual=3D"unknown" enumerated value ** (schema) Added a "yes-no-unknown" type used by System@spoofed and @virtu= al ** (schema) Added Address@indicator-set-id to schema to be consistent with = the text ** (schema) Added DomainData@{indicator-uid, indicator-set-uid} (Issue #30) -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, January 07, 2014 9:41 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v= 2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-03.txt Pages : 113 Date : 2014-01-07 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Tue Jan 7 20:15:38 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34041AE2BA for ; Tue, 7 Jan 2014 20:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjIVl8k0ELJp for ; Tue, 7 Jan 2014 20:15:36 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90F321AE1FB for ; Tue, 7 Jan 2014 20:15:36 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s084FOBN022036; Tue, 7 Jan 2014 23:15:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389154524; bh=eskvxQD/9XFvNa0Zn1rdiT5Oam0f3USvXt1ohl6ZEjw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=ODYn00TTkjjrsAq6nyH8qzTBtG4zRthpG2vmwr/SX9lYCVtVmHXPWjamOUNYr1Q+D vLtL//piWG1SS3d7DAtiqtq4EwGvEQOWlnWkDLzMLZrG9Xu3bXTiDMMTymRdtlonGM Qu3o8RTp8lYvRixgaWwuUAy4p/+BwD9DpoaIV90k= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s084FPM7010109; Tue, 7 Jan 2014 23:15:25 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Tue, 7 Jan 2014 23:15:23 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Document reviews Thread-Index: Ac8IpBtrPHYWJK+YSRuUsmxBbiV/ZQDfACFAAAF16lY= Date: Wed, 8 Jan 2014 04:15:22 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C06D99@marathon> References: , <359EC4B99E040048A7131E0F4E113AFC54C06AD0@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C06AD0@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Document reviews X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2014 04:15:39 -0000 =0A= Hello Tim!=0A= =0A= Thank you for taking the time to review the 5070-bis draft. More detailed = comments are inline. Much of your feedback was incorporated into the newly= released -03 draft.=0A= =0A= > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Tim Freestone=0A= > Sent: Friday, January 03, 2014 11:57 AM=0A= > To: mile@ietf.org=0A= > Subject: [mile] Document reviews=0A= =0A= [snip]=0A= =0A= > draft-ietf-mile-rfc5070-bis-02:=0A= > Section 1.4: 5th bullet typo =96 complementary=0A= =0A= Fixed in -03.=0A= =0A= > Section 2.6: Should this be =93A hexadecimal byte is encoded=85=94?=0A= =0A= I would disagree with this recommendation. The octet is what's being encod= ed as a hexadecimal string. Others?=0A= =0A= > Section 3.2: Incident Class. The Indicator-set-id attribute does not app= ear in the diagram=0A= =0A= Fixed in -03.=0A= =0A= > Section 3.8: For the Additional Data Class which allows any data to be tr= ansferred =96 may want some mechanism to prevent the contents of the data f= rom being executed automatically?=0A= =0A= Are you envisioning that a binary or script could be embedded into the XML = document and the parser at the receiving end extracts and executes it? If = so, we could put a language into the Security Considerations section saying= not to do that.=0A= =0A= > Section 3.11.1: Reference Class. The diagram does not show the 4 attribut= es for this Class=0A= > Section 3.12: Assessment Class. The diagram only shows 2 of the 4 attribu= tes for this class=0A= > Section 3.13.1: History Item Class. The diagram does not show the indicat= or-set-id or indicator-uid attributes=0A= > Section 3.14: EventData Class. The diagram does not show the indicator-se= t-id attribute=0A= > Section 3.14.2: typo =93related=94 -> =93relate=94=0A= > Section 3.15: Expectation Class. The diagram does not show the indicator-= uid or indicator-set-id attributes=0A= > Section 3.18.1: Counter Class. The diagram shows 5 attributes, but the wo= rds indicate there are 3 attributes and then describe 4 (leaving out =93mea= ning=94)=0A= > Section 3.18.2: Address Class. The diagram does not show the indicator-ui= d attribute=0A= > Section 3.19: Service Class =96 typo =93a a=94=0A= > Section 3.19: Service Class. The diagram does not show the indicator-uid = or indicator-set-id attributes=0A= > Section 3.21.1: RecordData Class. The diagram does not show the indicator= -uid or indicator-set-id attributes=0A= > Section 3.21.2: RecordPattern Class. The text indicates 4 attributes, but= describes 6=0A= > Section 7: Examples have the IODEF-Document Version as 1.0 not 2.0=0A= =0A= All fixed in the -03 draft.=0A= =0A= > Section 7: Is it worth including an example with some of the new fields f= or this version?=0A= =0A= Definitely. I've added Issue #38 (http://trac.tools.ietf.org/wg/mile/trac/= ticket/38) to track this suggestion.=0A= =0A= > Section 8: The IODEF Schema indicates that Service Class has been extende= d by email address, email subject and x-mailer, but these are not described= in the text (section 3.19)=0A= > Section 8: The Service Class schema shows elements for Email Subject and = X-Mailer as well as EmailDetails which is the same set of elements?=0A= =0A= You're right. This omission is a still a gap that needs to be addressed. = We're tracking it in Issue #15 (http://trac.tools.ietf.org/wg/mile/trac/tic= ket/15).=0A= =0A= > Section 12.2: Reference [18] could be RFC 6545 and Reference [19] could b= e RFC 6546 now?=0A= =0A= Fixed in the -03 draft.=0A= =0A= > General: The extensibility in the data model increases the risk of data l= eakage or =0A= > inbound malicious data through the extensions mechanism. Is it possible t= hat over =0A= > time, profiles defining what can and can=92t be sent will be defined for = use between =0A= > CSIRTS to ensure that only the expected data is transferred?=0A= =0A= Yes, I'd think it would be likely that such profiles would be implemented.= =0A= =0A= Again, thank you so much for your careful review.=0A= =0A= Roman= From tim.freestone@deep-secure.com Wed Jan 8 00:51:49 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5CD1AE048 for ; Wed, 8 Jan 2014 00:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcFo_hUjBrxU for ; Wed, 8 Jan 2014 00:51:47 -0800 (PST) Received: from mx3.a4mail.net (mx3.a4mail.net [94.185.132.7]) by ietfa.amsl.com (Postfix) with ESMTP id 284571AE02F for ; Wed, 8 Jan 2014 00:51:46 -0800 (PST) X-ASG-Debug-ID: 1389171096-06180b6b25225dd0001-Q78J5t Received: from A4HUB03.a4mail.net ([172.20.0.128]) by mx3.a4mail.net with ESMTP id yAM2sWJcHfDhURL9 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Wed, 08 Jan 2014 08:51:36 +0000 (GMT) X-Barracuda-Envelope-From: tim.freestone@deep-secure.com X-ASG-Whitelist: Client Received: from A4MBX02.a4mail.net ([fe80::b479:3944:9cdc:3dc9]) by A4HUB03.a4mail.net ([fe80::c81c:c092:d733:52c3%11]) with mapi id 14.02.0247.003; Wed, 8 Jan 2014 08:51:36 +0000 From: Tim Freestone X-Barracuda-Apparent-Source-IP: fe80::b479:3944:9cdc:3dc9 To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: Document reviews X-ASG-Orig-Subj: RE: Document reviews Thread-Index: Ac8IpBtrPHYWJK+YSRuUsmxBbiV/ZQDfACFAAAF16lYACinbAA== Date: Wed, 8 Jan 2014 08:51:35 +0000 Message-ID: References: , <359EC4B99E040048A7131E0F4E113AFC54C06AD0@marathon> <359EC4B99E040048A7131E0F4E113AFC54C06D99@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C06D99@marathon> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.188.163.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.20.0.128] X-Barracuda-Start-Time: 1389171096 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.a4mail.net:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at a4mail.net X-Barracuda-BRTS-Status: 1 Subject: Re: [mile] Document reviews X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2014 08:51:49 -0000 Thanks Roman.=20 >> Section 3.8: For the Additional Data Class which allows any data to be t= ransferred - may want some mechanism to prevent the contents of the data fr= om being executed automatically? >Are you envisioning that a binary or script could be embedded into the XML= document and the parser at the receiving end extracts and executes it? If= so, we could put a language into the >Security Considerations section sayi= ng not to do that. Yes that was what I was thinking. Regards, Tim -----Original Message----- From: Roman D. Danyliw [mailto:rdd@cert.org]=20 Sent: 08 January 2014 04:15 To: mile@ietf.org Cc: Tim Freestone Subject: RE: Document reviews Hello Tim! Thank you for taking the time to review the 5070-bis draft. More detailed = comments are inline. Much of your feedback was incorporated into the newly= released -03 draft. > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Tim Freestone > Sent: Friday, January 03, 2014 11:57 AM > To: mile@ietf.org > Subject: [mile] Document reviews [snip] > draft-ietf-mile-rfc5070-bis-02: > Section 1.4: 5th bullet typo - complementary Fixed in -03. > Section 2.6: Should this be "A hexadecimal byte is encoded..."? I would disagree with this recommendation. The octet is what's being encod= ed as a hexadecimal string. Others? > Section 3.2: Incident Class. The Indicator-set-id attribute does not=20 > appear in the diagram Fixed in -03. > Section 3.8: For the Additional Data Class which allows any data to be tr= ansferred - may want some mechanism to prevent the contents of the data fro= m being executed automatically? Are you envisioning that a binary or script could be embedded into the XML = document and the parser at the receiving end extracts and executes it? If = so, we could put a language into the Security Considerations section saying= not to do that. > Section 3.11.1: Reference Class. The diagram does not show the 4=20 > attributes for this Class Section 3.12: Assessment Class. The diagram=20 > only shows 2 of the 4 attributes for this class Section 3.13.1:=20 > History Item Class. The diagram does not show the indicator-set-id or=20 > indicator-uid attributes Section 3.14: EventData Class. The diagram does = not show the indicator-set-id attribute Section 3.14.2: typo "related" -> = "relate" > Section 3.15: Expectation Class. The diagram does not show the=20 > indicator-uid or indicator-set-id attributes Section 3.18.1: Counter=20 > Class. The diagram shows 5 attributes, but the words indicate there=20 > are 3 attributes and then describe 4 (leaving out "meaning") Section 3.18= .2: Address Class. The diagram does not show the indicator-uid attribute Se= ction 3.19: Service Class - typo "a a" > Section 3.19: Service Class. The diagram does not show the=20 > indicator-uid or indicator-set-id attributes Section 3.21.1:=20 > RecordData Class. The diagram does not show the indicator-uid or=20 > indicator-set-id attributes Section 3.21.2: RecordPattern Class. The=20 > text indicates 4 attributes, but describes 6 Section 7: Examples have=20 > the IODEF-Document Version as 1.0 not 2.0 All fixed in the -03 draft. > Section 7: Is it worth including an example with some of the new fields f= or this version? Definitely. I've added Issue #38 (http://trac.tools.ietf.org/wg/mile/trac/= ticket/38) to track this suggestion. > Section 8: The IODEF Schema indicates that Service Class has been=20 > extended by email address, email subject and x-mailer, but these are not = described in the text (section 3.19) Section 8: The Service Class schema sh= ows elements for Email Subject and X-Mailer as well as EmailDetails which i= s the same set of elements? You're right. This omission is a still a gap that needs to be addressed. = We're tracking it in Issue #15 (http://trac.tools.ietf.org/wg/mile/trac/tic= ket/15). > Section 12.2: Reference [18] could be RFC 6545 and Reference [19] could b= e RFC 6546 now? Fixed in the -03 draft. > General: The extensibility in the data model increases the risk of=20 > data leakage or inbound malicious data through the extensions=20 > mechanism. Is it possible that over time, profiles defining what can=20 > and can't be sent will be defined for use between CSIRTS to ensure that o= nly the expected data is transferred? Yes, I'd think it would be likely that such profiles would be implemented. Again, thank you so much for your careful review. Roman From rdd@cert.org Thu Jan 9 11:38:41 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8FF1AE542 for ; Thu, 9 Jan 2014 11:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPGwtv8pBwRz for ; Thu, 9 Jan 2014 11:38:39 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id F03D71AE539 for ; Thu, 9 Jan 2014 11:38:36 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s09JcGxY017319 for ; Thu, 9 Jan 2014 14:38:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389296306; bh=kNoIm1bKgu6I75OySpivzNBh/pmQvrMf0o5016BTr1I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=IHEk5pY4PMYuCnQYPk9S/9EJYAL1Jde/8ElGZazuML0g1js9qcPDb+D7FR/ctb5/E 1xZQrArpKZ0hWDxuKfI6sK4LXg7xDrfcJkCwIdSUblAYKKNyfEKElvu7H0u5MJ2EPy zHlKfn+uyi3Kk3OX5tZIbb195wLCLTk25T5t0e0c= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s09JcG38015798 for ; Thu, 9 Jan 2014 14:38:16 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 14:38:16 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Consistency in @indicator-uid/set-id attributes Thread-Index: Ac8Ncbl6MftTED3GTomys4zoctibpw== Date: Thu, 9 Jan 2014 19:38:15 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C0B160@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Consistency in @indicator-uid/set-id attributes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 19:38:41 -0000 Hello! I reviewed the -03 draft to examine where @indicator-uid and @indicator-set= -id attributes are present in the document. Each instances of these attrib= utes should be found documented in three places: in the text describing the= class, in the diagram depicting the class, and in the schema. =20 The following classes have @indicator-uid and @indicator-set-id attributes = fully documented: HistoryItem, Expectation, Reference, Assessment, RecordDa= ta, HashInformation, and Service. A few inconsistencies were found in the review. Editorial mistakes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ** Address =3D @indicator-set-id not found in text but in the diagram and s= chema ** DomainData =3D @indicator-uid and set-id in schema, but not in text or d= iagram (expected and tracked in Issue #15) Inconsistencies that pose questions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D ** EmailDetails =3D has @indicator-uid but no set-id in the schema. There = is not text or diagram due to Issue #15. I recommend we add @indicator-set= -id. I believe this was an editorial mistake. Agreed? ** Incident =3D has @indicator-set-id but not uid. Was excluding @indicato= r-uid intentionally? ** EventData =3D has @indicator-set-id but not uid. Was excluding @indicat= or-uid intentionally? ** RegistryKeyModified =3D has @indicator-uid and set-id in the schema by n= ot in the text. See Key for recommendation. ** Key =3D has @indicator-uid and set-id in the text and diagram but not in= the schema. These attributes should be in either RegistryKeyModified or K= ey, but not both. I would recommend that these attributes be in Key. Roman From rdd@cert.org Thu Jan 9 13:37:53 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413C31ADF7E for ; Thu, 9 Jan 2014 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoJy2EvrE1s5 for ; Thu, 9 Jan 2014 13:37:50 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67B5E1A1521 for ; Thu, 9 Jan 2014 13:37:50 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s09LbcTB012474; Thu, 9 Jan 2014 16:37:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389303458; bh=4CuxZx80ti03EyhN6FR0oLMk1y2Q78iSdLTrx2ucg/Q=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=KqYJIzCZtz6XL/RV2V0tiSjGOYeeS5qcyDW8a39SorcCPfpp41XqBtr2otiLtJ2ae B+KFwRnKikMAOD1SSA4sL05E8rzfwEJWWNkfXDguwfclgTnseqLeXs1ZLh+2FCnbc1 KlrlE8/uHcbF8d9wgb3dgEud/zSJPJI9rOoXzFrU= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s09LbdE5006818; Thu, 9 Jan 2014 16:37:40 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 16:37:37 -0500 From: "Roman D. Danyliw" To: Tim Freestone , "mile@ietf.org" Thread-Topic: Document reviews Thread-Index: Ac8IpBtrPHYWJK+YSRuUsmxBbiV/ZQDfACFAAAF16lYACinbAABNDi5A Date: Thu, 9 Jan 2014 21:37:36 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C0BC0E@marathon> References: , <359EC4B99E040048A7131E0F4E113AFC54C06AD0@marathon> <359EC4B99E040048A7131E0F4E113AFC54C06D99@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Document reviews X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 21:37:53 -0000 Hi Tim, I'll add the following text to Section 9 (Security Considerations). Executable content could be embedded into the IODEF document directly or th= rough an extension. The IODEF parser should handle this content with care = to prevent unintentional automated execution. Roman > -----Original Message----- > From: Tim Freestone [mailto:tim.freestone@deep-secure.com] > Sent: Wednesday, January 08, 2014 3:52 AM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: Document reviews >=20 > Thanks Roman. >=20 > >> Section 3.8: For the Additional Data Class which allows any data to be > transferred - may want some mechanism to prevent the contents of the data > from being executed automatically? > >Are you envisioning that a binary or script could be embedded into the X= ML > document and the parser at the receiving end extracts and executes it? I= f so, > we could put a language into the >Security Considerations section saying = not > to do that. >=20 > Yes that was what I was thinking. >=20 > Regards, > Tim >=20 >=20 > -----Original Message----- > From: Roman D. Danyliw [mailto:rdd@cert.org] > Sent: 08 January 2014 04:15 > To: mile@ietf.org > Cc: Tim Freestone > Subject: RE: Document reviews >=20 >=20 > Hello Tim! >=20 > Thank you for taking the time to review the 5070-bis draft. More detaile= d > comments are inline. Much of your feedback was incorporated into the > newly released -03 draft. >=20 > > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Tim Freestone > > Sent: Friday, January 03, 2014 11:57 AM > > To: mile@ietf.org > > Subject: [mile] Document reviews >=20 > [snip] >=20 > > draft-ietf-mile-rfc5070-bis-02: > > Section 1.4: 5th bullet typo - complementary >=20 > Fixed in -03. >=20 > > Section 2.6: Should this be "A hexadecimal byte is encoded..."? >=20 > I would disagree with this recommendation. The octet is what's being > encoded as a hexadecimal string. Others? >=20 > > Section 3.2: Incident Class. The Indicator-set-id attribute does not > > appear in the diagram >=20 > Fixed in -03. >=20 > > Section 3.8: For the Additional Data Class which allows any data to be > transferred - may want some mechanism to prevent the contents of the data > from being executed automatically? >=20 > Are you envisioning that a binary or script could be embedded into the XM= L > document and the parser at the receiving end extracts and executes it? I= f so, > we could put a language into the Security Considerations section saying n= ot > to do that. >=20 > > Section 3.11.1: Reference Class. The diagram does not show the 4 > > attributes for this Class Section 3.12: Assessment Class. The diagram > > only shows 2 of the 4 attributes for this class Section 3.13.1: > > History Item Class. The diagram does not show the indicator-set-id or > > indicator-uid attributes Section 3.14: EventData Class. The diagram doe= s not > show the indicator-set-id attribute Section 3.14.2: typo "related" -> "r= elate" > > Section 3.15: Expectation Class. The diagram does not show the > > indicator-uid or indicator-set-id attributes Section 3.18.1: Counter > > Class. The diagram shows 5 attributes, but the words indicate there > > are 3 attributes and then describe 4 (leaving out "meaning") Section 3.= 18.2: > Address Class. The diagram does not show the indicator-uid attribute Sect= ion > 3.19: Service Class - typo "a a" > > Section 3.19: Service Class. The diagram does not show the > > indicator-uid or indicator-set-id attributes Section 3.21.1: > > RecordData Class. The diagram does not show the indicator-uid or > > indicator-set-id attributes Section 3.21.2: RecordPattern Class. The > > text indicates 4 attributes, but describes 6 Section 7: Examples have > > the IODEF-Document Version as 1.0 not 2.0 >=20 > All fixed in the -03 draft. >=20 > > Section 7: Is it worth including an example with some of the new fields= for > this version? >=20 > Definitely. I've added Issue #38 > (http://trac.tools.ietf.org/wg/mile/trac/ticket/38) to track this suggest= ion. >=20 > > Section 8: The IODEF Schema indicates that Service Class has been > > extended by email address, email subject and x-mailer, but these are no= t > described in the text (section 3.19) Section 8: The Service Class schema > shows elements for Email Subject and X-Mailer as well as EmailDetails whi= ch > is the same set of elements? >=20 > You're right. This omission is a still a gap that needs to be addressed.= We're > tracking it in Issue #15 (http://trac.tools.ietf.org/wg/mile/trac/ticket/= 15). >=20 > > Section 12.2: Reference [18] could be RFC 6545 and Reference [19] could= be > RFC 6546 now? >=20 > Fixed in the -03 draft. >=20 > > General: The extensibility in the data model increases the risk of > > data leakage or inbound malicious data through the extensions > > mechanism. Is it possible that over time, profiles defining what can > > and can't be sent will be defined for use between CSIRTS to ensure that > only the expected data is transferred? >=20 > Yes, I'd think it would be likely that such profiles would be implemented= . >=20 > Again, thank you so much for your careful review. >=20 > Roman From rdd@cert.org Thu Jan 9 13:59:17 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C431AE108 for ; Thu, 9 Jan 2014 13:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdyxjC9eTcwR for ; Thu, 9 Jan 2014 13:59:13 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 068871AE171 for ; Thu, 9 Jan 2014 13:59:11 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s09LwxEA021000; Thu, 9 Jan 2014 16:59:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389304740; bh=iwpw2po3p0ZQkvwE8masq4SDCu6zQ1uYCTpD7U7JLpM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=bgcnXEQnzUFhVWzBX1lN5LgRZs4u1tvsqNmA1DgzNsy86q93nES2OiF1qjbbxY26B UZB+PHf6JyaDJT0NCbNo6YN405JO1cFpGqzOaBTT37lZP5/8NDzwiBpxhiZLz0+q3O VeeW3+vHsFxzlBwsuISXWE8GxZ/ajj1JKrUsTbto= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s09Lwxq3028551; Thu, 9 Jan 2014 16:58:59 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 9 Jan 2014 16:58:59 -0500 From: "Roman D. Danyliw" To: "Harrington, Christopher" , "Stoecker, Paul" Thread-Topic: [mile] Describing the time window during which an indicator should be used Thread-Index: AQHO/c57pAnDrzzu2ESFoBQTQ/2vJZpiPtQAgAAFdwCAGshVUA== Date: Thu, 9 Jan 2014 21:58:58 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C0BCBC@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54BF92D2@marathon>, <8E856A31-290B-4A4A-ABC5-DC7177E41B89@rsa.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C0BCBCmarathon_" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 21:59:18 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C0BCBCmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Chris: Thanks for the background! To date, the message traffic suggests interest in per-indicator annotation = of validity. That would suggest something as follows: Or The follow-up discuss asked if organizations really every stop looking for = indicators they have. One answer was yes. How do we want to handle that? Ideas might include: (1) provide only an @indicator-stime and @indicator-etime, and these are th= e best guess of the reporter of how long to make it valid. The recipient c= an decide how and if to honor these. (2) provide another attribute that would suggest an aging policy that the r= ecipient can choose to honor. What would we those aging policies? Roman From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] Sent: Monday, December 23, 2013 10:46 AM To: Stoecker, Paul Cc: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator sh= ould be used Yes we do stop looking. A good example is when NBC.com got hacked a few mon= ths ago. We watched for people hitting it while the URL was malicious. Once= it was cleaned up we stopped watching for it since it was a somewhat popul= ar URL that would fire all the time and bury us in false positives. Indicator aging is an area that nobody has a good handle one. Each organiza= tion seems to have their own way of doing things with aging, if they do any= thing at all. Some commercial threat intel providers use a decrementing cou= nter based on the last time the indicator was seen. At EMC we make the agin= g calculation based on time since last seen, attribution (if known), kill c= hain stage, confidence in the source and other factors. It's not automated= at this point. We can't keep all indicators forever. At some point the watch lists and blo= ck lists on your Proxy, firewall, etc get too large and the devices start h= aving issues. We ran into this at EMC and had to switch from Proxy blocks f= or domains to DNS RPZ with a sinkhole web servers. There were too many doma= ins in the proxy block list. We have tens of thousands. There are indicator= s that we consider "persistent". These are indicators that we always want t= o be alerted about. Generally these are advanced threat / APT and have eith= er been seen in activity involving EMC or they belong to threat actor group= s that we have seen at EMC. Thanks, --Chris From: Stoecker, Paul Sent: Monday, December 23, 2013 10:26 AM To: Harrington, Christopher Cc: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Describing the time window during which an indicator sh= ould be used I have a question...Do we really stop looking for IOCs whose time has expir= ed? Like a malicious URL whose time has expired...do you stop looking for = that URL? Let's say that Paul the malware dude got a hold of the IODEF doc= ument...I shutdown my web server and after the time expired I turned it bac= k on? Just wondering how IOC aging is actually handled? Sent from my iPhone On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" > wrote: Hello, Answers inline below. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, December 20, 2013 4:26 PM To: mile@ietf.org Subject: [mile] Describing the time window during which an indicator should= be used Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking = the need to convey the valid time during which to apply an indicator. I wa= nted to solicit from the community the degree of flexibility desired. For = the purposes of this discussion an indicator is defined as a class that has= an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, Yes, a malicious URL would be valid only as long as it is live. ** Could it be at the EventData level (and the time window cascades to all = indicators that are children)? Example 2:, ... = ... many domain indicators ... Example 3: ... 2013/12/01 12:00:00 ... ... many domain indicators ... Yes, you could have multiple malware delivery URLs that are all on the same= domain. If the Domain is specified at EvenData level then when it is no lo= nger valid the children would no longer be valid. I hope I explained that r= ight :) I am not sure how it would differ between Example 2 and 3. ** Could it be at the Incident level? Example 4: ... 2013/12/01 12:00:00 ... many domain indicators ... If there was only one Indicator in an incident it could be. In practical te= rms this is very unlikely. Per indicator time information would provide the most flexibility but would= require duplication of the same information. A time window for indicator validity specified at the Incident level would = not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would= require nested EventData instances to convey different time period. Also,= some indicators are only in the Incident class so this approach would be i= nsufficient. Perhaps a hybrid approach where this timing information is in= the EventData and IncidentData classes could be possible. Personally I think the safest approach is validity per Indicator. Validity= for parent / child would be rare and validity per Incident even rarer. One question, how do we represent "still valid"? If I have an indicator tha= t is valid when I send the message how do I know what that time represents?= If I put "12/20/2013 13:00" as the time can you tell if I mean that it wa= s still valid when I sent the message at that time or that its validity per= iod ended at that time. Those are very different scenarios and critically i= mportant for searching / responding to indicator hits. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_359EC4B99E040048A7131E0F4E113AFC54C0BCBCmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

Chris: Thanks for the = background!

 

To date, the message t= raffic suggests interest in per-indicator annotation of validity.  Tha= t would suggest something as follows:

 

<Assessment indicator-uid=3D”foo-12345̶= 1; indicator-stime=3D”2013/12/01 12:00:00”>

Or <= /p>

<Assessment indicator-uid=3D”foo-12345̶= 1; indicator-stime=3D”2013/12/01 12:00:00” indicator-etime=3D&#= 8221;2013/12/01 13:00:00”-->

 

The follow-up discuss asked if organizations really = every stop looking for indicators they have.  One answer was yes.=

 

How do we want to handle that?  Ideas might inc= lude:

 

(1) provide only an @indicator-stime and @indicator-= etime, and these are the best guess of the reporter of how long to make it = valid.  The recipient can decide how and if to honor these.=

 

(2) provide another attribute that would suggest an = aging policy that the recipient can choose to honor.  What would we th= ose aging policies?

 

Roman

 

 

From: Harringt= on, Christopher [mailto:Christopher.Harrington@emc.com]
Sent: Monday, December 23, 2013 10:46 AM
To: Stoecker, Paul
Cc: Roman D. Danyliw; mile@ietf.org
Subject: RE: [mile] Describing the time window during which an indic= ator should be used

 

Yes we do stop looking= . A good example is when NBC.com got hacked a few months ago. We watched fo= r people hitting it while the URL was malicious. Once it was cleaned up we = stopped watching for it since it was a somewhat popular  URL that would fire all the time and bury us in f= alse positives.

 

Indicator aging is an = area that nobody has a good handle one. Each organization seems to have the= ir own way of doing things with aging, if they do anything at all. Some com= mercial threat intel providers use a decrementing counter based on the last time the indicator was seen. At EMC= we make the aging calculation based on time since last seen, attribution (= if known), kill chain stage, confidence in the source  and other facto= rs. It’s not automated at this point.

 

We can’t keep al= l indicators forever. At some point the watch lists and block lists on your= Proxy, firewall, etc get too large and the devices start having issues. We= ran into this at EMC and had to switch from Proxy blocks for domains to DNS RPZ with a sinkhole web servers. There wer= e too many domains in the proxy block list. We have tens of thousands. Ther= e are indicators that we consider “persistent”. These are indic= ators that we always want to be alerted about. Generally these are advanced threat / APT and have either been seen in act= ivity involving EMC or they belong to threat actor groups that we have seen= at EMC.

 

Thanks,

 

--Chris

 

From: Stoecker= , Paul
Sent: Monday, December 23, 2013 10:26 AM
To: Harrington, Christopher
Cc: Roman D. Danyliw; mile@ietf.org=
Subject: Re: [mile] Describing the time window during which an indic= ator should be used

 

I have a question...Do we really stop looking for IO= Cs whose time has expired?  Like a malicious URL whose time has expire= d...do you stop looking for that URL?  Let's say that Paul the malware= dude got a hold of the IODEF document...I shutdown my web server and after the time expired I turned it back on?

 

Just wondering how IOC aging is actually handled?
Sent from my iPhone


On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" <Christopher.Harrington@emc.com<= /a>> wrote:

Hello,

 

Answers inline below. =

 

Thanks,

 

--Chris

 

Christopher Harrington=
Consulting Security Engineer
GSO - Critical Incident Response Center
EMC
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, December 20, 2013 4:26 PM
To: mile@ietf.org
Subject: [mile] Describing the time window during which an indicator= should be used

 

Hello!

 

Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28= ) is tracking the need to convey the valid time during which to apply an in= dicator.  I wanted to solicit from the community the degree of flexibility desired.  For the purposes of thi= s discussion an indicator is defined as a class that has an @indicator-uid = attribute.

 

** Does this flexibility need to exist on a per indi= cator basis?

Example 1, <Assessment indicator-uid=3D”foo= -12345” indicator-valid-stime=3D”2013/12/01 12:00:00”>=

Yes, a malicious URL w= ould be valid only as long as it is live.

 

** Could it be at the EventData level (and the time = window cascades to all indicators that are children)?

Example 2:, <EventData indicator-stime=3D”2= 013/12/01 12:00:00”> … <Flow> … many domain indi= cators </Flow> … </EventData>

Example 3: <EventData>  … <Indic= atorStartTime>2013/12/01 12:00:00</IndicatorStartTime> … <= ;Flow> … many domain indicators </Flow> … </EventDa= ta>

Yes, you could have mu= ltiple malware delivery URLs that are all on the same domain. If the Domain= is specified at EvenData level then when it is no longer valid the childre= n would no longer be valid. I hope I explained that right J  I am not sure how it wou= ld differ between Example 2 and 3.

 

** Could it be at the Incident level?

Example 4: <Incident>  … <Indica= torStartTime>2013/12/01 12:00:00</IndicatorStartTime> … many= domain indicators </Flow> … </Incident>

If there was only one = Indicator in an incident it could be. In practical terms this is very unlik= ely.

 

Per indicator time information would provide the mos= t flexibility but would require duplication of the same information.

 

A time window for indicator validity specified at th= e Incident level would not allow for multiple time windows per indicator.

 

A time window for indicator validity specified in th= e EventData class would require nested EventData instances to convey differ= ent time period.  Also, some indicators are only in the Incident class= so this approach would be insufficient.  Perhaps a hybrid approach where this timing information is in the EventDat= a and IncidentData classes could be possible.

 

Personally I think the= safest approach is validity per Indicator.  Validity for parent / chi= ld would be rare and validity per Incident even rarer.

 

One question, how do w= e represent “still valid”? If I have an indicator that is valid= when I send the message how do I know what that time represents?  If = I put “12/20/2013 13:00” as the time can you tell if I mean that it was still valid when I sent the message at that time or tha= t its validity period ended at that time. Those are very different scenario= s and critically important for searching / responding to indicator hits.

 

Roman

 

____________________________________= ___________
mile mailing list
mile@ietf.org
https://www.ietf.org= /mailman/listinfo/mile

--_000_359EC4B99E040048A7131E0F4E113AFC54C0BCBCmarathon_-- From rdd@cert.org Sat Jan 11 10:14:20 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4066E1AE074 for ; Sat, 11 Jan 2014 10:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o54gV-_RxXQA for ; Sat, 11 Jan 2014 10:14:17 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC141ACCE2 for ; Sat, 11 Jan 2014 10:14:17 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0BIE6hW027288 for ; Sat, 11 Jan 2014 13:14:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389464046; bh=beDhuF16xPpF28xnIwoXRC3hc8+9a5N3FSdUD3qZ+QM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To:Cc; b=j31buTQ1nL2ZE+pweAPUkVQHpByu6lZ0Gn7YUHrTlOi74v9qHU7/v/Vl+3Y1+VZxu u/EUq5WgXtfit90AA5lenC9O9T/ypEdSSm5DQ7vzYfLsnHD0c7fLg73qe5bfkATN+0 TYOLEUsXbw9n14eDp2BaHOnrSZD5vPLBDOzsEk0Y= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0BIE8F3027114 for ; Sat, 11 Jan 2014 13:14:08 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Sat, 11 Jan 2014 13:14:05 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] [Issue #2] Better citation to RecordPattern@type=regex Thread-Index: Ac6MFpmi/zYLHB2jSzu7hqtC/ihxxwAUqKWAIKLXlTA= Date: Sat, 11 Jan 2014 18:14:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C0DED6@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C55C8F@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C0DED6marathon_" MIME-Version: 1.0 Subject: Re: [mile] [Issue #2] Better citation to RecordPattern@type=regex X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Jan 2014 18:14:20 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C0DED6marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! I'm repeating this call to implementers. Would there be interest in redefi= ning the citation for regex? If so how. We have one suggestion to date for PCRE. Roman From: Jerome Athias [mailto:athiasjerome@gmail.com] Sent: Monday, July 29, 2013 6:38 AM To: Roman D. Danyliw Cc: mile@ietf.org Subject: Re: [mile] [Issue #2] Better citation to RecordPattern@type=3Drege= x Hi, I would say PCRE Best regards 2013/7/29 Roman D. Danyliw > Per, http://trac.tools.ietf.org/wg/mile/trac/ticket/2 RecordPattern@type=3D"regex" is currently cited as Appendix F of [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation , October 2004, . Third hand feedback received from an implementer is that the W3C definition= of regular expressions isn't sufficiently expressive. For background, a c= omparison of features differences across regex implementations is summarize= d at http://www.regular-expressions.info/refflavors.html. Do others implementers agree that the XML Schema citation should not be use= d? If so, which definition would you like to use instead? POSIX ERE (1003= .2)? PERL 5? PCRE? Python? Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_359EC4B99E040048A7131E0F4E113AFC54C0DED6marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!<= /p>

 <= /p>

I’m repeating this = call to implementers.  Would there be interest in redefining the citat= ion for regex?  If so how.

 <= /p>

We have one suggestion to= date for PCRE.

 <= /p>

Roman

 <= /p>

From: Jerome A= thias [mailto:athiasjerome@gmail.com]
Sent: Monday, July 29, 2013 6:38 AM
To: Roman D. Danyliw
Cc: mile@ietf.org
Subject: Re: [mile] [Issue #2] Better citation to RecordPattern@type= =3Dregex

 

Hi,

 

I would say PCRE

 

Best regards

 

2013/7/29 Roman D. Danyliw <rdd@cert.org>

Per, http://trac.tools.ietf.org/wg/mile/trac/ticket/2

RecordPattern@type=3D"regex" is currently cited as Appendix F of<= br>
   [3]   World Wide Web Consortium, "XML Schema Part 2:= Datatypes Second
         Edition", W3C Recommendation , Octob= er 2004,
         <http://www.w3.org/TR/xmlschema-2/>.

Third hand feedback received from an implementer is that the W3C definition= of regular expressions isn't sufficiently expressive.  For background= , a comparison of features differences across regex implementations is summ= arized at http://www.regular-expressions.info/refflavors.html.

Do others implementers agree that the XML Schema citation should not be use= d?  If so, which definition would you like to use instead?  POSIX= ERE (1003.2)? PERL 5? PCRE? Python?

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

 

--_000_359EC4B99E040048A7131E0F4E113AFC54C0DED6marathon_-- From Christopher.Harrington@emc.com Sat Jan 11 12:05:15 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C900B1AE0F3 for ; Sat, 11 Jan 2014 12:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbwTGz64GZaj for ; Sat, 11 Jan 2014 12:05:13 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 707FE1AE0B6 for ; Sat, 11 Jan 2014 12:05:13 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0BK50dk030901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jan 2014 15:05:00 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0BK50dk030901 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389470700; bh=yuQE3w+DffkRVSQi+h0gbC6sosY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Ttd+hT1FNXc/Qu+uyDgQTro6IYJdV+iTTcGAQJB3eGZtKh7t8/yE01wl6Hx4LpBBQ 3kbFTE2Qj0dYeki7qKvPHtdp9bLOWF4lj8lMraIwRYAx7iOto7SkoWrBuRGlFvNWVA UtAKIRR/v3Pg8eHf5C+b517/4rYelAmks9pxJY4g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0BK50dk030901 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd03.lss.emc.com (RSA Interceptor); Sat, 11 Jan 2014 15:04:53 -0500 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0BK4qc4008359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jan 2014 15:04:53 -0500 Received: from mx36a.corp.emc.com ([169.254.1.232]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Sat, 11 Jan 2014 15:04:52 -0500 From: "Harrington, Christopher" To: "Roman D. Danyliw" Date: Sat, 11 Jan 2014 15:04:51 -0500 Thread-Topic: [mile] [Issue #2] Better citation to RecordPattern@type=regex Thread-Index: Ac8PCGMslRt3FoAIQgC73YkZhk/ZYw== Message-ID: <3964C7C2-E9E9-4BCE-8680-019F4BC200DB@emc.com> References: <359EC4B99E040048A7131E0F4E113AFC13C55C8F@marathon> <359EC4B99E040048A7131E0F4E113AFC54C0DED6@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C0DED6@marathon> 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_3964C7C2E9E94BCE8680019F4BC200DBemccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" Subject: Re: [mile] [Issue #2] Better citation to RecordPattern@type=regex X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Jan 2014 20:05:16 -0000 --_000_3964C7C2E9E94BCE8680019F4BC200DBemccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx0aG91Z2ggSSBhbSBwYXJ0aWFsIHRvIFB5dGhvbiBJIHRoaW5rIFBDUkUgaXMgcHJvYmFibHkg bW9yZSB3aWRlbHkgdXNlZC4NCg0KT24gSmFuIDExLCAyMDE0LCBhdCAxOjE0IFBNLCAiUm9tYW4g RC4gRGFueWxpdyIgPHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNlcnQub3JnPj4gd3JvdGU6DQoN CkhlbGxvIQ0KDQpJ4oCZbSByZXBlYXRpbmcgdGhpcyBjYWxsIHRvIGltcGxlbWVudGVycy4gIFdv dWxkIHRoZXJlIGJlIGludGVyZXN0IGluIHJlZGVmaW5pbmcgdGhlIGNpdGF0aW9uIGZvciByZWdl eD8gIElmIHNvIGhvdy4NCg0KV2UgaGF2ZSBvbmUgc3VnZ2VzdGlvbiB0byBkYXRlIGZvciBQQ1JF Lg0KDQpSb21hbg0KDQpGcm9tOiBKZXJvbWUgQXRoaWFzIFttYWlsdG86YXRoaWFzamVyb21lQGdt YWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSAyOSwgMjAxMyA2OjM4IEFNDQpUbzogUm9tYW4g RC4gRGFueWxpdw0KQ2M6IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW21pbGVdIFtJc3N1ZSAjMl0gQmV0dGVyIGNpdGF0aW9uIHRvIFJlY29yZFBhdHRl cm5AdHlwZT1yZWdleA0KDQpIaSwNCg0KSSB3b3VsZCBzYXkgUENSRQ0KDQpCZXN0IHJlZ2FyZHMN Cg0KMjAxMy83LzI5IFJvbWFuIEQuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNl cnQub3JnPj4NClBlciwgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvbWlsZS90cmFjL3Rp Y2tldC8yDQoNClJlY29yZFBhdHRlcm5AdHlwZT0icmVnZXgiIGlzIGN1cnJlbnRseSBjaXRlZCBh cyBBcHBlbmRpeCBGIG9mDQoNCiAgIFszXSAgIFdvcmxkIFdpZGUgV2ViIENvbnNvcnRpdW0sICJY TUwgU2NoZW1hIFBhcnQgMjogRGF0YXR5cGVzIFNlY29uZA0KICAgICAgICAgRWRpdGlvbiIsIFcz QyBSZWNvbW1lbmRhdGlvbiAsIE9jdG9iZXIgMjAwNCwNCiAgICAgICAgIDxodHRwOi8vd3d3Lncz Lm9yZy9UUi94bWxzY2hlbWEtMi8+Lg0KDQpUaGlyZCBoYW5kIGZlZWRiYWNrIHJlY2VpdmVkIGZy b20gYW4gaW1wbGVtZW50ZXIgaXMgdGhhdCB0aGUgVzNDIGRlZmluaXRpb24gb2YgcmVndWxhciBl eHByZXNzaW9ucyBpc24ndCBzdWZmaWNpZW50bHkgZXhwcmVzc2l2ZS4gIEZvciBiYWNrZ3JvdW5k LCBhIGNvbXBhcmlzb24gb2YgZmVhdHVyZXMgZGlmZmVyZW5jZXMgYWNyb3NzIHJlZ2V4IGltcGxl bWVudGF0aW9ucyBpcyBzdW1tYXJpemVkIGF0IGh0dHA6Ly93d3cucmVndWxhci1leHByZXNzaW9u cy5pbmZvL3JlZmZsYXZvcnMuaHRtbC4NCg0KRG8gb3RoZXJzIGltcGxlbWVudGVycyBhZ3JlZSB0 aGF0IHRoZSBYTUwgU2NoZW1hIGNpdGF0aW9uIHNob3VsZCBub3QgYmUgdXNlZD8gIElmIHNvLCB3 aGljaCBkZWZpbml0aW9uIHdvdWxkIHlvdSBsaWtlIHRvIHVzZSBpbnN0ZWFkPyAgUE9TSVggRVJF ICgxMDAzLjIpPyBQRVJMIDU/IFBDUkU/IFB5dGhvbj8NCg0KUm9tYW4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptaWxlIG1haWxpbmcgbGlzdA0KbWls ZUBpZXRmLm9yZzxtYWlsdG86bWlsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWlsZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbWlsZSBtYWlsaW5nIGxpc3QNCm1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1p bGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGUN Cg== --_000_3964C7C2E9E94BCE8680019F4BC200DBemccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+QWx0aG91 Z2ggSSBhbSBwYXJ0aWFsIHRvIFB5dGhvbiBJIHRoaW5rIFBDUkUgaXMgcHJvYmFibHkgbW9yZSB3 aWRlbHkgdXNlZC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj5PbiBKYW4gMTEsIDIwMTQsIGF0IDE6MTQg UE0sICJSb21hbiBELiBEYW55bGl3IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyI+ cmRkQGNlcnQub3JnPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48ZGl2Pg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9V2luZG93cy0xMjUyIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCg0KDQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SeKAmW0gcmVwZWF0aW5nIHRoaXMgY2FsbCB0byBpbXBsZW1lbnRlcnMuJm5ic3A7IFdvdWxk IHRoZXJlIGJlIGludGVyZXN0IGluIHJlZGVmaW5pbmcgdGhlIGNpdGF0aW9uIGZvciByZWdleD8m bmJzcDsgSWYgc28gaG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBvbmUgc3VnZ2VzdGlvbiB0byBkYXRl IGZvciBQQ1JFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9tYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gSmVyb21lIEF0aGlhcyBbPGEgaHJlZj0ibWFpbHRvOmF0aGlhc2plcm9t ZUBnbWFpbC5jb20iPm1haWx0bzphdGhpYXNqZXJvbWVAZ21haWwuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjksIDIwMTMgNjozOCBBTTxicj4NCjxiPlRvOjwvYj4g Um9tYW4gRC4gRGFueWxpdzxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0 Zi5vcmciPm1pbGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWlsZV0g W0lzc3VlICMyXSBCZXR0ZXIgY2l0YXRpb24gdG8gUmVjb3JkUGF0dGVybkB0eXBlPXJlZ2V4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBzYXkg UENSRTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDEzLzcvMjkgUm9tYW4g RC4gRGFueWxpdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5QZXIsIDxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL21pbGUvdHJh Yy90aWNrZXQvMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv d2cvbWlsZS90cmFjL3RpY2tldC8yPC9hPjxicj4NCjxicj4NClJlY29yZFBhdHRlcm5AdHlwZT0i cmVnZXgiIGlzIGN1cnJlbnRseSBjaXRlZCBhcyBBcHBlbmRpeCBGIG9mPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO1szXSAmbmJzcDsgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSwgIlhNTCBTY2hl bWEgUGFydCAyOiBEYXRhdHlwZXMgU2Vjb25kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0VkaXRpb24iLCBXM0MgUmVjb21tZW5kYXRpb24gLCBPY3RvYmVyIDIwMDQsPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwOi8v d3d3LnczLm9yZy9UUi94bWxzY2hlbWEtMi8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lncz Lm9yZy9UUi94bWxzY2hlbWEtMi88L2E+Jmd0Oy48YnI+DQo8YnI+DQpUaGlyZCBoYW5kIGZlZWRi YWNrIHJlY2VpdmVkIGZyb20gYW4gaW1wbGVtZW50ZXIgaXMgdGhhdCB0aGUgVzNDIGRlZmluaXRp b24gb2YgcmVndWxhciBleHByZXNzaW9ucyBpc24ndCBzdWZmaWNpZW50bHkgZXhwcmVzc2l2ZS4g Jm5ic3A7Rm9yIGJhY2tncm91bmQsIGEgY29tcGFyaXNvbiBvZiBmZWF0dXJlcyBkaWZmZXJlbmNl cyBhY3Jvc3MgcmVnZXggaW1wbGVtZW50YXRpb25zIGlzIHN1bW1hcml6ZWQgYXQNCjxhIGhyZWY9 Imh0dHA6Ly93d3cucmVndWxhci1leHByZXNzaW9ucy5pbmZvL3JlZmZsYXZvcnMuaHRtbCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cucmVndWxhci1leHByZXNzaW9ucy5pbmZvL3JlZmZsYXZv cnMuaHRtbDwvYT4uPGJyPg0KPGJyPg0KRG8gb3RoZXJzIGltcGxlbWVudGVycyBhZ3JlZSB0aGF0 IHRoZSBYTUwgU2NoZW1hIGNpdGF0aW9uIHNob3VsZCBub3QgYmUgdXNlZD8gJm5ic3A7SWYgc28s IHdoaWNoIGRlZmluaXRpb24gd291bGQgeW91IGxpa2UgdG8gdXNlIGluc3RlYWQ/ICZuYnNwO1BP U0lYIEVSRSAoMTAwMy4yKT8gUEVSTCA1PyBQQ1JFPyBQeXRob24/PGJyPg0KPGJyPg0KUm9tYW48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cm1pbGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1p bGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9taWxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9taWxlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bh bj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48 YnI+PHNwYW4+bWlsZSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0 bzptaWxlQGlldGYub3JnIj5taWxlQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pbGU8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Js b2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_3964C7C2E9E94BCE8680019F4BC200DBemccom_-- From rdd@cert.org Sun Jan 12 18:16:11 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045531AD6C1 for ; Sun, 12 Jan 2014 18:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZw1atzv7YUx for ; Sun, 12 Jan 2014 18:16:07 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF091ACC7D for ; Sun, 12 Jan 2014 18:16:07 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0D2Ftr6014233 for ; Sun, 12 Jan 2014 21:15:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389579355; bh=XFtoV+bSEk/UiRrsuEZkjfbY7DZzlog57I4v/IjY9Uc=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:In-Reply-To: References; b=k/DJgQE1Iwu7FCmdh5gzcR8F2RZj6xTg9St2lGEsyGcwWTJRk3sKk72sGrj0zieqY XFWBd9OghJc6yStgaydlH5NLBnREgiBEz/RHmcdvuUqjOsy+Mw+djneJud2JYxaVtj 7y0YF9R65DbHvEAt6sjwS55hRo53zG/XjTNE/tMY= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0D2Ftng011046 for ; Sun, 12 Jan 2014 21:15:55 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Sun, 12 Jan 2014 21:15:55 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Two places for email details Thread-Index: Ac8QA0MMALQvGI9kSSGXL/bjcNeKQQ== Date: Mon, 13 Jan 2014 02:15:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C0EE16@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Two places for email details X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 02:16:11 -0000 Hello! As the schema is currently defined in -03 of 5070bis, the details of an ema= il message can be represented in two places in the Service class. ** A From address can be in Service/EmailInfo/Email and Service/Email ** A Subject can be in Service/EmailInfo/EmailSubject and Service/EmailSubj= ect ** A X-Mailer can be in Service/EmailInfo/X-Mailer For example, the following snippet would be valid: ... user0234@example.com user92034234@example.com ... There is no text describing these classes so I'm assuming they represent th= e same information. Can someone explain the use case for supporting such f= lexibility. When do I Service/{Email,EmailSubject,X-Mailer} instead of Ser= vice/EmailInfo/{Email,EmailSubject,X-Mailer}? It would seem to me having one set of classes might be better -- perhaps ju= st Service/EmailInfo. Roman From Christopher.Harrington@emc.com Mon Jan 13 05:18:30 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C16A1AE16B for ; Mon, 13 Jan 2014 05:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.359 X-Spam-Level: *** X-Spam-Status: No, score=3.359 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBnCAzPG5qBy for ; Mon, 13 Jan 2014 05:18:25 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 266C11AE169 for ; Mon, 13 Jan 2014 05:18:24 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0DDI6lJ009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jan 2014 08:18:07 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s0DDI6lJ009869 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389619087; bh=GTe++PW/mMV0+R5ljchF6+pjJ70=; h=From:To:CC:Date:Subject:Message-ID:Content-Type:MIME-Version; b=mLA/pfGBGePnk22Umclg/XQ6ZVK//lzebA6bDaoKI9eJR/R7FR61MCW9r5qiJA0tW vAuSy+GtxmuECUKs+5xf/SLTULcVwAFnl0JR+jQg8yXWR9NVvJdLR8gOD9ZbtwKe59 qCsFAo48qrtbZ6hhYPH9HEzgHX4wJxjXRsSIBNm0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s0DDI6lJ009869 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 13 Jan 2014 05:17:59 -0800 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0DDHr3m016083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 08:17:59 -0500 Received: from mx36a.corp.emc.com ([169.254.1.232]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Mon, 13 Jan 2014 08:17:58 -0500 From: "Harrington, Christopher" To: "Roman D. Danyliw" , "Stoecker, Paul" Date: Mon, 13 Jan 2014 08:17:57 -0500 Thread-Topic: [mile] Describing the time window during which an indicator should be used Thread-Index: Ac8QYd5ePk2lBkToRcSzhFdZzeEY9Q== 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/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0117_01CF1037.F71E2F70" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:18:30 -0000 ------=_NextPart_000_0117_01CF1037.F71E2F70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0118_01CF1037.F71E2F70" ------=_NextPart_001_0118_01CF1037.F71E2F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Roman, >From what I have seen the aging is usually up to the recipient. I would say that option #1 would be better. For purposes of deciding to stop looking for an indicator there is another data point that is used far more frequently, Last Seen time. For the majority of indicators we use the time it was last "seen". For us the "seen" means that either we have seen it being used or we have intel from a 3rd party or open source that it is still in use. The only time we use the stime-etime paradigm is when there is an infection (delivery stage of the Kill Chain) that was valid but later cleaned up. Nbc.com was compromised last year for about 4 hours then cleaned up. In that case we would use stime-etime. There are indicators that we call persistent. These are indicators that we will never stop looking for. These could be indicators that are used exclusively by a specific threat actor (like a domain registered by an actor) or something that we used in a previous incident at our organization, like RSA breech related indicators. A construct to flag an indicator as persistent would be helpful as this is information is something we routinely share. Thanks, --Chris From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 09, 2014 4:59 PM To: Harrington, Christopher; Stoecker, Paul Cc: mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator should be used Hello! Chris: Thanks for the background! To date, the message traffic suggests interest in per-indicator annotation of validity. That would suggest something as follows: Or The follow-up discuss asked if organizations really every stop looking for indicators they have. One answer was yes. How do we want to handle that? Ideas might include: (1) provide only an @indicator-stime and @indicator-etime, and these are the best guess of the reporter of how long to make it valid. The recipient can decide how and if to honor these. (2) provide another attribute that would suggest an aging policy that the recipient can choose to honor. What would we those aging policies? Roman From: Harrington, Christopher [ mailto:Christopher.Harrington@emc.com] Sent: Monday, December 23, 2013 10:46 AM To: Stoecker, Paul Cc: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator should be used Yes we do stop looking. A good example is when NBC.com got hacked a few months ago. We watched for people hitting it while the URL was malicious. Once it was cleaned up we stopped watching for it since it was a somewhat popular URL that would fire all the time and bury us in false positives. Indicator aging is an area that nobody has a good handle one. Each organization seems to have their own way of doing things with aging, if they do anything at all. Some commercial threat intel providers use a decrementing counter based on the last time the indicator was seen. At EMC we make the aging calculation based on time since last seen, attribution (if known), kill chain stage, confidence in the source and other factors. It's not automated at this point. We can't keep all indicators forever. At some point the watch lists and block lists on your Proxy, firewall, etc get too large and the devices start having issues. We ran into this at EMC and had to switch from Proxy blocks for domains to DNS RPZ with a sinkhole web servers. There were too many domains in the proxy block list. We have tens of thousands. There are indicators that we consider "persistent". These are indicators that we always want to be alerted about. Generally these are advanced threat / APT and have either been seen in activity involving EMC or they belong to threat actor groups that we have seen at EMC. Thanks, --Chris From: Stoecker, Paul Sent: Monday, December 23, 2013 10:26 AM To: Harrington, Christopher Cc: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Describing the time window during which an indicator should be used I have a question...Do we really stop looking for IOCs whose time has expired? Like a malicious URL whose time has expired...do you stop looking for that URL? Let's say that Paul the malware dude got a hold of the IODEF document...I shutdown my web server and after the time expired I turned it back on? Just wondering how IOC aging is actually handled? Sent from my iPhone On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" wrote: Hello, Answers inline below. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile [ mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, December 20, 2013 4:26 PM To: mile@ietf.org Subject: [mile] Describing the time window during which an indicator should be used Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey the valid time during which to apply an indicator. I wanted to solicit from the community the degree of flexibility desired. For the purposes of this discussion an indicator is defined as a class that has an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, Yes, a malicious URL would be valid only as long as it is live. ** Could it be at the EventData level (and the time window cascades to all indicators that are children)? Example 2:, . . many domain indicators . Example 3: . 2013/12/01 12:00:00 . . many domain indicators . Yes, you could have multiple malware delivery URLs that are all on the same domain. If the Domain is specified at EvenData level then when it is no longer valid the children would no longer be valid. I hope I explained that right J I am not sure how it would differ between Example 2 and 3. ** Could it be at the Incident level? Example 4: . 2013/12/01 12:00:00 . many domain indicators . If there was only one Indicator in an incident it could be. In practical terms this is very unlikely. Per indicator time information would provide the most flexibility but would require duplication of the same information. A time window for indicator validity specified at the Incident level would not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would require nested EventData instances to convey different time period. Also, some indicators are only in the Incident class so this approach would be insufficient. Perhaps a hybrid approach where this timing information is in the EventData and IncidentData classes could be possible. Personally I think the safest approach is validity per Indicator. Validity for parent / child would be rare and validity per Incident even rarer. One question, how do we represent "still valid"? If I have an indicator that is valid when I send the message how do I know what that time represents? If I put "12/20/2013 13:00" as the time can you tell if I mean that it was still valid when I sent the message at that time or that its validity period ended at that time. Those are very different scenarios and critically important for searching / responding to indicator hits. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile ------=_NextPart_001_0118_01CF1037.F71E2F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roman,

 

From what I have seen = the aging is usually up to the recipient. I would say that option #1 = would be better.

 

For purposes of deciding = to stop looking for an indicator there is another data point that is = used far more frequently, Last Seen time. For the majority of indicators = we use the time it was last “seen”. For us the = “seen” means that either we have seen it being used or we = have intel from a 3rd party or open source that it is still = in use. The only time we use the stime-etime paradigm is when there is = an infection (delivery stage of the Kill Chain) that was valid but later = cleaned up. Nbc.com was compromised last year for about 4 hours then = cleaned up. In that case we would use stime-etime. There are indicators = that we call persistent. These are indicators that we will never stop = looking for. These could be indicators that are used exclusively by a = specific threat actor (like a domain registered by an actor) or = something that we used in a previous incident at our organization, like = RSA breech related indicators. A construct to flag an indicator as = persistent would be helpful as this is information is something we = routinely share.

 

Thanks,

 

--Chris

 

From:= = Roman D. Danyliw [mailto:rdd@cert.org]
Sent: = Thursday, January 09, 2014 4:59 PM
To: Harrington, = Christopher; Stoecker, Paul
Cc: mile@ietf.org
Subject: RE: = [mile] Describing the time window during which an indicator should be = used

 

Hello!

 

Chris: Thanks for the = background!

 

To date, the message = traffic suggests interest in per-indicator annotation of validity.  = That would suggest something as follows:

 

<Assessment indicator-uid=3D”foo-12345” = indicator-stime=3D”2013/12/01 12:00:00”>

Or

<Assessment indicator-uid=3D”foo-12345” = indicator-stime=3D”2013/12/01 12:00:00” = indicator-etime=3D”2013/12/01 = 13:00:00”-->

 

The = follow-up discuss asked if organizations really every stop looking for = indicators they have.  One answer was yes.

 

How do we = want to handle that?  Ideas might include:

 

(1) provide = only an @indicator-stime and @indicator-etime, and these are the best = guess of the reporter of how long to make it valid.  The recipient = can decide how and if to honor these.

 

(2) provide = another attribute that would suggest an aging policy that the recipient = can choose to honor.  What would we those aging = policies?

 

Roman

 

 

From:= = Harrington, Christopher [mailto:Chris= topher.Harrington@emc.com] =
Sent: Monday, December 23, 2013 10:46 AM
To: = Stoecker, Paul
Cc: Roman D. Danyliw; mile@ietf.or= g
Subje= ct: RE: [mile] Describing the time window during which an indicator = should be used

 

Yes we do stop looking. A good example is when = NBC.com got hacked a few months ago. We watched for people hitting it = while the URL was malicious. Once it was cleaned up we stopped watching = for it since it was a somewhat popular  URL that would fire all the = time and bury us in false positives.

 

Indicator aging is an = area that nobody has a good handle one. Each organization seems to have = their own way of doing things with aging, if they do anything at all. = Some commercial threat intel providers use a decrementing counter based = on the last time the indicator was seen. At EMC we make the aging = calculation based on time since last seen, attribution (if known), kill = chain stage, confidence in the source  and other factors. = It’s not automated at this point.

 

We can’t keep all = indicators forever. At some point the watch lists and block lists on = your Proxy, firewall, etc get too large and the devices start having = issues. We ran into this at EMC and had to switch from Proxy blocks for = domains to DNS RPZ with a sinkhole web servers. There were too many = domains in the proxy block list. We have tens of thousands. There are = indicators that we consider “persistent”. These are = indicators that we always want to be alerted about. Generally these are = advanced threat / APT and have either been seen in activity involving = EMC or they belong to threat actor groups that we have seen at EMC. =

 

Thanks,

 

--Chris

 

From:= = Stoecker, Paul
Sent: Monday, December 23, 2013 10:26 = AM
To: Harrington, Christopher
Cc: Roman D. Danyliw; = mile@ietf.or= g
Subje= ct: Re: [mile] Describing the time window during which an indicator = should be used

 

I have = a question...Do we really stop looking for IOCs whose time has expired? =  Like a malicious URL whose time has expired...do you stop looking = for that URL?  Let's say that Paul the malware dude got a hold of = the IODEF document...I shutdown my web server and after the time expired = I turned it back on?

 

Just wondering how IOC aging is actually = handled?

Sent from my iPhone


On Dec 20, 2013, at = 4:57 PM, "Harrington, Christopher" <Christopher.Harrington@emc= .com> wrote:

Hello,

 

Answers inline below. =

 

Thanks,

 

--Chris

 

Christopher = Harrington
Consulting Security Engineer
GSO - Critical Incident = Response Center
EMC
174 Middlesex Turnpike
Bedford, MA = 01730
781-515-5862 (work)
603-583-1585 = (cell)

 

From:= = mile [mailto:mile-= bounces@ietf.org] On = Behalf Of Roman D. Danyliw
Sent: Friday, December 20, 2013 = 4:26 PM
To: mile@ietf.or= g
Subje= ct: [mile] Describing the time window during which an indicator = should be used

 

Hello!

 

Ticket #28 = (http://trac.to= ols.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey = the valid time during which to apply an indicator.  I wanted to = solicit from the community the degree of flexibility desired.  For = the purposes of this discussion an indicator is defined as a class that = has an @indicator-uid attribute.

 

** Does this = flexibility need to exist on a per indicator basis?

Example 1, <Assessment = indicator-uid=3D”foo-12345” = indicator-valid-stime=3D”2013/12/01 = 12:00:00”>

Yes, a malicious URL would be valid only as long = as it is live.

 

** Could it = be at the EventData level (and the time window cascades to all = indicators that are children)?

Example 2:, <EventData = indicator-stime=3D”2013/12/01 12:00:00”> … = <Flow> … many domain indicators </Flow> … = </EventData>

Example 3: = <EventData>  … <IndicatorStartTime>2013/12/01 = 12:00:00</IndicatorStartTime> … <Flow> … many = domain indicators </Flow> … = </EventData>

Yes, you could have multiple malware delivery = URLs that are all on the same domain. If the Domain is specified at = EvenData level then when it is no longer valid the children would no = longer be valid. I hope I explained that right J  I am not sure how it would differ between = Example 2 and 3.

 

** Could it be at the Incident level?

Example 4: <Incident>  … = <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> = … many domain indicators </Flow> … = </Incident>

If there was only one Indicator in an incident = it could be. In practical terms this is very unlikely. =

 

Per indicator time information would provide the most = flexibility but would require duplication of the same = information.

 

A time window for indicator validity specified at the = Incident level would not allow for multiple time windows per = indicator.

 

A time window for indicator validity specified in the = EventData class would require nested EventData instances to convey = different time period.  Also, some indicators are only in the = Incident class so this approach would be insufficient.  Perhaps a = hybrid approach where this timing information is in the EventData and = IncidentData classes could be possible.

 

Personally I think the = safest approach is validity per Indicator.  Validity for parent / = child would be rare and validity per Incident even rarer. =

 

One question, how do we = represent “still valid”? If I have an indicator that is = valid when I send the message how do I know what that time = represents?  If I put “12/20/2013 13:00” as the time = can you tell if I mean that it was still valid when I sent the message = at that time or that its validity period ended at that time. Those are = very different scenarios and critically important for searching / = responding to indicator hits.

 

Roman

 

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

------=_NextPart_001_0118_01CF1037.F71E2F70-- ------=_NextPart_000_0117_01CF1037.F71E2F70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY2DCCA2Ew ggJJoAMCAQICEAoBAQEAAAJ8AAAACgAAAAIwDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDEwMjIyMjAz OTIzWhcNMjYwMjIyMjAzOTIzWjA6MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQL ExRSU0EgU2VjdXJpdHkgMjA0OCBWMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALeP VXHSgN17aXmn8BhQMjxiZ/YKlQfd5hvzntnSQVRrrZ98vhnN+0arQWgeGOpVyC+ReIko+ycpYP/f j4w7yUmbtaSUzgHqPrVje38m/RndwCG9hNEtT0bDTtzYNzk7KK/LnRrqK68hpcEjIri4G1oTh1eD 0fAg5+hPI0KwAKV9ienpYXOUmHEmvC1q4PdN8PG2KjgxgQ0p4QDBUQ9MUvgEWqp9ctO4hyq7YxAD KrOhTw1aXka3PQ71dOyZn/k9JIGIpt1gVOiVNj3GCZOaoxKAAFWZGUe90KV8w7r7H/f1D/isubX0 N5gTGN6FW7cMgjuHb5U5WDDabgFoFyLMwAsCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUB8NRMKSq6UWuNST6/yQsM9CxnYwwHQYDVR0OBBYEFAfD UTCkqulFrjUk+v8kLDPQsZ2MMA0GCSqGSIb3DQEBBQUAA4IBAQBfPoZ2brg1PE42HB55mL/91RIR eVIO7jGJvN1/+dHGFSHoigFUDTr7VLnWY9SxqpZNokJN1FMfixDef2W+YBMncYikc+OEY9GkVeFQ k+YbDnnQZ7xGyL8/Fw2V5saQad7ntC/elX3QEj89Pn9NPxRo9RFQ1cH0kKUIHTFg/2CMI1QKr/6h bsXReipoeM8eggogtB+t5YWyamh1Tq0lN5SFvr2h1Oq3DEs8negSAPBfrA3hrHBjc/d/eZ8yJUJ0 BYAov73BJJZYFbEXIemJS9sHiGf0Fa1wPi9NhTvCt9v+mGgjieF0D970xYRjKRvMywfJAKSp18Ii T2fXd+wgBWHeMIIEzDCCA7SgAwIBAgIQfwkpTisxI69dQcDR3n6N2TANBgkqhkiG9w0BAQUFADA6 MRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgSW5jMR0wGwYDVQQLExRSU0EgU2VjdXJpdHkgMjA0OCBW MzAeFw0xMTAzMDMyMDUyMTVaFw0xOTA0MDExNDQ1MzlaMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaLCcEh7lhj dqYo6ryZ8oHK4kJRmQuxfwMa/3PE1Vd4U7U5x15UuSX+qd78hnEdR6yGGxhmY8U2SDG31u+yJD9o OpXFQm6/A4xzItwfcs6SD3Gt6nI/Oa6M0M/7MjPqSc1aUUm2NFiyb6DjotYLDzeAVCqF+4V/Dgc2 QdO1FZeFUCcb5lMqkVAr+O3uAEZEmtD3Cr06YavA38fxeWCiPoheUuWuAQcvOdEnSzJFm6GM8yBJ l9J1cAibE6c4DCl+eHj4M+O/ON2fFVb/lQdS4xO7cSZ9fKGCI7kWr0/7ssSjPsIIGpg0hLRZ35aZ fCK1fFLi9VKvIcTYTrA8Gf9bIGsCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk +v8kLDPQsZ2MMBIGA1UdEwEB/wQIMAYBAf8CAQMwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3 dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0 YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwHQYDVR0OBBYEFHMbOEsly1qOvQLs310p9hB0 DtiYMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUGATB2MC4GCCsGAQUFBwIBFiJodHRwOi8vY2Eu cnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNBIFNlY3VyaXR5IExM QzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTAOBgNVHQ8BAf8EBAMCAYYwDQYJ KoZIhvcNAQEFBQADggEBAHGIVCAjCZ+z2vRElolRsLsz4L/js0Zm019rr/+eFks5VnSf5T0HJj7Z tzjtna/+O5b01L8L6Fz64Yui+h/cnxvDwQrhzajbiMiN/JFH+kNOUJ9LcInBkmu45d98h+EQw3Yz XwfnHYaXLArfgeY3CP8AYi0pxXEXf0bH8Prl+P0n4SOUqxh6J0GIz/haW1+usvMscB7lCpJ2loo9 +TmRn3WQrokgr1ILm/3apel6ydpkoFUxEoP5a1806Z7SD9KljN+Vc9o521VkMtnzLlDEkn05by/p QNdlidY7eV7xcpCvuI6qFzyfHdI3G0/Vao0L0os6lEwb5PSa1IysLlHT0uUwggT+MIID5qADAgEC AhBiTV1a7zr4E+gcgJ4lG6TBMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJVUzEWMBQGA1UE CBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5 IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEcMBoGA1UEAxMTUlNB IENvcnBvcmF0ZSBDQSB2MjAeFw0xMTAzMTAyMjQwMDRaFw0xOTAyMjgyMTU2MzNaMIGeMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UE ChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlv bjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDNEVsNPFZOP83bMzCpUDGnf/5IDIQvVRhDHkyrkbv5X1ih4xdTsSdzTDrj LUxIzC7nJswCv+jBaWWm1YoqzBXqQl2/Hl6T5Bt3HBT302GSYamtKcCWve25DoJav+dJd9U/XkCq SSNN7DNVXkJrKC7Zq7OS6/O308pZNkCRJJfMRrodgSx1NoQYZJCfufTOshslVSVhj3Ar274qmuf8 iqM0RR5OMpm7t2dtHzvYJPHR3+HwfQ+s64YBC7NBrBLOYMeq8tzkPKzyITXhwopgbM6gbp+Z8qX5 /lo4Y3OEm7ED51iDqdruRoRnfTQGKdZJT7IYGLH+x0roRKmYKP/2HRNpAgMBAAGjggE7MIIBNzAP BgNVHRMECDAGAQH/AgECMIGRBgNVHSAEgYkwgYYwgYMGCSqGSIb3DQUHAjB2MC4GCCsGAQUFBwIB FiJodHRwOi8vY2EucnNhc2VjdXJpdHkuY29tL0NQUy5odG1sMEQGCCsGAQUFBwICMDgwFxYQUlNB IFNlY3VyaXR5IExMQzADAgEBGh1DUFMgSW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTBABgNVHR8E OTA3MDWgM6Axhi9odHRwOi8vY3JsLnJzYXNlY3VyaXR5LmNvbS9SU0FDb3Jwb3JhdGVDQXYyLmNy bDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFBQw62v19Em1aFJ1ptu9rlvIrH1MMB8GA1UdIwQY MBaAFHMbOEsly1qOvQLs310p9hB0DtiYMA0GCSqGSIb3DQEBBQUAA4IBAQCPepLT4buLa9p5VwF1 OW2YUwliCqxecs0CxRGJVR4cwvOuMeXxutP+m51n3vzseGkM0d1fmA9JTz8X+5LFdRD12Iw124oj 79QA7NKhO/xoPgbo0QxgnvHS15o94BPvFiZE6QGUjkHs9/hDvU+eIx7OG+Kzxt47vZZef+fJF0+s ZgEDIMXXPXAtJW3xg/JhPrl4z0L7gmjgO+KxV0cyxaDrk6SEW5zZCqAcLehnW7MH8vvlzMsQ6pVr f1g8xMCJonyxow9AwXGyQ0z1866qbJ8t+nQC/sGx3msJVHQg1JyjOWF4PMm8DdeUt+qUrSFRLY4J MroY51gM90nnhtijtleCMIIFxTCCBK2gAwIBAgIRAIQ3oNuoPqBS3YhDUJp3rlQwDQYJKoZIhvcN AQEFBQAwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdC ZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJp dHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MjAeFw0x MzA2MTkxMTAwNThaFw0xNTA2MTkxMTAwNThaMIHvMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYK CZImiZPyLGQBGRYDZW1jMRgwFgYDVQQKEw9FTUMgQ29ycG9yYXRpb24xETAPBgNVBAsTCEFtZXJp Y2FzMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMQ8wDQYDVQQFEwYxMjI3NjUxFzAVBgoJ kiaJk/IsZAEBEwdoYXJyaWM4MR8wHQYDVQQDExZDaHJpc3RvcGhlciBIYXJyaW5ndG9uMS0wKwYJ KoZIhvcNAQkBFh5jaHJpc3RvcGhlci5oYXJyaW5ndG9uQGVtYy5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIBKcM4e/EfofFwfGGTTzP9Q5h+TbnMfUHaXkYleI6YteMOkHmp+f3 6y9+TztCDzpypIBDHJ61t9jP3Wl1ktHiRvXUyjvciaJuVGNSlhqik/9i94jfWeb0Tw5bjFWgnFyW f4nk51Zu2NvMfCVA3Uu6PS7pf1vWkkDs37XIX3zHeATa189aQRHS8enAItBbC8aE38b+H4Umy2Nm IQQFtXbkB3pzzBImFujgbZdx8PrjRmBaIfXNXIaLDkTc8VmF1MkxSk2Gwt4BeLE5xGMWtTqXv3j8 D7YTk416tj/vIpe+t/cSa7eiydNP74no4GMSRhY4Z6iaX+A+kCTshLze/4w5AgMBAAGjggGpMIIB pTAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwKQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMEoG A1UdEQRDMEGBHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbaAfBgorBgEEAYI3FAIDoBEM D2hhcnJpYzhAZW1jLmNvbTAOBgNVHQ8BAf8EBAMCB4AwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC5yc2FzZWN1cml0eS5jb206ODAvUlNBQ2xhc3MyUGVyc29uYWxDQXYyLmNybDAdBgNVHQ4E FgQU8PcZ+AZ1SlXp4EE3P4yjbslfqpIwDQYJKoZIhvcNAQEFBQADggEBAL9Or82VcAEw1PGuPbBD QzDy1rwrjFwoN9nMuNaMdqtgNlhhiHldOOlccTiXJVMykbmY3brFqTnvwCA9vMnJJnRqHPfZp5ic waWVpn8H50FHx0o4ftycPEl0oH9RPOJgDc/t/jHpLpLB94kHxyxQ4vJundplDbR2LYsUZa03GBMo hvfMuiKw0CeBr1R7x4WIiseWQ4KB71zmW3AbsYI9y0q9DlHIgtNmfOj84tY9f2QC3ndMkmSGvmMm X7DWCMnlHPN+0FiRkMqOeoYFwRaTeRM1i2Sm91E83TNRmb7f6xzIc4mLsHKP2Jui5nA/V8NWvTqI YhCkCB0cZkc91ehe4n4wggXUMIIEvKADAgECAhAzkGSOsA6fNPJDSK+W/N5kMA0GCSqGSIb3DQEB BQUAMIGeMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVk Zm9yZDEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5 IE9yZ2FuaXphdGlvbjEjMCEGA1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjIwHhcNMTMw NjE5MTUwNDQ1WhcNMTUwNjE5MTUwNDIxWjCB8zETMBEGCgmSJomT8ixkARkWA2NvbTETMBEGCgmS JomT8ixkARkWA2VtYzEYMBYGA1UEChMPRU1DIENvcnBvcmF0aW9uMREwDwYDVQQLEwhBbWVyaWNh czEcMBoGA1UECxMTSW5mb3JtYXRpb24gU3lzdGVtczEPMA0GA1UEBRMGMTIyNzY1MRcwFQYKCZIm iZPyLGQBARMHaGFycmljODEjMCEGA1UEAxMaQ2hyaXN0b3BoZXIgSGFycmluZ3Rvbi1FbmMxLTAr BgkqhkiG9w0BCQEWHmNocmlzdG9waGVyLmhhcnJpbmd0b25AZW1jLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALkuHI2WDll/BOd40HVywnDJpkxwxGs0Hpqxmikq298tLVn4QxLr LhdIFtW+8Ish3Cfat2810FCTAbmh855JYkAJlj2zMx5s4hri45l4cRpRVeWxdH0o5X278NS2ZXU2 DDJAa3Dx46gTz9/xRE4EAoHtMhr5Vr9rDOqkfCmAZmd1kOeQF3W1SmUgaPxEIHp27s0Sso5khGdc 2/2GyEmos4dJ86PaaZbpf9lcZwC5LVfcpa9ZOXh6bqd7U8hDznZ5PRJB6k+CAFBrt+WiYvsYG7is IYIPXrCkUVuRYkXupXqXqu5OEs3ANeAG+ehJxn6Ww+mZeYJfOSAWLARLWsI5ZGsCAwEAAaOCAbUw ggGxMDUGA1UdJQQuMCwGCisGAQQBgjcUAgIGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoD BDAfBgNVHSMEGDAWgBQUMOtr9fRJtWhSdabbva5byKx9TDCBkQYDVR0gBIGJMIGGMIGDBgkqhkiG 9w0FBwUwdjAuBggrBgEFBQcCARYiaHR0cDovL2NhLnJzYXNlY3VyaXR5LmNvbS9DUFMuaHRtbDBE BggrBgEFBQcCAjA4MBcWEFJTQSBTZWN1cml0eSBMTEMwAwIBARodQ1BTIEluY29ycG9yYXRlZCBi eSByZWZlcmVuY2UwSgYDVR0RBEMwQYEeY2hyaXN0b3BoZXIuaGFycmluZ3RvbkBlbWMuY29toB8G CisGAQQBgjcUAgOgEQwPaGFycmljOEBlbWMuY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9j cmwucnNhc2VjdXJpdHkuY29tOjgwL1JTQUNsYXNzMlBlcnNvbmFsQ0F2Mi5jcmwwHQYDVR0OBBYE FFp5a07UDPJYJvedFEuB1U2ACAW1MA4GA1UdDwEB/wQEAwIDODANBgkqhkiG9w0BAQUFAAOCAQEA PaMUkDlrJh/pKXE9hwn4NJny1feBdfjqRUlziiKo3/+Jwn3YToU+nh+uic4anPiw+Iv1N1apK5mW aPCu36xFhgtVBnbSJQ0c+Aeal1HxRttlJp2AtQ8WBYN2eJ7NkEHajhTU+49GL6woFU9cKS+GI9cp QU6H2E/eYe628ngK/sTqfUF2HZalvwLcQZAr7RkrLcOYt8PsXFZmijVGZC76wI4xRfo4o9Of1epL jZ0FmhRy3sfnLuEmDBuOOnlQSkyBUinHcv0g0QhZ8WOvhocAvobbYXk67ADjRF2MV/J6jHq+lQVG p5/DLic0VM0W/gRcpZmZu5DYeK/TJD8ohGaq1zGCBHswggR3AgEBMIG0MIGeMQswCQYDVQQGEwJV UzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEQMA4GA1UEBxMHQmVkZm9yZDEZMBcGA1UEChMQUlNB IFNlY3VyaXR5IExMQzElMCMGA1UECxMcR2xvYmFsIFNlY3VyaXR5IE9yZ2FuaXphdGlvbjEjMCEG A1UEAxMaUlNBIENsYXNzIDIgUGVyc29uYWwgQ0EgdjICEQCEN6DbqD6gUt2IQ1Cad65UMAkGBSsO AwIaBQCgggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEx MzEzMTc1N1owIwYJKoZIhvcNAQkEMRYEFOWozg5MVrP10qxMthwieIYgRdZFMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHEBgkrBgEE AYI3EAQxgbYwgbMwgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYD VQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0EgU2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwg U2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYDVQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2 MgIQM5BkjrAOnzTyQ0ivlvzeZDCBxgYLKoZIhvcNAQkQAgsxgbaggbMwgZ4xCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHEwdCZWRmb3JkMRkwFwYDVQQKExBSU0Eg U2VjdXJpdHkgTExDMSUwIwYDVQQLExxHbG9iYWwgU2VjdXJpdHkgT3JnYW5pemF0aW9uMSMwIQYD VQQDExpSU0EgQ2xhc3MgMiBQZXJzb25hbCBDQSB2MgIQM5BkjrAOnzTyQ0ivlvzeZDANBgkqhkiG 9w0BAQEFAASCAQC7x0RvzJKiHfu+V/4Ve4jCVdTaXTdJbQoCNoFBdhxq43DBWvkXOZ8porlsiTfb yUylGKs+7LQefqrTVY62BRTAb0ksNl7b/AXuMnEFY3chtSRR0aK40yNMTns654avdV1Obsjw+pD0 vTi+EGhOwDWngf/EmuCWtM8iZCRBzF3AtMkRSueQJI9Vf+AHFeeimpJ27TqS62bJF5HttGGDUc+L CidZ/qgA2BYj2KplS1K336Nge/Im6JVzg5v5QpdhzUGgdqa4lZ8wM7/wZtz+kSSwSxMIf5XH6hwM Q0BeSupQmaMJdsLZ/e7BjTkynZxN/l5weuhdYSNhmK1rJQuTvuv1AAAAAAAA ------=_NextPart_000_0117_01CF1037.F71E2F70-- From rdd@cert.org Mon Jan 13 13:33:07 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFB91AE1CC for ; Mon, 13 Jan 2014 13:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe2PAPUjrZSu for ; Mon, 13 Jan 2014 13:33:05 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 662491AE1C0 for ; Mon, 13 Jan 2014 13:33:05 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0DLWrEr009123 for ; Mon, 13 Jan 2014 16:32:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389648773; bh=wzf2MNt+YH3EvyoL8P0kuxf20Zw+XDDbcdRH1cO10MU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=OEvmTKgE7FWG8N9I6GeFb7x2CcDb28wq1Oj4Sj5fAx7J1QFPYmI2xKmTO0pcxVcOU AtRSSjLM0KEazgieSbE3sH0TD3f0VbkEPFqkM4JJXeug8xjvTLed6kGzkMrq9rPwFr KlRpnozkHL2m1EG0PD2w7oouQVekRlTfd6q40+ds= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0DLWrsa009696 for ; Mon, 13 Jan 2014 16:32:53 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 16:32:53 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Consistent and descriptive naming of EmailInfo Subclasses Thread-Index: Ac8QV9J9J77J1kH7Skeb9WDsXPXS+A== Date: Mon, 13 Jan 2014 21:32:52 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C0FAFB@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Consistent and descriptive naming of EmailInfo Subclasses X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:33:07 -0000 Hello! Currently, the EmailInfo class is defined as: +-------------------------+ | EmailInfo | +-------------------------+ {0..1}--[ Email ] {0..1}--[ EmailSubject ] {0..1}--[ X-Mailer ] Would there be interest in renaming some of these classes for consistency a= nd descriptive clarity as follows: ** The name of the class "Email" is misleading to me since it represents no= t an email but the From: header field value (per the schema comments). I w= ould propose that the Email class be renamed to EmailFrom for clarity. ** In order to consistently name all subclasses of EmailInfo with the prefi= x "Email", I would propose that the "X-Mailer" class be renamed to "EmailX-= Mailer". Roman From Paul.Stoecker@rsa.com Mon Jan 13 13:38:09 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CBF1AE1C1 for ; Mon, 13 Jan 2014 13:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.997 X-Spam-Level: * X-Spam-Status: No, score=1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEixB8NxZJEX for ; Mon, 13 Jan 2014 13:38:08 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 016D41AE1C6 for ; Mon, 13 Jan 2014 13:38:07 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0DLbrfv005326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jan 2014 16:37:53 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0DLbrfv005326 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1389649073; bh=rA2TjtlyfWNZQzxAY3ZIztGHu1A=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=Z66r7z5EElBgi1QbNX1Nta2SiXnJTWyV3GE1+GTTpLbIZrff9L0FLjZTenw5yiwMW jNaE7Q4EhbJR9uu4VzjXzb52zPzhS+zEAEY5ZkzGjudgoz86ZmzVylCSiUTS7MNrXH 50OOahe4Ulb3IG2TxU8huqgB5+6qE96jhNzRB+a4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s0DLbrfv005326 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 13 Jan 2014 13:37:40 -0800 Received: from mxhub39.corp.emc.com (mxhub39.corp.emc.com [128.222.70.106]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0DLbdGa009535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 16:37:40 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub39.corp.emc.com (128.222.70.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 13 Jan 2014 16:37:39 -0500 Received: from MX103CL01.corp.emc.com ([169.254.5.132]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 16:37:39 -0500 From: "Stoecker, Paul" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: [mile] Consistent and descriptive naming of EmailInfo Subclasses Thread-Index: AQHPEKeu+WrDw11P/kKjcnICIKBYSA== Date: Mon, 13 Jan 2014 21:37:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.105.36.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <8DF0087C0AD03547B39811F3FC1FF663@mail.corp.emc.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Consistent and descriptive naming of EmailInfo Subclasses X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:38:09 -0000 Agreed. =20 Paul W. Stoecker, Ph.D. Principal Product Manager Regional Product Management Team Pragmatic Marketing Certified - III RSA, The Security Division of EMC cell: 571.419.2578 | e: paul.stoecker@rsa.com =20 On 1/13/14 4:32 PM, "Roman D. Danyliw" wrote: >Hello! > >Currently, the EmailInfo class is defined as: > >+-------------------------+ >| EmailInfo | >+-------------------------+ >{0..1}--[ Email ] >{0..1}--[ EmailSubject ] >{0..1}--[ X-Mailer ] > >Would there be interest in renaming some of these classes for consistency >and descriptive clarity as follows: > >** The name of the class "Email" is misleading to me since it represents >not an email but the From: header field value (per the schema comments). >I would propose that the Email class be renamed to EmailFrom for clarity. >** In order to consistently name all subclasses of EmailInfo with the >prefix "Email", I would propose that the "X-Mailer" class be renamed to >"EmailX-Mailer". > >Roman >_______________________________________________ >mile mailing list >mile@ietf.org >https://www.ietf.org/mailman/listinfo/mile > From rdd@cert.org Tue Jan 14 07:25:25 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4331AE0EA for ; Tue, 14 Jan 2014 07:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkiulnsXwkyc for ; Tue, 14 Jan 2014 07:25:23 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 512991ADFB6 for ; Tue, 14 Jan 2014 07:25:23 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0EFPBLE011089 for ; Tue, 14 Jan 2014 10:25:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389713111; bh=AmteDvdLr3YsxRACf7ZApX/ThGo5niiXKoEm1t3aTfg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=BYR7aurYfF/CHY6CJDSOjT0Cd4V4VOeydckLxt/flrcCwd8WN9MVevMuRuhTLPUnn 6QcuiCMck+W2w7/4Oh2BHsh7M3fv9GUBXOifj46rh7q4qrXjYUI0KSo0DJhZPSD24k Z/fmMURMcP7PHX7fRo7wTcCSdBqltc1tMXMZIDPs= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0EFPBtv017629 for ; Tue, 14 Jan 2014 10:25:11 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Tue, 14 Jan 2014 10:25:11 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Attributes of the Key class Thread-Index: Ac8ROH1UKtJl+89zQoqJaQFudDjEbQ== Date: Tue, 14 Jan 2014 15:25:11 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C104F8@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Attributes of the Key class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:25:25 -0000 Hello, In reviewing the -03 draft, I have a few questions on the definition of the= Key class (Section 3.22.1). ** RegistryKeyModified/Key has the @ext-category attribute whose text read= s "extension category". Could someone please explain the purpose of this a= ttribute or provide better text. It seems like this attribute was a typo a= nd should really be named @ext-registryaction to extend @registryaction whe= n it is set to "ext-value". ** RegistryKeyModified/Key also has the attributes @type and @type-ext list= ed in the text, but not in the schema. It is not documented but is describ= ed as having two enumerated values of "watchlist" and "ext-value". Could s= omeone please explain this attribute or provide better text. Also, the num= erated value of "ext-value" for @type is being used in a way inconsistently= with Section 5.1. We need to fix that. Roman From kathleen.moriarty@emc.com Tue Jan 14 12:18:39 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F291AE0D5 for ; Tue, 14 Jan 2014 12:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf4Tt68cojHJ for ; Tue, 14 Jan 2014 12:18:36 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0F17E1AE155 for ; Tue, 14 Jan 2014 12:18:35 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0EKII1G018118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Jan 2014 15:18:19 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0EKII1G018118 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389730699; bh=rk4S3qneA3A1Y5KAv+EKYIGsHD0=; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; b=M1ah1MRvT4bag51GYuT13sCaz64ZAwpFzqMlIYcfDFzYe3HZEfI3PsZ+E72Oo+bix p6MT0WI+VDCtvEtjYs5x+OrbdA7GPuarB60lV58WU4aj5oD3GC8pD9xPa5v1R7tkGp QuQnesmmIEnnUQT3X15nH5YmPCYGa0/lA0q7EQpA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0EKII1G018118 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Tue, 14 Jan 2014 15:18:13 -0500 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0EKICBm005217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 14 Jan 2014 15:18:13 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Tue, 14 Jan 2014 15:18:12 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Tue, 14 Jan 2014 15:18:11 -0500 Thread-Topic: Implementation Report - opportunity for vendors and other implementors Thread-Index: Ac8RZSp3GXR+y/yMSmy6PFswgSgutw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2406584BA62EMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Subject: [mile] Implementation Report - opportunity for vendors and other implementors X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:18:39 -0000 --_000_F5063677821E3B4F81ACFB7905573F2406584BA62EMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We are pulling together an implementation report in a draft on MILE related= standards. If you have implemented any of the MILE related standards and = would like to have a description included in the report, please let me know= ASAP. I will plan to have the first draft out within a week and can add a= dditional implementation reports into subsequent drafts. I will just need a write up that can include a product or implementation de= scription and details on the RFCs or drafts implemented. This can include = RFC5070, work on RFC5070-bis (IODEF v2), support of the SCI draft (soon-to-= be RFC), IODEF extensions, or RID (RFC6545 and RFC6546). I know there are = a few IODEF over XMPP implementations, they are welcome as well. If you ar= e not sure, please ask. You can send the write up to me directly and I'll include them all in the d= raft report. Thank you, Kathleen --_000_F5063677821E3B4F81ACFB7905573F2406584BA62EMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

We are = pulling together an implementation report in a draft on MILE related standa= rds.  If you have implemented any of the MILE related standards and wo= uld like to have a description included in the report, please let me know A= SAP.  I will plan to have the first draft out within a week and can ad= d additional implementation reports into subsequent drafts. 

 

I will= just need a write up that can include a product or implementation descript= ion and details on the RFCs or drafts implemented.  This can include R= FC5070, work on RFC5070-bis (IODEF v2), support of the SCI draft (soon-to-b= e RFC), IODEF extensions, or RID (RFC6545 and RFC6546).  I know there = are a few IODEF over XMPP implementations, they are welcome as well.  = If you are not sure, please ask.

&n= bsp;

You can send the write up to me directly= and I’ll include them all in the draft report.

 

Thank you,

Kathleen

= --_000_F5063677821E3B4F81ACFB7905573F2406584BA62EMX15Acorpemcc_-- From internet-drafts@ietf.org Tue Jan 14 18:13:12 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72B71AE1D8; Tue, 14 Jan 2014 18:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3zStt5lRHsy; Tue, 14 Jan 2014 18:13:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B5A1AE151; Tue, 14 Jan 2014 18:13:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140115021310.29105.36406.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2014 18:13:10 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-sci-13.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 02:13:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : IODEF-extension for structured cybersecurity info= rmation Authors : Takeshi Takahashi Kent Landfield Thomas Millar Youki Kadobayashi Filename : draft-ietf-mile-sci-13.txt Pages : 30 Date : 2014-01-14 Abstract: This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among security experts at organizations and facilitates their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-sci/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-sci-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-sci-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rdd@cert.org Wed Jan 15 06:57:25 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BED11AE389 for ; Wed, 15 Jan 2014 06:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7p7GswSkS0J for ; Wed, 15 Jan 2014 06:57:23 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 549B81AE386 for ; Wed, 15 Jan 2014 06:57:21 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0FEv9LC010439 for ; Wed, 15 Jan 2014 09:57:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389797829; bh=OVGhwaa+jVpp2+m6yAZfntXEQZCtyEhUNoJVchxygo8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=UMJwAvI7glkPsxxBng2ngYB6K1eu0GlN+PCA+ZivPC9CH0veEYRQfVgn3bzfwtcw8 8GVlldFnwfGXE5+RaTLwktPZmpCAN/Lim1WngAzrTsdQbyrBciL7iPwPVrNImweg6r RUfO5GNYZPZhYHqcuOO/xyqxFquU1AhAIS13Jls8= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0FEv9MT006270 for ; Wed, 15 Jan 2014 09:57:09 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Wed, 15 Jan 2014 09:57:09 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Representing a domain name (or Issue #4) Thread-Index: Ac8SAgtTsOQXjaJoSD+fM1PrWR2VyQ== Date: Wed, 15 Jan 2014 14:57:07 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1204A@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Representing a domain name (or Issue #4) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:57:25 -0000 Hello! Tracked in Issue #4, http://trac.tools.ietf.org/wg/mile/trac/ticket/4, is t= he need to make a modeling decision on how to represent domain name. To su= mmarize, we currently have two duplicate ways to represent a domain name fo= r given Node. RFC5070 defined Node/NodeName. DomainData from RFC5901 was = added to the Node class in RFC5070bis. This change allows Node/DomainData/= Name to also describe a domain name. Both of these valid representations are shown in this XML snippet: www.example.com www.example.com 2013-01-02T05:54:02-05:00
10.1.1.1.
2013-01-02T05:54:02-05:00 This will likely create implementation confusion. As I see it, we have at least the following options: (1) Remove NodeName and DateTime from Node in favor of DomainData (2) Remove Name and DateDomainWasChecked from DomainData in favor of NodeNa= me and DateTime Option #1 break compatibility with RFC 5070. Also, NodeName can represent = any kind of host name. As defined DomainData/Name only represents FQDN DNS= names. Option #2 redefines DomainData from RFC 5901 so we can't strictly cite the = element. Roman From rdd@cert.org Wed Jan 15 08:03:09 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9815B1AE398 for ; Wed, 15 Jan 2014 08:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jft9TD1KSCW for ; Wed, 15 Jan 2014 08:03:05 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7C1AE3A4 for ; Wed, 15 Jan 2014 08:03:04 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0FG2pGR013184; Wed, 15 Jan 2014 11:02:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389801771; bh=itIQjIM9oBmYQvZlB/Ak7kekMOvOTeD34mgd+p7v5Nk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=llWa4S/hYXkNoaYpYtvAUNbGtGX6Y4OTyKB4M2tkN8lHryJ8TnKElb9MouAOMwnPI bp4FHDt7uKFDBeuZAHmsfCItddyabkQVj5FmuRZ37gqPrx6QMnfu6/+yUrPCU5Xdbo ZogTmJrrrGaPuH7JoRECWhnPgKjPZY7Yk1P3zTSY= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0FG2nhK013159; Wed, 15 Jan 2014 11:02:50 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Wed, 15 Jan 2014 11:02:49 -0500 From: "Roman D. Danyliw" To: "Harrington, Christopher" , "Stoecker, Paul" Thread-Topic: [mile] Describing the time window during which an indicator should be used Thread-Index: Ac8QYd5ePk2lBkToRcSzhFdZzeEY9QBp2miA Date: Wed, 15 Jan 2014 16:02:48 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C12208@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C12208marathon_" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 16:03:09 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C12208marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like to explore the community thinking on how to implement a flag as Ch= ris suggested to note that an indicator is persistent. Assuming that the c= onvention of @indicator-stime and -etime was adopted, a few possibilities t= o add a "persistence flag" would be: (1) Add a boolean attribute, say @indicator-persistent, to convey to always= look for this indicator. No @indicator-etime would be required. (2) Define a particular date far into the future for @indicator-etime that = conveys persistence. For example, when @indicator-etime=3D"3000/12/01 12:0= 0:00" is seen, this indicator is persistent. Option #1 is most intuitively self-describing but adds another attribute, n= ow the fifth, to the list of "special indicator attributes". Option #2 reduces the number of additional attributes. Personally, I prefer #2. Your thoughts? Roman From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] Sent: Monday, January 13, 2014 8:18 AM To: Roman D. Danyliw; Stoecker, Paul Cc: mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator sh= ould be used Roman, >From what I have seen the aging is usually up to the recipient. I would say= that option #1 would be better. For purposes of deciding to stop looking for an indicator there is another = data point that is used far more frequently, Last Seen time. For the majori= ty of indicators we use the time it was last "seen". For us the "seen" mean= s that either we have seen it being used or we have intel from a 3rd party = or open source that it is still in use. The only time we use the stime-etim= e paradigm is when there is an infection (delivery stage of the Kill Chain)= that was valid but later cleaned up. Nbc.com was compromised last year for= about 4 hours then cleaned up. In that case we would use stime-etime. Ther= e are indicators that we call persistent. These are indicators that we will= never stop looking for. These could be indicators that are used exclusivel= y by a specific threat actor (like a domain registered by an actor) or some= thing that we used in a previous incident at our organization, like RSA bre= ech related indicators. A construct to flag an indicator as persistent woul= d be helpful as this is information is something we routinely share. Thanks, --Chris From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 09, 2014 4:59 PM To: Harrington, Christopher; Stoecker, Paul Cc: mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator sh= ould be used Hello! Chris: Thanks for the background! To date, the message traffic suggests interest in per-indicator annotation = of validity. That would suggest something as follows: Or The follow-up discuss asked if organizations really every stop looking for = indicators they have. One answer was yes. How do we want to handle that? Ideas might include: (1) provide only an @indicator-stime and @indicator-etime, and these are th= e best guess of the reporter of how long to make it valid. The recipient c= an decide how and if to honor these. (2) provide another attribute that would suggest an aging policy that the r= ecipient can choose to honor. What would we those aging policies? Roman From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] Sent: Monday, December 23, 2013 10:46 AM To: Stoecker, Paul Cc: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator sh= ould be used Yes we do stop looking. A good example is when NBC.com got hacked a few mon= ths ago. We watched for people hitting it while the URL was malicious. Once= it was cleaned up we stopped watching for it since it was a somewhat popul= ar URL that would fire all the time and bury us in false positives. Indicator aging is an area that nobody has a good handle one. Each organiza= tion seems to have their own way of doing things with aging, if they do any= thing at all. Some commercial threat intel providers use a decrementing cou= nter based on the last time the indicator was seen. At EMC we make the agin= g calculation based on time since last seen, attribution (if known), kill c= hain stage, confidence in the source and other factors. It's not automated= at this point. We can't keep all indicators forever. At some point the watch lists and blo= ck lists on your Proxy, firewall, etc get too large and the devices start h= aving issues. We ran into this at EMC and had to switch from Proxy blocks f= or domains to DNS RPZ with a sinkhole web servers. There were too many doma= ins in the proxy block list. We have tens of thousands. There are indicator= s that we consider "persistent". These are indicators that we always want t= o be alerted about. Generally these are advanced threat / APT and have eith= er been seen in activity involving EMC or they belong to threat actor group= s that we have seen at EMC. Thanks, --Chris From: Stoecker, Paul Sent: Monday, December 23, 2013 10:26 AM To: Harrington, Christopher Cc: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Describing the time window during which an indicator sh= ould be used I have a question...Do we really stop looking for IOCs whose time has expir= ed? Like a malicious URL whose time has expired...do you stop looking for = that URL? Let's say that Paul the malware dude got a hold of the IODEF doc= ument...I shutdown my web server and after the time expired I turned it bac= k on? Just wondering how IOC aging is actually handled? Sent from my iPhone On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" > wrote: Hello, Answers inline below. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, December 20, 2013 4:26 PM To: mile@ietf.org Subject: [mile] Describing the time window during which an indicator should= be used Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking = the need to convey the valid time during which to apply an indicator. I wa= nted to solicit from the community the degree of flexibility desired. For = the purposes of this discussion an indicator is defined as a class that has= an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, Yes, a malicious URL would be valid only as long as it is live. ** Could it be at the EventData level (and the time window cascades to all = indicators that are children)? Example 2:, ... = ... many domain indicators ... Example 3: ... 2013/12/01 12:00:00 ... ... many domain indicators ... Yes, you could have multiple malware delivery URLs that are all on the same= domain. If the Domain is specified at EvenData level then when it is no lo= nger valid the children would no longer be valid. I hope I explained that r= ight :) I am not sure how it would differ between Example 2 and 3. ** Could it be at the Incident level? Example 4: ... 2013/12/01 12:00:00 ... many domain indicators ... If there was only one Indicator in an incident it could be. In practical te= rms this is very unlikely. Per indicator time information would provide the most flexibility but would= require duplication of the same information. A time window for indicator validity specified at the Incident level would = not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would= require nested EventData instances to convey different time period. Also,= some indicators are only in the Incident class so this approach would be i= nsufficient. Perhaps a hybrid approach where this timing information is in= the EventData and IncidentData classes could be possible. Personally I think the safest approach is validity per Indicator. Validity= for parent / child would be rare and validity per Incident even rarer. One question, how do we represent "still valid"? If I have an indicator tha= t is valid when I send the message how do I know what that time represents?= If I put "12/20/2013 13:00" as the time can you tell if I mean that it wa= s still valid when I sent the message at that time or that its validity per= iod ended at that time. Those are very different scenarios and critically i= mportant for searching / responding to indicator hits. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_359EC4B99E040048A7131E0F4E113AFC54C12208marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I’d like to expl= ore the community thinking on how to implement a flag as Chris suggested to= note that an indicator is persistent.  Assuming that the convention o= f @indicator-stime and –etime was adopted, a few possibilities to add a “persiste= nce flag” would be:

 

(1) Add a boolean attr= ibute, say @indicator-persistent, to convey to always look for this indicat= or.  No @indicator-etime would be required.

 

(2) Define a particula= r date far into the future for @indicator-etime that conveys persistence.&n= bsp; For example, when @indicator-etime=3D”3000/12/01 12:00:00= ”  is seen, this indicator is persistent.

 

Option #1 is most intuitively self-describing but ad= ds another attribute, now the fifth, to the list of “special indicato= r attributes”.

 

Option #2 reduces the number of additional attribute= s.

 

Personally, I prefer #2.  Your thoughts?

 

Roman

 

From: Harringt= on, Christopher [mailto:Christopher.Harrington@emc.com]
Sent: Monday, January 13, 2014 8:18 AM
To: Roman D. Danyliw; Stoecker, Paul
Cc: mile@ietf.org
Subject: RE: [mile] Describing the time window during which an indic= ator should be used

 

Roman,

 

From what I have seen = the aging is usually up to the recipient. I would say that option #1 would = be better.

 

For purposes of decidi= ng to stop looking for an indicator there is another data point that is use= d far more frequently, Last Seen time. For the majority of indicators we us= e the time it was last “seen”. For us the “seen” means that either we have seen it being used or we = have intel from a 3rd party or open source that it is still in u= se. The only time we use the stime-etime paradigm is when there is an infec= tion (delivery stage of the Kill Chain) that was valid but later cleaned up. Nbc.com was compromised last year for abou= t 4 hours then cleaned up. In that case we would use stime-etime. There are= indicators that we call persistent. These are indicators that we will neve= r stop looking for. These could be indicators that are used exclusively by a specific threat actor (like a= domain registered by an actor) or something that we used in a previous inc= ident at our organization, like RSA breech related indicators. A construct = to flag an indicator as persistent would be helpful as this is information is something we routinely share. <= o:p>

 

Thanks,

 

--Chris

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Thursday, January 09, 2014 4:59 PM
To: Harrington, Christopher; Stoecker, Paul
Cc: mile@ietf.org
Subject: RE: [mile] Describing the time window during which an indic= ator should be used

 

Hello!

 

Chris: Thanks for the = background!

 

To date, the message t= raffic suggests interest in per-indicator annotation of validity.  Tha= t would suggest something as follows:

 

<Assessment indicator-uid=3D”foo-12345̶= 1; indicator-stime=3D”2013/12/01 12:00:00”>

Or <= /p>

<Assessment indicator-uid=3D”foo-12345̶= 1; indicator-stime=3D”2013/12/01 12:00:00” indicator-etime=3D&#= 8221;2013/12/01 13:00:00”-->

 

The follow-up discuss asked if organizations really = every stop looking for indicators they have.  One answer was yes.=

 

How do we want to handle that?  Ideas might inc= lude:

 

(1) provide only an @indicator-stime and @indicator-= etime, and these are the best guess of the reporter of how long to make it = valid.  The recipient can decide how and if to honor these.=

 

(2) provide another attribute that would suggest an = aging policy that the recipient can choose to honor.  What would we th= ose aging policies?

 

Roman

 

 

From: Harringt= on, Christopher [<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">mailto:Christopher.Harrington@emc.com]
Sent: Monday, December 23, 2013 10:46 AM
To: Stoecker, Paul
Cc: Roman D. Danyliw; mile@ietf.org
Subject: RE: [mile] Describing the time window during which an indic= ator should be used

 

Yes we do stop looking= . A good example is when NBC.com got hacked a few months ago. We watched fo= r people hitting it while the URL was malicious. Once it was cleaned up we = stopped watching for it since it was a somewhat popular  URL that would fire all the time and bury us in f= alse positives.

 

Indicator aging is an = area that nobody has a good handle one. Each organization seems to have the= ir own way of doing things with aging, if they do anything at all. Some com= mercial threat intel providers use a decrementing counter based on the last time the indicator was seen. At EMC= we make the aging calculation based on time since last seen, attribution (= if known), kill chain stage, confidence in the source  and other facto= rs. It’s not automated at this point.

 

We can’t keep al= l indicators forever. At some point the watch lists and block lists on your= Proxy, firewall, etc get too large and the devices start having issues. We= ran into this at EMC and had to switch from Proxy blocks for domains to DNS RPZ with a sinkhole web servers. There wer= e too many domains in the proxy block list. We have tens of thousands. Ther= e are indicators that we consider “persistent”. These are indic= ators that we always want to be alerted about. Generally these are advanced threat / APT and have either been seen in act= ivity involving EMC or they belong to threat actor groups that we have seen= at EMC.

 

Thanks,

 

--Chris

 

From: Stoecker= , Paul
Sent: Monday, December 23, 2013 10:26 AM
To: Harrington, Christopher
Cc: Roman D. Danyliw; mile@ietf.org
Subject: Re: [mile] Describing the time window during which an indic= ator should be used

 

I have a question...Do we really stop looking for IO= Cs whose time has expired?  Like a malicious URL whose time has expire= d...do you stop looking for that URL?  Let's say that Paul the malware= dude got a hold of the IODEF document...I shutdown my web server and after the time expired I turned it back on?

 

Just wondering how IOC aging is actually handled?
Sent from my iPhone


On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" <Christopher.Harrington@emc.com<= /a>> wrote:

Hello,

 

Answers inline below. =

 

Thanks,

 

--Chris

 

Christopher Harrington=
Consulting Security Engineer
GSO - Critical Incident Response Center
EMC
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

 

From: mile [mailto:mile-bounc= es@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, December 20, 2013 4:26 PM
To: mile@ietf.or= g
Subject: [mile] Describing the time window during which an indicator= should be used

 

Hello!

 

Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28= ) is tracking the need to convey the valid time during which to apply an in= dicator.  I wanted to solicit from the community the degree of flexibility desired.  For the purposes of thi= s discussion an indicator is defined as a class that has an @indicator-uid = attribute.

 

** Does this flexibility need to exist on a per indi= cator basis?

Example 1, <Assessment indicator-uid=3D”foo= -12345” indicator-valid-stime=3D”2013/12/01 12:00:00”>=

Yes, a malicious URL w= ould be valid only as long as it is live.

 

** Could it be at the EventData level (and the time = window cascades to all indicators that are children)?

Example 2:, <EventData indicator-stime=3D”2= 013/12/01 12:00:00”> … <Flow> … many domain indi= cators </Flow> … </EventData>

Example 3: <EventData>  … <Indic= atorStartTime>2013/12/01 12:00:00</IndicatorStartTime> … <= ;Flow> … many domain indicators </Flow> … </EventDa= ta>

Yes, you could have mu= ltiple malware delivery URLs that are all on the same domain. If the Domain= is specified at EvenData level then when it is no longer valid the childre= n would no longer be valid. I hope I explained that right J  I am not sure how it wou= ld differ between Example 2 and 3.

 

** Could it be at the Incident level?

Example 4: <Incident>  … <Indica= torStartTime>2013/12/01 12:00:00</IndicatorStartTime> … many= domain indicators </Flow> … </Incident>

If there was only one = Indicator in an incident it could be. In practical terms this is very unlik= ely.

 

Per indicator time information would provide the mos= t flexibility but would require duplication of the same information.

 

A time window for indicator validity specified at th= e Incident level would not allow for multiple time windows per indicator.

 

A time window for indicator validity specified in th= e EventData class would require nested EventData instances to convey differ= ent time period.  Also, some indicators are only in the Incident class= so this approach would be insufficient.  Perhaps a hybrid approach where this timing information is in the EventDat= a and IncidentData classes could be possible.

 

Personally I think the= safest approach is validity per Indicator.  Validity for parent / chi= ld would be rare and validity per Incident even rarer.

 

One question, how do w= e represent “still valid”? If I have an indicator that is valid= when I send the message how do I know what that time represents?  If = I put “12/20/2013 13:00” as the time can you tell if I mean that it was still valid when I sent the message at that time or tha= t its validity period ended at that time. Those are very different scenario= s and critically important for searching / responding to indicator hits.

 

Roman

 

____________________________________= ___________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile<= o:p>

--_000_359EC4B99E040048A7131E0F4E113AFC54C12208marathon_-- From rdd@cert.org Wed Jan 15 08:23:44 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CEC1AE3CC for ; Wed, 15 Jan 2014 08:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNN4S1gsG6rk for ; Wed, 15 Jan 2014 08:23:42 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5FDA1AE104 for ; Wed, 15 Jan 2014 08:23:38 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0FGNPHt013705 for ; Wed, 15 Jan 2014 11:23:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389803005; bh=WSr9AKaESkSB6LiI2O+1jxACiQOoeXbc8GAnusyBY8M=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=ZpZbdWKeji2p/1rRa0S0nkHU2GYDzj8tagx/B6k6ktsrWEdPGAkj9jmv5XxwxVq7r kIZD2jE9Jcqq7WGaWSlOrXDlJDb15UW/Hmt1g+9eEnGt2XVNXO8b4Pe05ENJTdXTr0 GR0+uL4HMZnjt/gldPNDX9XgMHm+6tFZibEMbeN4= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0FGNSkc022896 for ; Wed, 15 Jan 2014 11:23:28 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Wed, 15 Jan 2014 11:23:25 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Representing a domain name (or Issue #4) Thread-Index: Ac8SAgtTsOQXjaJoSD+fM1PrWR2VyQACdNwQ Date: Wed, 15 Jan 2014 16:23:25 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C122B3@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C1204A@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1204A@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Representing a domain name (or Issue #4) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 16:23:44 -0000 Hello! I omitted an important detail in my earlier write-up. The Service class al= so got a DomainData class in 5070bis (at least in the schema but not in the= text). Hence, there are actually three places to put the domain name. He= nce, the following XML-snippet would be legal: ... www.example.com www.example.com 2013-01-02T05:54:02-05:00
10.1.1.1.
2013-01-02T05:54:02-05:00 ... www.example.com 2013-01-02T05:54:02-05:00 To expand upon the previously suggested options: (1) Remove Node/NodeName and Service/DomainData/Name in favor of Node/Domai= nData/Name =20 (2) Remove Node/DomainData/Name and Service/DomainData/Name in favor of Nod= e/NodeName (3) Remove Node/DomainData/Name and Node/NodeName in favor of Service/Domai= nData/Name =20 > Option #1 break compatibility with RFC 5070. Also, NodeName can represen= t > any kind of host name. As defined DomainData/Name only represents FQDN > DNS names. >=20 > Option #2 redefines DomainData from RFC 5901 so we can't strictly cite th= e > element. Option #3 has the same disadvantages as #1 and would also requires further = changes Service. Currently, the Service class minimally expects port infor= mation. Roman > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Wednesday, January 15, 2014 9:57 AM > To: mile@ietf.org > Subject: [mile] Representing a domain name (or Issue #4) >=20 > Hello! >=20 > Tracked in Issue #4, http://trac.tools.ietf.org/wg/mile/trac/ticket/4, is= the > need to make a modeling decision on how to represent domain name. To > summarize, we currently have two duplicate ways to represent a domain > name for given Node. RFC5070 defined Node/NodeName. DomainData from > RFC5901 was added to the Node class in RFC5070bis. This change allows > Node/DomainData/Name to also describe a domain name. >=20 > Both of these valid representations are shown in this XML snippet: >=20 > > > www.example.com > > www.example.com > 2013-01-02T05:54:02- > 05:00 > >
10.1.1.1.
> 2013-01-02T05:54:02-05:00 > > >=20 > This will likely create implementation confusion. >=20 > As I see it, we have at least the following options: >=20 > (1) Remove NodeName and DateTime from Node in favor of DomainData >=20 > (2) Remove Name and DateDomainWasChecked from DomainData in favor of > NodeName and DateTime >=20 > Option #1 break compatibility with RFC 5070. Also, NodeName can represen= t > any kind of host name. As defined DomainData/Name only represents FQDN > DNS names. >=20 > Option #2 redefines DomainData from RFC 5901 so we can't strictly cite th= e > element. >=20 > Roman > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trevorf@exchange.microsoft.com Wed Jan 15 11:36:20 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41F11AE199 for ; Wed, 15 Jan 2014 11:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy7a3UDK0yAm for ; Wed, 15 Jan 2014 11:36:18 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) by ietfa.amsl.com (Postfix) with ESMTP id 086FF1AE0FD for ; Wed, 15 Jan 2014 11:36:17 -0800 (PST) Received: from BL2SR01CA104.namsdf01.sdf.exchangelabs.com (10.255.109.149) by BLUSR01MB589.namsdf01.sdf.exchangelabs.com (10.255.124.163) with Microsoft SMTP Server (TLS) id 15.0.868.2; Wed, 15 Jan 2014 19:03:03 +0000 Received: from SN2FFOFD003.ffo.gbl (157.55.158.23) by BL2SR01CA104.outlook.office365.com (10.255.109.149) with Microsoft SMTP Server (TLS) id 15.0.868.2 via Frontend Transport; Wed, 15 Jan 2014 19:03:03 +0000 Received: from hybrid.exchange.microsoft.com (131.107.159.100) by SN2FFOFD003.mail.o365filtering.com (10.111.201.40) with Microsoft SMTP Server (TLS) id 15.0.847.5 via Frontend Transport; Wed, 15 Jan 2014 19:03:03 +0000 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.23; Wed, 15 Jan 2014 11:02:32 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) with Microsoft SMTP Server (TLS) id 15.0.847.21; Wed, 15 Jan 2014 11:02:31 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.37]) with mapi id 15.00.0847.008; Wed, 15 Jan 2014 11:02:31 -0800 From: Trevor Freeman To: "mile@ietf.org" Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616w== Date: Wed, 15 Jan 2014 19:02:29 +0000 Message-ID: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_5ab052bec168432abe90e4de00da53fbDFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.159.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(199002)(189002)(77982001)(59766001)(6806004)(51856001)(66066001)(80022001)(44976005)(4396001)(65816001)(83322001)(81542001)(19580395003)(46102001)(81342001)(79102001)(92566001)(49866001)(63696002)(71186001)(20776003)(16236675003)(69226001)(47736001)(53806001)(47976001)(512954002)(19300405004)(50986001)(74502001)(74662001)(81816001)(47446002)(31966008)(84326002)(33646001)(76796001)(76786001)(77096001)(15202345003)(87936001)(2656002)(93136001)(56816005)(90146001)(85306002)(81686001)(15975445006)(85852003)(83072002)(87266001)(74366001)(54356001)(74876001)(76176001)(74706001)(80976001)(54316002)(56776001)(76482001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUSR01MB589; H:hybrid.exchange.microsoft.com; CLIP:131.107.159.100; FPR:BC22FEDC.8E92849A.61DF1F38.84E9D171.201DE; InfoDomainNonexistentA:1; MX:1; LANG:en; X-Forefront-PRVS: 00922518D8 X-OriginatorOrg: exchange.microsoft.com Subject: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 19:36:20 -0000 --_000_5ab052bec168432abe90e4de00da53fbDFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor --_000_5ab052bec168432abe90e4de00da53fbDFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am looking at implementing better end to end secur= ity with IODEF documents.

 

For example, stronger access control on the data tha= n is possible via the restriction attribute, or stronger data origination a= uthentication by singing incidents.

 

In both cases there is  security relevant metad= ata which may apply to multiple incidents in an IODEF document. For example= with signed incidents, I want to include a set certificates to enable rely= ing parties to be able to validate the incident. I also want to optimize the set of certificates in the document = i.e. ensure I don’t include the same certificate multiple places in t= he document. The simplest way to achieve that is to have all the certificat= es in one place.  The logical place to store the set of certificates would be in the IODEF document class. This i= s equivalent to CMS, where the set of signing certificates are in the Signe= dData object not the SignerInfo object. However the IODEF document class la= cks the AdditionalData extension point preset in other IODEF classes.

 

Is it possible to add the optional AdditionalData el= ement to the v2 of the IODEF document class so it is possible to extend tha= t class the same way it is possible to extend other classes?

 

Trevor

--_000_5ab052bec168432abe90e4de00da53fbDFMTK5MBX1505exchangeco_-- From kathleen.moriarty@emc.com Wed Jan 15 11:42:00 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD751AE112 for ; Wed, 15 Jan 2014 11:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWb0nvJc-PZ2 for ; Wed, 15 Jan 2014 11:41:57 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBFD1AE0FD for ; Wed, 15 Jan 2014 11:41:57 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0FJfd3S028032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 14:41:42 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0FJfd3S028032 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389814902; bh=9MdLkj2lTqx2RFqL+ohk0eRmtC0=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=rsGJhwI17MXxWIFyZuIPysXa6yvhdOUomKpntAakqueDUP5FA7KnG2umrgi5ji8AK ag79wZWXtTtgiVUA7ASpfK6m4yRomDQVb6NHuAEQL79h8LPiZ1c55c3/luUYaEgxCT fYf49jfiNIPJBlLxs2t59FsW2ZpTHLQ4JRwmTukk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0FJfd3S028032 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 15 Jan 2014 14:41:27 -0500 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0FJfQJo018918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jan 2014 14:41:27 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Wed, 15 Jan 2014 14:41:26 -0500 From: "Moriarty, Kathleen" To: Trevor Freeman , "mile@ietf.org" Date: Wed, 15 Jan 2014 14:41:25 -0500 Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616wACLQsg Message-ID: References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.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_F5063677821E3B4F81ACFB7905573F2406584BA765MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 19:42:01 -0000 --_000_F5063677821E3B4F81ACFB7905573F2406584BA765MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, Could you elaborate on how this is different from or compliments the Digita= l signature and Encryption for IODEF in RID, RFC6545? I think that will be= helpful here. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 2:02 PM To: mile@ietf.org Subject: [mile] Extending the IODEF-Document class I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor --_000_F5063677821E3B4F81ACFB7905573F2406584BA765MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

Could you elaborate on how this is different= from or compliments the Digital signature and Encryption for IODEF in RID,= RFC6545?  I think that will be helpful here.

 

Thanks,

Kathleen

 <= /o:p>

From: mile [mailto:mile-= bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednes= day, January 15, 2014 2:02 PM
To: mile@ietf.org
Subject: [mile] Extending the IODEF-Document class

 

I am looki= ng at implementing better end to end security with IODEF documents.

 

For = example, stronger access control on the data than is possible via the restr= iction attribute, or stronger data origination authentication by singing in= cidents.

 

In both cases there is  security relevant metadata which = may apply to multiple incidents in an IODEF document. For example with sign= ed incidents, I want to include a set certificates to enable relying partie= s to be able to validate the incident. I also want to optimize the set of c= ertificates in the document i.e. ensure I don’t include the same cert= ificate multiple places in the document. The simplest way to achieve that i= s to have all the certificates in one place.  The logical place to sto= re the set of certificates would be in the IODEF document class. This is eq= uivalent to CMS, where the set of signing certificates are in the SignedDat= a object not the SignerInfo object. However the IODEF document class lacks = the AdditionalData extension point preset in other IODEF classes.

 

Is it p= ossible to add the optional AdditionalData element to the v2 of the IODEF d= ocument class so it is possible to extend that class the same way it is pos= sible to extend other classes?

&nbs= p;

Trevor

= --_000_F5063677821E3B4F81ACFB7905573F2406584BA765MX15Acorpemcc_-- From trevorf@exchange.microsoft.com Wed Jan 15 15:18:55 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD33C1AE22A for ; Wed, 15 Jan 2014 15:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMf8M5mHj8PF for ; Wed, 15 Jan 2014 15:18:52 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) by ietfa.amsl.com (Postfix) with ESMTP id D58331AE1DA for ; Wed, 15 Jan 2014 15:18:51 -0800 (PST) Received: from BLUSR01CA101.namsdf01.sdf.exchangelabs.com (10.255.124.146) by CH1SR01MB598.namsdf01.sdf.exchangelabs.com (10.255.157.35) with Microsoft SMTP Server (TLS) id 15.0.868.2; Wed, 15 Jan 2014 23:18:38 +0000 Received: from BY1FFOFD002.ffo.gbl (64.4.22.87) by BLUSR01CA101.outlook.office365.com (10.255.124.146) with Microsoft SMTP Server (TLS) id 15.0.868.2 via Frontend Transport; Wed, 15 Jan 2014 23:18:38 +0000 Received: from hybrid.exchange.microsoft.com (131.107.147.100) by BY1FFOFD002.mail.o365filtering.com (10.1.16.84) with Microsoft SMTP Server (TLS) id 15.0.847.5 via Frontend Transport; Wed, 15 Jan 2014 23:18:38 +0000 Received: from DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.23; Wed, 15 Jan 2014 15:17:54 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) with Microsoft SMTP Server (TLS) id 15.0.847.21; Wed, 15 Jan 2014 15:17:54 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.37]) with mapi id 15.00.0847.008; Wed, 15 Jan 2014 15:17:54 -0800 From: Trevor Freeman To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616wACLQsgAAXYzoA= Date: Wed, 15 Jan 2014 23:17:53 +0000 Message-ID: References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_eefebdc180a0485ab2c9df8904e9ba4bDFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.147.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(377454003)(199002)(189002)(164054003)(51444003)(83072002)(19580395003)(56816005)(90146001)(85852003)(80976001)(74706001)(79102001)(54356001)(80022001)(65816001)(81342001)(81542001)(69226001)(16236675003)(83322001)(19580405001)(44976005)(74876001)(59766001)(77982001)(92566001)(31966008)(47446002)(74502001)(6806004)(93136001)(74662001)(66066001)(71186001)(20776003)(63696002)(15202345003)(33646001)(87936001)(46102001)(4396001)(50986001)(2656002)(76482001)(54316002)(56776001)(81816001)(81686001)(19300405004)(512954002)(87266001)(51856001)(76796001)(85306002)(76786001)(84326002)(47736001)(47976001)(49866001)(74366001)(53806001)(15975445006)(77096001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CH1SR01MB598; H:hybrid.exchange.microsoft.com; CLIP:131.107.147.100; FPR:8C6CF2DE.AE221511.EDDBFDBB.46ECF961.20445; InfoDomainNonexistentA:1; MX:1; LANG:en; X-Forefront-PRVS: 00922518D8 X-OriginatorOrg: exchange.microsoft.com Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 23:18:56 -0000 --_000_eefebdc180a0485ab2c9df8904e9ba4bDFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kathleen, RID, to my mind offers a set of security serves targeting the transport and= authorization of the RID messages. The security of RID, handles the secur= ity associated with the processing of RID messages. For example, a RID mess= age could be a request for an action or a query for information. This messa= ges need security services because of the potential impact i.e. we don't wa= nt to repeat the mistake of SMTP where there is no authentication when emai= l is sent between MTAs. The timeframe of the security is around the request= and the response RID messages, i.e. send a RID request, get a RID response= , case closed. The RID security provides operational security for the funct= ioning of ecosystem. Information policies like information sharing or confidentiality agreements= relate to the actual content itself regardless of format and persists beyo= nd receiving the data hence apply to the content of the IODEF documents whe= rever they are. If I was a repository of incident data, I am receiving inci= dents which could be signed as proof of data origination from many sources.= If I receive a RID query message, I would authorize processing the request= based on the RID security then construct a new IODEF document containing a= ll the incidents covered by the request. The repository would sign the RID = response, but I want to retain the original signatures of the contributor o= f the incident data itself as it relates directly to the providence of the = data. If the incident data requires specific access control policies, thos= e too would need to be respected as part of the response and are orthogonal= to the confidentiality of the RID response as they can change incident by = incident. I see any IODEF security providing security services to support c= ompliance with the information policies be they regulatory policies, contra= ctual policies, information sharing agreements or whatever. Hope that helps. Trevor From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 15, 2014 11:41 AM To: Trevor Freeman; mile@ietf.org Subject: RE: Extending the IODEF-Document class Trevor, Could you elaborate on how this is different from or compliments the Digita= l signature and Encryption for IODEF in RID, RFC6545? I think that will be= helpful here. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 2:02 PM To: mile@ietf.org Subject: [mile] Extending the IODEF-Document class I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor --_000_eefebdc180a0485ab2c9df8904e9ba4bDFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kathleen,

 

RID, to my mind offers= a set of security serves targeting the transport and authorization of the = RID messages. The security of  RID, handles the security associated wi= th the processing of RID messages. For example, a RID message could be a request for an action or a query for information.= This messages need security services because of the potential impact i.e. = we don’t want to repeat the mistake of SMTP where there is no authent= ication when email is sent between MTAs. The timeframe of the security is around the request and the response RID m= essages, i.e. send a RID request, get a RID response, case closed. The RID = security provides operational security for the functioning of ecosystem.

 

Information policies l= ike information sharing or confidentiality agreements relate to the actual = content itself regardless of format and persists beyond receiving the data = hence apply to the content of the IODEF documents wherever they are. If I was a repository of incident data, I am = receiving incidents which could be signed as proof of data origination from= many sources. If I receive a RID query message, I would authorize processi= ng the request based on the RID security then construct a new IODEF document containing all the incidents = covered by the request. The repository would sign the RID response, but I w= ant to retain the original signatures of the contributor of the incident da= ta itself as it relates directly to the providence of the data.  If the incident data requires specifi= c access control policies, those too would need to be respected as part of = the response and are orthogonal to the confidentiality of the RID response = as they can change incident by incident. I see any IODEF security providing security services to support compliance= with the information policies be they regulatory policies, contractual pol= icies,  information sharing agreements or whatever.

 

Hope that helps.<= /o:p>

 

Trevor

 

From: Moriarty, Kathleen [mailto:kathleen.mor= iarty@emc.com]
Sent: Wednesday, January 15, 2014 11:41 AM
To: Trevor Freeman; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Trevor,

 

Could you elaborate on= how this is different from or compliments the Digital signature and Encryp= tion for IODEF in RID, RFC6545?  I think that will be helpful here.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 2:02 PM
To: mile@ietf.org
Subject: [mile] Extending the IODEF-Document class=

 

I am looking at implementing better end to end secur= ity with IODEF documents.

 

For example, stronger access control on the data tha= n is possible via the restriction attribute, or stronger data origination a= uthentication by singing incidents.

 

In both cases there is  security relevant metad= ata which may apply to multiple incidents in an IODEF document. For example= with signed incidents, I want to include a set certificates to enable rely= ing parties to be able to validate the incident. I also want to optimize the set of certificates in the document = i.e. ensure I don’t include the same certificate multiple places in t= he document. The simplest way to achieve that is to have all the certificat= es in one place.  The logical place to store the set of certificates would be in the IODEF document class. This i= s equivalent to CMS, where the set of signing certificates are in the Signe= dData object not the SignerInfo object. However the IODEF document class la= cks the AdditionalData extension point preset in other IODEF classes.

 

Is it possible to add the optional AdditionalData el= ement to the v2 of the IODEF document class so it is possible to extend tha= t class the same way it is possible to extend other classes?

 

Trevor

--_000_eefebdc180a0485ab2c9df8904e9ba4bDFMTK5MBX1505exchangeco_-- From pkampana@cisco.com Thu Jan 16 09:25:11 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69921AE316 for ; Thu, 16 Jan 2014 09:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsSsMk8jCuaY for ; Thu, 16 Jan 2014 09:25:08 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1571AE0DF for ; Thu, 16 Jan 2014 09:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15085; q=dns/txt; s=iport; t=1389893096; x=1391102696; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=m46Tg+4EVosRlNw/8GE56Z1orjJ7TOYnXvw31Wf/hqw=; b=V6tuQAudVJfaXTw00SpmcY7O+0gla+jEgnMn6A1NcWgYo8NaIKqxQYCJ PH7/Je53BCZT028u8TPcoS7h8+/ZZeK30zi1Svqnhq7xhwzTKWrGagOez cCMhufoRCephi+JRPrPJHgdGaYXHhz14eAWqWwporKDkLgdlj4HRNOXq1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAIIV2FKtJXHB/2dsb2JhbABZgkdEOFa7C4EOFnSCJQEBAQQtXAIBCBEEAQELHQcyFAkIAQEEARIIh3zEZheOHREBHzcBBoMegRQEqjiDLYFqBxcGHA X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208,217";a="13376601" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 16 Jan 2014 17:24:55 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0GHOtpj028298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jan 2014 17:24:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 16 Jan 2014 11:24:55 -0600 From: "Panos Kampanakis (pkampana)" To: Trevor Freeman , "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616wACLQsgAAXYzoAAJpMnYA== Date: Thu, 16 Jan 2014 17:24:54 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FAAB38Exmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:25:12 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750FAAB38Exmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authentication of the incident data themselves seems reasonable to address. But to solve that, would it be simpler for someone to sign the XML doc or = parts of it and include all the certs using XML DSIG (enveloped or detached= ) ? Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 6:18 PM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Kathleen, RID, to my mind offers a set of security serves targeting the transport and= authorization of the RID messages. The security of RID, handles the secur= ity associated with the processing of RID messages. For example, a RID mess= age could be a request for an action or a query for information. This messa= ges need security services because of the potential impact i.e. we don't wa= nt to repeat the mistake of SMTP where there is no authentication when emai= l is sent between MTAs. The timeframe of the security is around the request= and the response RID messages, i.e. send a RID request, get a RID response= , case closed. The RID security provides operational security for the funct= ioning of ecosystem. Information policies like information sharing or confidentiality agreements= relate to the actual content itself regardless of format and persists beyo= nd receiving the data hence apply to the content of the IODEF documents whe= rever they are. If I was a repository of incident data, I am receiving inci= dents which could be signed as proof of data origination from many sources.= If I receive a RID query message, I would authorize processing the request= based on the RID security then construct a new IODEF document containing a= ll the incidents covered by the request. The repository would sign the RID = response, but I want to retain the original signatures of the contributor o= f the incident data itself as it relates directly to the providence of the = data. If the incident data requires specific access control policies, thos= e too would need to be respected as part of the response and are orthogonal= to the confidentiality of the RID response as they can change incident by = incident. I see any IODEF security providing security services to support c= ompliance with the information policies be they regulatory policies, contra= ctual policies, information sharing agreements or whatever. Hope that helps. Trevor From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 15, 2014 11:41 AM To: Trevor Freeman; mile@ietf.org Subject: RE: Extending the IODEF-Document class Trevor, Could you elaborate on how this is different from or compliments the Digita= l signature and Encryption for IODEF in RID, RFC6545? I think that will be= helpful here. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 2:02 PM To: mile@ietf.org Subject: [mile] Extending the IODEF-Document class I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor --_000_1C9F17D1873AFA47A969C4DD98F98A750FAAB38Exmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authentication of the = incident data themselves seems reasonable to address.

But to solve that, &nb= sp;would it be simpler for someone to sign the XML doc or parts of it and i= nclude all the certs using XML DSIG (enveloped or detached)  ?

Panos

 

 

 

 

From: mile [ma= ilto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 6:18 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] Extending the IODEF-Document class

 

Hi Kathleen,

 

RID, to my mind offers= a set of security serves targeting the transport and authorization of the = RID messages. The security of  RID, handles the security associated wi= th the processing of RID messages. For example, a RID message could be a request for an action or a query for information.= This messages need security services because of the potential impact i.e. = we don’t want to repeat the mistake of SMTP where there is no authent= ication when email is sent between MTAs. The timeframe of the security is around the request and the response RID m= essages, i.e. send a RID request, get a RID response, case closed. The RID = security provides operational security for the functioning of ecosystem.

 

Information policies l= ike information sharing or confidentiality agreements relate to the actual = content itself regardless of format and persists beyond receiving the data = hence apply to the content of the IODEF documents wherever they are. If I was a repository of incident data, I am = receiving incidents which could be signed as proof of data origination from= many sources. If I receive a RID query message, I would authorize processi= ng the request based on the RID security then construct a new IODEF document containing all the incidents = covered by the request. The repository would sign the RID response, but I w= ant to retain the original signatures of the contributor of the incident da= ta itself as it relates directly to the providence of the data.  If the incident data requires specifi= c access control policies, those too would need to be respected as part of = the response and are orthogonal to the confidentiality of the RID response = as they can change incident by incident. I see any IODEF security providing security services to support compliance= with the information policies be they regulatory policies, contractual pol= icies,  information sharing agreements or whatever.

 

Hope that helps.<= /o:p>

 

Trevor

 

From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: Wednesday, January 15, 2014 11:41 AM
To: Trevor Freeman; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Trevor,

 

Could you elaborate on= how this is different from or compliments the Digital signature and Encryp= tion for IODEF in RID, RFC6545?  I think that will be helpful here.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 2:02 PM
To: mile@ietf.org
Subject: [mile] Extending the IODEF-Document class=

 

I am looking at implementing better end to end secur= ity with IODEF documents.

 

For example, stronger access control on the data tha= n is possible via the restriction attribute, or stronger data origination a= uthentication by singing incidents.

 

In both cases there is  security relevant metad= ata which may apply to multiple incidents in an IODEF document. For example= with signed incidents, I want to include a set certificates to enable rely= ing parties to be able to validate the incident. I also want to optimize the set of certificates in the document = i.e. ensure I don’t include the same certificate multiple places in t= he document. The simplest way to achieve that is to have all the certificat= es in one place.  The logical place to store the set of certificates would be in the IODEF document class. This i= s equivalent to CMS, where the set of signing certificates are in the Signe= dData object not the SignerInfo object. However the IODEF document class la= cks the AdditionalData extension point preset in other IODEF classes.

 

Is it possible to add the optional AdditionalData el= ement to the v2 of the IODEF document class so it is possible to extend tha= t class the same way it is possible to extend other classes?

 

Trevor

--_000_1C9F17D1873AFA47A969C4DD98F98A750FAAB38Exmbrcdx10ciscoc_-- From kathleen.moriarty@emc.com Thu Jan 16 09:33:15 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B3A1AE132 for ; Thu, 16 Jan 2014 09:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZLrLX4ELmdk for ; Thu, 16 Jan 2014 09:33:12 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 538371AE0FC for ; Thu, 16 Jan 2014 09:33:12 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0GHWtn2028734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2014 12:32:56 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0GHWtn2028734 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389893576; bh=8hi044tNYU/Y3aVJkOM/FB9Camw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=YXoO5KGrXUff7LKYrzSqitRd2mxvBmdd4OVrNSZzVJ33ry/UJgYFlMgPKpiwOI+TY wTv7v5vsdJHp8+XgF1sZrvg93KhOfbx5/KzsdOxR2ykERSpnxb6SO5kbQ5tzBEb58u n1oOo2oD1u4gykuZXGlzRBzK9EktpSBXnVgVdMD0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0GHWtn2028734 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Thu, 16 Jan 2014 12:32:42 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0GHWf5N029422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jan 2014 12:32:41 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub33.corp.emc.com ([::1]) with mapi; Thu, 16 Jan 2014 12:32:41 -0500 From: "Moriarty, Kathleen" To: "Panos Kampanakis (pkampana)" Date: Thu, 16 Jan 2014 12:32:41 -0500 Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8S4PUdyRYo0joMSGi7iZ7SiAC3hg== Message-ID: <8CB00DC6-7AC7-4AB2-A592-8974705EC757@emc.com> References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.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_8CB00DC67AC74AB2A5928974705EC757emccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:33:15 -0000 --_000_8CB00DC67AC74AB2A5928974705EC757emccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBpcyBkZXNjcmliZWQgaW4gUkZDNjU0NSBzZWN0aW9uIDkuMS4gQW5kIGNvdWxkIGJlIHVz ZWQgd2l0aG91dCB0aGUgZnVsbCBSRkMgZ2V0dGluZyBpbXBsZW1lbnRlZC4gVHJldm9yJ3Mgd29y ayBpcyBhIGRpZmZlcmVudCwgaXQgbWF5IGJlIGhlbHBmdWwgdG8gaGVhciBmcm9tIGhpbSBvbiB0 aGUgdmFsdWUgb2YgaGlzIHdvcmsgYWJvdmUgd2hhdCBoYXMgYmVlbiBkb25lIGFscmVhZHkuDQoN ClRoYW5rcywNCkthdGhsZWVuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gSmFuIDE2LCAy MDE0LCBhdCAxMjoyNyBQTSwgIlBhbm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKSIgPHBrYW1wYW5h QGNpc2NvLmNvbTxtYWlsdG86cGthbXBhbmFAY2lzY28uY29tPj4gd3JvdGU6DQoNCkF1dGhlbnRp Y2F0aW9uIG9mIHRoZSBpbmNpZGVudCBkYXRhIHRoZW1zZWx2ZXMgc2VlbXMgcmVhc29uYWJsZSB0 byBhZGRyZXNzLg0KQnV0IHRvIHNvbHZlIHRoYXQsICB3b3VsZCBpdCBiZSBzaW1wbGVyIGZvciBz b21lb25lIHRvIHNpZ24gdGhlIFhNTCBkb2Mgb3IgcGFydHMgb2YgaXQgYW5kIGluY2x1ZGUgYWxs IHRoZSBjZXJ0cyB1c2luZyBYTUwgRFNJRyAoZW52ZWxvcGVkIG9yIGRldGFjaGVkKSAgPw0KUGFu b3MNCg0KDQoNCg0KRnJvbTogbWlsZSBbbWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFRyZXZvciBGcmVlbWFuDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTUsIDIw MTQgNjoxOCBQTQ0KVG86IE1vcmlhcnR5LCBLYXRobGVlbjsgbWlsZUBpZXRmLm9yZzxtYWlsdG86 bWlsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbWlsZV0gRXh0ZW5kaW5nIHRoZSBJT0RFRi1E b2N1bWVudCBjbGFzcw0KDQpIaSBLYXRobGVlbiwNCg0KUklELCB0byBteSBtaW5kIG9mZmVycyBh IHNldCBvZiBzZWN1cml0eSBzZXJ2ZXMgdGFyZ2V0aW5nIHRoZSB0cmFuc3BvcnQgYW5kIGF1dGhv cml6YXRpb24gb2YgdGhlIFJJRCBtZXNzYWdlcy4gVGhlIHNlY3VyaXR5IG9mICBSSUQsIGhhbmRs ZXMgdGhlIHNlY3VyaXR5IGFzc29jaWF0ZWQgd2l0aCB0aGUgcHJvY2Vzc2luZyBvZiBSSUQgbWVz c2FnZXMuIEZvciBleGFtcGxlLCBhIFJJRCBtZXNzYWdlIGNvdWxkIGJlIGEgcmVxdWVzdCBmb3Ig YW4gYWN0aW9uIG9yIGEgcXVlcnkgZm9yIGluZm9ybWF0aW9uLiBUaGlzIG1lc3NhZ2VzIG5lZWQg c2VjdXJpdHkgc2VydmljZXMgYmVjYXVzZSBvZiB0aGUgcG90ZW50aWFsIGltcGFjdCBpLmUuIHdl IGRvbuKAmXQgd2FudCB0byByZXBlYXQgdGhlIG1pc3Rha2Ugb2YgU01UUCB3aGVyZSB0aGVyZSBp cyBubyBhdXRoZW50aWNhdGlvbiB3aGVuIGVtYWlsIGlzIHNlbnQgYmV0d2VlbiBNVEFzLiBUaGUg dGltZWZyYW1lIG9mIHRoZSBzZWN1cml0eSBpcyBhcm91bmQgdGhlIHJlcXVlc3QgYW5kIHRoZSBy ZXNwb25zZSBSSUQgbWVzc2FnZXMsIGkuZS4gc2VuZCBhIFJJRCByZXF1ZXN0LCBnZXQgYSBSSUQg cmVzcG9uc2UsIGNhc2UgY2xvc2VkLiBUaGUgUklEIHNlY3VyaXR5IHByb3ZpZGVzIG9wZXJhdGlv bmFsIHNlY3VyaXR5IGZvciB0aGUgZnVuY3Rpb25pbmcgb2YgZWNvc3lzdGVtLg0KDQpJbmZvcm1h dGlvbiBwb2xpY2llcyBsaWtlIGluZm9ybWF0aW9uIHNoYXJpbmcgb3IgY29uZmlkZW50aWFsaXR5 IGFncmVlbWVudHMgcmVsYXRlIHRvIHRoZSBhY3R1YWwgY29udGVudCBpdHNlbGYgcmVnYXJkbGVz cyBvZiBmb3JtYXQgYW5kIHBlcnNpc3RzIGJleW9uZCByZWNlaXZpbmcgdGhlIGRhdGEgaGVuY2Ug YXBwbHkgdG8gdGhlIGNvbnRlbnQgb2YgdGhlIElPREVGIGRvY3VtZW50cyB3aGVyZXZlciB0aGV5 IGFyZS4gSWYgSSB3YXMgYSByZXBvc2l0b3J5IG9mIGluY2lkZW50IGRhdGEsIEkgYW0gcmVjZWl2 aW5nIGluY2lkZW50cyB3aGljaCBjb3VsZCBiZSBzaWduZWQgYXMgcHJvb2Ygb2YgZGF0YSBvcmln aW5hdGlvbiBmcm9tIG1hbnkgc291cmNlcy4gSWYgSSByZWNlaXZlIGEgUklEIHF1ZXJ5IG1lc3Nh Z2UsIEkgd291bGQgYXV0aG9yaXplIHByb2Nlc3NpbmcgdGhlIHJlcXVlc3QgYmFzZWQgb24gdGhl IFJJRCBzZWN1cml0eSB0aGVuIGNvbnN0cnVjdCBhIG5ldyBJT0RFRiBkb2N1bWVudCBjb250YWlu aW5nIGFsbCB0aGUgaW5jaWRlbnRzIGNvdmVyZWQgYnkgdGhlIHJlcXVlc3QuIFRoZSByZXBvc2l0 b3J5IHdvdWxkIHNpZ24gdGhlIFJJRCByZXNwb25zZSwgYnV0IEkgd2FudCB0byByZXRhaW4gdGhl IG9yaWdpbmFsIHNpZ25hdHVyZXMgb2YgdGhlIGNvbnRyaWJ1dG9yIG9mIHRoZSBpbmNpZGVudCBk YXRhIGl0c2VsZiBhcyBpdCByZWxhdGVzIGRpcmVjdGx5IHRvIHRoZSBwcm92aWRlbmNlIG9mIHRo ZSBkYXRhLiAgSWYgdGhlIGluY2lkZW50IGRhdGEgcmVxdWlyZXMgc3BlY2lmaWMgYWNjZXNzIGNv bnRyb2wgcG9saWNpZXMsIHRob3NlIHRvbyB3b3VsZCBuZWVkIHRvIGJlIHJlc3BlY3RlZCBhcyBw YXJ0IG9mIHRoZSByZXNwb25zZSBhbmQgYXJlIG9ydGhvZ29uYWwgdG8gdGhlIGNvbmZpZGVudGlh bGl0eSBvZiB0aGUgUklEIHJlc3BvbnNlIGFzIHRoZXkgY2FuIGNoYW5nZSBpbmNpZGVudCBieSBp bmNpZGVudC4gSSBzZWUgYW55IElPREVGIHNlY3VyaXR5IHByb3ZpZGluZyBzZWN1cml0eSBzZXJ2 aWNlcyB0byBzdXBwb3J0IGNvbXBsaWFuY2Ugd2l0aCB0aGUgaW5mb3JtYXRpb24gcG9saWNpZXMg YmUgdGhleSByZWd1bGF0b3J5IHBvbGljaWVzLCBjb250cmFjdHVhbCBwb2xpY2llcywgIGluZm9y bWF0aW9uIHNoYXJpbmcgYWdyZWVtZW50cyBvciB3aGF0ZXZlci4NCg0KSG9wZSB0aGF0IGhlbHBz Lg0KDQpUcmV2b3INCg0KRnJvbTogTW9yaWFydHksIEthdGhsZWVuIFttYWlsdG86a2F0aGxlZW4u bW9yaWFydHlAZW1jLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxNSwgMjAxNCAxMTo0 MSBBTQ0KVG86IFRyZXZvciBGcmVlbWFuOyBtaWxlQGlldGYub3JnPG1haWx0bzptaWxlQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IEV4dGVuZGluZyB0aGUgSU9ERUYtRG9jdW1lbnQgY2xhc3MNCg0K VHJldm9yLA0KDQpDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIGhvdyB0aGlzIGlzIGRpZmZlcmVudCBm cm9tIG9yIGNvbXBsaW1lbnRzIHRoZSBEaWdpdGFsIHNpZ25hdHVyZSBhbmQgRW5jcnlwdGlvbiBm b3IgSU9ERUYgaW4gUklELCBSRkM2NTQ1PyAgSSB0aGluayB0aGF0IHdpbGwgYmUgaGVscGZ1bCBo ZXJlLg0KDQpUaGFua3MsDQpLYXRobGVlbg0KDQpGcm9tOiBtaWxlIFttYWlsdG86bWlsZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVHJldm9yIEZyZWVtYW4NClNlbnQ6IFdlZG5lc2Rh eSwgSmFudWFyeSAxNSwgMjAxNCAyOjAyIFBNDQpUbzogbWlsZUBpZXRmLm9yZzxtYWlsdG86bWls ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFttaWxlXSBFeHRlbmRpbmcgdGhlIElPREVGLURvY3VtZW50 IGNsYXNzDQoNCkkgYW0gbG9va2luZyBhdCBpbXBsZW1lbnRpbmcgYmV0dGVyIGVuZCB0byBlbmQg c2VjdXJpdHkgd2l0aCBJT0RFRiBkb2N1bWVudHMuDQoNCkZvciBleGFtcGxlLCBzdHJvbmdlciBh Y2Nlc3MgY29udHJvbCBvbiB0aGUgZGF0YSB0aGFuIGlzIHBvc3NpYmxlIHZpYSB0aGUgcmVzdHJp Y3Rpb24gYXR0cmlidXRlLCBvciBzdHJvbmdlciBkYXRhIG9yaWdpbmF0aW9uIGF1dGhlbnRpY2F0 aW9uIGJ5IHNpbmdpbmcgaW5jaWRlbnRzLg0KDQpJbiBib3RoIGNhc2VzIHRoZXJlIGlzICBzZWN1 cml0eSByZWxldmFudCBtZXRhZGF0YSB3aGljaCBtYXkgYXBwbHkgdG8gbXVsdGlwbGUgaW5jaWRl bnRzIGluIGFuIElPREVGIGRvY3VtZW50LiBGb3IgZXhhbXBsZSB3aXRoIHNpZ25lZCBpbmNpZGVu dHMsIEkgd2FudCB0byBpbmNsdWRlIGEgc2V0IGNlcnRpZmljYXRlcyB0byBlbmFibGUgcmVseWlu ZyBwYXJ0aWVzIHRvIGJlIGFibGUgdG8gdmFsaWRhdGUgdGhlIGluY2lkZW50LiBJIGFsc28gd2Fu dCB0byBvcHRpbWl6ZSB0aGUgc2V0IG9mIGNlcnRpZmljYXRlcyBpbiB0aGUgZG9jdW1lbnQgaS5l LiBlbnN1cmUgSSBkb27igJl0IGluY2x1ZGUgdGhlIHNhbWUgY2VydGlmaWNhdGUgbXVsdGlwbGUg cGxhY2VzIGluIHRoZSBkb2N1bWVudC4gVGhlIHNpbXBsZXN0IHdheSB0byBhY2hpZXZlIHRoYXQg aXMgdG8gaGF2ZSBhbGwgdGhlIGNlcnRpZmljYXRlcyBpbiBvbmUgcGxhY2UuICBUaGUgbG9naWNh bCBwbGFjZSB0byBzdG9yZSB0aGUgc2V0IG9mIGNlcnRpZmljYXRlcyB3b3VsZCBiZSBpbiB0aGUg SU9ERUYgZG9jdW1lbnQgY2xhc3MuIFRoaXMgaXMgZXF1aXZhbGVudCB0byBDTVMsIHdoZXJlIHRo ZSBzZXQgb2Ygc2lnbmluZyBjZXJ0aWZpY2F0ZXMgYXJlIGluIHRoZSBTaWduZWREYXRhIG9iamVj dCBub3QgdGhlIFNpZ25lckluZm8gb2JqZWN0LiBIb3dldmVyIHRoZSBJT0RFRiBkb2N1bWVudCBj bGFzcyBsYWNrcyB0aGUgQWRkaXRpb25hbERhdGEgZXh0ZW5zaW9uIHBvaW50IHByZXNldCBpbiBv dGhlciBJT0RFRiBjbGFzc2VzLg0KDQpJcyBpdCBwb3NzaWJsZSB0byBhZGQgdGhlIG9wdGlvbmFs IEFkZGl0aW9uYWxEYXRhIGVsZW1lbnQgdG8gdGhlIHYyIG9mIHRoZSBJT0RFRiBkb2N1bWVudCBj bGFzcyBzbyBpdCBpcyBwb3NzaWJsZSB0byBleHRlbmQgdGhhdCBjbGFzcyB0aGUgc2FtZSB3YXkg aXQgaXMgcG9zc2libGUgdG8gZXh0ZW5kIG90aGVyIGNsYXNzZXM/DQoNClRyZXZvcg0K --_000_8CB00DC67AC74AB2A5928974705EC757emccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+VGhhdCBp cyBkZXNjcmliZWQgaW4gUkZDNjU0NSBzZWN0aW9uIDkuMS4gQW5kIGNvdWxkIGJlIHVzZWQgd2l0 aG91dCB0aGUgZnVsbCBSRkMgZ2V0dGluZyBpbXBsZW1lbnRlZC4gVHJldm9yJ3Mgd29yayBpcyBh IGRpZmZlcmVudCwgaXQgbWF5IGJlIGhlbHBmdWwgdG8gaGVhciBmcm9tIGhpbSBvbiB0aGUgdmFs dWUgb2YgaGlzIHdvcmsgYWJvdmUgd2hhdCBoYXMgYmVlbiBkb25lIGFscmVhZHkuPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5UaGFua3MsPC9kaXY+PGRpdj5LYXRobGVlbiZuYnNwOzxicj48YnI+ U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2PjxkaXY+PGJyPk9uIEphbiAxNiwgMjAxNCwgYXQgMTI6 MjcgUE0sICJQYW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkiICZsdDs8YSBocmVmPSJtYWlsdG86 cGthbXBhbmFAY2lzY28uY29tIj5wa2FtcGFuYUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+DQo8bWV0YSBodHRwLWVxdWl2 PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1XaW5kb3dzLTEyNTIi Pg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmls dGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KDQoNCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXV0aGVudGljYXRpb24gb2YgdGhlIGluY2lkZW50 IGRhdGEgdGhlbXNlbHZlcyBzZWVtcyByZWFzb25hYmxlIHRvIGFkZHJlc3MuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+QnV0IHRvIHNvbHZlIHRoYXQsICZuYnNwO3dvdWxkIGl0IGJlIHNpbXBsZXIgZm9yIHNv bWVvbmUgdG8gc2lnbiB0aGUgWE1MIGRvYyBvciBwYXJ0cyBvZiBpdCBhbmQgaW5jbHVkZSBhbGwg dGhlIGNlcnRzIHVzaW5nIFhNTCBEU0lHIChlbnZlbG9wZWQgb3IgZGV0YWNoZWQpICZuYnNwOz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+UGFub3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtaWxlIFs8YSBocmVmPSJtYWlsdG86 bWlsZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+VHJldm9yIEZyZWVtYW48YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBKYW51YXJ5IDE1LCAyMDE0IDY6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IE1vcmlhcnR5 LCBLYXRobGVlbjsgPGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPm1pbGVAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWlsZV0gRXh0ZW5kaW5nIHRoZSBJT0RFRi1E b2N1bWVudCBjbGFzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBLYXRobGVlbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJJRCwgdG8gbXkgbWluZCBvZmZlcnMgYSBzZXQgb2Yg c2VjdXJpdHkgc2VydmVzIHRhcmdldGluZyB0aGUgdHJhbnNwb3J0IGFuZCBhdXRob3JpemF0aW9u IG9mIHRoZSBSSUQgbWVzc2FnZXMuIFRoZSBzZWN1cml0eSBvZiAmbmJzcDtSSUQsIGhhbmRsZXMg dGhlIHNlY3VyaXR5IGFzc29jaWF0ZWQgd2l0aCB0aGUgcHJvY2Vzc2luZyBvZiBSSUQgbWVzc2Fn ZXMuIEZvciBleGFtcGxlLA0KIGEgUklEIG1lc3NhZ2UgY291bGQgYmUgYSByZXF1ZXN0IGZvciBh biBhY3Rpb24gb3IgYSBxdWVyeSBmb3IgaW5mb3JtYXRpb24uIFRoaXMgbWVzc2FnZXMgbmVlZCBz ZWN1cml0eSBzZXJ2aWNlcyBiZWNhdXNlIG9mIHRoZSBwb3RlbnRpYWwgaW1wYWN0IGkuZS4gd2Ug ZG9u4oCZdCB3YW50IHRvIHJlcGVhdCB0aGUgbWlzdGFrZSBvZiBTTVRQIHdoZXJlIHRoZXJlIGlz IG5vIGF1dGhlbnRpY2F0aW9uIHdoZW4gZW1haWwgaXMgc2VudCBiZXR3ZWVuIE1UQXMuDQogVGhl IHRpbWVmcmFtZSBvZiB0aGUgc2VjdXJpdHkgaXMgYXJvdW5kIHRoZSByZXF1ZXN0IGFuZCB0aGUg cmVzcG9uc2UgUklEIG1lc3NhZ2VzLCBpLmUuIHNlbmQgYSBSSUQgcmVxdWVzdCwgZ2V0IGEgUklE IHJlc3BvbnNlLCBjYXNlIGNsb3NlZC4gVGhlIFJJRCBzZWN1cml0eSBwcm92aWRlcyBvcGVyYXRp b25hbCBzZWN1cml0eSBmb3IgdGhlIGZ1bmN0aW9uaW5nIG9mIGVjb3N5c3RlbS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW5mb3JtYXRpb24gcG9saWNpZXMgbGlrZSBp bmZvcm1hdGlvbiBzaGFyaW5nIG9yIGNvbmZpZGVudGlhbGl0eSBhZ3JlZW1lbnRzIHJlbGF0ZSB0 byB0aGUgYWN0dWFsIGNvbnRlbnQgaXRzZWxmIHJlZ2FyZGxlc3Mgb2YgZm9ybWF0IGFuZCBwZXJz aXN0cyBiZXlvbmQgcmVjZWl2aW5nIHRoZSBkYXRhIGhlbmNlIGFwcGx5IHRvIHRoZSBjb250ZW50 IG9mIHRoZSBJT0RFRg0KIGRvY3VtZW50cyB3aGVyZXZlciB0aGV5IGFyZS4gSWYgSSB3YXMgYSBy ZXBvc2l0b3J5IG9mIGluY2lkZW50IGRhdGEsIEkgYW0gcmVjZWl2aW5nIGluY2lkZW50cyB3aGlj aCBjb3VsZCBiZSBzaWduZWQgYXMgcHJvb2Ygb2YgZGF0YSBvcmlnaW5hdGlvbiBmcm9tIG1hbnkg c291cmNlcy4gSWYgSSByZWNlaXZlIGEgUklEIHF1ZXJ5IG1lc3NhZ2UsIEkgd291bGQgYXV0aG9y aXplIHByb2Nlc3NpbmcgdGhlIHJlcXVlc3QgYmFzZWQgb24gdGhlIFJJRA0KIHNlY3VyaXR5IHRo ZW4gY29uc3RydWN0IGEgbmV3IElPREVGIGRvY3VtZW50IGNvbnRhaW5pbmcgYWxsIHRoZSBpbmNp ZGVudHMgY292ZXJlZCBieSB0aGUgcmVxdWVzdC4gVGhlIHJlcG9zaXRvcnkgd291bGQgc2lnbiB0 aGUgUklEIHJlc3BvbnNlLCBidXQgSSB3YW50IHRvIHJldGFpbiB0aGUgb3JpZ2luYWwgc2lnbmF0 dXJlcyBvZiB0aGUgY29udHJpYnV0b3Igb2YgdGhlIGluY2lkZW50IGRhdGEgaXRzZWxmIGFzIGl0 IHJlbGF0ZXMgZGlyZWN0bHkNCiB0byB0aGUgcHJvdmlkZW5jZSBvZiB0aGUgZGF0YS4gJm5ic3A7 SWYgdGhlIGluY2lkZW50IGRhdGEgcmVxdWlyZXMgc3BlY2lmaWMgYWNjZXNzIGNvbnRyb2wgcG9s aWNpZXMsIHRob3NlIHRvbyB3b3VsZCBuZWVkIHRvIGJlIHJlc3BlY3RlZCBhcyBwYXJ0IG9mIHRo ZSByZXNwb25zZSBhbmQgYXJlIG9ydGhvZ29uYWwgdG8gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0 aGUgUklEIHJlc3BvbnNlIGFzIHRoZXkgY2FuIGNoYW5nZSBpbmNpZGVudCBieSBpbmNpZGVudC4N CiBJIHNlZSBhbnkgSU9ERUYgc2VjdXJpdHkgcHJvdmlkaW5nIHNlY3VyaXR5IHNlcnZpY2VzIHRv IHN1cHBvcnQgY29tcGxpYW5jZSB3aXRoIHRoZSBpbmZvcm1hdGlvbiBwb2xpY2llcyBiZSB0aGV5 IHJlZ3VsYXRvcnkgcG9saWNpZXMsIGNvbnRyYWN0dWFsIHBvbGljaWVzLCAmbmJzcDtpbmZvcm1h dGlvbiBzaGFyaW5nIGFncmVlbWVudHMgb3Igd2hhdGV2ZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkhvcGUgdGhhdCBoZWxwcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlRyZXZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IE1vcmlhcnR5LCBLYXRobGVlbiBbPGEgaHJlZj0ibWFpbHRv OmthdGhsZWVuLm1vcmlhcnR5QGVtYy5jb20iPm1haWx0bzprYXRobGVlbi5tb3JpYXJ0eUBlbWMu Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMTUsIDIwMTQg MTE6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IFRyZXZvciBGcmVlbWFuOyA8YSBocmVmPSJtYWlsdG86 bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IEV4dGVuZGluZyB0aGUgSU9ERUYtRG9jdW1lbnQgY2xhc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UcmV2b3IsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Db3VsZCB5b3UgZWxhYm9yYXRlIG9u IGhvdyB0aGlzIGlzIGRpZmZlcmVudCBmcm9tIG9yIGNvbXBsaW1lbnRzIHRoZSBEaWdpdGFsIHNp Z25hdHVyZSBhbmQgRW5jcnlwdGlvbiBmb3IgSU9ERUYgaW4gUklELCBSRkM2NTQ1PyZuYnNwOyBJ IHRoaW5rIHRoYXQgd2lsbCBiZSBoZWxwZnVsIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkthdGhsZWVuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWlsZSBb PGEgaHJlZj0ibWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1pbGUtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRyZXZvciBGcmVlbWFuPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAxNSwgMjAxNCAyOjAyIFBNPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21pbGVdIEV4dGVuZGluZyB0aGUgSU9ERUYtRG9jdW1lbnQg Y2xhc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFt IGxvb2tpbmcgYXQgaW1wbGVtZW50aW5nIGJldHRlciBlbmQgdG8gZW5kIHNlY3VyaXR5IHdpdGgg SU9ERUYgZG9jdW1lbnRzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlLCBz dHJvbmdlciBhY2Nlc3MgY29udHJvbCBvbiB0aGUgZGF0YSB0aGFuIGlzIHBvc3NpYmxlIHZpYSB0 aGUgcmVzdHJpY3Rpb24gYXR0cmlidXRlLCBvciBzdHJvbmdlciBkYXRhIG9yaWdpbmF0aW9uIGF1 dGhlbnRpY2F0aW9uIGJ5IHNpbmdpbmcgaW5jaWRlbnRzLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIGJvdGggY2FzZXMgdGhlcmUgaXMmbmJzcDsgc2VjdXJpdHkgcmVsZXZhbnQgbWV0YWRh dGEgd2hpY2ggbWF5IGFwcGx5IHRvIG11bHRpcGxlIGluY2lkZW50cyBpbiBhbiBJT0RFRiBkb2N1 bWVudC4gRm9yIGV4YW1wbGUgd2l0aCBzaWduZWQgaW5jaWRlbnRzLCBJIHdhbnQgdG8gaW5jbHVk ZSBhIHNldCBjZXJ0aWZpY2F0ZXMgdG8gZW5hYmxlIHJlbHlpbmcgcGFydGllcyB0byBiZSBhYmxl IHRvIHZhbGlkYXRlIHRoZQ0KIGluY2lkZW50LiBJIGFsc28gd2FudCB0byBvcHRpbWl6ZSB0aGUg c2V0IG9mIGNlcnRpZmljYXRlcyBpbiB0aGUgZG9jdW1lbnQgaS5lLiBlbnN1cmUgSSBkb27igJl0 IGluY2x1ZGUgdGhlIHNhbWUgY2VydGlmaWNhdGUgbXVsdGlwbGUgcGxhY2VzIGluIHRoZSBkb2N1 bWVudC4gVGhlIHNpbXBsZXN0IHdheSB0byBhY2hpZXZlIHRoYXQgaXMgdG8gaGF2ZSBhbGwgdGhl IGNlcnRpZmljYXRlcyBpbiBvbmUgcGxhY2UuICZuYnNwO1RoZSBsb2dpY2FsIHBsYWNlIHRvDQog c3RvcmUgdGhlIHNldCBvZiBjZXJ0aWZpY2F0ZXMgd291bGQgYmUgaW4gdGhlIElPREVGIGRvY3Vt ZW50IGNsYXNzLiBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gQ01TLCB3aGVyZSB0aGUgc2V0IG9mIHNp Z25pbmcgY2VydGlmaWNhdGVzIGFyZSBpbiB0aGUgU2lnbmVkRGF0YSBvYmplY3Qgbm90IHRoZSBT aWduZXJJbmZvIG9iamVjdC4gSG93ZXZlciB0aGUgSU9ERUYgZG9jdW1lbnQgY2xhc3MgbGFja3Mg dGhlIEFkZGl0aW9uYWxEYXRhIGV4dGVuc2lvbg0KIHBvaW50IHByZXNldCBpbiBvdGhlciBJT0RF RiBjbGFzc2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBpdCBwb3NzaWJsZSB0byBhZGQg dGhlIG9wdGlvbmFsIEFkZGl0aW9uYWxEYXRhIGVsZW1lbnQgdG8gdGhlIHYyIG9mIHRoZSBJT0RF RiBkb2N1bWVudCBjbGFzcyBzbyBpdCBpcyBwb3NzaWJsZSB0byBleHRlbmQgdGhhdCBjbGFzcyB0 aGUgc2FtZSB3YXkgaXQgaXMgcG9zc2libGUgdG8gZXh0ZW5kIG90aGVyIGNsYXNzZXM/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRyZXZvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQoNCg0KPC9k aXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_8CB00DC67AC74AB2A5928974705EC757emccom_-- From rdd@cert.org Thu Jan 16 10:56:55 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445041A1F56 for ; Thu, 16 Jan 2014 10:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai8Nz9N-SUat for ; Thu, 16 Jan 2014 10:56:53 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA6F1A1F4E for ; Thu, 16 Jan 2014 10:56:53 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0GIudu3017656 for ; Thu, 16 Jan 2014 13:56:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389898599; bh=WxEXKEZIGp1r+V/W1oWcS/YTJGiUj+VPTmbddkxD7r0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=A485C/JsduldifBC4CwCmRrgBE1gqhRlohystoRx2DYmMCZvcoCzXgGSZDY4nYhZT exakV/HoUmSEY4zkOobFh8hH6LtAdnOtRcjfWRKMTIy5P5Mo+4b8DeMttHuISVZ2fb wGXnaTLMsBZ1sWXQkx4nWIaFlFAt7K5cSNAmbmvo= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0GIucFk021750 for ; Thu, 16 Jan 2014 13:56:39 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 16 Jan 2014 13:56:38 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: An alternative way to represent a URL Thread-Index: Ac8SJVS/DbLXXY1tToONjFAmsI3aZQ== Date: Thu, 16 Jan 2014 18:56:37 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C149B2@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] An alternative way to represent a URL X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 18:56:55 -0000 Hello, The schema definition of the Node class in -03 of 5070bis has the following= comment in it: [begin schema snippet] [end schema snippet] This proposal would provide an alternative to the current approach of repre= senting a URI for a Node using Address@category=3D"site-uri" (e.g., http://www.example.com/sites/foo). I don't know the origin or rational for this comment. Could anyone shed li= ght on why we'd want to change the current representation? Roman=20 From trevorf@exchange.microsoft.com Thu Jan 16 11:28:56 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4524C1AC404 for ; Thu, 16 Jan 2014 11:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuqLwqpmLYUp for ; Thu, 16 Jan 2014 11:28:51 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1F91A1F66 for ; Thu, 16 Jan 2014 11:28:51 -0800 (PST) Received: from CH1SR01CA101.namsdf01.sdf.exchangelabs.com (10.255.157.18) by BY2SR01MB595.namsdf01.sdf.exchangelabs.com (10.255.93.163) with Microsoft SMTP Server (TLS) id 15.0.856.2; Thu, 16 Jan 2014 19:28:37 +0000 Received: from BY1FFOFD004.ffo.gbl (64.4.22.89) by CH1SR01CA101.outlook.office365.com (10.255.157.18) with Microsoft SMTP Server (TLS) id 15.0.868.2 via Frontend Transport; Thu, 16 Jan 2014 19:28:36 +0000 Received: from hybrid.exchange.microsoft.com (131.107.147.100) by BY1FFOFD004.mail.o365filtering.com (10.1.16.61) with Microsoft SMTP Server (TLS) id 15.0.847.5 via Frontend Transport; Thu, 16 Jan 2014 19:28:35 +0000 Received: from DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.23; Thu, 16 Jan 2014 11:28:14 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) with Microsoft SMTP Server (TLS) id 15.0.847.21; Thu, 16 Jan 2014 11:28:14 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.37]) with mapi id 15.00.0847.008; Thu, 16 Jan 2014 11:28:14 -0800 From: Trevor Freeman To: "Panos Kampanakis (pkampana)" , "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616wACLQsgAAXYzoAAJpMnYAADsCRg Date: Thu, 16 Jan 2014 19:28:13 +0000 Message-ID: <673f2a8968f6437c844f5a0e148c7d84@DFM-TK5MBX15-05.exchange.corp.microsoft.com> References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_673f2a8968f6437c844f5a0e148c7d84DFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.147.100; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(377454003)(164054003)(51444003)(189002)(199002)(50986001)(76796001)(53806001)(59766001)(512954002)(16236675003)(87936001)(63696002)(47736001)(54356001)(83322001)(19580405001)(85852003)(44976005)(54316002)(93136001)(83072002)(77096001)(15975445006)(2656002)(87266001)(81686001)(76786001)(19580395003)(65816001)(47976001)(66066001)(51856001)(90146001)(74876001)(81542001)(74706001)(76482001)(81816001)(79102001)(33646001)(15202345003)(56816005)(56776001)(46102001)(74502001)(80976001)(20776003)(81342001)(19300405004)(69226001)(74366001)(80022001)(4396001)(47446002)(74662001)(84326002)(49866001)(31966008)(92566001)(77982001)(6806004)(85306002)(71186001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB595; H:hybrid.exchange.microsoft.com; CLIP:131.107.147.100; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Forefront-PRVS: 0093C80C01 X-OriginatorOrg: exchange.microsoft.com Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:28:56 -0000 --_000_673f2a8968f6437c844f5a0e148c7d84DFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos, For digital signatures, it is a classic issues between what you do with a s= ingle signature vs. multiple signatures. For a single signature, what you d= escribe works e.g. a document with a single incident - no problem. It's als= o not a problem with the actual signature itself, that too is fine. It's si= mply a question of optimizing the bag of certificates you need to validate = multiple signatures. If you start aggregating incident data, and have dif= ferent incidents from different sources with different signers, you need to= normalize the certificate data set across all the signers so you don't blo= at the document with redundant data. The schema I would define is trivial a= s it would reuse the elements defined in the XML signature standard, but sh= ould be stored in the schema at the level of the IODEF document as it per= tains to multiple incidents. This is the behavior that CMS uses i.e. certif= icates are not part of the SignerInfo but are part of the Signed Data struc= ture. This allows a single bag of certificates to be used across all Signer= Info structures. The work that Kathleen is referring to is the work I am doing with Jim Scha= ad on stronger policy enforcement on distributed data. We started work on e= mail and the work goes under the Plasma name in the IETF. We have developed= a mechanism to apply strong access control policy on email whereby we can = send out a message to multiple recipients and enforce attribute based acces= s control to the content. As part of that work we define something we call= a Plasma token which links an email message to a set of XACML rules which = defines the specifics of who can access the message. Its fairly simple to t= ake what we have in http://datatracker.ietf.org/doc/draft-schaad-plasma-cms= / and recast in in XML and embed a Plasma token in an IODEF document using = the additional data extension mechanism to deliver access control with teet= h. However you cannot homogenize the access control policy so it does not m= ake sense to apply access control at the document level but to individual i= ncidents or parts of incidents. Different incents could have different poli= cies. I can embed different policies into the single Plasma token, or I may= need to embed a separate token depending on the policies and who is truste= d. Again the tokens should be at the document level not the incident level = as each token can protect multiple indents. I cannot use the extension poin= t in the incident to store the token because I want to encrypt the entire i= ncent. In both scenarios, the IODEF extension mechanism works just fine to solve t= he problem, except that I cannot use it at the document level because it's = not in the IODEF-document class. Is there some reason for not wanting the document class extended? Trevor From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Thursday, January 16, 2014 9:25 AM To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org Subject: RE: Extending the IODEF-Document class Authentication of the incident data themselves seems reasonable to address. But to solve that, would it be simpler for someone to sign the XML doc or = parts of it and include all the certs using XML DSIG (enveloped or detached= ) ? Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 6:18 PM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Kathleen, RID, to my mind offers a set of security serves targeting the transport and= authorization of the RID messages. The security of RID, handles the secur= ity associated with the processing of RID messages. For example, a RID mess= age could be a request for an action or a query for information. This messa= ges need security services because of the potential impact i.e. we don't wa= nt to repeat the mistake of SMTP where there is no authentication when emai= l is sent between MTAs. The timeframe of the security is around the request= and the response RID messages, i.e. send a RID request, get a RID response= , case closed. The RID security provides operational security for the funct= ioning of ecosystem. Information policies like information sharing or confidentiality agreements= relate to the actual content itself regardless of format and persists beyo= nd receiving the data hence apply to the content of the IODEF documents whe= rever they are. If I was a repository of incident data, I am receiving inci= dents which could be signed as proof of data origination from many sources.= If I receive a RID query message, I would authorize processing the request= based on the RID security then construct a new IODEF document containing a= ll the incidents covered by the request. The repository would sign the RID = response, but I want to retain the original signatures of the contributor o= f the incident data itself as it relates directly to the providence of the = data. If the incident data requires specific access control policies, thos= e too would need to be respected as part of the response and are orthogonal= to the confidentiality of the RID response as they can change incident by = incident. I see any IODEF security providing security services to support c= ompliance with the information policies be they regulatory policies, contra= ctual policies, information sharing agreements or whatever. Hope that helps. Trevor From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 15, 2014 11:41 AM To: Trevor Freeman; mile@ietf.org Subject: RE: Extending the IODEF-Document class Trevor, Could you elaborate on how this is different from or compliments the Digita= l signature and Encryption for IODEF in RID, RFC6545? I think that will be= helpful here. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 2:02 PM To: mile@ietf.org Subject: [mile] Extending the IODEF-Document class I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor --_000_673f2a8968f6437c844f5a0e148c7d84DFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Panos,

 

For digital signatures= , it is a classic issues between what you do with a single signature vs. mu= ltiple signatures. For a single signature, what you describe works e.g. a d= ocument with a single incident – no problem. It’s also not a problem with the actual signature itself, t= hat too is fine. It’s simply a question of optimizing the bag of cert= ificates you need to validate multiple signatures.  If you start = aggregating incident data, and have different incidents from different sources with different signers, you need to normalize the c= ertificate data set across all the signers so you don’t bloat the doc= ument with redundant data. The schema I would define is trivial as it would= reuse the elements defined in the XML signature standard, but should be  stored in the schema  at the = level of the IODEF document as it pertains to multiple incidents. This is t= he behavior that CMS uses i.e. certificates are not part of the SignerInfo = but are part of the Signed Data structure. This allows a single bag of certificates to be used across all SignerInfo = structures. 

 

The work that Kathleen= is referring to is the work I am doing with Jim Schaad on stronger policy = enforcement on distributed data. We started work on email and the work goes= under the Plasma name in the IETF. We have developed a mechanism to apply strong access control policy on ema= il whereby we can send out a message to multiple recipients and enforce att= ribute based access control to the content.  As part of that work we d= efine something we call a Plasma token which links an email message to a set of XACML rules which defines the spe= cifics of who can access the message. Its fairly simple to take what we hav= e in http:/= /datatracker.ietf.org/doc/draft-schaad-plasma-cms/ and recast in in XML= and embed a Plasma token in an IODEF document using the additional data ex= tension mechanism to deliver access control with teeth. However you cannot homogenize the access control polic= y so it does not make sense to apply access control at the document level b= ut to individual incidents or parts of incidents. Different incents could h= ave different policies. I can embed different policies into the single Plasma token, or I may need to embed a = separate token depending on the policies and who is trusted. Again the toke= ns should be at the document level not the incident level as each token can= protect multiple indents. I cannot use the extension point in the incident to store the token because I want = to encrypt the entire incent.

 

In both scenarios, the= IODEF extension mechanism works just fine to solve the problem, except tha= t I cannot use it at the document level because it’s not in the IODEF= -document class.

 

Is there some reason f= or not wanting the document class extended?

 

Trevor

 

From: Panos Kampanakis (pkampana) [mailto:pka= mpana@cisco.com]
Sent: Thursday, January 16, 2014 9:25 AM
To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Authentication of the = incident data themselves seems reasonable to address.

But to solve that, &nb= sp;would it be simpler for someone to sign the XML doc or parts of it and i= nclude all the certs using XML DSIG (enveloped or detached)  ?

Panos

 

 

 

 

From: mile [mailto:mile-bounc= es@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 6:18 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] Extending the IODEF-Document class

 

Hi Kathleen,

 

RID, to my mind offers= a set of security serves targeting the transport and authorization of the = RID messages. The security of  RID, handles the security associated wi= th the processing of RID messages. For example, a RID message could be a request for an action or a query for information.= This messages need security services because of the potential impact i.e. = we don’t want to repeat the mistake of SMTP where there is no authent= ication when email is sent between MTAs. The timeframe of the security is around the request and the response RID m= essages, i.e. send a RID request, get a RID response, case closed. The RID = security provides operational security for the functioning of ecosystem.

 

Information policies l= ike information sharing or confidentiality agreements relate to the actual = content itself regardless of format and persists beyond receiving the data = hence apply to the content of the IODEF documents wherever they are. If I was a repository of incident data, I am = receiving incidents which could be signed as proof of data origination from= many sources. If I receive a RID query message, I would authorize processi= ng the request based on the RID security then construct a new IODEF document containing all the incidents = covered by the request. The repository would sign the RID response, but I w= ant to retain the original signatures of the contributor of the incident da= ta itself as it relates directly to the providence of the data.  If the incident data requires specifi= c access control policies, those too would need to be respected as part of = the response and are orthogonal to the confidentiality of the RID response = as they can change incident by incident. I see any IODEF security providing security services to support compliance= with the information policies be they regulatory policies, contractual pol= icies,  information sharing agreements or whatever.

 

Hope that helps.<= /o:p>

 

Trevor

 

From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: Wednesday, January 15, 2014 11:41 AM
To: Trevor Freeman; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Trevor,

 

Could you elaborate on= how this is different from or compliments the Digital signature and Encryp= tion for IODEF in RID, RFC6545?  I think that will be helpful here.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounc= es@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 2:02 PM
To: mile@ietf.or= g
Subject: [mile] Extending the IODEF-Document class=

 

I am looking at implementing better end to end secur= ity with IODEF documents.

 

For example, stronger access control on the data tha= n is possible via the restriction attribute, or stronger data origination a= uthentication by singing incidents.

 

In both cases there is  security relevant metad= ata which may apply to multiple incidents in an IODEF document. For example= with signed incidents, I want to include a set certificates to enable rely= ing parties to be able to validate the incident. I also want to optimize the set of certificates in the document = i.e. ensure I don’t include the same certificate multiple places in t= he document. The simplest way to achieve that is to have all the certificat= es in one place.  The logical place to store the set of certificates would be in the IODEF document class. This i= s equivalent to CMS, where the set of signing certificates are in the Signe= dData object not the SignerInfo object. However the IODEF document class la= cks the AdditionalData extension point preset in other IODEF classes.

 

Is it possible to add the optional AdditionalData el= ement to the v2 of the IODEF document class so it is possible to extend tha= t class the same way it is possible to extend other classes?

 

Trevor

--_000_673f2a8968f6437c844f5a0e148c7d84DFMTK5MBX1505exchangeco_-- From rdd@cert.org Thu Jan 16 11:38:23 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443C51AC49D for ; Thu, 16 Jan 2014 11:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aldqt3-edYT for ; Thu, 16 Jan 2014 11:38:17 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id A65031A1F61 for ; Thu, 16 Jan 2014 11:38:16 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0GJbZAx018631; Thu, 16 Jan 2014 14:37:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1389901055; bh=DKFSKiN9JCtoDOlvjjrtQwV1Br+j/yw/b+O6XQqnHJA=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To:Cc; b=PV0Cp+dhRfvUJ7Y9l/nBtPetqpsLi4yic2kmYuRgLoiAQx5f/l6HXjeThLadKOn+d FCejJ7Ai0UH5ULABQNRF8wb/MzqQi7jNVVzBD9PdwX8yO6l0eNXmP8uOcPDXGqa5H/ LvfpNu5uGEdh2jUI9arG5PygZ85PWS23q2oGk+Ts= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0GJbYF4025862; Thu, 16 Jan 2014 14:37:35 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 16 Jan 2014 14:37:34 -0500 From: "Roman D. Danyliw" To: Trevor Freeman , "Panos Kampanakis (pkampana)" , "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616wACLQsgAAXYzoAAJpMnYAADsCRgAAHTrZA= Date: Thu, 16 Jan 2014 19:37:34 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C14EAA@marathon> References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> <673f2a8968f6437c844f5a0e148c7d84@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: <673f2a8968f6437c844f5a0e148c7d84@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C14EAAmarathon_" MIME-Version: 1.0 Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 19:38:23 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C14EAAmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good afternoon! Sidestepping the signature discussion, I think that Trevor is pointing out = a gap in the data model. I concur that it would be valuable to have the ab= ility to add an extension into an IODEF-Document. It would allow unanticip= ated data elements to be added into the root node that are relevant to mult= iple Incident classes aggregated in the IODEF-Document class. Roman From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Thursday, January 16, 2014 2:28 PM To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Panos, For digital signatures, it is a classic issues between what you do with a s= ingle signature vs. multiple signatures. For a single signature, what you d= escribe works e.g. a document with a single incident - no problem. It's als= o not a problem with the actual signature itself, that too is fine. It's si= mply a question of optimizing the bag of certificates you need to validate = multiple signatures. If you start aggregating incident data, and have dif= ferent incidents from different sources with different signers, you need to= normalize the certificate data set across all the signers so you don't blo= at the document with redundant data. The schema I would define is trivial a= s it would reuse the elements defined in the XML signature standard, but sh= ould be stored in the schema at the level of the IODEF document as it per= tains to multiple incidents. This is the behavior that CMS uses i.e. certif= icates are not part of the SignerInfo but are part of the Signed Data struc= ture. This allows a single bag of certificates to be used across all Signer= Info structures. The work that Kathleen is referring to is the work I am doing with Jim Scha= ad on stronger policy enforcement on distributed data. We started work on e= mail and the work goes under the Plasma name in the IETF. We have developed= a mechanism to apply strong access control policy on email whereby we can = send out a message to multiple recipients and enforce attribute based acces= s control to the content. As part of that work we define something we call= a Plasma token which links an email message to a set of XACML rules which = defines the specifics of who can access the message. Its fairly simple to t= ake what we have in http://datatracker.ietf.org/doc/draft-schaad-plasma-cms= / and recast in in XML and embed a Plasma token in an IODEF document using = the additional data extension mechanism to deliver access control with teet= h. However you cannot homogenize the access control policy so it does not m= ake sense to apply access control at the document level but to individual i= ncidents or parts of incidents. Different incents could have different poli= cies. I can embed different policies into the single Plasma token, or I may= need to embed a separate token depending on the policies and who is truste= d. Again the tokens should be at the document level not the incident level = as each token can protect multiple indents. I cannot use the extension poin= t in the incident to store the token because I want to encrypt the entire i= ncent. In both scenarios, the IODEF extension mechanism works just fine to solve t= he problem, except that I cannot use it at the document level because it's = not in the IODEF-document class. Is there some reason for not wanting the document class extended? Trevor From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Thursday, January 16, 2014 9:25 AM To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org Subject: RE: Extending the IODEF-Document class Authentication of the incident data themselves seems reasonable to address. But to solve that, would it be simpler for someone to sign the XML doc or = parts of it and include all the certs using XML DSIG (enveloped or detached= ) ? Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 6:18 PM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Kathleen, RID, to my mind offers a set of security serves targeting the transport and= authorization of the RID messages. The security of RID, handles the secur= ity associated with the processing of RID messages. For example, a RID mess= age could be a request for an action or a query for information. This messa= ges need security services because of the potential impact i.e. we don't wa= nt to repeat the mistake of SMTP where there is no authentication when emai= l is sent between MTAs. The timeframe of the security is around the request= and the response RID messages, i.e. send a RID request, get a RID response= , case closed. The RID security provides operational security for the funct= ioning of ecosystem. Information policies like information sharing or confidentiality agreements= relate to the actual content itself regardless of format and persists beyo= nd receiving the data hence apply to the content of the IODEF documents whe= rever they are. If I was a repository of incident data, I am receiving inci= dents which could be signed as proof of data origination from many sources.= If I receive a RID query message, I would authorize processing the request= based on the RID security then construct a new IODEF document containing a= ll the incidents covered by the request. The repository would sign the RID = response, but I want to retain the original signatures of the contributor o= f the incident data itself as it relates directly to the providence of the = data. If the incident data requires specific access control policies, thos= e too would need to be respected as part of the response and are orthogonal= to the confidentiality of the RID response as they can change incident by = incident. I see any IODEF security providing security services to support c= ompliance with the information policies be they regulatory policies, contra= ctual policies, information sharing agreements or whatever. Hope that helps. Trevor From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 15, 2014 11:41 AM To: Trevor Freeman; mile@ietf.org Subject: RE: Extending the IODEF-Document class Trevor, Could you elaborate on how this is different from or compliments the Digita= l signature and Encryption for IODEF in RID, RFC6545? I think that will be= helpful here. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 2:02 PM To: mile@ietf.org Subject: [mile] Extending the IODEF-Document class I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor --_000_359EC4B99E040048A7131E0F4E113AFC54C14EAAmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good afternoon!

 

Sidestepping the signa= ture discussion, I think that Trevor is pointing out a gap in the data mode= l.  I concur that it would be valuable to have the ability to add an e= xtension into an IODEF-Document.  It would allow unanticipated data elements to be added into the root node that are = relevant to multiple Incident classes aggregated in the IODEF-Document clas= s.

 

Roman

 

From: mile [ma= ilto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Thursday, January 16, 2014 2:28 PM
To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class

 

Hi Panos,

 

For digital signatures= , it is a classic issues between what you do with a single signature vs. mu= ltiple signatures. For a single signature, what you describe works e.g. a d= ocument with a single incident – no problem. It’s also not a problem with the actual signature itself, t= hat too is fine. It’s simply a question of optimizing the bag of cert= ificates you need to validate multiple signatures.  If you start = aggregating incident data, and have different incidents from different sources with different signers, you need to normalize the c= ertificate data set across all the signers so you don’t bloat the doc= ument with redundant data. The schema I would define is trivial as it would= reuse the elements defined in the XML signature standard, but should be  stored in the schema  at the = level of the IODEF document as it pertains to multiple incidents. This is t= he behavior that CMS uses i.e. certificates are not part of the SignerInfo = but are part of the Signed Data structure. This allows a single bag of certificates to be used across all SignerInfo = structures. 

 

The work that Kathleen= is referring to is the work I am doing with Jim Schaad on stronger policy = enforcement on distributed data. We started work on email and the work goes= under the Plasma name in the IETF. We have developed a mechanism to apply strong access control policy on ema= il whereby we can send out a message to multiple recipients and enforce att= ribute based access control to the content.  As part of that work we d= efine something we call a Plasma token which links an email message to a set of XACML rules which defines the spe= cifics of who can access the message. Its fairly simple to take what we hav= e in http:/= /datatracker.ietf.org/doc/draft-schaad-plasma-cms/ and recast in in XML= and embed a Plasma token in an IODEF document using the additional data ex= tension mechanism to deliver access control with teeth. However you cannot homogenize the access control polic= y so it does not make sense to apply access control at the document level b= ut to individual incidents or parts of incidents. Different incents could h= ave different policies. I can embed different policies into the single Plasma token, or I may need to embed a = separate token depending on the policies and who is trusted. Again the toke= ns should be at the document level not the incident level as each token can= protect multiple indents. I cannot use the extension point in the incident to store the token because I want = to encrypt the entire incent.

 

In both scenarios, the= IODEF extension mechanism works just fine to solve the problem, except tha= t I cannot use it at the document level because it’s not in the IODEF= -document class.

 

Is there some reason f= or not wanting the document class extended?

 

Trevor

 

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]
Sent: Thursday, January 16, 2014 9:25 AM
To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Authentication of the = incident data themselves seems reasonable to address.

But to solve that, &nb= sp;would it be simpler for someone to sign the XML doc or parts of it and i= nclude all the certs using XML DSIG (enveloped or detached)  ?

Panos

 

 

 

 

From: mile [mailto:mile-bounc= es@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 6:18 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] Extending the IODEF-Document class

 

Hi Kathleen,

 

RID, to my mind offers= a set of security serves targeting the transport and authorization of the = RID messages. The security of  RID, handles the security associated wi= th the processing of RID messages. For example, a RID message could be a request for an action or a query for information.= This messages need security services because of the potential impact i.e. = we don’t want to repeat the mistake of SMTP where there is no authent= ication when email is sent between MTAs. The timeframe of the security is around the request and the response RID m= essages, i.e. send a RID request, get a RID response, case closed. The RID = security provides operational security for the functioning of ecosystem.

 

Information policies l= ike information sharing or confidentiality agreements relate to the actual = content itself regardless of format and persists beyond receiving the data = hence apply to the content of the IODEF documents wherever they are. If I was a repository of incident data, I am = receiving incidents which could be signed as proof of data origination from= many sources. If I receive a RID query message, I would authorize processi= ng the request based on the RID security then construct a new IODEF document containing all the incidents = covered by the request. The repository would sign the RID response, but I w= ant to retain the original signatures of the contributor of the incident da= ta itself as it relates directly to the providence of the data.  If the incident data requires specifi= c access control policies, those too would need to be respected as part of = the response and are orthogonal to the confidentiality of the RID response = as they can change incident by incident. I see any IODEF security providing security services to support compliance= with the information policies be they regulatory policies, contractual pol= icies,  information sharing agreements or whatever.

 

Hope that helps.<= /o:p>

 

Trevor

 

From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: Wednesday, January 15, 2014 11:41 AM
To: Trevor Freeman; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Trevor,

 

Could you elaborate on= how this is different from or compliments the Digital signature and Encryp= tion for IODEF in RID, RFC6545?  I think that will be helpful here.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounc= es@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 2:02 PM
To: mile@ietf.or= g
Subject: [mile] Extending the IODEF-Document class=

 

I am looking at implementing better end to end secur= ity with IODEF documents.

 

For example, stronger access control on the data tha= n is possible via the restriction attribute, or stronger data origination a= uthentication by singing incidents.

 

In both cases there is  security relevant metad= ata which may apply to multiple incidents in an IODEF document. For example= with signed incidents, I want to include a set certificates to enable rely= ing parties to be able to validate the incident. I also want to optimize the set of certificates in the document = i.e. ensure I don’t include the same certificate multiple places in t= he document. The simplest way to achieve that is to have all the certificat= es in one place.  The logical place to store the set of certificates would be in the IODEF document class. This i= s equivalent to CMS, where the set of signing certificates are in the Signe= dData object not the SignerInfo object. However the IODEF document class la= cks the AdditionalData extension point preset in other IODEF classes.

 

Is it possible to add the optional AdditionalData el= ement to the v2 of the IODEF document class so it is possible to extend tha= t class the same way it is possible to extend other classes?

 

Trevor

--_000_359EC4B99E040048A7131E0F4E113AFC54C14EAAmarathon_-- From kathleen.moriarty@emc.com Thu Jan 16 12:02:52 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A6B1AD62B for ; Thu, 16 Jan 2014 12:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCrp-o_FGOOo for ; Thu, 16 Jan 2014 12:02:50 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 42EE51ACCFD for ; Thu, 16 Jan 2014 12:02:50 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0GK2XEK016664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2014 15:02:35 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0GK2XEK016664 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389902555; bh=jHe7t3JsO0+IZq3DZOjNBpr2xeY=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YR/2I+j4gGmq22oROzHEaFrhP7GvK4GB4lBB7dGPU+yD7bcJzB+oLbu23MQB+lGBJ 4Su2/DogbWqMeGUe+kuZ2n7ozQS7u9ppV0G1hmwm65wGq5ZlCu64ljRR9eHjEwHT6X tNtazV0lOodJljXW4JPdfMPoa8kHI9EAhJxOA+Ps= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0GK2XEK016664 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 16 Jan 2014 15:02:20 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0GK2KVS017028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jan 2014 15:02:20 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Thu, 16 Jan 2014 15:00:53 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Thu, 16 Jan 2014 15:02:19 -0500 Thread-Topic: An alternative way to represent a URL Thread-Index: Ac8SJVS/DbLXXY1tToONjFAmsI3aZQA0Claw Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C149B2@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C149B2@marathon> 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-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: Re: [mile] An alternative way to represent a URL X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 20:02:52 -0000 Hi Roman, I think it was only left in to show that we could do this another way if pe= ople were interested. If the WG is happy with the approach in place now th= at achieves the same objective, this can be removed. The discussions that = led to this may go back to Rosella's presentation and that URLs could only = be included as a reference and not an indicator in IODEF v1. Thanks, Kathleen -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Thursday, January 16, 2014 1:57 PM To: mile@ietf.org Subject: [mile] An alternative way to represent a URL Hello, The schema definition of the Node class in -03 of 5070bis has the following= comment in it: [begin schema snippet] [end= schema snippet] This proposal would provide an alternative to the current approach of repre= senting a URI for a Node using Address@category=3D"site-uri" (e.g., http://www.example.com/sites/foo). I don't know the origin or rational for this comment. Could anyone shed li= ght on why we'd want to change the current representation? Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From trevorf@exchange.microsoft.com Fri Jan 17 10:43:31 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE5D1AD73F for ; Fri, 17 Jan 2014 10:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXs4eqNQP24D for ; Fri, 17 Jan 2014 10:43:25 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id 765E81AD939 for ; Fri, 17 Jan 2014 10:43:25 -0800 (PST) Received: from BLUSR01CA101.namsdf01.sdf.exchangelabs.com (10.255.124.146) by BL2SR01MB593.namsdf01.sdf.exchangelabs.com (10.255.109.164) with Microsoft SMTP Server (TLS) id 15.0.868.2; Fri, 17 Jan 2014 18:27:14 +0000 Received: from BY1FFOFD001.ffo.gbl (64.4.22.93) by BLUSR01CA101.outlook.office365.com (10.255.124.146) with Microsoft SMTP Server (TLS) id 15.0.868.2 via Frontend Transport; Fri, 17 Jan 2014 18:27:13 +0000 Received: from hybrid.exchange.microsoft.com (131.107.147.100) by BY1FFOFD001.mail.o365filtering.com (10.1.16.83) with Microsoft SMTP Server (TLS) id 15.0.856.11 via Frontend Transport; Fri, 17 Jan 2014 18:27:13 +0000 Received: from DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.23; Fri, 17 Jan 2014 10:26:30 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) with Microsoft SMTP Server (TLS) id 15.0.847.21; Fri, 17 Jan 2014 10:26:29 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.37]) with mapi id 15.00.0847.008; Fri, 17 Jan 2014 10:26:29 -0800 From: Trevor Freeman To: "Roman D. Danyliw" , "Panos Kampanakis (pkampana)" , "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616wACLQsgAAXYzoAAJpMnYAADsCRgAAHTrZAAL/Qv8A== Date: Fri, 17 Jan 2014 18:26:28 +0000 Message-ID: <9d7bcf3f29f942c5b7e410d14f1ae16d@DFM-TK5MBX15-05.exchange.corp.microsoft.com> References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> <673f2a8968f6437c844f5a0e148c7d84@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <359EC4B99E040048A7131E0F4E113AFC54C14EAA@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C14EAA@marathon> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_9d7bcf3f29f942c5b7e410d14f1ae16dDFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.147.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(199002)(189002)(377454003)(164054003)(51444003)(74366001)(83072002)(77096001)(76786001)(76796001)(19300405004)(74706001)(15202345003)(84326002)(87266001)(19580405001)(83322001)(19580395003)(80976001)(51856001)(85306002)(53806001)(76482001)(79102001)(44976005)(6806004)(2656002)(4396001)(512954002)(47736001)(47976001)(50986001)(49866001)(77982001)(54316002)(59766001)(56776001)(33646001)(46102001)(81542001)(90146001)(56816005)(85852003)(87936001)(20776003)(63696002)(16236675003)(69226001)(71186001)(74662001)(74502001)(47446002)(31966008)(81342001)(66066001)(80022001)(65816001)(81686001)(15975445006)(93516002)(54356001)(74876001)(93136001)(81816001)(92566001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB593; H:hybrid.exchange.microsoft.com; CLIP:131.107.147.100; FPR:FE4CF2DD.A222D511.F9D1F0BB.42E8F961.2065C; InfoDomainNonexistentA:1; MX:1; LANG:en; X-Forefront-PRVS: 0094E3478A X-OriginatorOrg: exchange.microsoft.com Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:43:31 -0000 --_000_9d7bcf3f29f942c5b7e410d14f1ae16dDFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Exactly I was trying to figure out if this is a simple oversight or deliberate act. Does anyone object to filling the gap and adding the extension to the IODEF= -document class? Trevor From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 16, 2014 11:38 AM To: Trevor Freeman; Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@i= etf.org Subject: RE: Extending the IODEF-Document class Good afternoon! Sidestepping the signature discussion, I think that Trevor is pointing out = a gap in the data model. I concur that it would be valuable to have the ab= ility to add an extension into an IODEF-Document. It would allow unanticip= ated data elements to be added into the root node that are relevant to mult= iple Incident classes aggregated in the IODEF-Document class. Roman From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Thursday, January 16, 2014 2:28 PM To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Panos, For digital signatures, it is a classic issues between what you do with a s= ingle signature vs. multiple signatures. For a single signature, what you d= escribe works e.g. a document with a single incident - no problem. It's als= o not a problem with the actual signature itself, that too is fine. It's si= mply a question of optimizing the bag of certificates you need to validate = multiple signatures. If you start aggregating incident data, and have dif= ferent incidents from different sources with different signers, you need to= normalize the certificate data set across all the signers so you don't blo= at the document with redundant data. The schema I would define is trivial a= s it would reuse the elements defined in the XML signature standard, but sh= ould be stored in the schema at the level of the IODEF document as it per= tains to multiple incidents. This is the behavior that CMS uses i.e. certif= icates are not part of the SignerInfo but are part of the Signed Data struc= ture. This allows a single bag of certificates to be used across all Signer= Info structures. The work that Kathleen is referring to is the work I am doing with Jim Scha= ad on stronger policy enforcement on distributed data. We started work on e= mail and the work goes under the Plasma name in the IETF. We have developed= a mechanism to apply strong access control policy on email whereby we can = send out a message to multiple recipients and enforce attribute based acces= s control to the content. As part of that work we define something we call= a Plasma token which links an email message to a set of XACML rules which = defines the specifics of who can access the message. Its fairly simple to t= ake what we have in http://datatracker.ietf.org/doc/draft-schaad-plasma-cms= / and recast in in XML and embed a Plasma token in an IODEF document using = the additional data extension mechanism to deliver access control with teet= h. However you cannot homogenize the access control policy so it does not m= ake sense to apply access control at the document level but to individual i= ncidents or parts of incidents. Different incents could have different poli= cies. I can embed different policies into the single Plasma token, or I may= need to embed a separate token depending on the policies and who is truste= d. Again the tokens should be at the document level not the incident level = as each token can protect multiple indents. I cannot use the extension poin= t in the incident to store the token because I want to encrypt the entire i= ncent. In both scenarios, the IODEF extension mechanism works just fine to solve t= he problem, except that I cannot use it at the document level because it's = not in the IODEF-document class. Is there some reason for not wanting the document class extended? Trevor From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Thursday, January 16, 2014 9:25 AM To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org Subject: RE: Extending the IODEF-Document class Authentication of the incident data themselves seems reasonable to address. But to solve that, would it be simpler for someone to sign the XML doc or = parts of it and include all the certs using XML DSIG (enveloped or detached= ) ? Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 6:18 PM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Kathleen, RID, to my mind offers a set of security serves targeting the transport and= authorization of the RID messages. The security of RID, handles the secur= ity associated with the processing of RID messages. For example, a RID mess= age could be a request for an action or a query for information. This messa= ges need security services because of the potential impact i.e. we don't wa= nt to repeat the mistake of SMTP where there is no authentication when emai= l is sent between MTAs. The timeframe of the security is around the request= and the response RID messages, i.e. send a RID request, get a RID response= , case closed. The RID security provides operational security for the funct= ioning of ecosystem. Information policies like information sharing or confidentiality agreements= relate to the actual content itself regardless of format and persists beyo= nd receiving the data hence apply to the content of the IODEF documents whe= rever they are. If I was a repository of incident data, I am receiving inci= dents which could be signed as proof of data origination from many sources.= If I receive a RID query message, I would authorize processing the request= based on the RID security then construct a new IODEF document containing a= ll the incidents covered by the request. The repository would sign the RID = response, but I want to retain the original signatures of the contributor o= f the incident data itself as it relates directly to the providence of the = data. If the incident data requires specific access control policies, thos= e too would need to be respected as part of the response and are orthogonal= to the confidentiality of the RID response as they can change incident by = incident. I see any IODEF security providing security services to support c= ompliance with the information policies be they regulatory policies, contra= ctual policies, information sharing agreements or whatever. Hope that helps. Trevor From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 15, 2014 11:41 AM To: Trevor Freeman; mile@ietf.org Subject: RE: Extending the IODEF-Document class Trevor, Could you elaborate on how this is different from or compliments the Digita= l signature and Encryption for IODEF in RID, RFC6545? I think that will be= helpful here. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 2:02 PM To: mile@ietf.org Subject: [mile] Extending the IODEF-Document class I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor --_000_9d7bcf3f29f942c5b7e410d14f1ae16dDFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Exactly

 

I was trying to figure= out if this is a simple oversight or deliberate act.

 

Does anyone object to = filling the gap and adding the extension to the IODEF-document class?<= /o:p>

 

Trevor

 

From: Roman D. Danyliw [mailto:rdd@cert.org] =
Sent: Thursday, January 16, 2014 11:38 AM
To: Trevor Freeman; Panos Kampanakis (pkampana); Moriarty, Kathleen;= mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Good afternoon!

 

Sidestepping the signa= ture discussion, I think that Trevor is pointing out a gap in the data mode= l.  I concur that it would be valuable to have the ability to add an e= xtension into an IODEF-Document.  It would allow unanticipated data elements to be added into the root node that are = relevant to multiple Incident classes aggregated in the IODEF-Document clas= s.

 

Roman

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Thursday, January 16, 2014 2:28 PM
To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] Extending the IODEF-Document class

 

Hi Panos,

 

For digital signatures= , it is a classic issues between what you do with a single signature vs. mu= ltiple signatures. For a single signature, what you describe works e.g. a d= ocument with a single incident – no problem. It’s also not a problem with the actual signature itself, t= hat too is fine. It’s simply a question of optimizing the bag of cert= ificates you need to validate multiple signatures.  If you start = aggregating incident data, and have different incidents from different sources with different signers, you need to normalize the c= ertificate data set across all the signers so you don’t bloat the doc= ument with redundant data. The schema I would define is trivial as it would= reuse the elements defined in the XML signature standard, but should be  stored in the schema  at the = level of the IODEF document as it pertains to multiple incidents. This is t= he behavior that CMS uses i.e. certificates are not part of the SignerInfo = but are part of the Signed Data structure. This allows a single bag of certificates to be used across all SignerInfo = structures. 

 

The work that Kathleen= is referring to is the work I am doing with Jim Schaad on stronger policy = enforcement on distributed data. We started work on email and the work goes= under the Plasma name in the IETF. We have developed a mechanism to apply strong access control policy on ema= il whereby we can send out a message to multiple recipients and enforce att= ribute based access control to the content.  As part of that work we d= efine something we call a Plasma token which links an email message to a set of XACML rules which defines the spe= cifics of who can access the message. Its fairly simple to take what we hav= e in http:/= /datatracker.ietf.org/doc/draft-schaad-plasma-cms/ and recast in in XML= and embed a Plasma token in an IODEF document using the additional data ex= tension mechanism to deliver access control with teeth. However you cannot homogenize the access control polic= y so it does not make sense to apply access control at the document level b= ut to individual incidents or parts of incidents. Different incents could h= ave different policies. I can embed different policies into the single Plasma token, or I may need to embed a = separate token depending on the policies and who is trusted. Again the toke= ns should be at the document level not the incident level as each token can= protect multiple indents. I cannot use the extension point in the incident to store the token because I want = to encrypt the entire incent.

 

In both scenarios, the= IODEF extension mechanism works just fine to solve the problem, except tha= t I cannot use it at the document level because it’s not in the IODEF= -document class.

 

Is there some reason f= or not wanting the document class extended?

 

Trevor

 

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]
Sent: Thursday, January 16, 2014 9:25 AM
To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Authentication of the = incident data themselves seems reasonable to address.

But to solve that, &nb= sp;would it be simpler for someone to sign the XML doc or parts of it and i= nclude all the certs using XML DSIG (enveloped or detached)  ?

Panos

 

 

 

 

From: mile [mailto:mile-bounc= es@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 6:18 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] Extending the IODEF-Document class

 

Hi Kathleen,

 

RID, to my mind offers= a set of security serves targeting the transport and authorization of the = RID messages. The security of  RID, handles the security associated wi= th the processing of RID messages. For example, a RID message could be a request for an action or a query for information.= This messages need security services because of the potential impact i.e. = we don’t want to repeat the mistake of SMTP where there is no authent= ication when email is sent between MTAs. The timeframe of the security is around the request and the response RID m= essages, i.e. send a RID request, get a RID response, case closed. The RID = security provides operational security for the functioning of ecosystem.

 

Information policies l= ike information sharing or confidentiality agreements relate to the actual = content itself regardless of format and persists beyond receiving the data = hence apply to the content of the IODEF documents wherever they are. If I was a repository of incident data, I am = receiving incidents which could be signed as proof of data origination from= many sources. If I receive a RID query message, I would authorize processi= ng the request based on the RID security then construct a new IODEF document containing all the incidents = covered by the request. The repository would sign the RID response, but I w= ant to retain the original signatures of the contributor of the incident da= ta itself as it relates directly to the providence of the data.  If the incident data requires specifi= c access control policies, those too would need to be respected as part of = the response and are orthogonal to the confidentiality of the RID response = as they can change incident by incident. I see any IODEF security providing security services to support compliance= with the information policies be they regulatory policies, contractual pol= icies,  information sharing agreements or whatever.

 

Hope that helps.<= /o:p>

 

Trevor

 

From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: Wednesday, January 15, 2014 11:41 AM
To: Trevor Freeman; mile@ietf.org
Subject: RE: Extending the IODEF-Document class

 

Trevor,

 

Could you elaborate on= how this is different from or compliments the Digital signature and Encryp= tion for IODEF in RID, RFC6545?  I think that will be helpful here.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounc= es@ietf.org] On Behalf Of Trevor Freeman
Sent: Wednesday, January 15, 2014 2:02 PM
To: mile@ietf.or= g
Subject: [mile] Extending the IODEF-Document class=

 

I am looking at implementing better end to end secur= ity with IODEF documents.

 

For example, stronger access control on the data tha= n is possible via the restriction attribute, or stronger data origination a= uthentication by singing incidents.

 

In both cases there is  security relevant metad= ata which may apply to multiple incidents in an IODEF document. For example= with signed incidents, I want to include a set certificates to enable rely= ing parties to be able to validate the incident. I also want to optimize the set of certificates in the document = i.e. ensure I don’t include the same certificate multiple places in t= he document. The simplest way to achieve that is to have all the certificat= es in one place.  The logical place to store the set of certificates would be in the IODEF document class. This i= s equivalent to CMS, where the set of signing certificates are in the Signe= dData object not the SignerInfo object. However the IODEF document class la= cks the AdditionalData extension point preset in other IODEF classes.

 

Is it possible to add the optional AdditionalData el= ement to the v2 of the IODEF document class so it is possible to extend tha= t class the same way it is possible to extend other classes?

 

Trevor

--_000_9d7bcf3f29f942c5b7e410d14f1ae16dDFMTK5MBX1505exchangeco_-- From internet-drafts@ietf.org Fri Jan 17 18:15:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DEE1AD94A; Fri, 17 Jan 2014 18:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMGYgbYb07Gt; Fri, 17 Jan 2014 18:15:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24B1AD8F5; Fri, 17 Jan 2014 18:15:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140118021509.14042.8005.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2014 18:15:09 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-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, 18 Jan 2014 02:15:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-04.txt Pages : 119 Date : 2014-01-17 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rdd@cert.org Fri Jan 17 18:19:50 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9975A1AD937 for ; Fri, 17 Jan 2014 18:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl3X0CNxait5 for ; Fri, 17 Jan 2014 18:19:48 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id BFA431AD791 for ; Fri, 17 Jan 2014 18:19:48 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0I2JZY7026035 for ; Fri, 17 Jan 2014 21:19:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390011575; bh=Dwm/A8sk+lgktd9Amioe2letrGYCE/ZMwgZ0KXWDZfc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=QbGa9xsVoymenNxXSOv3Z3D9eJcZzX1T2pbb6SyQVTNvP1J8DwOYqEFBLQWXYcVpw TMOv9A1JhNhz0SzvSnnR69R6CvLYPGZI7h1iNEN2U8LP2+n1jOpPdBj0ucNZOr+5/D Dp8x16LIECBWbeBOyDMWbw6nuS0UGfdMMwFSg5JM= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0I2JZEl010941 for ; Fri, 17 Jan 2014 21:19:35 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Fri, 17 Jan 2014 21:19:35 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-04.txt Thread-Index: AQHPE/MZEkFGmDan8U6+FwvWPmYSxpqJvsTg Date: Sat, 18 Jan 2014 02:19:34 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1661E@marathon> References: <20140118021509.14042.8005.idtracker@ietfa.amsl.com> In-Reply-To: <20140118021509.14042.8005.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Jan 2014 02:19:50 -0000 Good evening! The following is the CHANGELOG for draft-ietf-mile-rfc5070bis-04: ** (schema) Removed Incident/ReportId from the schema per WG discussion (Is= sue #15) ** (schema) Reference EmailInfo with a ref in Service class ** (schema) Reference WindowsRegistryKeysModified with a ref in the RecordD= ata class ** (schema) Rename EmailInfo/{Email,X-Mailer} to {EmailFrom,EmailX-Mailer} ** (schema) Added a missing @indicator-set-id to EmailInfo ** (schema) Added @indicator-id to Incident and EventData ** (schema) Renamed HashInformation@ext-category to @ext-type to fix a typo ** (schema) Renamed HashSigDetails complexType to HashInformation ** (schema) Reference HashInformation with a ref in the RecordData class ** (schema) Fixed schema error introduced in the -01 draft. RecordData sho= uld have a HashInformation child class not FileInfo and ds:Reference ** (schema) Added Node/PostalAddress and rewrote text for Node/Location (Is= sue #11) ** (schema) Added AdditionalData@dtype=3D"bytes" value ** (schema) Added Service/ApplicationHeader (Issue #26) ** (schema) Renamed WindowsRegistryKeysAction/Key/Value to KeyValue to be c= onsistent with KeyName ** (schema) Renamed WindowsRegistryKeysAction/Key@ext-category to @ext-regi= stryaction to fix typo ** (schema) Added IODEF-Document/AdditionalData ** (schema) Added {Expectation,HistoryItem}/DefinedCOA and @action=3D"defin= ed-coa" (Issue #32) ** (schema) Renamed RelatedDNS@ext-category to @ext-RecordType ** (editorial) Use xmlns:iodef=3D"urn:ietf:params:xml:ns:iodef-2.0" in the = namespace ** (editorial) Added text to Security Considerations to carefully parse exe= cutable content ** (editorial) Renamed Section 3.22 as WindowsRegistryKeysModified and corr= ected cardinality of aggregated classes ** (editorial) Removed @indicator-uid and @indicator-set-id from the text d= escribing Key since they belong in the parent WindowsRegistryKeysModified ** (editorial) Changed RFC2822 reference to RFC5322 ** (editorial) Added reference to registry keys for WindowsRegistryKeysActi= on ** (editorial) Consistently left aligned all diagrams ** (editorial) Added at least blank sections for all previously undocumente= d classes in the schema ** (editorial) Use reference names instead of numbers Roman -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, January 17, 2014 9:15 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v= 2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-04.txt Pages : 119 Date : 2014-01-17 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Fri Jan 17 18:32:16 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC99A1AD6C1 for ; Fri, 17 Jan 2014 18:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLdororELGFU for ; Fri, 17 Jan 2014 18:32:14 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1441ACCEA for ; Fri, 17 Jan 2014 18:32:14 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0I2W1DB007616 for ; Fri, 17 Jan 2014 21:32:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390012321; bh=e9qbLouCYv+mn8uao2tWM3O5uLqTTk/IXxx9UiOJY5o=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=lfl4lzuL+eB7AZiaUhnVoJuOmGHDwlGJHtKq3WX1YdgThccFHmhDZ+OVmrdu8m+c3 FakEzk1re8KfLmLNJ066Pjr3MR2Z5goczmeNckH2p+nLYst3PDlbmoXTbQQIHabHnT wpRv1zCJdA5KfI3UHw0uX88BMveAXMoa4JLi8q1w= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0I2W0vN011754 for ; Fri, 17 Jan 2014 21:32:01 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Fri, 17 Jan 2014 21:32:00 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Documenting DomainData Thread-Index: Ac8T9XBW9no0knEkSn6OJPXa0Du/9w== Date: Sat, 18 Jan 2014 02:32:00 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C1665Cmarathon_" MIME-Version: 1.0 Subject: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Jan 2014 02:32:16 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C1665Cmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_359EC4B99E040048A7131E0F4E113AFC54C1665Cmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

Since being copied from RFC5901 into 5070bis, Domain= Data has evolved.  Currently the two definition differ as follows:

 

** 5070bis added DomainData@{indicator-uid, indicato= r-set-id}

** 5070bis added DomainData/RelatedDNS

** 5070bis uses iodef:Contact for DomainData/DomainC= ontacts/Contact instead of phish:Contact which added classes and attributes= to Contact

 

A few questions:

 

(1) Since bits and pieces were added and modified in= the cut-and-paste from 5901, is there agreement that we don’t need t= o remove anything from DomainData?  Do we want to represent this level= of detail in the core IODEF data model?

 

(2) RelatedDNS was added to DomainData and is not pr= esent in RFC5901.  There is no descriptive text.  Could someone s= hed light on the purpose of this class.

 

(3) The attributes DomainData@{SystemStatus, DomainS= tatus} and RelatedDNS@RecordType don't follow the naming convention of lowe= r case names separated by a hyphen.  As in other cases where classes h= ave been moved, I would be inclined to rename the attributes.  Any concern in doing that?

 

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC54C1665Cmarathon_-- From kathleen.moriarty@emc.com Mon Jan 20 05:48:27 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3A1A0168 for ; Mon, 20 Jan 2014 05:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RtxFEk9d1V5 for ; Mon, 20 Jan 2014 05:48:25 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DB0CC1A0162 for ; Mon, 20 Jan 2014 05:48:24 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0KDmJ8B012681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 08:48:21 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s0KDmJ8B012681 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390225701; bh=hjdHPPuKohHmtJbsho27GnfgCYo=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=NYs/yAfPLhuKDtmMo2BnWNbA4NhA/2OTud0DLgz0oPXWAOfIdY5wHzmFdL7TnrzaC DiJ+tvVqQ69B832ViNCxclht04U1UtVENr7dCbylaKI0X9UhIQR49/HyOTQDo2bAyf DRJrWsuoMtZj+jjkaqb/CFRj6NmaVZC/GKt+k19s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s0KDmJ8B012681 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 20 Jan 2014 05:48:01 -0800 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0KDm1tD016614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jan 2014 08:48:01 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Mon, 20 Jan 2014 08:47:22 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Mon, 20 Jan 2014 08:47:58 -0500 Thread-Topic: [mile] Documenting DomainData Thread-Index: Ac8T9XBW9no0knEkSn6OJPXa0Du/9wB8Hm8Q Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> 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_F5063677821E3B4F81ACFB7905573F2406584BAA7AMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 13:48:27 -0000 --_000_F5063677821E3B4F81ACFB7905573F2406584BAA7AMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, #1 I thought the answer was yes, but it would be good to hear if anyone thi= nks it is too much detail now. #2 RelatedDNS lets you add any record type to expand out what is possible f= rom the Domain data class. You can also list what type of record you are i= ncluding. #3 I don't think there is a concern in adjusting the names for consistency. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, January 17, 2014 9:32 PM To: mile@ietf.org Subject: [mile] Documenting DomainData Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_F5063677821E3B4F81ACFB7905573F2406584BAA7AMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

#1 I thought the answer was yes, but it would be g= ood to hear if anyone thinks it is too much detail now.

 

#2 RelatedDNS lets= you add any record type to expand out what is possible from the Domain dat= a class.  You can also list what type of record you are including.

&= nbsp;

#3= I don’t think there is a concern in adjusting the names for consiste= ncy.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D.= Danyliw
Sent: Friday, January 17, 2014 9:32 PM
To: mil= e@ietf.org
Subject: [mile] Documenting DomainData

 

Hello!

 

Since being copied from RFC5901 into 5070bis, DomainData has= evolved.  Currently the two definition differ as follows:<= /p>

 

** 5070bi= s added DomainData@{indicator-uid, indicator-set-id}

** 5070bis added DomainData/RelatedDNS

** 5070bis uses iodef:Contact for DomainData/DomainContacts/Co= ntact instead of phish:Contact which added classes and attributes to Contac= t

 

A few questions:

 

(1) Since bits and pieces were added and modified in= the cut-and-paste from 5901, is there agreement that we don’t need t= o remove anything from DomainData?  Do we want to represent this level= of detail in the core IODEF data model?

 

(2) RelatedDNS was added to Doma= inData and is not present in RFC5901.  There is no descriptive text.&n= bsp; Could someone shed light on the purpose of this class.

<= p class=3DMsoNormal> 

(3) The attri= butes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@RecordType don= 't follow the naming convention of lower case names separated by a hyphen.&= nbsp; As in other cases where classes have been moved, I would be inclined = to rename the attributes.  Any concern in doing that?

 

Roman

= --_000_F5063677821E3B4F81ACFB7905573F2406584BAA7AMX15Acorpemcc_-- From rdd@cert.org Mon Jan 20 10:14:45 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFBA1A01C1 for ; Mon, 20 Jan 2014 10:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXeKZrsLL_Bd for ; Mon, 20 Jan 2014 10:14:42 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 153551A0169 for ; Mon, 20 Jan 2014 10:14:41 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0KIEfh6028245 for ; Mon, 20 Jan 2014 13:14:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390241681; bh=S7OXaZJYDmB5zj7/bywM12NB9uD19E2tQfKeBrGxzgM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version:Sender: Reply-To:Cc:In-Reply-To:References; b=f+FrL4nAYPEpVXOMXAztoVHaou9QVe2MwD3+6Gr3FcjZi9YSMh8yNJpoiWxTIxnyJ 5jP+sFgOGTZlP/+3+rh98JQyfADgc7zVdMdXhxzBzVOTTFpa1oUBZMuYbDCE/jzJSx rlDYO05fittx5SikQz7PTAMrPD8vAhJmeFUbfLOk= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0KIEfnY029700 for ; Mon, 20 Jan 2014 13:14:41 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 20 Jan 2014 13:14:40 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Clarifying the use of indicator-uid and set-id Thread-Index: Ac8WC0ksDHA2/WI9RNms16ruqKzVig== Date: Mon, 20 Jan 2014 18:14:39 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1878D@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C1878Dmarathon_" MIME-Version: 1.0 Subject: [mile] Clarifying the use of indicator-uid and set-id X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 18:14:45 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C1878Dmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! The response to scoping discussion #2 [1] and the subsequent discussion aro= und conveying timing information [2] began the specification of @indicator-= uid and @indicator-set-id in 5070bis. We agreed that if an element had eit= her an @indicator-uid or set-id then all aggregated elements nested in it w= ere considered part of the indicator. A few basic question still remain. This note is an attempt to clarify the = community's desires. (1) What is the format of the of @indicator-uid? @indicator-set-id? (2) Is the @indicator-uid identifier unique to the document (probably not?)= ? Unique to a given sender or recipient? Globally unique (like IncidentID)= ? (3) Is there an assumption of shared state between a sender and recipient? = Should a recipient understand/recognize the @indicator-uid or @indicator-s= et-id, or will it be an opaque blob? (4) If there is shared state between the sender and recipient, what should= be done when a recipient gets an @indicator-set-id it doesn't recognize? (5) How should a recipient interpret an indicator that has an @indicator-se= t-id but no @indicator-uid? (6) If an indicator is given an @indicator-uid and @indicator-set-id, is it= assumed that the uid is part of the described set? [1] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html [2] http://www.ietf.org/mail-archive/web/mile/current/msg01256.html Roman --_000_359EC4B99E040048A7131E0F4E113AFC54C1878Dmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

The response to scoping discussion #2 [1] and the su= bsequent discussion around conveying timing information [2] began the speci= fication of @indicator-uid and @indicator-set-id in 5070bis.  We agree= d that if an element had either an @indicator-uid or set-id then all aggregated elements nested in it were considered part o= f the indicator.

 

A few basic question still remain.  This note i= s an attempt to clarify the community’s desires.

 

(1) What is the format of the of @indicator-uid? @in= dicator-set-id?

 

(2) Is the @indicator-uid identifier unique to the d= ocument (probably not?)? Unique to a given sender or recipient?  Globa= lly unique (like IncidentID)?

 

(3) Is there an assumption of shared state between a= sender and recipient?  Should a recipient understand/recognize the @i= ndicator-uid or @indicator-set-id, or will it be an opaque blob?=

 

(4)  If there is shared state between the sende= r and recipient, what should be done when a recipient gets an @indicator-se= t-id it doesn’t recognize?

 

(5) How should a recipient interpret an indicator th= at has an @indicator-set-id but no @indicator-uid?

 

(6) If an indicator is given an @indicator-uid and @= indicator-set-id, is it assumed that the uid is part of the described set?<= o:p>

 

 

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html

[2] http://www.ietf.org/mail-archive/web/mile/current/msg01256.html

 

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC54C1878Dmarathon_-- From rdd@cert.org Mon Jan 20 14:04:00 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087131A0233 for ; Mon, 20 Jan 2014 14:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og9d7is5RU2y for ; Mon, 20 Jan 2014 14:03:57 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6EAF1A0240 for ; Mon, 20 Jan 2014 14:03:56 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0KM3rEc000351; Mon, 20 Jan 2014 17:03:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390255433; bh=XT/5jWVdbXw4Tk1IuvbsbAL8wi7he4Y7/eNO7v5PTvc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To:Cc; b=lTQgjT0/oC+yQszUnyrWmmDSnZA9xz6lgM0D3jO+WPFJz1BLPT65o4X+rBv0EcM4T eoe8WWcy8eBq6PEaL2sOUUa3JJxFUz5icienrONnSwXDzFiNVRSALgexhH395K97iq SMB1F4DDITJyHO6acj63MMCcPA/+M08TPWaHh7VM= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0KM3rON016815; Mon, 20 Jan 2014 17:03:53 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 20 Jan 2014 17:03:53 -0500 From: "Roman D. Danyliw" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: [mile] Documenting DomainData Thread-Index: AQHPFeZKcVHy8XjkSUe8d5nwrbpqVpqOITGA Date: Mon, 20 Jan 2014 22:03:51 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C18CF6@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C18CF6marathon_" MIME-Version: 1.0 Subject: Re: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 22:04:00 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C18CF6marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Understood on #1 and #3. I still need a little more clarification on your = answer to question #2, "RelatedDNS lets you add any record type to expand o= ut what is possible from the Domain data class. You can also list what typ= e of record you are including." To restate, RelatedDNS represents DNS reco= rds for a domain specified in DomainData/Name? If so, what exactly goes in= to the element content of RelatedDNS which is defined as xs:string? For ex= ample, if I had an AXFR record () how would= this be encoded? Since Node/DomainData/DateDomainWasChecked represents when Node/DomainData/= Name was resolved (where the IP address is stored in Node/Address), is ther= e a similar construct for these other record types in RelatedDNS? Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Monday, January 20, 2014 8:48 AM To: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hi Roman, #1 I thought the answer was yes, but it would be good to hear if anyone thi= nks it is too much detail now. #2 RelatedDNS lets you add any record type to expand out what is possible f= rom the Domain data class. You can also list what type of record you are i= ncluding. #3 I don't think there is a concern in adjusting the names for consistency. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, January 17, 2014 9:32 PM To: mile@ietf.org Subject: [mile] Documenting DomainData Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_359EC4B99E040048A7131E0F4E113AFC54C18CF6marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

Understood on #1 and #= 3.  I still need a little more clarification on your answer to questio= n #2, “RelatedDNS lets you add a= ny record type to expand out what is possible from the Domain data class.  You can also list what type of record you are= including.”  To restate, RelatedDNS represents DNS records for = a domain specified in DomainData/Name?  If so, what exactly goes into = the element content of RelatedDNS which is defined as xs:string?  For example, if I had an AXFR record (<RelatedDNS Reco= rdType=3D”AXRF”>) how would this be encoded?

 

Since Node/DomainData/= DateDomainWasChecked represents when Node/DomainData/Name was resolved (whe= re the IP address is stored in Node/Address), is there a similar construct = for these other record types in RelatedDNS?

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: Monday, January 20, 2014 8:48 AM
To: Roman D. Danyliw; mile@ietf.org
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

#1 I thought the answe= r was yes, but it would be good to hear if anyone thinks it is too much det= ail now.

 

#2 RelatedDNS lets you= add any record type to expand out what is possible from the Domain data cl= ass.  You can also list what type of record you are including.

 

#3 I don’t think= there is a concern in adjusting the names for consistency.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, January 17, 2014 9:32 PM
To: mile@ietf.org
Subject: [mile] Documenting DomainData

 

Hello!

 

Since being copied from RFC5901 into 5070bis, Domain= Data has evolved.  Currently the two definition differ as follows:

 

** 5070bis added DomainData@{indicator-uid, indicato= r-set-id}

** 5070bis added DomainData/RelatedDNS

** 5070bis uses iodef:Contact for DomainData/DomainC= ontacts/Contact instead of phish:Contact which added classes and attributes= to Contact

 

A few questions:

 

(1) Since bits and pieces were added and modified in= the cut-and-paste from 5901, is there agreement that we don’t need t= o remove anything from DomainData?  Do we want to represent this level= of detail in the core IODEF data model?

 

(2) RelatedDNS was added to DomainData and is not pr= esent in RFC5901.  There is no descriptive text.  Could someone s= hed light on the purpose of this class.

 

(3) The attributes DomainData@{SystemStatus, DomainS= tatus} and RelatedDNS@RecordType don't follow the naming convention of lowe= r case names separated by a hyphen.  As in other cases where classes h= ave been moved, I would be inclined to rename the attributes.  Any concern in doing that?

 

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC54C18CF6marathon_-- From rdd@cert.org Tue Jan 21 19:41:24 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF561A0016 for ; Tue, 21 Jan 2014 19:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EbXWWMDAWNb for ; Tue, 21 Jan 2014 19:41:22 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 625FC1A0017 for ; Tue, 21 Jan 2014 19:41:22 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0M3fL0s029577 for ; Tue, 21 Jan 2014 22:41:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390362081; bh=hE5Qr9EujR6ht5pL+72Qs0xEDtKzf5yUT1sErv8EbYo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=XKixtmx+LOBW6xUBRHzFjyOHIqjksalx0K8fpkQmAz1uJmEh6uYOFAbDJwQkJFVSx CSvGGEdbV2z5lwFXoVos+jG+v1LlGjfXhEPzLe5tSNmFxoE9A9RtzH/W1wGhWKO91o xsAzv5rypzBx0PChGepMPzTidz+h6m/HkfqcpPSA= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0M3fL8g016628 for ; Tue, 21 Jan 2014 22:41:21 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Tue, 21 Jan 2014 22:41:21 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Impact to the business (Issue #36) Thread-Index: Ac8XI0GRRx+PDs23Ts6TaQfVOj4fvg== Date: Wed, 22 Jan 2014 03:41:20 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1AB40@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Impact to the business (Issue #36) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 03:41:24 -0000 Good evening! Issue #36, http://tools.ietf.org/wg/mile/trac/ticket/36, is tracking the ne= ed to represent a summary of the impact an incident had on the organization= in 5070bis. To address this need, I would propose adding a new class, BusinessImpact, t= o Assessment. +-------------------------+ | Assessment | +-------------------------+ | ENUM occurrence |<>--{0..*}--[ Impact ] | ENUM restriction |<>--{0..*}--[ BusinessImpact ] | STRING indicator-uid |<>--{0..*}--[ TimeImpact ] | STRING indicator-set-id |<>--{0..*}--[ MonetaryImpact ] | |<>--{0..*}--[ Counter ] | |<>--{0..1}--[ Confidence ] | |<>--{0..*}--[ AdditionalData ] +-------------------------+ The BusinessImpact class describes and characterizes the degree to which th= e function of the organization was impacted by the Incident. The element body describes the impact to the organization as a free-form te= xt string. The two attributes characterize the impact. +-------------------------+ | BusinessImpact | +-------------------------+ | ML_STRING | | | | ENUM severity | | ENUM type | +-------------------------+ @severity (characterizes the severity of the incident on business functions= , from NIST SP800-61 Table 3-2) None =3D No effect to the organization's ability to provide all services to= all users Low =3D Minimal effect as the organization can still provide all critical s= ervices to all users but has lost efficiency Medium =3D The organization has lost the ability to provide a critical serv= ice to a subset of system users High =3D The organization is no longer able to provide some critical servic= es to any users unknown =3D The impact is unknown ext-severity =3D Extension mechanism @type (characterizes the effect this incident had on the business) breach-propriety =3D Sensitive or proprietary information was accessed or e= xfiltrated breach-privacy =3D Personally identifiable information was accessed or exfi= ltrated loss-of-integrity =3D Sensitive or proprietary information was changed or d= eleted loss-of-service =3D Service delivery was disrupted loss-financial =3D Money or services were stolen degraded-reputation =3D The reputation of the organization's brand was dimi= nished asset-destruction =3D A cyber-physical system was damaged legal =3D Incident resulted in legal or regulatory action ext-type Extension mechanism Any thoughts? @type might be missing a few values. Roman From rdd@cert.org Tue Jan 21 20:25:15 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C891A01BF for ; Tue, 21 Jan 2014 20:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfnMlEPJY8EX for ; Tue, 21 Jan 2014 20:25:11 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4F1A01C4 for ; Tue, 21 Jan 2014 20:25:08 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0M4P7gr030143 for ; Tue, 21 Jan 2014 23:25:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390364707; bh=mW4zsHVDN+qlq4yUtfKM1wXgPw/P7t4HTTScK2mmxr4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=TYuIOyD4o0N3hyuisoidSLwQci0PhRDntY8Fqj6wbrNr+FmcVTt46TqfHiLe8+kFY ciY3A9nh9KVpuiRHMcetCbb2kQ8v5AIjl9P70cX3Hys08ohnvPJesAk64utzejzr4W B0hDOylppRwVIJMyCvjV8HQmoy/n7jZrxbAVixHs= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0M4P9oD010204 for ; Tue, 21 Jan 2014 23:25:09 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Tue, 21 Jan 2014 23:25:06 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Addressing 5070bis schema comments (Issue #21) Thread-Index: Ac8XI/SP77e+P50aTEqEDMQDNw/g0w== Date: Wed, 22 Jan 2014 04:25:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1ABD5@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Addressing 5070bis schema comments (Issue #21) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 04:25:15 -0000 Good evening! Issue #21 is tracking the need to either act on or delete various questions= noted in the 5070bis schema. This note is intended to call out each of th= ese comments and open the discussion on what to do. =20 With all of the snippets of text presented here for clarity, my recommendat= ions are noted as "RD" so it's easier to follow along when others add their= thinking. (1) In Reference class: " (RD) I'm not sure what the first question is asking as Reference has both a= n @indicator-set-id and @indicator-uid. To the second question, using indi= cator-uid in a way limit with whom to share information is a use case I hav= en't seen previously documented. Could the interested/originating party pl= ease clarify. (2) In Impact@type: "" (RD) While multiple attributes can't occur in a single class, multiple inst= ances of Impact are possible in a single instance of Assessment. I would r= ecommend that this is sufficient and to delete this comment. (3) In Flow "" (RD) This comment notes a change in the data model. However, the modeling = flexibility this change is intended to support is not documented. This is = an action. (4) In Service " " (RD) An known, issue. Whether we need to place in the same class to repres= ent email information was posed to the list, http://www.ietf.org/mail-archi= ve/web/mile/current/msg01275.html. =20 (5) In EmailInfo "" (RD) If we want an extension mechanism we could either implement something = like ApplicationHeader to allow arbitrary Email headers, or add in Addition= alData. I recommend the former and this is tracked in Issue #24. To the s= econd question, I don't understand the purpose of an IANA table in this con= text. Could the interested/originating party please clarify. (6) In WindowsRegistryKeysModified " (RD) I don't understand which class the pronoun "this" is referencing to re= ason about whether it should be divided into multiple classes. Could the in= terested/originating party please clarify. (7) In HashInformation "" (RD) I would recommend it. By adding AdditionalData, an extension could a= dd richer file information. Supporting this richer information is tracked = as Issue #23. =20 (8) In HashInformation@type "" (RD) I don't appreciate the issue here. Could the interested/originating p= arty please clarify. (9) In SoftwareType "" (RD) I recommend having a separate discussion on how to best represent it. = For example, HTTPUserAgent could also be represented as in Service/Applica= tionHeader. Roman From kathleen.moriarty@emc.com Wed Jan 22 15:38:05 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A21A051F for ; Wed, 22 Jan 2014 15:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bVtUFh4duzs for ; Wed, 22 Jan 2014 15:38:02 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 581031A0511 for ; Wed, 22 Jan 2014 15:38:02 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0MNbpXA018270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 18:37:51 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0MNbpXA018270 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390433871; bh=kCQTLUTDj4USl5A+Fyws4u9X5zs=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lXjiCL9frgpwCSf3TF4dSrOVCkeFi85p6JhK3hn3fy28WIDCEjrPu3qCO93raDmEi kcz/3lDdo+JpjZcfEoMB54ROg9ks070DZ66wFhgG/fcCW4oIyKtdDyZRjfukxDdIs5 R1//MUXEaRsAc5B6ZODHC5irs10Cs1nf4F1kxfqw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0MNbpXA018270 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd54.lss.emc.com (RSA Interceptor); Wed, 22 Jan 2014 18:37:42 -0500 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0MNbfNJ022447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 18:37:41 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub34.corp.emc.com ([::1]) with mapi; Wed, 22 Jan 2014 18:37:41 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 22 Jan 2014 18:37:39 -0500 Thread-Topic: Impact to the business (Issue #36) Thread-Index: Ac8XI0GRRx+PDs23Ts6TaQfVOj4fvgAZR7Bg Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C1AB40@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1AB40@marathon> 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-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Impact to the business (Issue #36) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 23:38:05 -0000 +1 for adding in BusinessImpact with your proposal. Can you make sure @type can have other values in the schema with an ext- ? Thanks, Kathleen -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, January 21, 2014 10:41 PM To: mile@ietf.org Subject: [mile] Impact to the business (Issue #36) Good evening! Issue #36, http://tools.ietf.org/wg/mile/trac/ticket/36, is tracking the ne= ed to represent a summary of the impact an incident had on the organization= in 5070bis. To address this need, I would propose adding a new class, BusinessImpact, t= o Assessment. +-------------------------+ | Assessment | +-------------------------+ | ENUM occurrence |<>--{0..*}--[ Impact ] | ENUM restriction |<>--{0..*}--[ BusinessImpact ] | STRING indicator-uid |<>--{0..*}--[ TimeImpact ] | STRING indicator-set-id |<>--{0..*}--[ MonetaryImpact ] | |<>--{0..*}--[ Counter ] | |<>--{0..1}--[ Confidence ] | |<>--{0..*}--[ AdditionalData ] +-------------------------+ The BusinessImpact class describes and characterizes the degree to which th= e function of the organization was impacted by the Incident. The element body describes the impact to the organization as a free-form te= xt string. The two attributes characterize the impact. +-------------------------+ | BusinessImpact | +-------------------------+ | ML_STRING | | | | ENUM severity | | ENUM type | +-------------------------+ @severity (characterizes the severity of the incident on business functions= , from NIST SP800-61 Table 3-2) None =3D No effect to the organization's ab= ility to provide all services to all users Low =3D Minimal effect as the or= ganization can still provide all critical services to all users but has los= t efficiency Medium =3D The organization has lost the ability to provide a = critical service to a subset of system users High =3D The organization is n= o longer able to provide some critical services to any users unknown =3D Th= e impact is unknown ext-severity =3D Extension mechanism @type (characterizes the effect this incident had on the business) breach-p= ropriety =3D Sensitive or proprietary information was accessed or exfiltrat= ed breach-privacy =3D Personally identifiable information was accessed or e= xfiltrated loss-of-integrity =3D Sensitive or proprietary information was c= hanged or deleted loss-of-service =3D Service delivery was disrupted loss-f= inancial =3D Money or services were stolen degraded-reputation =3D The repu= tation of the organization's brand was diminished asset-destruction =3D A c= yber-physical system was damaged legal =3D Incident resulted in legal or re= gulatory action ext-type Extension mechanism Any thoughts? @type might be missing a few values. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Jan 22 15:50:54 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1D41A012C for ; Wed, 22 Jan 2014 15:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2XrV6WtTGdS for ; Wed, 22 Jan 2014 15:50:51 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF441A04E2 for ; Wed, 22 Jan 2014 15:50:49 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0MNoWOZ025725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 18:50:36 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0MNoWOZ025725 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390434636; bh=PzzcrHMtfjUrXNM1LtNteN1Hc28=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=ecZo/oHpmK4Fp58vogIST56ZutG1kbIYc+PYvkP8zhlbPWFC6y66TydbG9c5HgYhs jDQKf6nJyXWfDJrRH20mbIaJo/v/V5tmgn4re/5may+x9VOuFH9tDP0ADj3ATS3YV2 WubwiWitH0wh4Oyz+bK50c2r64mL6SCp6IrMR4Ms= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s0MNoWOZ025725 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 22 Jan 2014 18:50:17 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0MNoGg5023855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 18:50:17 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Wed, 22 Jan 2014 18:50:16 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 22 Jan 2014 18:50:14 -0500 Thread-Topic: [mile] Documenting DomainData Thread-Index: AQHPFeZKcVHy8XjkSUe8d5nwrbpqVpqOITGAgAAOhgA= Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> <359EC4B99E040048A7131E0F4E113AFC54C18CF6@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C18CF6@marathon> 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="_004_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: Re: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 23:50:54 -0000 --_004_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_ Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_" --_000_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, I was able to dig up an example from the group that was proposing the addit= ion of RelatedDNS to the DomainData class that was added from RFC5901. Pan= os may have other examples planned for the IODEF Guidance document. I think as long as the data of other records can be included, the intent wi= ll be met for the requestors. See the attached example and I am sure a pro= posal that alters it, but provides the ability to include that information = would be fine. Anyone else? Thanks, Kathleen From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Monday, January 20, 2014 5:04 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hello! Understood on #1 and #3. I still need a little more clarification on your = answer to question #2, "RelatedDNS lets you add any record type to expand o= ut what is possible from the Domain data class. You can also list what typ= e of record you are including." To restate, RelatedDNS represents DNS reco= rds for a domain specified in DomainData/Name? If so, what exactly goes in= to the element content of RelatedDNS which is defined as xs:string? For ex= ample, if I had an AXFR record () how would= this be encoded? Since Node/DomainData/DateDomainWasChecked represents when Node/DomainData/= Name was resolved (where the IP address is stored in Node/Address), is ther= e a similar construct for these other record types in RelatedDNS? Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Monday, January 20, 2014 8:48 AM To: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hi Roman, #1 I thought the answer was yes, but it would be good to hear if anyone thi= nks it is too much detail now. #2 RelatedDNS lets you add any record type to expand out what is possible f= rom the Domain data class. You can also list what type of record you are i= ncluding. #3 I don't think there is a concern in adjusting the names for consistency. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, January 17, 2014 9:32 PM To: mile@ietf.org Subject: [mile] Documenting DomainData Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

I was able to dig up an example from the group tha= t was proposing the addition of RelatedDNS to the DomainData class that was= added from RFC5901.  Panos may have other examples planned for the IO= DEF Guidance document.

 

I think as long as the data of other records can be= included, the intent will be met for the requestors.  See the attache= d example and I am sure a proposal that alters it, but provides the ability= to include that information would be fine.

 

Anyone else?

 <= /span>

Thanks,

Kathleen<= o:p>

 

 

From:= Roman D= . Danyliw [mailto:rdd@cert.org]
Sent: Monday, January 20, 2014 5= :04 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: R= E: [mile] Documenting DomainData

 

Hello!

 

Understood on #1 and #3.  I still need a little mor= e clarification on your answer to question #2, “RelatedDNS lets you a= dd any record type to expand out what is possible from the Domain data clas= s.  You can also list what type of record you are including.”&nb= sp; To restate, RelatedDNS represents DNS records for a domain specified in= DomainData/Name?  If so, what exactly goes into the element content o= f RelatedDNS which is defined as xs:string?  For example, if I had an = AXFR record (<RelatedDNS RecordType=3D”AXRF”>) how would = this be encoded?

 

Since Node/DomainData/DateDomainWasChecked represents wh= en Node/DomainData/Name was resolved (where the IP address is stored in Nod= e/Address), is there a similar construct for these other record types in Re= latedDNS?

 

Roman

 

From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: Monday, January 2= 0, 2014 8:48 AM
To: Roman D. Danyliw; mile@ietf.org
Subject: RE: [mile] Documenting DomainDat= a

 

Hi Roman,

 

#1 I though= t the answer was yes, but it would be good to hear if anyone thinks it is t= oo much detail now.

 

#2 RelatedDNS lets you add any record type to expand= out what is possible from the Domain data class.  You can also list w= hat type of record you are including.

 

#3 I don’t think there is a co= ncern in adjusting the names for consistency.

 

Thanks,

Kathleen

 =

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, January 17, 2014 9:32 PM
To= : mile@ietf.org
Subject:= [mile] Documenting DomainData

 

Hello!

 

Since being co= pied from RFC5901 into 5070bis, DomainData has evolved.  Currently the= two definition differ as follows:

=  

** 5070bis added DomainData@{indicator= -uid, indicator-set-id}

** 5070bis added= DomainData/RelatedDNS

** 5070bis uses i= odef:Contact for DomainData/DomainContacts/Contact instead of phish:Contact= which added classes and attributes to Contact

 

A few questions:

 

(1) Sin= ce bits and pieces were added and modified in the cut-and-paste from 5901, = is there agreement that we don’t need to remove anything from DomainD= ata?  Do we want to represent this level of detail in the core IODEF d= ata model?

 

(2) RelatedDNS was added to DomainData and is not present in R= FC5901.  There is no descriptive text.  Could someone shed light = on the purpose of this class.

 = ;

(3) The attributes DomainData@{SystemStatus= , DomainStatus} and RelatedDNS@RecordType don't follow the naming conventio= n of lower case names separated by a hyphen.  As in other cases where = classes have been moved, I would be inclined to rename the attributes. = ; Any concern in doing that?

 =

Roman

= --_000_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_-- --_004_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_ Content-Type: text/xml; name="Spearphish-updatedIODEF-scenario1_v1.xml" Content-Description: Spearphish-updatedIODEF-scenario1_v1.xml Content-Disposition: attachment; filename="Spearphish-updatedIODEF-scenario1_v1.xml"; size=7603; creation-date="Wed, 22 Jan 2014 23:46:48 GMT"; modification-date="Wed, 22 Jan 2014 23:46:48 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxJT0RFRi1Eb2N1bWVudCB2 ZXJzaW9uPSIxLjAwIiBsYW5nPSJlbiINCiAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpu czppb2RlZi0xLjAiDQogICAgeG1sbnM6aW9kZWY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6aW9k ZWYtMS4wIg0KICAgIHhtbG5zOmlvZGVmLXNjaT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczppb2Rl Zi1zY2ktMS4wIg0KICAgIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEtaW5zdGFuY2UiDQogICAgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1s ZHNpZyMiPg0KICAgICA8aW9kZWY6SW5jaWRlbnQgcHVycG9zZT0icmVwb3J0aW5nIj4NCiAgICAg ICAgICA8aW9kZWY6SW5jaWRlbnRJRCBuYW1lPSJjc2lydC5leGFtcGxlLmNvbSI+MTg5NjAxPC9p b2RlZjpJbmNpZGVudElEPg0KICAgICAgICAgPGlvZGVmOlN0YXJ0VGltZT4yMDEzLTAxLTA0VDA4 OjAxOjM0KzAwOjAwPC9pb2RlZjpTdGFydFRpbWU+DQogICAgICAgICA8aW9kZWY6U3RvcFRpbWU+ MjAxMy0wMS0wNFQwODozMToyNyswMDowMDwvaW9kZWY6U3RvcFRpbWU+DQogICAgICAgICA8aW9k ZWY6RGV0ZWN0VGltZT4yMDEzLTAxLTA0VDA4OjA2OjEyKzAwOjAwPC9pb2RlZjpEZXRlY3RUaW1l Pg0KICAgICAgICAgPGlvZGVmOlJlcG9ydFRpbWU+MjAxMy0wMS0wNFQwOToxNTo0NSswMDowMDwv aW9kZWY6UmVwb3J0VGltZT4NCiAgICAgICAgIDxpb2RlZjpkZXNjcmlwdGlvbj5aZXVzIFNwZWFy IFBoaXNoaW5nIEUtbWFpbCB3aXRoIE1hbHdhcmUgQXR0YWNobWVudDwvaW9kZWY6ZGVzY3JpcHRp b24+DQogICAgICAgICAgICA8aW9kZWY6QXNzZXNzbWVudCBvY2N1cnJlbmNlPSJwb3RlbnRpYWwi Pg0KICAgICAgICAgICAgICAgIDxpb2RlZjpJbXBhY3Qgc2V2ZXJpdHk9Im1lZGl1bSIgdHlwZT0i aW5mby1sZWFrIj4NCiAgICAgICAgICAgICAgICBNYWx3YXJlIHdpdGggQ29tbWFuZCBhbmQgQ29u dHJvbCBTZXJ2ZXIgYW5kIFN5c3RlbSBDaGFuZ2VzPC9pb2RlZjpJbXBhY3Q+DQogICAgICAgICAg ICA8L2lvZGVmOkFzc2Vzc21lbnQ+DQogICAgICAgICAgICA8aW9kZWY6Q29udGFjdCByb2xlPSJj cmVhdG9yIiB0eXBlPSJvcmdhbml6YXRpb24iPg0KICAgICAgICAgICAgICAgIDxpb2RlZjpDb250 YWN0TmFtZT5leGFtcGxlLmNvbSBDU0lSVDwvaW9kZWY6Q29udGFjdE5hbWU+DQogICAgICAgICAg ICAgICAgPGlvZGVmOkVtYWlsPmNvbnRhY3RAY3NpcnQuZXhhbXBsZS5jb208L2lvZGVmOkVtYWls Pg0KICAgICAgICAgICAgPC9pb2RlZjpDb250YWN0Pg0KICAgICAgICAgICAgPGlvZGVmOkV2ZW50 RGF0YT4NCiAgICAgICAgICAgICAgPGlvZGVmOkRlc2NyaXB0aW9uPlRhcmdldGluZyBEZWZlbnNl IENvbnRyYWN0b3JzLCBzcGVjaWZpY2FsbHkNCiAgICAgICAgICAgICAgICAgYm9hcmQgbWVtYmVy cyBhdHRlbmRpbmcgQUNJSVMgQ29uPC9pb2RlZjpEZXNjcmlwdGlvbj4NCiAgICAgICAgICAgIDwh LS0gTWF5IHdhbnQgdG8gYWRkIG5ldyBvcHRpb25zIGZvciBhY3Rpb24gYW5kIGV4dGVuZCB3aXRo IGFuIElBTkEgdGFibGUgLS0+DQogICAgICAgICAgICA8aW9kZWY6RXhwZWN0YXRpb24gYWN0aW9u PSJvdGhlciIvPg0KICAgICAgICAgICAgPGlvZGVmOk1ldGhvZD4NCiAgICAgICAgICAgICAgIDwh LS0gVXNlZCBpbmRpY2F0b3JfdWlkIHRvIHRpZSB0aGUgcmVmZXJlbmNlIHRvIHRoZSBmaWxlIGhh c2gNCiAgICAgICAgICAgICAgICAgICAgYXMgdGhlIHpldXMgZmlsZSAtLT4NCiAgICAgICAgICAg ICAgIDxpb2RlZjpSZWZlcmVuY2UgaW5kaWNhdG9yX3VpZD0iMTIzNCI+DQogICAgICAgICAgICAg ICAgICA8aW9kZWY6UmVmZXJlbmNlTmFtZT5aZXVzPC9pb2RlZjpSZWZlcmVuY2VOYW1lPg0KICAg ICAgICAgICAgICAgICAgPCEtLSBObyBVUkwgcHJvdmlkZWQsIGJ1dCBpdCBjb3VsZCBiZSBhZGRl ZCBmb3IgdGhlIHJlZmVyZW5jZSAtLT4NCiAgICAgICAgICAgICAgICAgIDwvaW9kZWY6UmVmZXJl bmNlPg0KICAgICAgICAgICAgPC9pb2RlZjpNZXRob2Q+DQogICAgICAgICAgICA8aW9kZWY6Rmxv dz4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIMKgPGlvZGVmOlN5c3RlbSBjYXRlZ29yeT0i c291cmNlIj4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxpb2RlZjpOb2Rl Pg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGlvZGVmOkFkZHJlc3Mg Y2F0ZWdvcnk9InVybCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuemV1 c2V2aWwuY29tPC9pb2RlZjpBZGRyZXNzPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImlwdjQtYWRkciI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgIDE5Ni4xNjcuMTQuODE8L2lvZGVmOkFkZHJlc3M+DQrCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImFzIj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgMjI1PC9pb2RlZjpBZGRyZXNzPg0KPCEtLSBDSEFO R0UgUXVlc3Rpb246IFNob3VsZCB3ZSBhZGQgYSB2YWx1ZSBmb3IgdHlwZSB0byBpbmNsdWRlIEFT TiBOYW1lDQogYW5kIEFTIFByZWZpeD8gLS0+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgPGlvZGVmOkFkZHJlc3MgY2F0ZWdvcnk9ImV4dC12YWx1ZSIgZXh0LWNhdGVn b3J5PSJhcy1uYW1lIj4NCiAgICAgICAgICAgICAgICAgICAgICBWSVJHSU5JQS1BUyAtIFVuaXZl cnNpdHkgb2YgVmlyZ2luaWHigJ08L2lvZGVmOkFkZHJlc3M+DQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIMKgwqA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iZXh0LXZhbHVlIiBl eHQtY2F0ZWdvcnk9ImFzLXByZWZpeCI+DQoxOC4xNDQuMC4wLzE2PC9pb2RlZjpBZGRyZXNzPg0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxpb2RlZjpOb2RlUm9sZSBj YXRlZ29yeT0id3d3IiBhdHRhY2t0eXBlPSJtYWx3YXJlLWRpc3RyaWJ1dGlvbiIvPg0KwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPC9pb2RlZjpOb2RlPg0KICAgICAgICAgICAgICA8 L2lvZGVmOlN5c3RlbT4NCiAgICAgICAgICAgIDwvaW9kZWY6Rmxvdz4NCsKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPGlvZGVmOkZsb3c+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoDxpb2Rl ZjpTeXN0ZW0gY2F0ZWdvcnk9InNvdXJjZSI+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqA8aW9kZWY6Tm9kZT4NCiAgICAgICAgICAgICAgICAgICA8aW9kZWY6Tm9kZU5hbWU+ bWFpbDEuZXZpbGRhdmUuY29tPC9pb2RlZjpOb2RlTmFtZT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxpb2RlZjpBZGRyZXNzIGNhdGVnb3J5PSJpcHY0LWFkZHIiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAxNzYuMTU3LjMyLjE3PC9pb2RlZjpBZGRyZXNzPg0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxpb2RlZjpBZGRyZXNzIGNhdGVn b3J5PSJhc24iPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAyMjU8L2lvZGVmOkFkZHJlc3M+ DQo8IS0tIENIQU5HRSBRdWVzdGlvbjogU2hvdWxkIHdlIGFkZCBhIHZhbHVlIGZvciB0eXBlIHRv IGluY2x1ZGUgQVNOIE5hbWU/IC0tPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoDxpb2RlZjpBZGRyZXNzIGNhdGVnb3J5PSJleHQtdmFsdWUiIGV4dC1jYXRlZ29yeT0i YXMtbmFtZSI+DQogICAgICAgICAgICAgICAgICAgICAgVklSR0lOSUEtQVMgLSBVbml2ZXJzaXR5 IG9mIFZpcmdpbmlh4oCdDQo8L2lvZGVmOkFkZHJlc3M+DQogICA8aW9kZWY6RG9tYWluRGF0YT4N CiAgICAgIDxpb2RlZjpOYW1lPmV2aWxkYXZlLmNvbTwvaW9kZWY6TmFtZT4NCiAgICAgIDxpb2Rl ZjpEYXRlRG9tYWluV2FzQ2hlY2tlZD4yMDEzLTAxLTA0VDA5OjEwOjI0KzAwOjAwPC9pb2RlZjpE YXRlRG9tYWluV2FzQ2hlY2tlZD4NCiAgICAgIDxpb2RlZjpSZWxhdGVkRE5TIFJlY29yZFR5cGU9 Ik1YIj5ldmlsZGF2ZS5jb20gTVggcHJlZmVybmNlID0gMTAsIG1haWwgZXhjaGFuZ2VyID0gbWFp bDEuZXZpbGRhdmUuY29tPC9pb2RlZjpSZWxhdGVkRE5TPg0KICAgICAgPGlvZGVmOlJlbGF0ZWRE TlMgUmVjb3JkVHlwZT0iQSI+bWFpbDEuZXZpbGRhdmUuY29tIGludGVybmV0IGFkZHJlc3MgPSAx NzYuMTU3LjMyLjE3PC9pb2RlZjpSZWxhdGVkRE5TPg0KICAgICAgPGlvZGVmOlJlbGF0ZWRETlMg UmVjb3JkVHlwZT0iU1BGIj56dWVzZXZpbC5jb20uIElOIFRYVCBcInY9c3BmMSBhIG14IOKAk2Fs bFwiPC9pb2RlZjpSZWxhdGVkRE5TPg0KICAgPC9pb2RlZjpEb21haW5EYXRhPg0KPCEtLSBBc3N1 bWluZyBpdCBpcyB0aGUgbWFpbCBzZXJ2ZXIgZm9yIHRoZSBzcGVhciBwaGlzaGluZyBlbWFpbCBh bmQgdGhhdCB3ZSB3YW50IHRoZSBjb250ZXh0IC0tPg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoDxpb2RlZjpOb2RlUm9sZSBjYXRlZ29yeT0ibWFpbCIgYXR0YWNrdHlw ZT0ic3BlYXItcGhpc2hpbmciLz4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDwv aW9kZWY6Tm9kZT4NCiAgICAgICAgICAgICAgICAgPGlvZGVmOlNlcnZpY2U+DQogICAgICAgICAg ICAgICAgICAgIDxpb2RlZjpFbWFpbEluZm8+DQogICAgICAgICAgICAgICAgICAgICAgPGlvZGVm OkVtYWlsPmVtYWlsZGF2ZUBldmlsZGF2ZS5jb208L2lvZGVmOkVtYWlsPg0KICAgICAgICAgICAg ICAgICAgICAgPGlvZGVmOkVtYWlsU3ViamVjdD5Kb2luIHVzIGF0IEFDSUlTIENvbjwvaW9kZWY6 RW1haWxTdWJqZWN0Pg0KICAgICAgICAgICAgICAgICAgICAgPGlvZGVmOlgtTWFpbGVyPlN0b3Jt UmlkZXIgNC4wPC9pb2RlZjpYLU1haWxlcj4NCjwhLS0gR0FQIC0gbmVlZCB0byBpbmNsdWRlIFNQ RiwgTUlNRVR5cGUsIGFuZCB0aGF0IHRoZXJlIGlzIE5PIERLSU0gc2lnbmF0dXJlIC0tPg0KICAg ICAgICAgICAgICAgICAgICA8L2lvZGVmOkVtYWlsSW5mbz4NCiAgICAgICAgICAgICAgICAgPC9p b2RlZjpTZXJ2aWNlPg0KICAgICAgICAgICAgICA8L2lvZGVmOlN5c3RlbT4NCiAgICAgICAgICAg ICAgPGlvZGVmOlN5c3RlbSBjYXRlZ29yeT0idGFyZ2V0Ij4NCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqA8aW9kZWY6Tm9kZT4NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqA8aW9kZWY6QWRkcmVzcyBjYXRlZ29yeT0iaXB2NCI+DQogICAgICAgICAgICAg ICAgICAgICAgMTkzLjE4Ni4xMzguMTAxPC9pb2RlZjpBZGRyZXNzPg0KwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgPC9pb2RlZjpOb2RlPg0KICDCoCDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8L2lvZGVmOlN5c3RlbT4NCiAgICAgICAgICAgIDwvaW9kZWY6Rmxvdz7CoMKgwqANCg0KICAg ICAgICAgICAgPGlvZGVmOlJlY29yZD4NCiAgICAgICAgICAgICAgPGlvZGVmOlJlY29yZERhdGE+ DQo8IS0tICBJbmNsdWRlZCBpbmZvcm1hdGlvbiBvbiBlbWFpbCBhdHRhY2htZW50IGhhc2ggLS0+ DQogICAgICAgICAgICAgICAgPGlvZGVmOkhhc2hJbmZvcm1hdGlvbiB0eXBlPSJmaWxlX2hhc2gi IGluZGljYXRvcl91aWQ9IjEyMzQiPg0KICAgICAgICAgICAgICAgICAgIDxpb2RlZjpGaWxlTmFt ZT5BQ0lJUyBDb24gU2lnbiBVcCBTaGVldC50eHQ8L2lvZGVmOkZpbGVOYW1lPg0KICAgICAgICAg ICAgICAgICAgIDxpb2RlZjpGaWxlU2l6ZT4xNTI8L2lvZGVmOkZpbGVTaXplPg0KICAgICAgICAg ICAgICAgIDxkczpSZWZlcmVuY2U+DQogICAgICAgICAgICAgICAgICAgPGRzOkRpZ2VzdE1ldGhv ZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTI1NiIvPg0K ICAgICAgICAgICAgICAgICAgICAgIDxkczpEaWdlc3RWYWx1ZT4NCiAgICAgICAgICAgICAgICAg ICAgICAgIDE0MWFjY2VjMjNlN2U1MTU3ZGU2MDg1M2NiMWUwMWJjMzgwNDJkMDhmOTA4NjA0MDgx NTMwMGI3ZmU3NWMxODQNCiAgICAgICAgICAgICAgICAgICAgICA8L2RzOkRpZ2VzdFZhbHVlPg0K ICAgICAgICAgICAgICAgIDwvZHM6UmVmZXJlbmNlPg0KICAgICAgICAgICAgICA8L2lvZGVmOkhh c2hJbmZvcm1hdGlvbj4NCiAgICAgICAgICAgICA8L2lvZGVmOlJlY29yZERhdGE+DQogICAgICAg ICAgICAgPGlvZGVmOlJlY29yZERhdGE+DQogICAgICAgICAgICAgIDwhLS0gSGFzaCB2YWx1ZSBm cm9tIGRpZ2l0YWwgc2lnbmF0dXJlIG9uIGVtYWlsIHVzaW5nIFBLSSBYLjUwOSANCiAgICAgICAg ICAgICAgICAgICBhbmQgd2FzIG5vdCBhIHZhbGlkIENlcnQgdXNlZCB0byBzaWduIHRoZSBlbWFp bCAtLT4NCiAgICAgICAgICAgICAgPGlvZGVmOkhhc2hJbmZvcm1hdGlvbiB0eXBlPSJQS0lfZW1h aWxfZHMiIHZhbGlkPSIwIj4NCiAgICAgICAgICAgICAgICA8ZHM6U2lnbmF0dXJlPg0KICAgICAg ICAgICAgICAgICA8ZHM6S2V5SW5mbz4NCiAgICAgICAgICAgICAgICAgICAgPGRzOlg1MDlEYXRh Pg0KICAgICAgICAgICAgICAgICAgICAgICA8ZHM6WDUwOUlzc3VlclNlcmlhbD4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRzOlg1MDlJc3N1ZXJOYW1lPkZha2VDQTwvZHM6WDUwOUlzc3Vl ck5hbWU+DQogICAgICAgICAgICAgICAgICAgICAgIDwvZHM6WDUwOUlzc3VlclNlcmlhbD4NCiAg ICAgICAgICAgICAgICAgICAgICAgPGRzOlg1MDlTdWJqZWN0TmFtZT5FdmlsRGF2ZTwvZHM6WDUw OVN1YmplY3ROYW1lPg0KICAgICAgICAgICAgICAgICAgICA8L2RzOlg1MDlEYXRhPg0KICAgICAg ICAgICAgICAgICA8L2RzOktleUluZm8+DQogICAgICAgICAgICAgICAgICAgIDxkczpTaWduZWRJ bmZvPg0KICAgICAgICAgICAgICAgICAgICAgPGRzOlJlZmVyZW5jZT4NCiAgICAgICAgICAgICAg ICAgICAgICAgIDxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8y MDAxLzA0L3htbGVuYyNzaGEyNTYiLz4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkczpEaWdl c3RWYWx1ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAzNTJiZGRlYzEzZTRlNTI1N2VlNjM4 NTRjYjFmMDVkZTQ4MDQzZDA5ZjkwNzYwNzA4NDUzMDdiN2NlNzZjMTg1DQogICAgICAgICAgICAg ICAgICAgICAgICA8L2RzOkRpZ2VzdFZhbHVlPg0KICAgICAgICAgICAgICAgICAgICA8L2RzOlJl ZmVyZW5jZT4NCiAgICAgICAgICAgICAgICAgIDwvZHM6U2lnbmVkSW5mbz4NCiAgICAgICAgICAg ICAgICA8L2RzOlNpZ25hdHVyZT4NCiAgICAgICAgICAgICA8L2lvZGVmOkhhc2hJbmZvcm1hdGlv bj4NCiAgICAgICAgICA8L2lvZGVmOlJlY29yZERhdGE+DQogICAgICAgICA8L2lvZGVmOlJlY29y ZD7CoCANCiAgICAgICAgPC9pb2RlZjpFdmVudERhdGE+DQogICAgPC9pb2RlZjpJbmNpZGVudD4N CjwvSU9ERUYtRG9jdW1lbnQ+DQoNCg== --_004_F5063677821E3B4F81ACFB7905573F2406584BAEBFMX15Acorpemcc_-- From kathleen.moriarty@emc.com Wed Jan 22 16:08:28 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628BC1A0232 for ; Wed, 22 Jan 2014 16:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryFrc78pgONG for ; Wed, 22 Jan 2014 16:08:26 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C3E8C1A0171 for ; Wed, 22 Jan 2014 16:08:25 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0N08K8x028666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 19:08:21 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s0N08K8x028666 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390435701; bh=E7pGVNOjwbKSbkmUMWFGsMCO0Dw=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YJrvGc7kSyae6iJYuU4uljUggzICSDdkMvo3u4AH5XLD9cszmPorx+nW5gDes05Ro CjREj5Xtt/TqlbmwvT2TWZTQ7/ghNPfUWHE6+7L5f1/yQFTQAPQi46U5d4h2rrDrbQ UjVbBkqiz2iWlG9EU/G9N6xjSEhMKF3ju4TUYNVw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s0N08K8x028666 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 22 Jan 2014 19:08:06 -0500 Received: from mxhub38.corp.emc.com (mxhub38.corp.emc.com [128.222.70.105]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0N085of030746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 19:08:05 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Wed, 22 Jan 2014 19:08:05 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 22 Jan 2014 19:08:03 -0500 Thread-Topic: Addressing 5070bis schema comments (Issue #21) Thread-Index: Ac8XI/SP77e+P50aTEqEDMQDNw/g0wAZYTAQ Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C1ABD5@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1ABD5@marathon> 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-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Addressing 5070bis schema comments (Issue #21) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 00:08:28 -0000 Hi Roman, I'll answer in-line with KM> and using +1 where appropriate. Others, pleas= e chime in! Some of the questions were off-list in a group testing interoperability of = implementations and working against use cases. Some were questions to trac= k options and can just be removed. I tried to look up what I could and jog= my memory for other questions. Thanks, Kathleen -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, January 21, 2014 11:25 PM To: mile@ietf.org Subject: [mile] Addressing 5070bis schema comments (Issue #21) Good evening! Issue #21 is tracking the need to either act on or delete various questions= noted in the 5070bis schema. This note is intended to call out each of th= ese comments and open the discussion on what to do. =20 With all of the snippets of text presented here for clarity, my recommendat= ions are noted as "RD" so it's easier to follow along when others add their= thinking. (1) In Reference class: " (RD) I'm not sure what the first question is asking as Reference has both a= n @indicator-set-id and @indicator-uid. To the second question, using indi= cator-uid in a way limit with whom to share information is a use case I hav= en't seen previously documented. Could the interested/originating party pl= ease clarify. KM> Unfortunately, this was a discussion outside of mailing lists. I think= this may have to do with the walls needed within a product when you share = with multiple groups. If an indicator_UID is from a particular source, you= may have to restrict access to team members of one organization where some= may not have approved access for some data (clearance levels, privacy info= rmation, human resources sensitivity, etc.). (2) In Impact@type: "" (RD) While multiple attributes can't occur in a single class, multiple inst= ances of Impact are possible in a single instance of Assessment. I would r= ecommend that this is sufficient and to delete this comment. KM> +1 (3) In Flow "" (RD) This comment notes a change in the data model. However, the modeling = flexibility this change is intended to support is not documented. This is = an action. KM> +1 on the action. (4) In Service " " (RD) An known, issue. Whether we need to place in the same class to repres= ent email information was posed to the list, http://www.ietf.org/mail-archi= ve/web/mile/current/msg01275.html. =20 KM> OK, so this decision is tracked elsewhere... (5) In EmailInfo "" (RD) If we want an extension mechanism we could either implement something = like ApplicationHeader to allow arbitrary Email headers, or add in Addition= alData. I recommend the former and this is tracked in Issue #24. To the s= econd question, I don't understand the purpose of an IANA table in this con= text. Could the interested/originating party please clarify. KM> I think your proposal is fine. I think the IANA table suggestion was a= long the thought process of Take's SCI draft where entire schemas may get e= mbedded. (6) In WindowsRegistryKeysModified " (RD) I don't understand which class the pronoun "this" is referencing to re= ason about whether it should be divided into multiple classes. Could the in= terested/originating party please clarify. KM> I think there was no interest in additional changes and that folks were= happy with the current proposal, meaning you can just delete the comment. (7) In HashInformation "" (RD) I would recommend it. By adding AdditionalData, an extension could a= dd richer file information. Supporting this richer information is tracked = as Issue #23. =20 KM> +1 (8) In HashInformation@type "" (RD) I don't appreciate the issue here. Could the interested/originating p= arty please clarify. KM> I think this might be referring to key types, like X.509 or PGP, but I = believe that is covered in ds: (9) In SoftwareType "" (RD) I recommend having a separate discussion on how to best represent it. = For example, HTTPUserAgent could also be represented as in Service/Applica= tionHeader. KM> +1 on separate discussion I hope that helps! Kathleen Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Wed Jan 22 16:20:07 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9DB1A01DD for ; Wed, 22 Jan 2014 16:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuXoKs63uG7t for ; Wed, 22 Jan 2014 16:20:03 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id CC4621A01A5 for ; Wed, 22 Jan 2014 16:20:02 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0N0JxBh005913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 19:19:59 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s0N0JxBh005913 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390436399; bh=Y2RAlC/N2SnR8vBrW79VGDQ52DQ=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cnuN6HSLEN/Gw5NeBH1iMUZHwyJyUkv5tuEQAqr0g5JXon7ROKL4vdAlEsneVEp2C m0Rse2/XDMmjICBfAfhDEjbUmaRKgz5TWut25RMWjFioFqAI6zHJctTxVHYxB/740n mcvHZB3mrImIgXm/EfhnnjfpOZextAWQfAIo1kLg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s0N0JxBh005913 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 22 Jan 2014 16:19:48 -0800 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0N0JlJ3008948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 19:19:47 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 22 Jan 2014 19:19:47 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Wed, 22 Jan 2014 19:19:45 -0500 Thread-Topic: Attributes of the Key class Thread-Index: Ac8ROH1UKtJl+89zQoqJaQFudDjEbQAEDvZw Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C104F8@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C104F8@marathon> 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-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Attributes of the Key class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 00:20:07 -0000 Hi Roman, I'll answer in line. Others, please chime in. Thanks! Kathleen -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, January 14, 2014 10:25 AM To: mile@ietf.org Subject: [mile] Attributes of the Key class Hello, In reviewing the -03 draft, I have a few questions on the definition of the= Key class (Section 3.22.1). ** RegistryKeyModified/Key has the @ext-category attribute whose text read= s "extension category". Could someone please explain the purpose of this a= ttribute or provide better text. It seems like this attribute was a typo a= nd should really be named @ext-registryaction to extend @registryaction whe= n it is set to "ext-value". KM> I am having trouble finding this one in the current document.. ** RegistryKeyModified/Key also has the attributes @type and @type-ext list= ed in the text, but not in the schema. It is not documented but is describ= ed as having two enumerated values of "watchlist" and "ext-value". Could s= omeone please explain this attribute or provide better text. Also, the num= erated value of "ext-value" for @type is being used in a way inconsistently= with Section 5.1. We need to fix that. KM> Ah, okay from my last response, this additional context helps to see th= e intent. I think this was to provide a watchlist. The schema just had a = comment to see if it should be included. As long as you can include a watc= hlist, the intent would be met. The watchlist would be a list of values th= at may be ORed with other values in the list and an AND with the EventData = in the set. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Thu Jan 23 05:08:39 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753E31A043E for ; Thu, 23 Jan 2014 05:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5wuBSdcKJAe for ; Thu, 23 Jan 2014 05:08:37 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7BC1A0439 for ; Thu, 23 Jan 2014 05:08:37 -0800 (PST) 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/1408) with ESMTP id s0ND8XPp009105; Thu, 23 Jan 2014 08:08:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390482513; bh=HSgjE5kP4SJQlYAMdbvefSn0yJSY/fAcpEUHBGpKx0g=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=FvMDtniMGr6ibmwQRofsaMmTF59XCLFR3Fl9KEZvVuOYTn3tUFynamcrLjJBAJqQI whMZfe5j/jHJepWya7Y7Zplr7h/V510PLwwFRZjbp+Q3e0mcqC9zpLhr1AJ6VpZD83 NR51o7PEB2IhyNEKuFvRGVSoh0gqRrH7IlBDI+D4= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0ND8acQ029522; Thu, 23 Jan 2014 08:08:36 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 23 Jan 2014 08:08:32 -0500 From: "Roman D. Danyliw" To: "'Moriarty, Kathleen'" , "mile@ietf.org" Thread-Topic: Impact to the business (Issue #36) Thread-Index: Ac8XI0GRRx+PDs23Ts6TaQfVOj4fvgAZR7BgACzpoKA= Date: Thu, 23 Jan 2014 13:08:31 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1D307@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C1AB40@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Impact to the business (Issue #36) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 13:08:39 -0000 Definitely! BusinessImpact@{ext-severity, ext-type} are in the write-up bel= ow but I forgot to added them into the diagram. Roman -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]=20 Sent: Wednesday, January 22, 2014 6:38 PM To: Roman D. Danyliw; mile@ietf.org Subject: RE: Impact to the business (Issue #36) +1 for adding in BusinessImpact with your proposal. Can you make sure @type can have other values in the schema with an ext- ? Thanks, Kathleen -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, January 21, 2014 10:41 PM To: mile@ietf.org Subject: [mile] Impact to the business (Issue #36) Good evening! Issue #36, http://tools.ietf.org/wg/mile/trac/ticket/36, is tracking the ne= ed to represent a summary of the impact an incident had on the organization= in 5070bis. To address this need, I would propose adding a new class, BusinessImpact, t= o Assessment. +-------------------------+ | Assessment | +-------------------------+ | ENUM occurrence |<>--{0..*}--[ Impact ] | ENUM restriction |<>--{0..*}--[ BusinessImpact ] | STRING indicator-uid |<>--{0..*}--[ TimeImpact ] | STRING indicator-set-id |<>--{0..*}--[ MonetaryImpact ] | |<>--{0..*}--[ Counter ] | |<>--{0..1}--[ Confidence ] | |<>--{0..*}--[ AdditionalData ] +-------------------------+ The BusinessImpact class describes and characterizes the degree to which th= e function of the organization was impacted by the Incident. The element body describes the impact to the organization as a free-form te= xt string. The two attributes characterize the impact. +-------------------------+ | BusinessImpact | +-------------------------+ | ML_STRING | | | | ENUM severity | | ENUM type | +-------------------------+ @severity (characterizes the severity of the incident on business functions= , from NIST SP800-61 Table 3-2) None =3D No effect to the organization's ab= ility to provide all services to all users Low =3D Minimal effect as the or= ganization can still provide all critical services to all users but has los= t efficiency Medium =3D The organization has lost the ability to provide a = critical service to a subset of system users High =3D The organization is n= o longer able to provide some critical services to any users unknown =3D Th= e impact is unknown ext-severity =3D Extension mechanism @type (characterizes the effect this incident had on the business) breach-p= ropriety =3D Sensitive or proprietary information was accessed or exfiltrat= ed breach-privacy =3D Personally identifiable information was accessed or e= xfiltrated loss-of-integrity =3D Sensitive or proprietary information was c= hanged or deleted loss-of-service =3D Service delivery was disrupted loss-f= inancial =3D Money or services were stolen degraded-reputation =3D The repu= tation of the organization's brand was diminished asset-destruction =3D A c= yber-physical system was damaged legal =3D Incident resulted in legal or re= gulatory action ext-type Extension mechanism Any thoughts? @type might be missing a few values. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From iesg-secretary@ietf.org Thu Jan 23 05:11:34 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA871A00A5; Thu, 23 Jan 2014 05:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuwH0kScB4uN; Thu, 23 Jan 2014 05:11:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B181A0432; Thu, 23 Jan 2014 05:11:30 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123131130.1662.33884.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 05:11:30 -0800 Cc: mile mailing list , mile chair , RFC Editor Subject: [mile] Protocol Action: 'IODEF-extension for structured cybersecurity information' to Proposed Standard (draft-ietf-mile-sci-13.txt) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 13:11:34 -0000 The IESG has approved the following document: - 'IODEF-extension for structured cybersecurity information' (draft-ietf-mile-sci-13.txt) as Proposed Standard This document is the product of the Managed Incident Lightweight Exchange Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ Technical Summary The document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information . It provides the capability of embedding structured information, such as identifier- and XML-based information. It defines an IANA registry of external schemas that can be referenced from IODEF documents. Working Group Summary and Document Quality The document received extensive review from the working group, which led to significant changes in the document. Earlier versions of the document had significant potential IPR issues (references to trademarked schema names) as well as reference issues (normative references to non-standards documents); these have all been resolved satisfactorily by moving these references to an IANA registry of SCI specifications, and providing for long-term references to the MTI schema, MMDEF. Personnel Brian Trammell is the doc shepherd. Sean Turner is the responsible AD. From rdd@cert.org Thu Jan 23 05:20:26 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909DF1A00C2 for ; Thu, 23 Jan 2014 05:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRneFen9zn9U for ; Thu, 23 Jan 2014 05:20:22 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id A5E3E1A0114 for ; Thu, 23 Jan 2014 05:20:18 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0NDK94N009334; Thu, 23 Jan 2014 08:20:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390483209; bh=Z8OnRMKWhExyWarUui/jWQm7EjHGBVAi55GcTQqVICw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=cH4dQ8vE6GrdGfIrfUVcbCLdBlgdkcx5SgXE/RpwSGyoqmasNFbPDXI0WyGw44mYQ Rbkn4f5sstpxgSqJadgOuQH6GDtA0esRgfnFIxbbeahDnf5vFcECVPnP2ELSaiGdkR HUU39Gvpdf0LbBeOnoHLcf5HJ66LoLZVKznmIzlc= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0NDK8vO021596; Thu, 23 Jan 2014 08:20:09 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 23 Jan 2014 08:20:08 -0500 From: "Roman D. Danyliw" To: "'Moriarty, Kathleen'" , "mile@ietf.org" Thread-Topic: [mile] Documenting DomainData Thread-Index: AQHPFeZKcVHy8XjkSUe8d5nwrbpqVpqOITGAgAAOhgCABB0RoA== Date: Thu, 23 Jan 2014 13:20:08 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1D3AA@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> <359EC4B99E040048A7131E0F4E113AFC54C18CF6@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C1D3AAmarathon_" MIME-Version: 1.0 Subject: Re: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 13:20:26 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C1D3AAmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kathleen! The example was very helpful. Thank you. For discussion purposes on the list, here is a relevant excerpt from the pr= eviously attached file: evildave.com 2013-01-04T09:10:24+00:00 evildave.com MX prefernce =3D 10, mail = exchanger =3D mail1.evildave.com mail1.evildave.com internet address =3D = 176.157.32.17 zuesevil.com. IN TXT \"v=3Dspf1 a mx -= all\" Reading this particular example, I understand what information is being pas= sed along in the DNS record. Where I need help is how do we formally descr= ibe this format for the draft. Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 22, 2014 6:50 PM To: Roman D. Danyliw; mile@ietf.org Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com) Subject: RE: [mile] Documenting DomainData Hi Roman, I was able to dig up an example from the group that was proposing the addit= ion of RelatedDNS to the DomainData class that was added from RFC5901. Pan= os may have other examples planned for the IODEF Guidance document. I think as long as the data of other records can be included, the intent wi= ll be met for the requestors. See the attached example and I am sure a pro= posal that alters it, but provides the ability to include that information = would be fine. Anyone else? Thanks, Kathleen From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Monday, January 20, 2014 5:04 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hello! Understood on #1 and #3. I still need a little more clarification on your = answer to question #2, "RelatedDNS lets you add any record type to expand o= ut what is possible from the Domain data class. You can also list what typ= e of record you are including." To restate, RelatedDNS represents DNS reco= rds for a domain specified in DomainData/Name? If so, what exactly goes in= to the element content of RelatedDNS which is defined as xs:string? For ex= ample, if I had an AXFR record () how would= this be encoded? Since Node/DomainData/DateDomainWasChecked represents when Node/DomainData/= Name was resolved (where the IP address is stored in Node/Address), is ther= e a similar construct for these other record types in RelatedDNS? Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Monday, January 20, 2014 8:48 AM To: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hi Roman, #1 I thought the answer was yes, but it would be good to hear if anyone thi= nks it is too much detail now. #2 RelatedDNS lets you add any record type to expand out what is possible f= rom the Domain data class. You can also list what type of record you are i= ncluding. #3 I don't think there is a concern in adjusting the names for consistency. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, January 17, 2014 9:32 PM To: mile@ietf.org Subject: [mile] Documenting DomainData Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_359EC4B99E040048A7131E0F4E113AFC54C1D3AAmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kathleen!

 

The example was very h= elpful.  Thank you.

 

For discussion purpose= s on the list, here is a relevant excerpt from the previously attached file= :

<iodef:DomainData&g= t;

<iodef:Name>evil= dave.com</iodef:Name>

<iodef:DateDomainWa= sChecked>2013-01-04T09:10:24+00:00</iodef:DateDomainWasChecked>= ;

<iodef:RelatedDNS R= ecordType=3D"MX">evildave.com MX prefernce =3D 10, mail exchan= ger =3D mail1.evildave.com</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"A">mail1.evildave.com internet address =3D 176.15= 7.32.17</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"SPF">zuesevil.com. IN TXT \"v=3Dspf1 a mx &#= 8211;all\"</iodef:RelatedDNS>

</iodef:DomainData&= gt;

 

Reading this particula= r example, I understand what information is being passed along in the DNS r= ecord.  Where I need help is how do we formally describe this format f= or the draft. 

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: Wednesday, January 22, 2014 6:50 PM
To: Roman D. Danyliw; mile@ietf.org
Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com)
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

I was able to dig up a= n example from the group that was proposing the addition of RelatedDNS to t= he DomainData class that was added from RFC5901.  Panos may have other= examples planned for the IODEF Guidance document.

 

I think as long as the= data of other records can be included, the intent will be met for the requ= estors.  See the attached example and I am sure a proposal that alters= it, but provides the ability to include that information would be fine.

 

Anyone else?

 

Thanks,

Kathleen

 

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Monday, January 20, 2014 5:04 PM
To: Moriarty, Kathleen; mile@ietf.o= rg
Subject: RE: [mile] Documenting DomainData

 

Hello!

 

Understood on #1 and #= 3.  I still need a little more clarification on your answer to questio= n #2, “RelatedDNS lets you add any record type to expand out what is = possible from the Domain data class.  You can also list what type of record you are including.”  To restate, Relat= edDNS represents DNS records for a domain specified in DomainData/Name?&nbs= p; If so, what exactly goes into the element content of RelatedDNS which is= defined as xs:string?  For example, if I had an AXFR record (<RelatedDNS RecordType=3D”AXRF”>) how would= this be encoded?

 

Since Node/DomainData/= DateDomainWasChecked represents when Node/DomainData/Name was resolved (whe= re the IP address is stored in Node/Address), is there a similar construct = for these other record types in RelatedDNS?

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.mo= riarty@emc.com]
Sent: Monday, January 20, 2014 8:48 AM
To: Roman D. Danyliw; mile@ietf.org=
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

#1 I thought the answe= r was yes, but it would be good to hear if anyone thinks it is too much det= ail now.

 

#2 RelatedDNS lets you= add any record type to expand out what is possible from the Domain data cl= ass.  You can also list what type of record you are including.

 

#3 I don’t think= there is a concern in adjusting the names for consistency.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, January 17, 2014 9:32 PM
To: mile@ietf.org
Subject: [mile] Documenting DomainData

 

Hello!

 

Since being copied from RFC5901 into 5070bis, Domain= Data has evolved.  Currently the two definition differ as follows:

 

** 5070bis added DomainData@{indicator-uid, indicato= r-set-id}

** 5070bis added DomainData/RelatedDNS

** 5070bis uses iodef:Contact for DomainData/DomainC= ontacts/Contact instead of phish:Contact which added classes and attributes= to Contact

 

A few questions:

 

(1) Since bits and pieces were added and modified in= the cut-and-paste from 5901, is there agreement that we don’t need t= o remove anything from DomainData?  Do we want to represent this level= of detail in the core IODEF data model?

 

(2) RelatedDNS was added to DomainData and is not pr= esent in RFC5901.  There is no descriptive text.  Could someone s= hed light on the purpose of this class.

 

(3) The attributes DomainData@{SystemStatus, DomainS= tatus} and RelatedDNS@RecordType don't follow the naming convention of lowe= r case names separated by a hyphen.  As in other cases where classes h= ave been moved, I would be inclined to rename the attributes.  Any concern in doing that?

 

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC54C1D3AAmarathon_-- From pkampana@cisco.com Thu Jan 23 06:27:48 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF7A1A0415 for ; Thu, 23 Jan 2014 06:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.835 X-Spam-Level: X-Spam-Status: No, score=-13.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C-st0ABzvDt for ; Thu, 23 Jan 2014 06:27:45 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECA41A00FC for ; Thu, 23 Jan 2014 06:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21491; q=dns/txt; s=iport; t=1390487264; x=1391696864; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=R+MSUr51oshwlfGYiNqMc7KBESypFLgRyc0g+RVAsC4=; b=P38ConcU7VNd6m/qyjAf3kWKsQZCbgBdmr2UXDutYXnkFfJpcbBqlzW7 OIvP8fUgit2kr9sEP5Q75iXOSizqP4F6UDLcQ7pv0iElNmF0CumXNS669 oyDTAjCDjC8cUvQd3mTXSOpzYuH2Hb5LyAftIBDvlTivgyyMZfdYK77E/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAAom4VKtJXG+/2dsb2JhbABbgkhEOFa7c4EQFnSCJQEBAQQtXAIBCBEEAQELHQcyFAkIAgQBEgiHfcVyF4x1gToBARgGCwIfCwECgyKBFASZVZBmgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208,217";a="299230782" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jan 2014 14:27:43 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0NERhuQ029771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 14:27:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 08:27:42 -0600 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "'Moriarty, Kathleen'" , "mile@ietf.org" Thread-Topic: [mile] Documenting DomainData Thread-Index: AQHPFeZKcVHy8XjkSUe8d5nwrbpqVpqOITGAgAAOhgCABB0RoIAAFI3g Date: Thu, 23 Jan 2014 14:27:42 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FAB17FA@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> <359EC4B99E040048A7131E0F4E113AFC54C18CF6@marathon> <359EC4B99E040048A7131E0F4E113AFC54C1D3AA@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1D3AA@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FAB17FAxmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:27:49 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750FAB17FAxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think text that says "The RelatedDNS record contain DNS records (i.e. MX,= A) that are related to the domain described in its parent DomainData class= . For example, in DomainData class for domain example.com, the RelatedDNS r= ecord could be carrying the MX record for example.com." would suffice. Panos From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 23, 2014 8:20 AM To: 'Moriarty, Kathleen'; mile@ietf.org Cc: Panos Kampanakis (pkampana) Subject: RE: [mile] Documenting DomainData Hi Kathleen! The example was very helpful. Thank you. For discussion purposes on the list, here is a relevant excerpt from the pr= eviously attached file: evildave.com 2013-01-04T09:10:24+00:00 evildave.com MX prefernce =3D 10, mail = exchanger =3D mail1.evildave.com mail1.evildave.com internet address =3D = 176.157.32.17 zuesevil.com. IN TXT \"v=3Dspf1 a mx -= all\" Reading this particular example, I understand what information is being pas= sed along in the DNS record. Where I need help is how do we formally descr= ibe this format for the draft. Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 22, 2014 6:50 PM To: Roman D. Danyliw; mile@ietf.org Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com) Subject: RE: [mile] Documenting DomainData Hi Roman, I was able to dig up an example from the group that was proposing the addit= ion of RelatedDNS to the DomainData class that was added from RFC5901. Pan= os may have other examples planned for the IODEF Guidance document. I think as long as the data of other records can be included, the intent wi= ll be met for the requestors. See the attached example and I am sure a pro= posal that alters it, but provides the ability to include that information = would be fine. Anyone else? Thanks, Kathleen From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Monday, January 20, 2014 5:04 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hello! Understood on #1 and #3. I still need a little more clarification on your = answer to question #2, "RelatedDNS lets you add any record type to expand o= ut what is possible from the Domain data class. You can also list what typ= e of record you are including." To restate, RelatedDNS represents DNS reco= rds for a domain specified in DomainData/Name? If so, what exactly goes in= to the element content of RelatedDNS which is defined as xs:string? For ex= ample, if I had an AXFR record () how would= this be encoded? Since Node/DomainData/DateDomainWasChecked represents when Node/DomainData/= Name was resolved (where the IP address is stored in Node/Address), is ther= e a similar construct for these other record types in RelatedDNS? Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Monday, January 20, 2014 8:48 AM To: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hi Roman, #1 I thought the answer was yes, but it would be good to hear if anyone thi= nks it is too much detail now. #2 RelatedDNS lets you add any record type to expand out what is possible f= rom the Domain data class. You can also list what type of record you are i= ncluding. #3 I don't think there is a concern in adjusting the names for consistency. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, January 17, 2014 9:32 PM To: mile@ietf.org Subject: [mile] Documenting DomainData Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_1C9F17D1873AFA47A969C4DD98F98A750FAB17FAxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think text that says= “The RelatedDNS record contain DNS records (i.e. MX, A) that are rel= ated to the domain described in its parent DomainData class. For example, i= n DomainData class for domain example.com, the RelatedDNS record could be carrying the MX record for example.com.R= 21; would suffice.

Panos

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Thursday, January 23, 2014 8:20 AM
To: 'Moriarty, Kathleen'; mile@ietf.org
Cc: Panos Kampanakis (pkampana)
Subject: RE: [mile] Documenting DomainData

 

Hi Kathleen!

 

The example was very h= elpful.  Thank you.

 

For discussion purpose= s on the list, here is a relevant excerpt from the previously attached file= :

<iodef:DomainData&g= t;

<iodef:Name>evil= dave.com</iodef:Name>

<iodef:DateDomainWa= sChecked>2013-01-04T09:10:24+00:00</iodef:DateDomainWasChecked>= ;

<iodef:RelatedDNS R= ecordType=3D"MX">evildave.com MX prefernce =3D 10, mail exchan= ger =3D mail1.evildave.com</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"A">mail1.evildave.com internet address =3D 176.15= 7.32.17</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"SPF">zuesevil.com. IN TXT \"v=3Dspf1 a mx &#= 8211;all\"</iodef:RelatedDNS>

</iodef:DomainData&= gt;

 

Reading this particula= r example, I understand what information is being passed along in the DNS r= ecord.  Where I need help is how do we formally describe this format f= or the draft. 

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.mo= riarty@emc.com]
Sent: Wednesday, January 22, 2014 6:50 PM
To: Roman D. Danyliw; mile@ietf.org=
Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com)
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

I was able to dig up a= n example from the group that was proposing the addition of RelatedDNS to t= he DomainData class that was added from RFC5901.  Panos may have other= examples planned for the IODEF Guidance document.

 

I think as long as the= data of other records can be included, the intent will be met for the requ= estors.  See the attached example and I am sure a proposal that alters= it, but provides the ability to include that information would be fine.

 

Anyone else?

 

Thanks,

Kathleen

 

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Monday, January 20, 2014 5:04 PM
To: Moriarty, Kathleen; mile@ietf.o= rg
Subject: RE: [mile] Documenting DomainData

 

Hello!

 

Understood on #1 and #= 3.  I still need a little more clarification on your answer to questio= n #2, “RelatedDNS lets you add any record type to expand out what is = possible from the Domain data class.  You can also list what type of record you are including.”  To restate, Relat= edDNS represents DNS records for a domain specified in DomainData/Name?&nbs= p; If so, what exactly goes into the element content of RelatedDNS which is= defined as xs:string?  For example, if I had an AXFR record (<RelatedDNS RecordType=3D”AXRF”>) how would= this be encoded?

 

Since Node/DomainData/= DateDomainWasChecked represents when Node/DomainData/Name was resolved (whe= re the IP address is stored in Node/Address), is there a similar construct = for these other record types in RelatedDNS?

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.mo= riarty@emc.com]
Sent: Monday, January 20, 2014 8:48 AM
To: Roman D. Danyliw; mile@ietf.org=
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

#1 I thought the answe= r was yes, but it would be good to hear if anyone thinks it is too much det= ail now.

 

#2 RelatedDNS lets you= add any record type to expand out what is possible from the Domain data cl= ass.  You can also list what type of record you are including.

 

#3 I don’t think= there is a concern in adjusting the names for consistency.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, January 17, 2014 9:32 PM
To: mile@ietf.org
Subject: [mile] Documenting DomainData

 

Hello!

 

Since being copied from RFC5901 into 5070bis, Domain= Data has evolved.  Currently the two definition differ as follows:

 

** 5070bis added DomainData@{indicator-uid, indicato= r-set-id}

** 5070bis added DomainData/RelatedDNS

** 5070bis uses iodef:Contact for DomainData/DomainC= ontacts/Contact instead of phish:Contact which added classes and attributes= to Contact

 

A few questions:

 

(1) Since bits and pieces were added and modified in= the cut-and-paste from 5901, is there agreement that we don’t need t= o remove anything from DomainData?  Do we want to represent this level= of detail in the core IODEF data model?

 

(2) RelatedDNS was added to DomainData and is not pr= esent in RFC5901.  There is no descriptive text.  Could someone s= hed light on the purpose of this class.

 

(3) The attributes DomainData@{SystemStatus, DomainS= tatus} and RelatedDNS@RecordType don't follow the naming convention of lowe= r case names separated by a hyphen.  As in other cases where classes h= ave been moved, I would be inclined to rename the attributes.  Any concern in doing that?

 

Roman

--_000_1C9F17D1873AFA47A969C4DD98F98A750FAB17FAxmbrcdx10ciscoc_-- From pkampana@cisco.com Thu Jan 23 06:31:04 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEAE1A00DF for ; Thu, 23 Jan 2014 06:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DSdP60Rb00w for ; Thu, 23 Jan 2014 06:31:02 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 279D21A00CA for ; Thu, 23 Jan 2014 06:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3091; q=dns/txt; s=iport; t=1390487461; x=1391697061; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DUgSnKwUjTAXrufWVDg38Wt3CoGYqyQGiPrUJfkWph8=; b=CgSgkcEGZCs93Mmyu1KABz2axhjdxYFP1cKdpvCm+uBfhorWQEMgX4ba 1BiDYtp55s7rx+0ZBCT9LxFVFXF2p/tzattavu1Z+BewS5yjFV2Uwo59z bCSIONprUllNq7PgCV+sKS/5hZcOUJNYfNBA3StTmLJVYQKoIK8n6Td3Q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPom4VKtJXG9/2dsb2JhbABbgww4VrtzgRAWdIIlAQEBBAEBATc0AhUEAgEIEQQBAQsUCQcnCxQJCAEBBAESCId9DcVmF447FDgGgx6BFASZVZBmgy2CKg X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208";a="14974052" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-7.cisco.com with ESMTP; 23 Jan 2014 14:31:01 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0NEV1sI010609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 14:31:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 08:31:00 -0600 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: Impact to the business (Issue #36) Thread-Index: Ac8XI0GRRx+PDs23Ts6TaQfVOj4fvgBJEpHA Date: Thu, 23 Jan 2014 14:31:00 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FAB181B@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC54C1AB40@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1AB40@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Impact to the business (Issue #36) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 14:31:04 -0000 No objections with BusinessImpact either.=20 Panos -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, January 21, 2014 10:41 PM To: mile@ietf.org Subject: [mile] Impact to the business (Issue #36) Good evening! Issue #36, http://tools.ietf.org/wg/mile/trac/ticket/36, is tracking the ne= ed to represent a summary of the impact an incident had on the organization= in 5070bis. To address this need, I would propose adding a new class, BusinessImpact, t= o Assessment. +-------------------------+ | Assessment | +-------------------------+ | ENUM occurrence |<>--{0..*}--[ Impact ] | ENUM restriction |<>--{0..*}--[ BusinessImpact ] | STRING indicator-uid |<>--{0..*}--[ TimeImpact ] | STRING indicator-set-id |<>--{0..*}--[ MonetaryImpact ] | |<>--{0..*}--[ Counter ] | |<>--{0..1}--[ Confidence ] | |<>--{0..*}--[ AdditionalData ] +-------------------------+ The BusinessImpact class describes and characterizes the degree to which th= e function of the organization was impacted by the Incident. The element body describes the impact to the organization as a free-form te= xt string. The two attributes characterize the impact. +-------------------------+ | BusinessImpact | +-------------------------+ | ML_STRING | | | | ENUM severity | | ENUM type | +-------------------------+ @severity (characterizes the severity of the incident on business functions= , from NIST SP800-61 Table 3-2) None =3D No effect to the organization's ab= ility to provide all services to all users Low =3D Minimal effect as the or= ganization can still provide all critical services to all users but has los= t efficiency Medium =3D The organization has lost the ability to provide a = critical service to a subset of system users High =3D The organization is n= o longer able to provide some critical services to any users unknown =3D Th= e impact is unknown ext-severity =3D Extension mechanism @type (characterizes the effect this incident had on the business) breach-p= ropriety =3D Sensitive or proprietary information was accessed or exfiltrat= ed breach-privacy =3D Personally identifiable information was accessed or e= xfiltrated loss-of-integrity =3D Sensitive or proprietary information was c= hanged or deleted loss-of-service =3D Service delivery was disrupted loss-f= inancial =3D Money or services were stolen degraded-reputation =3D The repu= tation of the organization's brand was diminished asset-destruction =3D A c= yber-physical system was damaged legal =3D Incident resulted in legal or re= gulatory action ext-type Extension mechanism Any thoughts? @type might be missing a few values. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From pkampana@cisco.com Thu Jan 23 07:20:56 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98911A0019 for ; Thu, 23 Jan 2014 07:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_60Kg66hL5q for ; Thu, 23 Jan 2014 07:20:51 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 703BF1A000F for ; Thu, 23 Jan 2014 07:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4077; q=dns/txt; s=iport; t=1390490451; x=1391700051; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AVWFpB6iONiOr7ykeUJcKf3wqWXVpYaVORqFnVet5Pk=; b=TY7T4Ek63PwmxXADLmTlcOpjnSFYcKNQH91mrlEVMDoLbwoyHQBmZs6s qe6AgQdS+dahH+QIFnghZ5nFLwdAfL1creXdnE7bQ9+K35JUHeYl3LdDF a3Jq45H2H0ub4Mabym8Xb7BNT7pSNuSCPm1apJONFn72CuPjiJ7+7YJoB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAJwy4VKtJXG9/2dsb2JhbABbgww4VrtzgRAWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAQEEARIIh30NxWETBI5POAaDHoEUBKo7gy2CKg X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208";a="14981522" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-3.cisco.com with ESMTP; 23 Jan 2014 15:20:50 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0NFKoxo003962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 15:20:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 09:20:50 -0600 From: "Panos Kampanakis (pkampana)" To: "Moriarty, Kathleen" , "Roman D. Danyliw" , "mile@ietf.org" Thread-Topic: Attributes of the Key class Thread-Index: Ac8ROH1UKtJl+89zQoqJaQFudDjEbQAEDvZwAb/7h+A= Date: Thu, 23 Jan 2014 15:20:49 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FAB192F@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC54C104F8@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Attributes of the Key class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:20:57 -0000 My thoughts in in PK> >> ** RegistryKeyModified/Key has the @ext-category attribute whose text r= eads "extension category". Could someone please explain the purpose of thi= s attribute or provide better text. It seems like this attribute was a typ= o and should really be named @ext-registryaction to extend @registryaction = when it is set to "ext-value". KM> I am having trouble finding this one in the current document.. PK> I think this existed in the -03 doc but removed in -04. Yes, @ext-regis= tryaction is the right attribute IMO. >> ** RegistryKeyModified/Key also has the attributes @type and @type-ext l= isted in the text, but not in the schema. It is not documented but is desc= ribed as having two enumerated values of "watchlist" and "ext-value". Coul= d someone please explain this attribute or provide better text. Also, the = numerated value of "ext-value" for @type is being used in a way inconsisten= tly with Section 5.1. We need to fix that. KM> Ah, okay from my last response, this additional context helps to see th= e intent. I think this was to provide a watchlist. The schema just had a = comment to see if it should be included. As long as you can include a watc= hlist, the intent would be met. The watchlist would be a list of values th= at may be ORed with other values in the list and an AND with the EventData = in the set. PK> Agree. I propose the attribute to be=20 BTW, the RegistryKeyModified should be WindowsRegistryKeysModified which se= ems to be fixed in the -04 version of the doc. Panos -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Wednesday, January 22, 2014 7:20 PM To: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Attributes of the Key class Hi Roman, I'll answer in line. Others, please chime in. Thanks! Kathleen -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Tuesday, January 14, 2014 10:25 AM To: mile@ietf.org Subject: [mile] Attributes of the Key class Hello, In reviewing the -03 draft, I have a few questions on the definition of the= Key class (Section 3.22.1). ** RegistryKeyModified/Key has the @ext-category attribute whose text read= s "extension category". Could someone please explain the purpose of this a= ttribute or provide better text. It seems like this attribute was a typo a= nd should really be named @ext-registryaction to extend @registryaction whe= n it is set to "ext-value". KM> I am having trouble finding this one in the current document.. ** RegistryKeyModified/Key also has the attributes @type and @type-ext list= ed in the text, but not in the schema. It is not documented but is describ= ed as having two enumerated values of "watchlist" and "ext-value". Could s= omeone please explain this attribute or provide better text. Also, the num= erated value of "ext-value" for @type is being used in a way inconsistently= with Section 5.1. We need to fix that. KM> Ah, okay from my last response, this additional context helps to see th= e intent. I think this was to provide a watchlist. The schema just had a = comment to see if it should be included. As long as you can include a watc= hlist, the intent would be met. The watchlist would be a list of values th= at may be ORed with other values in the list and an AND with the EventData = in the set. Roman _______________________________________________ mile mailing 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 eburger@cs.georgetown.edu Thu Jan 23 08:44:47 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1511A0006 for ; Thu, 23 Jan 2014 08:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.564 X-Spam-Level: * X-Spam-Status: No, score=1.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJDeeUUIEV85 for ; Thu, 23 Jan 2014 08:44:43 -0800 (PST) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8791A0012 for ; Thu, 23 Jan 2014 08:44:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 2930247F2A; Thu, 23 Jan 2014 11:44:42 -0500 (EST) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09jvlQeCQxpr; Thu, 23 Jan 2014 11:44:38 -0500 (EST) Received: from [192.168.15.103] (ip68-100-74-215.dc.dc.cox.net [68.100.74.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id CF34C47EC7; Thu, 23 Jan 2014 11:44:37 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_D09B5DB8-1B96-4B69-8C20-049B139C3D00"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C12208@marathon> Date: Thu, 23 Jan 2014 11:44:34 -0500 Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC54C12208@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.1827) Cc: "mile@ietf.org" Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:44:47 -0000 --Apple-Mail=_D09B5DB8-1B96-4B69-8C20-049B139C3D00 Content-Type: multipart/alternative; boundary="Apple-Mail=_EC4F3494-9F14-4383-B808-304B2DD53D45" --Apple-Mail=_EC4F3494-9F14-4383-B808-304B2DD53D45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Say what we mean. We are already paying the XML tax, so a fifth = attribute does not really =91cost=92 us anything. I can guarantee that = we will have more problems than a Year 3000 problem if we overload = indicator-etime. On Jan 15, 2014, at 11:02 AM, Roman D. Danyliw wrote: > Hi, > =20 > I=92d like to explore the community thinking on how to implement a = flag as Chris suggested to note that an indicator is persistent. = Assuming that the convention of @indicator-stime and =96etime was = adopted, a few possibilities to add a =93persistence flag=94 would be: > =20 > (1) Add a boolean attribute, say @indicator-persistent, to convey to = always look for this indicator. No @indicator-etime would be required. > =20 > (2) Define a particular date far into the future for @indicator-etime = that conveys persistence. For example, when = @indicator-etime=3D=943000/12/01 12:00:00=94 is seen, this indicator is = persistent. > =20 > Option #1 is most intuitively self-describing but adds another = attribute, now the fifth, to the list of =93special indicator = attributes=94. > =20 > Option #2 reduces the number of additional attributes. > =20 > Personally, I prefer #2. Your thoughts? > =20 > Roman > =20 > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]=20= > Sent: Monday, January 13, 2014 8:18 AM > To: Roman D. Danyliw; Stoecker, Paul > Cc: mile@ietf.org > Subject: RE: [mile] Describing the time window during which an = indicator should be used > =20 > Roman, > =20 > =46rom what I have seen the aging is usually up to the recipient. I = would say that option #1 would be better. > =20 > For purposes of deciding to stop looking for an indicator there is = another data point that is used far more frequently, Last Seen time. For = the majority of indicators we use the time it was last =93seen=94. For = us the =93seen=94 means that either we have seen it being used or we = have intel from a 3rd party or open source that it is still in use. The = only time we use the stime-etime paradigm is when there is an infection = (delivery stage of the Kill Chain) that was valid but later cleaned up. = Nbc.com was compromised last year for about 4 hours then cleaned up. In = that case we would use stime-etime. There are indicators that we call = persistent. These are indicators that we will never stop looking for. = These could be indicators that are used exclusively by a specific threat = actor (like a domain registered by an actor) or something that we used = in a previous incident at our organization, like RSA breech related = indicators. A construct to flag an indicator as persistent would be = helpful as this is information is something we routinely share. > =20 > Thanks, > =20 > --Chris > =20 > From: Roman D. Danyliw [mailto:rdd@cert.org]=20 > Sent: Thursday, January 09, 2014 4:59 PM > To: Harrington, Christopher; Stoecker, Paul > Cc: mile@ietf.org > Subject: RE: [mile] Describing the time window during which an = indicator should be used > =20 > Hello! > =20 > Chris: Thanks for the background! > =20 > To date, the message traffic suggests interest in per-indicator = annotation of validity. That would suggest something as follows: > =20 > > Or > > =20 > The follow-up discuss asked if organizations really every stop looking = for indicators they have. One answer was yes. > =20 > How do we want to handle that? Ideas might include: > =20 > (1) provide only an @indicator-stime and @indicator-etime, and these = are the best guess of the reporter of how long to make it valid. The = recipient can decide how and if to honor these. > =20 > (2) provide another attribute that would suggest an aging policy that = the recipient can choose to honor. What would we those aging policies? > =20 > Roman > =20 > =20 > From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com]=20= > Sent: Monday, December 23, 2013 10:46 AM > To: Stoecker, Paul > Cc: Roman D. Danyliw; mile@ietf.org > Subject: RE: [mile] Describing the time window during which an = indicator should be used > =20 > Yes we do stop looking. A good example is when NBC.com got hacked a = few months ago. We watched for people hitting it while the URL was = malicious. Once it was cleaned up we stopped watching for it since it = was a somewhat popular URL that would fire all the time and bury us in = false positives. > =20 > Indicator aging is an area that nobody has a good handle one. Each = organization seems to have their own way of doing things with aging, if = they do anything at all. Some commercial threat intel providers use a = decrementing counter based on the last time the indicator was seen. At = EMC we make the aging calculation based on time since last seen, = attribution (if known), kill chain stage, confidence in the source and = other factors. It=92s not automated at this point. > =20 > We can=92t keep all indicators forever. At some point the watch lists = and block lists on your Proxy, firewall, etc get too large and the = devices start having issues. We ran into this at EMC and had to switch = from Proxy blocks for domains to DNS RPZ with a sinkhole web servers. = There were too many domains in the proxy block list. We have tens of = thousands. There are indicators that we consider =93persistent=94. These = are indicators that we always want to be alerted about. Generally these = are advanced threat / APT and have either been seen in activity = involving EMC or they belong to threat actor groups that we have seen at = EMC. > =20 > Thanks, > =20 > --Chris > =20 > From: Stoecker, Paul=20 > Sent: Monday, December 23, 2013 10:26 AM > To: Harrington, Christopher > Cc: Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Describing the time window during which an = indicator should be used > =20 > I have a question...Do we really stop looking for IOCs whose time has = expired? Like a malicious URL whose time has expired...do you stop = looking for that URL? Let's say that Paul the malware dude got a hold = of the IODEF document...I shutdown my web server and after the time = expired I turned it back on? > =20 > Just wondering how IOC aging is actually handled? >=20 > Sent from my iPhone >=20 > On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" = wrote: >=20 > Hello, > =20 > Answers inline below. > =20 > Thanks, > =20 > --Chris > =20 > Christopher Harrington > Consulting Security Engineer > GSO - Critical Incident Response Center > EMC > 174 Middlesex Turnpike > Bedford, MA 01730 > 781-515-5862 (work) > 603-583-1585 (cell) > =20 > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw > Sent: Friday, December 20, 2013 4:26 PM > To: mile@ietf.org > Subject: [mile] Describing the time window during which an indicator = should be used > =20 > Hello! > =20 > Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is = tracking the need to convey the valid time during which to apply an = indicator. I wanted to solicit from the community the degree of = flexibility desired. For the purposes of this discussion an indicator = is defined as a class that has an @indicator-uid attribute. > =20 > ** Does this flexibility need to exist on a per indicator basis? > Example 1, > Yes, a malicious URL would be valid only as long as it is live. > =20 > ** Could it be at the EventData level (and the time window cascades to = all indicators that are children)? > Example 2:, =85 = =85 many domain indicators =85 > Example 3: =85 2013/12/01 = 12:00:00 =85 =85 many domain indicators = =85 > Yes, you could have multiple malware delivery URLs that are all on the = same domain. If the Domain is specified at EvenData level then when it = is no longer valid the children would no longer be valid. I hope I = explained that right J I am not sure how it would differ between = Example 2 and 3. > =20 > ** Could it be at the Incident level? > Example 4: =85 2013/12/01 = 12:00:00 =85 many domain indicators =85 = > If there was only one Indicator in an incident it could be. In = practical terms this is very unlikely. > =20 > Per indicator time information would provide the most flexibility but = would require duplication of the same information. > =20 > A time window for indicator validity specified at the Incident level = would not allow for multiple time windows per indicator. > =20 > A time window for indicator validity specified in the EventData class = would require nested EventData instances to convey different time = period. Also, some indicators are only in the Incident class so this = approach would be insufficient. Perhaps a hybrid approach where this = timing information is in the EventData and IncidentData classes could be = possible. > =20 > Personally I think the safest approach is validity per Indicator. = Validity for parent / child would be rare and validity per Incident even = rarer. > =20 > One question, how do we represent =93still valid=94? If I have an = indicator that is valid when I send the message how do I know what that = time represents? If I put =9312/20/2013 13:00=94 as the time can you = tell if I mean that it was still valid when I sent the message at that = time or that its validity period ended at that time. Those are very = different scenarios and critically important for searching / responding = to indicator hits. > =20 > Roman > =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 --Apple-Mail=_EC4F3494-9F14-4383-B808-304B2DD53D45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Say = what we mean. We are already paying the XML tax, so a fifth attribute = does not really =91cost=92 us anything. I can guarantee that we will = have more problems than a Year 3000 problem if we overload = indicator-etime.

On Jan 15, 2014, at 11:02 AM, Roman = D. Danyliw <rdd@cert.org> = wrote:

Hi,
 
I=92d = like to explore the community thinking on how to implement a flag as = Chris suggested to note that an indicator is persistent.  Assuming = that the convention of @indicator-stime and = =96etime was adopted, a few possibilities to add a =93persistence flag=94 = would be:
 
(1) Add a boolean attribute, say = @indicator-persistent, to convey to always look for this = indicator.  No @indicator-etime would be = required.
 
(2) Define a particular date far into = the future for @indicator-etime that conveys persistence.  For = example, when @indicator-etime=3D=943000/12/01 12:00:00=94 =  is seen, this indicator is persistent.
 
Option = #1 is most intuitively self-describing but adds another attribute, now = the fifth, to the list of =93special indicator = attributes=94.
 
Option #2 = reduces the number of additional attributes.
 
Personally, I prefer #2.  Your = thoughts?
 
Roman
 
From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] 
Sent: Monday, January 13, 2014 = 8:18 AM
To: Roman D. Danyliw; Stoecker, = Paul
Cc: mile@ietf.org
Subject: RE: [mile] Describing the = time window during which an indicator should be = used
 
Roman,
 
=46rom what I have seen the aging is usually up to = the recipient. I would say that option #1 would be = better.
 
For purposes of deciding to stop = looking for an indicator there is another data point that is used far = more frequently, Last Seen time. For the majority of indicators we use = the time it was last =93seen=94. For us the =93seen=94 means that either = we have seen it being used or we have intel from a 3rd party or open source that = it is still in use. The only time we use the stime-etime paradigm is = when there is an infection (delivery stage of the Kill Chain) that was = valid but later cleaned up. Nbc.com was compromised last year = for about 4 hours then cleaned up. In that case we would use = stime-etime. There are indicators that we call persistent. These are = indicators that we will never stop looking for. These could be = indicators that are used exclusively by a specific threat actor (like a = domain registered by an actor) or something that we used in a previous = incident at our organization, like RSA breech related indicators. A = construct to flag an indicator as persistent would be helpful as this is = information is something we routinely = share.
 
Thanks,
 
--Chris
 
From: Roman D. Danyliw [mailto:rdd@cert.org] 
Sent: Thursday, January 09, 2014 = 4:59 PM
To: Harrington, Christopher; = Stoecker, Paul
Cc: mile@ietf.org
Subject: RE: [mile] Describing the = time window during which an indicator should be = used
 
Hello!
 
Chris: Thanks for the = background!
 
To date, = the message traffic suggests interest in per-indicator annotation of = validity.  That would suggest something as = follows:
 
<Assessment indicator-uid=3D=94foo-12345=94 = indicator-stime=3D=942013/12/01 12:00:00=94>
Or
<Assessment = indicator-uid=3D=94foo-12345=94 indicator-stime=3D=942013/12/01 = 12:00:00=94 indicator-etime=3D=942013/12/01 = 13:00:00=94-->
 
The = follow-up discuss asked if organizations really every stop looking for = indicators they have.  One answer was yes.
 
How do = we want to handle that?  Ideas might include:
 
(1) = provide only an @indicator-stime and @indicator-etime, and these are the = best guess of the reporter of how long to make it valid.  The = recipient can decide how and if to honor these.
 
(2) = provide another attribute that would suggest an aging policy that the = recipient can choose to honor.  What would we those aging = policies?
 
Roman
 
 
From: Harrington, Christopher = [mailto:Christopher.Harrington@emc.com] 
Sent: Monday, December 23, 2013 = 10:46 AM
To: Stoecker, = Paul
Cc: Roman= D. Danyliw; mile@ietf.org
Subject: RE: [mile] Describing the = time window during which an indicator should be = used
 
Yes we do stop looking. A good = example is when NBC.com got hacked a few months = ago. We watched for people hitting it while the URL was malicious. Once = it was cleaned up we stopped watching for it since it was a somewhat = popular  URL that would fire all the time and bury us in false = positives.
 
Indicator = aging is an area that nobody has a good handle one. Each organization = seems to have their own way of doing things with aging, if they do = anything at all. Some commercial threat intel providers use a = decrementing counter based on the last time the indicator was seen. At = EMC we make the aging calculation based on time since last seen, = attribution (if known), kill chain stage, confidence in the source =  and other factors. It=92s not automated at this = point.
 
We can=92t keep all indicators = forever. At some point the watch lists and block lists on your Proxy, = firewall, etc get too large and the devices start having issues. We ran = into this at EMC and had to switch from Proxy blocks for domains to DNS = RPZ with a sinkhole web servers. There were too many domains in the = proxy block list. We have tens of thousands. There are indicators that = we consider =93persistent=94. These are indicators that we always want = to be alerted about. Generally these are advanced threat / APT and have = either been seen in activity involving EMC or they belong to threat = actor groups that we have seen at EMC.
 
Thanks,
 
--Chris
 
From: Stoecker, Paul 
Sent: Monday, December 23, 2013 = 10:26 AM
To: Harrington, = Christopher
Cc: Roman D. Danyliw; mile@ietf.org
Subject: Re: [mile] Describing the = time window during which an indicator should be = used
 
I have a = question...Do we really stop looking for IOCs whose time has expired? =  Like a malicious URL whose time has expired...do you stop looking = for that URL?  Let's say that Paul the malware dude got a hold of = the IODEF document...I shutdown my web server and after the time expired = I turned it back on?
 
Just = wondering how IOC aging is actually handled?

Sent from my = iPhone


On = Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" <Christopher.Harrington@emc.com> = wrote:

Hello,
 
Answers = inline below.
 
Thanks,
 
--Chris
 
Christopher Harrington
Consulting Security Engineer
GSO - = Critical Incident Response Center
EMC
174 Middlesex = Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 = (cell)
 
From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw
Sent: Friday, December 20, 2013 = 4:26 PM
To: mile@ietf.org
Subject: [mile] Describing the time = window during which an indicator should be = used
 
Hello!
 
Ticket #28 = (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is = tracking the need to convey the valid time during which to apply an = indicator.  I wanted to solicit from the community the degree of = flexibility desired.  For the purposes of this discussion an = indicator is defined as a class that has an @indicator-uid = attribute.
 
** Does = this flexibility need to exist on a per indicator = basis?
Example 1, = <Assessment indicator-uid=3D=94foo-12345=94 = indicator-valid-stime=3D=942013/12/01 12:00:00=94>
Yes, a = malicious URL would be valid only as long as it is = live.
 
** Could = it be at the EventData level (and the time window cascades to all = indicators that are children)?
Example 2:, <EventData indicator-stime=3D=942013/12/01 = 12:00:00=94> =85 <Flow> =85 many domain indicators = </Flow> =85 </EventData>
Example 3: <EventData>  =85 = <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> = =85 <Flow> =85 many domain indicators </Flow> =85 = </EventData>
Yes, you could have multiple malware = delivery URLs that are all on the same domain. If the Domain is = specified at EvenData level then when it is no longer valid the children = would no longer be valid. I hope I explained that right J  I am not sure how it would = differ between Example 2 and 3.
 
** Could = it be at the Incident level?
Example 4: <Incident>  =85 = <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> = =85 many domain indicators </Flow> =85 = </Incident>
If there was only one Indicator in an = incident it could be. In practical terms this is very = unlikely.
 
Per = indicator time information would provide the most flexibility but would = require duplication of the same information.
 
A time = window for indicator validity specified at the Incident level would not = allow for multiple time windows per indicator.
 
A time = window for indicator validity specified in the EventData class would = require nested EventData instances to convey different time = period.  Also, some indicators are only in the Incident class so = this approach would be insufficient.  Perhaps a hybrid approach = where this timing information is in the EventData and IncidentData = classes could be possible.
 
Personally I think the safest approach is validity per = Indicator.  Validity for parent / child would be rare and validity = per Incident even rarer.
 
One question, how do we represent = =93still valid=94? If I have an indicator that is valid when I send the = message how do I know what that time represents?  If I put = =9312/20/2013 13:00=94 as the time can you tell if I mean that it was = still valid when I sent the message at that time or that its validity = period ended at that time. Those are very different scenarios and = critically important for searching / responding to indicator = hits.
 
Roman
 
_______________________________________________
mile mailing = list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile
___________= ____________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile
= --Apple-Mail=_EC4F3494-9F14-4383-B808-304B2DD53D45-- --Apple-Mail=_D09B5DB8-1B96-4B69-8C20-049B139C3D00 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS4UbzAAoJEBTjQnN5ojkBZzUP/2xfIJ45hIHLxzEsBBywFcUJ T+xU7ChwMWRnifXkGw0Mmr5kvG4W7Md1/4zxmQQCq2Gv/t5s0+/LJHSjMmljD36z EbQjt7uAiJQ32VED6Q+YEIDCapugtRbFb23tZrs58FWuX8f6YVIJAJawOvH1+2jY ZA14BpiDHhDubYSl0YWB21PU3qJH8qbjl59T+dZ4A28fTFKGSvh7I+IYF9U0P8Gc h0LIabTzdk+oLUtmcUvY0QKBlFSiBEZP00fsJFOzfn57Dl1jTRRIvD3NjsjV+Ug8 R8iv3qXsntbsV2CLQ4CUTqTMZJZ0S0bqioy72P65LwbRF3tBqXAGGppWi9yQOVHA SF0Zzj99hU7uMotJQJoykF7GhRgk8FHEyLfLqH/buSk1/Q6XjWkvSBhCpTP/ypeI 37PP1Qj2KDG+dJxbgRac7vvWQB3IAQ0F0uEzsKJF6vrhCiHzg7UUUou+1TO2K0CS yWIXrUa+Xx2YyybU9f4NglpRy+m1h/YQd4ukMCMZtTynN4ixgjKMFV/kBiEUwFb7 24kxRnZWAZ4sREfOLvR7nSuyw2/ZVMu16cdYwqvwT9sESqdVucluC4dK+R77WcsJ 9fGvSCOlDWuaap8ztWDzFv/0zomMkh0cNHXE6i9GcQ/0pu5SKNRSH4QynsPGM7Ar L2yQ/KSuPBhSPemR15uK =BlpX -----END PGP SIGNATURE----- --Apple-Mail=_D09B5DB8-1B96-4B69-8C20-049B139C3D00-- From eburger@standardstrack.com Thu Jan 23 08:47:15 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8675B1A004C for ; Thu, 23 Jan 2014 08:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaBQZ8vAjau4 for ; Thu, 23 Jan 2014 08:47:14 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0021A0006 for ; Thu, 23 Jan 2014 08:47:14 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:49287 helo=[192.168.15.103]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1W6NQp-0004vt-3u; Thu, 23 Jan 2014 08:47:12 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_824D4560-43E1-4C40-8278-E1F9613D4F30"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C122B3@marathon> Date: Thu, 23 Jan 2014 11:47:05 -0500 Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC54C1204A@marathon> <359EC4B99E040048A7131E0F4E113AFC54C122B3@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: "mile@ietf.org" Subject: Re: [mile] Representing a domain name (or Issue #4) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:47:15 -0000 --Apple-Mail=_824D4560-43E1-4C40-8278-E1F9613D4F30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All I care about is if one is describing a Domain Name Thing, then = wherever one references the Domain Name Thing, one references it the = same way. How important is backwards compatibility with 5070 in this case? I would = think tis would be one of the more commonly used data elements, but I = could be wrong. On Jan 15, 2014, at 11:23 AM, Roman D. Danyliw wrote: > Hello! >=20 > I omitted an important detail in my earlier write-up. The Service = class also got a DomainData class in 5070bis (at least in the schema but = not in the text). Hence, there are actually three places to put the = domain name. Hence, the following XML-snippet would be legal: >=20 > ... > > www.example.com > > www.example.com > = 2013-01-02T05:54:02-05:00 > >
10.1.1.1.
> 2013-01-02T05:54:02-05:00 > > ... > > www.example.com > = 2013-01-02T05:54:02-05:00 > > > >=20 > To expand upon the previously suggested options: >=20 > (1) Remove Node/NodeName and Service/DomainData/Name in favor of = Node/DomainData/Name >=20 > (2) Remove Node/DomainData/Name and Service/DomainData/Name in favor = of Node/NodeName >=20 > (3) Remove Node/DomainData/Name and Node/NodeName in favor of = Service/DomainData/Name >=20 >> Option #1 break compatibility with RFC 5070. Also, NodeName can = represent >> any kind of host name. As defined DomainData/Name only represents = FQDN >> DNS names. >>=20 >> Option #2 redefines DomainData from RFC 5901 so we can't strictly = cite the >> element. >=20 > Option #3 has the same disadvantages as #1 and would also requires = further changes Service. Currently, the Service class minimally expects = port information. >=20 > Roman >=20 >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw >> Sent: Wednesday, January 15, 2014 9:57 AM >> To: mile@ietf.org >> Subject: [mile] Representing a domain name (or Issue #4) >>=20 >> Hello! >>=20 >> Tracked in Issue #4, = http://trac.tools.ietf.org/wg/mile/trac/ticket/4, is the >> need to make a modeling decision on how to represent domain name. To >> summarize, we currently have two duplicate ways to represent a domain >> name for given Node. RFC5070 defined Node/NodeName. DomainData from >> RFC5901 was added to the Node class in RFC5070bis. This change = allows >> Node/DomainData/Name to also describe a domain name. >>=20 >> Both of these valid representations are shown in this XML snippet: >>=20 >> >> >> www.example.com >> >> www.example.com >> 2013-01-02T05:54:02- >> 05:00 >> >>
10.1.1.1.
>> 2013-01-02T05:54:02-05:00 >> >> >>=20 >> This will likely create implementation confusion. >>=20 >> As I see it, we have at least the following options: >>=20 >> (1) Remove NodeName and DateTime from Node in favor of DomainData >>=20 >> (2) Remove Name and DateDomainWasChecked from DomainData in favor of >> NodeName and DateTime >>=20 >> Option #1 break compatibility with RFC 5070. Also, NodeName can = represent >> any kind of host name. As defined DomainData/Name only represents = FQDN >> DNS names. >>=20 >> Option #2 redefines DomainData from RFC 5901 so we can't strictly = cite the >> element. >>=20 >> Roman >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_824D4560-43E1-4C40-8278-E1F9613D4F30 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS4UeJAAoJEDY/T2tCIPW3xSMP/j45sdGImd2ww+FysvDJhhVg 9EhlvEGcUoJIXDppChZbZBmiXwl0cWYLHNvW2Utce6FNyKFwBueo1Rbvo3yaTheI Td8Va3uJ5C525xdmhplSEfzne/HLD/MeWjt+hu3c6uV7vuVSAZQqXL/rRd/B7WJ4 HVvtxYDev5qu2ydBRCbvfH/5doMetaNTsMe1f+BOIROvSFfS1lB3sFg1Ei4qYBPm aYT5D0VdCxiS3CmFDUjHoV029UyBQXIn5p72b+5W/JfyD+kxBuVKWOzcxQfHByNM /273MLXF5oW7KWrt8uGv+JzlW8hVpj/EqgKB8KYC2MGvjmDayW4NgONUUgh7Xwo5 RLgGHPcsBkqaLa1NEq/MhuJuS4muYrKkyzpCpXMETfBeKgyNksiQUjbkdyH3opL+ okjxpeec8xyTupMpH3TDMaWztOqSg+I4MSLuukOPJIouuyZ2t1J8GdvEl1tegQyL OPzvMYxDOfI2/JnKPCYLq6p399dIF2Hs2k/38peEAJ5ifElH2DJu2pLBKTOvyEVM DAWOuMxNjJ8JflnpxXN/zqUD8tOM65GLJOrjpMuf3Klh+QkoqI0RWXdFTlHdsDqx DnRX6/NPvN/1/miYyeWQSZ6mXTdjkebIcudwTuhAnl9d2FXkrM+lcdzFjlTa+lTU CkQiLbrVsVk7ZQm8LAR8 =xm8I -----END PGP SIGNATURE----- --Apple-Mail=_824D4560-43E1-4C40-8278-E1F9613D4F30-- From eburger@standardstrack.com Thu Jan 23 08:49:12 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E801A0061 for ; Thu, 23 Jan 2014 08:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzOb1cEszy_3 for ; Thu, 23 Jan 2014 08:49:11 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9E1A0006 for ; Thu, 23 Jan 2014 08:49:11 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:49292 helo=[192.168.15.103]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1W6NSg-0003Rr-3G; Thu, 23 Jan 2014 08:49:09 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_F6FE634B-E353-40F5-BE64-B945B5F1071A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: Date: Thu, 23 Jan 2014 11:49:00 -0500 Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC54C149B2@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: "mile@ietf.org" Subject: Re: [mile] An alternative way to represent a URL X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:49:12 -0000 --Apple-Mail=_F6FE634B-E353-40F5-BE64-B945B5F1071A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One and only one way to indicate a Thing sounds good to me. I would = remove the reference, as it does not change 5070 at all and it also = removes the temptation to implement in another, not-quite-compatible = format. On Jan 16, 2014, at 3:02 PM, Moriarty, Kathleen = wrote: > Hi Roman, >=20 > I think it was only left in to show that we could do this another way = if people were interested. If the WG is happy with the approach in = place now that achieves the same objective, this can be removed. The = discussions that led to this may go back to Rosella's presentation and = that URLs could only be included as a reference and not an indicator in = IODEF v1. >=20 > Thanks, > Kathleen >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw > Sent: Thursday, January 16, 2014 1:57 PM > To: mile@ietf.org > Subject: [mile] An alternative way to represent a URL >=20 > Hello, >=20 > The schema definition of the Node class in -03 of 5070bis has the = following comment in it: >=20 > [begin schema snippet] > = [end schema snippet] >=20 > This proposal would provide an alternative to the current approach of = representing a URI for a Node using Address@category=3D"site-uri" (e.g., =
http://www.example.com/sites/foo
). >=20 > I don't know the origin or rational for this comment. Could anyone = shed light on why we'd want to change the current representation? >=20 > Roman > _______________________________________________ > 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 --Apple-Mail=_F6FE634B-E353-40F5-BE64-B945B5F1071A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS4Uf8AAoJEDY/T2tCIPW3+DsP/3/EOD8SXEKA9/jB4gUV1TS1 UoKRWq2Wod6lxUzywyWlxS3pV1Ub/l29k2841asTfHmEZQ6YfAiGz2bC7ryLQlNA ByBv1ABM4CjapIjVe6B7kOkXHALaVaM0eOA4N3z/gUQAfH/BwCKasFcsik0CwV5Z OWgLCnCg5Y09JntH4g5BYuFPmGGGX/Wx9xZaBchksfsVIdHYEBNZD84GkAVLf5SK bCn9zQ74Q3yQvgmrERU6fl9woy1evpKv1UYJo1M7b4AWsAI3hxG4WvDparkU0XrX +Jsf3ZkQFom/7KVHijdqW0N5KLD90OzIq5GQB/puEiRLUuiUJrhI/fzUMcE1y9jV kFi9EkvclipjhvMHpSacvjypyTloBeoG20qXU0Xb1BD2GvNvgivRzT/uO4ZQXmd0 jeumAGJSrntI3KdlKX9uIXegAdtVhC0nTAy/EK0t0teZrNoPSj5EfyUKW45FuajQ xjy4zyi9B/qZsbVUtOov19wth/WF2VGe3WBmXf5NV+LbMu5y5hzTZX/XVSnKTK8J 9yuJ1WHnbk4L3xlZrzaJkRxW/6l1tnV382v2CTD66czeQS2UyhxqiCjbxUSXW+Ms OOo4G2+jT2CzaR/nYTZEiY6laZQ2qIRxs5wQfkZGudAhZSIBPkr+zZ3CYqOj/oMY kziNi8EdLCxFhKCv/wUQ =BdDb -----END PGP SIGNATURE----- --Apple-Mail=_F6FE634B-E353-40F5-BE64-B945B5F1071A-- From eburger@standardstrack.com Thu Jan 23 08:53:02 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09BB1A007C for ; Thu, 23 Jan 2014 08:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8wLX9vghqqE for ; Thu, 23 Jan 2014 08:53:00 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBA21A0028 for ; Thu, 23 Jan 2014 08:53:00 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:49309 helo=[192.168.15.103]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1W6NWP-0008VW-Ag for mile@ietf.org; Thu, 23 Jan 2014 08:52:58 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_7005EFD9-CF18-4CC5-92DD-FE7F888873DB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <6C121AB8-CA98-46F9-B8AE-307DBACF8869@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Thu, 23 Jan 2014 11:52:47 -0500 References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> <673f2a8968f6437c844f5a0e148c7d84@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <359EC4B99E040048A7131E0F4E113AFC54C14EAA@marathon> <9d7bcf3f29f942c5b7e410d14f1ae16d@DFM-TK5MBX15-05.exchange.corp.microsoft.com> To: "mile@ietf.org" In-Reply-To: <9d7bcf3f29f942c5b7e410d14f1ae16d@DFM-TK5MBX15-05.exchange.corp.microsoft.com> X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:53:02 -0000 --Apple-Mail=_7005EFD9-CF18-4CC5-92DD-FE7F888873DB Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3EDB74-9D31-467A-8752-AE45732A1E9D" --Apple-Mail=_0F3EDB74-9D31-467A-8752-AE45732A1E9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looks like an oversight, unless there is a compelling reason to have a = non-extensible top-level class. On Jan 17, 2014, at 1:26 PM, Trevor Freeman = wrote: > Exactly > =20 > I was trying to figure out if this is a simple oversight or deliberate = act. > =20 > Does anyone object to filling the gap and adding the extension to the = IODEF-document class? > =20 > Trevor > =20 > From: Roman D. Danyliw [mailto:rdd@cert.org]=20 > Sent: Thursday, January 16, 2014 11:38 AM > To: Trevor Freeman; Panos Kampanakis (pkampana); Moriarty, Kathleen; = mile@ietf.org > Subject: RE: Extending the IODEF-Document class > =20 > Good afternoon! > =20 > Sidestepping the signature discussion, I think that Trevor is pointing = out a gap in the data model. I concur that it would be valuable to have = the ability to add an extension into an IODEF-Document. It would allow = unanticipated data elements to be added into the root node that are = relevant to multiple Incident classes aggregated in the IODEF-Document = class. > =20 > Roman > =20 > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman > Sent: Thursday, January 16, 2014 2:28 PM > To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org > Subject: Re: [mile] Extending the IODEF-Document class > =20 > Hi Panos, > =20 > For digital signatures, it is a classic issues between what you do = with a single signature vs. multiple signatures. For a single signature, = what you describe works e.g. a document with a single incident =96 no = problem. It=92s also not a problem with the actual signature itself, = that too is fine. It=92s simply a question of optimizing the bag of = certificates you need to validate multiple signatures. If you start = aggregating incident data, and have different incidents from different = sources with different signers, you need to normalize the certificate = data set across all the signers so you don=92t bloat the document with = redundant data. The schema I would define is trivial as it would reuse = the elements defined in the XML signature standard, but should be = stored in the schema at the level of the IODEF document as it pertains = to multiple incidents. This is the behavior that CMS uses i.e. = certificates are not part of the SignerInfo but are part of the Signed = Data structure. This allows a single bag of certificates to be used = across all SignerInfo structures.=20 > =20 > The work that Kathleen is referring to is the work I am doing with Jim = Schaad on stronger policy enforcement on distributed data. We started = work on email and the work goes under the Plasma name in the IETF. We = have developed a mechanism to apply strong access control policy on = email whereby we can send out a message to multiple recipients and = enforce attribute based access control to the content. As part of that = work we define something we call a Plasma token which links an email = message to a set of XACML rules which defines the specifics of who can = access the message. Its fairly simple to take what we have in = http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ and recast in = in XML and embed a Plasma token in an IODEF document using the = additional data extension mechanism to deliver access control with = teeth. However you cannot homogenize the access control policy so it = does not make sense to apply access control at the document level but to = individual incidents or parts of incidents. Different incents could have = different policies. I can embed different policies into the single = Plasma token, or I may need to embed a separate token depending on the = policies and who is trusted. Again the tokens should be at the document = level not the incident level as each token can protect multiple indents. = I cannot use the extension point in the incident to store the token = because I want to encrypt the entire incent. > =20 > In both scenarios, the IODEF extension mechanism works just fine to = solve the problem, except that I cannot use it at the document level = because it=92s not in the IODEF-document class. > =20 > Is there some reason for not wanting the document class extended? > =20 > Trevor > =20 > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com]=20 > Sent: Thursday, January 16, 2014 9:25 AM > To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org > Subject: RE: Extending the IODEF-Document class > =20 > Authentication of the incident data themselves seems reasonable to = address. > But to solve that, would it be simpler for someone to sign the XML = doc or parts of it and include all the certs using XML DSIG (enveloped = or detached) ? > Panos > =20 > =20 > =20 > =20 > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman > Sent: Wednesday, January 15, 2014 6:18 PM > To: Moriarty, Kathleen; mile@ietf.org > Subject: Re: [mile] Extending the IODEF-Document class > =20 > Hi Kathleen, > =20 > RID, to my mind offers a set of security serves targeting the = transport and authorization of the RID messages. The security of RID, = handles the security associated with the processing of RID messages. For = example, a RID message could be a request for an action or a query for = information. This messages need security services because of the = potential impact i.e. we don=92t want to repeat the mistake of SMTP = where there is no authentication when email is sent between MTAs. The = timeframe of the security is around the request and the response RID = messages, i.e. send a RID request, get a RID response, case closed. The = RID security provides operational security for the functioning of = ecosystem. > =20 > Information policies like information sharing or confidentiality = agreements relate to the actual content itself regardless of format and = persists beyond receiving the data hence apply to the content of the = IODEF documents wherever they are. If I was a repository of incident = data, I am receiving incidents which could be signed as proof of data = origination from many sources. If I receive a RID query message, I would = authorize processing the request based on the RID security then = construct a new IODEF document containing all the incidents covered by = the request. The repository would sign the RID response, but I want to = retain the original signatures of the contributor of the incident data = itself as it relates directly to the providence of the data. If the = incident data requires specific access control policies, those too would = need to be respected as part of the response and are orthogonal to the = confidentiality of the RID response as they can change incident by = incident. I see any IODEF security providing security services to = support compliance with the information policies be they regulatory = policies, contractual policies, information sharing agreements or = whatever. > =20 > Hope that helps. > =20 > Trevor > =20 > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]=20 > Sent: Wednesday, January 15, 2014 11:41 AM > To: Trevor Freeman; mile@ietf.org > Subject: RE: Extending the IODEF-Document class > =20 > Trevor, > =20 > Could you elaborate on how this is different from or compliments the = Digital signature and Encryption for IODEF in RID, RFC6545? I think = that will be helpful here. > =20 > Thanks, > Kathleen > =20 > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman > Sent: Wednesday, January 15, 2014 2:02 PM > To: mile@ietf.org > Subject: [mile] Extending the IODEF-Document class > =20 > I am looking at implementing better end to end security with IODEF = documents. > =20 > For example, stronger access control on the data than is possible via = the restriction attribute, or stronger data origination authentication = by singing incidents. > =20 > In both cases there is security relevant metadata which may apply to = multiple incidents in an IODEF document. For example with signed = incidents, I want to include a set certificates to enable relying = parties to be able to validate the incident. I also want to optimize the = set of certificates in the document i.e. ensure I don=92t include the = same certificate multiple places in the document. The simplest way to = achieve that is to have all the certificates in one place. The logical = place to store the set of certificates would be in the IODEF document = class. This is equivalent to CMS, where the set of signing certificates = are in the SignedData object not the SignerInfo object. However the = IODEF document class lacks the AdditionalData extension point preset in = other IODEF classes. > =20 > Is it possible to add the optional AdditionalData element to the v2 of = the IODEF document class so it is possible to extend that class the same = way it is possible to extend other classes? > =20 > Trevor > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_0F3EDB74-9D31-467A-8752-AE45732A1E9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Looks = like an oversight, unless there is a compelling reason to have a = non-extensible top-level class.

On Jan 17, 2014, at = 1:26 PM, Trevor Freeman <trevorf@exchange.microsoft.= com> wrote:

Exactly
 
I was trying to figure out if this is a simple = oversight or deliberate act.
 
Does anyone object to filling the gap and adding the = extension to the IODEF-document class?
 
Trevor
 
From: Roman D. Danyliw [mailto:rdd@cert.org] 
Sent: Thursday, January 16, 2014 = 11:38 AM
To: Trevor Freeman; Panos = Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org
Subject: RE: Extending the = IODEF-Document class
 
Good = afternoon!
 
Sidestepping the signature discussion, I think that Trevor is = pointing out a gap in the data model.  I concur that it would be = valuable to have the ability to add an extension into an = IODEF-Document.  It would allow unanticipated data elements to be = added into the root node that are relevant to multiple Incident classes = aggregated in the IODEF-Document class.
 
Roman
 
From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor = Freeman
Sent: Thursday, January 16, 2014 = 2:28 PM
To: Panos Kampanakis = (pkampana); Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] Extending the = IODEF-Document class
 
Hi Panos,
 
For digital signatures, it is a classic issues = between what you do with a single signature vs. multiple signatures. For = a single signature, what you describe works e.g. a document with a = single incident =96 no problem. It=92s also not a problem with the = actual signature itself, that too is fine. It=92s simply a question of = optimizing the bag of certificates you need to validate multiple = signatures.  If you start  aggregating incident data, and have = different incidents from different sources with different signers, you = need to normalize the certificate data set across all the signers so you = don=92t bloat the document with redundant data. The schema I would = define is trivial as it would reuse the elements defined in the XML = signature standard, but should be  stored in the schema  at = the level of the IODEF document as it pertains to multiple incidents. = This is the behavior that CMS uses i.e. certificates are not part of the = SignerInfo but are part of the Signed Data structure. This allows a = single bag of certificates to be used across all SignerInfo = structures. 
 
The work = that Kathleen is referring to is the work I am doing with Jim Schaad on = stronger policy enforcement on distributed data. We started work on = email and the work goes under the Plasma name in the IETF. We have = developed a mechanism to apply strong access control policy on email = whereby we can send out a message to multiple recipients and enforce = attribute based access control to the content.  As part of that = work we define something we call a Plasma token which links an email = message to a set of XACML rules which defines the specifics of who can = access the message. Its fairly simple to take what we have in http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ and recast in in XML = and embed a Plasma token in an IODEF document using the additional data = extension mechanism to deliver access control with teeth. However you = cannot homogenize the access control policy so it does not make sense to = apply access control at the document level but to individual incidents = or parts of incidents. Different incents could have different policies. = I can embed different policies into the single Plasma token, or I may = need to embed a separate token depending on the policies and who is = trusted. Again the tokens should be at the document level not the = incident level as each token can protect multiple indents. I cannot use = the extension point in the incident to store the token because I want to = encrypt the entire incent.
 
In both scenarios, the IODEF extension mechanism = works just fine to solve the problem, except that I cannot use it at the = document level because it=92s not in the IODEF-document = class.
 
Is there some reason for not wanting = the document class extended?
 
Trevor
 
From: Panos Kampanakis (pkampana) = [mailto:pkampana@cisco.com] 
Sent: Thursday, January 16, 2014 = 9:25 AM
To: Trevor Freeman; Moriarty, = Kathleen; mile@ietf.org
Subject: RE: Extending the = IODEF-Document class
 
Authentication of the incident data = themselves seems reasonable to address.
But to = solve that,  would it be simpler for someone to sign the XML doc or = parts of it and include all the certs using XML DSIG (enveloped or = detached)  ?
Panos
 
 
 
 
From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor = Freeman
Sent: Wednesday, January 15, 2014 = 6:18 PM
To: Moriarty, Kathleen; mile@ietf.org
Subject: Re: [mile] Extending the = IODEF-Document class
 
Hi = Kathleen,
 
RID, to my mind offers a set of = security serves targeting the transport and authorization of the RID = messages. The security of  RID, handles the security associated = with the processing of RID messages. For example, a RID message could be = a request for an action or a query for information. This messages need = security services because of the potential impact i.e. we don=92t want = to repeat the mistake of SMTP where there is no authentication when = email is sent between MTAs. The timeframe of the security is around the = request and the response RID messages, i.e. send a RID request, get a = RID response, case closed. The RID security provides operational = security for the functioning of ecosystem.
 
Information policies like information sharing or = confidentiality agreements relate to the actual content itself = regardless of format and persists beyond receiving the data hence apply = to the content of the IODEF documents wherever they are. If I was a = repository of incident data, I am receiving incidents which could be = signed as proof of data origination from many sources. If I receive a = RID query message, I would authorize processing the request based on the = RID security then construct a new IODEF document containing all the = incidents covered by the request. The repository would sign the RID = response, but I want to retain the original signatures of the = contributor of the incident data itself as it relates directly to the = providence of the data.  If the incident data requires specific = access control policies, those too would need to be respected as part of = the response and are orthogonal to the confidentiality of the RID = response as they can change incident by incident. I see any IODEF = security providing security services to support compliance with the = information policies be they regulatory policies, contractual policies, =  information sharing agreements or = whatever.
 
Hope that = helps.
 
Trevor
 
From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] 
Sent: Wednesday, January 15, 2014 = 11:41 AM
To: Trevor Freeman; mile@ietf.org
Subject: RE: Extending the = IODEF-Document class
 
Trevor,
 
Could you elaborate on how this is different from or = compliments the Digital signature and Encryption for IODEF in RID, = RFC6545?  I think that will be helpful = here.
 
Thanks,
Kathleen
 
From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor = Freeman
Sent: Wednesday, January 15, 2014 = 2:02 PM
To: mile@ietf.org
Subject: [mile] Extending the = IODEF-Document class
 
I am = looking at implementing better end to end security with IODEF = documents.
 
For = example, stronger access control on the data than is possible via the = restriction attribute, or stronger data origination authentication by = singing incidents.
 
In both = cases there is  security relevant metadata which may apply to = multiple incidents in an IODEF document. For example with signed = incidents, I want to include a set certificates to enable relying = parties to be able to validate the incident. I also want to optimize the = set of certificates in the document i.e. ensure I don=92t include the = same certificate multiple places in the document. The simplest way to = achieve that is to have all the certificates in one place.  The = logical place to store the set of certificates would be in the IODEF = document class. This is equivalent to CMS, where the set of signing = certificates are in the SignedData object not the SignerInfo object. = However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes.
 
Is it = possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way = it is possible to extend other classes?
 
Trevor
__________________________= _____________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile

= --Apple-Mail=_0F3EDB74-9D31-467A-8752-AE45732A1E9D-- --Apple-Mail=_7005EFD9-CF18-4CC5-92DD-FE7F888873DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS4UjgAAoJEDY/T2tCIPW3ZVQP/1rQmD6oAQ5/FuUXEqD+XpkG 2tIw3itqR9UsN4jrvgkd+0HT5X32PVa8uvT+sTt9Tk6SQHuMCDTlbq3F3yytQOW7 +F0qVjmgDUCvFLf94y1T80vA3cnLY+GiOkaLJKpbSe5gQusDuHqnWB0MKgIN/vym Uqpk3N5/A8AWILSJiif9klnqyBpKRnBAi0C+MqWY+yqEYxD//F3Gs4f6He37Ig1H EyUn8zbH35WNtwTD3Yz+grcBI/GbD7Sk3xiht18g+C0IElAQEhwliF+daQouTUS2 a2bUnl6+m/2B+geQSr6GRC/WvRWGiQX2yCxmLPSVcjYMu0kss8Sqv3IwESuZw3cb TwoNREyuRH8TdBbgMCGhR4Uca165BFzacWfdMtH+U0TonXideNXex2muCUIiA7Vh K3Uuu3vbPl+HzVdxTjICnwwfTfmI+22xlei/5wEgcLArqxv8Lg7BQPf3PY/0CNFr XOCgQhFk/tLrEOPCsuPm+Lyom1gWhL83xK5It5Mwstkvoh4f2FCNJPU0jTQrrtiK m/xmnJzO8zatyQtk2PVyNqjvaN4iH+uTMquzv5MUHXJJzBI06EOXtXF5K/m522H0 /XlH1O043WqFxZCR8yfGt6eWM8fLeoE6q7PeaYC2CXgcKeJiY9n/4XS9BZAGm9jW s03wlcGxx0Se/VK4fn2D =NoVp -----END PGP SIGNATURE----- --Apple-Mail=_7005EFD9-CF18-4CC5-92DD-FE7F888873DB-- From eburger@standardstrack.com Thu Jan 23 08:58:00 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637541A0028 for ; Thu, 23 Jan 2014 08:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ima1PqlhILOt for ; Thu, 23 Jan 2014 08:57:58 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 45DC21A0041 for ; Thu, 23 Jan 2014 08:57:58 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:49318 helo=[192.168.15.103]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1W6NbD-0000cC-8Z for mile@ietf.org; Thu, 23 Jan 2014 08:57:56 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_38310EE7-A9BE-43B4-A7DF-62A76C6758F0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <3C3D0009-6A8D-4D59-943C-7066ECF35942@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Thu, 23 Jan 2014 11:57:45 -0500 References: <359EC4B99E040048A7131E0F4E113AFC54C1AB40@marathon> <1C9F17D1873AFA47A969C4DD98F98A750FAB181B@xmb-rcd-x10.cisco.com> To: "mile@ietf.org" In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FAB181B@xmb-rcd-x10.cisco.com> X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [mile] Impact to the business (Issue #36) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:58:00 -0000 --Apple-Mail=_38310EE7-A9BE-43B4-A7DF-62A76C6758F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Do we have any indication that anyone would fill in this field? On Jan 23, 2014, at 9:31 AM, Panos Kampanakis (pkampana) = wrote: > No objections with BusinessImpact either.=20 > Panos >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw > Sent: Tuesday, January 21, 2014 10:41 PM > To: mile@ietf.org > Subject: [mile] Impact to the business (Issue #36) >=20 > Good evening! >=20 > Issue #36, http://tools.ietf.org/wg/mile/trac/ticket/36, is tracking = the need to represent a summary of the impact an incident had on the = organization in 5070bis. >=20 > To address this need, I would propose adding a new class, = BusinessImpact, to Assessment. >=20 > > +-------------------------+ > | Assessment | > +-------------------------+ > | ENUM occurrence |<>--{0..*}--[ Impact ] > | ENUM restriction |<>--{0..*}--[ BusinessImpact ] > | STRING indicator-uid |<>--{0..*}--[ TimeImpact ] > | STRING indicator-set-id |<>--{0..*}--[ MonetaryImpact ] > | |<>--{0..*}--[ Counter ] > | |<>--{0..1}--[ Confidence ] > | |<>--{0..*}--[ AdditionalData ] > +-------------------------+ >=20 > The BusinessImpact class describes and characterizes the degree to = which the function of the organization was impacted by the Incident. >=20 > The element body describes the impact to the organization as a = free-form text string. The two attributes characterize the impact. >=20 > +-------------------------+ > | BusinessImpact | > +-------------------------+ > | ML_STRING | > | | > | ENUM severity | > | ENUM type | > +-------------------------+ >=20 > @severity (characterizes the severity of the incident on business = functions, from NIST SP800-61 Table 3-2) None =3D No effect to the = organization's ability to provide all services to all users Low =3D = Minimal effect as the organization can still provide all critical = services to all users but has lost efficiency Medium =3D The = organization has lost the ability to provide a critical service to a = subset of system users High =3D The organization is no longer able to = provide some critical services to any users unknown =3D The impact is = unknown ext-severity =3D Extension mechanism >=20 > @type (characterizes the effect this incident had on the business) = breach-propriety =3D Sensitive or proprietary information was accessed = or exfiltrated breach-privacy =3D Personally identifiable information = was accessed or exfiltrated loss-of-integrity =3D Sensitive or = proprietary information was changed or deleted loss-of-service =3D = Service delivery was disrupted loss-financial =3D Money or services were = stolen degraded-reputation =3D The reputation of the organization's = brand was diminished asset-destruction =3D A cyber-physical system was = damaged legal =3D Incident resulted in legal or regulatory action = ext-type Extension mechanism >=20 > Any thoughts? @type might be missing a few values. >=20 > Roman > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_38310EE7-A9BE-43B4-A7DF-62A76C6758F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS4UoKAAoJEDY/T2tCIPW3CZwP/j0FsFL8Zr//1wKOM+DdDhjy /fcO2b4/gOoUjssFSp44Z7mVdhqIpO951wLeqJmkrKI7X1/X03aNRyJgkmEw299/ GdjuL0q3OegwGxBEmLiOOnub6l3DI+4mYJHqgg1HPmSb6iTselZ3RR19ICDf0E6t TIm8q+zSR8UrtTgqCpl5nOyegQOBBWpA4n5acj7EHdyespmlMS6qgfJF/trcLWDI RgxlFTn78SqcrYNRm96Tigv5+MRMZdIcDzJ/DCIDUwVzbdZUCi+1/FGERg5fG1gO RPn/UiG0wKS17CuhcchSgps4SyaYAQkjSm+cRBD4IyzcSE+VNvLiMwVnbJ1lXzUC mYxPt579NeO/pCvb2o5/Qfe9Vgr4JMOg7rdCL1U0KdOOzfCdJwB6mBp5JSS/YVeV 5kD9NFvu9fIrpkphYcoVLU+2O6cCXHZaJfL1uceYHJ+efg9VEaUIiMSh0R4aXmGe nbbPED6G1mO98/uU2xv0gtVyVMYwVFaAhxm0DaQzx+eU16mKOw224I7KP/nTCX6H 5ru0N37XZiwKKE4eYll5Tvs0+O2tmku8eeOOUIYPut9G+4lWRA+6syj7YtVkBu48 xnh9bMNuUB9Es5LEvpv2ToMPvqP/dn2UR7qxUuPmdztY25rZgZ8GDghDk1HpeLFP cnLwvOG52Ob2XX/wfE3m =VJwS -----END PGP SIGNATURE----- --Apple-Mail=_38310EE7-A9BE-43B4-A7DF-62A76C6758F0-- From kathleen.moriarty@emc.com Thu Jan 23 09:49:14 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7C1A014F for ; Thu, 23 Jan 2014 09:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWF0xBwCIvWv for ; Thu, 23 Jan 2014 09:49:09 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 736671A014C for ; Thu, 23 Jan 2014 09:49:09 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0NHmtxp006089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2014 12:48:56 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0NHmtxp006089 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390499337; bh=399gcbiSJm9TquwGh6IfgwAgQTs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dzY9uxsRHyBe3FWZLysSvAp9ulPp22ndjDww4ZFAoU9C5ZjWG0d/OD0rJPgBDpJi3 iLbLihxc0K1O9xRUKu0i3YCHd3k3tttTBYHL7lEqfyXSgiCfmoBNCvBLuGbsYA/Av7 lHLhaHoM2OTCtJpKmlQo7RPKwh+4wIlxrtQJaUXc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0NHmtxp006089 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd52.lss.emc.com (RSA Interceptor); Thu, 23 Jan 2014 12:48:32 -0500 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0NHmViN031197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 12:48:31 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Thu, 23 Jan 2014 12:48:30 -0500 From: "Moriarty, Kathleen" To: Eric Burger Date: Thu, 23 Jan 2014 12:48:31 -0500 Thread-Topic: [mile] An alternative way to represent a URL Thread-Index: Ac8YY1QAq4GhjtQzQTO3ign4V4Rg7g== Message-ID: <3BB285B5-F453-442D-8E13-60C6699BDD36@emc.com> References: <359EC4B99E040048A7131E0F4E113AFC54C149B2@marathon> 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-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Cc: "mile@ietf.org" Subject: Re: [mile] An alternative way to represent a URL X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 17:49:14 -0000 Hi Eric, We need to include URLs that are references in addition to the newly added = ability to include a URL that is an indicator. The URL as a reference coul= d include a description of malware or a type of attack, etc. my quick ment= ion of URL as a reference was not clear on that point. =20 Thanks, Kathleen=20 Sent from my iPhone > On Jan 23, 2014, at 11:49 AM, "Eric Burger" = wrote: >=20 > One and only one way to indicate a Thing sounds good to me. I would remov= e the reference, as it does not change 5070 at all and it also removes the = temptation to implement in another, not-quite-compatible format. >=20 >> On Jan 16, 2014, at 3:02 PM, Moriarty, Kathleen wrote: >>=20 >> Hi Roman, >>=20 >> I think it was only left in to show that we could do this another way if= people were interested. If the WG is happy with the approach in place now= that achieves the same objective, this can be removed. The discussions th= at led to this may go back to Rosella's presentation and that URLs could on= ly be included as a reference and not an indicator in IODEF v1. >>=20 >> Thanks, >> Kathleen >>=20 >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw >> Sent: Thursday, January 16, 2014 1:57 PM >> To: mile@ietf.org >> Subject: [mile] An alternative way to represent a URL >>=20 >> Hello, >>=20 >> The schema definition of the Node class in -03 of 5070bis has the follow= ing comment in it: >>=20 >> [begin schema snippet] >> [en= d schema snippet] >>=20 >> This proposal would provide an alternative to the current approach of re= presenting a URI for a Node using Address@category=3D"site-uri" (e.g., http://www.example.com/sites/foo). >>=20 >> I don't know the origin or rational for this comment. Could anyone shed= light on why we'd want to change the current representation? >>=20 >> Roman >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >>=20 >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >=20 > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Thu Jan 23 17:52:20 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272751A0483 for ; Thu, 23 Jan 2014 17:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E4MajKFAsVE for ; Thu, 23 Jan 2014 17:52:17 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 526061A02C8 for ; Thu, 23 Jan 2014 17:52:16 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0O1q6Dk016285; Thu, 23 Jan 2014 20:52:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390528326; bh=fHlNOSHVVomwhv7LWXscg0mw0GqEa6FLvS+l6D0g2Pc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=Gkm1x5r2wTuWmYgKz1Fz7Nl/GU82YwHs1TVMBjJkZoMYGFY7hTnTZYkuIV+ihYSKq KL2MjHf0CcislOgFI+2QdPusXJB/7n0dbqnQvOA6f9rsYkhXdH2Kx8wrmPRIF+AuFB pG5xGHZpQeb9Sv8q9Noy2jxwhJDl10D14XVhm8v4= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0O1q5TP025171; Thu, 23 Jan 2014 20:52:05 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 23 Jan 2014 20:52:05 -0500 From: "Roman D. Danyliw" To: "Panos Kampanakis (pkampana)" , "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Attributes of the Key class Thread-Index: Ac8ROH1UKtJl+89zQoqJaQFudDjEbQAEDvZwAb/7h+AAF2GNMA== Date: Fri, 24 Jan 2014 01:52:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1E7F7@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C104F8@marathon> <1C9F17D1873AFA47A969C4DD98F98A750FAB192F@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FAB192F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Attributes of the Key class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:52:20 -0000 Hello, Comments inline ... > -----Original Message----- > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Thursday, January 23, 2014 10:21 AM > To: Moriarty, Kathleen; Roman D. Danyliw; mile@ietf.org > Subject: RE: Attributes of the Key class >=20 > My thoughts in in PK> >=20 > >> ** RegistryKeyModified/Key has the @ext-category attribute whose text > reads "extension category". Could someone please explain the purpose of > this attribute or provide better text. It seems like this attribute was = a typo > and should really be named @ext-registryaction to extend @registryaction > when it is set to "ext-value". >=20 > KM> I am having trouble finding this one in the current document.. > PK> I think this existed in the -03 doc but removed in -04. Yes, @ext- > registryaction is the right attribute IMO. RD> Panos is right. In the -04, it was assumed that @ext-category was at t= ypo and renamed to be @ext-registryaction. > >> ** RegistryKeyModified/Key also has the attributes @type and @type-ext > listed in the text, but not in the schema. It is not documented but is > described as having two enumerated values of "watchlist" and "ext-value". > Could someone please explain this attribute or provide better text. Also= , the > numerated value of "ext-value" for @type is being used in a way > inconsistently with Section 5.1. We need to fix that. >=20 > KM> Ah, okay from my last response, this additional context helps to see = the > intent. I think this was to provide a watchlist. The schema just had a > comment to see if it should be included. As long as you can include a > watchlist, the intent would be met. The watchlist would be a list of val= ues > that may be ORed with other values in the list and an AND with the > EventData in the set. >=20 > PK> Agree. I propose the attribute to be >=20 > > > > > > > > >=20 > BTW, the RegistryKeyModified should be WindowsRegistryKeysModified > which seems to be fixed in the -04 version of the doc. RD> Like above, yes the misnamed "RegistryKeyModified" was changed to "Wind= owsRegistryKeysModified" in the -04 version. I also tried to make all comp= lex classes in the schema have a name similar to the element name to reduce= confusion (e.g., EmailDetails complexType for an element named EmailInfo) Roman > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Moriarty, Kathleen > Sent: Wednesday, January 22, 2014 7:20 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: Re: [mile] Attributes of the Key class >=20 > Hi Roman, >=20 > I'll answer in line. Others, please chime in. >=20 > Thanks! > Kathleen >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Tuesday, January 14, 2014 10:25 AM > To: mile@ietf.org > Subject: [mile] Attributes of the Key class >=20 > Hello, >=20 > In reviewing the -03 draft, I have a few questions on the definition of t= he Key > class (Section 3.22.1). >=20 > ** RegistryKeyModified/Key has the @ext-category attribute whose text > reads "extension category". Could someone please explain the purpose of > this attribute or provide better text. It seems like this attribute was = a typo > and should really be named @ext-registryaction to extend @registryaction > when it is set to "ext-value". >=20 > KM> I am having trouble finding this one in the current document.. >=20 > ** RegistryKeyModified/Key also has the attributes @type and @type-ext > listed in the text, but not in the schema. It is not documented but is > described as having two enumerated values of "watchlist" and "ext-value". > Could someone please explain this attribute or provide better text. Also= , the > numerated value of "ext-value" for @type is being used in a way > inconsistently with Section 5.1. We need to fix that. >=20 > KM> Ah, okay from my last response, this additional context helps to see = the > intent. I think this was to provide a watchlist. The schema just had a > comment to see if it should be included. As long as you can include a > watchlist, the intent would be met. The watchlist would be a list of val= ues > that may be ORed with other values in the list and an AND with the > EventData in the set. >=20 > Roman > _______________________________________________ > 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 murillo@ieee.org Thu Jan 23 18:11:01 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68F1A01BE for ; Thu, 23 Jan 2014 18:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKfS8rGvk6QO for ; Thu, 23 Jan 2014 18:10:56 -0800 (PST) Received: from m1plsmtpa01-08.prod.mesa1.secureserver.net (m1plsmtpa01-08.prod.mesa1.secureserver.net [64.202.165.187]) by ietfa.amsl.com (Postfix) with ESMTP id BC46A1A017D for ; Thu, 23 Jan 2014 18:10:56 -0800 (PST) Received: from [10.8.90.31] ([66.205.162.90]) by m1plsmtpa01-08.prod.mesa1.secureserver.net with id HeAt1n0081xKu6y01eAu0L; Thu, 23 Jan 2014 19:10:55 -0700 X-Sender: martin@murillos.net Message-ID: <52E1CBB5.6000906@ieee.org> Date: Thu, 23 Jan 2014 21:11:01 -0500 From: Martin Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: mile@ietf.org References: <20140122155745.18162.21877.idtracker@ietfa.amsl.com> In-Reply-To: <20140122155745.18162.21877.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140122155745.18162.21877.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: murillo@ieee.org List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:11:01 -0000 Dear all, Please find below a link to a proposed draft for extending IODEF for the reporting of cyber-physical system incidents. These systems are often referred as Operational Technology Systems, Industrial Control Systems, Automatic Control Systems, or simply Control Systems. Cyber-Physical systems have been around for decades. However, they are now at a higher risk to be the target of attacks by individual highly-skilled attackers, organized groups, nation-states, or simply suffer repercussions of mainstream IT cyber-attacks. While over 90% of critical control system infrastructure is currently owned by private enterprises, these can have direct repercussions on national security of world nations. Indeed, various of these systems are key parts of nuclear reactor facilities, transportation systems, electric power distribution, oil and natural gas distribution, health care, water and waste-water treatment, dam infrastructure, missile and defense systems, and others. The disruption of these control systems could have a significant impact on public health, safety, and lead to large economic losses. Among the issues that catalyze this higher risk are: i) these systems are gradually becoming more interconnected, ii) legacy systems do not have proper cybersecurity protection, iii) the existence of highly-skilled individuals and motivations, iv) some these systems are generally considered critical, v) these are a natural extension of IT cyber-attacks, vi) the emergence of the Internet of Things (IOT), and vi) these attacks can be carried out remotely and quite inexpensively. While there might exist national approaches to deal with incidents, there's the need of a global international approach that will engulf governments, private organizations and other stakeholders. IETF, as a leading global Internet standards organization, seeks to satisfy this need through open standards that seek to encompass issues that are critical for the global community. Feedback at two levels are welcome: 1. On the existence and inclusion either by utilizing any already existing industry formats (XML- encoded) and/or by utilizing atomic data 2. Contributions on making the extension (and background information) more comprehensive, accurate and principally useful for the community Look forward to feedback and other input! Martin Murillo A new version of I-D, draft-murillo-mile-cps-00.txt has been successfully submitted by Martin Murillo and posted to the IETF repository. Name: draft-murillo-mile-cps Revision: 00 Title: IODEF extension for Reporting Cyber-Physical System Incidents Document date: 2014-01-21 Group: Individual Submission Pages: 24 URL: http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt Status: https://datatracker.ietf.org/doc/draft-murillo-mile-cps/ Htmlized: http://tools.ietf.org/html/draft-murillo-mile-cps-00 Abstract: This draft document will extend the Incident Object Description Exchange Format (IODEF) defined in [RFC5070] to support the reporting of incidents dealing with attacks to physical infrastructure through the utilization of IT means as a vehicle or as a tool. These systems might also be referred as Cyber-Physical Systems (CPS), Operational Technology Systems, Industrial Control Systems, Automatic Control Systems, or simply Control Systems. These names are used interchangeably in this document. In this context, an incident is generally the result of a cybersecurity issue whose main goal is to affect the operation of a CPS. It is considered that any unauthorized alteration of the operation is always malign. This extension will provide the capability of embedding structured information, such as identifier- and XML-based information. In its current state, this document provides important considerations for further work in implementing Cyber-Physical System incident reports, either by utilizing any already existing industry formats (XML- encoded) and/or by utilizing atomic data. In addition, this document should provide appropriate material for helping making due considerations in making an appropriate decision on how a CPS reporting is done: 1) through a data format extension to the Incident Object Description Exchange Format [RFC5070], 2) forming part of an already existing IODEF-extension for structured cybersecurity information (currently draft draft-ietf-mile-sci-11.txt), or others. While the format and contents of the present document fit more the earlier option, these can also be incorporated to the later. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From rdd@cert.org Thu Jan 23 18:20:00 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0735E1A010E for ; Thu, 23 Jan 2014 18:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq_D2prdub4u for ; Thu, 23 Jan 2014 18:19:53 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9CF1A0098 for ; Thu, 23 Jan 2014 18:19:53 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0O2JoPn016744; Thu, 23 Jan 2014 21:19:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390529990; bh=jY+Z57cND0vV9CjbPBW7NuqgB/+7yaJ/0ucL8FaCjF0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To; b=QxIvY60gtpCFYjyoaEvl8xE9Ck/6LKvvIlC6qW0ZUukoCfltCmWfMrxJv5RoZtSyL f4aFRCwyRcf+I7yCYDbXYTvVkoPlyzEK+McOp5n8JlTF60/WO+wyJmjm5eAVHSTQn6 Aqiywi8fmsPAfad/Qkmw7+vkRLqsC/z45TnwEXAg= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0O2JqVG004245; Thu, 23 Jan 2014 21:19:52 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Thu, 23 Jan 2014 21:19:49 -0500 From: "Roman D. Danyliw" To: Eric Burger Thread-Topic: [mile] Describing the time window during which an indicator should be used Thread-Index: Ac8QYd5ePk2lBkToRcSzhFdZzeEY9QBp2miAAZ7BfgAACK1eYA== Date: Fri, 24 Jan 2014 02:19:48 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1EA8D@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C12208@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C1EA8Dmarathon_" MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Describing the time window during which an indicator should be used X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:20:00 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C1EA8Dmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see your perspective Eric. Let's talk through a little more about how we = could use this fifth indicator attribute, perhaps calling it "indicator-per= sistent" for the moment. It seems like we'd end up in one of the following= situations: (1) known start time and end time for an indicator (i.e., only look for the= indicator during the described interval) (2) known start time for an indicator (i.e., look for the indicator indefin= itely after the start time) (3) known end time (i.e., an indicator won't be valid after a certain time = so look for it only before an end time) (4) unknown start or end time (i.e., look for the indicator on any data you= have) Do we want to deal with all of them? Are there others? If we did want to = cover all cases perhaps we could define @indicator-persistent as an ENUM: "start" =3D assume that the indicator is valid up to the provided @indicato= r-end-time. If this value is selected, @indicator-end-time must be set and= @indicator-start must not be set. "end" =3D assume that the indicator is valid indefinitely starting from the= provided @indicator-start-time. If this value is selected, @indicator-sta= rt-time value must be set and @indicator-end-time value must not be set. "defined" =3D assume that the indicator is valid between the specified @ind= icator-start-time and @indicator-end-time. If this value is selected both = the @indicator-start-time and @indicator-end-time must be set. "unknown" =3D assume that the indicator can be valid during any time period= . If this value is selected both @indicator-start-time and @indicator-end-= time must not be set. This is the default. Roman From: Eric Burger [mailto:eburger@cs.georgetown.edu] Sent: Thursday, January 23, 2014 11:45 AM To: Roman D. Danyliw Cc: mile@ietf.org Subject: Re: [mile] Describing the time window during which an indicator sh= ould be used Say what we mean. We are already paying the XML tax, so a fifth attribute d= oes not really 'cost' us anything. I can guarantee that we will have more p= roblems than a Year 3000 problem if we overload indicator-etime. On Jan 15, 2014, at 11:02 AM, Roman D. Danyliw > wrote: Hi, I'd like to explore the community thinking on how to implement a flag as Ch= ris suggested to note that an indicator is persistent. Assuming that the c= onvention of @indicator-stime and -etime was adopted, a few possibilities t= o add a "persistence flag" would be: (1) Add a boolean attribute, say @indicator-persistent, to convey to always= look for this indicator. No @indicator-etime would be required. (2) Define a particular date far into the future for @indicator-etime that = conveys persistence. For example, when @indicator-etime=3D"3000/12/01 12:0= 0:00" is seen, this indicator is persistent. Option #1 is most intuitively self-describing but adds another attribute, n= ow the fifth, to the list of "special indicator attributes". Option #2 reduces the number of additional attributes. Personally, I prefer #2. Your thoughts? Roman From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] Sent: Monday, January 13, 2014 8:18 AM To: Roman D. Danyliw; Stoecker, Paul Cc: mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator sh= ould be used Roman, >From what I have seen the aging is usually up to the recipient. I would say= that option #1 would be better. For purposes of deciding to stop looking for an indicator there is another = data point that is used far more frequently, Last Seen time. For the majori= ty of indicators we use the time it was last "seen". For us the "seen" mean= s that either we have seen it being used or we have intel from a 3rd party = or open source that it is still in use. The only time we use the stime-etim= e paradigm is when there is an infection (delivery stage of the Kill Chain)= that was valid but later cleaned up. Nbc.com was compromi= sed last year for about 4 hours then cleaned up. In that case we would use = stime-etime. There are indicators that we call persistent. These are indica= tors that we will never stop looking for. These could be indicators that ar= e used exclusively by a specific threat actor (like a domain registered by = an actor) or something that we used in a previous incident at our organizat= ion, like RSA breech related indicators. A construct to flag an indicator a= s persistent would be helpful as this is information is something we routin= ely share. Thanks, --Chris From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 09, 2014 4:59 PM To: Harrington, Christopher; Stoecker, Paul Cc: mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator sh= ould be used Hello! Chris: Thanks for the background! To date, the message traffic suggests interest in per-indicator annotation = of validity. That would suggest something as follows: Or The follow-up discuss asked if organizations really every stop looking for = indicators they have. One answer was yes. How do we want to handle that? Ideas might include: (1) provide only an @indicator-stime and @indicator-etime, and these are th= e best guess of the reporter of how long to make it valid. The recipient c= an decide how and if to honor these. (2) provide another attribute that would suggest an aging policy that the r= ecipient can choose to honor. What would we those aging policies? Roman From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] Sent: Monday, December 23, 2013 10:46 AM To: Stoecker, Paul Cc: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Describing the time window during which an indicator sh= ould be used Yes we do stop looking. A good example is when NBC.com got= hacked a few months ago. We watched for people hitting it while the URL wa= s malicious. Once it was cleaned up we stopped watching for it since it was= a somewhat popular URL that would fire all the time and bury us in false = positives. Indicator aging is an area that nobody has a good handle one. Each organiza= tion seems to have their own way of doing things with aging, if they do any= thing at all. Some commercial threat intel providers use a decrementing cou= nter based on the last time the indicator was seen. At EMC we make the agin= g calculation based on time since last seen, attribution (if known), kill c= hain stage, confidence in the source and other factors. It's not automated= at this point. We can't keep all indicators forever. At some point the watch lists and blo= ck lists on your Proxy, firewall, etc get too large and the devices start h= aving issues. We ran into this at EMC and had to switch from Proxy blocks f= or domains to DNS RPZ with a sinkhole web servers. There were too many doma= ins in the proxy block list. We have tens of thousands. There are indicator= s that we consider "persistent". These are indicators that we always want t= o be alerted about. Generally these are advanced threat / APT and have eith= er been seen in activity involving EMC or they belong to threat actor group= s that we have seen at EMC. Thanks, --Chris From: Stoecker, Paul Sent: Monday, December 23, 2013 10:26 AM To: Harrington, Christopher Cc: Roman D. Danyliw; mile@ietf.org Subject: Re: [mile] Describing the time window during which an indicator sh= ould be used I have a question...Do we really stop looking for IOCs whose time has expir= ed? Like a malicious URL whose time has expired...do you stop looking for = that URL? Let's say that Paul the malware dude got a hold of the IODEF doc= ument...I shutdown my web server and after the time expired I turned it bac= k on? Just wondering how IOC aging is actually handled? Sent from my iPhone On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" > wrote: Hello, Answers inline below. Thanks, --Chris Christopher Harrington Consulting Security Engineer GSO - Critical Incident Response Center EMC 174 Middlesex Turnpike Bedford, MA 01730 781-515-5862 (work) 603-583-1585 (cell) From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, December 20, 2013 4:26 PM To: mile@ietf.org Subject: [mile] Describing the time window during which an indicator should= be used Hello! Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking = the need to convey the valid time during which to apply an indicator. I wa= nted to solicit from the community the degree of flexibility desired. For = the purposes of this discussion an indicator is defined as a class that has= an @indicator-uid attribute. ** Does this flexibility need to exist on a per indicator basis? Example 1, Yes, a malicious URL would be valid only as long as it is live. ** Could it be at the EventData level (and the time window cascades to all = indicators that are children)? Example 2:, ... = ... many domain indicators ... Example 3: ... 2013/12/01 12:00:00 ... ... many domain indicators ... Yes, you could have multiple malware delivery URLs that are all on the same= domain. If the Domain is specified at EvenData level then when it is no lo= nger valid the children would no longer be valid. I hope I explained that r= ight :) I am not sure how it would differ between Example 2 and 3. ** Could it be at the Incident level? Example 4: ... 2013/12/01 12:00:00 ... many domain indicators ... If there was only one Indicator in an incident it could be. In practical te= rms this is very unlikely. Per indicator time information would provide the most flexibility but would= require duplication of the same information. A time window for indicator validity specified at the Incident level would = not allow for multiple time windows per indicator. A time window for indicator validity specified in the EventData class would= require nested EventData instances to convey different time period. Also,= some indicators are only in the Incident class so this approach would be i= nsufficient. Perhaps a hybrid approach where this timing information is in= the EventData and IncidentData classes could be possible. Personally I think the safest approach is validity per Indicator. Validity= for parent / child would be rare and validity per Incident even rarer. One question, how do we represent "still valid"? If I have an indicator tha= t is valid when I send the message how do I know what that time represents?= If I put "12/20/2013 13:00" as the time can you tell if I mean that it wa= s still valid when I sent the message at that time or that its validity per= iod ended at that time. Those are very different scenarios and critically i= mportant for searching / responding to indicator hits. Roman _______________________________________________ mile mailing 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_359EC4B99E040048A7131E0F4E113AFC54C1EA8Dmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see your perspective Er= ic. Let’s talk through a little more about how we could use this fift= h indicator attribute, perhaps calling it “indicator-persistent”= ; for the moment.  It seems like we’d end up in one of the follow= ing situations:

 <= /p>

(1) known start time and = end time for an indicator (i.e., only look for the indicator during the des= cribed interval)

(2) known start time for = an indicator (i.e., look for the indicator indefinitely after the start tim= e)

(3) known end time (i.e.,= an indicator won’t be valid after a certain time so look for it only= before an end time)

(4) unknown start or end = time (i.e., look for the indicator on any data you have)<= /p>

 <= /p>

Do we want to deal with a= ll of them?  Are there others?  If we did want to cover all cases= perhaps we could define @indicator-persistent as an ENUM:

 <= /p>

“start” =3D a= ssume that the indicator is valid up to the provided @indicator-end-time.&n= bsp; If this value is selected, @indicator-end-time must be set and @indica= tor-start must not be set.

“end” =3D ass= ume that the indicator is valid indefinitely starting from the provided @in= dicator-start-time.  If this value is selected, @indicator-start-time value must be set and @indicator-end-time value must not be set.

“defined” =3D= assume that the indicator is valid between the specified @indicator-start-= time and @indicator-end-time.  If this value is selected both the @ind= icator-start-time and @indicator-end-time must be set.

“unknown” =3D= assume that the indicator can be valid during any time period.  If th= is value is selected both @indicator-start-time and @indicator-end-time mus= t not be set.  This is the default.

 <= /p>

Roman

 <= /p>

From: Eric Bur= ger [mailto:eburger@cs.georgetown.edu]
Sent: Thursday, January 23, 2014 11:45 AM
To: Roman D. Danyliw
Cc: mile@ietf.org
Subject: Re: [mile] Describing the time window during which an indic= ator should be used

 

Say what we mean. We are already paying the XML tax,= so a fifth attribute does not really ‘cost’ us anything. I can= guarantee that we will have more problems than a Year 3000 problem if we o= verload indicator-etime.

 

On Jan 15, 2014, at 11:02 AM, Roman D. Danyliw <<= a href=3D"mailto:rdd@cert.org">rdd@cert.org> wrote:



Hi,

 

I’d like to explore= the community thinking on how to implement a flag as Chris suggested to no= te that an indicator is persistent.  Assuming that the convention of @indicator-stime and –etime was adopted, a few possibilities to add a “p= ersistence flag” would be:

 

(1) Add a boolean attribu= te, say @indicator-persistent, to convey to always look for this indicator.=   No @indicator-etime would be required.

 

(2) Define a particular d= ate far into the future for @indicator-etime that conveys persistence. = ; For example, when @indicator-etime=3D”3000/12/0= 1 12:00:00”  is seen, this indicator is persistent.

 

Option #1 is most intuitively self-desc= ribing but adds another attribute, now the fifth, to the list of “spe= cial indicator attributes”.

 

Option #2 reduces the number of additio= nal attributes.

 

Personally, I prefer #2.  Your tho= ughts?

 

Roman

 

From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] 
Sent: Monday, Janu= ary 13, 2014 8:18 AM
To: Roman D. Danyl= iw; Stoecker, Paul
Cc: mile@ietf.org Subject: RE: [mile= ] Describing the time window during which an indicator should be used

 

Roman,

 

From what I have seen the= aging is usually up to the recipient. I would say that option #1 would be = better.

 

For purposes of deciding = to stop looking for an indicator there is another data point that is used f= ar more frequently, Last Seen time. For the majority of indicators we use the time it was last “seen”. For us the R= 20;seen” means that either we have seen it being used or we have inte= l from a 3rd p= arty or open source that it is still in use. The only time we use the stime-etime paradigm is when there is an infection (delivery stage of = the Kill Chain) that was valid but later cleaned up. Nbc.com was compromised last year for about 4 hours then cleaned up. In that case we w= ould use stime-etime. There are indicators that we call persistent. These a= re indicators that we will never stop looking for. These could be indicator= s that are used exclusively by a specific threat actor (like a domain registered by an actor) or something = that we used in a previous incident at our organization, like RSA breech re= lated indicators. A construct to flag an indicator as persistent would be h= elpful as this is information is something we routinely share.

 

Thanks,

 

--Chris

 

From: Roman D. Danyliw [m= ailto:rdd@cert.org] <= /span>
Sent: Thursday, Ja= nuary 09, 2014 4:59 PM
To: Harrington, Ch= ristopher; Stoecker, Paul
Cc: mile@ietf.org Subject: RE: [mile= ] Describing the time window during which an indicator should be used

 

Hello!

 

Chris: Thanks for the bac= kground!

 

To date, the message traf= fic suggests interest in per-indicator annotation of validity.  That w= ould suggest something as follows:

 

<Assessment indicator-uid=3D”f= oo-12345” indicator-stime=3D”2013/12/01 12:00:00”>

Or

<Assessment indicator-uid=3D”f= oo-12345” indicator-stime=3D”2013/12/01 12:00:00” indicat= or-etime=3D”2013/12/01 13:00:00”-->

 

The follow-up discuss asked if organiza= tions really every stop looking for indicators they have.  One answer = was yes.

 

How do we want to handle that?  Id= eas might include:

 

(1) provide only an @indicator-stime an= d @indicator-etime, and these are the best guess of the reporter of how lon= g to make it valid.  The recipient can decide how and if to honor these.

 

(2) provide another attribute that woul= d suggest an aging policy that the recipient can choose to honor.  Wha= t would we those aging policies?

 

Roman

 

 

From: Harrington, Christopher [mailto:Christopher.Harrington@emc.com] 
Sent: Monday, Dece= mber 23, 2013 10:46 AM
To: Stoecker, Paul=
Cc: Roman D. Danyl= iw; <= a href=3D"mailto:mile@ietf.org">mile@ietf.org
Subject: RE: [mile= ] Describing the time window during which an indicator should be used

 

Yes we do stop looking. A= good example is when NBC.com got hacked a few months ago. We watched for people hitting it while the URL wa= s malicious. Once it was cleaned up we stopped watching for it since it was= a somewhat popular  URL that would fire all the time and bury us in f= alse positives.

 

Indicator aging is an are= a that nobody has a good handle one. Each organization seems to have their = own way of doing things with aging, if they do anything at all. Some commercial threat intel providers use a decrementing counter = based on the last time the indicator was seen. At EMC we make the aging cal= culation based on time since last seen, attribution (if known), kill chain = stage, confidence in the source  and other factors. It’s not automated at this point.

 

We can’t keep all i= ndicators forever. At some point the watch lists and block lists on your Pr= oxy, firewall, etc get too large and the devices start having issues. We ran into this at EMC and had to switch from Proxy blocks for do= mains to DNS RPZ with a sinkhole web servers. There were too many domains i= n the proxy block list. We have tens of thousands. There are indicators tha= t we consider “persistent”. These are indicators that we always want to be alerted about. Generally these ar= e advanced threat / APT and have either been seen in activity involving EMC= or they belong to threat actor groups that we have seen at EMC.

 

Thanks,

 

--Chris

 

From: Stoecker, Paul 
Sent: Monday, Dece= mber 23, 2013 10:26 AM
To: Harrington, Ch= ristopher
Cc: Roman D. Danyl= iw; <= a href=3D"mailto:mile@ietf.org">mile@ietf.org
Subject: Re: [mile= ] Describing the time window during which an indicator should be used

 

I have a question...Do we really stop l= ooking for IOCs whose time has expired?  Like a malicious URL whose ti= me has expired...do you stop looking for that URL?  Let's say that Paul the malware dude got a hold of the IODEF document...I shutdown m= y web server and after the time expired I turned it back on?

 

Just wondering how IOC aging is actuall= y handled?

Sent from my iPhone


On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" <Ch= ristopher.Harrington@emc.com> wrote:

Hello,

 

Answers inline below.

 

Thanks,

 

--Chris

 

Christopher Harrington Consulting Security Engineer
GSO - Critical Incident Response Center
EMC
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. D= anyliw
Sent: Friday, Dece= mber 20, 2013 4:26 PM
To: mile@ietf.o= rg
Subject: [mile] De= scribing the time window during which an indicator should be used

 

Hello!

 

Ticket #28 (http://trac= .tools.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey the valid time during which to apply an indicator. &nbs= p;I wanted to solicit from the community the degree of flexibility desired.=   For the purposes of this discussion an indicator is defined as a cla= ss that has an @indicator-uid attribute.

 

** Does this flexibility need to exist = on a per indicator basis?

Example 1, <Assessment indicator-uid= =3D”foo-12345” indicator-valid-stime=3D”2013/12/01 12:00:= 00”>

Yes, a malicious URL woul= d be valid only as long as it is live.

 

** Could it be at the EventData level (= and the time window cascades to all indicators that are children)?

Example 2:, <EventData indicator-sti= me=3D”2013/12/01 12:00:00”> … <Flow> … man= y domain indicators </Flow> … </EventData>

Example 3: <EventData>  R= 30; <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime>= ; … <Flow> … many domain indicators </Flow> …= </EventData>

Yes, you could have multi= ple malware delivery URLs that are all on the same domain. If the Domain is= specified at EvenData level then when it is no longer valid the children would no longer be valid. I hope I explained that right J  I am not sure how it would differ between Example 2 and 3.

 

** Could it be at the Incident level?

Example 4: <Incident>  ̷= 0; <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime>= … many domain indicators </Flow> … </Incident>

If there was only one Ind= icator in an incident it could be. In practical terms this is very unlikely= .

 

Per indicator time information would pr= ovide the most flexibility but would require duplication of the same inform= ation.

 

A time window for indicator validity sp= ecified at the Incident level would not allow for multiple time windows per= indicator.

 

A time window for indicator validity sp= ecified in the EventData class would require nested EventData instances to = convey different time period.  Also, some indicators are only in the Incident class so this approach would be insufficient.  P= erhaps a hybrid approach where this timing information is in the EventData = and IncidentData classes could be possible.

 

Personally I think the sa= fest approach is validity per Indicator.  Validity for parent / child = would be rare and validity per Incident even rarer.

 

One question, how do we r= epresent “still valid”? If I have an indicator that is valid wh= en I send the message how do I know what that time represents?  If I put “12/20/2013 13:00” as the time can you tell if I mean that= it was still valid when I sent the message at that time or that its validi= ty period ended at that time. Those are very different scenarios and critic= ally important for searching / responding to indicator hits.

 

Roman

 

_______________________________________________
mile mailing 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_359EC4B99E040048A7131E0F4E113AFC54C1EA8Dmarathon_-- From rdd@cert.org Thu Jan 23 18:25:35 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5319D1A0111 for ; Thu, 23 Jan 2014 18:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4haen4RpAkVj for ; Thu, 23 Jan 2014 18:25:31 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41C871A0098 for ; Thu, 23 Jan 2014 18:25:31 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0O2PTdx016820; Thu, 23 Jan 2014 21:25:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390530329; bh=Gbdbxeg2Hg2fqcfEH4qrO9TyQE9kk70AS+9QAj9r9ks=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=A4Q1fx/bA6btjJeik6ESYi7WiH3Sv7DdUrZ/C93PULb2e3uMqNOi1uGSGYQRpvjOh AcrrrXWJQMi2WVuYG7vlOH97WpCQSOG/7B884U4OxyiVSJDOS24wOo7q0/N/cCVG5V 9FjB58Ek6LhfPe0CedkblJhxWIFhrCetWMaBK5pc= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0O2PVqT004678; Thu, 23 Jan 2014 21:25:31 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Thu, 23 Jan 2014 21:25:28 -0500 From: "Roman D. Danyliw" To: Eric Burger Thread-Topic: [mile] Representing a domain name (or Issue #4) Thread-Index: Ac8SAgtTsOQXjaJoSD+fM1PrWR2VyQACdNwQAZ4yTYAACZEnkA== Date: Fri, 24 Jan 2014 02:25:27 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1EAC1@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C1204A@marathon> <359EC4B99E040048A7131E0F4E113AFC54C122B3@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mile@ietf.org" Subject: Re: [mile] Representing a domain name (or Issue #4) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 02:25:35 -0000 I tend to agree that domain information is important enough to break compat= ibility. We've already done that with the Reference class. Hence, my pref= erence would be for Option #1. Roman > -----Original Message----- > From: Eric Burger [mailto:eburger@standardstrack.com] > Sent: Thursday, January 23, 2014 11:47 AM > To: Roman D. Danyliw > Cc: mile@ietf.org > Subject: Re: [mile] Representing a domain name (or Issue #4) >=20 > All I care about is if one is describing a Domain Name Thing, then wherev= er > one references the Domain Name Thing, one references it the same way. >=20 > How important is backwards compatibility with 5070 in this case? I would > think tis would be one of the more commonly used data elements, but I cou= ld > be wrong. >=20 > On Jan 15, 2014, at 11:23 AM, Roman D. Danyliw wrote: >=20 > > Hello! > > > > I omitted an important detail in my earlier write-up. The Service clas= s also > got a DomainData class in 5070bis (at least in the schema but not in the = text). > Hence, there are actually three places to put the domain name. Hence, th= e > following XML-snippet would be legal: > > > > ... > > > > www.example.com > > > > www.example.com > > 2013-01-02T05:54:02- > 05:00 > > > >
10.1.1.1.
> > 2013-01-02T05:54:02-05:00 > > > > ... > > > > www.example.com > > 2013-01-02T05:54:02- > 05:00 > > > > > > > > > > To expand upon the previously suggested options: > > > > (1) Remove Node/NodeName and Service/DomainData/Name in favor of > > Node/DomainData/Name > > > > (2) Remove Node/DomainData/Name and Service/DomainData/Name in > favor > > of Node/NodeName > > > > (3) Remove Node/DomainData/Name and Node/NodeName in favor of > > Service/DomainData/Name > > > >> Option #1 break compatibility with RFC 5070. Also, NodeName can > >> represent any kind of host name. As defined DomainData/Name only > >> represents FQDN DNS names. > >> > >> Option #2 redefines DomainData from RFC 5901 so we can't strictly > >> cite the element. > > > > Option #3 has the same disadvantages as #1 and would also requires > further changes Service. Currently, the Service class minimally expects = port > information. > > > > Roman > > > >> -----Original Message----- > >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. > >> Danyliw > >> Sent: Wednesday, January 15, 2014 9:57 AM > >> To: mile@ietf.org > >> Subject: [mile] Representing a domain name (or Issue #4) > >> > >> Hello! > >> > >> Tracked in Issue #4, > >> http://trac.tools.ietf.org/wg/mile/trac/ticket/4, is the need to make > >> a modeling decision on how to represent domain name. To summarize, > >> we currently have two duplicate ways to represent a domain name for > >> given Node. RFC5070 defined Node/NodeName. DomainData from > >> RFC5901 was added to the Node class in RFC5070bis. This change > >> allows Node/DomainData/Name to also describe a domain name. > >> > >> Both of these valid representations are shown in this XML snippet: > >> > >> > >> > >> www.example.com > >> > >> www.example.com > >> 2013-01-02T05:54:02- > >> 05:00 > >> > >>
10.1.1.1.
> >> 2013-01-02T05:54:02-05:00 > >> > >> > >> > >> This will likely create implementation confusion. > >> > >> As I see it, we have at least the following options: > >> > >> (1) Remove NodeName and DateTime from Node in favor of DomainData > >> > >> (2) Remove Name and DateDomainWasChecked from DomainData in favor > of > >> NodeName and DateTime > >> > >> Option #1 break compatibility with RFC 5070. Also, NodeName can > >> represent any kind of host name. As defined DomainData/Name only > >> represents FQDN DNS names. > >> > >> Option #2 redefines DomainData from RFC 5901 so we can't strictly > >> cite the element. > >> > >> Roman > >> _______________________________________________ > >> mile mailing 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 athiasjerome@gmail.com Fri Jan 24 01:17:45 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F4F1A021A for ; Fri, 24 Jan 2014 01:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S6sLXbMiNzd for ; Fri, 24 Jan 2014 01:17:42 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA261A01DD for ; Fri, 24 Jan 2014 01:17:42 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so3029549pab.7 for ; Fri, 24 Jan 2014 01:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+9VHLmTXVHYKZpe5UcADTbcLWK6YVHgGTGVVkciou8M=; b=nC0amPA/oWkSGaG2SlTg+6ka3OMA3Hy6XWAekTuV97DfPAKBQxPP0X58NTuG2mlmOr z0Ijwuldb/lf+G3FnHbfe2rFt0I7MzthTBEk+vYv9dxyllU50dJt83sjm4prUpZirW89 YrDUewsKu9N8eFz62UkrqZXUX+nG1aLRVpSJHhhphC++EO1fI0ctZkMxTjn9VarNOJbg MUEh5XMqBOq3E63p7EvJdLCOrGzkKB3mNdUFgRXs7VHUO0qufODL3kaKJ7xIx2IvcLrM ye6WvbUogcp3D7wI6oO0sMJ3zG61w+4h+cGG90/+l0GWkkTbRIYxN5rEOs5TuHkq5fPB U1ZQ== MIME-Version: 1.0 X-Received: by 10.68.164.4 with SMTP id ym4mr13431510pbb.53.1390555061017; Fri, 24 Jan 2014 01:17:41 -0800 (PST) Received: by 10.68.195.104 with HTTP; Fri, 24 Jan 2014 01:17:40 -0800 (PST) In-Reply-To: <52E1CBB5.6000906@ieee.org> References: <20140122155745.18162.21877.idtracker@ietfa.amsl.com> <52E1CBB5.6000906@ieee.org> Date: Fri, 24 Jan 2014 12:17:40 +0300 Message-ID: From: Jerome Athias To: murillo@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "mile@ietf.org" Subject: Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 09:17:45 -0000 Hi, from what I know (which is limited), and as you mention, this ICS area is often also called Critical Infrastructures (CIs), or SCADA for a little bit of background, we could explore the Cybersecurity Framework Example references http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx http://www.ictqatar.qa/en/documents/download/National%20Industrial%20Control%20Systems%20Security%20Standard-English.pdf ANSI/ISA-99.02.01-2009 I don't have enough knowledge about the status and adoption of the different efforts in term of XML representation/format/standards http://xml.coverpages.org/emergencyManagement.html and resilience It would maybe be possible to obtain information from there http://ics-cert.us-cert.gov http://ics-isac.org/ My first feedback is that it looks like an interesting extension. I would suggest to focus on the reuse of existing Taxonomies, or references to them. As such, for [Industry], maybe http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012 ISO 3166 (Country Codes) [TargetSystems], I (personally) don't like the word "system" and prefer "asset" [CompromisedPhysicalInfrastrucute] (with a typo ;p) seems to be a category of "Infrastructure" (or group of assets) [EntryPoint] could be ok since it could be a little bit different from "endpoint" [PerpetratingParty] seems to reference "Threat Actor" or "Threat Agent" or "Attacker" [RecurrencePreventionMeasures] is this Security Controls? (and Mitigations/Remediations) Reference: https://web.nvd.nist.gov/view/800-53/control?controlName=AC-3&type=1 Describing an [Exploit] is not so easy (depending on the level of details wanted/needed) Figure 1 (or "Diagram 1") is interesting, (of course it is different from, i.e. CAESARS), it MAYBE could be more layered http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/ContentDisplay.cfm&ContentID=94401 (To follow: ENISA CDXI) Some typos Next step: more XML focused ;) My 2 bitcents 2014/1/24 Martin Murillo : > Dear all, > > Please find below a link to a proposed draft for extending IODEF for the > reporting of cyber-physical system incidents. These systems are often > referred as Operational Technology Systems, Industrial Control Systems, > Automatic Control Systems, or simply Control Systems. > > Cyber-Physical systems have been around for decades. However, they are now > at a higher risk to be the target of attacks by individual highly-skilled > attackers, organized groups, nation-states, or simply suffer repercussions > of mainstream IT cyber-attacks. While over 90% of critical control system > infrastructure is currently owned by private enterprises, these can have > direct repercussions on national security of world nations. Indeed, various > of these systems are key parts of nuclear reactor facilities, transportation > systems, electric power distribution, oil and natural gas distribution, > health care, water and waste-water treatment, dam infrastructure, missile > and defense systems, and others. The disruption of these control systems > could have a significant impact on public health, safety, and lead to large > economic losses. > > Among the issues that catalyze this higher risk are: > > i) these systems are gradually becoming more interconnected, ii) legacy > systems do not have proper cybersecurity protection, iii) the existence of > highly-skilled individuals and motivations, iv) some these systems are > generally considered critical, v) these are a natural extension of IT > cyber-attacks, vi) the emergence of the Internet of Things (IOT), and vi) > these attacks can be carried out remotely and quite inexpensively. > > While there might exist national approaches to deal with incidents, there's > the need of a global international approach that will engulf governments, > private organizations and other stakeholders. IETF, as a leading global > Internet standards organization, seeks to satisfy this need through open > standards that seek to encompass issues that are critical for the global > community. > > Feedback at two levels are welcome: > > 1. On the existence and inclusion either by utilizing any already existing > industry formats (XML- encoded) and/or by utilizing atomic data > 2. Contributions on making the extension (and background information) more > comprehensive, accurate and principally useful for the community > > Look forward to feedback and other input! > > Martin Murillo > > A new version of I-D, draft-murillo-mile-cps-00.txt > has been successfully submitted by Martin Murillo and posted to the > IETF repository. > > Name: draft-murillo-mile-cps > Revision: 00 > Title: IODEF extension for Reporting Cyber-Physical System > Incidents > Document date: 2014-01-21 > Group: Individual Submission > Pages: 24 > URL: > http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt > Status: https://datatracker.ietf.org/doc/draft-murillo-mile-cps/ > Htmlized: http://tools.ietf.org/html/draft-murillo-mile-cps-00 > > > Abstract: > This draft document will extend the Incident Object Description > Exchange Format (IODEF) defined in [RFC5070] to support the reporting > of incidents dealing with attacks to physical infrastructure through > the utilization of IT means as a vehicle or as a tool. These systems > might also be referred as Cyber-Physical Systems (CPS), Operational > Technology Systems, Industrial Control Systems, Automatic Control > Systems, or simply Control Systems. These names are used > interchangeably in this document. In this context, an incident is > generally the result of a cybersecurity issue whose main goal is to > affect the operation of a CPS. It is considered that any > unauthorized alteration of the operation is always malign. This > extension will provide the capability of embedding structured > information, such as identifier- and XML-based information. In its > current state, this document provides important considerations for > further work in implementing Cyber-Physical System incident reports, > either by utilizing any already existing industry formats (XML- > encoded) and/or by utilizing atomic data. > > In addition, this document should provide appropriate material for > helping making due considerations in making an appropriate decision > on how a CPS reporting is done: 1) through a data format extension to > the Incident Object Description Exchange Format [RFC5070], 2) forming > part of an already existing IODEF-extension for structured > cybersecurity information (currently draft > draft-ietf-mile-sci-11.txt), or others. While the format and > contents of the present document fit more the earlier option, these > can also be incorporated to the later. > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From eburger@standardstrack.com Fri Jan 24 03:36:36 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADF71A02C1 for ; Fri, 24 Jan 2014 03:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqNIS_yKR5Wz for ; Fri, 24 Jan 2014 03:36:32 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 81EDF1A02B2 for ; Fri, 24 Jan 2014 03:36:32 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:56965 helo=[192.168.15.103]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1W6f3d-0001fE-HQ; Fri, 24 Jan 2014 03:36:30 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_B420985A-9B22-48E4-9809-60D215F86FBD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: <3BB285B5-F453-442D-8E13-60C6699BDD36@emc.com> Date: Fri, 24 Jan 2014 06:36:19 -0500 Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC54C149B2@marathon> <3BB285B5-F453-442D-8E13-60C6699BDD36@emc.com> To: Moriarty Kathleen X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: "mile@ietf.org" Subject: Re: [mile] An alternative way to represent a URL X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 11:36:36 -0000 --Apple-Mail=_B420985A-9B22-48E4-9809-60D215F86FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry I was not clear. By =93remove the reference=94 I did not mean to = remove URL=92s as an indicator. I meant to answer Roman=92s question = about keeping the reference to =93another way=94 of representing URL=92s = in IODEF. So, keep URL=92s, but remove the *comments* about other ways of = specifying them. On Jan 23, 2014, at 12:48 PM, Moriarty, Kathleen = wrote: > Hi Eric, >=20 > We need to include URLs that are references in addition to the newly = added ability to include a URL that is an indicator. The URL as a = reference could include a description of malware or a type of attack, = etc. my quick mention of URL as a reference was not clear on that = point. =20 >=20 > Thanks, > Kathleen=20 >=20 > Sent from my iPhone >=20 >> On Jan 23, 2014, at 11:49 AM, "Eric Burger" = wrote: >>=20 >> One and only one way to indicate a Thing sounds good to me. I would = remove the reference, as it does not change 5070 at all and it also = removes the temptation to implement in another, not-quite-compatible = format. >>=20 >>> On Jan 16, 2014, at 3:02 PM, Moriarty, Kathleen = wrote: >>>=20 >>> Hi Roman, >>>=20 >>> I think it was only left in to show that we could do this another = way if people were interested. If the WG is happy with the approach in = place now that achieves the same objective, this can be removed. The = discussions that led to this may go back to Rosella's presentation and = that URLs could only be included as a reference and not an indicator in = IODEF v1. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>> -----Original Message----- >>> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw >>> Sent: Thursday, January 16, 2014 1:57 PM >>> To: mile@ietf.org >>> Subject: [mile] An alternative way to represent a URL >>>=20 >>> Hello, >>>=20 >>> The schema definition of the Node class in -03 of 5070bis has the = following comment in it: >>>=20 >>> [begin schema snippet] >>> = [end schema snippet] >>>=20 >>> This proposal would provide an alternative to the current approach = of representing a URI for a Node using Address@category=3D"site-uri" = (e.g.,
http://www.example.com/sites/foo
). >>>=20 >>> I don't know the origin or rational for this comment. Could anyone = shed light on why we'd want to change the current representation? >>>=20 >>> Roman >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>>=20 >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>=20 >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_B420985A-9B22-48E4-9809-60D215F86FBD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS4lAzAAoJEDY/T2tCIPW3bZUP+gPvas2vRbesfdGs7l7em+t4 +d/De4OqqcJ1oV56PyNzC+PMX+lZ6svhmjeyq0OJmSEGb7uTLgAPbYMgEuw+O/CB h70yMVZaRwSU8f0C5s/Wyo7M8XpLUJThuIECXrQPA1dwQqUX7K85sbkUeO+q6ULY AsDcV/bDIpZJhpO3+UPheUhul3xgJeBKRWsguGOxJHZfW7sOW8sQ5gKrHrwO5qBz mhafgNNknC0RAAlcE2KRjbPwL4z+8SjPUEjB2QPMG142t9ysQ6ObTE2kCQlmAddq UuS8Q/Ekebqz/4pWfiPqWRkoNdJ7TewCIZb3BH2kHIeR337LNjUD+3WRK1XDlttb Rbp0l9lAUe9M+erxg8YPCzjdtDjq9UInN5g9zwCDUQqZOn9IrXkg9t0SzfoKS1p+ c0Ph7HYjKFRr1dLAJg+P4NBznYP2JuGGzWx8q6Yks1GdtUqskykwRzdNOC87N6i4 OZ5Fi8gxTSOx4zmwr5imDHskGVOKdTV0qrC+aXoDH6GgR0DpSwR7ipwbrCaluVBU zVGzHpM6FsZGgmtCZ2Ha842DYNCRnJGYGebBBKLTCTiiz/a382U9eCzLzh9nSUXW zbKNfYefPt6sW9/y1zvVPwFPN9Q6sisvqOQVQ2sDIw/bFYTjrVhUAAdgNF0j+YWJ /4ImMzyiglK6SO541xQ0 =QwPi -----END PGP SIGNATURE----- --Apple-Mail=_B420985A-9B22-48E4-9809-60D215F86FBD-- From rdd@cert.org Fri Jan 24 10:03:15 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3041A00AF for ; Fri, 24 Jan 2014 10:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r44sQ9XjvDS for ; Fri, 24 Jan 2014 10:03:11 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFF161A00E1 for ; Fri, 24 Jan 2014 10:03:10 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0OI2xYi031328; Fri, 24 Jan 2014 13:02:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390586579; bh=8ZyEHqtZOyDnARNd/ych7DiaEMI7sd+FzGgvGuzVB/Y=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To:Cc; b=MwLN/w4q32bsErr1kNclP0W34DPQVZVKy5idEkusAMmgJUt+qxJpYkQFkjLCPGM// PDaXLBScrSMQa+9MJAtHH9vN5mbgIv6nN9mIuIaSowuL13oegFnQOOtiVEev0YkhN4 fAcj+fhFtgmH5Zgae1gTSZT2ym5hAHiudBbYJGi8= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0OI3288018641; Fri, 24 Jan 2014 13:03:02 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Fri, 24 Jan 2014 13:02:59 -0500 From: "Roman D. Danyliw" To: "Panos Kampanakis (pkampana)" , "'Moriarty, Kathleen'" , "mile@ietf.org" Thread-Topic: [mile] Documenting DomainData Thread-Index: AQHPFeZKcVHy8XjkSUe8d5nwrbpqVpqOITGAgAAOhgCABB0RoIAAFI3ggAHKzCA= Date: Fri, 24 Jan 2014 18:02:58 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1FF19@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> <359EC4B99E040048A7131E0F4E113AFC54C18CF6@marathon> <359EC4B99E040048A7131E0F4E113AFC54C1D3AA@marathon> <1C9F17D1873AFA47A969C4DD98F98A750FAB17FA@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A750FAB17FA@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C1FF19marathon_" MIME-Version: 1.0 Subject: Re: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:03:15 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C1FF19marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! I concur that RelatedDNS contains related DNS records for the domain listed= in DomainData/Name. However, I don't think we can be vague in describing = the format of RelatedDNS. The example shared by Kathleen's had the following example of a MX record. evildave.com MX prefernce =3D 10, mail = exchanger =3D mail1.evildave.com I can infer the format. However, without the draft providing guidance, the= following could have also have been acceptable (replacing evildave.com for= example.com): mail1.org1.example.com org1.example.com 4000 IN MX 10 mail1.org1.exa= mple.com org1.example.com mail1.org1.example.com @org1.example.com:10.1.2.3:mail1.org1.example= .com:0:86400:329832:0 I feel that we need to provide implementers unambiguous guidance if we expe= ct them to parse the field. Roman From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Thursday, January 23, 2014 9:28 AM To: Roman D. Danyliw; 'Moriarty, Kathleen'; mile@ietf.org Subject: RE: [mile] Documenting DomainData I think text that says "The RelatedDNS record contain DNS records (i.e. MX,= A) that are related to the domain described in its parent DomainData class= . For example, in DomainData class for domain example.com, the RelatedDNS r= ecord could be carrying the MX record for example.com." would suffice. Panos From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 23, 2014 8:20 AM To: 'Moriarty, Kathleen'; mile@ietf.org Cc: Panos Kampanakis (pkampana) Subject: RE: [mile] Documenting DomainData Hi Kathleen! The example was very helpful. Thank you. For discussion purposes on the list, here is a relevant excerpt from the pr= eviously attached file: evildave.com 2013-01-04T09:10:24+00:00 evildave.com MX prefernce =3D 10, mail = exchanger =3D mail1.evildave.com mail1.evildave.com internet address =3D = 176.157.32.17 zuesevil.com. IN TXT \"v=3Dspf1 a mx -= all\" Reading this particular example, I understand what information is being pas= sed along in the DNS record. Where I need help is how do we formally descr= ibe this format for the draft. Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 22, 2014 6:50 PM To: Roman D. Danyliw; mile@ietf.org Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com) Subject: RE: [mile] Documenting DomainData Hi Roman, I was able to dig up an example from the group that was proposing the addit= ion of RelatedDNS to the DomainData class that was added from RFC5901. Pan= os may have other examples planned for the IODEF Guidance document. I think as long as the data of other records can be included, the intent wi= ll be met for the requestors. See the attached example and I am sure a pro= posal that alters it, but provides the ability to include that information = would be fine. Anyone else? Thanks, Kathleen From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Monday, January 20, 2014 5:04 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hello! Understood on #1 and #3. I still need a little more clarification on your = answer to question #2, "RelatedDNS lets you add any record type to expand o= ut what is possible from the Domain data class. You can also list what typ= e of record you are including." To restate, RelatedDNS represents DNS reco= rds for a domain specified in DomainData/Name? If so, what exactly goes in= to the element content of RelatedDNS which is defined as xs:string? For ex= ample, if I had an AXFR record () how would= this be encoded? Since Node/DomainData/DateDomainWasChecked represents when Node/DomainData/= Name was resolved (where the IP address is stored in Node/Address), is ther= e a similar construct for these other record types in RelatedDNS? Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Monday, January 20, 2014 8:48 AM To: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hi Roman, #1 I thought the answer was yes, but it would be good to hear if anyone thi= nks it is too much detail now. #2 RelatedDNS lets you add any record type to expand out what is possible f= rom the Domain data class. You can also list what type of record you are i= ncluding. #3 I don't think there is a concern in adjusting the names for consistency. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, January 17, 2014 9:32 PM To: mile@ietf.org Subject: [mile] Documenting DomainData Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_359EC4B99E040048A7131E0F4E113AFC54C1FF19marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

I concur that RelatedD= NS contains related DNS records for the domain listed in DomainData/Name.&n= bsp; However, I don’t think we can be vague in describing the format = of RelatedDNS.

 

The example shared by = Kathleen’s had the following example of a MX record.

 

<iodef:RelatedDNS R= ecordType=3D"MX">evildave.com MX prefernce =3D 10, mail exchan= ger =3D mail1.evildave.com</iodef:RelatedDNS>

 

I can infer the format= .  However, without the draft providing guidance, the following could = have also have been acceptable (replacing evildave.com for example.com):

 

<RelatedDNS RecordT= ype=3D"MX">mail1.org1.example.com</RelatedDNS>

<RelatedDNS RecordT= ype=3D"MX">org1.example.com 4000 IN MX 10 mail1.org1.example.c= om</RelatedDNS>

<RelatedDNS RecordT= ype=3D"MX">org1.example.com mail1.org1.example.com</Related= DNS>

<RelatedDNS RecordT= ype=3D"MX">@org1.example.com:10.1.2.3:mail1.org1.example.com:0= :86400:329832:0</RelatedDNS>

 

I feel that we need to= provide implementers unambiguous guidance if we expect them to parse the f= ield.

 

Roman

 

From: Panos Ka= mpanakis (pkampana) [mailto:pkampana@cisco.com]
Sent: Thursday, January 23, 2014 9:28 AM
To: Roman D. Danyliw; 'Moriarty, Kathleen'; mile@ietf.org
Subject: RE: [mile] Documenting DomainData

 

I think text that says= “The RelatedDNS record contain DNS records (i.e. MX, A) that are rel= ated to the domain described in its parent DomainData class. For example, i= n DomainData class for domain example.com, the RelatedDNS record could be carrying the MX record for example.com.R= 21; would suffice.

Panos

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Thursday, January 23, 2014 8:20 AM
To: 'Moriarty, Kathleen'; mile@ietf= .org
Cc: Panos Kampanakis (pkampana)
Subject: RE: [mile] Documenting DomainData

 

Hi Kathleen!

 

The example was very h= elpful.  Thank you.

 

For discussion purpose= s on the list, here is a relevant excerpt from the previously attached file= :

<iodef:DomainData&g= t;

<iodef:Name>evil= dave.com</iodef:Name>

<iodef:DateDomainWa= sChecked>2013-01-04T09:10:24+00:00</iodef:DateDomainWasChecked>= ;

<iodef:RelatedDNS R= ecordType=3D"MX">evildave.com MX prefernce =3D 10, mail exchan= ger =3D mail1.evildave.com</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"A">mail1.evildave.com internet address =3D 176.15= 7.32.17</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"SPF">zuesevil.com. IN TXT \"v=3Dspf1 a mx &#= 8211;all\"</iodef:RelatedDNS>

</iodef:DomainData&= gt;

 

Reading this particula= r example, I understand what information is being passed along in the DNS r= ecord.  Where I need help is how do we formally describe this format f= or the draft. 

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.mo= riarty@emc.com]
Sent: Wednesday, January 22, 2014 6:50 PM
To: Roman D. Danyliw; mile@ietf.org=
Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com)
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

I was able to dig up a= n example from the group that was proposing the addition of RelatedDNS to t= he DomainData class that was added from RFC5901.  Panos may have other= examples planned for the IODEF Guidance document.

 

I think as long as the= data of other records can be included, the intent will be met for the requ= estors.  See the attached example and I am sure a proposal that alters= it, but provides the ability to include that information would be fine.

 

Anyone else?

 

Thanks,

Kathleen

 

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Monday, January 20, 2014 5:04 PM
To: Moriarty, Kathleen; mile@ietf.o= rg
Subject: RE: [mile] Documenting DomainData

 

Hello!

 

Understood on #1 and #= 3.  I still need a little more clarification on your answer to questio= n #2, “RelatedDNS lets you add any record type to expand out what is = possible from the Domain data class.  You can also list what type of record you are including.”  To restate, Relat= edDNS represents DNS records for a domain specified in DomainData/Name?&nbs= p; If so, what exactly goes into the element content of RelatedDNS which is= defined as xs:string?  For example, if I had an AXFR record (<RelatedDNS RecordType=3D”AXRF”>) how would= this be encoded?

 

Since Node/DomainData/= DateDomainWasChecked represents when Node/DomainData/Name was resolved (whe= re the IP address is stored in Node/Address), is there a similar construct = for these other record types in RelatedDNS?

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.mo= riarty@emc.com]
Sent: Monday, January 20, 2014 8:48 AM
To: Roman D. Danyliw; mile@ietf.org=
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

#1 I thought the answe= r was yes, but it would be good to hear if anyone thinks it is too much det= ail now.

 

#2 RelatedDNS lets you= add any record type to expand out what is possible from the Domain data cl= ass.  You can also list what type of record you are including.

 

#3 I don’t think= there is a concern in adjusting the names for consistency.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, January 17, 2014 9:32 PM
To: mile@ietf.org
Subject: [mile] Documenting DomainData

 

Hello!

 

Since being copied from RFC5901 into 5070bis, Domain= Data has evolved.  Currently the two definition differ as follows:

 

** 5070bis added DomainData@{indicator-uid, indicato= r-set-id}

** 5070bis added DomainData/RelatedDNS

** 5070bis uses iodef:Contact for DomainData/DomainC= ontacts/Contact instead of phish:Contact which added classes and attributes= to Contact

 

A few questions:

 

(1) Since bits and pieces were added and modified in= the cut-and-paste from 5901, is there agreement that we don’t need t= o remove anything from DomainData?  Do we want to represent this level= of detail in the core IODEF data model?

 

(2) RelatedDNS was added to DomainData and is not pr= esent in RFC5901.  There is no descriptive text.  Could someone s= hed light on the purpose of this class.

 

(3) The attributes DomainData@{SystemStatus, DomainS= tatus} and RelatedDNS@RecordType don't follow the naming convention of lowe= r case names separated by a hyphen.  As in other cases where classes h= ave been moved, I would be inclined to rename the attributes.  Any concern in doing that?

 

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC54C1FF19marathon_-- From rdd@cert.org Fri Jan 24 10:04:08 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30E1A00AF for ; Fri, 24 Jan 2014 10:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKiTSELCSKi5 for ; Fri, 24 Jan 2014 10:04:02 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 427C81A00BB for ; Fri, 24 Jan 2014 10:04:02 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0OI40F3031374; Fri, 24 Jan 2014 13:04:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390586640; bh=QM7+xihDdCOQn9p8T/fUBcsZTfj4a8bVBeVJYuY0lo0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version:Sender:Reply-To:Cc; b=iHKiRZ4qj7fdIN/dL87WRyLRj/cgTW/V1aO1E1bqkchnw5DbLTNLJo5XspvAmaX4f ExicgGNMy2Cb2tGCmxicxubclSJheej9ZGuLJMIjLNKFG8rI/U7knPnEwVMwSIeZEL MKIv5ry39pr/uDGQjd3Wi6lgmnWfrdKuL8iAd4rY= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0OI43rT018739; Fri, 24 Jan 2014 13:04:03 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Fri, 24 Jan 2014 13:04:00 -0500 From: "Roman D. Danyliw" To: Eric Burger , "mile@ietf.org" Thread-Topic: [mile] Extending the IODEF-Document class Thread-Index: Ac8SIOEkde7M7J1KRYWcE0lEG1616wACLQsgAAXYzoAAJpMnYAADsCRgAAHTrZAAL/Qv8AE1E6uAACpMpBA= Date: Fri, 24 Jan 2014 18:03:59 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C1FF40@marathon> References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> <673f2a8968f6437c844f5a0e148c7d84@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <359EC4B99E040048A7131E0F4E113AFC54C14EAA@marathon> <9d7bcf3f29f942c5b7e410d14f1ae16d@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <6C121AB8-CA98-46F9-B8AE-307DBACF8869@standardstrack.com> In-Reply-To: <6C121AB8-CA98-46F9-B8AE-307DBACF8869@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC54C1FF40marathon_" MIME-Version: 1.0 Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:04:08 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC54C1FF40marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This change was made in the -04 draft. Roman From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Eric Burger Sent: Thursday, January 23, 2014 11:53 AM To: mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Looks like an oversight, unless there is a compelling reason to have a non-= extensible top-level class. On Jan 17, 2014, at 1:26 PM, Trevor Freeman > wrote: Exactly I was trying to figure out if this is a simple oversight or deliberate act. Does anyone object to filling the gap and adding the extension to the IODEF= -document class? Trevor From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 16, 2014 11:38 AM To: Trevor Freeman; Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@i= etf.org Subject: RE: Extending the IODEF-Document class Good afternoon! Sidestepping the signature discussion, I think that Trevor is pointing out = a gap in the data model. I concur that it would be valuable to have the ab= ility to add an extension into an IODEF-Document. It would allow unanticip= ated data elements to be added into the root node that are relevant to mult= iple Incident classes aggregated in the IODEF-Document class. Roman From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Thursday, January 16, 2014 2:28 PM To: Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Panos, For digital signatures, it is a classic issues between what you do with a s= ingle signature vs. multiple signatures. For a single signature, what you d= escribe works e.g. a document with a single incident - no problem. It's als= o not a problem with the actual signature itself, that too is fine. It's si= mply a question of optimizing the bag of certificates you need to validate = multiple signatures. If you start aggregating incident data, and have dif= ferent incidents from different sources with different signers, you need to= normalize the certificate data set across all the signers so you don't blo= at the document with redundant data. The schema I would define is trivial a= s it would reuse the elements defined in the XML signature standard, but sh= ould be stored in the schema at the level of the IODEF document as it per= tains to multiple incidents. This is the behavior that CMS uses i.e. certif= icates are not part of the SignerInfo but are part of the Signed Data struc= ture. This allows a single bag of certificates to be used across all Signer= Info structures. The work that Kathleen is referring to is the work I am doing with Jim Scha= ad on stronger policy enforcement on distributed data. We started work on e= mail and the work goes under the Plasma name in the IETF. We have developed= a mechanism to apply strong access control policy on email whereby we can = send out a message to multiple recipients and enforce attribute based acces= s control to the content. As part of that work we define something we call= a Plasma token which links an email message to a set of XACML rules which = defines the specifics of who can access the message. Its fairly simple to t= ake what we have in http://datatracker.ietf.org/doc/draft-schaad-plasma-cms= / and recast in in XML and embed a Plasma token in an IODEF document using = the additional data extension mechanism to deliver access control with teet= h. However you cannot homogenize the access control policy so it does not m= ake sense to apply access control at the document level but to individual i= ncidents or parts of incidents. Different incents could have different poli= cies. I can embed different policies into the single Plasma token, or I may= need to embed a separate token depending on the policies and who is truste= d. Again the tokens should be at the document level not the incident level = as each token can protect multiple indents. I cannot use the extension poin= t in the incident to store the token because I want to encrypt the entire i= ncent. In both scenarios, the IODEF extension mechanism works just fine to solve t= he problem, except that I cannot use it at the document level because it's = not in the IODEF-document class. Is there some reason for not wanting the document class extended? Trevor From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Thursday, January 16, 2014 9:25 AM To: Trevor Freeman; Moriarty, Kathleen; mile@ietf.org Subject: RE: Extending the IODEF-Document class Authentication of the incident data themselves seems reasonable to address. But to solve that, would it be simpler for someone to sign the XML doc or = parts of it and include all the certs using XML DSIG (enveloped or detached= ) ? Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 6:18 PM To: Moriarty, Kathleen; mile@ietf.org Subject: Re: [mile] Extending the IODEF-Document class Hi Kathleen, RID, to my mind offers a set of security serves targeting the transport and= authorization of the RID messages. The security of RID, handles the secur= ity associated with the processing of RID messages. For example, a RID mess= age could be a request for an action or a query for information. This messa= ges need security services because of the potential impact i.e. we don't wa= nt to repeat the mistake of SMTP where there is no authentication when emai= l is sent between MTAs. The timeframe of the security is around the request= and the response RID messages, i.e. send a RID request, get a RID response= , case closed. The RID security provides operational security for the funct= ioning of ecosystem. Information policies like information sharing or confidentiality agreements= relate to the actual content itself regardless of format and persists beyo= nd receiving the data hence apply to the content of the IODEF documents whe= rever they are. If I was a repository of incident data, I am receiving inci= dents which could be signed as proof of data origination from many sources.= If I receive a RID query message, I would authorize processing the request= based on the RID security then construct a new IODEF document containing a= ll the incidents covered by the request. The repository would sign the RID = response, but I want to retain the original signatures of the contributor o= f the incident data itself as it relates directly to the providence of the = data. If the incident data requires specific access control policies, thos= e too would need to be respected as part of the response and are orthogonal= to the confidentiality of the RID response as they can change incident by = incident. I see any IODEF security providing security services to support c= ompliance with the information policies be they regulatory policies, contra= ctual policies, information sharing agreements or whatever. Hope that helps. Trevor From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 15, 2014 11:41 AM To: Trevor Freeman; mile@ietf.org Subject: RE: Extending the IODEF-Document class Trevor, Could you elaborate on how this is different from or compliments the Digita= l signature and Encryption for IODEF in RID, RFC6545? I think that will be= helpful here. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman Sent: Wednesday, January 15, 2014 2:02 PM To: mile@ietf.org Subject: [mile] Extending the IODEF-Document class I am looking at implementing better end to end security with IODEF document= s. For example, stronger access control on the data than is possible via the r= estriction attribute, or stronger data origination authentication by singin= g incidents. In both cases there is security relevant metadata which may apply to multi= ple incidents in an IODEF document. For example with signed incidents, I wa= nt to include a set certificates to enable relying parties to be able to va= lidate the incident. I also want to optimize the set of certificates in the= document i.e. ensure I don't include the same certificate multiple places = in the document. The simplest way to achieve that is to have all the certif= icates in one place. The logical place to store the set of certificates wo= uld be in the IODEF document class. This is equivalent to CMS, where the se= t of signing certificates are in the SignedData object not the SignerInfo o= bject. However the IODEF document class lacks the AdditionalData extension = point preset in other IODEF classes. Is it possible to add the optional AdditionalData element to the v2 of the = IODEF document class so it is possible to extend that class the same way it= is possible to extend other classes? Trevor _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile --_000_359EC4B99E040048A7131E0F4E113AFC54C1FF40marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This change was made in t= he -04 draft.

 <= /p>

Roman

 <= /p>

From: mile [ma= ilto:mile-bounces@ietf.org] On Behalf Of Eric Burger
Sent: Thursday, January 23, 2014 11:53 AM
To: mile@ietf.org
Subject: Re: [mile] Extending the IODEF-Document class

 

Looks like an oversight, unless there is a compellin= g reason to have a non-extensible top-level class.

 

On Jan 17, 2014, at 1:26 PM, Trevor Freeman <trevorf@exchange.microsoft.co= m> wrote:



Exactly

 

I was trying to figure ou= t if this is a simple oversight or deliberate act.=

 

Does anyone object to fil= ling the gap and adding the extension to the IODEF-document class?

 

Trevor

 

From: Roman D. Danyliw [= mailto:rdd@cert.org] =
Sent: Thursday, Ja= nuary 16, 2014 11:38 AM
To: Trevor Freeman= ; Panos Kampanakis (pkampana); Moriarty, Kathleen; mile@ietf.org
Subject: RE: Exten= ding the IODEF-Document class

 

Good afternoon!

 

Sidestepping the signatur= e discussion, I think that Trevor is pointing out a gap in the data model.&= nbsp; I concur that it would be valuable to have the ability to add an extension into an IODEF-Document.  It would allow unanticip= ated data elements to be added into the root node that are relevant to mult= iple Incident classes aggregated in the IODEF-Document class.

 

Roman

 

From: mile [ma= ilto:mile-bounces@ietf.org] On Behalf Of Trevor Freeman
Sent: Thursday, Ja= nuary 16, 2014 2:28 PM
To: Panos Kampanak= is (pkampana); Moriarty, Kathleen;&nb= sp;mi= le@ietf.org
Subject: Re: [mile= ] Extending the IODEF-Document class<= /p>

 

Hi Panos,

 

For digital signatures, i= t is a classic issues between what you do with a single signature vs. multi= ple signatures. For a single signature, what you describe works e.g. a document with a single incident – no problem. It’= s also not a problem with the actual signature itself, that too is fine. It= ’s simply a question of optimizing the bag of certificates you need t= o validate multiple signatures.  If you start  aggregating incident data, and have different incidents from different sources with di= fferent signers, you need to normalize the certificate data set across all = the signers so you don’t bloat the document with redundant data. The = schema I would define is trivial as it would reuse the elements defined in the XML signature standard, but should= be  stored in the schema  at the level of the IODEF document as = it pertains to multiple incidents. This is the behavior that CMS uses i.e. = certificates are not part of the SignerInfo but are part of the Signed Data structure. This allows a single bag of cer= tificates to be used across all SignerInfo structures. 

 

The work that Kathleen is= referring to is the work I am doing with Jim Schaad on stronger policy enf= orcement on distributed data. We started work on email and the work goes under the Plasma name in the IETF. We have developed a mecha= nism to apply strong access control policy on email whereby we can send out= a message to multiple recipients and enforce attribute based access contro= l to the content.  As part of that work we define something we call a Plasma token which links an email messa= ge to a set of XACML rules which defines the specifics of who can access th= e message. Its fairly simple to take what we have in http://datatracker.ietf= .org/doc/draft-schaad-plasma-cms/ and recast in in XML and embed a Plasma token in an IODEF document using the a= dditional data extension mechanism to deliver access control with teeth. Ho= wever you cannot homogenize the access control policy so it does not make s= ense to apply access control at the document level but to individual incidents or parts of incidents. Diff= erent incents could have different policies. I can embed different policies= into the single Plasma token, or I may need to embed a separate token depe= nding on the policies and who is trusted. Again the tokens should be at the document level not the incident= level as each token can protect multiple indents. I cannot use the extensi= on point in the incident to store the token because I want to encrypt the e= ntire incent.

 

In both scenarios, the IO= DEF extension mechanism works just fine to solve the problem, except that I= cannot use it at the document level because it’s not in the IODEF-document class.

 

Is there some reason for = not wanting the document class extended?

 

Trevor

 

From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] 
Sent: Thursday, Ja= nuary 16, 2014 9:25 AM
To: Trevor Freeman= ; Moriarty, Kathleen; mile@ietf.org
Subject: RE: Exten= ding the IODEF-Document class

 

Authentication of the inc= ident data themselves seems reasonable to address.=

But to solve that,  = would it be simpler for someone to sign the XML doc or parts of it and incl= ude all the certs using XML DSIG (enveloped or detached)  ?

Panos

 

 

 

 

From: mile [mailto:mile-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Trevor Fre= eman
Sent: Wednesday, J= anuary 15, 2014 6:18 PM
To: Moriarty, Kath= leen; mile@ietf.org<= /span>
Subject: Re: [mile= ] Extending the IODEF-Document class<= /p>

 

Hi Kathleen,

 

RID, to my mind offers a = set of security serves targeting the transport and authorization of the RID= messages. The security of  RID, handles the security associated with the processing of RID messages. For example, a RID message could be a= request for an action or a query for information. This messages need secur= ity services because of the potential impact i.e. we don’t want to re= peat the mistake of SMTP where there is no authentication when email is sent between MTAs. The timeframe of the se= curity is around the request and the response RID messages, i.e. send a RID= request, get a RID response, case closed. The RID security provides operat= ional security for the functioning of ecosystem.

 

Information policies like= information sharing or confidentiality agreements relate to the actual con= tent itself regardless of format and persists beyond receiving the data hence apply to the content of the IODEF documents wherever they a= re. If I was a repository of incident data, I am receiving incidents which = could be signed as proof of data origination from many sources. If I receiv= e a RID query message, I would authorize processing the request based on the RID security then construct a new IODE= F document containing all the incidents covered by the request. The reposit= ory would sign the RID response, but I want to retain the original signatur= es of the contributor of the incident data itself as it relates directly to the providence of the data.  If= the incident data requires specific access control policies, those too wou= ld need to be respected as part of the response and are orthogonal to the c= onfidentiality of the RID response as they can change incident by incident. I see any IODEF security providing s= ecurity services to support compliance with the information policies be the= y regulatory policies, contractual policies,  information sharing agre= ements or whatever.

 

Hope that helps.

 

Trevor

 

From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] 
Sent: Wednesday, J= anuary 15, 2014 11:41 AM
To: Trevor Freeman= ; mile@ietf.org
Subject: RE: Exten= ding the IODEF-Document class

 

Trevor,

 

Could you elaborate on ho= w this is different from or compliments the Digital signature and Encryptio= n for IODEF in RID, RFC6545?  I think that will be helpful here.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Trevor Fre= eman
Sent: Wednesday, J= anuary 15, 2014 2:02 PM
To: mile@ietf.= org
Subject: [mile] Ex= tending the IODEF-Document class

 

I am looking at implementing better end= to end security with IODEF documents.

 

For example, stronger access control on= the data than is possible via the restriction attribute, or stronger data = origination authentication by singing incidents.

 

In both cases there is  security r= elevant metadata which may apply to multiple incidents in an IODEF document= . For example with signed incidents, I want to include a set certificates to enable relying parties to be able to validate the incident= . I also want to optimize the set of certificates in the document i.e. ensu= re I don’t include the same certificate multiple places in the docume= nt. The simplest way to achieve that is to have all the certificates in one place.  The logical place to stor= e the set of certificates would be in the IODEF document class. This is equ= ivalent to CMS, where the set of signing certificates are in the SignedData= object not the SignerInfo object. However the IODEF document class lacks the AdditionalData extension point preset i= n other IODEF classes.

 

Is it possible to add the optional Addi= tionalData element to the v2 of the IODEF document class so it is possible = to extend that class the same way it is possible to extend other classes?

 

Trevor

______________________________________= _________
mile mailing list
mile@ietf.or= g
https://www.ietf.org/mailman/listinfo/mile<= /span>

 

--_000_359EC4B99E040048A7131E0F4E113AFC54C1FF40marathon_-- From kathleen.moriarty@emc.com Fri Jan 24 10:24:20 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00501A00C4 for ; Fri, 24 Jan 2014 10:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89iV72nVScxU for ; Fri, 24 Jan 2014 10:24:14 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 052C31A00DF for ; Fri, 24 Jan 2014 10:24:13 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0OINrhx032683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 13:23:54 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0OINrhx032683 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390587835; bh=NscLZfajbmdMo+8GgbRcrDziHq0=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=n2brd78n//ppeB9OKR7U3QWX69/x2bIacqgUKiC6tu9tHLUjkKhxm6IIRA9iAmWId tAr7WpEAov3lKJsfzzPdFSCcp8CL4s61sl6rGzxVk/2PKbkSpmnHayor7kfB4mgekI ikK9twdW2C9wBqRu67BpJCE2CDbA0emAEFdpqqAU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0OINrhx032683 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 24 Jan 2014 13:23:35 -0500 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0OINXaD008920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 13:23:35 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub34.corp.emc.com ([::1]) with mapi; Fri, 24 Jan 2014 13:21:35 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" Date: Fri, 24 Jan 2014 13:21:35 -0500 Thread-Topic: [mile] Extending the IODEF-Document class Thread-Index: Ac8ZMR1CPL+MjiQRS5ashgu+qBnn/g== Message-ID: References: <5ab052bec168432abe90e4de00da53fb@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1C9F17D1873AFA47A969C4DD98F98A750FAAB38E@xmb-rcd-x10.cisco.com> <673f2a8968f6437c844f5a0e148c7d84@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <359EC4B99E040048A7131E0F4E113AFC54C14EAA@marathon> <9d7bcf3f29f942c5b7e410d14f1ae16d@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <6C121AB8-CA98-46F9-B8AE-307DBACF8869@standardstrack.com> <359EC4B99E040048A7131E0F4E113AFC54C1FF40@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1FF40@marathon> 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_DD14082302C54FE989E2EC4CBAD8FED8emccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Cc: "mile@ietf.org" , Eric Burger Subject: Re: [mile] Extending the IODEF-Document class X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:24:20 -0000 --_000_DD14082302C54FE989E2EC4CBAD8FED8emccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gdW5hbWJpZ3VvdXMgZ3VpZGFuY2UNCg0KVGhhbmtzLA0KS2F0aGxlZW4NCg0KU2VudCBm cm9tIG15IGlQaG9uZQ0KDQpPbiBKYW4gMjQsIDIwMTQsIGF0IDE6MDQgUE0sICJSb21hbiBELiBE YW55bGl3IiA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+PiB3cm90ZToNCg0KVGhp cyBjaGFuZ2Ugd2FzIG1hZGUgaW4gdGhlIC0wNCBkcmFmdC4NCg0KUm9tYW4NCg0KRnJvbTogbWls ZSBbbWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgQnVyZ2Vy DQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMywgMjAxNCAxMTo1MyBBTQ0KVG86IG1pbGVAaWV0 Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21pbGVdIEV4dGVuZGlu ZyB0aGUgSU9ERUYtRG9jdW1lbnQgY2xhc3MNCg0KTG9va3MgbGlrZSBhbiBvdmVyc2lnaHQsIHVu bGVzcyB0aGVyZSBpcyBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGhhdmUgYSBub24tZXh0ZW5zaWJs ZSB0b3AtbGV2ZWwgY2xhc3MuDQoNCk9uIEphbiAxNywgMjAxNCwgYXQgMToyNiBQTSwgVHJldm9y IEZyZWVtYW4gPHRyZXZvcmZAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbTxtYWlsdG86dHJldm9yZkBl eGNoYW5nZS5taWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCg0KRXhhY3RseQ0KDQpJIHdhcyB0cnlp bmcgdG8gZmlndXJlIG91dCBpZiB0aGlzIGlzIGEgc2ltcGxlIG92ZXJzaWdodCBvciBkZWxpYmVy YXRlIGFjdC4NCg0KRG9lcyBhbnlvbmUgb2JqZWN0IHRvIGZpbGxpbmcgdGhlIGdhcCBhbmQgYWRk aW5nIHRoZSBleHRlbnNpb24gdG8gdGhlIElPREVGLWRvY3VtZW50IGNsYXNzPw0KDQpUcmV2b3IN Cg0KRnJvbTogUm9tYW4gRC4gRGFueWxpdyBbbWFpbHRvOnJkZEBjZXJ0Lm9yZ10NClNlbnQ6IFRo dXJzZGF5LCBKYW51YXJ5IDE2LCAyMDE0IDExOjM4IEFNDQpUbzogVHJldm9yIEZyZWVtYW47IFBh bm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKTsgTW9yaWFydHksIEthdGhsZWVuOyBtaWxlQGlldGYu b3JnPG1haWx0bzptaWxlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEV4dGVuZGluZyB0aGUgSU9E RUYtRG9jdW1lbnQgY2xhc3MNCg0KR29vZCBhZnRlcm5vb24hDQoNClNpZGVzdGVwcGluZyB0aGUg c2lnbmF0dXJlIGRpc2N1c3Npb24sIEkgdGhpbmsgdGhhdCBUcmV2b3IgaXMgcG9pbnRpbmcgb3V0 IGEgZ2FwIGluIHRoZSBkYXRhIG1vZGVsLiAgSSBjb25jdXIgdGhhdCBpdCB3b3VsZCBiZSB2YWx1 YWJsZSB0byBoYXZlIHRoZSBhYmlsaXR5IHRvIGFkZCBhbiBleHRlbnNpb24gaW50byBhbiBJT0RF Ri1Eb2N1bWVudC4gIEl0IHdvdWxkIGFsbG93IHVuYW50aWNpcGF0ZWQgZGF0YSBlbGVtZW50cyB0 byBiZSBhZGRlZCBpbnRvIHRoZSByb290IG5vZGUgdGhhdCBhcmUgcmVsZXZhbnQgdG8gbXVsdGlw bGUgSW5jaWRlbnQgY2xhc3NlcyBhZ2dyZWdhdGVkIGluIHRoZSBJT0RFRi1Eb2N1bWVudCBjbGFz cy4NCg0KUm9tYW4NCg0KRnJvbTogbWlsZSBbbWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFRyZXZvciBGcmVlbWFuDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNiwg MjAxNCAyOjI4IFBNDQpUbzogUGFub3MgS2FtcGFuYWtpcyAocGthbXBhbmEpOyBNb3JpYXJ0eSwg S2F0aGxlZW47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW21pbGVdIEV4dGVuZGluZyB0aGUgSU9ERUYtRG9jdW1lbnQgY2xhc3MNCg0KSGkgUGFub3Ms DQoNCkZvciBkaWdpdGFsIHNpZ25hdHVyZXMsIGl0IGlzIGEgY2xhc3NpYyBpc3N1ZXMgYmV0d2Vl biB3aGF0IHlvdSBkbyB3aXRoIGEgc2luZ2xlIHNpZ25hdHVyZSB2cy4gbXVsdGlwbGUgc2lnbmF0 dXJlcy4gRm9yIGEgc2luZ2xlIHNpZ25hdHVyZSwgd2hhdCB5b3UgZGVzY3JpYmUgd29ya3MgZS5n LiBhIGRvY3VtZW50IHdpdGggYSBzaW5nbGUgaW5jaWRlbnQg4oCTIG5vIHByb2JsZW0uIEl04oCZ cyBhbHNvIG5vdCBhIHByb2JsZW0gd2l0aCB0aGUgYWN0dWFsIHNpZ25hdHVyZSBpdHNlbGYsIHRo YXQgdG9vIGlzIGZpbmUuIEl04oCZcyBzaW1wbHkgYSBxdWVzdGlvbiBvZiBvcHRpbWl6aW5nIHRo ZSBiYWcgb2YgY2VydGlmaWNhdGVzIHlvdSBuZWVkIHRvIHZhbGlkYXRlIG11bHRpcGxlIHNpZ25h dHVyZXMuICBJZiB5b3Ugc3RhcnQgIGFnZ3JlZ2F0aW5nIGluY2lkZW50IGRhdGEsIGFuZCBoYXZl IGRpZmZlcmVudCBpbmNpZGVudHMgZnJvbSBkaWZmZXJlbnQgc291cmNlcyB3aXRoIGRpZmZlcmVu dCBzaWduZXJzLCB5b3UgbmVlZCB0byBub3JtYWxpemUgdGhlIGNlcnRpZmljYXRlIGRhdGEgc2V0 IGFjcm9zcyBhbGwgdGhlIHNpZ25lcnMgc28geW91IGRvbuKAmXQgYmxvYXQgdGhlIGRvY3VtZW50 IHdpdGggcmVkdW5kYW50IGRhdGEuIFRoZSBzY2hlbWEgSSB3b3VsZCBkZWZpbmUgaXMgdHJpdmlh bCBhcyBpdCB3b3VsZCByZXVzZSB0aGUgZWxlbWVudHMgZGVmaW5lZCBpbiB0aGUgWE1MIHNpZ25h dHVyZSBzdGFuZGFyZCwgYnV0IHNob3VsZCBiZSAgc3RvcmVkIGluIHRoZSBzY2hlbWEgIGF0IHRo ZSBsZXZlbCBvZiB0aGUgSU9ERUYgZG9jdW1lbnQgYXMgaXQgcGVydGFpbnMgdG8gbXVsdGlwbGUg aW5jaWRlbnRzLiBUaGlzIGlzIHRoZSBiZWhhdmlvciB0aGF0IENNUyB1c2VzIGkuZS4gY2VydGlm aWNhdGVzIGFyZSBub3QgcGFydCBvZiB0aGUgU2lnbmVySW5mbyBidXQgYXJlIHBhcnQgb2YgdGhl IFNpZ25lZCBEYXRhIHN0cnVjdHVyZS4gVGhpcyBhbGxvd3MgYSBzaW5nbGUgYmFnIG9mIGNlcnRp ZmljYXRlcyB0byBiZSB1c2VkIGFjcm9zcyBhbGwgU2lnbmVySW5mbyBzdHJ1Y3R1cmVzLg0KDQpU aGUgd29yayB0aGF0IEthdGhsZWVuIGlzIHJlZmVycmluZyB0byBpcyB0aGUgd29yayBJIGFtIGRv aW5nIHdpdGggSmltIFNjaGFhZCBvbiBzdHJvbmdlciBwb2xpY3kgZW5mb3JjZW1lbnQgb24gZGlz dHJpYnV0ZWQgZGF0YS4gV2Ugc3RhcnRlZCB3b3JrIG9uIGVtYWlsIGFuZCB0aGUgd29yayBnb2Vz IHVuZGVyIHRoZSBQbGFzbWEgbmFtZSBpbiB0aGUgSUVURi4gV2UgaGF2ZSBkZXZlbG9wZWQgYSBt ZWNoYW5pc20gdG8gYXBwbHkgc3Ryb25nIGFjY2VzcyBjb250cm9sIHBvbGljeSBvbiBlbWFpbCB3 aGVyZWJ5IHdlIGNhbiBzZW5kIG91dCBhIG1lc3NhZ2UgdG8gbXVsdGlwbGUgcmVjaXBpZW50cyBh bmQgZW5mb3JjZSBhdHRyaWJ1dGUgYmFzZWQgYWNjZXNzIGNvbnRyb2wgdG8gdGhlIGNvbnRlbnQu ICBBcyBwYXJ0IG9mIHRoYXQgd29yayB3ZSBkZWZpbmUgc29tZXRoaW5nIHdlIGNhbGwgYSBQbGFz bWEgdG9rZW4gd2hpY2ggbGlua3MgYW4gZW1haWwgbWVzc2FnZSB0byBhIHNldCBvZiBYQUNNTCBy dWxlcyB3aGljaCBkZWZpbmVzIHRoZSBzcGVjaWZpY3Mgb2Ygd2hvIGNhbiBhY2Nlc3MgdGhlIG1l c3NhZ2UuIEl0cyBmYWlybHkgc2ltcGxlIHRvIHRha2Ugd2hhdCB3ZSBoYXZlIGluIGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2NoYWFkLXBsYXNtYS1jbXMvIGFuZCByZWNh c3QgaW4gaW4gWE1MIGFuZCBlbWJlZCBhIFBsYXNtYSB0b2tlbiBpbiBhbiBJT0RFRiBkb2N1bWVu dCB1c2luZyB0aGUgYWRkaXRpb25hbCBkYXRhIGV4dGVuc2lvbiBtZWNoYW5pc20gdG8gZGVsaXZl ciBhY2Nlc3MgY29udHJvbCB3aXRoIHRlZXRoLiBIb3dldmVyIHlvdSBjYW5ub3QgaG9tb2dlbml6 ZSB0aGUgYWNjZXNzIGNvbnRyb2wgcG9saWN5IHNvIGl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8g YXBwbHkgYWNjZXNzIGNvbnRyb2wgYXQgdGhlIGRvY3VtZW50IGxldmVsIGJ1dCB0byBpbmRpdmlk dWFsIGluY2lkZW50cyBvciBwYXJ0cyBvZiBpbmNpZGVudHMuIERpZmZlcmVudCBpbmNlbnRzIGNv dWxkIGhhdmUgZGlmZmVyZW50IHBvbGljaWVzLiBJIGNhbiBlbWJlZCBkaWZmZXJlbnQgcG9saWNp ZXMgaW50byB0aGUgc2luZ2xlIFBsYXNtYSB0b2tlbiwgb3IgSSBtYXkgbmVlZCB0byBlbWJlZCBh IHNlcGFyYXRlIHRva2VuIGRlcGVuZGluZyBvbiB0aGUgcG9saWNpZXMgYW5kIHdobyBpcyB0cnVz dGVkLiBBZ2FpbiB0aGUgdG9rZW5zIHNob3VsZCBiZSBhdCB0aGUgZG9jdW1lbnQgbGV2ZWwgbm90 IHRoZSBpbmNpZGVudCBsZXZlbCBhcyBlYWNoIHRva2VuIGNhbiBwcm90ZWN0IG11bHRpcGxlIGlu ZGVudHMuIEkgY2Fubm90IHVzZSB0aGUgZXh0ZW5zaW9uIHBvaW50IGluIHRoZSBpbmNpZGVudCB0 byBzdG9yZSB0aGUgdG9rZW4gYmVjYXVzZSBJIHdhbnQgdG8gZW5jcnlwdCB0aGUgZW50aXJlIGlu Y2VudC4NCg0KSW4gYm90aCBzY2VuYXJpb3MsIHRoZSBJT0RFRiBleHRlbnNpb24gbWVjaGFuaXNt IHdvcmtzIGp1c3QgZmluZSB0byBzb2x2ZSB0aGUgcHJvYmxlbSwgZXhjZXB0IHRoYXQgSSBjYW5u b3QgdXNlIGl0IGF0IHRoZSBkb2N1bWVudCBsZXZlbCBiZWNhdXNlIGl04oCZcyBub3QgaW4gdGhl IElPREVGLWRvY3VtZW50IGNsYXNzLg0KDQpJcyB0aGVyZSBzb21lIHJlYXNvbiBmb3Igbm90IHdh bnRpbmcgdGhlIGRvY3VtZW50IGNsYXNzIGV4dGVuZGVkPw0KDQpUcmV2b3INCg0KRnJvbTogUGFu b3MgS2FtcGFuYWtpcyAocGthbXBhbmEpIFttYWlsdG86cGthbXBhbmFAY2lzY28uY29tXQ0KU2Vu dDogVGh1cnNkYXksIEphbnVhcnkgMTYsIDIwMTQgOToyNSBBTQ0KVG86IFRyZXZvciBGcmVlbWFu OyBNb3JpYXJ0eSwgS2F0aGxlZW47IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogRXh0ZW5kaW5nIHRoZSBJT0RFRi1Eb2N1bWVudCBjbGFzcw0KDQpBdXRo ZW50aWNhdGlvbiBvZiB0aGUgaW5jaWRlbnQgZGF0YSB0aGVtc2VsdmVzIHNlZW1zIHJlYXNvbmFi bGUgdG8gYWRkcmVzcy4NCkJ1dCB0byBzb2x2ZSB0aGF0LCAgd291bGQgaXQgYmUgc2ltcGxlciBm b3Igc29tZW9uZSB0byBzaWduIHRoZSBYTUwgZG9jIG9yIHBhcnRzIG9mIGl0IGFuZCBpbmNsdWRl IGFsbCB0aGUgY2VydHMgdXNpbmcgWE1MIERTSUcgKGVudmVsb3BlZCBvciBkZXRhY2hlZCkgID8N ClBhbm9zDQoNCg0KDQoNCkZyb206IG1pbGUgW21haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBUcmV2b3IgRnJlZW1hbg0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE1 LCAyMDE0IDY6MTggUE0NClRvOiBNb3JpYXJ0eSwgS2F0aGxlZW47IG1pbGVAaWV0Zi5vcmc8bWFp bHRvOm1pbGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21pbGVdIEV4dGVuZGluZyB0aGUgSU9E RUYtRG9jdW1lbnQgY2xhc3MNCg0KSGkgS2F0aGxlZW4sDQoNClJJRCwgdG8gbXkgbWluZCBvZmZl cnMgYSBzZXQgb2Ygc2VjdXJpdHkgc2VydmVzIHRhcmdldGluZyB0aGUgdHJhbnNwb3J0IGFuZCBh dXRob3JpemF0aW9uIG9mIHRoZSBSSUQgbWVzc2FnZXMuIFRoZSBzZWN1cml0eSBvZiAgUklELCBo YW5kbGVzIHRoZSBzZWN1cml0eSBhc3NvY2lhdGVkIHdpdGggdGhlIHByb2Nlc3Npbmcgb2YgUklE IG1lc3NhZ2VzLiBGb3IgZXhhbXBsZSwgYSBSSUQgbWVzc2FnZSBjb3VsZCBiZSBhIHJlcXVlc3Qg Zm9yIGFuIGFjdGlvbiBvciBhIHF1ZXJ5IGZvciBpbmZvcm1hdGlvbi4gVGhpcyBtZXNzYWdlcyBu ZWVkIHNlY3VyaXR5IHNlcnZpY2VzIGJlY2F1c2Ugb2YgdGhlIHBvdGVudGlhbCBpbXBhY3QgaS5l LiB3ZSBkb27igJl0IHdhbnQgdG8gcmVwZWF0IHRoZSBtaXN0YWtlIG9mIFNNVFAgd2hlcmUgdGhl cmUgaXMgbm8gYXV0aGVudGljYXRpb24gd2hlbiBlbWFpbCBpcyBzZW50IGJldHdlZW4gTVRBcy4g VGhlIHRpbWVmcmFtZSBvZiB0aGUgc2VjdXJpdHkgaXMgYXJvdW5kIHRoZSByZXF1ZXN0IGFuZCB0 aGUgcmVzcG9uc2UgUklEIG1lc3NhZ2VzLCBpLmUuIHNlbmQgYSBSSUQgcmVxdWVzdCwgZ2V0IGEg UklEIHJlc3BvbnNlLCBjYXNlIGNsb3NlZC4gVGhlIFJJRCBzZWN1cml0eSBwcm92aWRlcyBvcGVy YXRpb25hbCBzZWN1cml0eSBmb3IgdGhlIGZ1bmN0aW9uaW5nIG9mIGVjb3N5c3RlbS4NCg0KSW5m b3JtYXRpb24gcG9saWNpZXMgbGlrZSBpbmZvcm1hdGlvbiBzaGFyaW5nIG9yIGNvbmZpZGVudGlh bGl0eSBhZ3JlZW1lbnRzIHJlbGF0ZSB0byB0aGUgYWN0dWFsIGNvbnRlbnQgaXRzZWxmIHJlZ2Fy ZGxlc3Mgb2YgZm9ybWF0IGFuZCBwZXJzaXN0cyBiZXlvbmQgcmVjZWl2aW5nIHRoZSBkYXRhIGhl bmNlIGFwcGx5IHRvIHRoZSBjb250ZW50IG9mIHRoZSBJT0RFRiBkb2N1bWVudHMgd2hlcmV2ZXIg dGhleSBhcmUuIElmIEkgd2FzIGEgcmVwb3NpdG9yeSBvZiBpbmNpZGVudCBkYXRhLCBJIGFtIHJl Y2VpdmluZyBpbmNpZGVudHMgd2hpY2ggY291bGQgYmUgc2lnbmVkIGFzIHByb29mIG9mIGRhdGEg b3JpZ2luYXRpb24gZnJvbSBtYW55IHNvdXJjZXMuIElmIEkgcmVjZWl2ZSBhIFJJRCBxdWVyeSBt ZXNzYWdlLCBJIHdvdWxkIGF1dGhvcml6ZSBwcm9jZXNzaW5nIHRoZSByZXF1ZXN0IGJhc2VkIG9u IHRoZSBSSUQgc2VjdXJpdHkgdGhlbiBjb25zdHJ1Y3QgYSBuZXcgSU9ERUYgZG9jdW1lbnQgY29u dGFpbmluZyBhbGwgdGhlIGluY2lkZW50cyBjb3ZlcmVkIGJ5IHRoZSByZXF1ZXN0LiBUaGUgcmVw b3NpdG9yeSB3b3VsZCBzaWduIHRoZSBSSUQgcmVzcG9uc2UsIGJ1dCBJIHdhbnQgdG8gcmV0YWlu IHRoZSBvcmlnaW5hbCBzaWduYXR1cmVzIG9mIHRoZSBjb250cmlidXRvciBvZiB0aGUgaW5jaWRl bnQgZGF0YSBpdHNlbGYgYXMgaXQgcmVsYXRlcyBkaXJlY3RseSB0byB0aGUgcHJvdmlkZW5jZSBv ZiB0aGUgZGF0YS4gIElmIHRoZSBpbmNpZGVudCBkYXRhIHJlcXVpcmVzIHNwZWNpZmljIGFjY2Vz cyBjb250cm9sIHBvbGljaWVzLCB0aG9zZSB0b28gd291bGQgbmVlZCB0byBiZSByZXNwZWN0ZWQg YXMgcGFydCBvZiB0aGUgcmVzcG9uc2UgYW5kIGFyZSBvcnRob2dvbmFsIHRvIHRoZSBjb25maWRl bnRpYWxpdHkgb2YgdGhlIFJJRCByZXNwb25zZSBhcyB0aGV5IGNhbiBjaGFuZ2UgaW5jaWRlbnQg YnkgaW5jaWRlbnQuIEkgc2VlIGFueSBJT0RFRiBzZWN1cml0eSBwcm92aWRpbmcgc2VjdXJpdHkg c2VydmljZXMgdG8gc3VwcG9ydCBjb21wbGlhbmNlIHdpdGggdGhlIGluZm9ybWF0aW9uIHBvbGlj aWVzIGJlIHRoZXkgcmVndWxhdG9yeSBwb2xpY2llcywgY29udHJhY3R1YWwgcG9saWNpZXMsICBp bmZvcm1hdGlvbiBzaGFyaW5nIGFncmVlbWVudHMgb3Igd2hhdGV2ZXIuDQoNCkhvcGUgdGhhdCBo ZWxwcy4NCg0KVHJldm9yDQoNCkZyb206IE1vcmlhcnR5LCBLYXRobGVlbiBbbWFpbHRvOmthdGhs ZWVuLm1vcmlhcnR5QGVtYy5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTUsIDIwMTQg MTE6NDEgQU0NClRvOiBUcmV2b3IgRnJlZW1hbjsgbWlsZUBpZXRmLm9yZzxtYWlsdG86bWlsZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBFeHRlbmRpbmcgdGhlIElPREVGLURvY3VtZW50IGNsYXNz DQoNClRyZXZvciwNCg0KQ291bGQgeW91IGVsYWJvcmF0ZSBvbiBob3cgdGhpcyBpcyBkaWZmZXJl bnQgZnJvbSBvciBjb21wbGltZW50cyB0aGUgRGlnaXRhbCBzaWduYXR1cmUgYW5kIEVuY3J5cHRp b24gZm9yIElPREVGIGluIFJJRCwgUkZDNjU0NT8gIEkgdGhpbmsgdGhhdCB3aWxsIGJlIGhlbHBm dWwgaGVyZS4NCg0KVGhhbmtzLA0KS2F0aGxlZW4NCg0KRnJvbTogbWlsZSBbbWFpbHRvOm1pbGUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRyZXZvciBGcmVlbWFuDQpTZW50OiBXZWRu ZXNkYXksIEphbnVhcnkgMTUsIDIwMTQgMjowMiBQTQ0KVG86IG1pbGVAaWV0Zi5vcmc8bWFpbHRv Om1pbGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWlsZV0gRXh0ZW5kaW5nIHRoZSBJT0RFRi1Eb2N1 bWVudCBjbGFzcw0KDQpJIGFtIGxvb2tpbmcgYXQgaW1wbGVtZW50aW5nIGJldHRlciBlbmQgdG8g ZW5kIHNlY3VyaXR5IHdpdGggSU9ERUYgZG9jdW1lbnRzLg0KDQpGb3IgZXhhbXBsZSwgc3Ryb25n ZXIgYWNjZXNzIGNvbnRyb2wgb24gdGhlIGRhdGEgdGhhbiBpcyBwb3NzaWJsZSB2aWEgdGhlIHJl c3RyaWN0aW9uIGF0dHJpYnV0ZSwgb3Igc3Ryb25nZXIgZGF0YSBvcmlnaW5hdGlvbiBhdXRoZW50 aWNhdGlvbiBieSBzaW5naW5nIGluY2lkZW50cy4NCg0KSW4gYm90aCBjYXNlcyB0aGVyZSBpcyAg c2VjdXJpdHkgcmVsZXZhbnQgbWV0YWRhdGEgd2hpY2ggbWF5IGFwcGx5IHRvIG11bHRpcGxlIGlu Y2lkZW50cyBpbiBhbiBJT0RFRiBkb2N1bWVudC4gRm9yIGV4YW1wbGUgd2l0aCBzaWduZWQgaW5j aWRlbnRzLCBJIHdhbnQgdG8gaW5jbHVkZSBhIHNldCBjZXJ0aWZpY2F0ZXMgdG8gZW5hYmxlIHJl bHlpbmcgcGFydGllcyB0byBiZSBhYmxlIHRvIHZhbGlkYXRlIHRoZSBpbmNpZGVudC4gSSBhbHNv IHdhbnQgdG8gb3B0aW1pemUgdGhlIHNldCBvZiBjZXJ0aWZpY2F0ZXMgaW4gdGhlIGRvY3VtZW50 IGkuZS4gZW5zdXJlIEkgZG9u4oCZdCBpbmNsdWRlIHRoZSBzYW1lIGNlcnRpZmljYXRlIG11bHRp cGxlIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQuIFRoZSBzaW1wbGVzdCB3YXkgdG8gYWNoaWV2ZSB0 aGF0IGlzIHRvIGhhdmUgYWxsIHRoZSBjZXJ0aWZpY2F0ZXMgaW4gb25lIHBsYWNlLiAgVGhlIGxv Z2ljYWwgcGxhY2UgdG8gc3RvcmUgdGhlIHNldCBvZiBjZXJ0aWZpY2F0ZXMgd291bGQgYmUgaW4g dGhlIElPREVGIGRvY3VtZW50IGNsYXNzLiBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gQ01TLCB3aGVy ZSB0aGUgc2V0IG9mIHNpZ25pbmcgY2VydGlmaWNhdGVzIGFyZSBpbiB0aGUgU2lnbmVkRGF0YSBv YmplY3Qgbm90IHRoZSBTaWduZXJJbmZvIG9iamVjdC4gSG93ZXZlciB0aGUgSU9ERUYgZG9jdW1l bnQgY2xhc3MgbGFja3MgdGhlIEFkZGl0aW9uYWxEYXRhIGV4dGVuc2lvbiBwb2ludCBwcmVzZXQg aW4gb3RoZXIgSU9ERUYgY2xhc3Nlcy4NCg0KSXMgaXQgcG9zc2libGUgdG8gYWRkIHRoZSBvcHRp b25hbCBBZGRpdGlvbmFsRGF0YSBlbGVtZW50IHRvIHRoZSB2MiBvZiB0aGUgSU9ERUYgZG9jdW1l bnQgY2xhc3Mgc28gaXQgaXMgcG9zc2libGUgdG8gZXh0ZW5kIHRoYXQgY2xhc3MgdGhlIHNhbWUg d2F5IGl0IGlzIHBvc3NpYmxlIHRvIGV4dGVuZCBvdGhlciBjbGFzc2VzPw0KDQpUcmV2b3INCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptaWxlIG1haWxp bmcgbGlzdA0KbWlsZUBpZXRmLm9yZzxtYWlsdG86bWlsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbWlsZSBtYWlsaW5nIGxpc3QNCm1pbGVAaWV0Zi5v cmc8bWFpbHRvOm1pbGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21pbGUNCg== --_000_DD14082302C54FE989E2EC4CBAD8FED8emccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+KzEgb24g dW5hbWJpZ3VvdXMgZ3VpZGFuY2U8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyw8L2Rp dj48ZGl2PkthdGhsZWVuJm5ic3A7PGJyPjxicj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PGRp dj48YnI+T24gSmFuIDI0LCAyMDE0LCBhdCAxOjA0IFBNLCAiUm9tYW4gRC4gRGFueWxpdyIgJmx0 OzxhIGhyZWY9Im1haWx0bzpyZGRAY2VydC5vcmciPnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7IHdyb3Rl Ojxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCjxtZXRhIGh0dHAt ZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVdpbmRvd3Mt MTI1MiI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0 IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICov DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYg NCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglw YW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQoNCg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGlzIGNoYW5nZSB3YXMgbWFkZSBpbiB0aGUgLTA0IGRyYWZ0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9t YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWlsZSBbPGEg aHJlZj0ibWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1pbGUtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgQnVyZ2VyPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDIzLCAyMDE0IDExOjUzIEFNPGJyPg0KPGI+VG86PC9i PiA8YSBocmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFttaWxlXSBFeHRlbmRpbmcgdGhlIElPREVGLURvY3VtZW50IGNs YXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va3Mg bGlrZSBhbiBvdmVyc2lnaHQsIHVubGVzcyB0aGVyZSBpcyBhIGNvbXBlbGxpbmcgcmVhc29uIHRv IGhhdmUgYSBub24tZXh0ZW5zaWJsZSB0b3AtbGV2ZWwgY2xhc3MuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiAxNywgMjAxNCwgYXQgMToyNiBQTSwg VHJldm9yIEZyZWVtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0cmV2b3JmQGV4Y2hhbmdlLm1pY3Jv c29mdC5jb20iPnRyZXZvcmZAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV4YWN0bHk8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2FzIHRyeWluZyB0 byBmaWd1cmUgb3V0IGlmIHRoaXMgaXMgYSBzaW1wbGUgb3ZlcnNpZ2h0IG9yIGRlbGliZXJhdGUg YWN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RG9lcyBhbnlvbmUgb2JqZWN0IHRvIGZpbGxpbmcgdGhlIGdhcCBhbmQgYWRkaW5nIHRoZSBl eHRlbnNpb24gdG8gdGhlIElPREVGLWRvY3VtZW50IGNsYXNzPzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VHJldm9yPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Sb21hbg0KIEQuIERhbnlsaXcgWzxhIGhyZWY9Im1haWx0 bzpyZGRAY2VydC5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5tYWlsdG86cmRkQGNl cnQub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgSmFudWFyeSAxNiwgMjAxNCAxMTozOCBBTTxi cj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+VHJldm9yIEZyZWVtYW47IFBhbm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKTsgTW9yaWFy dHksIEthdGhsZWVuOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5 NTRGNzIiPm1pbGVAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogRXh0ZW5kaW5n IHRoZSBJT0RFRi1Eb2N1bWVudCBjbGFzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Hb29kIGFmdGVybm9vbiE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpZGVzdGVwcGluZyB0aGUgc2lnbmF0dXJlIGRpc2N1 c3Npb24sIEkgdGhpbmsgdGhhdCBUcmV2b3IgaXMgcG9pbnRpbmcgb3V0IGEgZ2FwIGluIHRoZSBk YXRhIG1vZGVsLiZuYnNwOyBJIGNvbmN1ciB0aGF0IGl0IHdvdWxkIGJlIHZhbHVhYmxlIHRvIGhh dmUgdGhlIGFiaWxpdHkNCiB0byBhZGQgYW4gZXh0ZW5zaW9uIGludG8gYW4gSU9ERUYtRG9jdW1l bnQuJm5ic3A7IEl0IHdvdWxkIGFsbG93IHVuYW50aWNpcGF0ZWQgZGF0YSBlbGVtZW50cyB0byBi ZSBhZGRlZCBpbnRvIHRoZSByb290IG5vZGUgdGhhdCBhcmUgcmVsZXZhbnQgdG8gbXVsdGlwbGUg SW5jaWRlbnQgY2xhc3NlcyBhZ2dyZWdhdGVkIGluIHRoZSBJT0RFRi1Eb2N1bWVudCBjbGFzcy48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJv bWFuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+bWlsZQ0KIFs8YSBocmVmPSJtYWlsdG86bWlsZS1ib3VuY2VzQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9iPlRyZXZvciBGcmVlbWFuPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBKYW51YXJ5IDE2LCAy MDE0IDI6MjggUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlBhbm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKTsgTW9yaWFydHks IEthdGhsZWVuOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRG NzIiPm1pbGVAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW21pbGVdIEV4dGVu ZGluZyB0aGUgSU9ERUYtRG9jdW1lbnQgY2xhc3M8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUGFu b3MsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Gb3IgZGlnaXRhbCBzaWduYXR1cmVzLCBpdCBpcyBhIGNsYXNzaWMgaXNzdWVzIGJldHdlZW4g d2hhdCB5b3UgZG8gd2l0aCBhIHNpbmdsZSBzaWduYXR1cmUgdnMuIG11bHRpcGxlIHNpZ25hdHVy ZXMuIEZvciBhIHNpbmdsZSBzaWduYXR1cmUsIHdoYXQgeW91IGRlc2NyaWJlDQogd29ya3MgZS5n LiBhIGRvY3VtZW50IHdpdGggYSBzaW5nbGUgaW5jaWRlbnQg4oCTIG5vIHByb2JsZW0uIEl04oCZ cyBhbHNvIG5vdCBhIHByb2JsZW0gd2l0aCB0aGUgYWN0dWFsIHNpZ25hdHVyZSBpdHNlbGYsIHRo YXQgdG9vIGlzIGZpbmUuIEl04oCZcyBzaW1wbHkgYSBxdWVzdGlvbiBvZiBvcHRpbWl6aW5nIHRo ZSBiYWcgb2YgY2VydGlmaWNhdGVzIHlvdSBuZWVkIHRvIHZhbGlkYXRlIG11bHRpcGxlIHNpZ25h dHVyZXMuJm5ic3A7IElmIHlvdSBzdGFydCZuYnNwOyBhZ2dyZWdhdGluZw0KIGluY2lkZW50IGRh dGEsIGFuZCBoYXZlIGRpZmZlcmVudCBpbmNpZGVudHMgZnJvbSBkaWZmZXJlbnQgc291cmNlcyB3 aXRoIGRpZmZlcmVudCBzaWduZXJzLCB5b3UgbmVlZCB0byBub3JtYWxpemUgdGhlIGNlcnRpZmlj YXRlIGRhdGEgc2V0IGFjcm9zcyBhbGwgdGhlIHNpZ25lcnMgc28geW91IGRvbuKAmXQgYmxvYXQg dGhlIGRvY3VtZW50IHdpdGggcmVkdW5kYW50IGRhdGEuIFRoZSBzY2hlbWEgSSB3b3VsZCBkZWZp bmUgaXMgdHJpdmlhbCBhcyBpdA0KIHdvdWxkIHJldXNlIHRoZSBlbGVtZW50cyBkZWZpbmVkIGlu IHRoZSBYTUwgc2lnbmF0dXJlIHN0YW5kYXJkLCBidXQgc2hvdWxkIGJlJm5ic3A7IHN0b3JlZCBp biB0aGUgc2NoZW1hJm5ic3A7IGF0IHRoZSBsZXZlbCBvZiB0aGUgSU9ERUYgZG9jdW1lbnQgYXMg aXQgcGVydGFpbnMgdG8gbXVsdGlwbGUgaW5jaWRlbnRzLiBUaGlzIGlzIHRoZSBiZWhhdmlvciB0 aGF0IENNUyB1c2VzIGkuZS4gY2VydGlmaWNhdGVzIGFyZSBub3QgcGFydCBvZiB0aGUgU2lnbmVy SW5mbw0KIGJ1dCBhcmUgcGFydCBvZiB0aGUgU2lnbmVkIERhdGEgc3RydWN0dXJlLiBUaGlzIGFs bG93cyBhIHNpbmdsZSBiYWcgb2YgY2VydGlmaWNhdGVzIHRvIGJlIHVzZWQgYWNyb3NzIGFsbCBT aWduZXJJbmZvIHN0cnVjdHVyZXMuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgd29yayB0aGF0IEthdGhsZWVuIGlzIHJlZmVy cmluZyB0byBpcyB0aGUgd29yayBJIGFtIGRvaW5nIHdpdGggSmltIFNjaGFhZCBvbiBzdHJvbmdl ciBwb2xpY3kgZW5mb3JjZW1lbnQgb24gZGlzdHJpYnV0ZWQgZGF0YS4gV2Ugc3RhcnRlZCB3b3Jr IG9uIGVtYWlsIGFuZA0KIHRoZSB3b3JrIGdvZXMgdW5kZXIgdGhlIFBsYXNtYSBuYW1lIGluIHRo ZSBJRVRGLiBXZSBoYXZlIGRldmVsb3BlZCBhIG1lY2hhbmlzbSB0byBhcHBseSBzdHJvbmcgYWNj ZXNzIGNvbnRyb2wgcG9saWN5IG9uIGVtYWlsIHdoZXJlYnkgd2UgY2FuIHNlbmQgb3V0IGEgbWVz c2FnZSB0byBtdWx0aXBsZSByZWNpcGllbnRzIGFuZCBlbmZvcmNlIGF0dHJpYnV0ZSBiYXNlZCBh Y2Nlc3MgY29udHJvbCB0byB0aGUgY29udGVudC4mbmJzcDsgQXMgcGFydCBvZiB0aGF0DQogd29y ayB3ZSBkZWZpbmUgc29tZXRoaW5nIHdlIGNhbGwgYSBQbGFzbWEgdG9rZW4gd2hpY2ggbGlua3Mg YW4gZW1haWwgbWVzc2FnZSB0byBhIHNldCBvZiBYQUNNTCBydWxlcyB3aGljaCBkZWZpbmVzIHRo ZSBzcGVjaWZpY3Mgb2Ygd2hvIGNhbiBhY2Nlc3MgdGhlIG1lc3NhZ2UuIEl0cyBmYWlybHkgc2lt cGxlIHRvIHRha2Ugd2hhdCB3ZSBoYXZlIGluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtc2NoYWFkLXBsYXNtYS1jbXMvIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zY2hhYWQtcGxhc21hLWNtcy88 L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5hbmQNCiByZWNhc3QgaW4gaW4gWE1MIGFuZCBlbWJlZCBhIFBsYXNtYSB0b2tlbiBpbiBhbiBJ T0RFRiBkb2N1bWVudCB1c2luZyB0aGUgYWRkaXRpb25hbCBkYXRhIGV4dGVuc2lvbiBtZWNoYW5p c20gdG8gZGVsaXZlciBhY2Nlc3MgY29udHJvbCB3aXRoIHRlZXRoLiBIb3dldmVyIHlvdSBjYW5u b3QgaG9tb2dlbml6ZSB0aGUgYWNjZXNzIGNvbnRyb2wgcG9saWN5IHNvIGl0IGRvZXMgbm90IG1h a2Ugc2Vuc2UgdG8gYXBwbHkgYWNjZXNzIGNvbnRyb2wgYXQNCiB0aGUgZG9jdW1lbnQgbGV2ZWwg YnV0IHRvIGluZGl2aWR1YWwgaW5jaWRlbnRzIG9yIHBhcnRzIG9mIGluY2lkZW50cy4gRGlmZmVy ZW50IGluY2VudHMgY291bGQgaGF2ZSBkaWZmZXJlbnQgcG9saWNpZXMuIEkgY2FuIGVtYmVkIGRp ZmZlcmVudCBwb2xpY2llcyBpbnRvIHRoZSBzaW5nbGUgUGxhc21hIHRva2VuLCBvciBJIG1heSBu ZWVkIHRvIGVtYmVkIGEgc2VwYXJhdGUgdG9rZW4gZGVwZW5kaW5nIG9uIHRoZSBwb2xpY2llcyBh bmQgd2hvIGlzDQogdHJ1c3RlZC4gQWdhaW4gdGhlIHRva2VucyBzaG91bGQgYmUgYXQgdGhlIGRv Y3VtZW50IGxldmVsIG5vdCB0aGUgaW5jaWRlbnQgbGV2ZWwgYXMgZWFjaCB0b2tlbiBjYW4gcHJv dGVjdCBtdWx0aXBsZSBpbmRlbnRzLiBJIGNhbm5vdCB1c2UgdGhlIGV4dGVuc2lvbiBwb2ludCBp biB0aGUgaW5jaWRlbnQgdG8gc3RvcmUgdGhlIHRva2VuIGJlY2F1c2UgSSB3YW50IHRvIGVuY3J5 cHQgdGhlIGVudGlyZSBpbmNlbnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JbiBib3RoIHNjZW5hcmlvcywgdGhlIElPREVGIGV4dGVuc2lv biBtZWNoYW5pc20gd29ya3MganVzdCBmaW5lIHRvIHNvbHZlIHRoZSBwcm9ibGVtLCBleGNlcHQg dGhhdCBJIGNhbm5vdCB1c2UgaXQgYXQgdGhlIGRvY3VtZW50IGxldmVsIGJlY2F1c2UgaXTigJlz IG5vdCBpbg0KIHRoZSBJT0RFRi1kb2N1bWVudCBjbGFzcy48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIHRoZXJlIHNvbWUgcmVhc29uIGZv ciBub3Qgd2FudGluZyB0aGUgZG9jdW1lbnQgY2xhc3MgZXh0ZW5kZWQ/PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UcmV2b3I8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBhbm9zDQogS2FtcGFuYWtpcyAocGthbXBhbmEp IFs8YSBocmVmPSJtYWlsdG86cGthbXBhbmFAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk1NEY3MiI+bWFpbHRvOnBrYW1wYW5hQGNpc2NvLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXks IEphbnVhcnkgMTYsIDIwMTQgOToyNSBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHJldm9yIEZyZWVtYW47IE1vcmlhcnR5 LCBLYXRobGVlbjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0 RjcyIj5taWxlQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IEV4dGVuZGluZyB0 aGUgSU9ERUYtRG9jdW1lbnQgY2xhc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QXV0aGVudGljYXRpb24gb2YgdGhlIGluY2lkZW50IGRhdGEgdGhlbXNlbHZlcyBz ZWVtcyByZWFzb25hYmxlIHRvIGFkZHJlc3MuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0 byBzb2x2ZSB0aGF0LCAmbmJzcDt3b3VsZCBpdCBiZSBzaW1wbGVyIGZvciBzb21lb25lIHRvIHNp Z24gdGhlIFhNTCBkb2Mgb3IgcGFydHMgb2YgaXQgYW5kIGluY2x1ZGUgYWxsIHRoZSBjZXJ0cyB1 c2luZyBYTUwgRFNJRyAoZW52ZWxvcGVkIG9yIGRldGFjaGVkKSAmbmJzcDs/PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBhbm9zPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5taWxlDQogWzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzptaWxlLWJvdW5jZXNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5NTRGNzIiPm1haWx0bzptaWxlLWJv dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5P bg0KIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L2I+VHJldm9yIEZyZWVtYW48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5LCBKYW51YXJ5IDE1LCAy MDE0IDY6MTggUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPk1vcmlhcnR5LCBLYXRobGVlbjs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOm1pbGVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM5NTRGNzIiPm1pbGVAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbbWlsZV0gRXh0ZW5k aW5nIHRoZSBJT0RFRi1Eb2N1bWVudCBjbGFzczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBLYXRo bGVlbiw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJJRCwgdG8gbXkgbWluZCBvZmZlcnMgYSBzZXQgb2Ygc2VjdXJpdHkgc2VydmVzIHRhcmdl dGluZyB0aGUgdHJhbnNwb3J0IGFuZCBhdXRob3JpemF0aW9uIG9mIHRoZSBSSUQgbWVzc2FnZXMu IFRoZSBzZWN1cml0eSBvZiAmbmJzcDtSSUQsIGhhbmRsZXMgdGhlIHNlY3VyaXR5IGFzc29jaWF0 ZWQNCiB3aXRoIHRoZSBwcm9jZXNzaW5nIG9mIFJJRCBtZXNzYWdlcy4gRm9yIGV4YW1wbGUsIGEg UklEIG1lc3NhZ2UgY291bGQgYmUgYSByZXF1ZXN0IGZvciBhbiBhY3Rpb24gb3IgYSBxdWVyeSBm b3IgaW5mb3JtYXRpb24uIFRoaXMgbWVzc2FnZXMgbmVlZCBzZWN1cml0eSBzZXJ2aWNlcyBiZWNh dXNlIG9mIHRoZSBwb3RlbnRpYWwgaW1wYWN0IGkuZS4gd2UgZG9u4oCZdCB3YW50IHRvIHJlcGVh dCB0aGUgbWlzdGFrZSBvZiBTTVRQIHdoZXJlIHRoZXJlIGlzDQogbm8gYXV0aGVudGljYXRpb24g d2hlbiBlbWFpbCBpcyBzZW50IGJldHdlZW4gTVRBcy4gVGhlIHRpbWVmcmFtZSBvZiB0aGUgc2Vj dXJpdHkgaXMgYXJvdW5kIHRoZSByZXF1ZXN0IGFuZCB0aGUgcmVzcG9uc2UgUklEIG1lc3NhZ2Vz LCBpLmUuIHNlbmQgYSBSSUQgcmVxdWVzdCwgZ2V0IGEgUklEIHJlc3BvbnNlLCBjYXNlIGNsb3Nl ZC4gVGhlIFJJRCBzZWN1cml0eSBwcm92aWRlcyBvcGVyYXRpb25hbCBzZWN1cml0eSBmb3IgdGhl IGZ1bmN0aW9uaW5nDQogb2YgZWNvc3lzdGVtLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5mb3JtYXRpb24gcG9saWNpZXMgbGlrZSBpbmZv cm1hdGlvbiBzaGFyaW5nIG9yIGNvbmZpZGVudGlhbGl0eSBhZ3JlZW1lbnRzIHJlbGF0ZSB0byB0 aGUgYWN0dWFsIGNvbnRlbnQgaXRzZWxmIHJlZ2FyZGxlc3Mgb2YgZm9ybWF0IGFuZCBwZXJzaXN0 cyBiZXlvbmQgcmVjZWl2aW5nDQogdGhlIGRhdGEgaGVuY2UgYXBwbHkgdG8gdGhlIGNvbnRlbnQg b2YgdGhlIElPREVGIGRvY3VtZW50cyB3aGVyZXZlciB0aGV5IGFyZS4gSWYgSSB3YXMgYSByZXBv c2l0b3J5IG9mIGluY2lkZW50IGRhdGEsIEkgYW0gcmVjZWl2aW5nIGluY2lkZW50cyB3aGljaCBj b3VsZCBiZSBzaWduZWQgYXMgcHJvb2Ygb2YgZGF0YSBvcmlnaW5hdGlvbiBmcm9tIG1hbnkgc291 cmNlcy4gSWYgSSByZWNlaXZlIGEgUklEIHF1ZXJ5IG1lc3NhZ2UsIEkgd291bGQgYXV0aG9yaXpl DQogcHJvY2Vzc2luZyB0aGUgcmVxdWVzdCBiYXNlZCBvbiB0aGUgUklEIHNlY3VyaXR5IHRoZW4g Y29uc3RydWN0IGEgbmV3IElPREVGIGRvY3VtZW50IGNvbnRhaW5pbmcgYWxsIHRoZSBpbmNpZGVu dHMgY292ZXJlZCBieSB0aGUgcmVxdWVzdC4gVGhlIHJlcG9zaXRvcnkgd291bGQgc2lnbiB0aGUg UklEIHJlc3BvbnNlLCBidXQgSSB3YW50IHRvIHJldGFpbiB0aGUgb3JpZ2luYWwgc2lnbmF0dXJl cyBvZiB0aGUgY29udHJpYnV0b3Igb2YgdGhlIGluY2lkZW50DQogZGF0YSBpdHNlbGYgYXMgaXQg cmVsYXRlcyBkaXJlY3RseSB0byB0aGUgcHJvdmlkZW5jZSBvZiB0aGUgZGF0YS4gJm5ic3A7SWYg dGhlIGluY2lkZW50IGRhdGEgcmVxdWlyZXMgc3BlY2lmaWMgYWNjZXNzIGNvbnRyb2wgcG9saWNp ZXMsIHRob3NlIHRvbyB3b3VsZCBuZWVkIHRvIGJlIHJlc3BlY3RlZCBhcyBwYXJ0IG9mIHRoZSBy ZXNwb25zZSBhbmQgYXJlIG9ydGhvZ29uYWwgdG8gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUg UklEIHJlc3BvbnNlIGFzDQogdGhleSBjYW4gY2hhbmdlIGluY2lkZW50IGJ5IGluY2lkZW50LiBJ IHNlZSBhbnkgSU9ERUYgc2VjdXJpdHkgcHJvdmlkaW5nIHNlY3VyaXR5IHNlcnZpY2VzIHRvIHN1 cHBvcnQgY29tcGxpYW5jZSB3aXRoIHRoZSBpbmZvcm1hdGlvbiBwb2xpY2llcyBiZSB0aGV5IHJl Z3VsYXRvcnkgcG9saWNpZXMsIGNvbnRyYWN0dWFsIHBvbGljaWVzLCAmbmJzcDtpbmZvcm1hdGlv biBzaGFyaW5nIGFncmVlbWVudHMgb3Igd2hhdGV2ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3BlIHRoYXQgaGVscHMuPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UcmV2b3I8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1vcmlhcnR5LA0KIEthdGhsZWVuIFs8 YSBocmVmPSJtYWlsdG86a2F0aGxlZW4ubW9yaWFydHlAZW1jLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOiM5NTRGNzIiPm1haWx0bzprYXRobGVlbi5tb3JpYXJ0eUBlbWMuY29tPC9zcGFuPjwvYT5d PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5XZWRuZXNkYXksIEphbnVhcnkgMTUsIDIwMTQgMTE6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRyZXZvciBGcmVl bWFuOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPm1p bGVAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogRXh0ZW5kaW5nIHRoZSBJT0RF Ri1Eb2N1bWVudCBjbGFzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UcmV2b3IsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Db3VsZCB5b3UgZWxhYm9yYXRlIG9uIGhvdyB0aGlzIGlzIGRpZmZlcmVudCBmcm9t IG9yIGNvbXBsaW1lbnRzIHRoZSBEaWdpdGFsIHNpZ25hdHVyZSBhbmQgRW5jcnlwdGlvbiBmb3Ig SU9ERUYgaW4gUklELCBSRkM2NTQ1PyZuYnNwOyBJIHRoaW5rIHRoYXQgd2lsbCBiZSBoZWxwZnVs DQogaGVyZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoYW5rcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+S2F0aGxlZW48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1pbGUNCiBbPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOm1pbGUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk1NEY3MiI+bWFpbHRvOm1pbGUtYm91bmNlc0Bp ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVo YWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv Yj5UcmV2b3IgRnJlZW1hbjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIEphbnVhcnkgMTUsIDIwMTQgMjow MiBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0i bWFpbHRvOm1pbGVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5 NTRGNzIiPm1pbGVAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlttaWxlXSBFeHRlbmRpbmcgdGhlIElPREVGLURvY3VtZW50 IGNsYXNzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5JIGFtIGxvb2tpbmcgYXQgaW1wbGVtZW50aW5nIGJldHRlciBlbmQgdG8g ZW5kIHNlY3VyaXR5IHdpdGggSU9ERUYgZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgZXhhbXBs ZSwgc3Ryb25nZXIgYWNjZXNzIGNvbnRyb2wgb24gdGhlIGRhdGEgdGhhbiBpcyBwb3NzaWJsZSB2 aWEgdGhlIHJlc3RyaWN0aW9uIGF0dHJpYnV0ZSwgb3Igc3Ryb25nZXIgZGF0YSBvcmlnaW5hdGlv biBhdXRoZW50aWNhdGlvbiBieSBzaW5naW5nIGluY2lkZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gYm90 aCBjYXNlcyB0aGVyZSBpcyZuYnNwOyBzZWN1cml0eSByZWxldmFudCBtZXRhZGF0YSB3aGljaCBt YXkgYXBwbHkgdG8gbXVsdGlwbGUgaW5jaWRlbnRzIGluIGFuIElPREVGIGRvY3VtZW50LiBGb3Ig ZXhhbXBsZSB3aXRoIHNpZ25lZCBpbmNpZGVudHMsIEkgd2FudCB0byBpbmNsdWRlIGEgc2V0DQog Y2VydGlmaWNhdGVzIHRvIGVuYWJsZSByZWx5aW5nIHBhcnRpZXMgdG8gYmUgYWJsZSB0byB2YWxp ZGF0ZSB0aGUgaW5jaWRlbnQuIEkgYWxzbyB3YW50IHRvIG9wdGltaXplIHRoZSBzZXQgb2YgY2Vy dGlmaWNhdGVzIGluIHRoZSBkb2N1bWVudCBpLmUuIGVuc3VyZSBJIGRvbuKAmXQgaW5jbHVkZSB0 aGUgc2FtZSBjZXJ0aWZpY2F0ZSBtdWx0aXBsZSBwbGFjZXMgaW4gdGhlIGRvY3VtZW50LiBUaGUg c2ltcGxlc3Qgd2F5IHRvIGFjaGlldmUgdGhhdCBpcw0KIHRvIGhhdmUgYWxsIHRoZSBjZXJ0aWZp Y2F0ZXMgaW4gb25lIHBsYWNlLiAmbmJzcDtUaGUgbG9naWNhbCBwbGFjZSB0byBzdG9yZSB0aGUg c2V0IG9mIGNlcnRpZmljYXRlcyB3b3VsZCBiZSBpbiB0aGUgSU9ERUYgZG9jdW1lbnQgY2xhc3Mu IFRoaXMgaXMgZXF1aXZhbGVudCB0byBDTVMsIHdoZXJlIHRoZSBzZXQgb2Ygc2lnbmluZyBjZXJ0 aWZpY2F0ZXMgYXJlIGluIHRoZSBTaWduZWREYXRhIG9iamVjdCBub3QgdGhlIFNpZ25lckluZm8g b2JqZWN0LiBIb3dldmVyDQogdGhlIElPREVGIGRvY3VtZW50IGNsYXNzIGxhY2tzIHRoZSBBZGRp dGlvbmFsRGF0YSBleHRlbnNpb24gcG9pbnQgcHJlc2V0IGluIG90aGVyIElPREVGIGNsYXNzZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPklzIGl0IHBvc3NpYmxlIHRvIGFkZCB0aGUgb3B0aW9uYWwgQWRkaXRpb25h bERhdGEgZWxlbWVudCB0byB0aGUgdjIgb2YgdGhlIElPREVGIGRvY3VtZW50IGNsYXNzIHNvIGl0 IGlzIHBvc3NpYmxlIHRvIGV4dGVuZCB0aGF0IGNsYXNzIHRoZSBzYW1lIHdheSBpdCBpcyBwb3Nz aWJsZSB0byBleHRlbmQNCiBvdGhlciBjbGFzc2VzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UcmV2b3I8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQptaWxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzptaWxlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bWlsZUBpZXRm Lm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9taWxlIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taWxlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQoNCg0KPC9kaXY+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPm1pbGUgbWFpbGluZyBs aXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86bWlsZUBpZXRmLm9yZyI+bWlsZUBp ZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWlsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9taWxlPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_DD14082302C54FE989E2EC4CBAD8FED8emccom_-- From prvs=110153de65=BlakeJohnson@alliantenergy.com Fri Jan 24 11:09:09 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAED1A00F4 for ; Fri, 24 Jan 2014 11:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpaSdy9YurYl for ; Fri, 24 Jan 2014 11:09:05 -0800 (PST) Received: from mx1.alliantenergy.com (out1.alliantenergy.com [198.7.45.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEB91A0047 for ; Fri, 24 Jan 2014 11:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=alliantenergy.com; s=alliantenergy; c=relaxed/simple; q=dns/txt; i=@alliantenergy.com; t=1390590543; x=1393182543; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XkIak9R57dJRtksMAYqLB3sK1kjVAdEnpzP36NjaiIE=; b=kPAqJ641pVHToV4sR1awhV8U8iMx4FZb8r8G+5/+D06wLCR0XkO68jEavS4EBlXc KUThVRP7Cuwcj9SQ+11srPNKbarZZFCpng+6dpnRzD+O4e7msS1TJLaAu0UB2IQ2 fA/02GYdkzoVwS2evmNd6Pbe56gNZ3Nin0AUH01oeq4=; X-AuditID: c6072d90-f79366d00000786f-e2-52e2ba4f5a21 Received: from email.alliant-energy.com ( [10.10.69.178]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.alliantenergy.com (Alliant Energy) with SMTP id 7C.8B.30831.F4AB2E25; Fri, 24 Jan 2014 13:09:03 -0600 (CST) Received: from MSNWINMAILBOX2.ALI.PRI ([169.254.2.76]) by MSNWINMAILHC2.ALI.PRI ([10.10.69.178]) with mapi id 14.03.0174.001; Fri, 24 Jan 2014 13:09:03 -0600 From: "Johnson, Blake" To: Jerome Athias , "murillo@ieee.org" Thread-Topic: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt Thread-Index: AQHPGKmID+H3utsmqEmxpqGgRStvQpqT/YQAgAA/THA= Date: Fri, 24 Jan 2014 19:09:02 +0000 Message-ID: <6855397E5430804F9E017DDE40F11303F1EC36@MSNWINMAILBOX2.ALI.PRI> References: <20140122155745.18162.21877.idtracker@ietfa.amsl.com> <52E1CBB5.6000906@ieee.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.69.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsXCxeW6Sdd/16Mgg95+bYtnK4+yWez538dk 8Xj2fnYHZo+ds+6yezydcJDJY8mSn0wBzFHcNkmJJWXBmel5+nYJ3Bm9+1ezFPQ7V9zZztLA +Nqsi5GTQ0LAROLI3ccsELaYxIV769m6GLk4hAS6mSROn3vPAuEsZJQ4sW8iWBWbgLnE8eaV YLaIQLDEjTUnwWxmAWWJEw1L2EBsYYFQiZUd26FqwiRW71nDDGFbSTyevZMVxGYRUJX4s3Am UxcjBwevgLfE1hnsELuWMUqsadjPDlLDKRAo0XnvAxOIzQh03fdTa5ggdolL3HoynwniagGJ JXvOM0PYohIvH/9jhbAVJA7uOMUOUa8jsWD3JzYIW1ti2cLXYPW8AoISJ2c+YZnAKDYLydhZ SFpmIWmZhaRlASPLKkaZ3OK81OLkxDxDvcScnMzEvBLd1LzUovRKveT83E2MwBg7xq47YQfj uXU2hxgFOBiVeHh1Zz0KEmJNLCuuzD3EKMHBrCTCO3czUIg3JbGyKrUoP76oNCe1+BCjNAeL kjjv8ZozQUIC6YklqdmpqQWpRTBZJg5OkG4uKZHi1LyU1KLE0pKMeFBcxxcDI1uqgZGt5xyH 97Lk7bOqJojUaa2dsFIqW2qvds/WI7+Em5aJflObE6J7koH5gO7Gh7K+8uq8nfNrND1uVei0 Nf2uM9poM+FJocAbH5+t6lPfvvu4wM3CPGneXqV7bCVGjPqaNrsY5E6n33Zkqk4Nux45WTXd UNr/j+yp5NYVG9/2fzx6vX9+/+fkfiWW4oxEQy3mouJEAIrIFUfIAgAA Cc: "mile@ietf.org" Subject: Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:09:09 -0000 This is an interesting application of IODEF that I had not considered. Most= industry sharing that takes place in this space, from my perspective, is i= n the form of in person and telephone threat briefings. These are facilitat= ed by the FBI, DHS, and the ISAC's. At least a handful of the ISAC's have started sharing structured threat ind= icator data, and the taxonomy for this extension could cover what the Elect= ric Sector ISAC currently refers to as 'Experience Sharing.' I can review t= his proposal as it relates to information captured by the ES-ISAC's Experie= nce Sharing tool, using IEC/ANSI 62443 (ISA99) as an informative reference. Blake Johnson Threat Intelligence Analyst Alliant Energy | Infrastructure Secruity Office: 608-458-6320 | Cell: 608-843-2790 -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Jerome Athias Sent: Friday, January 24, 2014 3:18 AM To: murillo@ieee.org Cc: mile@ietf.org Subject: Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cp= s-00.txt Hi, from what I know (which is limited), and as you mention, this ICS area is often also called Critical Infrastructures (CIs), or SCADA for a little bit of background, we could explore the Cybersecurity Framewor= k Example references http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx http://www.ictqatar.qa/en/documents/download/National%20Industrial%20Contro= l%20Systems%20Security%20Standard-English.pdf ANSI/ISA-99.02.01-2009 I don't have enough knowledge about the status and adoption of the different efforts in term of XML representation/format/standards http://xml.coverpages.org/emergencyManagement.html and resilience It would maybe be possible to obtain information from there http://ics-cert.us-cert.gov http://ics-isac.org/ My first feedback is that it looks like an interesting extension. I would suggest to focus on the reuse of existing Taxonomies, or references to them. As such, for [Industry], maybe http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=3D2012 ISO 3166 (Country Codes) [TargetSystems], I (personally) don't like the word "system" and prefer "as= set" [CompromisedPhysicalInfrastrucute] (with a typo ;p) seems to be a category of "Infrastructure" (or group of assets) [EntryPoint] could be ok since it could be a little bit different from "endpoint" [PerpetratingParty] seems to reference "Threat Actor" or "Threat Agent" or "Attacker" [RecurrencePreventionMeasures] is this Security Controls? (and Mitigations/Remediations) Reference: https://web.nvd.nist.gov/view/800-53/control?controlName=3DAC-3&= type=3D1 Describing an [Exploit] is not so easy (depending on the level of details wanted/needed) Figure 1 (or "Diagram 1") is interesting, (of course it is different from, i.e. CAESARS), it MAYBE could be more layered http://www.isa.org/InTechTemplate.cfm?template=3D/ContentManagement/Content= Display.cfm&ContentID=3D94401 (To follow: ENISA CDXI) Some typos Next step: more XML focused ;) My 2 bitcents 2014/1/24 Martin Murillo : > Dear all, > > Please find below a link to a proposed draft for extending IODEF for the > reporting of cyber-physical system incidents. These systems are often > referred as Operational Technology Systems, Industrial Control Systems, > Automatic Control Systems, or simply Control Systems. > > Cyber-Physical systems have been around for decades. However, they are n= ow > at a higher risk to be the target of attacks by individual highly-skille= d > attackers, organized groups, nation-states, or simply suffer repercussion= s > of mainstream IT cyber-attacks. While over 90% of critical control system > infrastructure is currently owned by private enterprises, these can have > direct repercussions on national security of world nations. Indeed, vari= ous > of these systems are key parts of nuclear reactor facilities, transportat= ion > systems, electric power distribution, oil and natural gas distribution, > health care, water and waste-water treatment, dam infrastructure, missile > and defense systems, and others. The disruption of these control system= s > could have a significant impact on public health, safety, and lead to lar= ge > economic losses. > > Among the issues that catalyze this higher risk are: > > i) these systems are gradually becoming more interconnected, ii) legacy > systems do not have proper cybersecurity protection, iii) the existence o= f > highly-skilled individuals and motivations, iv) some these systems are > generally considered critical, v) these are a natural extension of IT > cyber-attacks, vi) the emergence of the Internet of Things (IOT), and vi) > these attacks can be carried out remotely and quite inexpensively. > > While there might exist national approaches to deal with incidents, there= 's > the need of a global international approach that will engulf governments, > private organizations and other stakeholders. IETF, as a leading global > Internet standards organization, seeks to satisfy this need through open > standards that seek to encompass issues that are critical for the global > community. > > Feedback at two levels are welcome: > > 1. On the existence and inclusion either by utilizing any already existin= g > industry formats (XML- encoded) and/or by utilizing atomic data > 2. Contributions on making the extension (and background information) mor= e > comprehensive, accurate and principally useful for the community > > Look forward to feedback and other input! > > Martin Murillo > > A new version of I-D, draft-murillo-mile-cps-00.txt > has been successfully submitted by Martin Murillo and posted to the > IETF repository. > > Name: draft-murillo-mile-cps > Revision: 00 > Title: IODEF extension for Reporting Cyber-Physical System > Incidents > Document date: 2014-01-21 > Group: Individual Submission > Pages: 24 > URL: > http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt > Status: https://datatracker.ietf.org/doc/draft-murillo-mile-cps/ > Htmlized: http://tools.ietf.org/html/draft-murillo-mile-cps-00 > > > Abstract: > This draft document will extend the Incident Object Description > Exchange Format (IODEF) defined in [RFC5070] to support the reporting > of incidents dealing with attacks to physical infrastructure through > the utilization of IT means as a vehicle or as a tool. These systems > might also be referred as Cyber-Physical Systems (CPS), Operational > Technology Systems, Industrial Control Systems, Automatic Control > Systems, or simply Control Systems. These names are used > interchangeably in this document. In this context, an incident is > generally the result of a cybersecurity issue whose main goal is to > affect the operation of a CPS. It is considered that any > unauthorized alteration of the operation is always malign. This > extension will provide the capability of embedding structured > information, such as identifier- and XML-based information. In its > current state, this document provides important considerations for > further work in implementing Cyber-Physical System incident reports, > either by utilizing any already existing industry formats (XML- > encoded) and/or by utilizing atomic data. > > In addition, this document should provide appropriate material for > helping making due considerations in making an appropriate decision > on how a CPS reporting is done: 1) through a data format extension to > the Incident Object Description Exchange Format [RFC5070], 2) forming > part of an already existing IODEF-extension for structured > cybersecurity information (currently draft > draft-ietf-mile-sci-11.txt), or others. While the format and > contents of the present document fit more the earlier option, these > can also be incorporated to the later. > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From pkampana@cisco.com Fri Jan 24 13:18:22 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E571A0209 for ; Fri, 24 Jan 2014 13:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.835 X-Spam-Level: X-Spam-Status: No, score=-8.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_Umz_hVwCob for ; Fri, 24 Jan 2014 13:18:18 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFC11A0205 for ; Fri, 24 Jan 2014 13:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29282; q=dns/txt; s=iport; t=1390598297; x=1391807897; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=djV57oyYelAmdsPXkL8hpEBSdWTzTlIRmLmbGhoWmdY=; b=DZ7+eSiRQAy1YKYcVn46F3vchK5SmsBMph1xiizX6zhpEGb7Lsqwuvtv aTR1CMDro0rMjJmrHhNJaxibN4qnjujQ29eKk3Tdc4iHdpFu6yaWbws9c 9+dRa7xmSydoi5/L0UgpDO3CWMgNCaQi8hxI6turwz1jH+AI4Co7aG58l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAKPX4lKtJXHB/2dsb2JhbABagkhEOFa8NYENFnSCJQEBAQQtXAIBCBEEAQELFgEGBzIUCQgCBAESCId9yGwXjH+BPAEBGAYLAh8LAQKDIoEUBJlZkGyDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,715,1384300800"; d="scan'208,217";a="15377373" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-3.cisco.com with ESMTP; 24 Jan 2014 21:18:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0OLIGqp029490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 21:18:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 15:18:15 -0600 From: "Panos Kampanakis (pkampana)" To: "Roman D. Danyliw" , "'Moriarty, Kathleen'" , "mile@ietf.org" Thread-Topic: [mile] Documenting DomainData Thread-Index: AQHPFeZKcVHy8XjkSUe8d5nwrbpqVpqOITGAgAAOhgCABB0RoIAAFI3ggAHKzCCAADjHoA== Date: Fri, 24 Jan 2014 21:18:15 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A750FAB2C72@xmb-rcd-x10.cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC54C1665C@marathon> <359EC4B99E040048A7131E0F4E113AFC54C18CF6@marathon> <359EC4B99E040048A7131E0F4E113AFC54C1D3AA@marathon> <1C9F17D1873AFA47A969C4DD98F98A750FAB17FA@xmb-rcd-x10.cisco.com> <359EC4B99E040048A7131E0F4E113AFC54C1FF19@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C1FF19@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.107] Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A750FAB2C72xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [mile] Documenting DomainData X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 21:18:22 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A750FAB2C72xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see your point now. Yes, we need to be as specific as possible. We can format them using colons as separators as you used in your example f= ollowing a simple pattern. It can be :< TTL>::< Data> The type is dictated by the RelatedDNS attribute and the class should be as= sumed as IN. Panos From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Friday, January 24, 2014 1:03 PM To: Panos Kampanakis (pkampana); 'Moriarty, Kathleen'; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hello! I concur that RelatedDNS contains related DNS records for the domain listed= in DomainData/Name. However, I don't think we can be vague in describing = the format of RelatedDNS. The example shared by Kathleen's had the following example of a MX record. evildave.com MX prefernce =3D 10, mail = exchanger =3D mail1.evildave.com I can infer the format. However, without the draft providing guidance, the= following could have also have been acceptable (replacing evildave.com for= example.com): mail1.org1.example.com org1.example.com 4000 IN MX 10 mail1.org1.exa= mple.com org1.example.com mail1.org1.example.com @org1.example.com:10.1.2.3:mail1.org1.example= .com:0:86400:329832:0 I feel that we need to provide implementers unambiguous guidance if we expe= ct them to parse the field. Roman From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] Sent: Thursday, January 23, 2014 9:28 AM To: Roman D. Danyliw; 'Moriarty, Kathleen'; mile@ietf.org Subject: RE: [mile] Documenting DomainData I think text that says "The RelatedDNS record contain DNS records (i.e. MX,= A) that are related to the domain described in its parent DomainData class= . For example, in DomainData class for domain example.com, the RelatedDNS r= ecord could be carrying the MX record for example.com." would suffice. Panos From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Thursday, January 23, 2014 8:20 AM To: 'Moriarty, Kathleen'; mile@ietf.org Cc: Panos Kampanakis (pkampana) Subject: RE: [mile] Documenting DomainData Hi Kathleen! The example was very helpful. Thank you. For discussion purposes on the list, here is a relevant excerpt from the pr= eviously attached file: evildave.com 2013-01-04T09:10:24+00:00 evildave.com MX prefernce =3D 10, mail = exchanger =3D mail1.evildave.com mail1.evildave.com internet address =3D = 176.157.32.17 zuesevil.com. IN TXT \"v=3Dspf1 a mx -= all\" Reading this particular example, I understand what information is being pas= sed along in the DNS record. Where I need help is how do we formally descr= ibe this format for the draft. Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Wednesday, January 22, 2014 6:50 PM To: Roman D. Danyliw; mile@ietf.org Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com) Subject: RE: [mile] Documenting DomainData Hi Roman, I was able to dig up an example from the group that was proposing the addit= ion of RelatedDNS to the DomainData class that was added from RFC5901. Pan= os may have other examples planned for the IODEF Guidance document. I think as long as the data of other records can be included, the intent wi= ll be met for the requestors. See the attached example and I am sure a pro= posal that alters it, but provides the ability to include that information = would be fine. Anyone else? Thanks, Kathleen From: Roman D. Danyliw [mailto:rdd@cert.org] Sent: Monday, January 20, 2014 5:04 PM To: Moriarty, Kathleen; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hello! Understood on #1 and #3. I still need a little more clarification on your = answer to question #2, "RelatedDNS lets you add any record type to expand o= ut what is possible from the Domain data class. You can also list what typ= e of record you are including." To restate, RelatedDNS represents DNS reco= rds for a domain specified in DomainData/Name? If so, what exactly goes in= to the element content of RelatedDNS which is defined as xs:string? For ex= ample, if I had an AXFR record () how would= this be encoded? Since Node/DomainData/DateDomainWasChecked represents when Node/DomainData/= Name was resolved (where the IP address is stored in Node/Address), is ther= e a similar construct for these other record types in RelatedDNS? Roman From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Monday, January 20, 2014 8:48 AM To: Roman D. Danyliw; mile@ietf.org Subject: RE: [mile] Documenting DomainData Hi Roman, #1 I thought the answer was yes, but it would be good to hear if anyone thi= nks it is too much detail now. #2 RelatedDNS lets you add any record type to expand out what is possible f= rom the Domain data class. You can also list what type of record you are i= ncluding. #3 I don't think there is a concern in adjusting the names for consistency. Thanks, Kathleen From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Friday, January 17, 2014 9:32 PM To: mile@ietf.org Subject: [mile] Documenting DomainData Hello! Since being copied from RFC5901 into 5070bis, DomainData has evolved. Curr= ently the two definition differ as follows: ** 5070bis added DomainData@{indicator-uid, indicator-set-id} ** 5070bis added DomainData/RelatedDNS ** 5070bis uses iodef:Contact for DomainData/DomainContacts/Contact instead= of phish:Contact which added classes and attributes to Contact A few questions: (1) Since bits and pieces were added and modified in the cut-and-paste from= 5901, is there agreement that we don't need to remove anything from Domain= Data? Do we want to represent this level of detail in the core IODEF data = model? (2) RelatedDNS was added to DomainData and is not present in RFC5901. Ther= e is no descriptive text. Could someone shed light on the purpose of this = class. (3) The attributes DomainData@{SystemStatus, DomainStatus} and RelatedDNS@R= ecordType don't follow the naming convention of lower case names separated = by a hyphen. As in other cases where classes have been moved, I would be i= nclined to rename the attributes. Any concern in doing that? Roman --_000_1C9F17D1873AFA47A969C4DD98F98A750FAB2C72xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see your point now. = Yes, we need to be as specific as possible.

 

We can format them usi= ng colons as separators as you used in your example following a simple patt= ern.  It can be

 

<owner>:<<= /span> TTL>:<MX Level>:< Data>

 

The type is dictated b= y the RelatedDNS attribute and the class should be assumed as IN.

 

Panos

 

 

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Friday, January 24, 2014 1:03 PM
To: Panos Kampanakis (pkampana); 'Moriarty, Kathleen'; mile@ietf.org=
Subject: RE: [mile] Documenting DomainData

 

Hello!

 

I concur that RelatedD= NS contains related DNS records for the domain listed in DomainData/Name.&n= bsp; However, I don’t think we can be vague in describing the format = of RelatedDNS.

 

The example shared by = Kathleen’s had the following example of a MX record.

 

<iodef:RelatedDNS R= ecordType=3D"MX">evildave.com MX prefernce =3D 10, mail exchan= ger =3D mail1.evildave.com</iodef:RelatedDNS>

 

I can infer the format= .  However, without the draft providing guidance, the following could = have also have been acceptable (replacing evildave.com for example.com):

 

<RelatedDNS RecordT= ype=3D"MX">mail1.org1.example.com</RelatedDNS>

<RelatedDNS RecordT= ype=3D"MX">org1.example.com 4000 IN MX 10 mail1.org1.example.c= om</RelatedDNS>

<RelatedDNS RecordT= ype=3D"MX">org1.example.com mail1.org1.example.com</Related= DNS>

<RelatedDNS RecordT= ype=3D"MX">@org1.example.com:10.1.2.3:mail1.org1.example.com:0= :86400:329832:0</RelatedDNS>

 

I feel that we need to= provide implementers unambiguous guidance if we expect them to parse the f= ield.

 

Roman

 

From: Panos Ka= mpanakis (pkampana) [mailto:pkampana@= cisco.com]
Sent: Thursday, January 23, 2014 9:28 AM
To: Roman D. Danyliw; 'Moriarty, Kathleen'; mile@ietf.org
Subject: RE: [mile] Documenting DomainData

 

I think text that says= “The RelatedDNS record contain DNS records (i.e. MX, A) that are rel= ated to the domain described in its parent DomainData class. For example, i= n DomainData class for domain example.com, the RelatedDNS record could be carrying the MX record for example.com.R= 21; would suffice.

Panos

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Thursday, January 23, 2014 8:20 AM
To: 'Moriarty, Kathleen'; mile@ietf= .org
Cc: Panos Kampanakis (pkampana)
Subject: RE: [mile] Documenting DomainData

 

Hi Kathleen!

 

The example was very h= elpful.  Thank you.

 

For discussion purpose= s on the list, here is a relevant excerpt from the previously attached file= :

<iodef:DomainData&g= t;

<iodef:Name>evil= dave.com</iodef:Name>

<iodef:DateDomainWa= sChecked>2013-01-04T09:10:24+00:00</iodef:DateDomainWasChecked>= ;

<iodef:RelatedDNS R= ecordType=3D"MX">evildave.com MX prefernce =3D 10, mail exchan= ger =3D mail1.evildave.com</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"A">mail1.evildave.com internet address =3D 176.15= 7.32.17</iodef:RelatedDNS>

<iodef:RelatedDNS R= ecordType=3D"SPF">zuesevil.com. IN TXT \"v=3Dspf1 a mx &#= 8211;all\"</iodef:RelatedDNS>

</iodef:DomainData&= gt;

 

Reading this particula= r example, I understand what information is being passed along in the DNS r= ecord.  Where I need help is how do we formally describe this format f= or the draft. 

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.mo= riarty@emc.com]
Sent: Wednesday, January 22, 2014 6:50 PM
To: Roman D. Danyliw; mile@ietf.org=
Cc: 'Panos Kampanakis (pkampana)' (pkampana@cisco.com)
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

I was able to dig up a= n example from the group that was proposing the addition of RelatedDNS to t= he DomainData class that was added from RFC5901.  Panos may have other= examples planned for the IODEF Guidance document.

 

I think as long as the= data of other records can be included, the intent will be met for the requ= estors.  See the attached example and I am sure a proposal that alters= it, but provides the ability to include that information would be fine.

 

Anyone else?

 

Thanks,

Kathleen

 

 

From: Roman D.= Danyliw [mailto:rdd@cert.org]
Sent: Monday, January 20, 2014 5:04 PM
To: Moriarty, Kathleen; mile@ietf.o= rg
Subject: RE: [mile] Documenting DomainData

 

Hello!

 

Understood on #1 and #= 3.  I still need a little more clarification on your answer to questio= n #2, “RelatedDNS lets you add any record type to expand out what is = possible from the Domain data class.  You can also list what type of record you are including.”  To restate, Relat= edDNS represents DNS records for a domain specified in DomainData/Name?&nbs= p; If so, what exactly goes into the element content of RelatedDNS which is= defined as xs:string?  For example, if I had an AXFR record (<RelatedDNS RecordType=3D”AXRF”>) how would= this be encoded?

 

Since Node/DomainData/= DateDomainWasChecked represents when Node/DomainData/Name was resolved (whe= re the IP address is stored in Node/Address), is there a similar construct = for these other record types in RelatedDNS?

 

Roman

 

From: Moriarty= , Kathleen [mailto:kathleen.mo= riarty@emc.com]
Sent: Monday, January 20, 2014 8:48 AM
To: Roman D. Danyliw; mile@ietf.org=
Subject: RE: [mile] Documenting DomainData

 

Hi Roman,

 

#1 I thought the answe= r was yes, but it would be good to hear if anyone thinks it is too much det= ail now.

 

#2 RelatedDNS lets you= add any record type to expand out what is possible from the Domain data cl= ass.  You can also list what type of record you are including.

 

#3 I don’t think= there is a concern in adjusting the names for consistency.

 

Thanks,

Kathleen

 

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Friday, January 17, 2014 9:32 PM
To: mile@ietf.org
Subject: [mile] Documenting DomainData

 

Hello!

 

Since being copied from RFC5901 into 5070bis, Domain= Data has evolved.  Currently the two definition differ as follows:

 

** 5070bis added DomainData@{indicator-uid, indicato= r-set-id}

** 5070bis added DomainData/RelatedDNS

** 5070bis uses iodef:Contact for DomainData/DomainC= ontacts/Contact instead of phish:Contact which added classes and attributes= to Contact

 

A few questions:

 

(1) Since bits and pieces were added and modified in= the cut-and-paste from 5901, is there agreement that we don’t need t= o remove anything from DomainData?  Do we want to represent this level= of detail in the core IODEF data model?

 

(2) RelatedDNS was added to DomainData and is not pr= esent in RFC5901.  There is no descriptive text.  Could someone s= hed light on the purpose of this class.

 

(3) The attributes DomainData@{SystemStatus, DomainS= tatus} and RelatedDNS@RecordType don't follow the naming convention of lowe= r case names separated by a hyphen.  As in other cases where classes h= ave been moved, I would be inclined to rename the attributes.  Any concern in doing that?

 

Roman

--_000_1C9F17D1873AFA47A969C4DD98F98A750FAB2C72xmbrcdx10ciscoc_-- From trevorf@exchange.microsoft.com Fri Jan 24 18:24:23 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7871A044F for ; Fri, 24 Jan 2014 18:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VAGEKkbvXpX for ; Fri, 24 Jan 2014 18:24:20 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) by ietfa.amsl.com (Postfix) with ESMTP id B3C8B1A02A5 for ; Fri, 24 Jan 2014 18:24:20 -0800 (PST) Received: from CH1SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.157.19) by BY2SR01MB597.namsdf01.sdf.exchangelabs.com (10.255.93.165) with Microsoft SMTP Server (TLS) id 15.0.873.2; Sat, 25 Jan 2014 00:49:39 +0000 Received: from SN2FFOFD002.ffo.gbl (157.55.158.26) by CH1SR01CA102.outlook.office365.com (10.255.157.19) with Microsoft SMTP Server (TLS) id 15.0.873.2 via Frontend Transport; Sat, 25 Jan 2014 00:49:38 +0000 Received: from hybrid.exchange.microsoft.com (131.107.159.100) by SN2FFOFD002.mail.o365filtering.com (10.111.201.21) with Microsoft SMTP Server (TLS) id 15.0.868.6 via Frontend Transport; Sat, 25 Jan 2014 00:49:38 +0000 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.26; Fri, 24 Jan 2014 16:49:13 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) with Microsoft SMTP Server (TLS) id 15.0.847.21; Fri, 24 Jan 2014 16:49:12 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.68]) with mapi id 15.00.0847.008; Fri, 24 Jan 2014 16:49:12 -0800 From: Trevor Freeman To: "mile@ietf.org" Thread-Topic: Validating the Schema of IODEF documents with Encrypted Classes Thread-Index: Ac8ZZsNdIzCvit/6S56GXQXQDBCO7g== Date: Sat, 25 Jan 2014 00:49:11 +0000 Message-ID: <45ec0e27391c4354aa263a85f0eec8a3@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_45ec0e27391c4354aa263a85f0eec8a3DFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.159.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(189002)(199002)(80022001)(84326002)(87266001)(85306002)(20776003)(63696002)(19580395003)(6806004)(56776001)(54316002)(76482001)(44976005)(81686001)(81816001)(2656002)(80976001)(66066001)(83322001)(93136001)(87936001)(93516002)(76786001)(56816005)(76796001)(19300405004)(76176001)(65816001)(90146001)(83072002)(77096001)(77982001)(85852003)(47736001)(79102001)(92566001)(59766001)(53806001)(51856001)(69226001)(16236675003)(54356001)(512954002)(15202345003)(46102001)(74706001)(49866001)(81342001)(81542001)(31966008)(47446002)(33646001)(47976001)(74662001)(74502001)(50986001)(71186001)(15975445006)(74876001)(4396001)(74366001)(94316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB597; H:hybrid.exchange.microsoft.com; CLIP:131.107.159.100; FPR:2F52F214.3EC68B8E.69DCBEF7.5AD5EE60.2017F; InfoDomainNonexistentMX:1; A:1; LANG:en; X-Forefront-PRVS: 01026E1310 X-OriginatorOrg: exchange.microsoft.com Subject: [mile] Validating the Schema of IODEF documents with Encrypted Classes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 02:24:24 -0000 --_000_45ec0e27391c4354aa263a85f0eec8a3DFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looking at the guidance in RFC6545 in section 9.1, it would appear to suppo= rt encrypting classes in IODEF documents where the restriction =3D private. 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= . However, if I do that, the XML validation of the document fails unless I pe= rform it after decrypting the class and putting humpty back together again. Has anyone else had the same problem? So far, the only fix I have come up with is tweeking the schema of classes = I want to encrypt. Trevor --_000_45ec0e27391c4354aa263a85f0eec8a3DFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looking at the guidance in RFC6545 in section 9.1, i= t would appear to support encrypting classes in IODEF documents where the r= estriction =3D private.

 

If restriction is set to ’private’, t= he class or document MUST be encrypted for the recipient using XML encrypti= on and the public key of the recipient.

 

However, if I do that, the XML validation of the doc= ument fails unless I perform it after decrypting the class and putting hump= ty back together again.

 

Has anyone else had the same problem?

 

So far, the only fix I have come up with is tweeking= the schema of classes I want to encrypt.

 

<xs:group name=3D"Cl= assChoice">

    <xs:choic= e>

        <xs:element ref=3D"iod= ef:Class"/>

        <xs:eleme= nt name=3D"EncryptedClass" = type=3D"xenc:EncryptedDataType"= />

    </xs:choi= ce>

</xs:group><= o:p>

 

Trevor

--_000_45ec0e27391c4354aa263a85f0eec8a3DFMTK5MBX1505exchangeco_-- From rdd@cert.org Mon Jan 27 09:56:11 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2571A027B for ; Mon, 27 Jan 2014 09:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r00USEzif9c7 for ; Mon, 27 Jan 2014 09:56:08 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id E92921A024C for ; Mon, 27 Jan 2014 09:56:07 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0RHu2G4005733; Mon, 27 Jan 2014 12:56:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390845362; bh=Nf9CHoANSp2OIo5161ZMkmeUvX+8NM72YBGiegguCAU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=a49VpTUWhW7nBIJsnD4DMiSnplPjWfYJN/BLlDEVwxjGE6yQ7lsF2hjgJHL6gCjPp QYh58Pad65oggYYsow32fPFmuIGJlvIg8ZNvbAdyvg/4V0wqx7ynclli9PofPoCTQp Gqcx2c27WDMlMOhUuOZQyk/y41B6azwn9aVn13nE= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0RHu27Y005947; Mon, 27 Jan 2014 12:56:02 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Mon, 27 Jan 2014 12:56:02 -0500 From: "Roman D. Danyliw" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: Addressing 5070bis schema comments (Issue #21) Thread-Index: Ac8XI/SP77e+P50aTEqEDMQDNw/g0wAZYTAQAPzLOEA= Date: Mon, 27 Jan 2014 17:56:01 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C21D36@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C1ABD5@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Addressing 5070bis schema comments (Issue #21) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2014 17:56:11 -0000 Hello Kathleen, I've added inline comments for questions #1, 4, and 8. In the interest of = future readability, I kept the entire thread. Roman > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Wednesday, January 22, 2014 7:08 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: Addressing 5070bis schema comments (Issue #21) >=20 > Hi Roman, >=20 > I'll answer in-line with KM> and using +1 where appropriate. Others, ple= ase > chime in! >=20 > Some of the questions were off-list in a group testing interoperability o= f > implementations and working against use cases. Some were questions to > track options and can just be removed. I tried to look up what I could a= nd jog > my memory for other questions. >=20 > Thanks, > Kathleen >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Tuesday, January 21, 2014 11:25 PM > To: mile@ietf.org > Subject: [mile] Addressing 5070bis schema comments (Issue #21) >=20 > Good evening! >=20 > Issue #21 is tracking the need to either act on or delete various questio= ns > noted in the 5070bis schema. This note is intended to call out each of t= hese > comments and open the discussion on what to do. >=20 > With all of the snippets of text presented here for clarity, my > recommendations are noted as "RD" so it's easier to follow along when oth= ers > add their thinking. >=20 > (1) In Reference class: >=20 > " >=20 > (RD) I'm not sure what the first question is asking as Reference has both= an > @indicator-set-id and @indicator-uid. To the second question, using > indicator-uid in a way limit with whom to share information is a use case= I > haven't seen previously documented. Could the interested/originating par= ty > please clarify. >=20 > KM> Unfortunately, this was a discussion outside of mailing lists. I thi= nk this > may have to do with the walls needed within a product when you share with > multiple groups. If an indicator_UID is from a particular source, you ma= y have > to restrict access to team members of one organization where some may not > have approved access for some data (clearance levels, privacy information= , > human resources sensitivity, etc.). RD> Is there something that needs to be done in the document or is it an i= mplementation detail? I'd like to either decide whether we can remove the = comment with no action or whether a discussion needs to be started to clari= fy the way ahead. If there is an action, then I'd recommend casting the di= scussion in terms of the other issues posed with defining the @indicator-ui= d and @indicator-set-id attributes in http://www.ietf.org/mail-archive/web/= mile/current/msg01299.html. > (2) In Impact@type: >=20 > "" >=20 > (RD) While multiple attributes can't occur in a single class, multiple in= stances > of Impact are possible in a single instance of Assessment. I would recom= mend > that this is sufficient and to delete this comment. > KM> +1 >=20 > (3) In Flow > "" >=20 > (RD) This comment notes a change in the data model. However, the modelin= g > flexibility this change is intended to support is not documented. This i= s an > action. > KM> +1 on the action. >=20 > (4) In Service > " " >=20 > (RD) An known, issue. Whether we need to place in the same class to > represent email information was posed to the list, http://www.ietf.org/ma= il- > archive/web/mile/current/msg01275.html. > KM> OK, so this decision is tracked elsewhere... RD> No decision has been made. This link posed the question to the group. = Does anyone have thoughts on the matter? As I noted in the link, it is my= opinion that we need to have only one place to describe this information. = Service/EmailInfo currently provides the most flexibility. > (5) In EmailInfo > " >=20 > (RD) I don't understand which class the pronoun "this" is referencing to > reason about whether it should be divided into multiple classes. Could th= e > interested/originating party please clarify. > KM> I think there was no interest in additional changes and that folks we= re > happy with the current proposal, meaning you can just delete the comment. >=20 > (7) In HashInformation > "" >=20 > (RD) I would recommend it. By adding AdditionalData, an extension could > add richer file information. Supporting this richer information is track= ed as > Issue #23. > KM> +1 >=20 > (8) In HashInformation@type > "" >=20 > (RD) I don't appreciate the issue here. Could the interested/originating= party > please clarify. > KM> I think this might be referring to key types, like X.509 or PGP, but = I > believe that is covered in ds: RD> Just to clarify, there is no action here and the comment can be deleted= ? =20 > (9) In SoftwareType > "" >=20 > (RD) I recommend having a separate discussion on how to best represent it= . > For example, HTTPUserAgent could also be represented as in > Service/ApplicationHeader. > KM> +1 on separate discussion >=20 > I hope that helps! > Kathleen >=20 > Roman Roman > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From rdd@cert.org Mon Jan 27 12:22:10 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B611A029F for ; Mon, 27 Jan 2014 12:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNSxF2VCJ69e for ; Mon, 27 Jan 2014 12:22:08 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 621AC1A029E for ; Mon, 27 Jan 2014 12:22:08 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0RKM5eV001614 for ; Mon, 27 Jan 2014 15:22:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390854125; bh=RblRA2qkDJ+W4mOAUreRhTTqCC1uzZ3sJ3xIFf+sk1U=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=GJTa8cYbS2GHDeBgI+NNUFUefu1fAS3je5O6fKhdb7poN1TlnzfPizi7NUZkFIbrf 6J4vGTHU6tYiWpAtZ3CTHBmCswHcWWpB2lpIyodn6dGKzPU9y4jyB8PhQHrREPdPMF 4EB279X66jh4vDTIBrETR4RdsPkw+Z1FuO3XwQA8= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0RKM8Pe028911 for ; Mon, 27 Jan 2014 15:22:08 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Mon, 27 Jan 2014 15:22:05 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: @user-agent attribute Thread-Index: Ac8biaIgVu/GOVUOSzWtoBMbCPiZdg== Date: Mon, 27 Jan 2014 20:22:04 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C222A1@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] @user-agent attribute X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2014 20:22:10 -0000 Hello! The -04 schema of 5070bis has the following comment in the definition of @u= ser-agent in the Application and OperatingSystem classes. =20 [begin comment] "" [end comment] SoftwareType is the complexType used to define System/Application and Servi= ce/OperatingSystem. Lacking documentation in the text and going only on th= e name in the schema, it would appear that this attribute is attempting to = describe the "User-Agent" HTTP field per Section 14.43 of RFC2616. If ther= e is a broader definition, could someone please talk us through it. With the addition of the Service/ApplicationHeader there appear to be two w= ays to represent a User-Agent. Consider the following XML snippet below: ... ... M= ozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gec= ko) Chrome/32.0.1667.0 Safari/537.36 ... something A few questions: ** Does the data model need the @user-agent attribute if ApplicationHeader = can model it? ** Could @swid (defined as "An identifier that can be used to reference thi= s software") be used for a User-Agent? ** What implementation guidance should be given about how @user-agent shoul= d be set with Service/OperatingSystem? To share my own bias, the Application and OperatingSystem Class are current= ly very poorly specified. I don't think we should continue improving them.= Instead, we should reference software through CPE (http://nvd.nist.gov/cp= e.cfm) or similar effort as is possible through the SCI-defined class Platf= orm. For the time being, I would drop @user-agent. Roman From rdd@cert.org Mon Jan 27 13:51:39 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22041A02DC for ; Mon, 27 Jan 2014 13:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHD6oainNhZv for ; Mon, 27 Jan 2014 13:51:37 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 654A11A008F for ; Mon, 27 Jan 2014 13:51:37 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0RLpYZ2003647 for ; Mon, 27 Jan 2014 16:51:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390859495; bh=z+q71uf5ostOgX1sAjTNgQFkvz7efeogLP6ruMxv974=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=AmpvRooI/IprOK0le7/UNwYk8Vm9T+HIUtPqK/Dg5CIE8tOysYrU/NG0LnuhAVrlk OO74yFxdVwiBgV5Y2YIH4TCgrcwLp3yT3WZLijGxHEZWor1C/kd+AWAOmqhU/CScvR OQmz7QOwPnB/zDefXCvEGj2YAFVwWzIhOOi+1jJg= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0RLpbmO004697 for ; Mon, 27 Jan 2014 16:51:37 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Mon, 27 Jan 2014 16:51:34 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: Consistency in classes suffixes Thread-Index: Ac8bqE74zt3UvA4dRxO4+mmGkDlQdg== Date: Mon, 27 Jan 2014 21:51:33 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C2264F@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] Consistency in classes suffixes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2014 21:51:39 -0000 Hello! By organic convention, we have a number of a classes that end with the suff= ix "Data" -- EventData, DomainData, RecordData, and AdditionalData. We've = added a few classes with the suffix "Information" or "Info" -- HashInformat= ion, EmailInfo, and reused ds:KeyInfo. For naming consistency, I would recommend renaming these classes as follows= : ** HashInformation --> HashData, that said, the class represents both signa= tures and hashes so perhaps there is an more descriptive name? ** EmailInfo --> EmailData or Email How does the community feel about this change? Roman From kathleen.moriarty@emc.com Mon Jan 27 14:33:55 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92501A03D8 for ; Mon, 27 Jan 2014 14:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJlD6cMgExxE for ; Mon, 27 Jan 2014 14:33:54 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id C96B81A03D2 for ; Mon, 27 Jan 2014 14:33:53 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0RMXlqI021388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jan 2014 17:33:48 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s0RMXlqI021388 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390862028; bh=GRClNlIkTfIWstwqhb0VZKa5+NU=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=JKZPINH5aoinYV3FkuX4KMPehTD14YzpJrnziavFkS9Vea2C0RegjMBKlIGgDRlxa d0KQbRxwcof4Rr+Fyjo2YDZHYqVeSNUeASmfGyDGK7AHHCNX9OXBu1mbQ/YfrVerlF CRUn+9civ8sDmx9RTJMU7MBGokckQLEhAkrGDLXM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s0RMXlqI021388 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 27 Jan 2014 17:33:33 -0500 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0RMXWl1009812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 17:33:33 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Mon, 27 Jan 2014 17:33:32 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Mon, 27 Jan 2014 17:33:30 -0500 Thread-Topic: Consistency in classes suffixes Thread-Index: Ac8bqE74zt3UvA4dRxO4+mmGkDlQdgAB2+sQ Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C2264F@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C2264F@marathon> 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-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] Consistency in classes suffixes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2014 22:33:55 -0000 +1 I am fine with the change, others? -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Monday, January 27, 2014 4:52 PM To: mile@ietf.org Subject: [mile] Consistency in classes suffixes Hello! By organic convention, we have a number of a classes that end with the suff= ix "Data" -- EventData, DomainData, RecordData, and AdditionalData. We've = added a few classes with the suffix "Information" or "Info" -- HashInformat= ion, EmailInfo, and reused ds:KeyInfo. For naming consistency, I would recommend renaming these classes as follows= : ** HashInformation --> HashData, that said, the class represents both signa= tures and hashes so perhaps there is an more descriptive name? ** EmailInfo --> EmailData or Email How does the community feel about this change? Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Mon Jan 27 14:40:54 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72DE1A03DF for ; Mon, 27 Jan 2014 14:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyJ0S63qNkcd for ; Mon, 27 Jan 2014 14:40:52 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 82B6B1A03D8 for ; Mon, 27 Jan 2014 14:40:52 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0RMelWm020976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jan 2014 17:40:48 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s0RMelWm020976 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1390862448; bh=+lEco7PXe3M1KPFRIkCvuEUMg+0=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=M+wJRAfXZPxP21Oerzppo8EgF6BcDHGnOLVHtrpB/bBM+8JVFCh4PGdkS1KcInO60 yE1Gfxytq7x6M8EZ/xYWCQ0KQ4DSNwDZo3bTlRE330XMCIuIrbfazbki8O6ruEHmsz Yhsp3ifblog9Z+0JsDQHa54M6gsosm4I6MzvdCTI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s0RMelWm020976 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 27 Jan 2014 14:40:29 -0800 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0RMeSQs013194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 17:40:29 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Mon, 27 Jan 2014 17:40:28 -0500 From: "Moriarty, Kathleen" To: "Roman D. Danyliw" , "mile@ietf.org" Date: Mon, 27 Jan 2014 17:40:27 -0500 Thread-Topic: @user-agent attribute Thread-Index: Ac8biaIgVu/GOVUOSzWtoBMbCPiZdgAJwBNw Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC54C222A1@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C222A1@marathon> 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-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Subject: Re: [mile] @user-agent attribute X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2014 22:40:55 -0000 CPE isn't funded anymore and may get folded in SWID. I don't have the late= st on this, but would not want to rely on something that may go away. Is a= nyone aware of the latest on CPE? Thanks, Kathleen -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Monday, January 27, 2014 3:22 PM To: mile@ietf.org Subject: [mile] @user-agent attribute Hello! The -04 schema of 5070bis has the following comment in the definition of @u= ser-agent in the Application and OperatingSystem classes. =20 [begin comment] "" [end comment] SoftwareType is the complexType used to define System/Application and Servi= ce/OperatingSystem. Lacking documentation in the text and going only on th= e name in the schema, it would appear that this attribute is attempting to = describe the "User-Agent" HTTP field per Section 14.43 of RFC2616. If ther= e is a broader definition, could someone please talk us through it. With the addition of the Service/ApplicationHeader there appear to be two w= ays to represent a User-Agent. Consider the following XML snippet below: ... ... M= ozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gec= ko) Chrome/32.0.1667.0 Safari/537.36 ... something A few questions: ** Does the data model need the @user-agent attribute if ApplicationHeader = can model it? ** Could @swid (defined as "An identifier that can be used to reference thi= s software") be used for a User-Agent? ** What implementation guidance should be given about how @user-agent shoul= d be set with Service/OperatingSystem? To share my own bias, the Application and OperatingSystem Class are current= ly very poorly specified. I don't think we should continue improving them.= Instead, we should reference software through CPE (http://nvd.nist.gov/cp= e.cfm) or similar effort as is possible through the SCI-defined class Platf= orm. For the time being, I would drop @user-agent. Roman _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From eburger@standardstrack.com Mon Jan 27 14:56:23 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A821A03DE for ; Mon, 27 Jan 2014 14:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.377 X-Spam-Level: * X-Spam-Status: No, score=1.377 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_27=0.6, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yafoXDNOS6z5 for ; Mon, 27 Jan 2014 14:56:22 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE4F1A03A5 for ; Mon, 27 Jan 2014 14:56:22 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:49718 helo=[192.168.15.101]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1W7v6G-0002pa-Jg for mile@ietf.org; Mon, 27 Jan 2014 14:56:18 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: Date: Mon, 27 Jan 2014 17:56:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC54C2264F@marathon> To: "mile@ietf.org" X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [mile] Consistency in classes suffixes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2014 22:56:23 -0000 +1=20 On Jan 27, 2014, at 5:33 PM, Moriarty, Kathleen = wrote: > +1 I am fine with the change, others? >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. = Danyliw > Sent: Monday, January 27, 2014 4:52 PM > To: mile@ietf.org > Subject: [mile] Consistency in classes suffixes >=20 > Hello! >=20 > By organic convention, we have a number of a classes that end with the = suffix "Data" -- EventData, DomainData, RecordData, and AdditionalData. = We've added a few classes with the suffix "Information" or "Info" -- = HashInformation, EmailInfo, and reused ds:KeyInfo. >=20 > For naming consistency, I would recommend renaming these classes as = follows: > ** HashInformation --> HashData, that said, the class represents both = signatures and hashes so perhaps there is an more descriptive name? > ** EmailInfo --> EmailData or Email >=20 > How does the community feel about this change? >=20 > Roman > _______________________________________________ > 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 rdd@cert.org Mon Jan 27 18:25:25 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8FE1A008F for ; Mon, 27 Jan 2014 18:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.101 X-Spam-Level: X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW7wQ6Jq8GBr for ; Mon, 27 Jan 2014 18:25:21 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 20B891A03C9 for ; Mon, 27 Jan 2014 18:25:20 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0S2PI3J017859 for ; Mon, 27 Jan 2014 21:25:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390875918; bh=nFb9ma+lMWm5BN8Zsq1M0pwXPIFzbgVIhbLePml73D0=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=GclarQo4MzOIvVnz+zUvmk+vZzUHG0/fDUBLq1lGdfhweAs/HJ/aheQr+DASnax/m n0xMbmsyj6gNNfwFI1GQclk5D1NefA1nYACq6T6BZFZhEnC3hVoK/cQlcnZCf9qXn/ RHhxcw/7ZKuDuQ3534hLG6fDizaA30XIS5SkXg3A= Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0S2PIwL017661 for ; Mon, 27 Jan 2014 21:25:18 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Mon, 27 Jan 2014 21:25:17 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] Clarity on HashInformation (or HashSigDetails) Thread-Index: Ac6SzRlNePRSckhET9GSnx9zRKUk8gAD4JpQAA5ZM7AAFXvtNgAA2w8gAAA8aTEAAGjNQAAHVf1gABNk8IAAAQ1DAAArwj+AHQBhoKAEzfVHYA== Date: Tue, 28 Jan 2014 02:25:16 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C2291D@marathon> References: <359EC4B99E040048A7131E0F4E113AFC13C5C39E@marathon> <359EC4B99E040048A7131E0F4E113AFC13C5C625@marathon> <1C9F17D1873AFA47A969C4DD98F98A750484EE88@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F232@xmb-rcd-x10.cisco.com> <1C9F17D1873AFA47A969C4DD98F98A750484F566@xmb-rcd-x10.cisco.com>, <359EC4B99E040048A7131E0F4E113AFC54C01481@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C01481@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] Clarity on HashInformation (or HashSigDetails) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:25:25 -0000 Hello! I'm again reposting this email and noting inline the items that still need = to be discussed for HashInformation. I've added two new issues as well. R= emoved from this discuss is matter of defining the behavior of HashInformat= ion@valid. See http://www.ietf.org/mail-archive/web/mile/current/msg01161.= html or Issue #26. [snip] > > > > -----Original Message----- > > > > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On > > > > Behalf Of Roman D. Danyliw > > > > Sent: Tuesday, August 06, 2013 4:33 PM > > > > To: mile@ietf.org > > > > Subject: [mile] Clarity on HashInformation (or HashSigDetails) > > > > > > > > Hello! > > > > > > > > I had a few questions about the HashInformation (HashSigDetails) > > > > class that > > > I wanted to discuss. [snip] > > > > =3D=3D=3D=3D=3D > > > > (6) What HashInformation@type should be used to convey a TLS > > > certificate? > > > > > > > > From > > > > http://www.ietf.org/mail-archive/web/mile/current/msg01148.html, > > > it was indicated that a TLS certificate or certificate chain could > > > be provided as an indicator. Let's say it was related to a web-serve= r. > > > What enumerate value should be used for the @type? > > > > > > > > PK> I was under the impression that ds:Signature or ds:KeyInfo > > > > PK> with ds:Reference could express certs for XML sigs in > > > > PK> http://www.w3.org/2000/09/xmldsig# > > > > KM> +1. The thinking was to use KeyInfo as you can refernce this > > > > KM> +and other > > > > points directly within the W3C schema and it is already in a > > > > number of > > > libraries. The other reason for using this is that it would be > > > maintained by the W3C and experts in that area. As their work > > > evolves, we can continue to point to it and have up-to-date > > > capabilities without having to keep up on their developments or > > > re-work > > the wheel. RD> I'm not disputing that ds:Signature and ds:Keyinfo can represent a cert= ification. However, I am wondering what the enumerated value of the @type = attribute would be if one passed such an indicator. Likewise, what would F= ileName and FileSize mean in this context? > > > > =3D=3D=3D=3D=3D > > > > (7) What is the minimum contents of HashInformation? > > > > > > > > Under the present definition of the HashInformation class, the > > > > following > > > blank definition is legal: > > > > > > > > > > > > > > > > > > > > All the attributes and elements are optional in the schema and no > > > > further > > > parsing logic is defined in the text. Do we want to make any of > > > contents mandatory? > > > > I think type should be required and either Signature or Reference > > > > should > > > also exist once. > > > > > > > > > > > > ** Does the choice of a particular @type value mandate a > > > > particular set of classes be used? For example, if > > > > @type=3D"PKI_email_ds" is set, can any guidance about whether > > > > ds:Reference, ds:Signature, or ds:KeyInfo > > > > PK> I think we can't be sure about it. > > > > KM> +1. In working through examples, I think we had come up with > > > > KM> +reasons to > > > > use a few options. This may depend on just needing the hash > > > > information > > > > (ds:Reference) or in other cases, you want the CA chaining > > > > information, so > > > you use ds:KeyInfo, or if you have even more detail, you start from > > > ds:Signature. RD> IMO, if the @type attribute dictates how ds:Keyinfo, ds:Signature, and = ds:Reference should be interpreted, we need to provide specific guidance on= a what they mean on a per enumerated value basis. Otherwise, we are left = in the situation described above where an empty HashInformation or HashInf= ormation@type=3D"PKI_email_ds"/ds:Signature/ds:KeyInfo/ds:PGPData are valid= . > > > > ** If any of the values of @type with email in them are chosen, > > > > and a > > > FileName is provided, what does that mean? For example: > > > > > > > > my- > > file > > > > ... > > > > > > > > > > > > PK> I think that should be illegal. Only file ds should have filena= mes. > > > > Maybe for email we can have the "Filename" depict the email subject= . > > > > KM> +1 - except - do we need to have filename outside of the > > > > KM> +container in > > > > case there is no signature? RD> This question highlights a bit of an inconsistency for me. HashInforma= tion is the only place to list filenames and associated hashes and signatur= es in a well-defined way. However, this class also has support for email h= ashes and signatures, but not any other email information. Email indicator= s that aren't hashes or signatures are listed in Services/EmailInfo. Does = that make sense to split email information in this ways? =20 Brainstorming for a minute, would it make sense to have a multiple containe= r classes, perhaps one for email and the other for files. In each of these= would be file/email specific information as well as the hash or signature = information. For example, add a stripped down version of HashInformation w= ith just ds:{Signature,KeyInfo,Reference} and @type=3D"*-email-*" to EmailI= nfo. An equivalent could be made for file information. [snip] (9) The text of HashInformation@type=3D"file-hash" reads "a file hash". Do= we need to say something about how this hash is computed? Perhaps "a hash= of the contents of the file". (10) Same as #9, but on an email. The text of HashInformation@type=3D"emai= l-hash" reads "an email hash". Which part of the email? Do we need to say= something about how this hash is computed? From rdd@cert.org Mon Jan 27 18:44:45 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7FB1A0176 for ; Mon, 27 Jan 2014 18:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU0XO9wWvPJq for ; Mon, 27 Jan 2014 18:44:43 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id C878F1A008F for ; Mon, 27 Jan 2014 18:44:42 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0S2icp8007801; Mon, 27 Jan 2014 21:44:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1390877078; bh=bh34L7cuXTH70HW8yiI7k0m3TzkTurtsntxaOETmAs8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=ABs8eMM8oczI9L43WY1rSqNFoRjhS2TudWIjcditdqxvL67xKqa0MWqNc0pcslVAz esCcZKdU93lH2x/bLssvFI1pSqZlJ7Kt96UYELSTAPSmvF70s/Jeeq0U+yfeccOniN eNVXEOloT4LFkzvGPQ/D27j9YJwvk2XpgwzhqJX0= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0S2ieHW026810; Mon, 27 Jan 2014 21:44:40 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Mon, 27 Jan 2014 21:44:37 -0500 From: "Roman D. Danyliw" To: "Moriarty, Kathleen" , "mile@ietf.org" Thread-Topic: @user-agent attribute Thread-Index: Ac8biaIgVu/GOVUOSzWtoBMbCPiZdgAJwBNwAAfrDWA= Date: Tue, 28 Jan 2014 02:44:36 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C229CF@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C222A1@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mile] @user-agent attribute X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:44:45 -0000 I can't speak to the latest on any of these projects, so I defer to those t= hat are tracking their future more closely. =20 We're definitely are going to need to provide a lot more guidance on what c= onstitutes a {Application,OperatingSystem}@swid, @configid, @vendor, @famil= y, @name, @version or @patch moving forward. The current description of th= ese attributes simply restates their name in a phrase. Roman > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Monday, January 27, 2014 5:40 PM > To: Roman D. Danyliw; mile@ietf.org > Subject: RE: @user-agent attribute >=20 > CPE isn't funded anymore and may get folded in SWID. I don't have the la= test > on this, but would not want to rely on something that may go away. Is > anyone aware of the latest on CPE? >=20 > Thanks, > Kathleen >=20 > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Monday, January 27, 2014 3:22 PM > To: mile@ietf.org > Subject: [mile] @user-agent attribute >=20 > Hello! >=20 > The -04 schema of 5070bis has the following comment in the definition of > @user-agent in the Application and OperatingSystem classes. >=20 > [begin comment] > "" > [end comment] >=20 > SoftwareType is the complexType used to define System/Application and > Service/OperatingSystem. Lacking documentation in the text and going onl= y > on the name in the schema, it would appear that this attribute is attempt= ing > to describe the "User-Agent" HTTP field per Section 14.43 of RFC2616. If= there > is a broader definition, could someone please talk us through it. >=20 > With the addition of the Service/ApplicationHeader there appear to be two > ways to represent a User-Agent. Consider the following XML snippet below= : >=20 > ... > > ... dtype=3D"string">Mozilla/5.0 (Windows NT 6.2; Win64; x64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 > Safari/537.36 >=20 > ... user-agent=3D"Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36" version=3D"32.0.116= 67"> > something >=20 > A few questions: > ** Does the data model need the @user-agent attribute if ApplicationHeade= r > can model it? > ** Could @swid (defined as "An identifier that can be used to reference t= his > software") be used for a User-Agent? > ** What implementation guidance should be given about how @user-agent > should be set with Service/OperatingSystem? >=20 > To share my own bias, the Application and OperatingSystem Class are > currently very poorly specified. I don't think we should continue improv= ing > them. Instead, we should reference software through CPE > (http://nvd.nist.gov/cpe.cfm) or similar effort as is possible through th= e SCI- > defined class Platform. For the time being, I would drop @user-agent. >=20 > Roman > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From athiasjerome@gmail.com Mon Jan 27 22:24:48 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE111A019D for ; Mon, 27 Jan 2014 22:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7iY8hnstavr for ; Mon, 27 Jan 2014 22:24:45 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id BCF1C1A0228 for ; Mon, 27 Jan 2014 22:24:45 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id x10so6660055pdj.22 for ; Mon, 27 Jan 2014 22:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6DeVVw8HV5OlyzsJ4caW5VOJukZnP13CLTsjmZTGpoA=; b=JA3uC5ALPLZYJadvESit5vHVKCVCgitc1C25m4YPYFwLcQF+qSzmIKYUaM8g6CWSgW wgUTcqf1zLicXg/f7pB3T+DdwsSk3TqamXB+/Un4LFPCZvow2FbbiKf7CRJu8XkeLEXN aUzyljAHzoUVxjH6+T8Go9/vnV3ZBa9lRH6IDJ/eNBEEY8cQcSWvtClAfyi8aPaqobL4 0jVHxZ0c97cWdO1prwiZBOoHWNH6PUeEEouQZMUJM10IBeZqPnalwz8aRxOoBUi/kawR WJuOaYVU2iTMttS52wzHY3oipzpNQb4bHDWCWRW5fbkijnxGF39KgJ05bcyxzDqKHMgA 1C2A== MIME-Version: 1.0 X-Received: by 10.66.145.199 with SMTP id sw7mr7459949pab.143.1390890283475; Mon, 27 Jan 2014 22:24:43 -0800 (PST) Received: by 10.68.195.104 with HTTP; Mon, 27 Jan 2014 22:24:43 -0800 (PST) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C229CF@marathon> References: <359EC4B99E040048A7131E0F4E113AFC54C222A1@marathon> <359EC4B99E040048A7131E0F4E113AFC54C229CF@marathon> Date: Tue, 28 Jan 2014 09:24:43 +0300 Message-ID: From: Jerome Athias To: "Roman D. Danyliw" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mile@ietf.org" Subject: Re: [mile] @user-agent attribute X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 06:24:48 -0000 Hi, Devil in the details Regarding the "User-Agent" HTTP field, in the context of Incident, it is useful for at least: - as a potential indicator of an "attack step", i.e.: "sqlmap, w3af, dirbuster" is an indicator of well known "offensive" security tools used by "scipt kiddies" or threat actors with low level of skills/knowledge using these tools with default configuration NB: These patterns (coming easily to a list of hundreds with robots) can be used for white/blacklisting, automated action, using regex - as an information (Signature as part of an Event) used as a criteria for identification (with low level of confidence) of a user or threat agent client software HTTPUserAgent, a "User Agent pattern for HTTP client software" is clearly different from a Service Banner Regarding, the CPEs, it is actually quite commonly used, as part of the CVEs, OVAL, or Softwares (including free softwares). Taking into consideration the adoption factor, and the use in daily updated repositories (NVD), I think it -currently- makes sense to use them. NB: a new mechanism, using the CPEs, (quite similar to OVAL) is now integrated in the CVE definition I see SWID tags as a "CPE extension" or more granular, with not enough maturity in term of adoption as of today. And ISO/IEC 19770 would also have to be evaluated. In terms of terminology (Taxonomy/Ontology/Vocabulary/Thesaurus), I concur that we need to be clear, precise and strict. Defining properly an "arcology" is difficult, but needed for proper inter-exchange and automation. (Terms like "System", "Host" or "Platform" mean nothing and everything for me, and are just lazy generic terms or should just be used for very high level of abstraction) My arcology definition tentative (bad english included): In the Cyber space, Internet of (Every)thing, there are interactions between Persons (individuals or group of people such as organisations) and Systems. These Systems are IT-Assets. IT-Assets are a combination of Hardware and Software elements. These elements have relationships and dependencies. Elements of the hardware domain are physical objects: Devices. Devices are physically constituted of Components One Device could be a combination of multiple Devices or Device Components. A Device Component could be a combination of Device Components. Elements of the software domain are Softwares and Applications. Softwares are a combination of source code (that could be compiled) NB: The difference between Software and Application potentially comes from the differentiation of closed-source and open-source Softwares could be a combination of Softwares (i.e. Libraries) (Example: an Operating System is a Software) Applications are a combination of code and potentially Softwares (Example: a web site is an Application) NB: an Application could be constituted of just one Software Softwares and Applications are classified using different terms (Type, Category, Flavor, ...) (Software) Services are offered by Applications (and so potentially by one unique Software) via an interaction of IT-Assets, for example hosted on Devices using Softwares. Happy to discuss this and any feedback welcome. Also happy to speak about Network Links (circuits, connections), Endpoints, Data, Partitions, Relationships or other Nodes/Clusters. Best regards 2014-01-28 Roman D. Danyliw : > I can't speak to the latest on any of these projects, so I defer to those= that are tracking their future more closely. > > We're definitely are going to need to provide a lot more guidance on what= constitutes a {Application,OperatingSystem}@swid, @configid, @vendor, @fam= ily, @name, @version or @patch moving forward. The current description of = these attributes simply restates their name in a phrase. > > Roman > >> -----Original Message----- >> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >> Sent: Monday, January 27, 2014 5:40 PM >> To: Roman D. Danyliw; mile@ietf.org >> Subject: RE: @user-agent attribute >> >> CPE isn't funded anymore and may get folded in SWID. I don't have the l= atest >> on this, but would not want to rely on something that may go away. Is >> anyone aware of the latest on CPE? >> >> Thanks, >> Kathleen >> >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw >> Sent: Monday, January 27, 2014 3:22 PM >> To: mile@ietf.org >> Subject: [mile] @user-agent attribute >> >> Hello! >> >> The -04 schema of 5070bis has the following comment in the definition of >> @user-agent in the Application and OperatingSystem classes. >> >> [begin comment] >> "" >> [end comment] >> >> SoftwareType is the complexType used to define System/Application and >> Service/OperatingSystem. Lacking documentation in the text and going on= ly >> on the name in the schema, it would appear that this attribute is attemp= ting >> to describe the "User-Agent" HTTP field per Section 14.43 of RFC2616. I= f there >> is a broader definition, could someone please talk us through it. >> >> With the addition of the Service/ApplicationHeader there appear to be tw= o >> ways to represent a User-Agent. Consider the following XML snippet belo= w: >> >> ... >> >> ... > dtype=3D"string">Mozilla/5.0 (Windows NT 6.2; Win64; x64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 >> Safari/537.36 >> >> ... > user-agent=3D"Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.3= 6 >> (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36" version=3D"32.0.11= 667"> >> something >> >> A few questions: >> ** Does the data model need the @user-agent attribute if ApplicationHead= er >> can model it? >> ** Could @swid (defined as "An identifier that can be used to reference = this >> software") be used for a User-Agent? >> ** What implementation guidance should be given about how @user-agent >> should be set with Service/OperatingSystem? >> >> To share my own bias, the Application and OperatingSystem Class are >> currently very poorly specified. I don't think we should continue impro= ving >> them. Instead, we should reference software through CPE >> (http://nvd.nist.gov/cpe.cfm) or similar effort as is possible through t= he SCI- >> defined class Platform. For the time being, I would drop @user-agent. >> >> Roman >> _______________________________________________ >> mile mailing 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 athiasjerome@gmail.com Tue Jan 28 01:41:00 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265171A014C for ; Tue, 28 Jan 2014 01:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_27=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHsnRVkiNy2J for ; Tue, 28 Jan 2014 01:40:58 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 807871A0018 for ; Tue, 28 Jan 2014 01:40:58 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id p10so140183pdj.29 for ; Tue, 28 Jan 2014 01:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zo7q6TJCi3YzvEVJ5+e1Oqba/tQoweRfG4KClTxHuf8=; b=sgj5J/iHlvn2EX19GW1KQTV7clNk5DQGuCCZJ9zYa1Pi4VVa0Mdvdo+N7DIhggDsmT IcTf+RUIHvBJ3j+J+ANYfet+7gU3zQdKaVplunAsLt4eIy/wvmnkaFtJR/nCYIjOBlg4 ctDtkDbYdeVfmC9QB9z21+XtDVMhPFNUXUXKV623HNW4EkA8PprlsK4TfBY6mda280H4 NOUW6KYvjK8kHTB7cAre7OqE3MLF/oP7ODWdo0b0CV07AbFr7H3SgNKAddVmKAifPFGQ gxHiRd7ZNrEyI8kCehqxtk+U0IFOLcoEVenvXdBbXzYdwBWGnW/bLKqTH+F/ptOsWUEh bS6w== MIME-Version: 1.0 X-Received: by 10.68.164.4 with SMTP id ym4mr475140pbb.53.1390902056152; Tue, 28 Jan 2014 01:40:56 -0800 (PST) Received: by 10.68.195.104 with HTTP; Tue, 28 Jan 2014 01:40:56 -0800 (PST) In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFC54C2264F@marathon> Date: Tue, 28 Jan 2014 12:40:56 +0300 Message-ID: From: Jerome Athias To: Eric Burger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mile@ietf.org" Subject: Re: [mile] Consistency in classes suffixes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:41:00 -0000 +1 that a change is needed to have the same suffix NB: the suffix could have been "Type" for the description, i.e: the EventType class is used to describe information related to an event and exchange EventData. 2014-01-28 Eric Burger : > +1 > > On Jan 27, 2014, at 5:33 PM, Moriarty, Kathleen wrote: > >> +1 I am fine with the change, others? >> >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw >> Sent: Monday, January 27, 2014 4:52 PM >> To: mile@ietf.org >> Subject: [mile] Consistency in classes suffixes >> >> Hello! >> >> By organic convention, we have a number of a classes that end with the s= uffix "Data" -- EventData, DomainData, RecordData, and AdditionalData. We'= ve added a few classes with the suffix "Information" or "Info" -- HashInfor= mation, EmailInfo, and reused ds:KeyInfo. >> >> For naming consistency, I would recommend renaming these classes as foll= ows: >> ** HashInformation --> HashData, that said, the class represents both si= gnatures and hashes so perhaps there is an more descriptive name? >> ** EmailInfo --> EmailData or Email >> >> How does the community feel about this change? >> >> Roman >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From trammell@tik.ee.ethz.ch Tue Jan 28 02:54:56 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BC81A0348 for ; Tue, 28 Jan 2014 02:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.135 X-Spam-Level: X-Spam-Status: No, score=-4.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSUPdvMBTxOE for ; Tue, 28 Jan 2014 02:54:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 663CE1A0178 for ; Tue, 28 Jan 2014 02:54:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 92F58D9314; Tue, 28 Jan 2014 11:54:50 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8ViUjcLZtmSS; Tue, 28 Jan 2014 11:54:50 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E25D3D930E; Tue, 28 Jan 2014 11:54:49 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_CCA8D1F1-FBA2-40FC-93D4-157165D94860"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC54C2264F@marathon> Date: Tue, 28 Jan 2014 11:54:48 +0100 Message-Id: <8EE65A1C-E1CC-4BE6-AD7E-EF2748C63608@tik.ee.ethz.ch> References: <359EC4B99E040048A7131E0F4E113AFC54C2264F@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.1827) Cc: "mile@ietf.org" Subject: Re: [mile] Consistency in classes suffixes X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 10:54:56 -0000 --Apple-Mail=_CCA8D1F1-FBA2-40FC-93D4-157165D94860 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Roman, all, +1 for both of these. Cheers, Brian On 27 Jan 2014, at 22:51, Roman D. Danyliw wrote: > Hello! >=20 > By organic convention, we have a number of a classes that end with the = suffix "Data" -- EventData, DomainData, RecordData, and AdditionalData. = We've added a few classes with the suffix "Information" or "Info" -- = HashInformation, EmailInfo, and reused ds:KeyInfo. >=20 > For naming consistency, I would recommend renaming these classes as = follows: > ** HashInformation --> HashData, that said, the class represents both = signatures and hashes so perhaps there is an more descriptive name? > ** EmailInfo --> EmailData or Email >=20 > How does the community feel about this change? >=20 > Roman > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile --Apple-Mail=_CCA8D1F1-FBA2-40FC-93D4-157165D94860 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS54x4AAoJENt3nsOmbNJcUoYH/3CiDwo6rIiQy5ThRraMgj7w WpKjaLiU0rVama4O6w22xeigGjUxzia3E325Os5mxDKYAnq7ND2x+DK40d666l2c /JQAOWwwJ7cmSUD/zEtC3hVTZUyR2wrewyZ1b4jjfpYjDsE/jFGaECTf+IdzUkuZ IPVF5j92bSh3eZ1EwVwE/Zy8u7EBK4N7OluzOolpqwsYlHUZ7LsIRhR27S+mlhA4 b1G9ZdcGmt1Hl1mZgUE5BMTsWJGhAe0uoXw7frzsREmA4YhREBtvhJvCGJXjtX4/ Lmx6GJC0722vPgBC7sHCPI+WXXOBFyGSp0wftKN2Mr+uOhO6V4Ixl37d4/kU820= =1Lyq -----END PGP SIGNATURE----- --Apple-Mail=_CCA8D1F1-FBA2-40FC-93D4-157165D94860-- From murillo@ieee.org Tue Jan 28 17:10:51 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4B1A0382 for ; Tue, 28 Jan 2014 17:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0ZuXKiD3ECE for ; Tue, 28 Jan 2014 17:10:49 -0800 (PST) Received: from m1plsmtpa01-03.prod.mesa1.secureserver.net (m1plsmtpa01-03.prod.mesa1.secureserver.net [64.202.165.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2216F1A0378 for ; Tue, 28 Jan 2014 17:10:49 -0800 (PST) Received: from [192.168.1.74] ([108.219.88.94]) by m1plsmtpa01-03.prod.mesa1.secureserver.net with id KdAk1n0092289Lk01dAl21; Tue, 28 Jan 2014 18:10:46 -0700 X-Sender: martin@murillos.net Message-ID: <52E85516.5000302@ieee.org> Date: Tue, 28 Jan 2014 20:10:46 -0500 From: Martin Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Johnson, Blake" , Jerome Athias References: <20140122155745.18162.21877.idtracker@ietfa.amsl.com> <52E1CBB5.6000906@ieee.org> <6855397E5430804F9E017DDE40F11303F1EC36@MSNWINMAILBOX2.ALI.PRI> In-Reply-To: <6855397E5430804F9E017DDE40F11303F1EC36@MSNWINMAILBOX2.ALI.PRI> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mile@ietf.org" Subject: Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: murillo@ieee.org List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 01:10:51 -0000 Have read the links posted by Jerome and info on the Experience Sharing Tool (EST). It is my impression that a revision under the light of the EST would be very appropriate, and one of the first uses of the extension, given its report-based nature. Look forward to seeing the reviews in this light. As Jerome mentioned, focusing on referencing already existing taxonomies (and when necessary reusing them and referencing their xml implementations, if publicly available) would be the best approach; given the early stages in the field, I tend to think that atomic data will need to be used. Regarding the term "Asset" vs "System", I believe system provides a more general connotation, while asset, seem to focus more on mainstream infrastructure; because the inclusion of IoT-related infrastructure (anywhere from centralized home control to self-driving cars), I wonder whether "Asset" is too an specific term. Martin Martin On 1/24/2014 2:09 PM, Johnson, Blake wrote: > This is an interesting application of IODEF that I had not considered. Most industry sharing that takes place in this space, from my perspective, is in the form of in person and telephone threat briefings. These are facilitated by the FBI, DHS, and the ISAC's. > > At least a handful of the ISAC's have started sharing structured threat indicator data, and the taxonomy for this extension could cover what the Electric Sector ISAC currently refers to as 'Experience Sharing.' I can review this proposal as it relates to information captured by the ES-ISAC's Experience Sharing tool, using IEC/ANSI 62443 (ISA99) as an informative reference. > > Blake Johnson > Threat Intelligence Analyst > Alliant Energy | Infrastructure Secruity > Office: 608-458-6320 | Cell: 608-843-2790 > > > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Jerome Athias > Sent: Friday, January 24, 2014 3:18 AM > To: murillo@ieee.org > Cc: mile@ietf.org > Subject: Re: [mile] Fwd: New Version Notification for draft-murillo-mile-cps-00.txt > > Hi, > > from what I know (which is limited), and as you mention, this ICS area > is often also called Critical Infrastructures (CIs), or SCADA > > for a little bit of background, we could explore the Cybersecurity Framework > Example references > http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx > http://www.ictqatar.qa/en/documents/download/National%20Industrial%20Control%20Systems%20Security%20Standard-English.pdf > ANSI/ISA-99.02.01-2009 > > I don't have enough knowledge about the status and adoption of the > different efforts in term of XML representation/format/standards > http://xml.coverpages.org/emergencyManagement.html > and resilience > > It would maybe be possible to obtain information from there > http://ics-cert.us-cert.gov > http://ics-isac.org/ > > My first feedback is that it looks like an interesting extension. > > I would suggest to focus on the reuse of existing Taxonomies, or > references to them. > > As such, for [Industry], maybe > http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012 > ISO 3166 (Country Codes) > > > [TargetSystems], I (personally) don't like the word "system" and prefer "asset" > > [CompromisedPhysicalInfrastrucute] (with a typo ;p) seems to be a > category of "Infrastructure" (or group of assets) > > > [EntryPoint] could be ok since it could be a little bit different from > "endpoint" > > [PerpetratingParty] seems to reference "Threat Actor" or "Threat > Agent" or "Attacker" > > [RecurrencePreventionMeasures] is this Security Controls? (and > Mitigations/Remediations) > Reference: https://web.nvd.nist.gov/view/800-53/control?controlName=AC-3&type=1 > > > Describing an [Exploit] is not so easy (depending on the level of > details wanted/needed) > > Figure 1 (or "Diagram 1") is interesting, (of course it is different > from, i.e. CAESARS), it MAYBE could be more layered > http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/ContentDisplay.cfm&ContentID=94401 > > (To follow: ENISA CDXI) > > > Some typos > > > > Next step: more XML focused ;) > > > My 2 bitcents > > 2014/1/24 Martin Murillo : >> Dear all, >> >> Please find below a link to a proposed draft for extending IODEF for the >> reporting of cyber-physical system incidents. These systems are often >> referred as Operational Technology Systems, Industrial Control Systems, >> Automatic Control Systems, or simply Control Systems. >> >> Cyber-Physical systems have been around for decades. However, they are now >> at a higher risk to be the target of attacks by individual highly-skilled >> attackers, organized groups, nation-states, or simply suffer repercussions >> of mainstream IT cyber-attacks. While over 90% of critical control system >> infrastructure is currently owned by private enterprises, these can have >> direct repercussions on national security of world nations. Indeed, various >> of these systems are key parts of nuclear reactor facilities, transportation >> systems, electric power distribution, oil and natural gas distribution, >> health care, water and waste-water treatment, dam infrastructure, missile >> and defense systems, and others. The disruption of these control systems >> could have a significant impact on public health, safety, and lead to large >> economic losses. >> >> Among the issues that catalyze this higher risk are: >> >> i) these systems are gradually becoming more interconnected, ii) legacy >> systems do not have proper cybersecurity protection, iii) the existence of >> highly-skilled individuals and motivations, iv) some these systems are >> generally considered critical, v) these are a natural extension of IT >> cyber-attacks, vi) the emergence of the Internet of Things (IOT), and vi) >> these attacks can be carried out remotely and quite inexpensively. >> >> While there might exist national approaches to deal with incidents, there's >> the need of a global international approach that will engulf governments, >> private organizations and other stakeholders. IETF, as a leading global >> Internet standards organization, seeks to satisfy this need through open >> standards that seek to encompass issues that are critical for the global >> community. >> >> Feedback at two levels are welcome: >> >> 1. On the existence and inclusion either by utilizing any already existing >> industry formats (XML- encoded) and/or by utilizing atomic data >> 2. Contributions on making the extension (and background information) more >> comprehensive, accurate and principally useful for the community >> >> Look forward to feedback and other input! >> >> Martin Murillo >> >> A new version of I-D, draft-murillo-mile-cps-00.txt >> has been successfully submitted by Martin Murillo and posted to the >> IETF repository. >> >> Name: draft-murillo-mile-cps >> Revision: 00 >> Title: IODEF extension for Reporting Cyber-Physical System >> Incidents >> Document date: 2014-01-21 >> Group: Individual Submission >> Pages: 24 >> URL: >> http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt >> Status: https://datatracker.ietf.org/doc/draft-murillo-mile-cps/ >> Htmlized: http://tools.ietf.org/html/draft-murillo-mile-cps-00 >> >> >> Abstract: >> This draft document will extend the Incident Object Description >> Exchange Format (IODEF) defined in [RFC5070] to support the reporting >> of incidents dealing with attacks to physical infrastructure through >> the utilization of IT means as a vehicle or as a tool. These systems >> might also be referred as Cyber-Physical Systems (CPS), Operational >> Technology Systems, Industrial Control Systems, Automatic Control >> Systems, or simply Control Systems. These names are used >> interchangeably in this document. In this context, an incident is >> generally the result of a cybersecurity issue whose main goal is to >> affect the operation of a CPS. It is considered that any >> unauthorized alteration of the operation is always malign. This >> extension will provide the capability of embedding structured >> information, such as identifier- and XML-based information. In its >> current state, this document provides important considerations for >> further work in implementing Cyber-Physical System incident reports, >> either by utilizing any already existing industry formats (XML- >> encoded) and/or by utilizing atomic data. >> >> In addition, this document should provide appropriate material for >> helping making due considerations in making an appropriate decision >> on how a CPS reporting is done: 1) through a data format extension to >> the Incident Object Description Exchange Format [RFC5070], 2) forming >> part of an already existing IODEF-extension for structured >> cybersecurity information (currently draft >> draft-ietf-mile-sci-11.txt), or others. While the format and >> contents of the present document fit more the earlier option, these >> can also be incorporated to the later. >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > From kathleen.moriarty@emc.com Wed Jan 29 12:59:53 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BAB1A02C0 for ; Wed, 29 Jan 2014 12:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUECk2lehOFH for ; Wed, 29 Jan 2014 12:59:51 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDF51A02B6 for ; Wed, 29 Jan 2014 12:59:50 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0TKxgS2009062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jan 2014 15:59:42 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0TKxgS2009062 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1391029182; bh=WyVN3ZrB3SCtmTSvaTKCGkzIqV8=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Hbva1s7Yvml4vaeHM62tgtEQY7P9RDQ67KlSKeLRD8W4aeBEHm3S8RYGadF60OVbd UTECiYpptEOIoNpZY+4u2ChXvIhWax5oY/Zi1EbCtwGuD/Scn57iUO3pY2lJGqS+vW IB14o1KB3rCLaWMtCRud/TuL5nAU0wcgp0/fa41I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s0TKxgS2009062 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Wed, 29 Jan 2014 15:59:31 -0500 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0TKxT18026863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 29 Jan 2014 15:59:31 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub34.corp.emc.com ([::1]) with mapi; Wed, 29 Jan 2014 15:59:29 -0500 From: "Moriarty, Kathleen" To: "mile@ietf.org" Date: Wed, 29 Jan 2014 15:59:27 -0500 Thread-Topic: Web-based email list archive search and browsing tool ready for use Thread-Index: Ac8dMxdaSnWQOs1GS7+zFbzkxvT51AAAc/RA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Subject: [mile] FW: Web-based email list archive search and browsing tool ready for use X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 20:59:53 -0000 An improved interface has been released for accessing the email archive. P= lease see the information provided below. Best regards, Kathleen -----Original Message----- From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of IETF Chair Sent: Wednesday, January 29, 2014 3:45 PM To: ietf-announce@ietf.org Cc: ietf@ietf.org Mailing List; tools-discuss@ietf.org Subject: Web-based email list archive search and browsing tool ready for us= e The tool realizing the requirements we developed in RFC 6778 is ready for y= our use. You'll find the service at https://mailarchive.ietf.org/ If you choose to l= og in, use your datatracker credentials. If you see issues in the messages for a list, please contact the list's adm= inistrators (typically the working group chairs for working group lists). If you encounter other problems or have suggestions for future improvements= , please file a report using http://trac.tools.ietf.org/tools/ietfdb/newtic= ket If you find spam in the archives, please send a request to remove it includ= ing a link to the message to action@ietf.org. We are still working towards providing IMAP access to the archives. That is= not part of the tool at this time. The old archives will continue to receive new messages and will be availabl= e in their current locations until further notice. Early testers have reported this tool to be very useful. I hope you also fi= nd it to be so. (And I'd like to thank the tools team, AMS, and the early t= esters for this service!) Jari Arkko IETF Chair From internet-drafts@ietf.org Fri Jan 31 15:30:58 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3661AC7F0; Fri, 31 Jan 2014 15:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-HBb3Syq-yS; Fri, 31 Jan 2014 15:30:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F18291A04EA; Fri, 31 Jan 2014 15:30:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131233057.29890.66492.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 15:30:57 -0800 Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-05.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 List-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, 31 Jan 2014 23:30:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF. Title : The Incident Object Description Exchange Format v2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-05.txt Pages : 126 Date : 2014-01-31 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rfc5070-bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rdd@cert.org Fri Jan 31 15:32:16 2014 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F87B1AC82A for ; Fri, 31 Jan 2014 15:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_STOCK2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 542ptK4OYIla for ; Fri, 31 Jan 2014 15:32:14 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9B31AC7F2 for ; Fri, 31 Jan 2014 15:32:14 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0VNWAWR026843 for ; Fri, 31 Jan 2014 18:32:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1391211130; bh=ScmTCF2cOe4L+0wNl1gAq3z531TBJI1PmuCMulEBFc4=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To:Cc; b=mICl6YQDR9QrWr57mRstOB5uj2qORoCbY+NuweP4z/hkZ4+Qwbg0CKbhZ2elFefga TG9ZH/DF6La7MqZGL3gqX9GwPcibP9oshheAiEHUhMkOsvvd6+7+4vp75FKdm/AmUA rR+emJf48w9Vo+xntuWPvJoWeKmFZRrqXohxC6T8= Received: from CASSINA.ad.sei.cmu.edu (cassina.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s0VNWAHo007828 for ; Fri, 31 Jan 2014 18:32:10 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.02.0347.000; Fri, 31 Jan 2014 18:32:10 -0500 From: "Roman D. Danyliw" To: "mile@ietf.org" Thread-Topic: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-05.txt Thread-Index: AQHPHtyAJ2+T57/ycE6n45IfDsYWpJqfe1mQ Date: Fri, 31 Jan 2014 23:32:08 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC54C2A75C@marathon> References: <20140131233057.29890.66492.idtracker@ietfa.amsl.com> In-Reply-To: <20140131233057.29890.66492.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mile] FW: I-D Action: draft-ietf-mile-rfc5070-bis-05.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 31 Jan 2014 23:32:16 -0000 The Changelog for this -05 draft is as follows: ** (schema) Renamed DomainData@{SystemStatus,DomainStatus} to @{system-stat= us, domain-status}=20 ** (schema) Renamed RelatedDNS@RecordType to @record-type ** (schema) Added DomainData@{ext-system-status, ext-domain-status} to allo= w extensibility ** (schema) Added Assessment/BusinessImpact (Issue #36) ** (schema) Added EmailInfo/EmailHeaderField (Issue #24 and raised in a sch= ema comment per Issue #21) ** (schema) Added HashInformation/AdditionalData (Issue #23) ** (schema) Renamed HashInformation to HashData ** (schema) Renamed EmailInfo to EmailData ** (schema) Added enumerated values to Contact@type to track RFC5901 and ot= her gaps ** (editorial) Added a reference (IANA.Ports) for ApplicationHeader@proto ** (editorial) Added a reference (IANA.Protocols) for Service@ip_protocol ** (editorial) Added documentation for DomainData, Nameservers, and DomainC= ontacts ** (editorial) Removed some of the schema comments (Issue #21) Roman -----Original Message----- From: mile [mailto:mile-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, January 31, 2014 6:31 PM To: i-d-announce@ietf.org Cc: mile@ietf.org Subject: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Managed Incident Lightweight Exchange Wor= king Group of the IETF. Title : The Incident Object Description Exchange Format v= 2 Authors : Roman Danyliw Paul Stoecker Filename : draft-ietf-mile-rfc5070-bis-05.txt Pages : 126 Date : 2014-01-31 Abstract: The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-rfc5070-bis-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile