Ditto.
On 06/14/2017 10:19 AM, Landfield, Kent wrote:
> Sadly I too will not make the call today.
>
> Kent Landfield
> Kent_Landfield@McAfee.com
> +1.817.637.8026
>
>> On Jun 14, 2017, at 12:17 PM, Art Manion <amanion@cert.org> wrote:
>>
>>> On 2017-06-14 10:25, Coffin, Chris wrote:
>>> Here is what I think we are driving to in this thread. We can
>>> discuss more on the call today if needed.
>>
>> I won't make the call today, here's some input.
>>
>> 1. When we're ready, publicly document states, including a state
>> transition diagram. A colleague of mine started one but it's not
>> quite ready to share.
>>
>>> STATE:UNASSIGNED: A CVE that has never been RESERVED. The CVE
>>> master list provides an error message in the case that someone
>>> attempts to view this CVE ID.
>>> Example:
>>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2001-10000
>>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>>
>> This is the default state, correct? This state should never appear
>> in a CVE data record?
Agreed.
>>
>>> STATE:RESERVED: A CVE Identifier (CVE ID) is marked as "RESERVED"
>>> when it has been reserved for use by a CVE Numbering Authority
>>> (CNA) or security researcher, but the details of it are not yet
>>> populated.
>>> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-1253
>>> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to
>>> a CNA
>>> STATE_DETAIL:ASSIGNED - assigned to a vulnerability
>>
>> Are these finite state details? If reserved, must also be
>> cna_allocated or assigned, state detail can't be empty?
I think so, unless there are other RESERVED states (I can't think of any
though).
>>
>>> STATE:REJECT: A CVE ID listed as "REJECT" is a CVE ID that is not
>>> accepted as a CVE ID. The reason a CVE ID is marked REJECT will
>>> most often be stated in the description of the CVE ID.
>>> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784
>>> STATE_DETAIL:DUPLICATE_ASSIGNMENT
>>> STATE_DETAIL:DUPLICATE_RESERVATION
>>> STATE_DETAIL:DUPLICATE_TYPO_SEQ_OR_YEAR
>>> STATE_DETAIL:MIXED_ISSUES_OR_DUAL_USE
>>> STATE_DETAIL:MERGED
>>> STATE_DETAIL:WITHDRAWN
>>> STATE_DETAIL:EXPIRED
>>> STATE_DESCRIPTION: // probably the only STATE where this is required
>>
>> Again, is state detail required?
I think we should require this, otherwise "it's broken. can't tell you
why or how. Maybe there's another CVE related to this (duplicate) or
maybe not."
>>
>> If duplicate or merged, must description note the other IDs involved?
I'm going to say yes, as you must submit that data to MITRE anyways
currently AFAIK.
>>
>>> STATE:POPULATED: The CVE entry has been published with at least a
>>> minimum amount of detail and at least one public reference.
>>> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0002
>>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>>
>> There is currently a PUBLIC state I think. Is populated replacing
>> public?
I think perhaps this is to distinguish between "PUBLIC" being someone
published it somewhere, and it showing up in the CVE database?
>> Regards,
>>
>> - Art
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com