Actually the scheme I propose does not depend on pre-announcement of the list,
only providing a proof of registration.
I have not worked out exactly to avoid every attack but there is certainly no
need to publish everyone's email address - although it is odd that you would
mention that as the IETF is currently publishing my telephone number I gave
when registering for a previous IETF. Certainly every selected member of NOMCON
has to be reachable by email.
All you require is a unique identifier. It could be the participant's name. If
a person is registered twice and this is detected then you use the name that
occurs first in some cannonical ordering.
The registration mechanism could be a Web form that you fill in that causes a
receipt to be sent to the email address specified. That way a registrant has a
proof that they registered and can use that to challenge the list.
________________________________
From: Eastlake III Donald-LDE008
[mailto:Donald(_dot_)Eastlake(_at_)motorola(_dot_)com]
Sent: Saturday, September 02, 2006 6:39 PM
To: IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...
Depends what you mean by "it". The overall process may have broke in
this case but the "it" referred to in the message you were responding to is the
"cryptographic" part of the process. The one in RFC 3797 depends on
pre-announcement of the ordered list of volunteers. The one you suggested
depends on pre-announcement of the email address of every volunteer. Neither is
any more robust than the other against a failure to make all the information
necessary for public verification available in advance, including the
specification of the source of future randomness.
Donald
________________________________
From: Hallam-Baker, Phillip [mailto:pbaker(_at_)verisign(_dot_)com]
Sent: Saturday, September 02, 2006 10:00 AM
To: John C Klensin; Ned Freed; Eastlake III Donald-LDE008
Cc: IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...
If it ain't broke? How much more evidence of being broke do we need?
The bug here is that the process is insufficiently robust under
operator error.
That is broke.
The underlying problem here is the lack of auditability in the process.
There is a simple fix here, eliminate the dependency on the list
ordering and the system does not have such a critical dependence on the
operator.
Again nobody is claiming anything dishonest has happened here. The
concern is that the accident could be repeated on purpose in the future to
exclude undesirable candidates. Having spent part of last month watching this
attempted in Alabama it is a real concern.
When something is broke admit the fact. Prattling on about not fixing
what aint broke only makes people angry.
Sent from my GoodLink Wireless Handheld (www.good.com)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf