Re: Re: Re: Re:

From: laird popkin <lairdp_at_gmail_dot_com>
Date: Fri Apr 08 2005 - 16:57:42 CDT

I've always felt that the terminology "trusted person" is misleading,
because non-cryptographers read that as "someone they can trust",
which sounds good, while crypto people read it as "someone I am forced
to trust", which is bad because the "trusted person" can betray the
trust and break the system. In a good system, nobody is "trusted",
which means that the system doesn't rely on "trust" but on proof,
auditing, etc.

This is what makes the 'trusted computing initiative' such an amusing
name, since it (to a crypto person) basically says that your computer
is a black box that can betray you.

- LP

On Apr 8, 2005 5:46 PM, Ron Crane <voting@lastland.net> wrote:
> "Authorized" conveys the idea that a subject is allowed to operate on
> an object, but doesn't indicate that the object's proper operation is
> contingent upon the subject's honesty. Yet that's exactly what we need
> others to understand about existing voting systems.
>
> "Trusted person" and similar terms have a long history in security
> discourse. For example, Schneier's Applied Cryptography, in discussing
> arbitrated protocols (e.g. PGP for email), refers to "Trent", the
> "trusted arbitrator", saying, "Trusted means that all people involved
> in the protocol accept what he says as true, what he does as correct,
> and that he will complete his part of the protocol." p.23. Schneier
> then goes on to note the problem with trust: "Since everyone on the
> network must trust the arbitrator, he represents a vulnerable point for
> anyone trying to subvert the network." p.25.
>
> My definition implicitly conveys this point, but now I see it's not
> nearly explicit enough. think we should make it approach Schneier's
> more closely, e.g.:
>
> Trusted person/entity: A person or entity whose assertions we accept as
> true, and whose acts we accept as correct, for some purpose or set of
> purposes. This term does not imply that trust is warranted, only that a
> system's security or correctness is contingent upon a trusted person or
> entity exercising her or its powers truthfully and correctly. In the
> context of voting systems, a vendor may be a trusted entity, since,
> unless the system is subject to total public verification, we trust
> that the vendor has not incorporated a Trojan Horse into it. A person
> or entity may be trusted to perform one function (e.g. the creation of
> a ballot form) but remain untrusted for others (e.g. the modification
> of a voting system's software).
>
> Please comment and help me tighten this.
>
> All that said, if "trusted person" is truly a roadblock to agreement on
> the submission, we should cut it. My primary goal is to get "Trojan
> Horse" and "Security Analysis" into the lexicon, so as to dispel the
> notion that subversion of voting machines can't happen or is something
> that only "moonbats" worry about.
>
> -Ron
>
> On Apr 8, 2005, at 1:46 PM, Arthur Keller wrote:
>
> > Maybe the word "authorized" should be used instead of "trusted."
> >
> > Best regards,
> > Arthur
> >
> > At 11:10 AM -0700 4/8/05, Alan Dechert wrote:
> >> Joe Hall wrote:
> >>>
> >>> +1 on keeping these definitions.
> >>>
> >>> From a theoretical perspective, it makes sense to model the larger
> >>> elections system as having "trusted" subsystems or agents, and then
> >>> discuss what happens when the trust is compromised. To this extent,
> >>> it
> >>> is nice to have a definition of trusted and untrusted agents in the
> >>> system. Vendors (such as the OVC) are free to design their systems
> >>> relying on trusted parties... as well as designing their systems
> >>> with
> >>> no reliance on trust whatsoever.
> >>>
> >>> Maybe there is a better word than "trust"... essentially, we're
> >>> trying
> >>> to define what kind of access a person has based on their official
> >>> capacity, right? We could instead use a term that approached
> >>> something like permissions... like "restricted access" or
> >>> "privileged
> >>> access". Any other ideas out there?
> >>>
> >> This makes some sense. However, I still don't like Trusted/Untrused
> >> persons. What you're bringing up here fits with something about
> >> access
> >> rights. This will not be a black/white trusted/untrusted situation.
> >> For
> >> example, the registration database needs to be used by many people,
> >> but
> >> trusted/untrusted is not the relevant concept. Some people need
> >> edit/add
> >> privledges. Some people need to have lookup privledges. Some people
> >> need
> >> to receive reports from the database. Under certain circumstances,
> >> organizations may receive electronic versions of the voter file,
> >> which may
> >> exclude certain information (like ssn or driver's license no).
> >>
> >> In any case, we do not "trust" people with these access rights. These
> >> various access privledges are [should be] given in accordance with
> >> institutional protocols that are published. The ID of any person
> >> editing
> >> the voter file needs to be stored in the database. Trust is the
> >> wrong word.
> >> People are given responsibilities to perform operations -- who does
> >> what
> >> should always be tracked.
> >>
> >> Alan D.
> >
> >
> > --
> > -----------------------------------------------------------------------
> > --------
> > 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 lists
> Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
>
>

-- 
- Laird Popkin, cell: 917/453-0700
_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Sat Apr 30 23:17:04 2005

This archive was generated by hypermail 2.1.8 : Sat Apr 30 2005 - 23:17:22 CDT