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:
>>> https://cve.org/CVERecord?id=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: https://cve.org/CVERecord?id=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: https://cve.org/CVERecord?id=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: https://cve.org/CVERecord?id=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