Re: CVE ID Syntax Vote - results and next steps

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

Thanks Steve, 

That is the most significant change to my perception of the issue.  I think
it's to be expected that transition strategies will have an effect on format
votes, with the harshest transitions increasing votes for less disruptive
("selfish") options.  Not specifying them makes people consider the ones they
fear most.  

Making the transition in 2015 instead of 2014, if realistic, could make option
A more acceptable to organizations with large investments. An ugly but
functional "plan B" would be to start allocating 2015 IDs in the new format if
we run out of IDs in 2014. In my mind that's no more ugly than starting to
count at 1000 and influencing the choice of format for the sake of a smoother
transition, and there's a chance it won't be needed.

Given all this and the list of desired properties, I'd lean towards option A or
variants with leading zeros instead of option B, for which I voted.  Increasing
numbers of numeric characters chase vanishing decreases in risk, in exchange
for a constant increase in cost that is paid by all.  In the absence of
retroactive applications, I don't think format changes need to be such a
concern, as long as they don't happen too frequently.  Option A has an
acceptable risk.  Option D (7 characters, as named by Art) should make the most
risk averse, comfortable. 

Pascal

On Fri, 19 Apr 2013 09:58:53 -0400
"Christey, Steven M." <coley@mitre.org> wrote:

> Pascal, regardless of the new option, we did not plan to renumber any of the
> old IDs - that would be too disruptive.  So the expectation is that will be a
> "syntax version 1.0" (for 2013 and earlier) and a "syntax 2.0" (for 2014 and
> later).  This topic was not covered too deeply, however, as we had planned to
> cover transition strategies in more detail AFTER selection of an option. 
> 
> - Steve
> 
> 
> >-----Original Message-----
> >From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-
> >editorial-board-list@lists.mitre.org] On Behalf Of Pascal Meunier
> >Sent: Friday, April 19, 2013 12:17 AM
> >To: Booth, Harold
> >Cc: cve-editorial-board-list
> >Subject: Re: CVE ID Syntax Vote - results and next steps
> >
> >That assumes that already issued CVEs would not be revised to conform to
> >the
> >new format.  My understanding of the proposals so far is that as soon as a
> >new
> >option will be adopted, all previously issued CVEs would be changed to the
> >new
> >format.
> >
> >On Thu, 18 Apr 2013 22:34:07 -0400
> >"Booth, Harold" <harold.booth@nist.gov> wrote:
> >
> >> I would also add that with an Option B with no leading zeros, including
> >> less than four digits, a transition of sorts is available for the first
> >> year (or more) if CVE identifiers started at 1000. Until the 9000'th CVE
> >> tools would successfully chug along giving everyone a bit more transition
> >> time. This could allow even more time depending on the eventual number of
> >> CVEs
> >created.
> >> Whereas with an Option A with padding there is no such transition, and
> >> whatever number of digits are agreed to are included in every CVE from the
> >> beginning (in 2014?).
> >>
> >> Regards,
> >>
> >> -Harold
> >>
> >> -----Original Message-----
> >> From: owner-cve-editorial-board-list@lists.mitre.org
> >> [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of
> >> security curmudgeon Sent: Thursday, April 18, 2013 6:05 PM To:
> >> Kent_Landfield@McAfee.com Cc: cve-editorial-board-list@lists.mitre.org
> >> Subject: Re: CVE ID Syntax Vote - results and next steps
> >> Importance: High
> >>
> >> On Thu, 18 Apr 2013, Kent_Landfield@McAfee.com wrote:
> >>
> >> : Agreed.
> >> :
> >> : I could see changing my vote to A if the number of digits were extended.
> >> : I responded that I believed Harold was on target with his idea to
> >> : reevaluate Option A.
> >>
> >> As mentioned, this is fine with me. I was not voting for the # of digits in
> >> A. I was voting for the standard method it used in displaying it.
> >>
> >> Optionally, if Option B was redone to remove ALL trailing zeros, that too
> >> would be fine with me, as it would then bear a standard display format (of
> >> sorts).
> >>
> >> : Harold wrote:
> >> :
> >> : I agree that a revote using the same options would probably result in
> >> : more or less the same result. But after reviewing the reasoning for
> >> : voting, those that voted for Option B were mostly concerned with
> >> : avoiding the need to change again ("future proofing") while those who
> >> : voted for Option A seemed to be mostly concerned with the variable
> >>
> >> If both were changed as mentioned above, where A was 7 digits intead of 6,
> >> and B had no leading zeros at all. I am really curious how people would
> >> vote.
> >>
> >> : Using his logic, we could make it 10+ digits and not pad it with leading
> >> : zeros.  Then it would be capped at a static length but we would only
> >> : have to use what we need.  It could grow as needed and we would have
> >the
> >> : future proofing that is a major reason stated by those who voted for
> >> : Options B.  The end user would see a CVE ID that is reasonable from a
> >> : readability perspective, software would have a static length that we can
> >> : grow into. An approach like this could potentially go a long way to
> >> : getting to a consensus majority.
> >> :
> >> : Thoughts?
> >>
> >> Overall I like it. We're addressing the problems with the proposed
> >> solutions, and building on them, rather than coming up with additional.
> >>
> >> It would be great if every member would weigh in on the above, not as an
> >> official vote, but just to see if either has more benefit, or to add other
> >> options and ideas.
> >>
>