Re: CVE Current States

["kseifried@redhat.com" <kseifried@redhat.com>]

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