[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [atlarge-discuss] online voting
Vittorio and all stakeholders or interested parties,
Vittorio Bertola wrote:
> On Thu, 16 May 2002 11:11:17 -0500, you wrote:
> >organization. You might accept PGP keys with only email verification,
> >you might accept them printed out and sent by normal mail, you might
> >accept keys that have been signed into the global web of trust. Each
> >approach offers a different degree of authenticity, and carries with it
> >a different degree of overhead.
> In fact, that's exactly what I am thinking of. The original ICANN
> proposal was to identify people by having them register a domain name
> and be listed on a WHOIS server - which was an unsecure method, costly
> for the user, and easily capturable by registries and registrars
> (though perhaps these were appreciable features for some of those who
> drafted that proposal).
Yes this was essentially the central part of the ALSC "Final Report"
which was resoundingly rejected for cause...
> My idea for what we are doing now (which, to make it clearer for
> people who are not involved directly, is building an independent
> verified membership roll for ICANN that can later be used to have
> elections for user representatives in the unlikely case that ICANN
> will accept this, see www.icannatlarge.com) is that we should employ a
> wide number of different authentication methods, not necessarily
> PGP-based (as the target is much less technical).
Many different authentication methods are available and some
are inter operable. We have a product that we market known
as the Interface facility. It is used predominantly for inter operability
of various security and authentication systems/methods to be used
in a compatible way.
> Surely using the
> official certification authorities as created by law in the US and EU
> and other countries would be fine, but that cannot be the only method,
> as certificates are costly, not yet spread enough, and we have a
> worldwide target (so we have to take developing countries into account
Certificates are not costly. Many Cert Authorities offer free or low
cost PKI another type CERTS for no cost at all. Most others are
quite cheap and can be obtained in some 128 different countries
via a download. The big problem with this is that a credit card
for the non-free certs is required. Many potential At-Large
members and/or existing At-Large members would not have
a credit card to use. Hence the At-Large would need to
become it's own Cert authority issue Certs to members...
> Having members introduce other members would be nice, though
> there have to be strict provisions to prevent frauds. Sending scanned
> images of official ID documents would be fine too, if we can prevent
> people from using Photoshop (er... ok, gimp or ImageMagick) to fake
Sending scanned documents would be a privacy concern for
many potential At-Large members and very specifically and
excessively expensive to adequately administer...
> Moreover, my idea is that we should decentralize this as much as
> possible: you lose in safety, but the system you build is much less
> subject to capture and single points of failure, and much less costly.
> So I would be quite happy to accept "Debian-certified individuals" in
> the membership, for example.
Agreed decentralization is the way to go. Surevote provides for this
> .oOo.oOo.oOo.oOo vb.
> Vittorio Bertola <firstname.lastname@example.org> Ph. +39 011 23381220
> Vitaminic [The Music Evolution] - Vice President for Technology
> DISCLAIMER, PLEASE NOTE: This communication is intended only for use by the
> addressee. It may contain confidential or privileged information.
> Transmission, distribution and/or copy cannot be permitted. Please notify
> immediately the sender by replying if you are not the intended recipient.
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
Jeffrey A. Williams
Spokesman for INEGroup - (Over 121k members/stakeholdes strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
Contact Number: 972-244-3801 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org