Re: Very Important Message for the Editorial Board

["Landfield, Kent B" <kent.b.landfield@intel.com>]

I agree with Kurt here.  100%

This breaks just about everything.  When I have mentioned federated CVE 
support I was imaging the Board, I and others that have operational 
responsibility for using and distributing CVEs would have some say in 
what it looked like. I fully understand you are under pressure but this 
is not the right way to do this.  I really would have liked this to be 
one of the topics we discussed at the CVE Improvement Summit instead of 
having this hoisted on us this way. It would be in the best interest to 
hold off in my mind since these Ids have NO usefulness in product and 
this will totally confuse the market, researcher and those with 
operational needs for a consistent CVE.

This really needs to be discussed before you make the problem worse…
---
Kent Landfield
+1.817.637.8026

From: 
<owner-cve-editorial-board-list@lists.mitre.org<mailto:owner-cve-editorial-board-list@lists.mitre.org>>
 on behalf of Kurt Seifried 
<kseifried@redhat.com<mailto:kseifried@redhat.com>>
Date: Thursday, March 17, 2016 at 4:26 PM
To: "Sain, Joe" <jas@mitre.org<mailto:jas@mitre.org>>
Cc: cve-editorial-board-list 
<cve-editorial-board-list@lists.mitre.org<mailto:cve-editorial-board-list@lists.mitre.org>>
Subject: Re: Very Important Message for the Editorial Board


The new, rapid-response federated ID scheme has been carefully designed 
so that it does not disrupt existing processes and their attendant use 
cases, and allows for future compatibility with existing CVE 
identifiers. Federated CVE Identifiers will allow for rapid 
experimentation with new types of assignments and use cases so that 
CVE, the CVE Editorial Board, and the community can work together to 
determine what best serves the needs of the community.

Who will be issuing these? Have any been assigned/announced?


The federated ID syntax will be CVE-CCCIII-YYYY-NNNN…N, where “CCC” 
encodes the issuing authority’s

Oh dear. So this breaks every piece of CVE tooling/software currently 
in existence. Before the industry collectively puts a few tens/hundreds 
of thousands of hours of work and quite a lot of money into supporting 
this is there any guarantee from Mitre that this is a long term 
project? There is no mention of how widespread or long this pilot 
project is going to go for. Can you please provide concrete details?

country and “III” encodes the issuing authority. At its launch, MITRE 
will be the only issuing authority, but we expect to quickly add others 
to address the needs of the research and discloser communities, as well 
as the cybersecurity community as a whole. This new federated ID system 
will significantly enhance the early stage vulnerability mitigation 
coordination, and reduce the time lapse between request and issuance.

MITRE is continuing to refine CVE operational capabilities so that 
automated vulnerability identification, description, and processing are 
incorporated over time. As both the Federated Pilot and the next phase 
of CVE operational capabilities are scaled and automated, traditional 
CVEs can be merged with federated CVEs.

Are there any specific goals/timeframes here? We're still waiting for 
an ETA on a possible solution for the robots.txt on the CVE web site 
(http://cve.mitre.org/robots.txt) that blocks all indexing of the CVE 
content on the web site.


The CVE Team looks forward to working with members of the CVE Editorial 
Board and the broader community to rapidly expand CVE coverage and 
implement the federated CVE identification scheme, so that the CVE 
capability keeps pace with the increasing demand for well-recognized 
vulnerability identifiers.

I'm a bit worried as the board was never consulted on this as far as I 
know (no emails, nothing mentioned in the phone call I had). Can anyone 
on the board confirm that they suggested this/supported this strategy 
by Mitre?


--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
secalert@redhat.com<mailto:secalert@redhat.com>