Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 10 Feb 2017 22:59:27 -0500
From: <>
To: <>
CC: <>
Subject: Re: MITRE is adding data intake to its CVE ID process

Hash: SHA256


Thanks to all who have provided constructive and meaningful feedback
on this change up to this point. This reply will hopefully answer all
of the concerns so far. We are hearing 11 distinct concerns, listed
below as C1 through C11, along with our responses of R1 through R11.
If you have any ideas or suggestions for improvements to the CVE web
form, we are completely open to this.

C1. What exactly has changed after MITRE's 2017-02-09 announcement?

R1. There are two changes. Each of the two changes is about the case
where an oss-security participant is immediately ready to make a
public disclosure, and wants an accompanying CVE ID. First, the person
must visit to make the CVE request (but can
also send the vulnerability information to oss-security at the same
time). Second, we would like a vulnerability description (i.e., a
sentence or two about the product name, affected versions, problem
type, impact, and attack methodology) so that we can publish the CVE
on much more quickly. We recognize that, in a
fraction of the cases (e.g., unanalyzed fuzzer results), a description
would have very limited information.

C2. Can I still obtain a CVE ID if I'm not yet willing to disclose
what the vulnerability is, and cannot offer any public reference URL?

R2. Yes, simply visit and leave the
"Reference(s)" box blank. Alternatively, you can enter a reference
URL, and use the "Additional information" box to clarify that neither
the reference nor the CVE should be public yet. This is not a change
to how the oss-security list has be used. The oss-security list has
always been about only public vulnerabilities.

C3. MITRE currently has documentation such as that recommends contacting
DWF if an Open Source product does not appear on a certain list.

R3. In all cases where our documentation suggests contacting DWF,
please use instead at this time. DWF is
currently ramping up their operations. CVE is covering all Open Source
software. There is no list that is excluding anything.

C4. I have historically obtained CVE IDs from the CNA of a specific
Linux distribution (e.g., Debian, Ubuntu, or Red Hat) and they are
still willing to provide CVE IDs to me. May I continue?

R4. Yes.

C5. I want MITRE to send the form data, and
the CVE ID, to the oss-security list at the same time that these are
sent to the requester.

R5. We have had internal discussions within MITRE about this. We are
able to implement this easily if the community requires this approach.
At the moment, we are expecting the requester to resend this
information to oss-security once they accept their CVE ID assignment.
Please see
for an example.

C6. I want MITRE to send the form data to
the oss-security list as soon as that data is entered (i.e., before a
CVE ID exists).

R6. We have had internal discussions within MITRE about this. We are
not yet able to implement this easily. We may work on this if the
community requires this approach. However, our understanding of CVE
consumers is that they look to MITRE as a source of vulnerability
information after a CVE ID number exists, not before.

C7. When using the site, it is unclear what
a "vendor" is, e.g., must it be the name of a Linux distribution?

R7. The vendor is the name of the upstream project or organization
that maintains the Open Source software. If there isn't any project
name or organization name, then the name of the software can be used
as the vendor name.

C8. A CAPTCHA makes it difficult to do high-volume vulnerability

R8. We agree. The use case is persons with
low-volume reporting needs. We will announce other solutions for
high-volume reporting. You can contact us, using the "request type: Other" option, if you need a
high-volume workaround now.

C9. I want to obtain CVE IDs faster in the future. Is there a plan for

R9. Yes, we anticipate that, in the future, hundreds of Open Source
projects will become CNAs for their own vulnerabilities. This will be
coordinated under DWF. In other words, an individual Open Source
project will have a "sub-CNA" role. The initial documentation is on
web page.

C10. I do not want to use Google docs. Is there any other option?

R10. First, Google docs is applicable only to DWF, which is currently
ramping up their operations, and is not a required entity for any CVE
ID requests at present. Also, we do not expect that Google docs will
be applicable to persons or organizations with a higher level of DWF
participation, such as sub-CNA participation. At the higher levels,
DWF currently uses GitHub, not Google docs.

C11. The X.509 certificate chain is

R11. Yes, we realize this and will be adding the missing item (Entrust
Certification Authority - L1K) soon.


- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.