[CVEPRI] Editorial Board meeting summary - 12/15/1999
Here is my summary of yesterday's teleconference. If I left anything
out or you'd like to make some comments, feel free.
CVE Editorial Board Review Meeting - 12/15/1999
Below is a writeup of the Editorial Board review teleconference that
took place on December 15, 1999.
The following Board members participated in the teleconference:
Other participants included Marv Christensen (IBM ERS), Char Sample
(L-3), and Jim Magdych (NAI).
MITRE participants included Margie Zuk, Bill Hill, Dave Baker, and
A meeting was held earlier that day between Steve Christey and Eric
Cole, who was unable to attend the teleconference.
Candidate Status Update
An update on candidates was provided. Various Board members confirmed
that they will be voting on recently proposed clusters. In addition,
some older candidates may be approved with one more vote. It is not
certain yet whether the Board will achieve the goal of 500 entries by
January 1. MITRE is working on ensuring that candidates are added for
all known 1999 problems, a goal that was proposed and approved in the
last Board teleconference. A question arises as to how we can be
certain that we have covered all publicly known problems.
We discussed the short term plans for candidates over the next month.
"Semi-live" assignment of candidates will continue until mid-January.
On a weekly basis, a candidate cluster will be proposed to the Board
which identifies all problems that were announced in the previous
week. Board members were encouraged to submit any additional problems
that may be missing from these clusters.
The CVE web site will be updated in mid-January to handle candidates.
Search utilities and downloads will be enhanced for candidates; in
addition, web pages describing the candidate concept will be included.
Once the web site has been updated, live candidate assignment will
begin. A "legacy cutoff date" will be set at that time; all
candidates that were publicly known before that date will be
considered "legacy" with respect to CVE.
Introducing Candidates to the Public
Different consumers of candidate information were identified. They
include Editorial Board members who may use that information for
voting and inclusion in their own databases; interested parties such
as other database developers and data summarizers; visitors to the CVE
web site; and casual observers who may only want high level
information regarding how many candidates have been approved, etc.
There is a potential complication with introduction of candidates into
the public, and how candidates are currently processed by the Board.
Typically there has been a delay between number asignment and proposal
to the Board, e.g. for candidate clusters. It was suggested that a
forced delay between assignment and proposal might actually be useful,
as the understanding of the underlying issue may improve in that time.
There was some discussion about the best way to introduce the concept
of candidates to the public. Two basic approaches were discussed:
make a formal announcement first, or just start using them and include
short annotations when candidates are being used, e.g. in advisories.
Formal announcements may be a challenge to do effectively, given the
common misconceptions that the public already has about CVE. It was
suggested to use a metaphor to educate the public about the
differences between candidates and CVE entries: candidates are raw
information which is not guaranteed to be fully vetted, like posts to
NTBugtraq; CVE entries are refined and validated, like advisories.
With respect to using short annotations in publications such as
advisories, it was proposed that the following should be done:
1) Use a short phrase after the candidate number to emphasize that it
is not a guarantee of inclusion into CVE. An example would be:
CAN-1999-XXXX (pending validation)
It was suggested to use the phrase "proposed" instead of "pending
validation." There may be a small complication with this particular
term since proposal is a specific phase in how candidates are
processed, but there were no major concerns that this discrepancy in
terminology would cause any significant misunderstanding on the part
of the public.
2) Use a short descriptive text that explains what the candidate
number is. The following sentence was proposed and discussed:
"This is a candidate for inclusion in the Common Vulnerabilities
and Exposures list, which standardizes names for security
weaknesses. It is pending validation by the CVE Editorial Board."
Various modifications were suggested for this text, including:
- replace "weaknesses" with "issues"
- emphasize that the candidate is a "temporary" identifier, and if
the candidate is accepted, it will become a CVE entry
- replace "validation" with "review" or "acceptance"
The Editorial Board will further discuss this text on the mailing
What Information to Publish
The Board discussed the following information associated with
candidates, and whether it should be made publicly accessible:
- name and description
- phase (assigned, proposed, interim decision, etc.)
- associated content decisions
- moderator comments
- votes (who voted, and what the votes were)
- voters' comments
A sample web page was provided. Nobody expressed a concern that this
information should be kept private. This information is already
included in voting summaries, such as Interim and Final decisions for
candidates. However, some people weren't sure if information such as
votes and voter comments would be useful to many people, and if it was
necessary to present it when it can already be seen in the mailing
list archives. Voting comments might be useful to non-Board members
who are interested in the issues surrounding a candidate, e.g. why it
hasn't been accepted, or why it was ultimately split or merged with
other candidates. A compromise was offered in which additional
information could be provided to a user through an additional link or
a checkbox. This would allow MITRE to determine whether that
information is being used.
Some Board members were surprised to know that voter comments were
being recorded and publicly viewable. It was suggested that Board
members be reminded that their votes and comments will become public,
so that they can use appropriate discretion. Voting ballots will be
annotated to include this reminder.
Use of Candidates in Mailing Lists
Some time was spent discussing the issues related to integrating
candidate numbers into discussion forums such as the Bugtraq and
NTBugtraq mailing lists. Due to how moderation of such lists is
performed, the moderator is unable to modify the original text of a
post in order to insert a candidate number. A followup to the
original post that includes the number would associate the candidate
with that thread; however, the original post would not be returned if
a user searches an archive for a specific candidate number. An
alternate method would be to have MITRE (or another CNA) provide a
number to the moderator or the poster, who could then ensure that it
is integrated into the original post. However, this could increase
the amount of time it takes for the moderator to approve the message.
A third option would be to have the moderators act as CNA's and take
care of assigning numbers themselves, working from a block of
candidate numbers that the CNA has allocated to them. However, this
could result in increased "noise" for candidate numbers with respect
to duplication or level of abstraction. For example, many content
decisions in CVE are unresolved and have not been sufficiently
documented for use by other CNA's, and there is an increased risk of
duplication. While it is uncertain how risky this third option would
be, Board members seemed willing to take this risk in the early days.
Further offline discussion will take place with interested parties to
determine the best approach.
Frequency of Candidate Announcements
There was some discussion about how often candidates should be made
available to the Board, to interested parties, to the web site, or to
the rest of the public. With respect to legacy candidates, a weekly
schedule has appeared to work well. It was also agreed that weekly
proposals of newly discovered candidates will be sufficient for most
purposes, but more frequent updates could be made available on an ad
It was suggested that each newly discovered candidate should be
proposed in a separate email. A concern was raised that this would
increase the amount of traffic to the list significantly; for example,
60 new candidates had been proposed in the previous two weeks.
For newly discovered candidates, it will often be the case that when a
number is assigned, it may be made available to the public before the
candidate is proposed to the Board. For that reason, updates may need
to be provided more frequently to interested parties. This could be
done through regular web site updates or distribution to a "rapid
response" mailing list.
Implications of Public Candidates
Some implications were discussed with respect to making candidates
publicly known. If CVE entries are not approved rapidly enough by the
Board, then candidates may become the de facto standard. This concern
could be limited by more efficient voting, which could be improved if
Board members integrate candidate numbers into their database
population activities. There are also some potential implications
with respect to CVE searchable databases. A user may enter a
candidate number into a CVE searchable database; how should a database
handle this, e.g. if the candidate is associated with an approved CVE
entry? It was re-emphasized that the notion of CVE compatibility will
only apply to CVE entries, but it was recommended that CVE searchable
databases consider the issues related to use of candidates for search.
Private Candidate Assignment
A brief discussion was held with respect to the private assignment of
candidate numbers to Board members who want to include the numbers in
first-time announcements of new security flaws. A PGP key for the CVE
content team will be made available so that those members can encrypt
their transmissions if they wish. Members should request candidate
numbers as close to their scheduled announcement date as possible.
The candidate must be slated for public dissemination.
To avoid potential competition with organizations that introduce new
security problems to the public, MITRE will not announce or propose
any candidates before they have already been publicized.
As private candidate assignment may only be desired by a small number
of Board members, it will be handled on an ad hoc basis. Roughly, the
process may be as follows. The "requestor" submits information to
MITRE with sufficient details for MITRE to look for duplicates, apply
the appropriate content decisions, and generate a description. The
requestor also states how quickly they need a response, which can be
no less than 1 business day. MITRE returns a candidate number(s) and
description to the requestor, deleting or encrypting the associated
data to minimize potential information leaks. The requestor must then
notify MITRE when the candidate has been published. To follow up with
the requestor for updates on the status of the private candidate,
MITRE would need to record who requested that candidate. Board
members did not express a problem with MITRE keeping this information,
provided it was not made available to any other organization.
A potential situation could occur when a requestor asks for a private
candidate number for a problem that has already had a private number
assigned to another requestor. MITRE would be very limited in what
actions it could take, as most solutions could result in some release
of competitive information (e.g. by implying that an unnamed
competitor is already working on the same issue). Since it is
expected that this will rarely happen, it may be best for MITRE to
assign a separate private candidate even though it is a duplicate of
another private candidate, then merge the candidates before they are
combined into a single entry, giving preference to the first
MITRE will work offline with interested Board members on the mechanics
of private candidate assignment.
Various suggestions were made to Board members regarding how to
process candidates. They included:
- Voting on a partial cluster is better than no votes at all
- Use NOOPs if you can't vote
- Keep your database up-to-date with respect to new candidate numbers
- Make ad hoc requests for candidates to vote on, e.g:
- All CAN's with Microsoft advisories
- CAN's needing only one more vote
- Unix/NT problems [noisy and incomplete]
- New/legacy problems proposed since YYYYMMDD
Eventually, an online web site will support Board members in their
voting activities. Until then, Board members can make ad hoc requests
for such information.
Next Face-to-Face Meeting
Craig Ozancin said that AXENT is willing to hose the next face-to-face
meeting in Salt Lake City, Utah sometime in February. A 2-day meeting
will be planned, and a basic agenda will be posted. The Board will
determine the specific date on the mailing list.