Subject: [mile] IODEF Reference Format for Enumerations

From: Adam Montville <[email-masked]>
Date: Mon, 9 Apr 2012 18:38:13 +0000

All:

There is an identified need to specify a format to include relevant
enumeration values in an IODEF document.  The initial idea is to place
enumeration values and their references in IODEF's Reference class.  There
are several ways to accomplish this goal.  I'll do my best to enumerate
some options here, then I hope to hear some feedback/opinions about the
different approaches from the list.

>From the Structured Cybersecurity Information draft
(draft-takahashi-mile-sci-02), we may be interested to include the
following (not an inclusive list) enumerations in an IODEF document:
CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.

The IODEF Reference class is described in 3.9.1 of RFC 5070, where a
Reference must have a ReferenceName and zero or more of URL or Description
respectively.

For each option described below, we can consider use of the IANA registry.
The registry may be used to identify the identifier category and
potentially the appropriate identification format for that category.

Option 1: Simple ID
===================
The first option would simply embed the relevant identifier in the
ReferenceName element of the Reference class.  This may look like the
following:

    <Reference>
        <ReferenceName>id</ReferenceName>
        <URL>http://www.example.com/path</URL>
        <URL>http://www.otherexample.com/path</URL>
        <Description>Description</Description>
    </Reference>

Using this option, a variety of specific identifier formats could be
specified.  CVE, for example, would start with "CVE-" and this convention
may be registered in an IANA table.

No changes to IODEF are required for this option.

Option 2: ID with coupled ID type
=================================
The second option would prepend the identifier with it's type, which may
look something like the following.

    <Reference>
        <ReferenceName>id_type:id</ReferenceName>
        <URL>http://www.example.com/path</URL>
        <URL>http://www.otherexample.com/path</URL>
        <Description>Description</Description>
    </Reference>

Using this option, a variety of specific identifier types could be
specified, such that the identifier itself would not necessarily be
constrained, nor would new identifier formats necessarily need to be
specified in the future.  An IANA table may be used for this solution as
well.

No changes to IODEF would be required for this option.

Option 3: ID with type expressed in Reference attribute
=======================================================
The third option would require opening IODEF to update the Reference class
with an attribute, which may look something like the following.

    <Reference registryId="id_type">
        <ReferenceName>id</ReferenceName>
        <URL>http://www.example.com/path</URL>
        <URL>http://www.otherexample.com/path</URL>
        <Description>Description</Description>
    </Reference>

Changes to IODEF are required for this option.

----

I look forward to fielding responses to these options, including any
additional options you may see, but which are not listed.

What is your solution preference?

Regards,

Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | Take CONTROL
http://www.tripwire.com

---

From: <[email-masked]>
Date: Mon, 9 Apr 2012 14:40:54 -0500

I vote option 1, for the sake of simplicity. I realize it may not result in perfect interpretation every time, but neither will the other options.

 - 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 Adam Montville
Sent: Monday, April 09, 2012 2:38 PM
To: [email-masked]
Subject: [mile] IODEF Reference Format for Enumerations

All:

There is an identified need to specify a format to include relevant enumeration values in an IODEF document.  The initial idea is to place enumeration values and their references in IODEF's Reference class.  There are several ways to accomplish this goal.  I'll do my best to enumerate some options here, then I hope to hear some feedback/opinions about the different approaches from the list.

>From the Structured Cybersecurity Information draft (draft-takahashi-mile-sci-02), we may be interested to include the following (not an inclusive list) enumerations in an IODEF document:

The IODEF Reference class is described in 3.9.1 of RFC 5070, where a Reference must have a ReferenceName and zero or more of URL or Description respectively.

For each option described below, we can consider use of the IANA registry.
The registry may be used to identify the identifier category and potentially the appropriate identification format for that category.

Option 1: Simple ID
===================
The first option would simply embed the relevant identifier in the ReferenceName element of the Reference class.  This may look like the
following:

    <Reference>

Using this option, a variety of specific identifier formats could be specified.  CVE, for example, would start with "CVE-" and this convention may be registered in an IANA table.

Option 2: ID with coupled ID type
=================================
The second option would prepend the identifier with it's type, which may look something like the following.

    <Reference>

Using this option, a variety of specific identifier types could be specified, such that the identifier itself would not necessarily be constrained, nor would new identifier formats necessarily need to be specified in the future.  An IANA table may be used for this solution as well.

Option 3: ID with type expressed in Reference attribute =======================================================
The third option would require opening IODEF to update the Reference class with an attribute, which may look something like the following.

----

I look forward to fielding responses to these options, including any additional options you may see, but which are not listed.

Regards,

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | Take CONTROL
http://www.tripwire.com

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

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 9 Apr 2012 17:53:11 -0400

My preference would be to use option #2.  This approadch will essentially provide a namespace for identifiers which conveys more semantics than a simple string.  Although maybe forward looking, this will be useful in cases where different identification schemes may have similar syntax but differ in meaning.  It is also useful to denote revisions for a given scheme where there may be partial overlap in instances.  This approach provides greater overall flexibility without the need to revise IODEF. If IODEF is revised, we may want to consider option 3 to avoid a secondary parsing step to separate the namespace from the value.

Sincerely,
Dave Waltermire

> enumeration values and their references in IODEF's Reference class.
> There are several ways to accomplish this goal.  I'll do my best to
> enumerate some options here, then I hope to hear some feedback/opinions
> about the different approaches from the list.
> 
> From the Structured Cybersecurity Information draft (draft-takahashi-
> mile-sci-02), we may be interested to include the following (not an
> inclusive list) enumerations in an IODEF document:
> Reference must have a ReferenceName and zero or more of URL or
> Description respectively.
> 
> specified.  CVE, for example, would start with "CVE-" and this
> convention may be registered in an IANA table.
> 
> specified in the future.  An IANA table may be used for this solution
> as well.
> 
> The third option would require opening IODEF to update the Reference
> class with an attribute, which may look something like the following.
>

---

From: <[email-masked]>
Date: Mon, 9 Apr 2012 18:02:23 -0400

I agree with Dave on #2 - having a separate namespace above the identifier avoids
possible future problems with identifier collisions (e.g., if some future standard
of interest uses "CVE-" as the string prefix for something completely different
than the CVE we're currently familiar with).

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Waltermire, David A.
> Sent: Monday, April 09, 2012 5:53 PM
> To: Adam Montville; [email-masked]
> Subject: Re: [mile] IODEF Reference Format for Enumerations
> 
> My preference would be to use option #2.  This approadch will essentially
> provide a namespace for identifiers which conveys more semantics than a simple
> string.  Although maybe forward looking, this will be useful in cases where
> different identification schemes may have similar syntax but differ in
> meaning.  It is also useful to denote revisions for a given scheme where there
> may be partial overlap in instances.  This approach provides greater overall
> flexibility without the need to revise IODEF. If IODEF is revised, we may want
> to consider option 3 to avoid a secondary parsing step to separate the
> namespace from the value.
> 
> Sincerely,
> Dave Waltermire
>

---

From: Lagadec Philippe <[email-masked]>
Date: Tue, 10 Apr 2012 08:18:16 +0000

Hello,

Personally I think option #3 looks cleaner for parsing and more in the spirit of XML than option #2.
It would also be compatible with option #1, for parsers which ignore the registryId attribute.
Of course, modifying IODEF would take more time.
So maybe a solution could be to start with option #1, until IODEF is modified towards option #3?

BTW is there a plan to modify IODEF in the future?
There are quite a few other issues that would need to be fixed here and there.

Philippe.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 10 April 2012 00:02
To: [email-masked]; [email-masked]
Subject: Re: [mile] IODEF Reference Format for Enumerations

I agree with Dave on #2 - having a separate namespace above the identifier avoids possible future problems with identifier collisions (e.g., if some future standard of interest uses "CVE-" as the string prefix for something completely different than the CVE we're currently familiar with).

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Waltermire, David A.
> My preference would be to use option #2.  This approadch will 
> essentially provide a namespace for identifiers which conveys more 
> semantics than a simple string.  Although maybe forward looking, this 
> will be useful in cases where different identification schemes may 
> have similar syntax but differ in meaning.  It is also useful to 
> denote revisions for a given scheme where there may be partial overlap 
> in instances.  This approach provides greater overall flexibility 
> without the need to revise IODEF. If IODEF is revised, we may want to 
> consider option 3 to avoid a secondary parsing step to separate the namespace from the value.
> 
> Sincerely,
> Dave Waltermire
> 
> > enumeration values in an IODEF document.  The initial idea is to 
> > place enumeration values and their references in IODEF's Reference class.
> > enumerate some options here, then I hope to hear some 
> > feedback/opinions about the different approaches from the list.
> >
> > (draft-takahashi- mile-sci-02), we may be interested to include the 
> > specified in the future.  An IANA table may be used for this 
> > solution as well.
> >

---

From: <[email-masked]>
Date: Tue, 10 Apr 2012 07:37:02 -0400

Hello Philippe,

Thank you for chiming in on both accounts.  We know there are issues with how internationalization was specified in IODEF, so we may need to open it up to fix it.  If there are other issues that should be resolved or updating that needs to happen, helping to figure that out on list will drive a result from the working group.  If you or others want to take on leading the discussion on possible updates and managing the document revision (editor), than we can start to look at an RFC5070-bis. These types of initiatives are led by the working group members and volunteers, so help is appreciated!

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lagadec Philippe
Sent: Tuesday, April 10, 2012 4:18 AM
To: [email-masked]
Subject: Re: [mile] IODEF Reference Format for Enumerations

Hello,

Philippe.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 10 April 2012 00:02
To: [email-masked]; [email-masked]
Subject: Re: [mile] IODEF Reference Format for Enumerations

Thanks,
--David

> > Of Adam Montville

---

From: "Struse, Richard" <[email-masked]>
Date: Tue, 10 Apr 2012 08:05:59 -0400

I'd opt for #2 with a plan for getting to #3 during the next rev of
IODEF.

Rich

-----Original Message-----
Lagadec Philippe

Hello,

Personally I think option #3 looks cleaner for parsing and more in the
spirit of XML than option #2.
It would also be compatible with option #1, for parsers which ignore the
registryId attribute.
Of course, modifying IODEF would take more time.
So maybe a solution could be to start with option #1, until IODEF is
modified towards option #3?

BTW is there a plan to modify IODEF in the future?
There are quite a few other issues that would need to be fixed here and
there.

Philippe.

-----Original Message-----
[email-masked]

I agree with Dave on #2 - having a separate namespace above the
identifier avoids possible future problems with identifier collisions
(e.g., if some future standard of interest uses "CVE-" as the string
prefix for something completely different than the CVE we're currently
familiar with).

Thanks,
--David

> > The second option would prepend the identifier with it's type, which

> > may look something like the following.
> >
> >     <Reference>

---

From: "Baker, Jon" <[email-masked]>
Date: Tue, 10 Apr 2012 12:51:34 +0000

Based upon current IODEF structures, I would prefer option one. I would rather avoid adding additional syntax to the ReferenceName element as option two suggests. If option one is selected and there are later changes to IODEF we could migrate to option 3 fairly easily. 

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [email-masked]

>Adam Montville

---

From: "Panos Kampanakis" <[email-masked]>
Date: Tue, 10 Apr 2012 09:39:36 -0400

Agree. 
#1 until #3 is possible.

Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Baker, Jon
Sent: Tuesday, April 10, 2012 8:52 AM
To: [email-masked]
Subject: Re: [mile] IODEF Reference Format for Enumerations

Based upon current IODEF structures, I would prefer option one. I would
rather avoid adding additional syntax to the ReferenceName element as option
two suggests. If option one is selected and there are later changes to IODEF
we could migrate to option 3 fairly easily. 

Jon

---

From: <[email-masked]>
Date: Tue, 10 Apr 2012 12:16:23 -0500

I like option two as well for all the same reasons.  Knowing what it is to be applied to  before makes it easier than having to parse the string itself.

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: David Waltermire <[email-masked]<mailto:[email-masked]>>
Date: Mon, 9 Apr 2012 16:53:11 -0500
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] IODEF Reference Format for Enumerations

Sincerely,
Dave Waltermire

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Adam Montville
To: [email-masked]<mailto:[email-masked]>
For each option described below, we can consider use of the IANA
registry.
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 11 Apr 2012 13:19:20 +0900

Hi Adam and all, 

I also like option 2.

By the way, I am a bit behind the conversation, so I would appreciate if you
could clarify the below question.

I think we are defining the use of Reference class as a container for
various identifiers (e.g. CVE-ID).
Then, "are we thinking to adopt this use of the Reference class for the SCI
draft?"

In my humble opinion, the current SCI draft has the same kind of philosophy,
with different structure.
If we look at the Vulnerability class of the SCI draft, we have the
structure like below.

+------------------------+
| Vulnerability          |
+------------------------+
| ENUM SpecID            |<>--(0..*)-[ RawData ]
| STRING ext-SpecID      |<>--(0..*)-[ Reference ]
| STRING VulnerabilityID |<>--(0..*)-[ Platform ]
|                        |<>--(0..*)-[ Scoring ]
+------------------------+

SpecID corresponds to the id_type (of the option 2) while VulnerabilityID
corresponds to e.g., CVE-ID.

By the way, the latest version of the SCI draft is available below.
I've uploaded the SCI draft I've shared to the MILE mailing list on 21st
March.

http://www.ietf.org/internet-drafts/draft-ietf-mile-sci-03.txt

Thank you.
Take

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, April 11, 2012 2:16 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] IODEF Reference Format for Enumerations

I like option two as well for all the same reasons.  Knowing what it is to
be applied to  before makes it easier than having to parse the string
itself. 

Kent Landfield

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

From: David Waltermire <[email-masked]>
Date: Mon, 9 Apr 2012 16:53:11 -0500
To: Adam Montville <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [mile] IODEF Reference Format for Enumerations

My preference would be to use option #2.  This approadch will essentially
provide a namespace for identifiers which conveys more semantics than a
simple string.  Although maybe forward looking, this will be useful in cases
where different identification schemes may have similar syntax but differ in
meaning.  It is also useful to denote revisions for a given scheme where
there may be partial overlap in instances.  This approach provides greater
overall flexibility without the need to revise IODEF. If IODEF is revised,
we may want to consider option 3 to avoid a secondary parsing step to
separate the namespace from the value.

Sincerely,
Dave Waltermire

---

From: Brian Trammell <[email-masked]>
Date: Wed, 11 Apr 2012 11:29:10 +0200

Hi, Take,

I've read this conversation to date as covering a different draft; incorporation of content and reference to enumeration are different things with different use cases.

Best regards,

Brian

Sent from my iPhone

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 11 Apr 2012 21:04:33 +0900

Hi Brian,

Thank you very much for the clarification :)

Best Regards,
Take

> From: Brian Trammell [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2012 6:29 PM
> To: Takeshi Takahashi
> Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> I've read this conversation to date as covering a different draft;
> incorporation of content and reference to enumeration are different
> things with different use cases.
> 
> Best regards,
> 
> Brian
> 
> Sent from my iPhone
> 
> > By the way, I am a bit behind the conversation, so I would appreciate
> > if you could clarify the below question.
> >
> > Then, "are we thinking to adopt this use of the Reference class for
> > the SCI draft?"
> >
> > In my humble opinion, the current SCI draft has the same kind of
> > philosophy, with different structure.
> > SpecID corresponds to the id_type (of the option 2) while
> > VulnerabilityID corresponds to e.g., CVE-ID.
> >
> > I've uploaded the SCI draft I've shared to the MILE mailing list on
> > 21st March.
> >
> > Of [email-masked]
> > I like option two as well for all the same reasons.  Knowing what it
> > is to be applied to  before makes it easier than having to parse the
> > string itself.
> >
> >
> > Kent Landfield

---

From: <[email-masked]>
Date: Wed, 11 Apr 2012 19:39:07 -0400

Adam,

I have a couple more comments.

[1] 19770-2

> CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.

I don't think 19770-2 belongs on the list of possible references.
A 19770-2 software tag appears to be XML, and hence belongs only in
the SCI draft.  Here's the XML schema for 19770-2 tags:

	http://standards.iso.org/iso/19770/-2/2009/schema.xsd

FWIW, the current version of the SCI draft is draft-ietf-mile-sci-03,
and it no longer includes 19770-2.

[2] ReferenceName string format

Beyond 19770-2, the other five specifications were all developed by Mitre,
who carefully ensured that each of them uses a different initial portion
of their enumeration strings.  That approach is likely to be problematic
for an IETF standard that will need to accommodate multiple other
independently developed enumeration specifications.  While IANA can perform
the corresponding function for IETF via a registry, there's a problem.
In contrast to Mitre, one can't realistically expect developers of
enumeration specifications to approach IANA in advance to obtain a string
prefix, and that's especially true for existing specifications ;-).

So, option 1 appears problematic if the specification and its reference
syntax have to be inferred from the identifier format in a fashion that is

> may be registered in an IANA table.

To take a simple example, suppose two different enumeration specifications
just use numbers for their enumerations, starting from 1.  When "42" shows
up as the ReferenceName, what does that refer to (aside from the answer to
life, the universe and everything)?

There should be a deterministic way to figure out which specification (and
hence which format) to use to interpret ReferenceName - for option 1 this
could be done by requiring that the first URL be a "Reference URI" from the
IANA registry established by the SCI draft.

This also deals with potential enumeration specifications that don't use
a constant initial portion of their reference strings.

While this approach could also be used for options 2 and 3, they both have
an explicit ID that addresses this problem.  For these two options, it seems
like a good idea to use a single specification registry for both references
and XML inclusion, and hence I'd suggest adding this ID as a registered
element to the IANA registry created by the SCI draft if option 2 or 3 is
chosen.

Bottom line: If option 1 is chosen, the first URL in the Reference MUST be
the Reference URI for the IANA-registered specification.

An interesting observation is that if option 1 is chosen, the result is
a common means of referencing specifications between the SCI draft and the
new draft on use of the IODEF reference format.

Thanks,
--David

---

From: Adam Montville <[email-masked]>
Date: Thu, 12 Apr 2012 18:24:05 +0000

This is good information, David, thank you.  I'll be sending another note
to the list in a few minutes assessing where we are, and I'll include this
advice therein.

Adam

On 4/11/12 4:39 PM, "[email-masked]" <[email-masked]> wrote:

>>Adam
>> Montville
>>There
>>Description
>>class

---

From: Adam Montville <[email-masked]>
Date: Thu, 12 Apr 2012 18:28:24 +0000

All:

So far, it seems as though more people are speaking up in favor of Option
2.  There are also several comments expressing a desire to choose either
Option 1 or Option 2, but then move to Option 3 at some point in the
future.  I'd like to understand more about what that really means -
choosing one option and then moving to another.

Would it make more sense to wait until IODEF is "opened" for an update to
address this issue?

For those of you who prefer Option 1 or Option 2, but have not indicated a
preference with respect to later moving to Option 3, do you have an
opinion about such a move?

David Black has put forward some additional insight where, "if Option 1 is
chosen, the result is a common means of referencing specifications between
the SCI draft and the new draft on use of the IODEF reference format."
This statement references the notion of requiring the first URL of on
IODEF <Reference> element (associated with the <ReferenceName>) to be a
reference URI from the IANA registry established by the SCI draft.

It would seem, then, that we have deterministic methods of understanding
what a <ReferenceName> is, and thus how to parse it, but that we have
several different mechanisms by which to accomplish this.

Comments? Opinions?

Regards,

Adam

---

From: <[email-masked]>
Date: Thu, 12 Apr 2012 14:56:14 -0400

Hi Adam,

Thank you for running the list of options by the WG and to those participating in the decision process!

We have had a couple of reasons discussed to 'open' up IODEF.  If we get a volunteer to help with the editing of an RFC5070 soon, then option 3 may be worth considering.  I would expect that a revision to RFC5070 would take some time as the list works through issues and options.

What do others think about this and Adam's other questions?

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Thursday, April 12, 2012 2:28 PM
To: Adam Montville; [email-masked]
Subject: Re: [mile] IODEF Reference Format for Enumerations

All:

Comments? Opinions?

Regards,

Adam

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 13 Apr 2012 10:03:31 -0400

Referencing security identifiers seems like an issue that will surface in other efforts.  If we create an IANA registry, it would be ideal if this registry could support reference use cases in other models.  Although each model may have sligtly different reference syntax, the general method for defining the type and identifier based the registry could be the same.  Have you put any thought into how this could be accomplished?

One idea would be to have the draft you are focused on define the mechanism for defining identifier types and then have IODEF define how to represent a reference using the Reference class.  Other models could follow suit.

Sincerely,
David Waltermire

> So far, it seems as though more people are speaking up in favor of
> Option 2.  There are also several comments expressing a desire to
> choose either Option 1 or Option 2, but then move to Option 3 at some
> point in the future.  I'd like to understand more about what that
> really means - choosing one option and then moving to another.
> 
> Would it make more sense to wait until IODEF is "opened" for an update
> to address this issue?
> 
> For those of you who prefer Option 1 or Option 2, but have not
> indicated a preference with respect to later moving to Option 3, do you
> have an opinion about such a move?
> 
> David Black has put forward some additional insight where, "if Option 1
> is chosen, the result is a common means of referencing specifications
> between the SCI draft and the new draft on use of the IODEF reference
> format."
> It would seem, then, that we have deterministic methods of
> understanding what a <ReferenceName> is, and thus how to parse it, but
> that we have several different mechanisms by which to accomplish this.
> 
> Comments? Opinions?
> 
> Regards,
> 
> Adam
> 
> feedback/opinions

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 16 Apr 2012 17:45:54 +0900

Hi all,

If we are going to update option 3, that would be one direction.

IMHO, the option 3 is very close to the expected use of the Vulnerability
class of SCI draft. (and some other classes as well)
The expected usage of the Vulnerability class of current SCI draft, with CVE
identifier, is as follows.

<iodef-sci:Vulnerability SpecID="http://cve.mitre.org/cve/downloads/1.0"
VulnerabilityID="CVE-2010-3654"/>

The slight difference between the SCI draft and the option 3 is that the SCI
draft took a semantic approach (vulnerability, attackpattern, etc.), while
the option three takes general container approach.
The URLs to the information of the specification (in this case CVE 1.0) are
described in the IANA table in case of the SCI draft approach.

I think both approach is viable, but proper description on how to choose
either of the approaches could be helpful for readers.

Thank you.
Take

> [email-masked]
> Sent: Friday, April 13, 2012 3:56 AM
> To: [email-masked]; [email-masked]
> We have had a couple of reasons discussed to 'open' up IODEF.  If we get
> a volunteer to help with the editing of an RFC5070 soon, then option 3
> may be worth considering.  I would expect that a revision to RFC5070 would
> take some time as the list works through issues and options.
> 
future.
> I'd like to understand more about what that really means - choosing one
> option and then moving to another.
> 
> For those of you who prefer Option 1 or Option 2, but have not indicated
> a preference with respect to later moving to Option 3, do you have an
> David Black has put forward some additional insight where, "if Option
> 1 is chosen, the result is a common means of referencing specifications
> IODEF <Reference> element (associated with the <ReferenceName>) to be
> a reference URI from the IANA registry established by the SCI draft.
> 
registry.

---

From: Adam Montville <[email-masked]>
Date: Mon, 23 Apr 2012 22:36:23 +0000

Hi David,

Sorry for dropping off the face of the planet for a while.  This may be a
useful suggestion.  I think what you're saying is that current work could
focus not on the SCI extensions specifically, but point more toward
defining how such extensions would work.  Then, opening IODEF would be
able to follow that model.

What do others on the list think of this?  I think such an approach could
work if it is limited MILE-specific documents.  If it is a generalized
approach, applicable to a wide variety of efforts in the Security Area,
then I would ask whether MILE is the right place for the work.

Regards,

Adam

On 4/13/12 7:03 AM, "Waltermire, David A." <[email-masked]>
wrote:

>Referencing security identifiers seems like an issue that will surface in
>other efforts.  If we create an IANA registry, it would be ideal if this
>registry could support reference use cases in other models.  Although
>each model may have sligtly different reference syntax, the general
>method for defining the type and identifier based the registry could be
>the same.  Have you put any thought into how this could be accomplished?
>
>One idea would be to have the draft you are focused on define the
>mechanism for defining identifier types and then have IODEF define how to
>represent a reference using the Reference class.  Other models could
>follow suit.
>
>Sincerely,
>David Waltermire
>
>

---

From: Adam Montville <[email-masked]>
Date: Mon, 23 Apr 2012 22:43:59 +0000

Take,

Do you think it would make any sense to combine the two approaches?
Option 3 could be rewritten to be more aligned with the
<iodef-sci:Vulnerability> example you provided.

<Reference registryId="id_type" referenceClass="some_class">

Or, perhaps the class information could be referenced in an IANA table in
a manner consistent with Options 1 and 2...  So, if there's a registryId,
then some semantic information about the types of classes accepted by that
registryId could be discovered.

Any thoughts from the list about this general approach?

Adam

On 4/16/12 1:45 AM, "Takeshi Takahashi" <[email-masked]>
wrote:

>>Option

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 19:56:14 -0400

Take, Adam, and MILE members,

Thanks for hashing out ideas on the list.  I think we need to make sure that we have one approach for including enumerated values consistently to ensure interoperability and one approach to include additional content via another XML document.  If it makes the most sense to add a field to IODEF for option 3, we should figure that out so enumerated values do not require an extension.  Or determine if either option 1 or 2 makes the most sense to have enumerated values represented in the base IODEF document.

Any other opinions?

Thank you!
Kathleen

-----Original Message-----
From: Adam Montville [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 6:44 PM
To: Takeshi Takahashi; Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] IODEF Reference Format for Enumerations

Take,

Adam

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 24 Apr 2012 09:56:07 +0900

Adam,

If modifying IODEF is allowed, I do not see any point to define classes
under AdditionalData class (as SCI draft does) since it makes the XML
longer.

Since the new Option 3 and the sci draft are not that different, it would be
fine for me to combine them into one.
Sci draft defines several containers for each semantics, and positioned them
under AdditionalData class, while new Option 3 defines one container with
semantic information that requires no additionalData class.
(I wonder whether we really need the semantics or not if we use the option 3
approach, since the location of the Reference class inside IODEF document
indicates the semantics.)

If Option 3 could cover the rest of the classes including the ones that do
not have any ID yet, I think it is reasonable to merge the works into one.
I do not see any point to have two drafts for similar issues.
That will just confuse users.

The remaining issues for the SCI draft were as follows in my understanding
1. "namespace identifying specification" needs to be confirmed
2. copyright issues needs to be clarified
3. schema needs to be reviewed

The merged work will inherit the above issues, and I am happy if you could
lead the work.
How does that sound to everybody?

Sincerey,
Take

> Sent: Tuesday, April 24, 2012 7:44 AM
> To: Takeshi Takahashi; [email-masked]; [email-masked]
> Or, perhaps the class information could be referenced in an IANA table
> in a manner consistent with Options 1 and 2...  So, if there's a
registryId,
> then some semantic information about the types of classes accepted by
> that registryId could be discovered.
> 
> >IMHO, the option 3 is very close to the expected use of the
> >Vulnerability class of SCI draft. (and some other classes as well) The
> >expected usage of the Vulnerability class of current SCI draft, with
> >CVE identifier, is as follows.
> >
> ><iodef-sci:Vulnerability
> SpecID="http://cve.mitre.org/cve/downloads/1.0"
> >The slight difference between the SCI draft and the option 3 is that
> >the SCI draft took a semantic approach (vulnerability, attackpattern,
> >etc.), while the option three takes general container approach.
> >The URLs to the information of the specification (in this case CVE 1.0)
> >are described in the IANA table in case of the SCI draft approach.
> >
> >I think both approach is viable, but proper description on how to
> >choose either of the approaches could be helpful for readers.
> >
> >Thank you.
> >Take
> >
> >> Of [email-masked]
> >> We have had a couple of reasons discussed to 'open' up IODEF.  If we
> >>get  a volunteer to help with the editing of an RFC5070 soon, then
> >>option 3  may be worth considering.  I would expect that a revision
> to
> >>RFC5070 would  take some time as the list works through issues and
> >>options.
> >>
> >>point in the
> >> I'd like to understand more about what that really means - choosing
> >> one option and then moving to another.
> >>
> >> Would it make more sense to wait until IODEF is "opened" for an
> >> update to address this issue?
> >>
> >> indicated a preference with respect to later moving to Option 3, do
> >> you have an opinion about such a move?
> >>
> >> 1 is chosen, the result is a common means of referencing
> >> specifications between the SCI draft and the new draft on use of the
> >> IODEF reference format."
> >> understanding what a <ReferenceName> is, and thus how to parse it,
> >> but that we have several different mechanisms by which to accomplish
> this.
> >>
> >> Comments? Opinions?
> >>
> >> Regards,
> >>
> >> Adam
> >>

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 24 Apr 2012 10:00:02 +0900

Let me rewrite the sentence:

> If Option 3 could cover the rest of the classes including the ones that
> do not have any ID yet, I think it is reasonable to merge the works into
> one.

If Option 3 could cover all the classes (not only the vulnerability class
but also the other classes), some of which supports XML without any IDs, I
think it is reasonable to merge the works into one.
I believe the Reference class can support them with proper extension.

Sincerely,
Take

> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2012 9:56 AM
> To: 'Adam Montville'; [email-masked]'; [email-masked]'
> Subject: RE: [mile] IODEF Reference Format for Enumerations
> 
> Adam,
> 
> Since the new Option 3 and the sci draft are not that different, it would
> be fine for me to combine them into one.
> Sci draft defines several containers for each semantics, and positioned
> them under AdditionalData class, while new Option 3 defines one container
> with semantic information that requires no additionalData class.
> (I wonder whether we really need the semantics or not if we use the option
> 3 approach, since the location of the Reference class inside IODEF
> document indicates the semantics.)
> 
> If Option 3 could cover the rest of the classes including the ones that
> do not have any ID yet, I think it is reasonable to merge the works into
> one.
> 1. "namespace identifying specification" needs to be confirmed 2.
> copyright issues needs to be clarified 3. schema needs to be reviewed
> 
> > registryId, then some semantic information about the types of classes
> > accepted by that registryId could be discovered.
> >
> > >Vulnerability class of SCI draft. (and some other classes as well)
> > >The expected usage of the Vulnerability class of current SCI draft,
> > >with CVE identifier, is as follows.
> > >
> > ><iodef-sci:Vulnerability
> > >The URLs to the information of the specification (in this case CVE
> > >1.0) are described in the IANA table in case of the SCI draft approach.
> > >
> > >> From: [email-masked] [mailto:[email-masked]] On
> > >> Behalf Of [email-masked]
> > >> We have had a couple of reasons discussed to 'open' up IODEF.  If
> > >>we get  a volunteer to help with the editing of an RFC5070 soon,
> > >>then option 3  may be worth considering.  I would expect that a
> > >>revision
> > to
> > >>choose either  Option 1 or Option 2, but then move to Option 3 at
> > >>some point in the
> > >future.
> > >> specifications between the SCI draft and the new draft on use of
> > >> the IODEF reference format."
> > >> >There is an identified need to specify a format to include
> > >> >relevant enumeration values in an IODEF document.  The initial
> > >> >idea is to place enumeration values and their references in
> > >> >IODEF's Reference
> > class.
> > >> >There are several ways to accomplish this goal.  I'll do my best
> > >> >to enumerate some options here, then I hope to hear some
> > >> >The second option would prepend the identifier with it's type,
> > >> >which may look something like the following.
> > >> >
> > >> >    <Reference>
> > >> >specified, such that the identifier itself would not necessarily
> > >> >be constrained, nor would new identifier formats necessarily need
> > >> >to
> > be
> > >> >The third option would require opening IODEF to update the
> > >> >Reference class with an attribute, which may look something like
> the following.
> > >> >
> > >> >I look forward to fielding responses to these options, including
> > >> >any additional options you may see, but which are not listed.
> > >> >

---

From: <[email-masked]>
Date: Thu, 26 Apr 2012 08:48:28 -0400

Hi Take,

Can you explain more on how you see merging the two into one document?  The only concern I have is that specifying the enumerations could be done without including the MITRE specifications right into the document, so we *MAY* not have to worry about the normative references (but I would need to confirm that).

One advantage of one document over two would be one registry page for the two IANA tables.

This approach would mean that we would plan on an IODEF revision for at least a few small things.

How do you see the approach working and what are the thoughts of others on the list?

Thank you,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:00 PM
To: 'Adam Montville'; Moriarty, Kathleen; [email-masked]
Subject: RE: [mile] IODEF Reference Format for Enumerations

Sincerely,
Take

> > >> Behalf Of Adam Montville

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 27 Apr 2012 07:31:55 +0900

Hi Kathleen

> Can you explain more on how you see merging the two into one document?

Yes, I think it would be fine.
I do not see the benefit of having two drafts for describing enumeration/id
values (e.g., CVE-IDs).

> The only concern I have is that specifying the enumerations could be done
> without including the MITRE specifications right into the document, so
> we *MAY* not have to worry about the normative references (but I would
> need to confirm that).
> 

I would be happy to hear people's opinion, but I think the option 2/3 and
SCI draft has some overlap, as mentioned above, and I do not see any point
to have similar but different drafts.
It would simply cause some confusion, I think.

On the other hand, if it is still better to have two distinct drafts, that
is also one option.
In that case, we need to clarify the distinction between the two drafts.

Both drafts describe enumerations (ids) in a similar manner, but one is
using SCI classes while the other is using Reference class.
If we cannot define any clear distinction, I think merging them into one
would be better.
The option 3 could be extended so that it could include the essence of the
current SCI draft, for instance.

I might be still behind discussion, so I would appreciate to hear comments
from the list.

Kind regards,

Take

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, April 26, 2012 9:48 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Can you explain more on how you see merging the two into one document?
> The only concern I have is that specifying the enumerations could be done
> without including the MITRE specifications right into the document, so
> we *MAY* not have to worry about the normative references (but I would
> need to confirm that).
> 
> > If Option 3 could cover the rest of the classes including the ones
> > that do not have any ID yet, I think it is reasonable to merge the
> > works into one.
> 
> but also the other classes), some of which supports XML without any IDs,
> I think it is reasonable to merge the works into one.
> > If modifying IODEF is allowed, I do not see any point to define
> > classes under AdditionalData class (as SCI draft does) since it makes
> > the XML longer.
> >
> > Since the new Option 3 and the sci draft are not that different, it
> > would be fine for me to combine them into one.
> > Sci draft defines several containers for each semantics, and
> > positioned them under AdditionalData class, while new Option 3 defines
> > one container with semantic information that requires no additionalData
> class.
> > If Option 3 could cover the rest of the classes including the ones
> > that do not have any ID yet, I think it is reasonable to merge the
> > works into one.
> > The remaining issues for the SCI draft were as follows in my
> > understanding 1. "namespace identifying specification" needs to be
> confirmed 2.
> > The merged work will inherit the above issues, and I am happy if you
> > could lead the work.
> > > Or, perhaps the class information could be referenced in an IANA
> > > table in a manner consistent with Options 1 and 2...  So, if there's
> > > a registryId, then some semantic information about the types of
> > > classes accepted by that registryId could be discovered.
> > >
> > > >The slight difference between the SCI draft and the option 3 is
> > > >that the SCI draft took a semantic approach (vulnerability,
> > > >attackpattern, etc.), while the option three takes general container
> approach.
> > > >> So far, it seems as though more people are speaking up in favor
> > > >>of Option  2.  There are also several comments expressing a desire
> > > >>to choose either  Option 1 or Option 2, but then move to Option
> 3
> > > >>at some point in the
> > > >future.
> > > >> I'd like to understand more about what that really means -
> > > >> This statement references the notion of requiring the first URL
> > > >> of
> > > on
> > > >> IODEF <Reference> element (associated with the <ReferenceName>)
> > > >> to
> > > be
> > > >> understanding what a <ReferenceName> is, and thus how to parse
> > > >> it, but that we have several different mechanisms by which to
> > > >> accomplish
> > > this.
> > > >>
> > > >> Comments? Opinions?
> > > >>
> > > >> Regards,
> > > >>
> > > >> Adam
> > > >>
> > > >> >(draft-takahashi-mile-sci-02), we may be interested to include
> > > >> >the following (not an inclusive list) enumerations in an IODEF
> document:
> > > >> >The IODEF Reference class is described in 3.9.1 of RFC 5070,
> > > >> >where
> > > a
> > > >> >The first option would simply embed the relevant identifier in
> > > >> >the ReferenceName element of the Reference class.  This may look
> > > >> >like the
> > > >> >following:
> > > >> >
> > > >> >    <Reference>
> > > >> >Using this option, a variety of specific identifier formats
> > > >> >could
> > > be
> > > >> >be constrained, nor would new identifier formats necessarily
> > > >> >need to
> > > be

---

From: <[email-masked]>
Date: Thu, 26 Apr 2012 18:50:13 -0400

Hi Take,

Thank you!  I thought the difference was that the SCI draft specified where other schemas would be incorporated into an IODEF document to extend the data model.  The enumerations would be specific to allow references only to be included directly in IODEF where enumerations are used to point to instances of the schema (CVE#1234).

Can you explain your thoughts behind the equivalence so that we can see if there is another option for consideration?

Thank you,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]]
Sent: Thursday, April 26, 2012 6:32 PM
To: Moriarty, Kathleen; [email-masked]; [email-masked]
Subject: RE: [mile] IODEF Reference Format for Enumerations

Hi Kathleen

Kind regards,

Take

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 27 Apr 2012 17:08:18 +0900

Hi Kathleen,

Thank you for your email.
I would like to know why you propose to have new draft to describe CVE-ID
regardless of the existence of the ongoing SCI work.
I am confused.

The benefit of using enumeration values (identifiers, such as CVE-ID) was
discussed on this mailing list last September (see the discussion around
Sept. 2011).
Thus the SCI draft is changed to reflect the discussion since then.
Regarding the CVE, the SCI draft is recommending to embed CVE-ID and not to
embed the raw XML if no special reason exists.

> Can you explain your thoughts behind the equivalence so that we can see
> if there is another option for consideration?

So, if a sender wants to embed CVE-ID, what would be the suggested way?
If the sender follows the SCI draft, he could write the following XML.

If the sender follows the option 3, he could write the following XML or the
likes.

<Reference registryId=" http://cve.mitre.org/cve/downloads/1.0"
referenceClass="some_class">
   <ReferenceName> CVE-2010-3654</ReferenceName>
   <URL>http://www.example.com/path</URL>
   <URL>http://www.otherexample.com/path</URL>
   <Description>Description</Description>
</Reference>

For me, both could be fine, but having two similar ways to convey CVE-ID
should be avoided since both sender and receiver of the IODEF will be
confused.
At least, some navigation should be clearly described in both drafts.
So, I would like to hear why you propose to have new draft for conveying
CVE-ID in addition to the SCI draft.

I have no intention to insist that SCI draft has the right way, and if
community finds better way to convey the CVE-ID, we could simply forget
about the sci draft and work for the new direction. I just think having two
similar but different draft should be avoided since it causes confusion to
receivers/senders of IODEF documents.

Thank you.
Take

> Sent: Friday, April 27, 2012 7:50 AM
> Thank you!  I thought the difference was that the SCI draft specified
> where other schemas would be incorporated into an IODEF document to extend
> the data model.  The enumerations would be specific to allow references
> only to be included directly in IODEF where enumerations are used to point
> to instances of the schema (CVE#1234).
> 
> Can you explain your thoughts behind the equivalence so that we can see
> if there is another option for consideration?
> 
> Thank you,
> Kathleen
> 
> > The only concern I have is that specifying the enumerations could be
> > done without including the MITRE specifications right into the
> > document, so we *MAY* not have to worry about the normative references
> > (but I would need to confirm that).
> >
> I would be happy to hear people's opinion, but I think the option 2/3
> and SCI draft has some overlap, as mentioned above, and I do not see any
> point to have similar but different drafts.
> On the other hand, if it is still better to have two distinct drafts,
> that is also one option.
> The option 3 could be extended so that it could include the essence of
> the current SCI draft, for instance.
> 
> > The only concern I have is that specifying the enumerations could be
> > done without including the MITRE specifications right into the
> > document, so we *MAY* not have to worry about the normative references
> > (but I would need to confirm that).
> >
> > If Option 3 could cover all the classes (not only the vulnerability
> > class but also the other classes), some of which supports XML without
> > any IDs, I think it is reasonable to merge the works into one.
> > > classes under AdditionalData class (as SCI draft does) since it
> > > makes the XML longer.
> > >
> > > positioned them under AdditionalData class, while new Option 3
> > > defines one container with semantic information that requires no
> > > additionalData
> > class.
> > > > table in a manner consistent with Options 1 and 2...  So, if
> > > > there's a registryId, then some semantic information about the
> > > > types of classes accepted by that registryId could be discovered.
> > > >
> > > > >Vulnerability class of SCI draft. (and some other classes as
> > > > >well) The expected usage of the Vulnerability class of current
> > > > >SCI draft, with CVE identifier, is as follows.
> > > > >
> > > > ><iodef-sci:Vulnerability
> > > > >> Thank you for running the list of options by the WG and to
> > > > >> those participating in the decision process!
> > > > >>
> > > > >> We have had a couple of reasons discussed to 'open' up IODEF.
> > > > >>If we get  a volunteer to help with the editing of an RFC5070
> > > > >>soon, then option 3  may be worth considering.  I would expect
> > > > >>that a revision
> > > > to
> > > > >>RFC5070 would  take some time as the list works through issues
> > > > >>and options.
> > > > >>
> > > > >>of Option  2.  There are also several comments expressing a
> > > > >>desire to choose either  Option 1 or Option 2, but then move to
> > > > >>Option
> > 3
> > > > >>at some point in the
> > > > >future.
> > > > >> indicated a preference with respect to later moving to Option
> > > > >> 3,
> > > do
> > > > >> specifications between the SCI draft and the new draft on use
> > > > >> of the IODEF reference format."
> > > > >> >There are several ways to accomplish this goal.  I'll do my
> > > > >> >best to enumerate some options here, then I hope to hear some
> > > > >> >The registry may be used to identify the identifier category
> > > > >> >and potentially the appropriate identification format for that
> > > category.
> > > > >> >
> > > > >> >
> > > > >> >Option 1: Simple ID
> > > > >> >===================
> > > > >> >the ReferenceName element of the Reference class.  This may
> > > > >> >look like the
> > > > >> >following:
> > > > >> >
> > > > >> >    <Reference>
> > > > >> >Using this option, a variety of specific identifier types
> > > > >> >could
> > > be
> > > > >> >specified, such that the identifier itself would not
> > > > >> >necessarily be constrained, nor would new identifier formats
> > > > >> >necessarily need to
> > > > be
> > > > >> >I look forward to fielding responses to these options,
> > > > >> >including any additional options you may see, but which are
> not listed.
> > > > >> >

---

From: <[email-masked]>
Date: Fri, 27 Apr 2012 09:19:17 -0400

Hi Take,

I think there is a misunderstanding and hopefully we can clear that up.  I was not aware that you had changed the most recent version of the SCI draft to include a standard way to represent enumerated values.  I will read through the updated SCI draft and ask that others on the list do so as well.  Your description of options below is helpful as well, thank you!

As a WG we will need to come to a consensus on how to handle the two types of representations now covered, specifically, schemas where data is not represented in the base data model and the method of representing enumerated values so that we will be able to send and receive them in a standard way.

My opinion: I think that we should use the base IODEF data model when possible and extend when needed (others, please chime in on your thoughts of how this should be approached to assist with a decision on the representation).  For this discussion, that would mean using the reference class for enumerations with one of the examples Adam proposed (Take, this would just mean updating the draft to use the option preferred by the WG) and then guidance on when to extend IODEF to include other schemas.

I thought this was not covered and was hoping we could avoid the problems with the lack of normative references depending on how the enumeration draft was written.  I am fine to go forward in one draft if that is the preference.

Thank you very much for all of your hard work on the SCI draft and I am sorry there was confusion I may have caused.

Best regards,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]]
Sent: Friday, April 27, 2012 4:08 AM
To: Moriarty, Kathleen; [email-masked]; [email-masked]
Subject: RE: [mile] IODEF Reference Format for Enumerations

Hi Kathleen,

Thank you.
Take