summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2777.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2777.txt')
-rw-r--r--doc/rfc/rfc2777.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc2777.txt b/doc/rfc/rfc2777.txt
new file mode 100644
index 0000000..3ddf9e7
--- /dev/null
+++ b/doc/rfc/rfc2777.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group D. Eastlake 3rd
+Request for Comments: 2777 Motorola
+Category: Informational February 2000
+
+
+ Publicly Verifiable Nomcom Random Selection
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document describes a method for making random selections in such
+ a way that the unbiased nature of the choice is publicly verifiable.
+ As an example, the selection of the voting members of the IETF
+ Nominations Committee from the pool of eligible volunteers is used.
+ Similar techniques would be applicable to other cases.
+
+Acknowledgement
+
+ Matt Crawford made major contributions to this document.
+
+Table of Contents
+
+ 1. Introduction............................................2
+ 2. General Flow of a Publicly Verifiable Process...........2
+ 2.1 Determination of the Pool..............................2
+ 2.2 Publication of the Algorithm...........................2
+ 2.3 Publication of Selection...............................3
+ 3. Randomness..............................................3
+ 3.1 Sources of Randomness..................................3
+ 3.2 Skew...................................................4
+ 3.3 Entropy Needed.........................................4
+ 4. A Suggested Precise Algorithm...........................5
+ 5. Fully Worked Example....................................6
+ 6. Security Considerations.................................7
+ 7. Reference Code.........................................8
+ Appendix: History of NomCom Member Selection..............14
+ References................................................15
+ Author's Address..........................................15
+ Full Copyright Statement..................................16
+
+
+
+Eastlake Informational [Page 1]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+1. Introduction
+
+ Under the IETF rules, each year 10 persons are randomly selected from
+ among the eligible persons who volunteer to be the voting members of
+ the nominations committee (NomCom) to nominate members of the
+ Internet Engineering Steering Group (IESG) and the Internet
+ Architecture Board (IAB) [RFC 2727]. The number of eligible
+ volunteers in recent years has varied in the approximate range of 40
+ to 60.
+
+ It is highly desireable that the random selection of the voting
+ NomCom be done in a unimpeachable fashion so that no reasonable
+ charges of bias or favoritism can be brought. This is for the
+ protection of the IETF from bias and protection of the administrator
+ of the selection (currently, the appointed non-voting NomCom chair)
+ from suspicion of bias.
+
+ A method such that public information will enable any person to
+ verify the randomness of the selection meets this criterion. This
+ document gives an example of such a method.
+
+2. General Flow of a Publicly Verifiable Process
+
+ In general, a selection of NomCom members publicly verifiable as
+ unbiased or similar selection could follow the three steps given
+ below.
+
+2.1 Determination of the Pool
+
+ First, you need to determine the pool from which the selection is to
+ be made.
+
+ Volunteers are solicited by the appointed (non-voting) NomCom chair.
+ Their names are then passed through the IETF Secretariat to check
+ eligibility. (Current eligibility criteria relate to IETF meeting
+ attendance, records of which are maintained by the Secretariat.) The
+ full list of eligible volunteers is made public early enough that
+ there is a reasonable time to resolve any disputes as to who should
+ be in the pool, probably a week to ten days before the selection.
+
+2.2 Publication of the Algorithm
+
+ The exact algorithm to be used, including the public future sources
+ of randomness, is made public. For example, the members of the final
+ list of eligible volunteers are ordered by publicly numbering them,
+ several public future sources of randomness such as government run
+
+
+
+
+
+Eastlake Informational [Page 2]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ lotteries are specified, and an exact algorithm is specified whereby
+ eligible volunteers are selected based on a strong hash function [RFC
+ 1750] of these future sources of randomness.
+
+2.3 Publication of Selection
+
+ When the prespecified sources of randomness produce their output,
+ those values plus a summary of the execution of the algorithm for
+ selection should be announced so that anyone can verify that the
+ correct randomness source values were used and the algorithm properly
+ executed. A cut off time for any complaint that the algorithm was
+ run with the wrong inputs or not faithfully executed should be
+ specified to finalize the output and provide a stable NomCom.
+
+3. Randomness
+
+ The crux of the unbiased nature of the selection is that it is based
+ exactly on random information which will be revealed in the future
+ and thus can not be known to the person specifying the algorithm by
+ which that random information will be used to select the NomCom
+ members. The random information must be such that it will be
+ publicly revealed in a timely fashion.
+
+ The random sources should not include anything that any reasonable
+ person would believe to be under the control or influence of the IETF
+ or its components, such as IETF meeting attendance statistics,
+ numbers of documents issued, or the like.
+
+3.1 Sources of Randomness
+
+ Examples of good information to use are lottery winning numbers for
+ specified runnings of specified lotteries. Particularly for
+ government run lotteries, great care is usually taken to see that
+ they produce random quantities. Even in the unlikely case one were
+ to have been rigged, it would almost certainly be in connection with
+ winning money in the lottery, not in connection with IETF use.
+
+ Other possibilities are such things as the closing price of a stock
+ on a particular day, daily balance in the US Treasury on a specified
+ day, the volume of trading on the New York Stock exchange on a
+ specified day, etc. (However, the reference code given below will not
+ handle integers that are too large.) Sporting events can be used but
+ only with care to specify exactly what quantities are being presumed
+ random and what will be done if they are cancelled or delayed.
+
+ It is important that the last source of randomness, chronologically,
+ produce a substantial amount of the entropy needed. If most of the
+ randomness has come from the earlier of the specified sources, and
+
+
+
+Eastlake Informational [Page 3]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ someone has even limited influence on the final source, they might do
+ an exhaustive analysis and exert such influence so as to bias the
+ selection in the direction they wanted. Thus it is best for the last
+ source to be an especially strong and unbiased source of a large
+ amount of randomness such as a government run lottery.
+
+ It is best not to use too many different sources. Every additional
+ source increases the probability that it might be delayed or
+ cancelled calling into play contingency plans or, worst of all,
+ possibly creating a situation that was not anticipated. This would
+ either require arbitrary judgement by the Nomcom chair, defeating the
+ randomness of the selection, or a re-run with a new set of sources,
+ causing much delay. Probably a good number of sources is three.
+
+3.2 Skew
+
+ Many of the sources of randomness suggested above produce data which
+ is not uniformly distributed. This is certainly true of stock prices
+ and horse race results, for example. However, use of a strong mixing
+ function [RFC 1750] will extract the available entropy and produce a
+ hash value whose bits, remainder modulo a small divisor, etc., are
+ uniformly distributed.
+
+3.3 Entropy Needed
+
+ What we are doing is selection N items without replacement from a
+ population of P items. The number of different ways to do this is as
+ follows, where "!" represents the factorial function:
+
+ P!
+ -------------
+ N! * (P - N)!
+
+ To do this in a completely random fashion requires as many random
+ bits as the logarithm base 2 of that quantity. Some sample
+ calculated approximate number of random bits for the selection of 10
+ nomcom members from various pool sizes is given below:
+
+ Random Selection of Ten Items From Pool
+
+ Pool size 20 25 30 35 40 50 60 75 100
+ Bits needed 18 22 25 28 30 34 37 40 44
+
+ Using an inadequate number of bits means that not all of the possible
+ selections would be available. For a substantially inadequate amount
+ of entropy, there would be substantial correlations between the
+ selection of two members of the pool, for example. However, as a
+ practical matter, for pool sizes likely to be encountered in IETF
+
+
+
+Eastlake Informational [Page 4]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ nomcom membership selection, 40 bits of entropy should always be
+ adequate. Even if there is a large pool and theoretically more bits
+ are needed for complete randomness, 40 bits of entropy will assure
+ that the probability of selection of each pool member differs from
+ that of other pool members, the correlation between the selection of
+ any pair of pool members, etc., differs only insignificantly from
+ that for completely random selection.
+
+ An MD5 [RFC 1321] hash has 128 bits and therefore can produce no more
+ than that number of bits of entropy. However, this is three times
+ what is likely to ever been needed for IETF nomcom membership
+ selection.
+
+4. A Suggested Precise Algorithm
+
+ It is important that a precise algorithm be given for mixing the
+ random sources specified and making the selection based thereon.
+ Sources suggested above each produce either a single positive number
+ (i.e., closing price for a stock) or a small set of positive numbers
+ (many lotteries provide 6 numbers in the range of 1 through 40 or the
+ like, a sporting event could produce the scores of two teams, etc.).
+ A sample precise algorithm is as follows:
+
+ For each source producing multiple numeric values, represent each as
+ a decimal number terminated by a period (or with a period separating
+ the whole from the fractional part) and without leading zeroes
+ (except for a single leading zero if the integer part is zero) or
+ trailing zeroes after the period. Order them from smallest to the
+ largest and concatenate them and follow the results by a "/". For
+ each source producing a single number, simply represent it as above
+ with a trailing "/". At this point you have a string for each
+ source, say s1/, s2/, ... Concatenate these strings in a pre-
+ specified order and represent each character as its ASCII code
+ producing s1/s2/.../.
+
+ You can then produce a sequence of random values derived from a
+ strong mixing of these sources by calculating the MD5 hash [RFC 1321]
+ of this string prefixed and suffixed with a zero byte for the first
+ value, the string prefixed and suffixed by a 0x01 byte for the second
+ value, etc. Treat each of these derived random values as a positive
+ multiprecision integer. If there are P eligible volunteers, select
+ the first voting member by dividing the first derived random value by
+ P and using the remainder plus one as the position of the selectee in
+ the ordered list or volunteers. Select the second voting member by
+ dividing the second derived random value by P-1 and using the
+ remainder plus one as the position of the selectee in the list with
+ the first selectee eliminated. Etc.
+
+
+
+
+Eastlake Informational [Page 5]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ It is recommended that alphanumeric random sources be avoided due to
+ the greater difficulty in canonicalizing them in an independently
+ repeatable fashion; however, if any are used, all white space,
+ punctuation, and special characters should be removed and all letters
+ set to upper case. This will leave only an unbroken sequence of
+ letters A-Z and digits 0-9 which can be treated as a canonicalized
+ number above and suffixed with a "/".
+
+5. Fully Worked Example
+
+ Assume the following ordered list of 25 eligible volunteers is
+ published in advance of selection:
+
+ 1. John 11. Pollyanna 21. Pride
+ 2. Mary 12. Pendragon 22. Sloth
+ 3. Bashful 13. Pandora 23. Envy
+ 4. Dopey 14. Faith 24. Anger
+ 5. Sleepy 15. Hope 25. Kasczynski
+ 6. Grouchy 16. Charity
+ 7. Doc 17. Love
+ 8. Sneazy 18. Longsuffering
+ 9. Handsome 19. Chastity
+ 10. Cassandra 20. Smith
+
+ Assume the following (fake example) ordered list of randomness
+ sources:
+
+ 1. The People's Democracy of Betastani State Lottery six winning
+ numbers (ignoring the seventh "extra" number) for 1 October 1998.
+ 2. Numbers of the winning horses at Hialeia for all races for the
+ first day on or after x September 1998 on which at least two
+ races are run.
+ 3. The Republic of Alphaland State Lottery daily number for 1
+ October 1998 treated as a single four digit integer.
+ 4. Closing price of Example Corporation stock on the Lunar Stock
+ Exchange for the first business day after x September 1998 when
+ it trades.
+
+ Randomness publicly produced:
+
+ Source 1: 9, 18, 26, 34, 41, 45
+ Source 2: 2, 5, 12, 8, 10
+ Source 3: 9319
+ Source 4: 13 11/16
+
+ Resulting key string:
+
+ 9.18.26.34.41.45./2.5.8.10.12./9319./13.6875/
+
+
+
+Eastlake Informational [Page 6]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ The table below gives the hex of the MD5 of the above key string
+ bracketed with a byte whose value is successively 0x00, 0x01, 0x02,
+ through 0x09. The divisor for the number size of the remaining pool
+ at each stage is given and the index of the selectee as per the
+ original number of those in the pool.
+
+ index hex value of MD5 div selected
+ 1 746612D0A75D2A2A39C0A957CF825F8D 25 -> 12 <-
+ 2 95E31A4429ED5AAF7377A15A8E10CD9D 24 -> 6 <-
+ 3 AFB2B3FD30E82AD6DC35B4D2F1CFC77A 23 -> 8 <-
+ 4 06821016C2A2EA14A6452F4A769ED1CC 22 -> 3 <-
+ 5 94DA30E11CA7F9D05C66D0FD3C75D6F7 21 -> 2 <-
+ 6 2FAE3964D5B1DEDD33FDA80F4B8EF45E 20 -> 24 <-
+ 7 F1E7AB6753A773EFE46393515FDA8AF8 19 -> 11 <-
+ 8 700B81738E07DECB4470879BEC6E0286 18 -> 19 <-
+ 9 1F23F8F8F8E5638A29D332BC418E0689 17 -> 15 <-
+ 10 61A789BA86BF412B550A5A05E821E0ED 16 -> 22 <-
+
+ Resulting selection, in order selected:
+
+ 1. Pendragon (12) 6. Anger (24)
+ 2. Grouchy (6) 7. Pollyanna (11)
+ 3. Sneazy (8) 8. Chastity (19)
+ 4. Bashful (3) 9. Hope (15)
+ 5. Mary (2) 10. Sloth (22)
+
+6. Security Considerations
+
+ Careful choice of should be made of randomness inputs so that there
+ is no reasonable suspicion that they are under the control of the
+ administrator. Guidelines given above to use a small number of
+ inputs with a substantial amount of entropy from the last shoud be
+ followed. And equal care needs to be given that the algorithm
+ selected is faithfully executed with the designated inputs values.
+ Publication of the results and a week or so window for the community
+ of interest to duplicate the calculations should give a reasonable
+ assurance against implementation tampering.
+
+ To maintain the unpredictable character of selections, should a
+ member of the nomcom need to be replaced due to death, resignation,
+ expulsion, etc., new publicly announced future random sources should
+ be used for the selection of their replacement.
+
+
+
+
+
+
+
+
+
+Eastlake Informational [Page 7]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+7. Reference Code
+
+ This code makes use of the MD5 reference code from [RFC 1321] ("RSA
+ Data Security, Inc. MD5 Message-Digest Algorithm"). The portion of
+ the code dealing with multiple floating point numbers was written by
+ Matt Crawford.
+
+ /****************************************************************
+ *
+ * Reference code for
+ * "Publicly Verifiable Nomcom Random Selection"
+ * Donald E. Eastlake 3rd
+ *
+ ****************************************************************/
+ #include <limits.h>
+ #include <math.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <string.h>
+
+ #include "global.h"
+ #include "MD5.h"
+
+ /* local prototypes */
+ int longremainder ( unsigned char divisor,
+ unsigned char dividend[16] );
+ int getinteger ( char *string );
+ double NPentropy ( int N, int P );
+
+
+ /* limited to 16 inputs of up to sixteen integers each */
+ /****************************************************************/
+
+ main ()
+ {
+ int i, j, k, k2, err, keysize, pool, selection;
+ unsigned char unch, uc16[16], remaining, *selected;
+ long int temp, array[16];
+ MD5_CTX ctx;
+ char buffer[257], key [800], sarray[16][256];
+
+ pool = getinteger ( "Type size of pool:\n" );
+ if ( pool > 255 )
+
+ {
+ printf ( "Pool too big.\n" );
+ exit ( 1 );
+ }
+
+
+
+Eastlake Informational [Page 8]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ selected = (unsigned char *) malloc ( pool );
+ if ( !selected )
+ {
+ printf ( "Out of memory.\n" );
+ exit ( 1 );
+ }
+ selection = getinteger ( "Type number of items to be selected:\n" );
+ if ( selection > pool )
+ {
+ printf ( "Pool too small.\n" );
+ exit ( 1 );
+ }
+ if ( selection == pool )
+ {
+ printf ( "All of the pool is selected.\n" );
+ exit ( 0 );
+ }
+ err = printf ( "Approximately %.1f bits of entropy needed.\n",
+ NPentropy ( selection, pool ) + 0.1 );
+ if ( err <= 0 ) exit ( 1 );
+ for ( i = 0, keysize = 0; i < 16; ++i )
+ {
+ if ( keysize > 500 )
+ {
+ printf ( "Too much input.\n" );
+ exit ( 1 );
+ }
+ /* get the "random" inputs. echo back to user so the user may
+ be able to tell if truncation or other glitches occur. */
+ err = printf (
+ "\nType #%d randomness or 'end' followed by new line.\n"
+ "Up to 16 integers or the word 'float' followed by up\n"
+ "to 16 x.y format reals.\n", i+1 );
+ if ( err <= 0 ) exit ( 1 );
+ gets ( buffer );
+ j = sscanf ( buffer,
+ "%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld",
+ &array[0], &array[1], &array[2], &array[3],
+ &array[4], &array[5], &array[6], &array[7],
+ &array[8], &array[9], &array[10], &array[11],
+ &array[12], &array[13], &array[14], &array[15] );
+ if ( j == EOF )
+ exit ( j );
+ if ( !j )
+ if ( buffer[0] == 'e' )
+ break;
+
+ else
+
+
+
+Eastlake Informational [Page 9]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ { /* floating point code by Matt Crawford */
+ j = sscanf ( buffer,
+ "float %ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
+ "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
+ "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]"
+ "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]",
+ &array[0], sarray[0], &array[1], sarray[1],
+ &array[2], sarray[2], &array[3], sarray[3],
+ &array[4], sarray[4], &array[5], sarray[5],
+ &array[6], sarray[6], &array[7], sarray[7],
+ &array[8], sarray[8], &array[9], sarray[9],
+ &array[10], sarray[10], &array[11], sarray[11],
+ &array[12], sarray[12], &array[13], sarray[13],
+ &array[14], sarray[14], &array[15], sarray[15] );
+ if ( j == 0 || j & 1 )
+ printf ( "Bad format." );
+ else {
+ for ( k = 0, j /= 2; k < j; k++ )
+ {
+ /* strip trailing zeros */
+ for ( k2=strlen(sarray[k]); sarray[k][--k2]=='0';)
+ sarray[k][k2] = '\0';
+ err = printf ( "%ld.%s\n", array[k], sarray[k] );
+ if ( err <= 0 ) exit ( 1 );
+ keysize += sprintf ( &key[keysize], "%ld.%s",
+ array[k], sarray[k] );
+ }
+ keysize += sprintf ( &key[keysize], "/" );
+ }
+ }
+ else
+ { /* sort values, not a very efficient algorithm */
+ for ( k2 = 0; k2 < j - 1; ++k2 )
+ for ( k = 0; k < j - 1; ++k )
+ if ( array[k] > array[k+1] )
+ {
+ temp = array[k];
+ array[k] = array[k+1];
+ array[k+1] = temp;
+ }
+ for ( k = 0; k < j; ++k )
+ { /* print for user check */
+ err = printf ( "%ld ", array[k] );
+ if ( err <= 0 ) exit ( 1 );
+ keysize += sprintf ( &key[keysize], "%ld.", array[k] );
+ }
+ keysize += sprintf ( &key[keysize], "/" );
+ }
+
+
+
+Eastlake Informational [Page 10]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ } /* end for i */
+
+ /* have obtained all the input, now produce the output */
+ err = printf ( "Key is:\n %s\n", key );
+ if ( err <= 0 ) exit ( 1 );
+ for ( i = 0; i < pool; ++i )
+ selected [i] = i + 1;
+ printf ( "index hex value of MD5 div selected\n" );
+ for ( unch = 0, remaining = pool;
+ unch < selection;
+ ++unch, --remaining )
+ {
+ MD5Init ( &ctx );
+ MD5Update ( &ctx, &unch, 1 );
+ MD5Update ( &ctx, (unsigned char *)key, keysize );
+ MD5Update ( &ctx, &unch, 1 );
+ MD5Final ( uc16, &ctx );
+ k = longremainder ( remaining, uc16 );
+ /* printf ( "Remaining = %d, remainder = %d.\n", remaining, k ); */
+ for ( j = 0; j < pool; ++j )
+ if ( selected[j] )
+ if ( --k < 0 )
+ {
+ printf ( "%2d "
+ "%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X "
+ "%2d -> %2d <-\n",
+ unch+1, uc16[0],uc16[1],uc16[2],uc16[3],uc16[4],uc16[5],uc16[6],
+ uc16[7],uc16[8],uc16[9],uc16[10],uc16[11],uc16[12],uc16[13],uc16[14],
+ uc16[15], remaining, selected[j] );
+ selected[j] = 0;
+ break;
+ }
+ }
+ printf ( "\nDone, type any character to exit.\n" );
+ getchar ();
+ return 0;
+ }
+
+ /* prompt for an integer input */
+ /****************************************************************/
+ int getinteger ( char *string )
+ {
+ int i, j;
+ char tin[257];
+
+ while ( 1 )
+ {
+ printf ( string );
+
+
+
+Eastlake Informational [Page 11]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ printf ( "(or 'exit' to exit) " );
+ gets ( tin );
+ j = sscanf ( tin, "%d", &i );
+ if ( ( j == EOF )
+
+ || ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) )
+ )
+ exit ( j );
+ if ( j == 1 )
+ return i;
+ } /* end while */
+ }
+
+ /* get remainder of dividing a 16 byte unsigned int
+ by a small positive number */
+ /****************************************************************/
+ int longremainder ( unsigned char divisor,
+ unsigned char dividend[16] )
+ {
+ int i;
+ long int kruft;
+
+ if ( !divisor )
+ return -1;
+ for ( i = 0, kruft = 0; i < 16; ++i )
+ {
+ kruft = ( kruft << 8 ) + dividend[i];
+ kruft %= divisor;
+ }
+ return kruft;
+ } /* end longremainder */
+
+ /* calculate how many bits of entropy it takes to select N from P */
+ /****************************************************************/
+ /* P!
+ log ( ----------------- )
+ 2 N! * ( P - N )!
+ */
+
+ double NPentropy ( int N, int P )
+ {
+ int i;
+ double result = 0.0;
+
+ if ( ( N < 1 ) /* not selecting anything? */
+ || ( N >= P ) /* selecting all of pool or more? */
+ )
+ return 1.0; /* degenerate case */
+
+
+
+Eastlake Informational [Page 12]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+ for ( i = P; i > ( P - N ); --i )
+ result += log ( i );
+ for ( i = N; i > 1; --i )
+ result -= log ( i );
+ /* divide by [ log (base e) of 2 ] to convert to bits */
+ result /= 0.69315;
+
+ return result;
+ } /* end NPentropy */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake Informational [Page 13]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+Appendix: History of NomCom Member Selection
+
+ For reference purposes, here is a list of the IETF Nominations
+ Committee member selection techniques and chairs so far:
+
+ YEAR CHAIR SELECTION METHOD
+
+ 1993/1994 Jeff Case Clergy
+ 1994/1995 Fred Baker Clergy
+ 1995/1996 Guy Almes Clergy
+ 1996/1997 Geoff Huston Spouse
+ 1997/1998 Mike St.Johns Algorithm
+ 1998/1999 Donald Eastlake 3rd This Algorithm
+ 1999/2000 Avri Doria This Alogrithm
+
+ Clergy = Names were written on pieces of paper, placed in a
+ receptacle, and a member of the clergy picked the Nomcom members.
+
+ Spouse = Same as Clergy except chair's spouse made the selection.
+
+ Algorithm = Algorithmic selection based on the same concepts as
+ documented herein.
+
+ This Algorithm = Algorithmic selection using the algorithm and
+ reference code (but not the fake example sources of randomness)
+ described herein.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake Informational [Page 14]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+References
+
+ RFC 1321 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+ RFC 1750 Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness
+ Recommendations for Security", RFC 1750, December 1994.
+
+ RFC 2727 Galvin, J., "IAB and IESG Selection, Confirmation, and
+ Recall Process: Operation of the Nominating and Recall
+ Committees", BCP 10, RFC 2727, February 2000.
+
+Author's Address
+
+ Donald E. Eastlake, 3rd
+ Motorola
+ 65 Shindegan Hill Road, RR #1
+ Carmel, NY 10512 USA
+
+ Phone: +1-914-276-2668 (h)
+ +1-508-261-5434 (w)
+ Fax: +1-508-261-4447 (w)
+ EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake Informational [Page 15]
+
+RFC 2777 Verifiable Random Selection February 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake Informational [Page 16]
+