Define the expiration process for reserved CVE IDs

[EvansJonathan]

GOAL: Make the CNA processes more standardized and repeatable.
CHANGE: Describe when and how reserved CVE IDs become expired (e.g. unused IDs are rejected at the start of the new year). Should assigned but reserved CVE IDs have an expiration?
OUTCOME: Consumers of the CVE List will know which CVE IDs are usable.

[kurtseifried]

Please note some CNAs, e.g. Red Hat have blocks of CNAs for previous years, a week ago I assigned a 2014 CVE (this is in summer of 2017). Like my email to the board, I think it';s about managing expectations, e.g. is this CVE for a timely issue, or part of a block for historical stuff that may never be used?

[EvansJonathan]

If #24 gets approved, then reserved blocks for previous years would be unnecessary. Also, I believe Red Hat is the only CNA that has felt it necessary to have reserved blocks for previous years. All others request them on an as-needed basis.

This is also a question about incentives. For example, if we put an expiration date of two years on all CVE ID, there is an incentive to ensure that vulnerability becomes public and the entry is populated by the deadline. Of course, if #11 is approved, this would not be appropriate.

[dadinolfi]

There are two different issues here:

1. Describe when and how reserved CVE IDs become expired (e.g. unused IDs are rejected at the start of the new year). This is current practice, and we should codify this in the CNA Rules. This was already discussed within the Board and the CNAs are already doing this.
2. Should assigned but reserved CVE IDs have an expiration? This is a new idea that requires separate discussion.

I'll discuss them separately below.

[dadinolfi]

Suggestion: For issue 1, add to section 3.2.1 a fifth requirement.

5. Maintain a process for rejecting unused reserved CVE IDs each year. One example process would be: at the beginning of each calendar year, CNAs must indicate to the Primary CNA which CVE IDs from the previous calendar year were not assigned to a vulnerability. Those CVE IDs that were unused would be rejected. (CVE IDs for previous calendar years can always be requested from the Primary CNA if necessary.)

[dadinolfi]

As @EvansJonathan noted above, if we change the assignment rules surrounding year to just be the year the CVE ID is assigned, we have a simplified situation. We can say that any CVE IDs a year or more old that are assigned but not yet populated will be rejected until and unless the CVE ID has been updated with the necessary descriptive information. (It is now practice that CVE IDs that are marked as "rejected" can be changed back to a non-rejected state.)

Suggestion: create section 3.2.1.6 in Assignment Rules for the Primary CNA
6. Maintain a process for rejecting assigned-but-unpopulated CVE entries based on an expiration period. For example, that period may be “if a CVE ID was assigned two years ago but the entry for it was not populated by the assigner, the CVE ID will be rejected”. The specific time frame should be publicly documented by the Primary CNA and can be updated based on the needs of the CVE community.

[EvansJonathan]

#37 also has to be approved for the expiration of unassigned IDs to occur. If the expiration process is the same in all cases, then #37 does not apply.