[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ga] Registration process suggestion



This has been a fascinating thread to read.  Pretty much everything people 
have been saying sounds correct and reasonable.  The only problem is that 
it is irrelevant to any near-term GA activity, since the technical 
solutions being proposed are not viable.

As noted, the spoofing problem is theoretically amenable to a localized 
technical solution.  The GA provides its own cert authority for just (and 
only) this use. Typical objections to use of CAs do not apply in this case, 
because the activity is sufficiently small scale and small scope.  (Not too 
many participants, and the certs are used in a very constrained way.)

The problem of ballot-stuffing by creation of multiple persona can only be 
solved by something that constrains the creation of those persona.  In the 
current environment, a persona is defined by an email address and, as we've 
seen, some people DO multiply themselves by getting any number of email 
addresses.

Although the formal cert developers understand the issue of certs needing 
to be defined carefully, so that different criteria are applied in 
assigning different kinds of certs, there is no large scale use of certs as 
a basis for distinguishing individuals.

For that matter, there is no large scale use of certs.

For that matter, there is no large scale use of open, encrypton-based 
authentication services.

And that's the problem.  All of this technology-iriented discussion, for 
solving the registration problem, is being conducted without attending to 
the raw fact that the technology has not already been deployed and used on 
very wide scale.  Hence considering it here is pursuit of a legal/technical 
experiement in an environment that is quite awful for experimentation.

PGP advocates might disagree about large scale authentication activities, 
but that is an example of the problem, rather than a counter to it.  Both 
PGP and S/Mime are still human factors problems for average users.

I'd love to offer a viable solution, but at this point only a human in the 
loop seems feasible.

d/

=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Gong Xi Fa Cai   /  Selamat Tahun Baru Cina

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html