Joint
CRT and STS Teleconference
Thursday, June 14, 2007
11:00 a.m. EDT
Draft Meeting Minutes
Draft
Agenda:
1) Administrative
updates (Eustis)
2) Issues received from TGDC members and the public (continued). See
the files under "CRT VVSG finalization working materials:"
at http://vote.nist.gov/TGDC/crt/index.html
(Flater)
3) Any other items
Attendees:
Alan Goldfine, Alicia Clay, Allan Eustis, Angela Orbaugh, Bill Burr, David
Flater, David Wagner, John Wack, Jon Crickenberger (NVLAP), Michael Koo,
Nelson Hastings, Paul Miller, Philip Pearce, Ron Rivest, Thelma Allen,
Wendy Havens, Rene Peralta
No Administrative
Items.
CRT Issues
(David Flater)
The issues
log being maintained by CRT contains over 273 issues, with 27 remaining
open as of today. Many of the open items are regarding terminology waiting
on feedback from Paul Miller. In order to make the deadline for final
draft, the open issues need to be closed by Friday, June 15.
- Issue
# 6: Benchmarking Test Methods Look Wrong (Ron Rivest): There has been
extensive email regarding this issue and will continue to try and resolve
this via email. This has been re-written extensively in the language
of classical hypothesis testing. This has hopefully been clarified per
Ron's issues.
- Issue
# 21: Threads and Memory Leaks (Ron Rivest): Should the following be
mentioned somewhere: "memory leaks" (memory allocations that
are never "freed") and "threads" (concurrent programming
techniques). Response: Memory leaks are addressed in III.16.4.1.8, though
not to the extent of proving their absence. Threads are not addressed.
Suggestion is to ban multi-threaded voting application logic, but this
could be controversial. It's common to have separate threads in gooey
applications. There are ways to deal with multithreads in a structured
way. The requirement should state that if a voting application's logic
is multi threaded, the vendor be required to provide demonstration that
it will not effect other programs or become deadlocked. David Flater
to add language.
- Issue
# 20: Ballots for opscan volume testing (David Wagner): Is it OK to
substitute mechanically marked ballots for manually marked ballots during
test. The proposed requirement states that it is not valid to substitute
with mechanically marked ballots if the vendor specifies that the system
is designed to count manually marked ballots. The 2nd issue was in order
to reach the number of ballots needed to run the volume test, is it
ok to recycle ballots during the test. The proposed requirement states
that there must be at least 10,000 manually marked ballots to run through
the test and after that you can recycle that 10,000 to get the number
needed for volume testing. David W likes resolution proposed.
- Issue
# 1: Terminology: Partisan contest to become party specific contest;
non-partisan contest to become non-party specific contest; after discussion
David F. will work to clarify the definition for primary election; the
term general election will be deleted.
- Issue
# 2: Terminology: Jurisdiction. This means different things in different
states. David F. will find a new word to replace the word jurisdiction,
keeping the definition currently used.
- Issue
# 3: Terminology: Scratch vote vs. crossover vote. It was decided to
replace with the term "straight party override".
- Issue
# 15: Terminology: User serviceable: This term means for errors that
are correctable by trouble shooter or election officials. The requirement
will be changed to clarify that it is only consider user serviceable
if the directions for fixing the error are provided in vendor documentation.
- Issue
# 19: Terminology: Ballot activation: This term will be defined to mean
what happens on the DRE itself. The epoll book issues ballot activation
credentials and John Wack has been using credential issuance in his
section.
- Issue
# 23: Terminology: Ballot choice term will be changed to contest choice.
- Issue
# 4: Terminology: Should there be a different definition for ballot?
What should it be, there are so many options. Ron suggested that maybe
there should be a listing of all the definitions of ballots with footnotes
in the document to the one matching the text. David F to come up with
a list of possible definitions and forward to Paul Miller for feedback
from election community (with the understanding that comments may not
be able to get into the July draft).
- Issue:
Terminology: Is the term "during an election" ambiguous. This
is used in the access control section. Nelson Hastings and David F will
work on this issue offline to put in a requirement and will take the
term issue off the table.
- Issue
# 14: Indicator for Whom (David Wagner): There is a requirement that
says that there will be a visual/audio indicator on the voting system
about the status of the voting device. It was decided to change the
requirement to narrow it to indicator for election judge.
- Issue
# 27: Public Information Package (PIP): Proposed change to the requirement
by David Wagner is to write the standard to say the test report must
contain something labeled as the PIP and that the PIP must contain the
test plan and test results to the extent possible. No objections from
members present.
Next
CRT meeting scheduled for Thursday, June 21. (Possibility it will be cancelled).
STS Issues:
Issue:
Cyrptogrpahy: The issue of what records have to be signed on the
voting system was discussed. There are multiple possibilities of what
a voting system does on Election Day and it was questioned whether different
keys were needed for different activities on the voting systems. It
was decided that the requirement would be written that the machine only
required one key, that everything must be signed, and there be able
to be a count of what was signed. [Bill Burr will write requirements
based on today's discussion.]
Issue:
Security through obscurity: David Wagner thinks there should be
a requirement that makes it clear that the system must not rely upon
security through obscurity for security. His proposed text: The voting
system must not rely upon the secrecy of its design, implementation,
or documentation for the security or integrity of the election. The
question is where does it go and how do you test. It should be considered
a guiding principle the same way privacy is. It was decided that the
requirement should go in the documentation standards. [Angela Orbaugh
will update this section.]
Issue:
Requires software independence: David Wagner was not able to find
any place in the standard which requires the voting system to be software
independent, as part of the normative text (rather than the discussion/introductory
material). He feels a requirement needs to be added. Subcommittee was
in agreement to add statement because the VVSG that is delivered to
the EAC must say all voting systems shall be SI, period. John Wack suggestion
was to add this requirement in the auditing chapter (being retitled
Security Architecture) as a high level requirement with subrequirements
on how to achieve SI, currently with VVPR. A glossary term for SI also
needs to be included - using Ron's original definition.
Issue:
VVPR should be mandatory: David Wagner feels there should be a requirement
specifying that all voting systems must produce a voter-verified paper
record. This is responsive to the TGDC resolution requiring software
independence, combined with the decision that systems producing a voter-verified
paper record are the only kind that will be currently supplied in the
standard, and the innovation class will provide a way to path for certifying
other kinds of voting systems. After discussion it was agreed that this
requirement would NOT be included. VVPR is included as a "may"
requirement for meeting software independence so that it leaves room
for other means of meeting SI for innovation class designs. It must
be made clear that any system in the innovation class must meet all
requirements in the VVSG and that SI must be met, but it can be met
in a new way. The proposal was to add a discussion to the requirement
to say the intent of the requirement is that all non innovation class
submissions must comply with VVPR but innovation class submissions can
meet the requirement of SI by other means. David Flater suggested adding
the caveat that any other way they system claims to be SI will be put
under intent scrutiny to make sure it meets SI.
Next
STS Meeting Tuesday, June 19th.
Meeting
adjourned at 12:30 p.m.
[* Pursuant
to the Help America Vote Act of 2002, the TGDC is charged with directing
NIST in performing voting systems research so that the TGDC can fulfill
its role of recommending technical standards for voting equipment to the
EAC. This teleconference discussion served the purposes of the CRT subcommittee
of the TGDC to direct NIST staff and coordinate its voting-related research
relevant to the VVSG 2007. Discussions on this telecon are preliminary,
pre-decisional and do not necessarily reflect the views of NIST or the
TGDC.]
************
Link
to NIST HAVA PageLast updated: July 25, 2007 Point of Contact
Privacy
policy / security notice / accessibility statement
Disclaimer
/ FOIA
NIST is an agency of the U.S. Commerce Department
|