Sounds fine to me, although the notation could be lighter, i.e., it could
be understood that if a CVE entry has a list at the end like:
1. Digital Unix 3.0x, 3.2x, 4.0, 4.0a and products based on these
2. FreeBSD v prior to 2.1.6
3. HPUX 9.x, 10.00-10.20,
4. AIX 3.2, 4.1, 4.2
then referring to CVE-1999-0128.3 means the vulnerability instance of
CVE-1999-0128 in
HPUX 9.x, 10.00-10.20.
Pascal
>Allow us to suggest an idea that we've been kicking around
>here at MITRE for a few weeks. I alluded to this idea with
>my analogy a week or so ago to the card catalog in the library.
>Recall, the observation there was that card catalogs operate
>at (at least) 2 levels of abstraction in terms of enumeration.
>For example, the card catalog may have a dozen cards with the
>title "Moby Dick". But, each card may represent a different edition.
>We might call the levels of abstraction "Same Title" and
>"Same Edition".
>
>Our suggestion for resolving the "Same Attack" vs "Same Codebase"
>issue (and other issues related to level of abstraction) is to move
>to a 2 tiered naming scheme. We suggest reserving the now
>standard CVE nomenclature for vulnerabilities that are essentially
>the same at the same attack (or some equivalent level of abstraction).
>This nomenclature could then be extended to cover each particular
>instance of the base vulnerability by appending a new number with a dot.