Re: Candidate numbering scheme

[Aleph One <aleph1@underground.org>]

On Fri, May 14, 1999 at 02:53:37PM -0400, Steven M. Christey wrote:
> 
> Elias said:
> 
> >The only concern I have is that the candiate numbers never make it
> >outside the working group...  Of curse this screws the fact we will be
> >using candidate numbers during our discussion and the discussions will
> >be public.
> 
> I don't think there's really a way around this, but the candidate
> numbers might only be exposed to those people who want to observe the
> process.  Perhaps we could provide a "disclaimer" or warning that they
> should only use the CVE number.
> 
> I think having "fully public" candidate numbers serves several
> purposes.  To me, the primary benefit is for early tracking of
> vulnerability information.  For example, the *Bugtraq moderators could
> use their own candidate number namespace to assign to postings (let's
> avoid the feasibility of such an approach for a moment).

That is exactly what I *don't* want. The second we start using
these "candidate" names in *BUGTRAQ you can forget about anyone
using the CVE number. They still continue to use the "candidate" number.

> 
> I think that most or all advisories should reference a CVE number in
> their first publication, since advisories are often a primary,
> universal source of vulnerability information.  It helps to get *some*
> number into advisories that announce a vulnerability for the first
> time (say, a vendor's security analysis team).  The sense that I get
> is that vendors believe they have a competitive advantage in
> announcing discovery of new vulnerabilities in their own advisories,
> and may not be willing to give this up.  If they aren't willing to
> give away such information (at least to the input forum), then there
> are 2 workarounds I can think of.  Public candidate numbers are the
> easiest way to address this problem.  A different mechanism might be a
> "secure channel" between MITRE and the advisory team which could
> result in a "conditional" assignment of a new CVE number.  Probably
> the best way would be for the advisory team to post an initial
> "pre-advisory" to the Input Forum for a brief and timely discussion,
> and CVE number assignment.  The benefits would be twofold: (a) all
> vendors would know of the vulnerability and be able to update their
> tools [which would immediately benefit *all* tool users], and (b) the
> first fully public advisory would have a CVE number.
> 
> The greatest risk in having public candidate numbers is in the
> potential confusion caused by multiple numbering schemes.  The CAN-
> prefix makes it clear to knowledgeable people that the vulnerability
> is "unreviewed," but the candidate number could become more widely
> used than the CVE number.  We want to minimize this problem as much as
> possible, IMHO.  If we decide to adopt a public candidate numbering
> scheme, then we need to make it clear to everyone, including the end
> users, that candidate numbers are in no way "official."
> 
> - Steve
> 

-- 
Aleph One / aleph1@underground.org
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01