Re: CVE: intellectual property/branding
Stuart Staniford-Chen asked:
>I'm interested in issues that would get in the way of the IETF saying
>in an RFC that the n'th field in an IDEF alert is a CVE number.
>what intellectual property rights does Mitre plan to assert in the
>content of the CVE?
The CVE will be copywritten but will allow unlimited distribution, but
the copyright statement will prevent its modification. This will
allow anybody to download the entire CVE, and in fact the downloads
page on the web site allows just that. But the copyright will be
worded to prevent someone from making changes to the CVE itself,
e.g. changing CVE-1999-0003 to be their favorite vulnerability,
instead of rpc.ttdbserverd. I don't know the details of the GNU
public license, but it will probably be something along those lines.
Full public distribution is a requirement of an acceptable common
The fact that the entire CVE can be freely downloaded, where
vulnerability databases are not, could make it appear that the CVE is
in "competition" with those other resources, or a replacement for
them. However, as long as we make certain that there is minimal
overlap between the CVE and any vulnerability database, then the CVE
could not effectively "compete" with vulnerability databases; nor is
it designed to. The CVE has to remain neutral in that regard,
especially since it's designed to link between vulnerability
databases, not to replace them. I believe that Editorial Board
members understand this, but every design decision we make with
respect to the CVE has to consider these implications, especially in
CMEX. And the CVE often appears to be a vulnerability database to
someone who's not familiar with it. The web site's FAQ and front page
make this distinction clear, but it may not register with the average
I would prefer that we also provide CMEX (or a portion) due to its
benefit (especially references), but that is a debate I've scheduled
for sometime in August. There were some initial concerns at the SANS
meeting that may not have been fully addressed yet.
>More nebulously, there's the issue of branding. At the moment, it
>looks to me that Mitre is definitely positioning this as "The Mitre
>CVE" with the Mitre brand strongly linked to it.
Since the CVE's inception, we have had a number of internal shifts in
how we refer to the CVE. In the paper that Dave Mann and I presented
at the CERIAS workshop, we discussed the possibility of multiple
CVE's, and we would often talk about "a CVE" in a generic sense. When
we started actually creating a CVE, we began referring to it as "the
MITRE CVE" to distinguish MITRE's work from other possible CVE's.
However, we believe that "the CVE" and "the MITRE CVE" have now become
interchangeable and synonymous. So we're moving to "the CVE" both
because there's only one CVE, and it re-emphasizes the fact that the
CVE is the result of a community effort, not just MITRE's. Note that
this most recent change in terminology was decided by the president of
>A possible route of evolution for the CVE would be for it to be
>published periodically as an RFC. Steve and other Mitre folks are
>still the authors, but it becomes a standards track document.
There are a number of long-term possibilities, this being one of them.
MITRE will choose the long-term strategy that best serves the public
I am trying to arrange for senior management to talk to the attendees
at the CVE Review meeting in August. There have been a number of
high-level questions that require answers from my management.
Certainly I can't answer for the company in some of these areas, but
the CVE does have support across the board, including MITRE's
president. They will be able to address your larger concerns.