Re: CVE ID Syntax Vote - results and next steps

["Andy Balinsky (balinsky)" <balinsky@cisco.com>]

I think the arbitrary length issue is also a concern for parsing CVE's from an email or web page, where they may just be inline text, without null-terminations.

Andy

On Apr 26, 2013, at 9:10 AM, Booth, Harold wrote:

> -----Original Message-----
> From: Art Manion [mailto:amanion@cert.org] 
> Sent: Friday, April 26, 2013 4:30 AM
> To: Booth, Harold
> Cc: cve-editorial-board-list
> Subject: Re: CVE ID Syntax Vote - results and next steps
> 
> On 2013-04-25 04:17, Booth, Harold wrote:
> 
>>>  * Do you desire a static length of the CVE Ids?
>>> 
>>> Yes, a specified maximum length is much easier to write parsing and 
>>> validation logic for and at the end of the day everyone will have to 
>>> decide on some sort of cut-off.
> 
>> I'm not expressing a preference, but is a null-terminated string any harder to parse?  'CVE-' or 'CVE-YYYY-' or 'CVE' is
>> the start of the string, read until the end, you now have your ID.
> 
> [HB] Nope, not harder to parse, but do you really want to have an input into your application where someone can give you an unlimited length string? Everyone will need to determine some maximum length that they will be willing to except for any given input or suffer the consequences when someone exploits the fact you are not checking your inputs.
> 
>>> - Any comment on Adam's suggestion of trailing zeros?
>>> 
>>> It is ambiguous for numbers divisible by ten, for example imagine if 
>>> CVE today had trailing instead of leading zeros and we had the following number:
>>> 
>>> 1000
>>> 
>>> Is this a 1 with three trailing zeros? A 10 with two trailing zeros? A
>>> 100 with one trailing zero? or 1000 with no trailing zeros?
> 
>> Seems pretty clear it's 1000 (one thousand) with no trailing zeros, positional notation and all, if the ID is a number leading zeros are decoration only, >trailing zeros matter.
> 
> [HB] Absent some other clarification, no, it's not clear what it is if all numbers have zeros added to the end of the string to make them the same number of digits. And given that this suggestion has been withdrawn I'm not sure it's worth discussing any more anyway.
> 
>> And, treat the ID as a string!  Even a string that you can safely expect to be digits, like this regex I looked up on stackoverflow: ^[0-9]{1,6}$
> 
> [HB] I think one should always perform input validation on strings if the input format is known a priori. At the risk of going down a rabbit hole, while I think identifiers for machine consumption should largely be treated as opaque strings with no semantic meaning embedded within them, there is often embedded meaning in identifiers that are used by humans. Dewey decimal system, phone numbers, VINs, and credit card numbers are examples where an identifier can be largely be treated as an opaque string, but embedded in the identifier there is some meaning (limited) that can be derived if one wants to process that meaning. There are reasons why they have this meaning in them and I think it would be a mistake to not be aware of why they ended up the way they are.
> 
> 
>> If IDs are variable length strings and there are no special formatting rules, then CVE-1999-00100 and CVE-1999-0100 are different...
> 
> [HB] This would be horrible. Based on this example, I am amending my previous statement that I have no strong opinions regarding padding. I think the padding rules must be consistent. If the two example IDs Art provides above are to be treated differently, that would be horribly confusing and lead to all kinds of errors. And to echo Andy and Steve's comments, regardless of eventual format rules, I think tools should allow human users as much flexibility as possible when they attempt to use a CVE.
> 
>> I guess there's a desire to keep the ID an integer, issued more or less sequentially?  This isn't really related to the syntax
>> change, unless treating the ID as a string affects the leading/trailing zeros
> 
> [HB] I think it matters that we all agree on a format for the identifier. How the identifiers are assigned to vulnerabilities and in what manner can largely be a separate question as long the agreed upon format does not hinder alternate models of assignment in the future. And that last point I think is where there is likely some disagreement.
> 
> 
>> - Art