Subject: [mile] MTI SCI?

From: Sean Turner <[email-masked]>
Date: Mon, 13 Feb 2012 18:57:18 -0500

There's 17 listed SCI (Structured Cybersecurity Information) 
specifications in draft-ietf-mile-sci.  Which one is the MTI (mandatory 
to implement) choice?  In other words, how will you get two 
interoperability implementations without picking one?

spt

---

From: <[email-masked]>
Date: Mon, 13 Feb 2012 19:11:21 -0500

Thank you for raising the interoperability testing as we need to plan for a bake-off that once these questions get answered and the draft is ready.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, February 13, 2012 6:57 PM
To: [email-masked]
Subject: [mile] MTI SCI?

spt
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Sean Turner <[email-masked]>
Date: Mon, 13 Feb 2012 19:19:29 -0500

Great - as long as we pick one as the MTI.  Note that MTI is not 
necessarily mandatory to use.

spt

---

From: Brian Trammell <[email-masked]>
Date: Tue, 14 Feb 2012 10:19:54 +0100

Hi, Sean, all,

Looking over the spec, it's not clear to me that one MTI makes sense here, given that mile-sci's purpose is to reference a set of external specifications by inclusion in an IODEF document, and that those external specifications represent fundamentally different things.

The specifications are split over their applicability to the IODEF extension classes. I could envision an mile-sci implementation that was only interested a subset of these classes (perhaps even only one). If my implementation has an internal representation of Verification, but not of any of the other classes, and the MTI is an enumeration that is applicable to Vulnerability... what do I do?

What about selecting an MTI per class, instead?

Best regards,

Brian (as contributor)

On Feb 14, 2012, at 1:19 AM, Sean Turner wrote:

> Great - as long as we pick one as the MTI.  Note that MTI is not necessarily mandatory to use.
> 
> spt
>

---

From: "Martin, Robert A." <[email-masked]>
Date: Tue, 14 Feb 2012 08:25:56 -0500

Brian,

You beat me to this point.  Like you, I would be concerned about a MTI 
selection that ended up requiring someone to implement something to meet 
the MTI but wasn't germane to anything else they intended to support.

Bob

On 2/14/12 4:19 AM, Brian Trammell wrote:
> .

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Feb 2012 08:40:34 -0500

Coming from the ol'school world of ASN.1 (all the cool kids are doing 
JSON now-a-days) when you have optional elements in say a sequence you 
had to say which one was the MTI to ensure you got interop.  In XML-land 
that doesn't happen as much.  There's a bunch of optional things and the 
implementation gets to pick what it wants to support.  That's great for 
gaining the widest possible adoption of the spec, but not so great for 
actually getting two implementations to interop.  I'll be happy as long 
as the WG comes up with a way to clearly describe what two 
implementations need to do to interop.

spt

On 2/14/12 8:25 AM, Martin, Robert A. wrote:
>> Looking over the spec, it's not clear to me that one MTI makes sense
>> here, given that mile-sci's purpose is to reference a set of external
>> specifications by inclusion in an IODEF document, and that those
>> external specifications represent fundamentally different things.
>>
>> The specifications are split over their applicability to the IODEF
>> extension classes. I could envision an mile-sci implementation that
>> was only interested a subset of these classes (perhaps even only one).
>> If my implementation has an internal representation of Verification,
>> but not of any of the other classes, and the MTI is an enumeration
>> that is applicable to Vulnerability... what do I do?
>>
>>>> Thank you for raising the interoperability testing as we need to
>>>> plan for a bake-off that once these questions get answered and the
>>>> draft is ready.
>>>>
>>>> Thanks,
>>>> Kathleen
>>>>

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 09:42:04 -0500

Hi Sean, Brian, all,

If you think if each included schema as a module, and each module is included the same way, but in different areas of IODEF, shouldn't one be sufficient for mandatory?  For a bake-off, we should do at least two?  IODEF specifies how to respond when a schema is not recognized, so that should be in the bake-off too.  

Other opinions?

Regards,
Kathleen

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 4:20 AM
To: Sean Turner
Cc: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] MTI SCI?

Hi, Sean, all,

Best regards,

Brian (as contributor)

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 10:03:03 -0500

I agree with Sean here in that there has to be at least one mandatory so we know if the method used to incorporate schemas within IODE for exchange works... otherwise, we may need to tweak something in the draft before it moves to standard.  Brian is arguing for one mandatory in each are of IODEF that is extended (valid point and an option we should consider).  I think Bob you feel nothing should be mandatory or are you agreeing with Brian - one per extended area of IODEF?

I think having one fail in the tests would also be good to make sure it happens in a way that works between implementations as well.

Other opinions?  Or agreement with any of the above opinions?

(and my posts to MILE seem to be delayed... apologies)

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Tuesday, February 14, 2012 8:41 AM
To: Martin, Robert A.; Brian Trammell
Cc: [email-masked]
Subject: Re: [mile] MTI SCI?

spt

---

From: Youki Kadobayashi <[email-masked]>
Date: Wed, 15 Feb 2012 00:14:41 +0900

I think CAPEC is best candidate of MTI spec, as it is simple,
and it nicely extends IODEF vocabulary.

I would like to hear other people's opinions.

-- 
     Youki Kadobayashi
     WIDE Project / Nara Institute of Science and Technology

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 11:14:28 -0500

Hi Bob,

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

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

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

What do you (and others) think about this?

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin, Robert A.
> Sent: Tuesday, February 14, 2012 8:26 AM
> To: Brian Trammell
> Cc: [email-masked]
> > Looking over the spec, it's not clear to me that one MTI makes sense here, given that mile-sci's
> purpose is to reference a set of external specifications by inclusion in an IODEF document, and that
> those external specifications represent fundamentally different things.
> >
> > The specifications are split over their applicability to the IODEF extension classes. I could
> envision an mile-sci implementation that was only interested a subset of these classes (perhaps even
> only one). If my implementation has an internal representation of Verification, but not of any of
> the other classes, and the MTI is an enumeration that is applicable to Vulnerability... what do I
> do?
> >
> >>> Thank you for raising the interoperability testing as we need to plan for a bake-off that once
> these questions get answered and the draft is ready.
> >>>
> >>> Thanks,
> >>> Kathleen
> >>>

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 10:36:57 -0600

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

IODEF by itself has been criticized by CSIRT operators for being more heavyweight than necessary for day-to-day usage; making CAPEC a mandatory aspect of "advanced IODEF" seems like it would be adding ammunition to that argument, especially if the CSIRT is having to fund implementation out of their own pocket. Personally, I would have a hard time asking US-CERT's primary constituents to implement IODEF + CAPEC if they are already balking at the consultant and developer resources required to implement RFC 5070 by itself. Also keep in mind that CAPEC references CybOX, so there's wheels within wheels now.

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

 - Tom Millar, US-CERT

[email-masked]
BB: [email-masked] / 202-631-1915
24x7: [email-masked] / 888-282-0870 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 14, 2012 11:14
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mile] MTI SCI?

Hi Bob,

Thanks,
--David

> selection that ended up requiring someone to implement something to 
> meet the MTI but wasn't germane to anything else they intended to support.
> 
> Bob
> 
> > here, given that mile-sci's
> purpose is to reference a set of external specifications by inclusion 
> in an IODEF document, and that those external specifications represent fundamentally different things.
> >
> > extension classes. I could
> envision an mile-sci implementation that was only interested a subset 
> of these classes (perhaps even only one). If my implementation has an 
> internal representation of Verification, but not of any of the other 
> classes, and the MTI is an enumeration that is applicable to Vulnerability... what do I do?
> >
> >>> plan for a bake-off that once
> >>> specifications in draft-ietf-mile-sci.  Which one is the MTI 
> >>> (mandatory to implement) choice?  In other words, how will you get 
> >>> two interoperability implementations without picking one?
> >>>
> >>> spt

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 10:45:24 -0600

CVE is widely used and understood by all in the the security community. I agree with Tom that CVE is the path of least resistance but may be the most useful for basic interoperability.

Kent Landfield
Director Content Strategy, Architecture and Standards

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 10:36:57 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bob Martin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] MTI SCI?

- Tom Millar, US-CERT

[email-masked]<mailto:[email-masked]>
BB: [email-masked]<mailto:[email-masked]> / 202-631-1915
24x7: [email-masked]<mailto:[email-masked]> / 888-282-0870

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, February 14, 2012 11:14
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] MTI SCI?

Hi Bob,

Thanks,
--David

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Martin, Robert A.
Sent: Tuesday, February 14, 2012 8:26 AM
To: Brian Trammell
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] MTI SCI?
Brian,
>> On 2/13/12 7:11 PM, [email-masked]<mailto:[email-masked]> wrote:
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
>>> Behalf Of Sean Turner
>>> To: [email-masked]<mailto:[email-masked]>
>>> Subject: [mile] MTI SCI?
>>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: "Martin, Robert A." <[email-masked]>
Date: Tue, 14 Feb 2012 11:46:06 -0500

I agree with Brian - one per extended area.  Sorry if I wasn't clear.

---

From: "Martin, Robert A." <[email-masked]>
Date: Tue, 14 Feb 2012 11:49:35 -0500

At the risk of contradicting myself - but then again I have now read the 
other replies to this issue - I agree that having one area be the smoke 
test makes sense and I also agree that something simple and commonly 
used already - like CVE - is the best candidate for what we need.

Bob

On 2/14/12 11:45 AM, [email-masked] wrote:
> From: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>, Bob Martin<[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 15 Feb 2012 18:15:38 +0900

Hello all,

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

(added sentences at the end of section 4.1)

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

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

The class could be seen as below.

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

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

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

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

Sincerely,
Take

> Sent: Wednesday, February 15, 2012 1:50 AM
> To: [email-masked]
> Cc: [email-masked]
> test makes sense and I also agree that something simple and commonly used
> already - like CVE - is the best candidate for what we need.
> 
> Bob
> 
> > CVE is widely used and understood by all in the the security community.
> I agree with Tom that CVE is the path of least resistance but may be the
> most useful for basic interoperability.
> >
> > Kent Landfield
> > From:
> "[email-masked]<mailto:[email-masked]>"<Thomas
> .M
> > [email-masked]<mailto:[email-masked]>>
> > To:
> "[email-masked]<mailto:[email-masked]>"<[email-masked]
> m<
> > mailto:[email-masked]>>, Bob
> > Martin<[email-masked]<mailto:[email-masked]>>
> > Cc:
> >
> "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:mile@ietf
> .o
> > rg>>
> > My concern with CAPEC being mandatory is that it could discourage
> effective operational uptake of IODEF-SCI as the CAPEC vocabulary remains
> "too comprehensive" for many CSIRTs to employ during incident handling
> and reporting activity.
> >
> > IODEF by itself has been criticized by CSIRT operators for being more
> heavyweight than necessary for day-to-day usage; making CAPEC a mandatory
> aspect of "advanced IODEF" seems like it would be adding ammunition to
> that argument, especially if the CSIRT is having to fund implementation
> out of their own pocket. Personally, I would have a hard time asking
> US-CERT's primary constituents to implement IODEF + CAPEC if they are
> already balking at the consultant and developer resources required to
> implement RFC 5070 by itself. Also keep in mind that CAPEC references
> CybOX, so there's wheels within wheels now.
> >
> > I would prefer we take the path of least resistance (from my
perspective)
> and make CVE the MTI, if we have to pick one additional spec.
> > From: [email-masked]<mailto:[email-masked]>
> > [mailto:[email-masked]] On Behalf Of
> > [email-masked]<mailto:[email-masked]>
> > I do appreciate the concern about implementing things that aren't going
> to be used.  OTOH, it may be useful to have a single simple MTI spec for
> SCI that can be used to "smoke test" a deployment before trying any
serious
> test data (and "simple" is important).
> >
> > In addition, a concern that I would have with an MTI SCI spec per class
> is that if two SCI implementations don't have at least one class in
common,
> they aren't going to interoperate, and that situation is unlikely to be
> acceptable to the IESG (i.e., with an MTI SCI spec per class, I suspect
> that there will also have to be an MTI class, which results in an overall
> MTI SCI spec).
> >
> > It may also be useful to include a simple example of the MTI SCI spec
> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI spec
> is CAPEC, as Youki suggested, the appendix could contain a CAPEC XML
> document for testing purposes, including enumeration values suitable for
> testing).
> >
> > From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf Of Martin, Robert A.
> >>> On 2/13/12 7:11 PM,
> [email-masked]<mailto:[email-masked]>  wrote:
> >>>> From: [email-masked]<mailto:[email-masked]>
> >>>> [mailto:[email-masked]] On Behalf Of Sean Turner

---

From: Brian Trammell <[email-masked]>
Date: Wed, 15 Feb 2012 11:27:36 +0100

Hi, Take, all,

Thank you for this edit/clarification.

On the first point, it does seem the discussion on the list converged rather quickly to CVE as MTI. However, as this is a rather important point, I'd like to make sure we didn't miss anything.

So, I'd like to call for consensus on the list. Does the working group agree on the following two points?

1. mile-sci requires one Mandatory to Implement schema in order to ensure interoperability.

2. The Mandatory to Implement schema is the Common Vulnerability Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile-sci-02.

Please note if you agree; if you disagree, please explain why not.

Best regards,

Brian (as chair)

On Feb 15, 2012, at 10:15 AM, Takeshi Takahashi wrote:

> <draft-ietf-mile-sci-03candidate_20120215.txt><draft-ietf-mile-sci-03candidate_20120215.txt.pdf>_______________________________________________
> mile mailing list
> [email-masked]

---

From: Kent Landfield <[email-masked]>
Date: Wed, 15 Feb 2012 06:32:43 -0600

I agree.

Kent Landfield
McAfee Labs
[email-masked]
+1.817.637.8026

---

From: "Martin, Robert A." <[email-masked]>
Date: Wed, 15 Feb 2012 07:43:21 -0500

Agree

On 2/15/12 7:32 AM, Kent Landfield wrote:
> On Feb 15, 2012, at 4:27 AM, Brian Trammell<[email-masked]>  wrote:
>
>> Hi, Take, all,
>>

---

From: <[email-masked]>
Date: Wed, 15 Feb 2012 09:43:23 -0500

Agree - I'd also like to see a CVE XML document suitable for testing, or at least CVE enumeration values recommended for that purpose in an Appendix.  The rationale would be to provide implementers with data for smoke tests that is clearly for testing only, and hence cannot be confused with actual CVE data if it should escape the smoke test into operational systems.

Thanks,
--David

> Sent: Wednesday, February 15, 2012 7:43 AM
> To: Kent Landfield
> Cc: [email-masked]
> Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?)
> 
> Agree
> 
> >> On the first point, it does seem the discussion on the list converged rather quickly to CVE as
> MTI. However, as this is a rather important point, I'd like to make sure we didn't miss anything.
> >>
> >> 2. The Mandatory to Implement schema is the Common Vulnerability Enumeration (CVE) version 1.0,
> as described in section 4.1.7 of mile-sci-02.
> >>
> >>> <draft-ietf-mile-sci-03candidate_20120215.txt><draft-ietf-mile-sci-
> 03candidate_20120215.txt.pdf>_______________________________________________
> >>> mile mailing list
> >>> [email-masked]

---

From: Luis Nunez <[email-masked]>
Date: Wed, 15 Feb 2012 09:49:53 -0500

Agree -  David also make a good point about having samples of what it looks like.

-ln

---

From: <[email-masked]>
Date: Wed, 15 Feb 2012 09:34:26 -0600

Agree and agree that an "EICAR" for CVE interop testing is reasonable.

 - Tom Millar, US-CERT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luis Nunez
Sent: Wednesday, February 15, 2012 09:50
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?)

-ln
On Feb 15, 2012, at 9:43 AM, <[email-masked]> <[email-masked]> wrote:

>>>> So, I'd like to call for consensus on the list. Does the working 
>>>> group agree on the following two
>> points?
>>>> 
>>>>> Following the discussion, I would like to add a couple of 
>>>>> sentences to clarify the MTI issues.
>>>>> I've attached the working version of the draft. I hope it helps to 
>>>>> clarify the changes.
>>>>> 
>>>>>  The SpecID attributes of extended classes (Section 4.3) must 
>>>>> allow  the values of the specifications' namespace fields, but 
>>>>> otherwise,  implementations are not required to support all the 
>>>>> above  specifications.  Implementations may choose which 
>>>>> specifications to  support, though CVE 1.0 (Section 4.1.7) needs 
>>>>> to be minimally  supported.  In case an implementation received a 
>>>>> data it does not  support, it may expand its functionality by 
>>>>> looking up the IANA table or  notify the sender of its inability 
>>>>> to parse the data by using any  means defined outside the scope of this specification.
>>>>> 
>>>>> On the other hand, I would like to add "STRING ext-SpecID" to each 
>>>>> class, which enables to embed data following private schema.
>>>>> For instance, one security operation center (SOC) may wish to 
>>>>> exchange a vulnerability data that is formatted in its own private 
>>>>> schema, and that is not formatted in CVE.
>>>>> In this case, the SOC may put the data's schema ID inside 
>>>>> ext-SpecID and then embed the data.
>>>>>> At the risk of contradicting myself - but then again I have now 
>>>>>> read the other replies to this issue - I agree that having one 
>>>>>> area be the smoke test makes sense and I also agree that 
>>>>>> something simple and commonly used already - like CVE - is the best candidate for what we need.
>>>>>> 
>>>>>> Bob
>>>>>> 
>>>>>> I agree with Tom that CVE is the path of least resistance but may 
>>>>>> be the most useful for basic interoperability.
>>>>>>> 
>>>>>>> Kent Landfield
>>>>>> effective operational uptake of IODEF-SCI as the CAPEC vocabulary 
>>>>>> remains "too comprehensive" for many CSIRTs to employ during 
>>>>>> incident handling and reporting activity.
>>>>>>> 
>>>>>> heavyweight than necessary for day-to-day usage; making CAPEC a 
>>>>>> mandatory aspect of "advanced IODEF" seems like it would be 
>>>>>> adding ammunition to that argument, especially if the CSIRT is 
>>>>>> having to fund implementation out of their own pocket. 
>>>>>> Personally, I would have a hard time asking US-CERT's primary 
>>>>>> constituents to implement IODEF + CAPEC if they are already 
>>>>>> balking at the consultant and developer resources required to 
>>>>>> implement RFC 5070 by itself. Also keep in mind that CAPEC references CybOX, so there's wheels within wheels now.
>>>>>>> 
>>>>>>> CVE is well known, has years of familiarity built in, and I 
>>>>>>> think it's
>>>>>> the simplest schema of the bunch.
>>>>>>> 
>>>>>>> 
>>>>>>> - Tom Millar, US-CERT
>>>>>>> 
>>>>>> to be used.  OTOH, it may be useful to have a single simple MTI 
>>>>>> spec for SCI that can be used to "smoke test" a deployment before 
>>>>>> trying any
>>>>> serious
>>>>>> they aren't going to interoperate, and that situation is unlikely 
>>>>>> to be acceptable to the IESG (i.e., with an MTI SCI spec per 
>>>>>> class, I suspect that there will also have to be an MTI class, 
>>>>>> which results in an overall MTI SCI spec).
>>>>>>> 
>>>>>> in an appendix to simplify "smoke testing" (e.g., if the MTI SCI 
>>>>>> spec is CAPEC, as Youki suggested, the appendix could contain a 
>>>>>> CAPEC XML document for testing purposes, including enumeration 
>>>>>> values suitable for testing).
>>>>>>> 
>>>>>>> You beat me to this point.  Like you, I would be concerned about 
>>>>>>> a MTI selection that ended up requiring someone to implement 
>>>>>>> something to meet the MTI but wasn't germane to anything else 
>>>>>>> they intended to
>>>>>> support.
>>>>>>> Bob
>>>>>>> purpose is to reference a set of external specifications by 
>>>>>>> inclusion in an IODEF document, and that those external 
>>>>>>> specifications represent
>>>>>> fundamentally different things.
>>>>>>>> 
>>>>>>> envision an mile-sci implementation that was only interested a 
>>>>>>> subset of these classes (perhaps even only one). If my 
>>>>>>> implementation has an internal representation of Verification, 
>>>>>>> but not of any of the other classes, and the MTI is an 
>>>>>>> enumeration that is applicable to
>>>>>> Vulnerability... what do I do?
>>>>>>>> 
>>>>>>>>>> (mandatory to implement) choice?  In other words, how will 
>>>>>>>>>> you get two interoperability implementations without picking one?
>>>>>>>>>> 
>>>>>>>>>> spt

---

From: "Barnum, Sean D." <[email-masked]>
Date: Wed, 15 Feb 2012 17:03:23 +0000

Agree.

Sean

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Wednesday, February 15, 2012 5:28 AM
To: Takeshi Takahashi
Cc: [email-masked]
Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re:
MTI SCI?)

Hi, Take, all,

On the first point, it does seem the discussion on the list converged rather
quickly to CVE as MTI. However, as this is a rather important point, I'd
like to make sure we didn't miss anything.

So, I'd like to call for consensus on the list. Does the working group agree
on the following two points?

1. mile-sci requires one Mandatory to Implement schema in order to ensure
interoperability.

2. The Mandatory to Implement schema is the Common Vulnerability Enumeration
(CVE) version 1.0, as described in section 4.1.7 of mile-sci-02.

Best regards,

Brian (as chair)

>>>>>> two interoperability implementations without picking one?
<draft-ietf-mile-sci-03candidate_20120215.txt><draft-ietf-mile-sci-03candida
te_20120215.txt.pdf>_______________________________________________

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 16 Feb 2012 17:26:10 -0500

I have not been following this thread as closely as I probably should.  Relative to MTI, is the question what schema should be MTI for the vulerability class?  In general I think we should have one or more MTI for each class.

Relative to CVE specifically, are we talking about the schema currently located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd?

This seems to match the namespace defined in section 4.1.7 of mile-sci-02.  Looking at the implementation of this schema, it looks like the targetNamespace is incorrectly assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be "http://cve.mitre.org/cve/downloads/1.0".  This will likely need to be fixed.

Also, the specification URI points to the CVE website, which is not really a specification.  It's not clear where to find guidance on how to properly use the model indicated by the namespace.  Without having clear guidance on its use I don't see how we can make it MTI, even if it is considered a de facto approach.  It might make sense to produce a specification for the model before making it MTI for the vulnerability class.

Sincerely,
David Waltermire

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Trammell
> Subject: [mile] Discussion / consensus call on CVE as MTI for SCI (was
> Re: MTI SCI?)
> 
> Hi, Take, all,
> 
> On the first point, it does seem the discussion on the list converged
> rather quickly to CVE as MTI. However, as this is a rather important
> point, I'd like to make sure we didn't miss anything.
> 
> 2. The Mandatory to Implement schema is the Common Vulnerability
> Enumeration (CVE) version 1.0, as described in section 4.1.7 of mile-
> sci-02.
> 
> exchange
> > a vulnerability data that is formatted in its own private schema, and
> > that is not formatted in CVE.
> > In this case, the SOC may put the data's schema ID inside ext-SpecID
> > and then embed the data.
> >> At the risk of contradicting myself - but then again I have now read
> >> the other replies to this issue - I agree that having one area be
> the
> >> smoke test makes sense and I also agree that something simple and
> >> commonly used already - like CVE - is the best candidate for what we
> need.
> >>
> >> Bob
> >>
> >> I agree with Tom that CVE is the path of least resistance but may be
> >> the most useful for basic interoperability.
> >>>
> >>> Kent Landfield
> >> mandatory aspect of "advanced IODEF" seems like it would be adding
> >> ammunition to that argument, especially if the CSIRT is having to
> >> fund implementation out of their own pocket. Personally, I would
> have
> >> a hard time asking US-CERT's primary constituents to implement IODEF
> >> + CAPEC if they are already balking at the consultant and developer
> >> resources required to implement RFC 5070 by itself. Also keep in
> mind
> >> that CAPEC references CybOX, so there's wheels within wheels now.
> >>>
> >>> CVE is well known, has years of familiarity built in, and I think
> >>> it's
> >> to be used.  OTOH, it may be useful to have a single simple MTI spec
> >> for SCI that can be used to "smoke test" a deployment before trying
> >> any
> > serious
> >> they aren't going to interoperate, and that situation is unlikely to
> >> be acceptable to the IESG (i.e., with an MTI SCI spec per class, I
> >> suspect that there will also have to be an MTI class, which results
> >> in an overall MTI SCI spec).
> >>>
> spec
> >> document for testing purposes, including enumeration values suitable
> >> for testing).
> >>>
> >>> You beat me to this point.  Like you, I would be concerned about a
> >>> MTI selection that ended up requiring someone to implement
> something
> >>> to meet the MTI but wasn't germane to anything else they intended
> to
> >> support.
> >>> Bob
> >>> implementation has an internal representation of Verification, but
> >>> not of any of the other classes, and the MTI is an enumeration that
> >>> is applicable to
> >>>>>> (mandatory to implement) choice?  In other words, how will you
> >>>>>> get two interoperability implementations without picking one?
> >>>>>>
> >>>>>> spt
> 03c
> andidate_20120215.txt.pdf>____________________________________________
> > ___
> > mile mailing list
> > [email-masked]

---

From: <[email-masked]>
Date: Mon, 20 Feb 2012 06:08:00 -0500

Thank you, Dave.

Dave raises a few very important points as we consider MTI for SCI.  We will need to resolve these issues if CVE is to be the (or an) MTI specification for the SCI draft.

If CVE is mandatory to implement, what guidance would be followed on how to use the model or will MTI only mean that the document can be received and parsed?   The CVE website is listed as the specification URI, but from Dave's message, the specification URI does not exist to provide the guidance (I get to broken link pages for both - the existing and suggested replacement link).

This is the closest I could find and may be the answer for guidance: http://cve.mitre.org/compatible/requirements.html

It looks like the reference to the target namespace needs to be fixed as well.

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Waltermire, David A. [[email-masked]]
Sent: Thursday, February 16, 2012 5:26 PM
To: Brian Trammell; Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re:  MTI SCI?)

Sincerely,
David Waltermire

---

From: Jeff Reed <[email-masked]>
Date: Mon, 20 Feb 2012 18:27:14 -0800

Take,

   Should your suggested text:

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

   ...be changes to:

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

   ...in the context of this discussion?

   Kind regards,

   Jeff Reed

On Wed, Feb 15, 2012 at 1:15 AM, Takeshi Takahashi <
[email-masked]> wrote:

> > Martin, Robert A.

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 21 Feb 2012 10:40:27 +0900

Hello all,

Thank you for your kind comments, which are really useful for me.
On the other hand, I have some difficulties to understand what people
specifically mean by "support" or "mandatory".
I would appreciate if you could kindly give me some comments on below.

Below are my views on the MTI issues.

1.	All the specification namespaces listed in the table MUST be
"supported" as values for the SpecID field.

These namespaces are the allowed ENUM values.
So, in a way, all the specification listed in the table are supported.
(implementations must allow these namespaces of all the specifications
listed in the table as values for SpecID field)
Since all the specification listed in the table are supported, we need to
have expert review before registration (as we discussed in Quebec City)

In this way, receivers can correctly understand the data.
That will give us the same level of interoperability as the RFC 5070 (IODEF)
does between sender and receiver, I think.

2.	Implementers have freedom to define how to parse, how to understand,
and how to respond the IODEF extension message

I might be wrong, but I do not think we would like to define how to parse
the IODEF extension message at the receiver side.
And I do not think we would like to define how to parse, for instance, CAPEC
data, at the receiver side.
I think the SCI draft is a container that conveys these structured
information, and it can see such information as a blackbox with a tag
(namespace information).

If above understanding is correct, I have some difficulty to understand the
meaning of "mandatory to support CVE".
As described in issue 1 above, if CVE or CAPEC data is attached, the
implementation needs to recognize that the data is in CVE/CAPEC format, and
that is the requirement for the implementation.
What else do we want to mandate here, specifically?
Do we need to manipulate the embedded xml data itself? I rather prefer to
handle the data as a blackbox.

I appreciate your kind comments.
Regarding the other point Dave kindly pointed out, let me have another
thread. (sorry I need to get on board now...)

Thank you.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 20, 2012 8:08 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (was
Re: MTI SCI?)

Thank you, Dave.

Dave raises a few very important points as we consider MTI for SCI.  We will
need to resolve these issues if CVE is to be the (or an) MTI specification
for the SCI draft.

If CVE is mandatory to implement, what guidance would be followed on how to
use the model or will MTI only mean that the document can be received and
parsed?   The CVE website is listed as the specification URI, but from
Dave's message, the specification URI does not exist to provide the guidance
(I get to broken link pages for both - the existing and suggested
replacement link).

This is the closest I could find and may be the answer for guidance:
http://cve.mitre.org/compatible/requirements.html

It looks like the reference to the target namespace needs to be fixed as
well.

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Waltermire,
David A. [[email-masked]]
Sent: Thursday, February 16, 2012 5:26 PM
To: Brian Trammell; Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was
Re:  MTI SCI?)

I have not been following this thread as closely as I probably should.
Relative to MTI, is the question what schema should be MTI for the
vulerability class?  In general I think we should have one or more MTI for
each class.

Relative to CVE specifically, are we talking about the schema currently
located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd?

This seems to match the namespace defined in section 4.1.7 of mile-sci-02.
Looking at the implementation of this schema, it looks like the
targetNamespace is incorrectly assigned to
"http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be
"http://cve.mitre.org/cve/downloads/1.0".  This will likely need to be
fixed.

Also, the specification URI points to the CVE website, which is not really a
specification.  It's not clear where to find guidance on how to properly use
the model indicated by the namespace.  Without having clear guidance on its
use I don't see how we can make it MTI, even if it is considered a de facto
approach.  It might make sense to produce a specification for the model
before making it MTI for the vulnerability class.

Sincerely,
David Waltermire

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Brian Trammell
> > a vulnerability data that is formatted in its own private schema, 
> > and that is not formatted in CVE.
> >> read the other replies to this issue - I agree that having one area 
> >> be
> the
> >> to be acceptable to the IESG (i.e., with an MTI SCI spec per class, 
> >> I suspect that there will also have to be an MTI class, which 
> >> results in an overall MTI SCI spec).
> >>>
> >> is CAPEC, as Youki suggested, the appendix could contain a CAPEC 
> >> XML document for testing purposes, including enumeration values 
> >> suitable for testing).
> >>>
> >>> not of any of the other classes, and the MTI is an enumeration 
> >>> that is applicable to

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 11:00:19 -0600

Take,

I think you've done a very good job of explaining the two different interpretations around this call for consensus.

My interpretation of MTI was closer to #2 - that to support this draft, an implementer would have to support not only recognition of the namespace in the appropriate IODEF parent class context, but also be able to parse the content of the referenced namespace. Hence my preference for a relatively simple and familiar spec as the MTI.

If we can concur that we all really mean the interpretation you describe under #1, then I'm okay with having an MTI for each class. What that says to me is that each implementer would need to conform to the SCI draft's class placement of each namespace, but not necessarily have to be able to interpret the contents of said namespace(s). So all I have to do, minimally, is recognize the class under which any of the referenced namespaces exist; I don't have to have any means to parse or handle that class content other than bucket it and move on to the next. Is that right?

I would recommend that we be very clear in regards to what "support" or "minimally support" mean so that technical requirements handed down based on this draft do not bar achievement by operational implementers and their engineering teams.

Thanks again,

 - Tom Millar, US-CERT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Monday, February 20, 2012 20:40
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?)

Hello all,

Thank you for your kind comments, which are really useful for me.
On the other hand, I have some difficulties to understand what people specifically mean by "support" or "mandatory".
I would appreciate if you could kindly give me some comments on below.

These namespaces are the allowed ENUM values.
So, in a way, all the specification listed in the table are supported.
(implementations must allow these namespaces of all the specifications listed in the table as values for SpecID field) Since all the specification listed in the table are supported, we need to have expert review before registration (as we discussed in Quebec City)

In this way, receivers can correctly understand the data.
That will give us the same level of interoperability as the RFC 5070 (IODEF) does between sender and receiver, I think.

I might be wrong, but I do not think we would like to define how to parse the IODEF extension message at the receiver side.
And I do not think we would like to define how to parse, for instance, CAPEC data, at the receiver side.
I think the SCI draft is a container that conveys these structured information, and it can see such information as a blackbox with a tag (namespace information).

If above understanding is correct, I have some difficulty to understand the meaning of "mandatory to support CVE".
As described in issue 1 above, if CVE or CAPEC data is attached, the implementation needs to recognize that the data is in CVE/CAPEC format, and that is the requirement for the implementation.
What else do we want to mandate here, specifically?
Do we need to manipulate the embedded xml data itself? I rather prefer to handle the data as a blackbox.

I appreciate your kind comments.
Regarding the other point Dave kindly pointed out, let me have another thread. (sorry I need to get on board now...)

Thank you.

Take

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 20, 2012 8:08 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (was
Re: MTI SCI?)

Thank you, Dave.

If CVE is mandatory to implement, what guidance would be followed on how to use the model or will MTI only mean that the document can be received and
parsed?   The CVE website is listed as the specification URI, but from
Dave's message, the specification URI does not exist to provide the guidance (I get to broken link pages for both - the existing and suggested replacement link).

Thank you,
Kathleen

I have not been following this thread as closely as I probably should.
Relative to MTI, is the question what schema should be MTI for the vulerability class?  In general I think we should have one or more MTI for each class.

This seems to match the namespace defined in section 4.1.7 of mile-sci-02.
Looking at the implementation of this schema, it looks like the targetNamespace is incorrectly assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be "http://cve.mitre.org/cve/downloads/1.0".  This will likely need to be fixed.

Sincerely,
David Waltermire

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 12:48:35 -0500

Hi Tom,

I believe I agree with you, although I'd like to add some precision on what is meant
by "parse".

I don't think it's sufficient to support the value in the SpecID field (e.g., a CVE
version) and accept an XML blob that is not a well-formed CVE XML document.

Hence, I think the minimum requirement is to validate the received SCI XML document
against the appropriate XML schema and detect any errors.

Beyond that, Take's reference to RFC 5070 is a useful source of insight, as I think it
rules out most additional requirements. IODEF is a format, not a protocol, so:

        A) Error reporting is specific to whatever transport protocol is being used.
                For example, if RID is used, the rfc6046-bis draft specifies how to
                report errors, but there's no RFC 5070 requirement that IODEF use RID.
                Beyond error detection, it's not possible to specify a required error
                reporting mechanism.

        B) RFC 5070 has nothing to say about replies or responses to IODEF, so the
                same should be true of extensions like SCI.

        C) I'm not sure I understand what Take had in mind by "how to understand" in
                #2.  I see no need to understand CVE semantics or meaning beyond the CVE
                syntax check obtained by validating the received document against the
                CVE XML schema.

> I would recommend that we be very clear in regards to what "support" or "minimally support" mean so
> that technical requirements handed down based on this draft do not bar achievement by operational
> implementers and their engineering teams.

I agree and would suggest:

        - The CVE SpecID value and related values (e.g., namespace) MUST
                be supported (not cause errors if used).
        - Recipient MUST validate received CVE XML document against the CVE
                XML schema to detect invalid CVE documents.

I assume that this is all about CVE 1.0.

Does all of this make sense?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, February 21, 2012 12:00 PM
> To: [email-masked]; Moriarty, Kathleen; [email-masked]; [email-masked];
> My interpretation of MTI was closer to #2 - that to support this draft, an implementer would have to
> support not only recognition of the namespace in the appropriate IODEF parent class context, but also
> be able to parse the content of the referenced namespace. Hence my preference for a relatively simple
> and familiar spec as the MTI.
>
> If we can concur that we all really mean the interpretation you describe under #1, then I'm okay with
> having an MTI for each class. What that says to me is that each implementer would need to conform to
> the SCI draft's class placement of each namespace, but not necessarily have to be able to interpret
> the contents of said namespace(s). So all I have to do, minimally, is recognize the class under which
> any of the referenced namespaces exist; I don't have to have any means to parse or handle that class
> content other than bucket it and move on to the next. Is that right?
>
> I would recommend that we be very clear in regards to what "support" or "minimally support" mean so
> that technical requirements handed down based on this draft do not bar achievement by operational
> implementers and their engineering teams.
>
> Thanks again,
>
>  - Tom Millar, US-CERT
>
> (implementations must allow these namespaces of all the specifications listed in the table as values
> for SpecID field) Since all the specification listed in the table are supported, we need to have
> expert review before registration (as we discussed in Quebec City)
>
> I think the SCI draft is a container that conveys these structured information, and it can see such
> information as a blackbox with a tag (namespace information).
>
> As described in issue 1 above, if CVE or CAPEC data is attached, the implementation needs to recognize
> that the data is in CVE/CAPEC format, and that is the requirement for the implementation.
> Dave raises a few very important points as we consider MTI for SCI.  We will need to resolve these
> issues if CVE is to be the (or an) MTI specification for the SCI draft.
>
> If CVE is mandatory to implement, what guidance would be followed on how to use the model or will MTI
> only mean that the document can be received and
> Dave's message, the specification URI does not exist to provide the guidance (I get to broken link
> pages for both - the existing and suggested replacement link).
>
> Relative to MTI, is the question what schema should be MTI for the vulerability class?  In general I
> think we should have one or more MTI for each class.
>
> Relative to CVE specifically, are we talking about the schema currently located at:
> http://cve.mitre.org/schema/cve/cve_1.0.xsd?
>
> Looking at the implementation of this schema, it looks like the targetNamespace is incorrectly
> assigned to "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be
> "http://cve.mitre.org/cve/downloads/1.0".  This will likely need to be fixed.
>
> Also, the specification URI points to the CVE website, which is not really a specification.  It's not
> clear where to find guidance on how to properly use the model indicated by the namespace.  Without
> having clear guidance on its use I don't see how we can make it MTI, even if it is considered a de
> facto approach.  It might make sense to produce a specification for the model before making it MTI for
> the vulnerability class.
>
> Sincerely,
> David Waltermire
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 21 Feb 2012 15:56:59 -0500

For all referenced models, a larger concern is referencing a website for guidance.  A website can be inherantly unstable, as it can be changed at any time, and does not necessarily represent a consensous opinion.  One possibility might be to reference a standards track document that specified the use of the model.  In addition the referenced document could possibly provide some parsing instructions for the model addressing some of the concerns from the other discussion thread.  This would require new work to be completed before completing the SCI document, but would provide a more concrete foundation for interoperable information exchange.

Any thoughts on this approach?

Sincerely,
David Waltermire

> Sent: Monday, February 20, 2012 6:08 AM
> To: Waltermire, David A.; [email-masked];
> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI
> (was Re: MTI SCI?)
>
> Thank you, Dave.
>
> Dave raises a few very important points as we consider MTI for SCI.  We
> will need to resolve these issues if CVE is to be the (or an) MTI
> specification for the SCI draft.
>
> If CVE is mandatory to implement, what guidance would be followed on
> how to use the model or will MTI only mean that the document can be
> received and parsed?   The CVE website is listed as the specification
> URI, but from Dave's message, the specification URI does not exist to
> provide the guidance (I get to broken link pages for both - the
> existing and suggested replacement link).
>
> From: [email-masked] [[email-masked]] On Behalf Of
> Waltermire, David A. [[email-masked]]
> vulerability class?  In general I think we should have one or more MTI
> for each class.
>
> This seems to match the namespace defined in section 4.1.7 of mile-sci-
> 02.  Looking at the implementation of this schema, it looks like the
> "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it
> should be "http://cve.mitre.org/cve/downloads/1.0".  This will likely
> need to be fixed.
>
> Also, the specification URI points to the CVE website, which is not
> really a specification.  It's not clear where to find guidance on how
> to properly use the model indicated by the namespace.  Without having
> clear guidance on its use I don't see how we can make it MTI, even if
> it is considered a de facto approach.  It might make sense to produce a
> specification for the model before making it MTI for the vulnerability
> class.
>
> Sincerely,
> David Waltermire
>
> group
> > agree on the following two points?
> >
> allow
> > >      specifying the format of the RawData element.  The value
> should
> > be
> area
> > >> "[email-masked]<mailto:Thomas.Millar@us-
> cert.gov>"<Thoma
> > >> s
> > >> .M
> class,
> a
> but

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 15:17:31 -0600

Should a recipient be required to validate a referenced schema even if they don't intend to interpret the content?

 - Tom Millar, US-CERT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2012 12:49
To: [email-masked]; Millar, Thomas R
Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?)

Hi Tom,

I believe I agree with you, although I'd like to add some precision on what is meant by "parse".

Hence, I think the minimum requirement is to validate the received SCI XML document against the appropriate XML schema and detect any errors.

Beyond that, Take's reference to RFC 5070 is a useful source of insight, as I think it rules out most additional requirements. IODEF is a format, not a protocol, so:

> I would recommend that we be very clear in regards to what "support" 
> or "minimally support" mean so that technical requirements handed down 
> based on this draft do not bar achievement by operational implementers and their engineering teams.

Thanks,
--David

> Of [email-masked]
> To: [email-masked]; Moriarty, Kathleen; 
> [email-masked]; [email-masked]; 
> I think you've done a very good job of explaining the two different 
> interpretations around this call for consensus.
>
> My interpretation of MTI was closer to #2 - that to support this 
> draft, an implementer would have to support not only recognition of 
> the namespace in the appropriate IODEF parent class context, but also 
> be able to parse the content of the referenced namespace. Hence my preference for a relatively simple and familiar spec as the MTI.
>
> If we can concur that we all really mean the interpretation you 
> describe under #1, then I'm okay with having an MTI for each class. 
> What that says to me is that each implementer would need to conform to 
> the SCI draft's class placement of each namespace, but not necessarily 
> have to be able to interpret the contents of said namespace(s). So all 
> I have to do, minimally, is recognize the class under which any of the referenced namespaces exist; I don't have to have any means to parse or handle that class content other than bucket it and move on to the next. Is that right?
>
> I would recommend that we be very clear in regards to what "support" 
> or "minimally support" mean so that technical requirements handed down 
> based on this draft do not bar achievement by operational implementers and their engineering teams.
>
> Thanks again,
>
>  - Tom Millar, US-CERT
>
> Of Takeshi Takahashi
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> listed in the table as values for SpecID field) Since all the 
> specification listed in the table are supported, we need to have 
> That will give us the same level of interoperability as the RFC 5070 
> (IODEF) does between sender and receiver, I think.
>
>
> I might be wrong, but I do not think we would like to define how to 
> parse the IODEF extension message at the receiver side.
> information, and it can see such information as a blackbox with a tag (namespace information).
>
> If above understanding is correct, I have some difficulty to 
> understand the meaning of "mandatory to support CVE".
> implementation needs to recognize that the data is in CVE/CAPEC format, and that is the requirement for the implementation.
> (was
> Dave raises a few very important points as we consider MTI for SCI.  
> We will need to resolve these issues if CVE is to be the (or an) MTI specification for the SCI draft.
>
> how to use the model or will MTI only mean that the document can be received and
> Dave's message, the specification URI does not exist to provide the 
> guidance (I get to broken link pages for both - the existing and suggested replacement link).
>
> vulerability class?  In general I think we should have one or more MTI for each class.
>
> "http://cve.mitre.org/cve/downloads/xml_schema_info.html" when it should be "http://cve.mitre.org/cve/downloads/1.0".  This will likely need to be fixed.
>
> it is considered a de facto approach.  It might make sense to produce a specification for the model before making it MTI for the vulnerability class.
>
> Sincerely,
> David Waltermire
>
> > On the first point, it does seem the discussion on the list 
> > converged rather quickly to CVE as MTI. However, as this is a rather 
> > important point, I'd like to make sure we didn't miss anything.
> >
> > group agree on the following two points?
> >
> > Enumeration (CVE) version 1.0, as described in section 4.1.7 of 
> > mile- sci-02.
> >
> > > sentences
> > >> area be
> > >> "[email-masked]<mailto:[email-masked]>"<Tho
> > >> ma
> > >> s
> > >> .M
> > >> "[email-masked]<mailto:[email-masked]>"<david.black@emc
> > >> .c
> > >> o
> > >> m<
> > >> "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:mile@i
> > >> et
> > >> f
> > >> .o
> > >>> rg>>
> > >> Personally, I would
> > >> + CAPEC if they are already balking at the consultant and 
> > >> + developer

---

From: "Martin, Robert A." <[email-masked]>
Date: Tue, 21 Feb 2012 16:20:02 -0500

I would like to offer that for some of the "ID" like things (i.e. CVE 
ID, CWE ID, and CAPEC ID) there may not be a need for an xml document 
and we may want to simplify those construct in SCI.

Most people who send a CVE ID send a ascii text string 'CVE-xxx-xxxx' 
and assume that the reciever knows that there is a well established cgi 
url 'http://cve.mitre.org/cgi-bin/cvename.cgi?name=xxxx-xxxx' where the 
recipient can look up the details about CVE-xxxx-xxxx.

CWE and CAPEC IDs have a similar well known address to resolve their IDs at.

Bob

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 16:36:55 -0500

Hi all,

I think we have 2 possible issues to help break down this question.

1)  If you think about what we actually use CVE for, do we want to pass the content of CVE around or for this case, just provide a CVE number and perhaps a reference URL?  Or do we want to set options and guidance for handling both use cases (just an enumerated value and reference URL and the use of another schema to extend the possible set of data elements).

For the CVE enumeration use case, we may want to consider creating tight guidance on how the Reference class of IODEF is used.  We could set the string value to be CVE and the number, roving strict guidance on how that would be represented.  Then also using the Reference URL.

There are other schemas in SCI where we clearly want to have the ability to include a document created by another schema.

2)  When you extend to use a schema, for the most part, we might think about this as a black box.  IODEF already has guidance to handle the use case of what to do when there its a schema that is included that cannot be parsed (already provided on list).  We are taking another step with the SCI draft - I am in agreement with David on this for the meaning of MTI.  I *think* the MTI use case is not to take away from the black box concept, but to test one instance of where the module can be parsed by the receiving node.  This helps us understand that this capability would work for any other module that uses the same approach.  Only one specification would be MTI, so the others may not be implemented and may respond via the guidance in IODEF.

The result of this conversation will help us understand what it means to be compliant with SCI.  If we are compliant with IODEF, then we have guidance to follow the use case where we can't parse something.

Then we need to figure out if CVE is the right schema for this and what we need to have appropriate guidance for that to really work - specification and schema (David Waltermire's points)?

Thanks,
Kathleen

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, February 21, 2012 4:17 PM
To: Black, David; [email-masked]
Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI   (wasRe: MTI SCI?)

 - Tom Millar, US-CERT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 21, 2012 12:49
To: [email-masked]; Millar, Thomas R
Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (wasRe: MTI SCI?)

Hi Tom,

Thanks,
--David

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 16:37:18 -0500

I agree, however, why don't we have the SCI draft provide guidance on what would be expected when the enumerations were included in IODEF using the Reference class for each of these rather than creating an extension for this use case?

Thank you,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Martin, Robert A. [[email-masked]]
Sent: Tuesday, February 21, 2012 4:20 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?)

Bob

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 18:47:28 -0500

A "smoke test" is one of the motivations for this MTI requirement - for that,
validation of the received content (e.g., against an XML schema for XML content)
should be required, as one usually wants to know that the "smoke" made it
through ok (the "smoke" that arrived matches what was sent).

So, even if the content will only be used as "smoke test" evidence, and not
otherwise interpreted, it's still a good idea to require format validation.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2012 4:18 PM
> Hence, I think the minimum requirement is to validate the received SCI XML document against the
> appropriate XML schema and detect any errors.
>
> Beyond that, Take's reference to RFC 5070 is a useful source of insight, as I think it rules out most
> additional requirements. IODEF is a format, not a protocol, so:
>
> > I have to do, minimally, is recognize the class under which any of the referenced namespaces exist;
> I don't have to have any means to parse or handle that class content other than bucket it and move on
> to the next. Is that right?
> >
> > it is considered a de facto approach.  It might make sense to produce a specification for the model

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 18:59:56 -0500

> For all referenced models, a larger concern is referencing a website for guidance.  A website can be
> inherently unstable, as it can be changed at any time, and does not necessarily represent a consensus
> opinion.

I concur with the need for a stable reference for guidance on SCI spec usage, as
the guidance could be quite important (e.g., prior discussion on how to use MAEC
in two different ways as an SCI).  FWIW, I recently discovered independently that
IETF doesn't consider Wikipedia to be a stable reference ;-).

Putting the guidance for usage of the initial specs into the SCI draft sounds like
a good idea, especially as the IANA registry entries for all of those initial specs
will point back to that draft (as an RFC), which should make the guidance easy to
find for implementers.

Beyond that I'm going to split a hair :-).  An RFC is a good stable guidance reference,
but an informational RFC (as opposed to standards track) may suffice.  I'd suggest
deferring that decision in favor of figuring out what the guidance needs to cover.

How does that sound?

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Waltermire, David A.
> Sent: Tuesday, February 21, 2012 3:57 PM
> To: Moriarty, Kathleen; [email-masked]; [email-masked]
> Cc: [email-masked]
> For all referenced models, a larger concern is referencing a website for guidance.  A website can be
> inherantly unstable, as it can be changed at any time, and does not necessarily represent a consensous
> opinion.  One possibility might be to reference a standards track document that specified the use of
> the model.  In addition the referenced document could possibly provide some parsing instructions for
> the model addressing some of the concerns from the other discussion thread.  This would require new
> work to be completed before completing the SCI document, but would provide a more concrete foundation
> for interoperable information exchange.
>
> > developer

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Feb 2012 10:32:37 +0100

Greetings, all,

First, I'm very happy to see this productive discussion. Thank you all! As chair, it's clear to me there's not consensus on these points yet (from the original call):

1. mile-sci requires one Mandatory to Implement schema in order to
ensure interoperability.

and that the discussion should continue; I'll call for consensus again once the working group has explored and understood the issues, and converges on a solution.

I may have misunderstood the intent of -sci as it stands, and I apologize for the consensus call being based on my unstated assumption that the content of a "CVE object" in an IODEF document would be a _reference_ (as in Kathleen's point 1, below); indeed, I didn't even consider the possibility that someone might want to move the _content_ around  via IODEF, and this assumption clearly colored my reading of the document.

Best regards,

Brian (as co-chair)

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Feb 2012 10:34:34 +0100

Greetings, all,

Taking my chair hat off, putting my contributor hat on now:

I like Kathleen's suggestion, and would extend it: do we want to consider explicitly considering the question from the standpoint of "reference" separately from "containment". For things like CVE, a CVE identifier is de facto operationally assumed to be a stable reference to a static resource. (The stability of a CVE reference is probably _not_ such that it could be used as a normative reference within the IETF; however, it is as far as I know still common practice to treat it as such in incident handling.)

Interoperability for a reference then is tested by the following two conditions:

1. an IODEF + SCI producer can take its internal representation of an SCI object and convert it to a reference in a standard representation which can be dereferenced by the consumer, perhaps relying on a connection to an external resource.

2. an IODEF + SCI consumer can take a reference in a standard representation from the IODEF document and deference it into its internal representation of a substantially identical SCI object, perhaps relying on a connection to an external resource.

Considering the question from the content angle, interoperability looks a bit more straightforward to test:

1. an IODEF + SCI producer can take its internal representation of an SCI object and convert it into an XML element embedded in an IODEF document.

2. an IODEF + SCI consumer can convert an XML element embedded in an IODEF Document and convert it into its internal representation of a substantially identical SCI object.

This raises another issue, though. Let's say I send content about an incident involving an exploit of CVE-2011-4692, a remote root vulnerability in OpenBSD exploitable by sending a specific sequence of unsolicited UDP packets. The receiver parses this and now knows that one of my OpenBSD boxes got rooted by a magic packet attack exploiting CVE-2011-4692. So the implementations are interoperable. Right? 

Well, no. According to http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4692, this is a WebKit browser cache information leak vulnerability. So you can't sensibly define interoperability in terms of content without reference to the static resource. What do I do as a receiver when I get information in content that conflicts with information in the referenced resource?

I suspect this is the case with most if not all of the enumerations covered by SCI. I don't have deep familiarity with all the enumerations: how many of these are commonly exchanged as references, and how many as content? For those which are generally exchanged by reference, it would seem to make sense to test "implementation" based on handling references, and not content.

Thoughts?

Brian (as contributor)

---

From: "Martin, Robert A." <[email-masked]>
Date: Wed, 22 Feb 2012 07:03:44 -0500

Brian,

I am confused.

Unlike the two texts you quoted I found the exact same text from that 
CVE at the CVE site and the NVD site.

Bob

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4692

WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 
and earlier, does not prevent capture of data about the time required 
for image loading, which makes it easier for remote attackers to 
determine whether an image exists in the browser cache via crafted 
JavaScript code, as demonstrated by visipisi.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4692

WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 
and earlier, does not prevent capture of data about the time required 
for image loading, which makes it easier for remote attackers to 
determine whether an image exists in the browser cache via crafted 
JavaScript code, as demonstrated by visipisi.

On 2/22/12 4:34 AM, Brian Trammell wrote:
> On Feb 22, 2012, at 12:47 AM,<[email-masked]>  <[email-masked]>  wrote:
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Feb 2012 13:21:00 +0100

hi, Bob,

sorry if the example wasn't clear: the point is, yes, it's a (real) WebKit vuln, not a (hypothetical) openbsd kernel vuln, but a test for interop at the content level without reference to the canonical enumeration would lead to syntactically accurate nonsense...

regards, Brian

Sent from my iPhone

On 22.02.2012, at 13:03, "Martin, Robert A." <[email-masked]> wrote:

> Brian,
> 
> I am confused.
> 
> Unlike the two texts you quoted I found the exact same text from that CVE at the CVE site and the NVD site.
> 
> Bob
> 
> WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 and earlier, does not prevent capture of data about the time required for image loading, which makes it easier for remote attackers to determine whether an image exists in the browser cache via crafted JavaScript code, as demonstrated by visipisi.
> 
> WebKit, as used in Apple Safari 5.1.1 and earlier and Google Chrome 15 and earlier, does not prevent capture of data about the time required for image loading, which makes it easier for remote attackers to determine whether an image exists in the browser cache via crafted JavaScript code, as demonstrated by visipisi.
> 
>>>>>> important point, I'd like to make sure we di

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 23 Feb 2012 03:05:36 +0900

I'm generally in favor of the kind opinions from Tom and David.
IMHO, the sentence David kindly provided could be changed as below:

In order to be compliant with SCI draft, the implementations need to suffice
below:

1. The CVE SpecID value and related values (e.g., namespace) MUST be
supported (not cause errors if used).
2. Recipient MUST "be capable of" validating received CVE 1.0 XML document
against the CVE 1.0 XML schema to detect invalid CVE documents.

I think the receiver needs to be capable of validating received CVE XML for
the smoke test purpose, but I am not sure whether we should mandate the
validation process to the receiver.
When operation processes are automated, validation process could be
implemented elsewhere (for instance, data generation unit could do the
validation).
So, I think the SCI draft could mandates the capability, instead of the
process.

Does it make sense?

Thank you.
Take

> Sent: Wednesday, February 22, 2012 8:47 AM
> To: [email-masked]; [email-masked]
> A "smoke test" is one of the motivations for this MTI requirement - for
> that, validation of the received content (e.g., against an XML schema
> for XML content) should be required, as one usually wants to know that
> the "smoke" made it through ok (the "smoke" that arrived matches what
> was sent).
> 
> So, even if the content will only be used as "smoke test" evidence, and
> not otherwise interpreted, it's still a good idea to require format
> validation.
> 
> Thanks,
> --David
> 
> > (wasRe: MTI SCI?)
> > Should a recipient be required to validate a referenced schema even
> if
> > they don't intend to interpret the content?
> >
> >  - Tom Millar, US-CERT
> >
> > (wasRe: MTI SCI?)
> > Hence, I think the minimum requirement is to validate the received SCI
> > XML document against the appropriate XML schema and detect any errors.
> >
> > Beyond that, Take's reference to RFC 5070 is a useful source of
> > insight, as I think it rules out most additional requirements. IODEF
> is a format, not a protocol, so:
> >
> > > or "minimally support" mean so that technical requirements handed
> > > down based on this draft do not bar achievement by operational
> > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.,
> > Hopkinton, MA  01748
> > > the namespace in the appropriate IODEF parent class context, but
> > > also be able to parse the content of the referenced namespace. Hence
> > > my preference for a relatively
> > simple and familiar spec as the MTI.
> > >
> > > What that says to me is that each implementer would need to conform
> > > to the SCI draft's class placement of each namespace, but not
> > > necessarily have to be able to interpret the contents of said
> > > namespace(s). So all I have to do, minimally, is recognize the class
> > > under which any of the referenced namespaces exist;
> > I don't have to have any means to parse or handle that class content
> > other than bucket it and move on to the next. Is that right?
> > >
> > > or "minimally support" mean so that technical requirements handed
> > > down based on this draft do not bar achievement by operational
> > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI for
> > > SCI
> > > (wasRe: MTI SCI?)
> > >
> > > Hello all,
> > >
> > > (implementations must allow these namespaces of all the
> > > specifications listed in the table as values for SpecID field) Since
> > > all the specification listed in the table are supported, we need to
> > > And I do not think we would like to define how to parse, for
> > > instance, CAPEC data, at the receiver side.
> > > implementation needs to recognize that the data is in CVE/CAPEC
> > > format, and that is the requirement
> > for the implementation.
> > > Regarding the other point Dave kindly pointed out, let me have
> > > another thread. (sorry I need to get on board now...)
> > >
> > > Thank you.
> > >
> > > Take
> > >
> > >
> > >
> > >
> > > We will need to resolve these issues if CVE is to be the (or an) MTI
> received and
> located at:
> > > should be
> > > really a specification.  It's not clear where to find guidance on
> > > how to properly use the model indicated by the namespace.  Without
> > > having clear guidance on its use I don't see how we can make it MTI,
> > > even if it is considered a de facto approach.  It might make sense
> > > to produce a specification for the model
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf Of Brian Trammell
> > > > converged rather quickly to CVE as MTI. However, as this is a
> > > > rather important point, I'd like to make sure we didn't miss
anything.
> > > > > I've attached the working version of the draft. I hope it helps
> > > > > to clarify the changes.
> > > > >
> > > > >   support, it may expand its functionality by looking up the
> > > > > IANA
> > > > table or
> > > > > On the other hand, I would like to add "STRING ext-SpecID" to
> > > > > each class, which enables to embed data following private schema.
> > > > > a vulnerability data that is formatted in its own private
> > > > >> smoke test makes sense and I also agree that something simple
> > > > >> and commonly used already - like CVE - is the best candidate
> > > > >> for what we
> > > > need.
> > > > >>
> > > > >> Bob
> > > > >>
> > > > >> I agree with Tom that CVE is the path of least resistance but
> > > > >> may be the most useful for basic interoperability.
> > > > >>>
> > > > >>> Kent Landfield
> > > > >> effective operational uptake of IODEF-SCI as the CAPEC
> > > > >> vocabulary remains "too comprehensive" for many CSIRTs to
> > > > >> employ during
> > > > incident
> > > > >> spec for SCI that can be used to "smoke test" a deployment
> > > > >> before trying any
> > > > > serious
> > > > >> they aren't going to interoperate, and that situation is
> > > > >> unlikely to be acceptable to the IESG (i.e., with an MTI SCI
> > > > >> spec per class, I suspect that there will also have to be an
> > > > >> MTI class, which results in an overall MTI SCI spec).
> > > > >>>
> > > > >> is CAPEC, as Youki suggested, the appendix could contain a
> > > > >>> You beat me to this point.  Like you, I would be concerned
> > > > >>> about a MTI selection that ended up requiring someone to
> > > > >>> implement
> > > > something
> > > > >>>>> Great - as long as we pick one as the MTI.  Note that MTI
> is
> > > > >>>>> not
> > > > >>>>>> There's 17 listed SCI (Structured Cybersecurity
> > > > >>>>>> Information) specifications in draft-ietf-mile-sci.  Which
> > > > >>>>>> one is the MTI (mandatory to implement) choice?  In other
> > > > >>>>>> words, how will you get two interoperability implementations
> without picking one?
> > > > >>>>>>
> > > > >>>>>> spt
> <draft-ietf-mile-sci-03candidate_20120215.txt><draft-ietf-mile-s
> > > > > ci
> > > > > -
> > > > 03c
> > > > >
> > > >
> andidate_20120215.txt.pdf>________________________________________
> > > > __
> > > > __
> > > > > ___
> > > > > mile mailing list
> > > > > [email-masked]

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 23 Feb 2012 03:05:36 +0900

Hi Jeff,

Thank you for your kind correction.
I appreciate feedbacks.

Kind Regards,
Take

From: Jeff Reed [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2012 11:27 AM
To: Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] MTI SCI?

Take,

   ...be changes to:

   Kind regards,

   Jeff Reed

On Wed, Feb 15, 2012 at 1:15 AM, Takeshi Takahashi
<[email-masked]> wrote:
Hello all,

Sincerely,
Take

> > Direct: +1.972.963.7096 <tel:%2B1.972.963.7096> 
> > Mobile: +1.817.637.8026 <tel:%2B1.817.637.8026> 
perspective)
serious
common,

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 23 Feb 2012 03:35:37 +0900

I understand and agree on the concern Dave kindly provided.

By the way, in Sci02 draft, multiple URI could be described in the
"Specification URI" field of the IANA table. (See section 6)
(Sci01 draft allowed only one URI for the field, but I changed when
publishing Sci02 draft.)

Specification URI: A list of one or more of the URIs [RFC3986]
from which the registered specification can be obtained. The
registered specification MUST be readily and publicly available
from that URI. (Section 6)

So, informational RFC that describes the usage of the specifications, as
well as the original specification, could be described in the field.

Thank you.
Take

> Sent: Wednesday, February 22, 2012 9:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mile] Guidance on SCI usage
> 
> > For all referenced models, a larger concern is referencing a website
> > for guidance.  A website can be inherently unstable, as it can be
> > changed at any time, and does not necessarily represent a consensus
> opinion.
> 
> I concur with the need for a stable reference for guidance on SCI spec
> usage, as the guidance could be quite important (e.g., prior discussion
> on how to use MAEC in two different ways as an SCI).  FWIW, I recently
> discovered independently that IETF doesn't consider Wikipedia to be a
> stable reference ;-).
> 
> Putting the guidance for usage of the initial specs into the SCI draft
> sounds like a good idea, especially as the IANA registry entries for all
> of those initial specs will point back to that draft (as an RFC), which
> should make the guidance easy to find for implementers.
> 
> Beyond that I'm going to split a hair :-).  An RFC is a good stable
guidance
> reference, but an informational RFC (as opposed to standards track) may
> suffice.  I'd suggest deferring that decision in favor of figuring out
> what the guidance needs to cover.
> 
> How does that sound?
> 
> Thanks,
> --David
> 
> Of Waltermire, David A.
> > For all referenced models, a larger concern is referencing a website
> > for guidance.  A website can be inherantly unstable, as it can be
> > changed at any time, and does not necessarily represent a consensous
> > opinion.  One possibility might be to reference a standards track
> > document that specified the use of the model.  In addition the
> > referenced document could possibly provide some parsing instructions
> > for the model addressing some of the concerns from the other discussion
> thread.  This would require new work to be completed before completing
> the SCI document, but would provide a more concrete foundation for
> interoperable information exchange.
> >
> > > Subject: RE: [mile] Discussion / consensus call on CVE as MTI for
> > > SCI (was Re: MTI SCI?)
> > >
> > > Thank you, Dave.
> > >
> > > URI, but from Dave's message, the specification URI does not exist
> > > to provide the guidance (I get to broken link pages for both - the
> > > SCI (was Re:  MTI SCI?)
> > > Relative to CVE specifically, are we talking about the schema
> > > currently located at: http://cve.mitre.org/schema/cve/cve_1.0.xsd?
> > >
> > > This seems to match the namespace defined in section 4.1.7 of
> > > mile-sci- 02.  Looking at the implementation of this schema, it
> > > looks like the targetNamespace is incorrectly assigned to
> > > should be "http://cve.mitre.org/cve/downloads/1.0".  This will
> > > likely need to be fixed.
> > >
> > > to produce a specification for the model before making it MTI for
> > > the vulnerability class.
> > >
> > > Sincerely,
> > > David Waltermire
> > >
anything.
> > > > >   specifications.  Implementations may choose which
> > > > > specifications
> > > to
> > > > >> Behalf Of Martin, Robert A.
> > > > >> is that if two SCI implementations don't have at least one
> > > > >> class
> > > in
> > > > > common,
> > > > >> spec per
> > > > >>> about
> > > > > ci-

---

From: <[email-masked]>
Date: Wed, 22 Feb 2012 14:38:38 -0500

Hi Take,

> validation process to the receiver.

I think you have a point.  In more detail, while discussing mandatory-to-implement
requirements, we have gotten into discussing whether schema validation should
not only be mandatory-to-implement, but also whether it should be
mandatory-to-use (a different, but related, concept) when the SpecID is used.

I suggest that validation that XML content is well-formed with respect to
its schema is a good idea, so I think something stronger than "be capable of"
is appropriate.  OTOH, I can conceive of reasons to bypass validation (e.g., the
schema validation is always failing, so as a step towards finding the problem,
turn off validation in order to take a look at the actual XML that arrived,
which should indicate whether the problem is at the sender vs. the receiver).

In light of that, here's a possible rewrite of my two sentences (they are now
three sentences in order to separate implementation and usage requirements):

1. The CVE SpecID value and related values (e.g., namespace) MUST be
        implemented (implementation is capable of sending and receiving
        well-formed CVE 1.0 XML documents without error).
2. The receiver MUST implement validation of received CVE 1.0 XML
        documents against the CVE 1.0 XML schema in order to detect
        invalid CVE documents.
3. The receiver SHOULD validate all received CVE 1.0 XML documents
        as described in item #2.

What do you think of this?

Thanks,
--David

> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2012 1:06 PM
> To: Black, David; [email-masked]; [email-masked]
> Subject: RE: [mile] Discussion / consensus call on CVE as MTI for SCI (was Re: MTI SCI?)
>
> > Behalf
> > Behalf
> > > > SCI (was
> > > > SCI (was
> currently
> > mile-sci-02.
> > specifications to
> > > > > >> class in

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 24 Feb 2012 01:05:48 +0900

Hi David and all,

I agree with the one you kindly proposed.
I appreciate that.

Thank you.
Take

> Sent: Thursday, February 23, 2012 4:39 AM
> To: [email-masked]; [email-masked]
> > I think the receiver needs to be capable of validating received CVE
> > XML for the smoke test purpose, but I am not sure whether we should
> > mandate the validation process to the receiver.
> 
> I think you have a point.  In more detail, while discussing
> mandatory-to-implement requirements, we have gotten into discussing
> whether schema validation should not only be mandatory-to-implement, but
> also whether it should be mandatory-to-use (a different, but related,
> concept) when the SpecID is used.
> 
> I suggest that validation that XML content is well-formed with respect
> to its schema is a good idea, so I think something stronger than "be
capable
> of"
> is appropriate.  OTOH, I can conceive of reasons to bypass validation
> (e.g., the schema validation is always failing, so as a step towards
> finding the problem, turn off validation in order to take a look at the
> actual XML that arrived, which should indicate whether the problem is
> at the sender vs. the receiver).
> 
> In light of that, here's a possible rewrite of my two sentences (they
> are now three sentences in order to separate implementation and usage
> requirements):
> 
> > 2. Recipient MUST "be capable of" validating received CVE 1.0 XML
> > document against the CVE 1.0 XML schema to detect invalid CVE documents.
> >
> > I think the receiver needs to be capable of validating received CVE
> > XML for the smoke test purpose, but I am not sure whether we should
> > mandate the validation process to the receiver.
> > So, I think the SCI draft could mandates the capability, instead of
> > the process.
> >
> > Does it make sense?
> >
> > Thank you.
> > Take
> >
> > > A "smoke test" is one of the motivations for this MTI requirement
> -
> > > for that, validation of the received content (e.g., against an XML
> > > schema for XML content) should be required, as one usually wants to
> > > know that the "smoke" made it through ok (the "smoke" that arrived
> > > matches what was sent).
> > >
> > > So, even if the content will only be used as "smoke test" evidence,
> > > and not otherwise interpreted, it's still a good idea to require
> > > format validation.
> > >
> > > Thanks,
> > > --David
> > >
> > > > I believe I agree with you, although I'd like to add some
> > > > precision
> > > on what is meant by "parse".
> > > >
> > > > Hence, I think the minimum requirement is to validate the received
> > > > SCI XML document against the appropriate XML schema and detect any
> errors.
> > > >
> > > >         A) Error reporting is specific to whatever transport
> > > > protocol
> > > is being used.
> > > >                 report errors, but there's no RFC 5070 requirement
> > > > that
> > > IODEF use RID.
> > > >                 Beyond error detection, it's not possible to
> > > > specify
> > > a required error
> > > >                 reporting mechanism.
> > > >
> > > >         B) RFC 5070 has nothing to say about replies or responses
> > > > to
> > > IODEF, so the
> > > >         C) I'm not sure I understand what Take had in mind by "how
> > > > to
> > > understand" in
> > > > > or "minimally support" mean so that technical requirements
> > > > > handed down based on this draft do not bar achievement by
> > > > > operational
> > > >         - The CVE SpecID value and related values (e.g.,
> > > > namespace)
> > > MUST
> > > >         - Recipient MUST validate received CVE XML document
> > > > against
> > > the CVE
> > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > > > St., Hopkinton, MA  01748
> > > > > I think you've done a very good job of explaining the two
> > > > > different interpretations around this call for consensus.
> > > > >
> > > > > draft, an implementer would have to support not only recognition
> > > > > of the namespace in the appropriate IODEF parent class context,
> > > > > but also be able to parse the content of the referenced
> > > > > namespace. Hence my preference for a relatively
> > > > > What that says to me is that each implementer would need to
> > > > > conform to the SCI draft's class placement of each namespace,
> > > > > but not necessarily have to be able to interpret the contents
> of
> > > > > said namespace(s). So all I have to do, minimally, is recognize
> > > > > the class under which any of the referenced namespaces exist;
> > > > I don't have to have any means to parse or handle that class
> > > > > or "minimally support" mean so that technical requirements
> > > > > handed down based on this draft do not bar achievement by
> > > > > operational
> > > > > Subject: Re: [mile] Discussion / consensus call on CVE as MTI
> > > > > for SCI
> > > > > (wasRe: MTI SCI?)
> > > > >
> > > > > Hello all,
> > > > >
> > > > > specifications listed in the table as values for SpecID field)
> > > > > Since all the specification listed in the table are supported,
> > > > > we need to have expert review before registration (as we
> > > > > discussed in Quebec
> > > > > City)
> > > > >
> > > > > I might be wrong, but I do not think we would like to define how
> > > > > to parse the IODEF extension message at the receiver side.
> > > > > I think the SCI draft is a container that conveys these
> > > > > structured information, and it can see such information as a
> > > > > blackbox with a
> > > tag (namespace information).
> > > > >
> > > > > As described in issue 1 above, if CVE or CAPEC data is attached,
> > > > > the implementation needs to recognize that the data is in
> > > > > CVE/CAPEC format, and that is the requirement
> > > > for the implementation.
> > > > > We will need to resolve these issues if CVE is to be the (or an)
> > > > > MTI specification for the SCI
> > > > draft.
> > > > >
> > > > > If CVE is mandatory to implement, what guidance would be
> > > > > followed
> > > on
> > > > > parsed?   The CVE website is listed as the specification URI,
> but
> > > from
> > > > > Dave's message, the specification URI does not exist to provide
> > > > > the guidance (I get to broken link pages for both - the existing
> > > > > and
> > > suggested replacement link).
> > > > >
> > > > > It looks like the reference to the target namespace needs to be
> > > > > fixed
> > > as well.
> > > > >
> > > > > Thank you,
> > > > > Kathleen
> > > > > Relative to MTI, is the question what schema should be MTI for
> > > > > the vulerability class?  In general I think we should have one
> > > > > or more
> > > MTI for each class.
> > > > >
> > > > "http://cve.mitre.org/cve/downloads/1.0".  This will likely need
> > > > to
> > > be fixed.
> > > > >
> > > > > Also, the specification URI points to the CVE website, which is
> > > > > not really a specification.  It's not clear where to find
> > > > > guidance on how to properly use the model indicated by the
> > > > > namespace.  Without having clear guidance on its use I don't see
> > > > > how we can make it MTI, even if it is considered a de facto
> > > > > > So, I'd like to call for consensus on the list. Does the
> > > > > > working group agree on the following two points?
> > > > > >
> > > > > > 1. mile-sci requires one Mandatory to Implement schema in
> > > > > > order
> > > to
> > > > > > ensure interoperability.
> > > > > >
> > > > > > 2. The Mandatory to Implement schema is the Common
> > > > > > Vulnerability Enumeration (CVE) version 1.0, as described in
> > > > > > section 4.1.7 of
> > > > > > mile- sci-02.
> > > > > >
> > > > > > > I've attached the working version of the draft. I hope it
> > > > > > > helps to clarify the changes.
> > > > > > >
> > > > > > >   supported.  In case an implementation received a data it
> > > > > > > does
> > > not
> > > > > > >   notify the sender of its inability to parse the data by
> > > > > > > using
> > > any
> > > > > > > On the other hand, I would like to add "STRING ext-SpecID"
> > > > > > > to each class, which enables to embed data following private
> schema.
> > > > > > > It could also be used to exchange data using beta version
> of
> > > > > > specifications.
> > > > > > >
> > > > > > >      specifying the format of the RawData element.  The
> > > > > > > value should
> > > > > > be
> > > > > > >      chosen from the namespaces [XMLNames] listed in Section
> > > > > > > 4.1
> > > or
> > > > > > >      according to an organization's private schema.  When
> > > > > > > the
> > > value
> > > > > > >      specifying the format of the RawData element.  When
> > > > > > > this
> > > element
> > > > > > >> At the risk of contradicting myself - but then again I have
> > > > > > >> now read the other replies to this issue - I agree that
> > > > > > >> having one area be
> > > > > > the
> > > > > > >> smoke test makes sense and I also agree that something
> > > > > > >> simple and commonly used already - like CVE - is the best
> > > > > > >> candidate for what we
> > > > > > need.
> > > > > > >>
> > > > > > >> Bob
> > > > > > >>
> > > > > > >>> CVE is widely used and understood by all in the the
> > > > > > >>> security
> > > > > > community.
> > > > > > >> I agree with Tom that CVE is the path of least resistance
> > > > > > >> but may be the most useful for basic interoperability.
> > > > > > >>>
> > > > > > >>> Kent Landfield
> > > > > > >> heavyweight than necessary for day-to-day usage; making
> > > > > > >> CAPEC
> > > a
> > > > > > >> adding ammunition to that argument, especially if the CSIRT
> > > > > > >> is having to fund implementation out of their own pocket.
> > > > > > >> Personally, I would
> > > > > > have
> > > > > > >> that CAPEC references CybOX, so there's wheels within
> > > > > > >> wheels
> > > now.
> > > > > > >>>
> > > > > > >>> CVE is well known, has years of familiarity built in, and
> > > > > > >>> I think it's
> [email-masked]<mailto:[email-masked]
> > > > > > >>> >
> > > > > > >>> BB: [email-masked]<mailto:[email-masked]>
> /
> > > > > > >>> 202-631-1915
> > > > > > >> to be used.  OTOH, it may be useful to have a single simple
> > > > > > >> MTI spec for SCI that can be used to "smoke test" a
> > > > > > >> deployment before trying any
> > > > > > > serious
> > > > > > >> unlikely to be acceptable to the IESG (i.e., with an MTI
> > > > > > >> SCI spec per class, I suspect that there will also have to
> > > > > > >> be an MTI class, which results in an overall MTI SCI spec).
> > > > > > >>>
> > > > > > >> CAPEC XML document for testing purposes, including
> > > > > > >> enumeration values suitable for testing).
> > > > > > >>>
> > > > > > >>> purpose is to reference a set of external specifications
> > > > > > >>> by inclusion in an IODEF document, and that those external
> > > > > > >>> specifications represent
> > > > > > >>> envision an mile-sci implementation that was only
> > > > > > >>> interested
> > > a
> > > > > > >>> implementation has an internal representation of
> > > > > > >>> Verification, but not of any of the other classes, and the
> > > > > > >>> MTI is an enumeration that is applicable to
> > > > > > >>>>>> [email-masked]<mailto:[email-masked]>
> > > > > > >>>>>> Information) specifications in draft-ietf-mile-sci.
> > > > > > >>>>>> Which one is the MTI (mandatory to implement) choice?
> > > > > > >>>>>> In other words, how will you get two interoperability
> > > > > > >>>>>> implementations
> > > without picking one?
> > > > > > >>>>>>
> > > > > > >>>>>> spt