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

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Fri Dec 01 2006 - 20:25:55 CST

Dick, you are commenting on an old message of Alan's. Please comment
on the actual proposal:
http://gnosis.python-hosting.com/voting-project/November.2006/0153.html

Thanks.

Best regards,
Arthur

At 6:14 PM -0800 12/1/06, Richard C. Johnson wrote:
>Alan,
>
>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 <dechert@gmail.com> 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
>nonetheless.
>
>The way I look at it, a lot of these issues are the same as for AB 2097.
>
>http://www.leginfo.ca.gov/pub/bill/asm/ab_2051-2100/ab_2097_bill_20060504_amended_asm.pdf
>
>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
>http://www.openvotingconsortium.org/blog/2006-apr-26/no_opposition 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:
>http://www.opengeospatial.org/resource/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
>openly.
>(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
>subdivision.
>
>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,
>anyway.
>
>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@listman.sonic.net
>http://lists.sonic.net/mailman/listinfo/ovc-discuss
>
>
>
>_______________________________________________
>OVC-discuss mailing list
>OVC-discuss@listman.sonic.net
>http://lists.sonic.net/mailman/listinfo/ovc-discuss

-- 
-------------------------------------------------------------------------------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss

==================================================================
= 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