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

Re: CVE ID Syntax Change - Voting Ballot INFO#679180


  • To: <cve-id-change@mitre.org>
  • Subject: Re: CVE ID Syntax Change - Voting Ballot INFO#679180
  • From: Art Manion <amanion@cert.org>
  • Date: Tue, 9 Apr 2013 08:44:39 -0400
  • CC: <cve-editorial-board-list@LISTS.MITRE.ORG>, CERT <cert@cert.org>
  • Delivery-Date: Tue Apr 9 08:44:43 2013
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org;s=jthatj15xw2j; t=1365511476;bh=FGZ/Se8+hT9DSsBjuGh6bz2wCablcwuj8ktkHhs3zD8=;h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding:Sender: Reply-To;b=bRP/fOzj/3m35gNcwwa4/KDZP9l7mX6OBOOpdWeC2LdmZs8OaFxwZVGW7MsR6ZQpj VBtgTfoxF2ZvojBm+n5Hqx0ODYAiUp6hyUGwWJjTrlP+/3Xqr2iar1VVgBZ7TcJHrD ygO4id0FN6WiOgF579AzSLc5cyKY9cvZ7w0uNMXc=
  • In-Reply-To: <201304012058.r31KwmHo024900@faron.mitre.org>
  • References: <201304012058.r31KwmHo024900@faron.mitre.org>
  • User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-04-01 16:58, cve-id-change@mitre.org wrote:

Voting for CERT/CC:

| FIRST CHOICE:

OPTION B: Year + arbitrary digits, no leading 0's except IDs 1 to 999

| REASONS (first choice):

Flexible, option B could actually support the other two options (with
the minor exception of the leading zeros in option A. With no
expectation of significant near-term change in CVE operation (other
than the CVE10K problem, which is solved by all three options), our
initial first choice was option A, just increasing the space using the
current syntax. Trying to look ahead, it seems possible that significant
growth in the number of CNAs or the number of reservations (whether or
not the IDs are ever actually assigned, the reservation alone will
consume IDs) could approach the limits of option A. Additional benefit
that there is no effective change in format until IDs > 10K are reserved
or assigned.

| SECOND CHOICE:

OPTION C: Year + arbitrary digits + check digit

Check digit is unnecessary, CVE ID operations are most often string
matching (searching), there's no strong reason to differentiate between
a failed match and an invalid (failed check) ID.  If desired in the
future, could be implemented within option B's format.

| REASONS (second choice):

| LAST CHOICE:

OPTION A: Year + 6 digits, with leading 0's

| REASONS (last choice):

Was initially our first choice, seeing no near-term change in CVE
coverage scope or abstraction.  However due to the (even small)
possibility of expanded reservations (see above), we're concerned about
the space limit (the CVE1M problem).

Additional comments:

We strongly suggest that code designed to handle CVE IDs treat
everything after "CVE" as a string, or at least everything after
"CVE-YYYY" as a string.


Regards,

~  - Art


~             Art Manion  --  CERT Coordination Center
~    <http://www.cert.org/>   <cert@cert.org>   +1 412-268-7090
~        2F15 E075 20A3 7B3D 88FE  7C1B 93FF 0510 36C2 68A3



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFkDTUACgkQk/8FEDbCaKMy/ACguCS2j+kQx+dmoQi6ExN0vI1c
PrgAnA/7YSca9ezLJdRNu6k69erWLYDw
=A1p+
-----END PGP SIGNATURE-----


 
Page Last Updated: June 26, 2013