[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Candidate numbering scheme discussion - summary so far


Adam Shostack said:

>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 [before it is reviewed by the board].
>Really only the second state requires a number early.

I think this is a fair assessment.  This also means that there may be
relatively few candidate numbers that appear in advisories.  I suspect
that in general, not too many candidates will become fully public.
Yes, someone reading the archives of EB (Editorial Board) discussions
will see candidate numbers, but anyone who's *that* interested in
those discussions should know the difference between a CVE number
versus the candidate (or be informed of the difference).

>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.

I think the CAN system helps to reinforce the fact that a
vulnerability hasn't been fully discussed in the CVE context.  In my
opinion, a CVE number should only be assigned to a well-understood
vulnerability.  The CVE "label" should imply stable information.
Candidates by their nature will be largely unstable.  So assigning a
CVE number to a candidate "dilutes" the power of the CVE name, to use
Russ' terminology.  Also, under Adam's proposal, only board members
would be able to assign CVE numbers.  This would remove (or limit)
OS/application vendors such as Microsoft, Sun, NetBSD, etc. from
getting their own numbers - or it would force them to share sensitive
data with a board member.  If we allow the OS/application vendors to
assign their own CVE number, we run a further risk of diluting the
quality of the CVE number - because they might not understand content
decisions as well as board members, and make a mistake which forces
the CVE number to be unaccepted, split or merged, etc.  I think we
want to reduce split/merge and other content operations as much as
possible, *especially* for CVE numbers.  Another risk with having
"proposed" CVE numbers instead of candidates - what happens when
someone else refers to that CVE number but doesn't say it's
"proposed"?  It's inherently given more "stability" than is warranted.

I think we should stay with the CAN approach.  And even if it doesn't
work as expected, I believe it would be easier for us to go from the
CAN approach to something like Adam suggested, than to do it the other
way around.

Comments?

- Steve
Page Last Updated or Reviewed: May 22, 2007