RE: [CD] CD Proposal: VOTE (Voting Requirements)

["Steven M. Christey" <coley@linus.mitre.org>]

Andre Frech said:

>> 5) If a voting member casts a REVIEWING vote, then the Editor may
>>    delay an Interim or Final Decision for at least 2 weeks after the
>>    vote was cast.
>
>Fine, as long as there is a REVIEWING WITHOUT DELAY voting option that
>indicates to everyone that the issue is being reviewed by the voting
>member, but should not be delayed in the approvai process.

The voting web site includes this option.  In the meantime, "nodelay"
REVIEWING's can be noted as a comment.

>> 7) If a voting member votes on a candidate for a security problem
>>    found in a product owned by a competing organization, then that
>>    member's vote cannot be counted towards the Quorum, unless the
>>    competing organization has publicly acknowledged the problem.

>Does this include the inferred vote that occurs when a competing
>organization casts a MODIFY vote?

I would say that it does, because a MODIFY is treated as an "ACCEPT
with small modifications."

>Also, how is a competing organization defined? Is it compartmentalized
>by vendors, academic, and government, or perhaps IDS, VA, and other
>security products?

Good question.  I originally thought that it should be separated by
the type of product.  So a vendor who doesn't make a vulnerability
assessment tool could vote on an IDS problem.  But the two vendors
could have competing IDSes...  So I'm not sure.  Perhaps it should be
left up to the Board member to define who their competitors are.

>On a similar issue, would a MODIFY followed by a reference citation
>into a voting member's database constitute a public acknowledgement of
>the problem? I think I know the answer to this question, but I would
>like to see it articulated for the record.

If you're asking: "if my competitor acknowledges the problem, but that
information isn't included in the candidate, and the competitor hasn't
voted, can I still vote for it?"  I'd say yes, if some public record
can reliably indicate that the competitor has acknowledged the
problem.  I'm not fully sure I understood the question...

>> 3) A voting member should vote on candidates according to approved
>>    content decisions, instead of their own personal preferences.

>Would it be appropriate to add a "no supporting documentation" clause
>to this list?
>
>It's not good form to prevent a voting member from casting a REJECT
>just because CVE claims that an issue exists without external support.


Lack of supporting documentation gets a little fuzzy in the area of
certain configuration problems, but I'd say that if a stated problem
has no supporting documentation, it could be REJECTed.  This could
also apply if the Board member doesn't trust the documentation.  There
are some older candidates, as you've observed, that have no supporting
documentation.  I have slated them for rejection because of this.

There's a little bit of a slippery slope here.  Some people have voted
to REJECT a problem that is confirmed to exist, but has no details
whatsoever.  For example, some vendors release advisories without any
details, and just say "there's a problem in this piece of software,
apply these patches."  An as-yet-unnamed content decision will
eventually be proposed to handle these cases in which there is vendor
acknowledgement but little "supporting documentation" per se.

>> 4) A voting member should not vote for a candidate that is related to
>>    a security problem in a competitor's product, unless the competitor
>>    has acknowledged that the problem exists.
>
>Again, would a MODIFY followed by a reference citation suffice as
>acknowledgement?

I'll try an alternate take on your question in the hopes that I'll
eventually hit the right one.  If a Board member votes to ACCEPT or
MODIFY a candidate related to their own product, then that's vendor
acknowledgement.

- Steve