TGDC Subcommittee Work - Historical Meetings - STS Meetings - 2006

1) Administrative Updates
2) Preview/Review of draft presentations
3) Other Items
4) Next call?

• Allan: TGDC members should have received the advanced CD for the meeting next week. Some papers will be revised. John Wack will send out new ones, notebook will have the accurate copy.
• Allan: Sunday night reception will be in Rockville room of the hotel.
• John W: Wondering if TGDC should be sent an email specifying a "reading list". Ron Rivest to send out email about what STS recommends reading.

• Curt Barker leads by saying auditing is good - generically that is how we secure systems in the world today;
   
  [Plans to talk about the auditability of systems from a security perspective, general information about other auditable systems such as financial systems, etc. This will set the stage for the talks that deal specifically with voting systems.]
   
• John Wack builds off that - we don't know how to write good requirements for closed box DREs;
  
  [Concern is that some people on the TGDC will not be happy about banning stand-alone DREs - an aggressive discussion may ensue at the meeting. Going to say that NIST conducted lot of research, did a lot of threat analyses, observed elections, worked with vendors, and NVLAP test labs, and kept coming to same conclusion - people that used VVPR machines were more secure and most resistant to threats. NIST cannot write requirements to make up for lack of audit capabilities in closed box DREs. Not a good direction for VVSG 07. NIST researched IDV, and the goal is to write requirements for paperless software IV systems that are independently auditable.
  
  Unable to derive general testable requirements. NIST would investigate further, but they would be design specific. Conclusions about VVPR and problems. We should talk about all the work that's being done in STS and CSD, not just the material we determined would be of most interest to the TGDC.]
   
• Ron to talk about software independence and innovation class - followed by resolutions;
  
  [John Wack sent some rough draft slide to Ron last night for the SI presentation. Also sent two draft resolutions. We need a third resolution for wireless - an amendment to an existing resolution. Slides say STS has developed strategy recommending software independence; possible paperless SI approaches; what is software independence; why end-to-end would be premature; and roadmap for new approaches to voting systems (innovation classes). Recommendations need to be built into the 3 hour period. [Recommendation for Resolutions: To write requirements only for SI based systems, innovation classes being implemented, and recommendations to EAC (?). Before the December 4 meeting, John/Ron to ask EAC if they would like resolutions/recommendations that might be useful for talking to Congress.
  
  We do not know how to do software independence for blind voters. There are lots of classes of disabilities that we do not know how to handle. For typical voters, we want software independent systems. For voters with disabilities, we need flexability. We need reasonable accommodations for voters with disabilities. Verification is a tough one to figure out. [NOTE: Software independence has to do with the auditing of the system, not for the usage of the voter.]
  
  Procedural defense: We need to have sighted people use the assistive technology and vote and look at their paper record to verify their vote. This gives you the security property you want. VVPAT is ok because it is not the vote of record - there are accessibility problems with VVPAT.
  HFP to discuss changes and additions made to HFP section. Sharon to think in terms of accessibility in the voter verification process. Sharon to include slide on "next steps".
  
  A good strategy has been developed in how the security work should be approach in the VVSG 07. If the SI stuff goes down in flames, do we have a contingency plan? Yes. If we don't have an agreement from the TGDC on SI, it will not radically change what is being done in security analysis or the IDV.
  We want the TGDC to recommend that NIST work on the SI stuff and write requirements for those.
  What about non-SI systems? If the TGDC says we should write requirements for them, then the burden is on those people to say what kind of approach should be taken.
  
  What requirements do we write for the current set of DREs if it is recommended we do so.]
   
• John Kelsey to discuss audit architecture and IDV - the high level approach to writing a security standard; identifying threats and addressing those threats
  
  [Building IDV is still a research problem - we're not ready to write standards for it. Point out that problems experienced with paper systems could get better.]
   
• Other significant changes - status, wireless with amendment of resolution introduced by Ron, then VVPR, setup validation, electronic record requirements - Nelson
   
• Discussion/questions should be expected regarding hardware change requirements
   

• Allan and John recommended new way to do teleconference. Pick issues that would become focus of teleconference, overlapping with two or more subcommittees.
• Ron Rivest to make phone calls to other TGDC members for preliminary discussions.
• Next teleconference will be December 19, 2006, at 10:30 a.m.
   

• Ron will be writing the next draft of the resolutions for Software Independence.
• John Wack will be preparing the next draft of the amended wireless resolution.

1) Administrative Updates
2) SW independent/dependent and innovation class presentation details
3) Final TGDC December meeting agenda for STS
4) Other Items
6) Next call Tuesday, November 28, 2006 at 10:30AM.

• Draft papers for the December have been posted on the TGDC website. (Some may be modified over the next few days.)
• There will be hard wire internet capabilities during the December meeting if anybody wants - just send Allan an email request.
• STS will be first on the agenda for the December 4th meeting, followed by CRT the HFP. Allan has allotted more time to STS and CRT since HFP needed less time. A two hour timeframe has been added on to second day for introduction of resolutions & discussion.

• New architecture with audit base (paper forthcoming, main piece is about threats)
• Related, high level testing expectations (will include discussion of OEVT [white paper before meeting] and security documentation)

• Wireless (may be members that understand and think they need to do wireless, white paper to be posted)
• Changes to HW (what the policy is about backwards compatibility, currently states use new standards when purchasing new equipment)
• Set-up validation - as time permits
• New VVPR requirements - as time permits (white paper)
• New electronic records requirements - as time permits (white paper)
• Others?

1) Administrative Updates
2) SW independent/dependent path forward
3) Revised TGDC December meeting agenda for STS (See attachment TGDC Agenda_draft_110806.pdf)
4) Clarification of content for security documentation requirements
5) Other Items
6) Next call Tuesday, November 21, 2006 at 10:30AM.

• Allan: EAC/NIST are starting to plan when the next TGDC meeting after December will be. Tentatively week of March 15-16 or 20-25 are in play.

• John W: Ron had sent his software independent paper to the EAC. John is writing Bill Burr's version of this combined with an internal NIST paper focusing on what we'll be presenting - a white paper outlining our strategy. Donetta Davidson will email Brian's concerns about this paper for Ron and John's response.
   
• Issue from meeting: Are we making big changes in VVSG 07 or not? Discussion of Incremental changes how state laws may have some affect on those changes.
   
• We should discuss where we are and what we have left to do for the December meeting.
   
• Ron: We need to nail down as much as possible for the security and risk management piece.
   
• The software independent system was discussed a lot, both specifically and in regards to what it means to the larger picture of other kinds of voting systems.
   
• Black box DREs without software independence would not be certified under the new system.
   
• Two categories of voting systems: independent dual verification (viability in the marketplace) and end-to-end cryptographic systems which would be software independent, but we could be more specific about the kind of requirements we write for them. Coming back from the EAC/NIST meeting with a clearer view that the independent dual verification system not be excluded.
   
• Alicia question: When Mark Skall said he wanted us to move forward on the innovation class, does he want us to write requirements to get certified or the process? There was discussion but no conclusions. We could probably write high level requirements, but we definitely need more discussion. This should be brought to full TGDC committee. Is it enough to say "we want to encourage innovation; we realize it's not happening fast enough"? How do we stimulate vendors to produce a new designs. We should have an open door policy - we need a certification process that makes it clear that they can request certification of a system that involves innovative approaches.
   
• There was discussion about disabled voters and accessibility and how it relates to software independence and voter verification. Whitney Q will help work on the white paper.
   
• Everyone on the EAC/NIST call felt comfortable with our approach on wireless.
   
• OEVT was mentioned, not much time for discussing.
   
• Also discussion led by Whitney and Dan on their subcommittees priorities.
   
• Donetta: EAC has testified before congress that VVSG 07 will be delivered in July 07 and we cannot change our timeframe. We need to prioritize the most important elements in the security area that we need to address. We need to evaluate the security risks and how they fall into place. Think about cost factor. Think about time element - TGDC needs to give guidance about how long it will take manufacturers to meet requirements. Will EAC be holding a hearing with the vendors to get their feedback? This should be brought up at ITAA vendor meeting. EAC is going to have a summit about the costs of doing certification.
   
• Helen feels that they were rushed before with the VVSG 2005 standards and buying voting equipment to comply with HAVA and does not want that to happen again.
   
• Donetta hopes election officials will ask questions at the TGDC meeting so that they understand what we are doing with VVSG 2007.

• New architecture with audit base
• Related, high level testing expectations (will include discussion of OEVT and security documentation)

• Wireless
• Changes to HW
• Set-up validation - (as time permits)
• New VVPR requirements - as time permits
• New electronic records requirements - as time permits
• Others?

1) Administrative Updates
2) Discussion of voter verifiable paper records (VVPR)
3) Discussion of end-to-end voting systems
4) Path forward on IDV in VVSG 2007
5) Other Items
6) Next call Thursday, November 9, 2006 at 10:30AM.

• Allan: Lucy Salah sent out email. For those who have not completed travel plans, there are some deadlines for hotels and flights.
• Allan: There will be a reception on Sunday night, 7:00 p.m. - 9:00 p.m., in the Hilton bar. EAC commissioners, NIST staff plan to attend. Monday begins at 9:00 a.m., Tuesday at 8:30 a.m. Draft agenda available soon.
• John W: We are putting up presentation material on the web by November 20. It will be mailed in final form November 27.
• John W: Security Assessment of Diebold Scan by Univ. of Conn.
• John W: David Wagner emails about priorities for December.
• John W: Meeting with NIST Director about recommendations for presentations and positions we are taking. We need a short summary paper about why we want to mandate(?) software independent voting systems.

• Metaphor - this industry is a lot like the children's toy industry when talking about regulations - wireless is like something with a sharp edge.
• Number 1 Priority - Software independent /software dependent. We should push hard to ban software dependent profiles of voting. We don't want secret code where an undetected bug could cause undetectable changes in the election outcome. If not good for TGDC, we should make the code public.
• Number 2 - Security Documentation. Make sure we have burden on vendor.
• Number 3 - Open-ended Vulnerability Testing.
• Number 4 - Banning Wireless.
• Number 5 - Requiring Set-up Validation. Wants to change "should" to "shall". If not, recommend we mandate systems that don't have validators have hard wire reprogrammable program memory.
• Number 6 - Having an innovation class. We spend too much time on design modes of new classes of voting systems that aren't designed, electronic IDV.

• Allan: Welcome to David Wagner (STS) who is now officially part of the TGDC, as well as the other three new members: Philip Pearce (CRT), Tricia Mason (HFP), and Paul Miller (CRT). We are setting up an orientation teleconference, hopefully before the  end of October.
   
• Allan: Reminder, the next plenary session of the TGDC is December 4 and 5, 2006  here at NIST. A letter will be sent shortly  to Committee members so that travel plans can be made. Also available for anyone who can not attend will be teleconferencing capabilities and webcasting. Schedule (preliminary): Reception on Dec. 3, (7 pm).  9:00 a.m. start on Dec. 4 (finish 5:30 pm), and 8:30-2:00 on Dec. 5.
   
• John W: EAC agreed that for the VVSG 07, voting systems should not have wireless capabilities. Using IR to read valid activation token is not a bad idea, since smart cards wear out. There is an ITAA  vendor meeting on Friday, John will question them about e-poll book usage. [Ron questioned whether the e-poll books should be in the scope of the committee.] John wil  write position piece on issues and decisions on e-poll books to vent with other subcommittees and EAC.

• Alicia Clay took notes for meeting  minutes. A lot of good work at the meeting. Final notes will be sent to STS.
   
• Group came to an agreement on the revised outline for the security related topics for the VVSG 07,it will be circulated for comment. The basic idea is to start with a security and audit architecture overview, talking about threat and securing the systems; then profile specific security and audit functional overviews (testable requirements), broken out into software independent voting systems and software dependent voting systems. The next section is profile independent tactical security requirements (where the bulk of the material from the original outline will go). Last will be a section on end-to-end verifiable voting systems, starting with an overview of principles behind how each system works. The last section will different in that instead of just testable requirements, it will start with submission requirements. An electronic copy of the outline will be available shortly.
   
• General comments on the security component.
   
• Documentation requirements: Need a decision about what should be in  public test package and what shouldn't; how we could make these test packages support  good procedures. Make sure we get requirements from the labs to get their understanding of how security works to ensure that they look at the details of the system.
   
• Decided to require FIPS 140-2, Validated Hardware Crypto models for certain functions - for all digital signatures.
   
• Also considering having two kinds of keys for every voting machine - one permanent key and one changed for every election.
   
• Received an verview on open-ended vulnerability testing.
   
• IDV: General ideas for IDV systems that will be presented in VVSG 07 and coming up with a position paper on why we were not discussing detailed requirements for stand-alone DREs in VVSG 07.
   
• Someone needs to update the working outline on the web. The revised outline from the meeting is written at a high level.

• Module serial number - a unique serial number for the module, created by the module manufacturer, and stored in the module. The module serial number can be read from the module.
   
• Module key - a signature key pair generated once by the module during module initialization and never changed during the life of the module. This key is used to sign election keys and election closeout records. The device private key is never exported from the module.
   
• Module certificate - a public key certificate, issued by the entity that initialized the module, binding the module serial number and the module key.
   
• Election key - a signature key pair generated by the module for each election; the election private key is never exported from the module and is zero'd by the process that generates the election closeout certificate; thereafter that election private key no longer exists. {the election key may also be used to sign some kind of initial system configuration record, and other kinds of logged transactions}
   
• Election counter - a running count of the number of election keys generated by the module
   
• Election signature counter - a count of the number of signature operations performed by the current election key.
   
• Election certificate - A public key certificate signed by the module key, that certifies an election key. The election key is generated at the start of the election certificate generation process and the election certificate is exported from the module after it is generated.
   
• Election closeout certificate - A certificate signed by the election key that is created at the conclusion of and election. The election closeout process creates this certificate, then increments the election counter and zeroizes election private key before outputting the election closeout certificate.

STS Teleconference
Tuesday, October 3, 2006

The meeting commenced at 10:00 a.m.

Agenda:

1) Administrative Updates
2) Discussion of paper on VVPAT and Paper Based Voting System Requirements Relating to Usability and Auditability of the Records
3) Other Items
4) Next call Tuesday, October 17, 2006 at 10:30 a.m.

Participants: Alicia Clay, Allan Eustis, Anoop Singhal, Barbara Guttman, Bill Burr, David Wagner, Helen Purcell, John Kelsey, John Wack, Nelson Hastings, Patrick Gannon, Quin Dang, Rene Peralta, Ron Rivest, Thelma Allen, Wendy Havens, David Flater

Administrative Updates:

• Allan talked to Commissioner Davidson yesterday who informed him that Philip Pearce (Core Requirements Subcommittee) and Tricia Mason (Human Factors Subcommittee) are confirmed as US Access Board representatives to the TGDC. Paul Miller (an election official in WA, Core Requirements Subcommittee) will likely be approved by EAC and NIST soon. David Wagner has bee nominated as the new representative from ANSI to the TGDC.
   
• Allan: Observed WA post election activities. The state is primarily a vote by mail state. All four voting vendors have presence in the state of WA with DREs to comply with Section 301 of HAVA. Allan saw 3 of the 4 DREs and 4 counties certification processes. Trip report forthcoming.
   
• John W: The official letter ANSI appointing David Wagner has been sent to EAC.

Discussion of paper on VVPAT and Paper Based Voting System Requirements Relating to Usability and Auditability of the Records - John Wack

• This was intended initially to be a write up to self after reading Election Science Institute's paper and meeting with authors to discuss problems had by Cuyahoga County in auditing their VVPAT systems.
   
• In a written response, Diebold has challenged a number of things in the ESI report and so has the Board of Elections in the county.
   
• It appears as if the Diebold system was set up to permit rudimentary audits, it didn't seem to be useful; usability seemed to be the biggest problem.
   
• A lot of stuff is not VVPAT specific, more so paper records in general.
   
• VVPAT defined as DRE with printer.
   
• Discussion: Flat sheets of paper vs. paper spools is a difficult choice. Usability issues either way. Which is better? Does the Human Factors committee have an opinion? John's personal experience is that handling the spools is difficult. Spools do maintain a paper record all in one container, but in a continuous non-private record.
   
• Bar code issue - Discussed with the Open Voting Consortium. They like using them. It makes the paper record have more integrity. Less resistant to damage. Used for easy sorting. John feels it's an attack vector. You can't trust that audits of the bar code will occur. It's another record you have to keep as well as all the other records. It's not transparent to the voter. If not carefully controlled, it could be trouble in the future. [Ron feels that bar codes were used for visibility. It could be used for accessibility reasons. Also it wouldn't be human readable.] Bar codes can be used for audio translation of names.
   
• Do we digitally sign electronic records? This isn't specific for VVPATs that could be done on DREs, could be done by ballot marking devices. It means key pairs on the voting station and how to store them.
   
• Records more useful if they were in the interoperable format, we've talked about EML. David Flater and the Core Requirements may be putting something in already.
   
• Allan: During his post certification experience in WA, of the paper, mailed-in, op scan ballots, bar codes are used as a record keeping mechanism on envelopes and later auditing processes. Helen uses bar codes to track when the ballots have gone out, and then again when they've come back to tell who has voted. The codes are not on actual ballots, so votes can not be tied to voters.
   
• Vendor did not do a good job about documenting how an audit should be conducted or how the records should be used.
   
• Issues such as digital signatures on records could be controversial. We want to keep in mind what's most important and then what would be nice to have. Will they be used? What's important to election officials when auditing? We need to be thinking of future.
   
• We need to think through how digital signatures will be used, the key management applications. Are they the lifetime of the machine? A memory card for the machine? Per election? What is the signature going to accomplish?
   
• John K: We need to write one or two specifications that we know how to test. A little concerned with open-ended testing process being burdened with analyzing key management in a crypto protocol.
   
• One of auditors issues in Cuyahoga County: trying to figure out which electronic records came from which machine, comparing what they had to what was still on the machine. Also memory cards that contained ballot layout information actually assigned a machine ID that was not the same as the physical ID. Robust identification would be good. Vendor should contain database linking serial numbers or identifiers on machine to public keys. Looking at electronic records, you should know which machine produced them.
   
• Processes for audits have not been tried out or well designed. In the standards, we need to require that someone goes through these audits and make sure they actually work. All information needed for an audit needs to be available, it needs to be in a form suitable for an audit, and procedures need to be tested. This needs to go in document requirements for VVSG 07. Performance benchmarks will have to be done as addendum. [Ron thinks they are easily doable for 07.]
   
• Ron: Question is what records should be maintained by the machine and guaranteeing that they're available.
   
• In order to get certain pieces of information off machines, a technician would have to be called - this is not a good procedure. Any interaction with the machine should be well documented.
   
• John W: Voting machines should digitally sign their records. For linking the electronic records with the paper records and verifying their integrity -- always include the robust machine identifier and include a unique identifier. We have key pairs on voting systems. We should include this in our requirements.
   
• John K: If you are digitally signing electronic records, it does not add any value to have that signature on the paper records. The paper record is to mostly check to see if the machine was working properly. There's no added security by putting digital signature on paper record.
   
• John W: The reason we have these sort of requirements is to facilitate audits of this nature. Is this the minimum for IV systems? Do we want them to have capabilities for this type of audit, or do we want them to have capabilities for full recounts? [John K has a write up on a proposal about this. Email discussion to follow.]
   
• Ron: If paper records are suitable for auditing purposes, and the paper records correspond to the electronic records, why would they not be suitable for recounts? [John W: Possibility that elections conducted on a bunch of VVPATs with paper rolls could be suitable for full recount, but we're getting more into usability issues - more legal issues than technology issues. It's a design consideration for IVs. John K. The minimal requirement is that the system is auditable to see if the machine was misbehaving. It would be nice for records to be suitable for recounting.]

The meeting adjourned at 11:30 a.m.

Teleconferences from 2004, 2005, 2006 and upcoming in 2006.

************

Security and Transparency Teleconference Meeting
Thursday, September 19, 2006 at 10:30AM

Participants: Allan Eustis, Angela Orbaugh, Bill Burr, David Flater, John Kelsey, John Wack, Helen Purcell, Nelson Hastings, Patrick Gannon, Rene Peralta, Rick Kuhn, Ron Rivest, Thelma Allen, Wendy Havens

Agenda:

1) Administrative Updates
2) Updated Cryptography Section;
       -No modifications to requirements but put into VVSG 2007 final format
       -Security documentation example requirements
3) Discussion of Security and Audit Architecture
4) Discussion of Threat Overview
5) Other Items

Meeting commenced at 10:30 a.m.

Administrative Updates:

• Allan worked at the polls last week in DC. Everything went smoothly, mainly because there were no major changes in voting equipment or procedures in DC from the 2004 elections. Voters Still have choices between OpScan and Sequoia DREs. Allan sent out his trip report from his experience in WY. Allan will be going out to Washington state for post election canvassing.
   
• Plans are to go to Arizona in November for L & A testing before the election.
   
• Rene Peralta went to Washington state for the Logic &Accuracy test. Stated that Seattle was an eye opener. VVPAT was a special case in WA where most voting is by mail. The DREs only require VVPAT, and the DREs are only used for special accessibility. Officials looking for emergency legislation about machines because there is a possibility of confidentiality being breached if only 5 to 6 people use a certain machine.
   
• John Wack worked the polls in Montgomery and had a very different experience than Allan. He has sent his comments out to wgvote and Ron Rivest. He will edit and then share with the rest of the TGDC. Voter access card was just a small part of the problem. John didn't like that every DRE has modem that could be connected. Any machine could be made into an accumulator. All the new equipment, including the electronic poll books, could be one of the reasons mistakes were made and the voter access cards weren't delivered.
   
• Frederick County, and other western counties, elected not to phone in results. They decided not to do counting at the polls which seemed to cause less hassle. John feels that it might be better to do these things at a central location where election activities are less hectic.
   
• John would like to discuss white papers regarding controversial issues that he wants to get in front of the TGDC.
   
• Helen would like to hear more about the electronic poll books and the poor manufacturing standards. Helen said that the Arizona primaries went well. Said very few people used the Sequoia Edge DRE equipment. Most problems caused by inexperienced poll workers and problems with new equipment. They did a full hand recount (not certified) of 24 precincts just to have the experience before a general election. Things were much better than expected. All were done by hand, nothing was supplied by Sequoia for the hand count.
   
• Allan and John will be attending the AEI-Brookings Election Reform Project on Friday September 22nd from 8:30am - 12:30pm, located at the Wohlstetter Conference Center in Washington D.C. Charles Steward of MIT is one of the panelists. Allan will send around URL for conference. A representative of ESI will be there and they hope to get some good information about how VVPAT systems performed.

Updated Cryptography Section - Nelson Hastings

• Nelson did not make any changes to the text of the requirements; the main reason that he wanted this on the agenda was to show the final format (which is in question). [John - Some things may change on the format, but the structure should remain the same.] Wanted to point out that short titles have been added before requirements. We have a couple of "applies to" fields, as well as a test reference field.
   
• Ron: Looks nice. Also source and impact fields? [John W: Source is basically a reference for the requirement. Impact is an internal field saying what is the impact of this requirement to existing technology and existing systems. Not sure this field is necessary.]
   
• John W: Usage of glossary terms and how they should be used in the text. In the "requirements" text we should probably link each use of the glossary term to the glossary. Consistency of usage needs to be clear.
   
• Nelson: The other thing is about security documentation. Wanted to look at a couple of examples in the cryptography requirements of documentation requirements and see if they meet Ron's expectation. [Ron: Do we have a definition for security services? Nelson - Section 2.1. We need to make sure how those services get used are also discussed. And also about encryption security cards.] Nelson would like Ron to look at this section and let him know if there is anything he feels is not covered in the documentation requirements.
   
• Ron: We need to think about what we want the vendor to provide, everything from the declared security objective, policies for the machine, how to configure, what security mechanisms there are and how they work, and then to justify to the evaluator the architecture and the rationale for the machine.
   
• Nelson: If it is determined that the security documentation provided in the cryptography document meets our needs, should they be kept in that section or pulled out separately. [Ron: A security document as part of the evaluation package is important. Ron's opinion is that all the security regulations should be done in a larger combined document and refer to other things as necessary. We need to give guidance to vendors about what can be expected as far as structure of the documentation. Not just a list of items that need to be there.]
   
• John K: Should there be a section regarding the security documentation with links throughout the document where it states that it imposes this additional documentation? Sections that state what the requirements for the technical documentation are? Throughout should there be statements that say in order to meet the security documentation this is what you need to do? [Ron feels that having the security documentation together might be the right way, but this is open for discussion.]
   
• David F: In the outline that we're following, within the chapter on user documentation, there is a distinct section on security documentation requirements where these types of documentation would go. [Ron: User documentation means poll workers, voters, and election officials? David: It means the customer. However it is also included in the technical data package.] With the outline, all requirements could be moved into the chapter on user documentation, and they could be cross referenced with the security requirements section. The security documentation would be a chapter within the user documentation. [Ron: There may be other things regarding security that the user doesn't see, having to do with the internal architecture and the structure of the machine.] Maybe there should be a separate section for the TDP. [John K: Seems like these would be two completely different things for the users and the test labs.] [Ron: There needs to be evaluation to make sure the user is being adequately instructed.]
   
• [John W: As far at the documentation that should go to the labs, was there a questionnaire? ] Ron will dig it up and revisit it as a checklist for the vendors, making sure they extend the level of detail we're looking for. The vendor needs to know that the default for the system is insecure and it will only be deemed secured when it goes through all the requirements. The burden of proof is on the vendor for security. Ron will turn this into a better organized list. Maybe we can all generate questions we'd like the vendor to answer.

Threat Overview and Threat Tree

• John K sent around something. We've been looking at outline to see what the components met. We weren't sure what we needed to write, so he took a stab and that is what he sent out. Part 1 is a draft threat overview.
   
• We have the Brennan Center report. Is the vision here that we need more into material?
   
• JK: We have two sections, the threat overview and the threat tree that are here to set the tone of how we're thinking about the threats at a high level. The big thing John wanted to do with the overview was describe the type of categories of threat we cared about, and how we think about these attacks; what we mean when we talk about an attack on a voting system, who are potential attackers and what kind of budget they have. [Ron: This is just informational for the reader, cluing in the vendor about how each of these threats can be dealt with.] The overview is not normative, neither is the threat tree. There are no "shalls" in the threat tree. [Ron: The benefit is to educate the reader about why the security requirements are there. Some of the requirements may link back to this.] John doesn't have a good intuition how this is all going to fit together.
   
• John Wack thinks the introduction of the VVSG would be a good place to put controversial topics because it would be more accessible. This may be a good place to discuss these threats. We at NIST should talk about this before going further.
   
• Ron: In terms of writing various security requirements, do we have a policy for tying them to particular threats or providing a justification for the requirements or to the higher level security? John Kelsey does not see the logic of tying each requirement to a threat. John Wack thinks that it might be a good idea to have the introduction state something about how the requirements might prevent certain groups or types of threats. In the discussion field we might be able to do traceability. Thinks doing the introduction this way would be very useful.
   
• David F: The same things we're seeing here, could be used on the requirements for the security documentation to require vendors to explain how your system prevents each of these classes of attacks.
   
• Ron: We just want to make sure that vendors explicitly considers voter attempts to subvert his own privacy.
   
• John K: It's worthwhile to point out these classes of attacks and to go into a little more detail in the attack tree, but concerned about requirements that say demonstrate how you prevent the broad attack of subverting the election. Multiple requirements you want to uphold because they prevent multiple kinds of attacks.

Security and Audit Architecture

• John K: I don't feel like I know what we need to accomplish with this section. This is just a first take to see how others felt. We need to discuss architectural profiles on the different type of voting systems to make sure each piece of the voting process can be audited.
   
• David F: One of the first questions to answer is, which kinds of auditing are you concerned with? Not only that the recorded votes were counted correctly but also that the votes that were intended to be cast by the voter were recorded correctly. Some of the specific designs we have only accomplishes one or the other. If you're auditing for all the above, then that will determine your responses. [John K: should audit for the full correctness of the system, so that final vote totals are substantially correct.] Where does ballot accounting fit in? [John K. would expect that to go in this section. They assumed that the poll books were part of the auditing trail. It was disconcerting to see that both the electronic poll books and DREs were from same manufacturer.]
   
• John Wack: The electronic poll book that he used wrote to the smart card that activated the ballot. [Ron - they're called voter activation systems]
   
• This section is all about auditing even though we divided it into a separate section. Thought the audit section should be about audit longs and audit trails and how to accomplish the auditing technically.

Voting Activities Section:

• David F.: In the outline for VVSG 07, there's one major chapter regarding general requirements that seem to apply globally throughout the voting process. Following is another large division of requirements by activity that goes chronologically throughout election day with requirements that are more specific to the individual activity than the voting process.
   
• Ron: You need to divy up type of audit material. You need to organize the auditing section by the information you want to have available after the election to do any kind of checking. [John K: It's not enough to specify the information has to be produced, you also have to specify how its going to be used and make sure the architecture of the voting system supports that.] The high level goal here is to make sure we have some kind of coherent organization discussing the various kinds of auditing that can be done, what the information is that is produced, what the procedures are, how the audit information gets protected.
   
• John K: We don't have to specify what the procedures are, but we do have to specify that what they do, like audit this against this.
   
• John W: In the threat overview, you'd have to reference various type of audits as addressing some of the threats but was wondering about a section that says these requirements exists to support the following types of audits.

White Papers

• Possibly on VVPAT. Privacy requirement in effect won't permit paper rolls. New VVPAT requirements versus old.
• Possibly another on 8022 wireless.
• John Kelsey has concerns that asking someone to do white papers at this point would be a bit much as everyone already has enough deadlines.
• Group should come up with a list of major controversial items. This will be a dynamic list.

Next scheduled meeting; Tuesday, October 3rd at 10:30-11:30

Meeting adjourns at 11:45

Teleconferences from 2004, 2005, 2006 and upcoming in 2006.

**************

Security and Transparency Teleconference Meeting
Thursday, September 7, 2006 at 10:30AM

Agenda:

1) Administrative Updates
2) Update on high-level assumptions and security assumptions
3) Discussion of priorities for STS
4) Other Items
5) Next and future STS calls

Tuesday, September 19 at 10:30AM
Tuesday, October 3 at 10:30AM
Tuesday, October 17 at 10:30AM
Tuesday, October 31 at 10:30AM
Tuesday, November 14 at 10:30AM
Tuesday, November 28 at 10:30AM

Meeting commenced at 10:30 a.m.

Participants: Alicia Clay, Allan Eustis, Anoop Singhal, Bill Burr, David Flater, John Kelsy, John Wack, Nelson Hastings, Quynh Dang, Rick Kuhn, Ron Rivest, Sharon Laskowski, Steve Quinn, Thelma Allen, Wendy Havens, Wendy Orbaugh, Rene Peralta

Administrative Updates:

• Allan Eustis will finish up his trip report from Wyoming. He has to scan in some documents, including a contract between the state of Wyoming and election system vendors. The contract states that the vendors will comply will all NIST and EAC standards. Allan is interested in group's reaction. Three counties use Diebold, the rest using ES&S.
   
• John Wack: A few people will be volunteering at the polls next week. Alicia and John will be traveling to Denver in two weeks to do a NVLAP assessment.
   
• John Wack: Discussed a paper that was forwarded from Election Archives Organization. John doesn't know about the merits of the paper, but it has less than nice things to say about election officials. Allan is waiting to get the author's permission to post it on the public comments web page.
   
• John, Ron, and Max had a discussion with Gtech, an organization that makes gaming systems for the gambling industry for a number of states. Intent was to get contacts. Lots to learn from what they're doing in testing and self validation and authenticating process and programs. They're interested in setting up a conference call and discussing the overlaps with what we're doing. Allan's going to find out what the DC lottery procedures are.

Basic Assumptions Update:

• The basic assumptions section is item #4 on Computer Security Division's (CSD) list of deliverables for NIST's December delivery. They will publish this list of deliverables and their schedule soon on the web. Steve Quinn has updated the basic assumptions bullets internally that were discussed in detail at the last S&T meeting based on comments from that meeting. He will send out a new iteration for further comments and vetting before doing the white paper and becoming part of the standard.
   
• Ron felt this was a good start but still a little way to go before we can convert this into a usable white paper. Ron wanted to know how CSD's deliverables mapped to our priorities. Steve will send the matrix out soon. Their bullets were created from the table of contents which maps to the priorities. The priorities should not change what they're writing.

STS Priorities:

Looking at the overall package of what needs to be done for December meeting.

Need to identify what will have the most qualitative improvements in the voting system.

The following 3 items are things for discussion that might/should be at the top of the list:

(1) further definition of requirements for open ended vulnerability testing
(2) security documentation requirements
(3) IDV-related requirements (software independence)

Security documentation is good place to start since we already have a framework in place. Security evaluation process shouldn't be put together from bits from vendors. Requirements, mechanisms, policy need to be articulated by the vendor and why they think is sufficient to support the security objectives listed. Good place to push forward, doesn't require any changes in the systems being sold. Makes the evaluation system for security more robust and reliable. Qualitative improvement should be high.

JW: If voting standards have general statements, you get the least amount possible, so we might want to be more specific with possibly an outline, details about what we expect from the vendor. Our challenge will be to right the specs.

JK: Links to open-ended testing is where there's a requirement statement; there should be a statement saying "how" you are meeting this requirement and point you to where it can be reviewed to verify. Proposed as a high priority item, should it be? Seems like it should be a part of every other component.

JK: Documentation requirements should be included where helpful to the evaluator to judge where it passes/fails.

JW: Two audiences - testing lab and users. Some effort should be put forward to identify each aspect of the system that requires procedures.

SQ: It doesn't have to be human-readable in order to make it into the standard.

AE: VVSG primary users are the testing labs.

JW: We started out in relation to security systems and how they are presented to labs and how they are used by vendors but we've discovered as time goes on that usability and security is important for users and election officials. A lot of the problems we are seeing now are because systems are not well documented and people are not appropriately trained. One of the tests should be whether or not procedures are plausible and can be followed. We realize for 2007 that we are not going to be able to do as good a job for security for poll workers as we would like. Procedures for IT systems needs to be present in order for the security goals of the IT system to be effective - what the labs need to evaluate is the system and its documentation. Vendors must be specific about what operating systems they are using, and what off-the-shelf software they are using.

IDV Related Requirements. Definitional proposal - software independence is a useful term to help us characterize what IDV is all about and what kind of testing we want. System is software dependent if correctness of the election results depends on the correctness of the software, that is to say if an undetected error in the software could cause an undetected error in the election results. CSD is willing to accept this proposal as the framework. The character of the testing we do should depend on whether the system is software dependent or not.

JK: The first question we have to ask is are we in the VVSG 2007 certifying closed box DREs.

JW: Opinion is no, IDV with two sets of records should be way to go. Not discussed with TDGC as a whole. Issues may arise because some states are invested in black box DREs and what happens to them, issue which should be handled by EAC, especially if we go a different direction and those are no longer certifiable. The other issue is the debate on VVPAT systems as one of the major types of software independent systems as to whether or not they actually achieve their goals in providing the detectability and auditability that we want. The current round of VVPAT has some issues. The proposal that IDV systems be the only ones that are certifiable is a good place to start from. If we do not write requirements for closed box DREs and we are overwritten, the security holes will continue to exist and we will do nothing to make it better. If black box DREs are allowable, then a vendor proposing software dependent system needs to go to extraordinary lengths to prove that the software in reliable, this may require formal proofs that other systems do not require. If NIST decides to take this approach, it must be organizationally backed. A fairly simple white paper needs to be put out ahead of December TDGC meeting discussing this approach and framing this issue. If we are not going to support black box DREs, then we need to give alternatives. Make sure that TDGC does not think they're only course of action is to throw out current DREs. We are not talking only about existing systems, but new systems down the road. VVSG 2007 certified systems will not be available until 2012. Based on a 10 year system lifetime, they do not want people to think they have to throw out of the systems that don't meet the 2007 standards. IDV spans both categories - dependent and independent.

ACTION: Paper that Ron did on software dependence needs to be warped into a white paper that STS recommends for review by TGDC members. See John Kelsy's email for possible plausible strategies. Email conversations to follow. Move forward with proposal that black box DREs are not going to be supported.

One of HFP's goal is to increase universal accessibility over several years. HFP wants comparable functionality. Paper is not accessible, but when used with voting system with accessible functionality, it is OK.

Open Ended Vulnerability Testing. Ron feels this is something that can provide major qualitative improvement in the security of voting systems. If we can get this up and flying by December, it will be a major milestone. At the monthly meetings between EAC and NIST, it keeps coming up about what can be done now to improve voting systems. Open ended vulnerability testing keeps coming up. This should be a high priority because we may need to provide material on this before the July timeframe. Some skepticism that open ended vulnerability testing will improve the security of the systems. Might be another matter for the TDGC to take on as a whole. If we are trying to test existing systems, the penetration testing has a lot less appeal than if you were testing future systems. The goal is for certification of new systems primarily, not as important for older systems.

ACTION: Meet internally to discuss options and resources.

OTHER:

• Questions about what the expectations for deliverables arose. Allan, John, Steve, and Alica meeting offline to look at matrix to see how deliverables map.
   
• John Wack: Set-up validation is ongoing and very important. We've requested several times that the requirement in VVSG 2007 be rewritten, currently it is pretty ambiguous. VVPAT is another, as there are no real standards on it right now. John lumps VVPAT in with IDV stuff.
   
• Meetings have been moved to Tuesday mornings.
   
• Two day MIT meeting (October 5 & 6) on voter identification and voter registration systems. Program is almost set. Ron will send around the URL.
   
• Allan and John will forward upcoming conferences around. Will post on the web if we get information provided.

Next meeting September 19, 2006.

Meeting adjourned at 11:55 a.m.

John Kelsey e-mail:

Some Notes on Alternatives for Audit Architecture Strategy
John Kelsey, September 2006

1 Introduction

In the last couple of months, we've had a couple apparent changes of direction with respect to what I'll call the architectural requirements for allowing auditing in voting systems. We need to make some decisions about the direction we're going to take, given the time and resources we have available and what we think will actually be used.
The big problem we need to address is that DREs, which are increasingly widely used, have major security problems. These can be broken into two broad categories:

a. The impossibility of meaningful audit of DRE results, and the resulting requirement to trust the in operation of software and hardware.

b. Implementation or design flaws that make the DREs less secure than they have to be.

1.1 IDV

Our original goal was to address (a) with IDV. That is, we could write standards for pure-electronic systems that were designed to be meaningfully auditable. This centered around the idea of some independent piece of software or hardware which could be used to audit the correct recording of the interaction between the voter and the voting machine. (This should sound a bit like Chaum's observer chips.) The good thing about this is that while there are no IDV systems (other than VVPAT) on the market, there's nothing all that hard about building one from available technology. While using an IDV system still leaves us trusting some software and hardware, we only end up trusting that one of two systems hasn't been tampered with.

My sense is that if we have standards for IDV (assuming we can write meaningful ones), we may be able to exclude pure, closed-box DREs. This would be a really good thing, and getting people from unauditable black boxes to pairs of black boxes that audit each other seems like a pretty big win. (We still need to address (b), which is where all the headline-grabbing attacks have happened.) I'm not sure this is possible, but it might be.

The downside of all this is that IDV gives you some audit, but not a really strong audit. It's like the difference between having two different accountants who work in the same office checking each other's work, and having a completely independent auditor come in and go over the books and all the supporting records. It's very easy to imagine that the two different modules in the IDV system will be corrupted at the same time--they'll be stored under the control of the same person, they'll likely have some software in common, they'll be sold by a consolidator who buys the individual components and hooks them together into full systems, etc. What I see as the big problem with IDV is that it pushes us toward a future that is still software-dependent. The clever attacker has to take over two machines, or three, or ten, but then he gets to fix the election.

1.2 Paper (Direct Verification)

John and Ron's software independence paper basically pushed us toward a different direction--not allowing any voting machines which can't be meaningfully audited in a way that doesn't depend on any software or hardware operating correctly. Excluding crypto (which does rely on software correctness, but allows a skeptic to write his own software, and which is not at all ready for standardization), this means we accept only paper systems right now. My concern with this is that I don't think it addresses the DRE question in a way that's actually workable. I'd love to see us say "DREs are no longer going to be part of the standard," and if we can do that, we should. But I think if we write that kind of standard, the TGDC won't accept it, and the EAC will ignore it and keep allowing DREs, and we will be left with no meaningful improvement in the security of the existing crop of DREs, because we won't have written meaningful standards for them.

1.3 End-to-End Crypto

I'm pretty convinced that some kind of crypto voting scheme, like those pushed by VoteHere and David Chaum, is where we'd like to end up. I think there are still some pretty big issues to hash out about them, and we need some kind of operational experience running small elections--I know David Chaum is working on this with the student election competition. I've heard that some states have provisions for the use of experimental voting technology, which is a potential starting point for this stuff. (I keep thinking one of David's all-paper schemes might make a good absentee ballot scheme.) The biggest issue with these is how we standardize the cryptographic protocols. We can describe this class of systems at a high level, and do a Brennan-center type threat analysis of them, but the process of deciding that a proposed voting protocol is secure is going to be harder to deal with. To my mind, protocols are much harder to get right than cryptographic mechanisms like hash functions or block ciphers, but NIST took many years to settle on one acceptable block cipher, and we'll likely do the same with a hash function. It's hard for me to visualize us or anyone else being able to confidently approve a whole proposed voting protocol in much less time.

2 So, What About DREs?

The elephant hiding under the rug (I love mixed metaphors) is what we do about DREs. I see a few plausible strategies, and I'd like to discuss which of them makes sense, both in terms of technology and in terms of what will actually get accepted. (I don't know about you guys, but I'm not really interested in writing standards that get ignored. Life's too short.)

2.1 No DREs in the VVSG2007, Software Independence

We could get rid of any support for DREs in the next version of the standard. Just say no! But then we have to decide what to do about the present and the future. If we go with the software independence notion from John and Ron as a requirement, along with allowing crypto when it's ready, we get a path like:
Today: Use paper
Someday: Use crypto

If we want to do this, I'll be very happy. In that case, we could really try to push the crypto stuff forward, with the hope that existing DREs slowly die off and ultimately are replaced with some kind of end-to-end crypto scheme. But we're a long way from being able to standardize on a crypto scheme, so for the next 10 years or so, probably only paper-based systems would be certified. In security terms, this is probably the best we could do, if it is followed. If we end up certifying DREs anyway, we lose our chance to address some of the huge security problems with them. (DREs could be made very hard to attack for outsiders, though probably not for insiders.)

2.2 No DREs in VVSG2007, IDV

We could also not certify any pure closed-box DREs in the VVSG2007, but write a somewhat theoretical standard (since we have no operational experience, only a few prototypes) for IDV systems. The advantage of this is that some vendor could build a system of this kind from existing components in a couple of years.

This would require writing some pretty extensive requirements for IDV, a lot more than just requiring an audit port on the side of the DRE. One downside here is that we could end up pushing people toward IDV, and thus ultimately away from crypto. Since crypto has the potential to be a lot more secure than IDV, that's a little troubling.

2.3 DREs in VVSG2007, Software Independence as an Ideal

We could write requirements for DREs in VVSG2007 and allow them to continue to be certified, subject to some much tougher testing and security requirements. This is where both the audit port and the OEVT stuff come in. We could then require software independence for VVPAT and Opscan systems (which basically means specifying how they must be audited). We could also write some theoretical discussions of crypto for the future.

This seems like where we're headed right now. We certify DREs for now with tighter requirements, but try to ultimately push software independence where we can. We encourage the eventual move to crypto.

2.4 DREs in VVSG2007, IDV

Finally, we could both allow new DREs with tighter requirements, and also push IDV architecture as a future alternative. I think this doesn't make much sense.

3 My Ideas

I'd like to see us do one of the following:

a. Move to IDV for DREs now, and push toward crypto in the future. (This probably requires more work than we'll be able to get done in the available time.) Don't support DREs anymore.

b. Don't support DREs anymore. Move to paper now, and push toward crypto in the future.

What I think we'll end up doing, in practice, is:

c. Allow DREs with tightened security requirements and no IDV, and make some vague handwaves about how we would like to see crypto systems in the future. Also make some vague comments about how software independence is worthwhile.

I suspect that (a) is politically possible but pretty hard to actually write, and that (b) is much easier to write but probably will either be changed or ignored by the EAC. That lets us keep relatively clean hands, but it does mean that the current security problems with DREs don't get addressed in any comprehensive way in the standard.

3.1 Timetable

Anything we do with a full IDV spec is going to be a pretty theoretical standard (we'll be standardizing stuff that exists only in prototype form right now), and will take some serious time. However, a lot of that time is going to come from the requirements for
hardening software and hardware systems (OEVT, for example). That work probably has to be done anyway. We're not going to have a complete draft of an IDV section we'd be happy using for actual certification of machines in November/December, as far as I can see.
(Who has time to write it?)

OEVT is going to take another year anyway. So maybe making IDV take that long, and getting down to specific testable requirements then is okay. I'd love to hear some discussion of this.

Comments?

--John

Teleconferences from 2004, 2005, 2006 and upcoming in 2006.

**************

Security and Transparency Teleconference Meeting
Wednesday, August 23, 2006
10:30 a.m.

Participants: Alicia Clay, Allen Eustis, Angela, David Flater, Helen Purcell, Nelson Hastings, Patrick Gannon, Philip Pearce, Ron Rivest, Sharon Laskowski, Thelma Allen, Wendy Haven

The meeting was called to order at 10:33 a.m.

Administrative Updates:

***************

Participants: Allen Eustis, Nelson Hastings, John Wack, Quynh Dang, John Kelsey, Rene Peralta, David Flater Ron Rivest, Angela Orebaugh, Philip Pearce, Adam Ambrogi, Wendy Havens

Agenda:

1) Administrative Updates

2) Summary of USENIX/ACCURATE Electronic Voting Workshop - < http://www.usenix.org/events/evt06/tech/>

3) Follow up discussion on software-independence approach

4) Other Items

Administrative Updates:

AE-while away on vacation, inadvertently two meetings were not recorded because of a low battery level in the audio recording device. The minutes of these teleconferences are available for public review on the web site (http://vote.nist.gov/subcomm_2006.htm). We can fill in past discussion item details when discussing items during this conference call.

AE-informed everyone Paul Craft of the TGDC has recently resigned from the TGDC. Letter of appreciation to Paul and recognition of service will be available soon from Dr. William Jeffrey. His NASED Replacement nominee is Paul Miller who is with the State of Washington's secretary of State's office. The vetting process for his appointment should be completed shortly.

JW-discusses issues brought forth from the NIST monthly meeting with the EAC:

• 2005 VVSG security requirements, current direction in VVSG 2007 VVSG
• EAC asked for more information on the NSRL; build environment; hold more than hashes in the future? (RR noted problematic issues here- question of what software has to be hashed.)
• EAC would like know more about where specific voting systems are located within the US (down to county level),sighting, different jurisdictions have different problems. Also EAC will need to notify jurisdiction of re-certification and de-certification related issues.
• There is a need to address metadata requirements related to voting systems vis a vis robust inventory control.

JW- Noted effort to look at security standards in gaming industry. AE will research security experts in the gambling security area (States of Nevada and New Jersey) and forward names to STS mailing list.

USENIX Electronic Voting Workshop:

NH-summarizes the workshop he attended in Vancouver;

• good presentation from the keynote speaker
• included statistical approach to detect fraud
• importance of exit polls; are they a reliable source
• if exit polls are too small, do they stay useful
• talk on source code "very interesting"; open source and disclosed source
• John Kelsey talks about testing the "hypothesis"
• Ron Rivest will look into survey reference material and will forward. If sample is random, you can detect anomalies.
• usable paper records; paper formats
• read back; pronunciation of names of candidates
• issue on use of bar codes- layered on a bad design; Populex approach
• could there be a convergence of EBMS/VVPR here

Software-independence:

JK-after looking at relevant memo (below), concern of "what problem" is trying to be solved.

• direct verification
• pronunciation of candidates names re: OCR text
• mechanical (human use) systems
• concerns worth looking into- don't want to look at just bar codes
• Question of Populex System that uses a ballot without printing the name of the candidate
• OP Scan just reads position on ballot and not candidates name
• Heart of issue here is to detect errors
• definition of "verification" procedures: we are re introducing directly verifiable records
• RR noted that being software independent is not a panacea here.
• John Kelsey will send comments on the document: You still have implicit trade offs here that depend on procedural mechanisms.

JW-will send out useful overlap VVSG areas in which "gaming" requirements might be informative (FIPs modules, etc.)

Next scheduled teleconference:

Wednesday, August 23, 2006 at 10:30 AM EST

Note on Handling of Voter Verified Paper Audit Trail Requirements in VVSG 2007, John Wack
August, 2006

This is a short note whose purpose is to outline an approach to structuring requirements for VVPAT in the VVSG 2007.Some Terminology-

First, I'll address some terminology. I believe that the acronym VVPAT has become associated with today's VVPAT systems, which, I also believe, are not especially usable
or built well. I would like to use a somewhat different term in the VVSG 2007 so as to differentiate the new requirements from today's systems. I think the term 'DRE-Voter Verified Paper Records' is a better term to use to describe its use with DRE systems (DRE-VVPR). I recommend that VVPAT not be used in VVSG 2007.

Overall Presentation Structure

The VVPAT requirements section in VVSG 2005 started out as a self-contained standard. It was subsequently modified so as to reference usability and accessibility requirements in the HFP section, but otherwise, it still contains many workmanship, reliability, interoperability, security, and cryptography requirements that logically would belong in other sections of the VVSG 07.

I recommend that the requirements be better integrated into the VVSG, that is, the VVPAT section should contain only those requirements that pertain specifically to
VVPAT and other requirements be located in their major sections (e.g. Usability, Hardware, etc).

I recommend using the class structure and the appropriate 'applies to' fields in requirements as the preferred way of doing this. Overall, I recommend that Software Independent Approaches be the highest-level category of acceptable voting systems, with IV being one of the approaches. DREVVPR is one example of IV. Another example is Op Scan-VVPR.

Privacy

I recommend that VVPAT not violate privacy: paper audit trails shall not store voter's cast ballot records sequentially. This was the TGDC's direction in VVSG 2005 but the EAC subsequently decided to permit sequential storage and require stronger procedures for safeguarding the paper rolls (an un-testable and unenforceable requirement).

Bar Codes

I recommend that bar codes to contain cast ballot records no longer be permitted. I believe the bar codes came about because of the recognition that paper rolls are difficult at best to use in audits and therefore use of a bar code would permit relatively simple and
accurate optical scanning. However, voters cannot verify the bar codes and therefore they can't be used in audits unless they are compared against their plain-text equivalents in sufficient numbers. This adds complexity to auditing and doesn't adequately address
the main problem, that being the poor quality and usability of the paper record. I think
the fonts on the paper record should continue to be required to be OCR fonts (as in VVSG 2005). If printed well, the fonts should be adequate and useful in optical
scanning.

• Teleconferences from 2004, 2005, 2006 and upcoming in 2006.

*************