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

RE: Candidate numbering scheme

I would agree, the shorter number scheme definatly makes readability
smother.

Craig


> -----Original Message-----
> From:	Adam Shostack [SMTP:adam@netect.com]
> Sent:	Friday, May 14, 1999 7:29 AM
> To:	Bill Hill; cve-review@linus.mitre.org
> Subject:	Re: Candidate numbering scheme
> 
> I agree with Dave that shorter numbers are more usable by people.
> I'll also agree with Bill that if we have substantial discussion of a
> candidate, we can point to it in the references.  I think we should
> move ahead to working with some of the CVE sub-lists, either the easy
> or the hard ones, to get closer to release.
> 
> Adam
> 
> 
> On Fri, May 14, 1999 at 08:32:25AM -0400, Bill Hill wrote:
> | I agree with Steve's points.  
> | 
> | I've been an advocate of minimalism where the core CVE is concerned, but
> | I can see a lot of value in being able to map between candidate
> | info/threads/etc. and the CVE.  It seems to me (for all the reasons that
> | Steve mentioned) that the proposed candidate numbering system still
> | requires that the CVE maintain references to candidate numbers in some
> | cases.    
> | 
> | I suggest adding this information as an explicit reference(s).  Not sure
> | if this would mean something in the CMEX, or the CVE proper. 
> | 
> | I strongly suggest keeping this or any kind of data out of the CVE
> | number itself.  During our many design discussions we've been tempted to
> | put "stuff" in there, and we've always found it introduces unwanted
> | complications, inconsistencies, etc.  We've always (at least so far :-)
> | found better ways of handling the problem, and I think our focus on
> | keeping the CVE number and data simple and "pure" has helped make as
> | much progress as we have already, and will help us really push forward.
> | 
> | Of course, this is all IMHO :-)
> | 
> | Bill
> | 
> | "Steven M. Christey" wrote:
> | <SNIP>
> | > 
> | > There is a third problem which I believe is the most significant.
> | > Multiple candidates will be proposed that wind up being part of the
> | > same CVE vulnerability (let's say they are duplicates, or they're both
> | > subsumed by them), or split into multiple CVE vulnerabilities.  There
> | > won't be a one-to-one relationship between the candidate number and
> | > the CVE number, so the CAN- portion will be different than the CVE-
> | > portion.  This would require a "lookup" capability to go from the
> | > candidate number to the real associated number.  I.e., we would
> | > *still* have to maintain a mapping from candidate numbers to the CVE
> | > numbers.
> | > 
> | > None of these problems is significant if the candidate number is never
> | > really public, and only for use within the Input Forum.  They might be
> | > relatively minor compared with some of the benefits, e.g. "early
> | > tracking" of new vulnerability information, and allowing Input Forum
> | > members (e.g. vendors) to use candidate numbers in advisories that
> | > they post for new vulnerabilities.
> | > 
> | > The question is: how important is it to the members of this group that
> | > we should have such "external candidate numbers"?  Russ' perspective
> | > is clear since he is concerned with numbering vulnerabilities as early
> | > as possible, and I believe Andre would agree since he expressed
> | > concerns with getting numbers for advisories for new vulnerabilities.
> | > A second question is: assuming we have external candidate numbers, do
> | > they *have* to be the same as the CVE number?  To reduce confusion,
> | > sure, but there won't always be a one-to-one relationship as I
> | > indicated earlier.
> | > 
> | > I think that such a radical change to the CVE name requires a decision
> | > before release.  Any commitments we make to a numbering scheme will
> | > have to be adhered to once the CVE is public.
> | > 
> | > - Steve
> | 
> | -- 
> | ----------------------------------------------------------------------
> | William Hill                                            V:703-883-6416
> | INFOSEC Engineer                                        F:703-883-1397
> | The MITRE Corporation                                   bill@mitre.org
> | 1820 Dolley Madison Blvd.  M/S W422                     whhill@acm.org
> | McLean, VA  22102-3481
Page Last Updated or Reviewed: May 22, 2007