Participants: Alan Goldfine, Allan Eustis, Brit Williams, David Flater, Donetta Davidson, John Wack, Max Etschmaier, Nelson Hastings, Paul Miller, Steve Berger, Wendy Havens, Dan Schutzer, Steve Berger
Voting Machines: Quality and Configuration Management Requirements - Max
The report has been available for review on the website for a couple of weeks.
Max gave a general overview of the report:
Third report that Max has written: The first one defined what a voting system is all about, what is required of the voting machine, and the concept of reliability. The second report builds on the first one and shows what reliability performance could and should be expected of a voting machine, and it is reasonable to expect the voting machine not to have any critical failures, or at least a very small number (low probability of failure). The centerpiece of the second report was a model of a generic voting machine and a functional analysis of it.
The current (third) report builds on the earlier two and developed requirements for quality and configuration management. It defines quality and configuration management and examines what was written in VVSG 05. It develops a framework where regulator and vendor are separated. There are both a product and a quality process.. The system develops product quality through process quality. The standard is outlined in ISO 9000. It defines the terms and the general principals. You want a measure of rigor to ensure quality and avoid pitfalls of workarounds.
Further details regarding the report were given, followed by a discussion period.
Donetta: When talking about all 3 presentations, when we have the December meeting, how much of this are you going to explain to the others? Answer: Decision forthcoming. It would be beneficial to spend time educating the TGDC on a number of these issues. They should be stated simply - we may end up sacrificing issues in the interest of making them clear. Members should also realize the VVSG 07 must be written clearly, that we do have a firm deadline, and that we need to put as much information as possible in the guidelines.
Some of this proposal looked like it would result in new hardware; if that is the case it needs to be made clear to the members. It would be nice to have a cost estimate for Max's proposal. New equipment also affects the timeframe when everything becomes effective. When considering the deadline for implementation, take into consideration design, building, and testing of any new hardware. The two year deadline may not be enough.
Max restated the purpose of his three papers. Following an outline prescribed by CRT, he was to develop new quality assurance language for the VVSG 07. These three documents provide the basis for further work. Next step is to look at implementation. Currently, we have not looked at the economics from transitioning from the current system to future systems. Recommendations will be based on this analysis, followed by discussion of specific recommendations for next guidelines. These documents presented by Max are a precursor to the language going into the document.
Alan G: Cost implications have come up before - it seems that the general consensus has been that although we should not eliminate the cost issues, NIST's responsibility is to develop the best possible technical recommendations.
Steve B: Cost not the issue, it is implementation and understanding the possible interruptions and consequences. He would like to see a gap analysis from both CRS and STS subcommittees. Compare these new concepts versus the current class of equipment being sold and used. The TGDC has to understand the size of the gap with equipment currently in use and how much would have to change. Second, what is the time period for having plans for these concepts for deployment and implementation? Some aspects of this concept are a long way from being effectively implemented. Next, what is a credible transition plan that wouldn't be unduly disruptive? Vendors must design equipment taking into account that new requirements will be forthcoming and they will be harder to certify. We have to look at all three of these things before we're asked to make decisions.
Max pointed out that new machines that meet new requirements will be no more expensive than current machines.
New machines would not be open systems. Some input/output mechanisms that generate vulnerabilities we've been discussing would be disabled. Unnecessary software would be disabled in the new systems -- any function that is not needed on a system should not be included. General purpose code is not necessary. Once you know that the software in the machines works as advertised, there is no need further modify that software. (This eliminates the emergency patch scenario.) Interaction with the outside is strictly prohibited with the closed box and does not need any modification. The outside voting system (which is part of the internet) will need to be patched and modified and adapted as needed but it will never change what is in the secure voting machine that will be available for verification. If we go with this protocol, we can ensure safe and creditable elections. [Steve: To go with this, we would have to replace every electronic voting station currently in the field.]
How far are we along? What do we want to do? We shouldn't be designing voting machines. If we only design guidelines, we are well along to meeting VVSG 07 deadline.
issue: It would be unthinkable to throw out all current systems. It is
a learning process. We can modify old systems to get them close to what
a reliable voting machine should look like. Voting machines being recommended
require an understanding of everyone in the voting system. Use transition
of the systems to reevaluate voting process.
With the scope of the things we're changing, it would be helpful for CRT to develop a field deployment scenario like when major upgrades are made to the telecom system. This is to understand the scope and challenges of changes. [This will be looked at in next report, as well as an implementation plan.]
We need TGDC buy-in at the December meeting if this is the way to go. It needs to be decided if this makes sense or whether we should change course. After that we would begin writing text for the VVSG 07 for approval by the TGDC.
There is support for this concept and realization that there will be much improvement. We need to figure out how much is specifiable and how much is implementable by VVSG 07. In December, we are going to propose formal adoption of ISO 9000 or the vendors be formally certified after a transition period to ISO 9000. Max's approach requires coordination with the other subcommittees, especially STS.
There are several things that can be accomplished near term. We should not only be looking at long-term goals.
Steve expressed concern that there has not been enough discussion on the deployment and implementation of COTS. There have been white papers addressing this issue. [John W: This requires EAC implement things differently.]
John W: We have to consider VVSG 07 as a major upgrade, a standard that will stand for 4 years. How far should we be going in our 2007 recommendations? NIST is addressing future voting systems, not looking at current systems.
Donetta: The subcommittee needs to provide guidance on how long this will take - two years, four years? We had originally set a 2 year window for manufacturers to meet, but looking ahead this is not a 2 year implementation time frame for core requirements. You have to design, build, and test. We need to think about is the negativity associated with the election process. Congress made a mistake with HAVA and the time requirements - requiring new machines by 2006 which weren't ready with new standards. People had an issue buying systems with 2002 standards that they felt were going to change right away. We're looking at the future election equipment and process.
Max's opinion is that, implementing his proposal, developing new systems in two years should not be a problem. What would cause a problem would be replacing current systems, this is a financial issue, but technologically this should not be a problem. [Group disagrees, we haven't discussed the local jurisdictions who have to buy them] We don't have to get rid of present machines - there is a lot we can do to make current systems as reliable as possible.
We are suggesting two types of requirements, one that can be used with existing software, and ones that cannot. There is a grandfather clause; we're not suggesting anyone throw away any machines.
It would be nice to know how long a system actually lasts, e.g., plastic deterioration, etc. to see how long an actual machine may be in use.
At the next teleconference, actual presentations for the December meeting should be available for comment. A suggestion was made to form a small task group to think about what we need to go into the meeting with, so we know what the TGDC needs to give guidance on. EAC and TGDC need to decide if we should go further than current systems. We do not want new guidelines every two years. Several vendors would like to start building on VVSG 07 guidelines instead of worrying about 05 ones that will change.
At the end of Max's report, together with the certification for quality management might also require certification for ISO 14,000 (environmental quality) which would be consistent and provide overall quality management for the manufacturers. Something we might expect of the machines - they conform to the standard that most new equipment today routinely conforms to - the energy star compliance.
When talking about implementation, in the certification arena, NVLAP will have to go back and reassess whether they can test to the new standard.
Next meeting will be November 30 at 11:00 a.m.
adjourned at 12:10 pm.
policy / security notice / accessibility statement