RE: 2 CVE's to be rejected

["Christey, Steven M." <coley () mitre org>]

> > [cve-assign@mitre]
> > We would want this information even if the correct CVE ID still
> > refers to an embargoed issue.
>
> [Kurt]
> The duplicate issue is still embargoed, the other one is also an
> embargoed issue. 

To be (hopefully) more clear, we do not need to "populate" the CVE description or references for the (still-valid) 
embargoed issue; we only want to refer to its ID from the REJECTed CVE.  That way, if for any reason the REJECTed CVE 
is used in public, there will be a clear link to the appropriate CVE.  We don't feel that the reference to the 
still-embargoed issue is an information leak of any sort, given that Red Hat is likely to be working on dozens of 
not-yet-disclosed vulnerabilities at any point in time, and you've already publicly stated that CVE-2013-1870 (or 
CVE-2013-4398?) is a dupe of *something*.

While it's unusual to do a REJECT of one CVE and say that it's a duplicate of another CVE that's still not public and 
still shows up as RESERVED, this action still gives useful information to certain CVE consumers who rely on the CVE IDs 
to coordinate vulnerability information between diverse parties (which is, after all, CVE's primary goal).

Similarly, while it's unusual to publicly claim a REJECT of one CVE because it's not a security issue, in the past we 
have supported various "private" REJECTs that occur when the original CVE requester determines that the issue is just a 
"bug" (or "feature") and not a vulnerability before the issue was ever published.  It doesn't seem like much of an 
information leak to know *that* a particular CVE ID was REJECTed because further research showed that the issue was not 
a vulnerability.

As such, it doesn't seem like there would be any loss of privacy/secrecy if we knew which of (CVE-2013-1870 or 
CVE-2013-4398) was a duplicate [of some other CVE, whose ID would be nice to know even if the issue isn't public yet], 
and which of (CVE-2013-1870 or CVE-2013-4398) should be REJECTed because it's not a CVE-qualifying vulnerability at all.

I recognize that we might not have sufficient insight into the situation at hand, so any clarification would be welcome.

- Steve