Re: Proposal: CVE candidate/approved numbering scheme
So, I'm uncomfortable with the amount of structure we've put into
candidacy, and am trying to find ways to simplify it. I've been
trying to effectively eliminate CAN numbers from the system.
It seems to me that we have two classes of vulnerability for which we
want CAN numbers; published issues that the editorial board wants to
discuss, and advisories where the publisher wants to include a CVE
related number in the advisory.
Really only the second state requires a number early. The issue here
is, when to number? I don't think that Aleph is interested in seeing
items that go through bugtraq numbered, but Russ wants numbers on
NTbugtraq. This difference comes from differences in the level of
moderation and control of the list contents; Aleph is very liberal,
Russ more conservative. Russ tends to verify things before passing
So, as a straw man, I'd like to propose that we replace the CAN system
with the ability to enter something in the CVE as "PROPOSED." Any
member of the board can assign an issue a CVE number, which is then
assigned to that problem. The CVE will contain issues which are later
found to be known, or otherwise modified or denied.
The CVE will end up with more in it than if we let the vetting happen
in the CAN state, but the numbers will be no less sparse, since we'll
have to keep the concordance between candidates and approved numbers.
(Perhaps we can avoid locking by having each board member have a small
group of numbers which they "hold" and can assign at will. Those
members who publish a lot can hold a larger group, or anyone can say
"I'm going to need a dozen over the next week, can I take 6412-6425?")
This proposal offers simplicity in that we only have one type of
numbers, CVE, rather than two, CAN and CVE. It offers more simplicity
in that we do not define a stage of candidate numbering, and entities
with that privledge.
On Thu, May 20, 1999 at 01:13:27PM -0400, Steven M. Christey wrote:
| Elias said:
| >Just exactly why would you need CAN-numbers in bulk? The most
| >vulnerabilities I've ever seens any one organization publish in
| >a single day has been three or four.
| I agree with Russ that a new CNA might need a number of candidates all
| at once. There are also some potentially high-volume CNA's - for
| example, the *Bugtraq moderators may want to follow up emails to the
| lists with a candidate number, or provide one for the poster to
| include in their email. (Just a suggestion, I know there might not be
| a particularly efficient way to do this, and it adds to the workload.)
| But I think we should encourage CNA's to only reserve the number of
| candidates they plan on using within, say, the next week or so.
| Otherwise we'll introduce additional overhead by having to track a
| larger number of inactive but pending candidates, as well as
| increasing the risk of filling the candidate name space (i.e. 9,999
| per year) due to "hoarding." Some of that problem could be handled by
| "expiring" unused candidates after a particular amount of time, but
| that approach seems aesthetically unpleasant to me.
| - Steve