Re: [mile] Clarifying iodef:SoftwareType (Issue #47)
"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Wed, 25 March 2015 09:41 UTC
Return-Path: <takeshi_takahashi@nict.go.jp>
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 5C2431A90B2 for <mile@ietfa.amsl.com>; Wed, 25 Mar 2015 02:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-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 mWPsMZaiiqFW for <mile@ietfa.amsl.com>; Wed, 25 Mar 2015 02:41:11 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E22A1A07BC for <mile@ietf.org>; Wed, 25 Mar 2015 02:41:11 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id t2P9exdR026035; Wed, 25 Mar 2015 18:40:59 +0900 (JST)
Received: from takeAsus (ssh.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with SMTP id t2P9etek026006; Wed, 25 Mar 2015 18:40:56 +0900 (JST)
Message-ID: <652B4972D3544608954B6EC5533E2FCB@takeAsus>
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: Jerome Athias <athiasjerome@gmail.com>, "Roman D. Danyliw" <rdd@cert.org>
References: <359EC4B99E040048A7131E0F4E113AFCD93D2DE8@marathon> <CAA=AuEdi+G=ML67NGvmkEzV34D0YEFjQ3MEb6NJ_Rc2PnmzvQg@mail.gmail.com>
In-Reply-To: <CAA=AuEdi+G=ML67NGvmkEzV34D0YEFjQ3MEb6NJ_Rc2PnmzvQg@mail.gmail.com>
Date: Wed, 25 Mar 2015 04:39:38 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
X-Virus-Scanned: clamav-milter 0.98.5 at zenith2
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/mile/t2KtCnrOJuqL5h9LXscow5vHHN4>
Cc: mile@ietf.org
Subject: Re: [mile] Clarifying iodef:SoftwareType (Issue #47)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 09:41:14 -0000
Hi, As a person who had engaged in IODEF-SCI, I would be happy if we can use IODEF-SCI. (It does not mean I am objecting any other options for this issue.) I was planning to propose some minor changes after the IODEF-bis is finalized. So, if some changes to IODEF-SCI may help here, I am happy to do so. The current IODEF-SCI (RFC 7203) was made for IODEF v1, and it anyway needs some small changes to cope with IODEF-bis. The current IODEF-SCI defines one basic structure, and it is used by its inherited classes: AttackPattern, Platform, Vulnerability, Scoring, Weakness, EventReport, Verification, or Remediation classe. The structure of all these classes are more-or-less the same as the basic structure, but the location to use them are restricted. If it helps, we could for instance remove these inherited classes and just define the basic structure so that it can be used by any of the AdditionalData class inside IODEF document. In this way, we do not have to re-invent new data model for this discussion. Kind regards, Take -----Original Message----- From: Jerome Athias Sent: Wednesday, March 25, 2015 3:10 AM To: Roman D. Danyliw Cc: mile@ietf.org Subject: Re: [mile] Clarifying iodef:SoftwareType (Issue #47) Hi (4) seems the best approach IMHO for now (would allow use of OVAL/CPE, SWID, or any others. And the "any others" is needed.) Warning regarding OVAL vs IODEF-SCI (4.5.2.) for the -Platform- definition and use: different Little warning regarding "Application" vs "Software" Note: a IANA registry tentative would be difficult, IMHO, and not flexible enough (potentially too restrictive) IF the extension mechanism is not allowing others (e.g. own organisation classification/categories). Furthermore, I'm not sure a IANA registry with just 2 entries would need effort put in it. Cristal clear recommandations/guidances for use of CPE or SWID could be enough. (2) is not free Any stats on real/current usage rate of SWID? PS: SWID->CPE mapping is possible My 2c for now Best regards 2015-03-24 20:55 GMT+01:00 Roman D. Danyliw <rdd@cert.org>: > Good afternoon! > > One of the remaining issues with rfc5070bis is to clarify the > iodef:SoftwareType. See Issue #47 [1]. We discussed this impasse in > Honolulu [2]. > > --[ snip discussion from IETF 91 ]-- > Q1: (Roman Danyliw) Last mailing list discussion on clarifying > iodef:Software produced no result. What does the group want to do? > A: (David Waltermire) Extensibility is key dimension. Consider just using > swid and reference the ISO standard. Alternatively, redefine the class to > be AdditionalData. > A: (Adam Monteville) Reiterated the importance of extensibility > A: Isn't swid support already in the spec? > A: (Roman Danyliw) There is an attribute named "swid" but this comes from > RFC5070 which just happened to use this name without reference to the ISO > standard. > A: (Takeshi Takahashi) IODEF-SCI can embed SWID and CPE as well, but the > context is different; it is added under AdditionalData. If we need the > data here, we could make a model here like the SCI draft does. > --[ end snip ]-- > > The four options mentioned to date (not just at IETF 91) are: > > (1) Use OVAL [3] > > (2) Use swid referencing ISO/IEC 19770-2:2009 (with XML schema at [4]) > > (3) Don't define it and use AdditionalData > > (4) Support mutiple techniques to reference software in the same way > (like IODEF-SCI and ENUM) > > Approach (1) and (2) are require little further explanation. Hence, let > me describe (3) in more detail. > > The thinking would be to create an IANA registry to maintain a list of > external references, in this case application reference techniques (e.g., > swid and CPE), just like IODEF-SCI and ENUM current do. The class using > this technique might look as follows: > +---------------------+ > | Application | > +---------------------+ > | ENUM SpecID |<>--(0..*)-[ SpecData ] > | STRING ext-SpecID | > | | > +---------------------+ > > ** SpecID would map to an IANA registry of application reference > techniques > ** ext-SpecID would allow for private enumerated value extensions as > currently done in the draft > ** SpecData would be defined as follows allowing both XML or atomic data > types such as a string. > <xs:complexType name="AppIdType" mixed="true"> > <xs:sequence> > <xs:any namespace="##any" processContents="lax" > minOccurs="0" maxOccurs="unbounded"/> > </xs:sequence> > > In the same way that the general purpose ENUM approach was useful to SACM > and MILE, SACM has also expressed interest in a common approach on this > class too. > > What does the community feel is the correct approach? > > Roman > > [1] http://trac.tools.ietf.org/wg/mile/trac/ticket/47 > [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-mile > [3] https://nvd.nist.gov/cpe.cfm > [4] http://standards.iso.org/iso/19770/-2/2009/schema.xsd > _______________________________________________ > mile mailing 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] Clarifying iodef:SoftwareType (Issue #47) Roman D. Danyliw
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Adam W. Montville
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Tony Rutkowski
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Sean Turner
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Jerome Athias
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Takeshi Takahashi
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Roman D. Danyliw
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Sean Turner
- Re: [mile] Clarifying iodef:SoftwareType (Issue #… Cheikes, Brant A.