再保险:CVE ID语法变化和选择

2012-11-05 19:47 Christey, Steven m .写道:>编辑部电话会议中讨论在10月31日>是时候更新CVE ID语法,以便CVE可以支持10000多>标识符在一年内(“CVE-10K问题”)。> *建议不同的语法吗?没有,除非我们打算地址显著增加(和可以由选项# 1和7,或除非我们想分区分配空间,必须或其他分布式/联邦系统可以更好地跟踪CVE任务。cve -年- cnaid - 000000 ?我看不出这两种具体计划,和# 1和7可以适应弥补这两种情况下。我更喜欢保持CVE接近当前的语法。新CVE ID >语法是“好”,它应该大部分(或者全部)>以下属性:> > 1)大空间ID,即。,大量潜在的id >分配。总而言之,我不确定未来的空间需求是什么。在致力于寻找漏洞自动化工具(主要是起毛),我们看到需要分配每年10 ^ 5或更多的IDs与线性增长的潜力增加更多的起毛机。但我不认为CVE id分配给每一个人崩溃报告。 If we do expect significant growth (which would mean drastically changing the nature of a CVE entry, or greatly increasing throughput and coverage), then we need to go with arbitrary scale, options #1 or #7. > 5) Delayed impact of the syntax change - since any change will have > many unexpected effects on downstream consumers, we want to give > people as much time to adjust to the new syntax as possible. So, > it may be favorable to use a syntax that doesn't appear to change > until 10,000 identifiers are needed. Could encourage people to do nothing then scramble when -9845 is published in March. > 6) Syntax version recognition - if possible, it should be clear to the > consumer or an automated system as to which syntax version is being > used for an ID - the old syntax, or the new syntax. For example, > ISBN numbers were originally 10 digits long, then expanded to 13 > digits - so the length of the ISBN clarifies which version is being > used. I like this idea, but is it necessary? Conflicts somewhat with #5. I don't well understand the costs of changing software to account for the new syntax, so consider that when weighing my feedback. (That is, I don't know how many vendors have how many products that require how many lines of code to be changed. CERT just has a couple scripts and web pages to worry about.) So, I'm somewhat biased to pick a syntax that favors functionality and longevity over ease of implementation. I'm not too worried about the impact of immediate change. That could be shortsighted. What's easier? A longer ID with only digits, or a 4 character alpha-numeric ID? If compatibility with the current syntax is important, then I like option #1. I don't think alpha sorting is that important. Can't I sort results by the Assigned date? > Option 1: Year + arbitrary digits, no leading 0's > ------------------------------------------------- > > Examples: CVE-2013-1234, CVE-2013-12345 (if 4 digits or less, leading > 0's would be used, e.g. CVE-2013-0056 instead of CVE-2013-56) Mildly in favor, good for backwards compatibility. > Option 2: Year + 5 digits, leading 0's > -------------------------------------- > > Examples: CVE-2013-01234, CVE-2013-56789 > Option 3: Year + 6 digits, leading 0's > -------------------------------------- > > Example: CVE-2013-012345, CVE-2013-678901 Neutral. Distinct from old syntax, prefer option #3 for space reasons. > Option 4: Non-standard year + 4 digits > -------------------------------------- Strongly against, keep the year meaningful. > Option 5: year + 4 hex digits > ----------------------------- > > Example: CVE-2013-A9E4 > Option 6: year + 4 alphanumeric > ------------------------------- > > Example: CVE-2013-ZW1K Neutral, prefer 6 over 5 since it has more space. > Option 7: CCE-Style (year + arbitrary digits + check digit) > ----------------------------------------------------------- > > Example: CVE-2013-12345-6 (the "6" is a check digit, following the > Luhn Check Digit Algorithm) Mildly in favor, check digit might be a bit of over-engineering, effectively unlimited space. Does it make sense to retro-fit so that until the 10K mark, the check digit is optional and leading zeros are used? > Option 8: CERT-VU/JVN Style > --------------------------- > > Example: CVE#12345678 Strongly against. This is not necessary for CVE and too radical a change. A major design goal of this syntax was to not leak timing information (like the year and sequential IDs) for pre-disclosure vulnerability tracking. - Art