再保险:候选人编号方案

我同意,短数方案definatly使可读性窒息。克雷格> - - - - - - - - - - - >从原始信息:亚当Shostack (SMTP: adam@netect.com) >发送:星期五,5月14日1999年29我>:比尔山;cve-review@linus.mitre.org >主题:Re:候选人编号方案> >我同意戴夫,短的数字更有用的人。>我也会同意比尔,如果我们有实质性讨论的一个候选人,我们可以指向它的引用。我认为我们应该>继续处理一些CVE列表,简单>或硬的,接近释放。亚当> > > > >在星期五,5月14日,1999年在08:32:25AM -0400年,比尔希尔写道:|我同意史蒂夫的点。> | > |我一直倡导的简约主义核心CVE而言,但> |我可以看到很多有价值的候选人之间能够地图> |信息/ etc /线程。CVE。在我看来(所有的原因> |史蒂夫提到),提出候选人编号系统仍然> |要求CVE保持对候选人在一些> |病例数量的引用。> | > |我建议添加这个信息作为一个显式引用(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: > |  > | > > | > 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