[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65b06dc7fec741e9a6d301142f20705d@imshyb01.MITRE.ORG>
Date: Fri, 17 Feb 2017 12:25:17 -0500
From: <cve-assign@...re.org>
To: <oss-security@...ts.openwall.com>
CC: <cve-assign@...re.org>
Subject: Re: MITRE is adding data intake to its CVE ID process
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> C11. The https://cveform.mitre.org X.509 certificate chain is
> incomplete.
>
> R11. Yes, we realize this and will be adding the missing item (Entrust
> Certification Authority - L1K) soon.
Our current maintenance schedule for resolving this is 2017-02-21 at
2300 to 2359 UTC.
> C5. I want MITRE to send the https://cveform.mitre.org 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.
We apologize for the delayed response on this topic. The CVE Team has
been considering deeper details of how this could be implemented. The
advantage is that oss-security readers would obtain vulnerability
details faster. The main disadvantage is that it would discourage some
people from ever making CVE requests with public vulnerability
information, and thus might make the overall information flow worse.
The reasons it could discourage people include:
- At the time of their CVE request, they have a rough draft that
proves that a CVE should exist, but they haven't edited it for
full technical accuracy and/or spelling/grammar. They do not want
unedited text to be publicly attached to their name.
- People sometimes rely on their request remaining non-public, and
provide a great variety of information to us when requesting a CVE
ID for an already-disclosed vulnerability. They would need to
spend extra time on redactions, or MITRE would need to allocate
staff time to assess what part of the request seems non-public,
and redact it before making the oss-security post. Examples
include: (A) some people provide their work email address that
they don't ever use on public mailing lists, (B) some people
forward email threads with personal email addresses of the
vendor's PSIRT staff who responded to them, (C) some people
include non-public credentials for a demo site or a download of an
unreleased build with an experimental fix, (D) some people refer
to embargoed vulnerabilities when clarifying that they have a new
request that is different from related embargoed vulnerabilities.
In general, there's a common case (the requester only provides a
basic technical outline of the vulnerability and the commit URL)
where implementation is easy. There are several corner cases where
implementation is hard. The simple solution is to always ask the
requester to make their own (correctly threaded) oss-security post
that contains any or all of the response from MITRE. Until we have a
better understanding of why that simple solution is incorrect, we are
continuing to go with that simple solution. Thus far, every
https://cveform.mitre.org user (who we recognize as being an
oss-security participant) has made their own subsequent oss-security
post with at least the CVE ID. In other words, we haven't noticed a
problem at this point. We will continue to monitor open-source requests
for this situation and may reconsider this position if the problem
presents itself.
One final note: if the person declines to make their own oss-security
post, this does NOT mean that the vulnerability becomes impossible to
find. The CVE Team does publish entries on https://cve.mitre.org for
these public vulnerabilities, and this may happen very quickly when
the requester writes the description.
- --
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJYpy7yAAoJEHb/MwWLVhi2ol4QAJvLHwhli8Xn4Ib9QfHbD+GN
xCtdhEaJ7hjt6iHWIxgS/k1kTQN0HLPH8z3ubvN9Uc1dW0UYuaVphxaXJ1vXuVqJ
/YKrUPw7WdIVWPSPfhLnmisBAI9+8YNhffRP8QAe8FyFSAyDCPYRzpJNo3kpP7s8
/JO2eJFgB9zVbIfNYGtshdEL/F34UDLbldfC3ihOmFCnGeMpp3+xm/ZJo/XjX6Yv
k9P9vZEbl3meylrn1UW9314aSDt7kydcNsP6UvtH9mmXKn4ROtKW3+FmyuUX1G4L
NXkvHCqOVnL3ht0n1ZcTxvCCOACMjYF3WJDgvTJMU7af+sW7KE9FwhCwnVtIJXcd
Z3xaVOlIsVwkHjntS2+6L0YWeG6fRO9diiNmRajmn5DUbyAShNwtW+zauaA7CrqZ
meClRv+ndXBjbK2x4n15wJ6ml5R93E3Iq3HdlSf27zS9lNAHLxvq1cQF0WcDMAoG
SZX0+lVCQtAMXiNJG5AMIY5y933n29Q1h/mVqoml2jwNpq7vlyIeunGAkZ4jzchD
eRci0wcVboVRp4pMmbT0mvt6pFwStypyFchm/bv+JN1f0o/F0YZegA4rZ6vwtyN6
NVxa70Sg+gjVx12YIgtwBDaq2Lpfaijcsqf+5kL74XJrCO3lChoQeirmELRzK4gH
4Jxus+DnasYSrVlsJ9Wq
=VpXe
-----END PGP SIGNATURE-----
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.
