Re: Vendor Applies for Open Voting Consortium Certification -- OVC Press Release

From: Richard C. Johnson <dick_at_iwwco_dot_com>
Date: Fri Dec 01 2006 - 20:14:41 CST


I would like to return to discussion of some issues you touched on when you noted the Open Voting Solutions application for OVC certification. That is the matter of Open Hardware Design.

It seems to me that actual designs must be known for all hardware components, including chips used on all boards. This is simply because specifications, however detailed, have alternate implementations. The design, however, is precise and sufficient. The design can be sent to a contract manufacturer and be produced as a known device, and it can be checked against its (digital) designs.

With no proprietary software, no proprietary firmware, and no proprietary hardware, we will have the Open Voting System we want and need in our elections. IMHO.

-- Dick

Alan Dechert <> wrote: Re: [OVC-discuss] Vendor Applies for Open Voting Consortiu
Thanks to Arthur Keller, Joe Hall, Dick Johnson, and Ron Rivest for
commenting on our proposal to issue a service mark for OVC compliant
products. We'll talk more about this at our next board meeting -- which is
soon (this Friday, as I recall). I want to put something in place then so
we can proceed with the OVS OpenScan product. We should probably say up
front that we will be a little flexible since this is the first try at it so
we may want to add, subtract, or modify something. We'll try to be complete

The way I look at it, a lot of these issues are the same as for AB 2097.

We might say that the OVC Listed requirements are "AB 2097 compatible." It
will be as if AB 2097 was already the law. We're going to ask for pretty
much the same things that we wanted to have on the SoS web site according to
the bill. As you probably know, AB 2097 died (in May) in the Assembly
Appropriations committee shortly after a 5-0 victory (April 18, see for
details) in our only policy hearing (Elections Committee). AB 2097 will be
revised and get a new author and new number soon (December, I guess).

The new bill will, in effect, say that if a product is going to be certified
for use in CA elections, it will need meet the requirements for OVC listing.
We may or may not want to actually advertise that anywhere, but that's how I
want to think about it.

The strategy for our new bill will depend on a few things we expect to find
out within a few weeks -- like, who will be the next Secretary of State and
who will be the committee chairs in the senate and in the assembly. In any
case, our efforts to get products OVC Listed should run parallel and
reinforce our efforts to get our new bill passed. And don't forget parallel
efforts in other states, such as Maryland.

It might be instructive to look at how the Open Geospatial Consortium lists
OGC compliant products:

Ron asked, "where is the URL?" Of course, there is no URL yet but I take
that to mean Ron would like to see a URL where submissions could be made. I
think that's a good idea - make it cut-and-dried. We will get on that.
Matt? Chito?

To apply for "OVC Listed," everything should be in the form of electronic
files. So, we're asking for documents and software. This may include
things such as sound files, graphic files, video files, etc. I suppose the
format of these files could be an issue. As much as possible, we want files
in common formats. What if a vendor gives us a 900-page manual in
FrameMaker 6.0? We can probably deal with it.

Certainly, we want to post binaries as well as source, along with hash
values. Perhaps Ron could suggest what to use. Presumably, Ron would think
MD4 inadequate. MD5 okay?

As in AB 2097, the vendor would need to grant the right of voters to test
the software and publish findings. From SEC 2 (b) of the bill,

     (1) The voter's right to inspect and test the voting system, to
     retain test materials, test results, and to freely publish the same
     (2) A promise to refrain from exerting any copyright, trade
     secret, or other rights that it may have to hinder any voter of the
     state from exercising the rights under paragraph (1) of this

So, for example (Joe's question), VoteHere's license grant language is
problematic: "...personal, royalty-free, non-transferable,
non-sublicensable, revocable...." If they want to be OVC listed, this would
have to be loosened a bit.

I don't think we'd specify any particular licenses that we accept: I think
the submission process would include some language like, "by submitting
these documents to OVC, you are granting these rights to OVC and the public
...." [click here to grant these rights!] Then there would have to be some
dialogue saying this isn't official until OVC has verified that you are an
authorized officer. Once the application is authenticated, OVC would issue
an application number.

Here's what we put in AB 2097 about what would be made freely available, SEC
2, (d):

     (1) All voting system specific source code.
     (2) Detailed instructions for building the software, including
     compiler used, compilation scripts, and checksums.
     (3) Voting specific hardware, complete specifications,
     drawings and schematics.
     (4) General purpose COTS components described in detail,
     including versions and dates of manufacture.

This list was never complete and we were planning to expand before the final
amendment. It might be good to start working on expanding on this now.
We're not asking for source code for COTS components, but we should be more
specific about these dependencies. Maybe we should include hash values for
COTS software and firmware.

At one point, I think I did have a catch all phrase but it fell off the map
somehow. Something like what Ron said, [all] "other associated programs or
configuration files required to build and/or install the software." Maybe,
"...and run the software."

Definitely we'd want user manuals ("operational and instructional
documentation") for the voter, technician, election official, and auditor.
And, as Arthur indicated, we want documentation of data formats.

I agree with most everything Arthur wrote. However, I don't know that we
should fix a fee for it right now. We don't plan to charge OVS at this
point. Ideally, I think, we would use this as an OVC member benefit. If
ES&S wanted to apply for OVC listing, maybe we'd negotiate a charge. If
they planned to submit x number of products over the next year, we could
factor that into their annual corporate membership dues taking into account
membership level (Strategic, Principle, Technical, etc). We could throw up
some non-member fee for OVC listing application.

I'm also not sure about partial or full listing. I'm inclined to think it
should be that the product is OVC listed or it's not.

Ron asked,

     "May others submit comments / bug reports? Is there a standard
     procedure for handling discovered vulnerabilities?"

Here's what we said in AB 2097, SEC 2 (e):

     (2) A system for acquiring and processing input from the
     voting public.
     (3) A reporting system to inform the public on findings,
     problems reported, problem resolution, and comments from the
     Secretary of State, the public, and vendors.

This definitely needs some elaboration. Suppose we have a bug tracking
system on the OVC web site for this. Someone posts regarding OpenScan 1.0:

     I noticed that when there is a paper jam, the operator sees
     a message that says, "PAPER JAM. Please re-scam the ballot."

     Shouldn't that be "re-scan" instead of "re-scam?"

Dick Johnson then posts a response that says, "yes, thank you. That will be
corrected in OpenScan 1.1"

Here's what I was thinking for AB 2097, and I am thinking the same thing for
OVC Listed: Other than providing the mechanism for the tester and the
vendor to post these findings, OVC would do nothing. To be OVC Listed only
means that everything is open. It doesn't mean we've verified that
everything is working correctly. So, we would not check OpenScan 1.1 to see
if the correction had been made.

If the vendor then wants to be "OVC Tested," then we'd do things like check
OpenScan 1.1 to see if this problem was fixed. For OVC testing, we'd have
to do a lot more work so there would be fees involved. Unlike the current
system where the vendor simply pays the testing agency, we could defray fees
in a couple of ways.

1) Have government agencies paying dues in the higher level membership
categories (Strategic, Principle, and Technical).
2) For truly Open Source products, we could enlist the open source community
to help test. To a certain extent, the geeks of America (and the world)
will be less inclined to help test disclosed but proprietary systems. So, I
suspect this could serve as an incentive to publish voting system software
under a free license since testing costs would be lower. That's the theory,

There is a lot more to think about and do for "OVC Tested." I think we're
getting close to informing OVS what we will need from them so OpenScan can
be OVC Listed.

I appreciate Dick Johnson's comments very much. He sounds "open" to it all!

Alan D.

----- Original Message -----
From: Arthur Keller
To: Open Voting Consortium discussion list
Sent: Tuesday, October 17, 2006 12:16 AM
Subject: Re: [OVC-discuss] Vendor Applies for Open Voting Consortium
Certification -- OVC Press Release

Note that I did not suggest requiring "Open Source" but rather "Disclosed
Source." And I do think that hardware specs and designs should be disclosed
as well. I would also be willing to have hardware security mechanisms to be
redacted from the disclosure. The problem with allowing the redaction of
security measures from the software is that it would preclude the potential
for ensuring that the software object code matched the software source code.

OVC-discuss mailing list

OVC-discuss mailing list

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Dec 31 23:17:03 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 23:17:16 CST