[TECH] CVE Entry Deprecation Process

["Steven M. Christey" <coley@linus.mitre.org>]

This was discussed during various meetings in the past, and is posted
mostly for reference.  However, feedback is welcome.

- Steve



CVE Entry Deprecation Process
-----------------------------
Version: 1.0

This document describes the process by which CVE entries are
deprecated.

While the CVE candidate review process is designed to minimize the
number of entries that are erroneously created, there is a risk that
an entry is improperly assigned.  For example, a duplicate entry may
be added, or an existing entry may need to be split into different
entries, or merged with other entries.  When such a change is needed,
a CVE entry may need to be deprecated.

The following process will be followed when an entry is slated for
deprecation.

1) The CVE Editor identifies which entries need to be deprecated.

   If there are duplicate entries, then the entry that was most
   recently added to the CVE list must be deprecated.  If the
   duplicates were added in the same version, then the least
   authoritative entry must be deprecated.  If the duplicates are
   equally authoritative, then the highest numbered entry must be
   deprecated.

2) The Editor sends an email to the Editorial Board to identify those
   entries that have been targeted for deprecation.  For each entry,
   the reasons for deprecation will be noted.  The subject line will
   include the tag:

     [ENTRYDEP] Deprecate N REASON entries (Final DATE)

   The REASON for deprecation will be included on the subject line,
   such as "Duplicate," "Recast," and "Not-Real."  N is the number of
   entries to be deprecated.  DATE is the expected date on which a
   Final Decision will be made.

3) The Board is provided with at least 4 business days to evaluate the
   proposal, possibly longer.

4) If Editorial Board members disagree with the proposed deprecation
   for any entry, then they send feedback to the Editor or to the
   entire Editorial Board.  If they agree with the proposal, they may
   remain silent.

5) After the review period, the CVE Editor makes a Final Decision to
   deprecate the entry (barring any feedback by Board members).  The
   Final Decision must not occur before the DATE as specified in (2)
   above.  The decision is sent to the Editorial Board mailing list
   with the subject tag:

     [ENTRYFIN] Deprecate N REASON entries

6) After the Final Decision, the entry is modified in the next CVE
   version.

7) The description of the entry is modified to say that it has been
   deprecated, and it also provides the reason for deprecation.  The
   format of the description will be:

     DEPRECATED.  This entry has been deprecated.  <REASON>

   where <REASON> describes the reason for deprecation.

8) If the entry is a duplicate, or if it has been recastm then the
   correct CVE entry or candidate is identified in the reason.  All
   associated references and other descriptive text are removed.

9) The deprecated entry is listed in the CVE difference report for the
   new CVE version.

10) The deprecated entry remains in the CVE list, in case
   CVE-compatible tools still use the deprecated entry.