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

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Tue Oct 17 2006 - 02:16:20 CDT

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.

At 2:33 PM -0700 10/16/06, Richard C. Johnson wrote:
>I like Joe's comments, esp. the question of "all" components of a
>system having to be available as Open Source. There is yet another
>variation, now being explored in New York: source code for all
>components in a voting system must be archived in a place accessible
>to the State Board of Elections. Not Open Source...but the kiss of
>death for MS Windows none the less. My own preference is very
>strong for Open Source for the OS, since something like CE can be
>modified by the "Microsoft Partner."
>
>Of course, NY now also requires $260,000 cash up front to defray
>state expenses. This will lock out startups and smaller company
>vendors; then, with no more vendors remaining, the state will likely
>fold this requirement for acess to source and just take the ready
>money from Diebold et all; these latter will raise their prices to
>cover the expense, of course.
>
>I think that operating systems, configuration files, setups, and
>installations--and security measures, authentication, and
>authorization are all necessarily Open. I would want an Open
>operating system even before an Open database. IMHO.
>
>Also, I think we need more thought on the Open Hardware question, as
>well as the OpenITA or OpenTest question. That will get the pot
>boiling...
>
>Regards,
>
>-- Dick
>
>Joseph Hall <joehall@gmail.com> wrote:
>
>a few comments offered with the purpose of getting the juices flowing:
>
>On 10/15/06, Arthur Keller wrote:
>> Here is my personal thinking about what OVC certification might mean.
>> This message does not represent the position of the OVC Board, which
>> will take up these issues at the next Board meeting.
>>
>> OVC certified is separated out into "OVC LIsted" and "OVC Tested"
>>
>> "OVC Listed" would say that the source, documentation, license, etc.,
>> are publicly disclosed. The public disclosure of the source,
>> documentation, license, etc., would be on our website. We need to
>> come up with a checklist of the items that need to be disclosed. We
>> would then provide a listing ID that one could look up on our website
>> to have access to the publicly disclosed information.
>>
>> My immediate list is:
>>
>> License for the system (which must allow others also to publish the
>> software, anyone to test and experiment and analyze, including
>> publication of analysis including excerpts of source code)
>> Listing of components of system (e.g., electronic ballot printer,
>> ballot reconciliation system, ballot verification system)
>
>Would this include things like VoteHere which has a "for evaluation
>purposes only" license:
>http://www.votehere.net/VoteHere_Source_Code_License_2.htm

I haven't studied this particular license, but my proposal is to
require the ability to republish the software on other websites and
the ability to do analyses, tests, and experiments (even if those
required derivative works, such as inserting debugging and tracing
code).

>It would also be good to list a bunch of popular or known Open Source
>licenses and state whether or not they meet the criteria (and why not,
>if not).
>
>> Full source code for each component of system
>
>Would systems that run on Windows be excluded? That is, does just the
>voting application have to be disclosed (or "public") or is it all of
>the system... including any third party software?

Yeah, see below about COTS.

> > Object code image for each component of system
>
>Doesnt' the image depend on the architecture? If there are multiple
>architectures, that mean multiple images, right? (I just don't know
>the answer to this, being only somewhat technical.)

It is my understanding that the existing voting system certification
process involves a particular hardware configuration with a
particular software configuration. Please correct me if that is
wrong. My intent is to require the object code image for each and
every configuration of hardware with a distinct object code image,
for any hardware configurations on which the vendor wishes the system
to operate. In particular, the disclosure should indicate which
object code images go with which hardware configurations.

> > Checksum of object code image for each component of system
>
>What kinds of checksums... CRCs? (Seems bad) MD5, SHA-1, SHA-256,
>tiger, whirlpool? A combination of the above to hedge against the
>future?

We can specify whatever checksums are desired. The list of checksums
can change over time to require new forms of checksum on new
listings. Note that given the object code images, it is possible for
the OVC to generate whatever checksums it wants. My intent here is
specifically to publish some checksums that could easily be checked,
either to help ensure that the OVC repository was not corrupted
(since the checksums are easy to cache) or to help ensure that the
actual software running on the requisite hardware was not corrupted.
If there is a hardware or software checksum process implemented, then
the checksums published should include the checksum(s) used by the
hardware or software checksum process(es).

> > Documentation
>> Internal and external document formats and sample documents
>> Specifications
>
>Does this include hardware schematics? What kind of licenses (open
>hardware, etc.) would be permissable for this?

I'm going for disclosure here, not derivative works.

> > Feature checklist (e.g., paper ballot vs. electronic ballot with
>> paper audit trail; basic architectural type)
>> OVC listed registry number and date (which would be assigned by OVC)
>>
>> Note that I would not require the rights to make derivative works or
>> derivative systems (other than as part of analyses, tests, or
>> experiments), and the rights to use the system for elections would
>> not be required to be granted as part of obtaining an OVC listing.
>
>This seems wise. I think "testing purposes" would include derivative
>works but for a specific purpose (although, of course, deriv. works
>are the stickiest and most opaque parts of copyright law)... that is,
>recompilation with debugging flags set creates a work based on the
>source code that is different from the distributed and as-implemented
>binary (the image above).

Exactly. And that's reiterated in my point above.

> > There would be a fee for listing that would cover costs of checking
>> completeness and publishing the data in permanent registry and for
>> developing and maintaining the feature checklist. My suggestion is
>> $1000 per listing. Each version is a separate listing. For OVC
>> listed, we do not certify anything about the system other than the
>> fact that what we publish is exactly what the vendor provided. We
>> should require that the vendor attest that the label "OVC Listed"
>> must always be accompanied by the listing number(s) and date(s) for
>> specific versions mentioned, and that the system for those versions
>> always exactly match that which was submitted for listing. The
>> vendor should also attest that all the information provided is true
> > and complete and applies to the same consistent and complete version.

It looks like such a fee is small in comparison to NY's fees. An
alternative is to give free listings to OVC Strategic Members (or
some other suitable categories of membership) and only to those
members, to encourage membership.

> > It is my intent that if an existing vendor wished to make their
>> system OVC listed by disclosing what we require, then we would allow
>> that. We should therefore indicate the potential for a COTS
>> exception and describe what can be COTS. The listing would be a
> > qualified listing "OVC listed, except for the non-disclosed COTS
>> elements x, y, and z"
>
>Ah, didn't read this far... there would seem to be an important
>distinction in here that we should all think through. For example,
>third-party code that directly participates with the voting
>application in the election events should probably be different than
>lower-level stuff like the OS and such. However, even the low-level
>stuff could be problematic (Hursi II, etc.). So maybe there should be
>a different thing for those systems... like "Components OVC Listed".
>(I'm having trouble thinking up something better... and maybe the
>qualifier that it's not completely listed is enough... Howabout,
>something added to complete OVC products to distinguish them like
>"Fully OVC Listed".

I think it's important for the qualification to specifically state
what isn't disclosed. Maybe "Partially OVC Listed; does not disclose
the COTS elements x, y, and z."

>best, Joe

Thanks for the feedback, Joe.

Best regards,
Arthur

> > "OVC Tested" would say that the system has undergone various tests.
>> I think we'll have to study exactly what that means.
>>
>> Best regards,
> > Arthur

-- 
-------------------------------------------------------------------------------
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 Tue Oct 31 23:17:05 2006

This archive was generated by hypermail 2.1.8 : Tue Oct 31 2006 - 23:17:10 CST