Initial Candidate Proposal and Acceptance Process

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

All:

Below is a process I have defined for proposing and discussing
candidates.  This process is open to adaptation by the Editorial
Board, as we go along and test it out, but in the interests of getting
*something* rolling, I'll follow this method to begin with.

0) While Dave Mann and I have taken the "silence implies assent"
approach, I believe it is important that everybody speak up for this
part of the CVE validation.  It's hard to know if someone's reading
and silently agreeing, or if they're off on vacation somewhere.  So
please speak up!

1) At the moment, I will be the only Candidate Numbering Authority
(CNA), so I am the only one who can propose candidates.  This will
change as we get closer to release, probably once we're discussing the
"Unknown" candidate cluster and/or bringing in new vulnerabilities.
(See another email for discussion of candidate clusters).

2) I will propose each cluster in a separate email.  Each candidate in
the cluster will include:
  - candidate number
  - proposer ID (just 001 for me, right now)
  - date assigned (i.e. date the candidate is "reserved" for use)
  - date announced (date candidate name is made public)
  - category
  - reference(s)
  - description

The candidate number will be equivalent to the CVE number (in version
199904290013), i.e. CAN-1999-00345 will be the same as CVE-00345 in
your CVE distribution.

3) Each member of the Editorial Board should respond to each
candidate.

The following responses are valid:
  (a) REVIEWING - member is reviewing/researching the candidate.
  (b) ACCEPT - member approves the vulnerability as proposed.
  (c) NO OPINION - member specifically avoids commenting on this
      vulnerability.  May be useful e.g. if member is not an expert
      for that particular type of vulnerability.  NO OPINION's are
      strongly discouraged.
  (d) REJECT - member rejects the candidate entirely, because:
        - it is not a vulnerability (i.e. was reported as a problem
          but turned out not to be)
        - it is unconfirmed (or not sufficiently confirmed)
        - it is not a *CVE vulnerability*, i.e. does not fit the CVE
          vulnerability definition
        - it is a duplicate
        - it subsumes a CVE vulnerability (i.e. it's too high level
          and encompasses existing vulnerabilities)
        - it is subsumed by a CVE vulnerability (i.e. it's an instance
          of an existing CVE vulnerability)
  (e) MODIFY - vulnerability is generally acceptable, but some details
      may be missing or wrong, e.g.:
        - description needs slight modification
        - references incorrect
        - category incorrect
  (f) RECAST - there needs to be a better term than this.  The member
      does not believe the candidate as proposed should go into
      the CVE without being heavily modified, e.g.:
        - change level of abstraction of the candidate (merge/split
          with others)

4) Every so often (to be determined), I will pose a "summary" of
candidates that appear to be close to resolution.  I will also develop
a clean way to announce when a final decision has been made.

5) As we get closer to release date, and as vendors/others begin to
identify gaps between the CVE and their own vulnerability databases,
then we will open the process to include other CNA's besides me.