Publicly Verifiable Nominations Committee (NomCom) Random Selection

Abstract

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. It focuses on the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers; however, similar or, in some cases, identical techniques could be and have been applied to other cases.¶

1. Introduction

Under the IETF rules, each year a set of people are randomly selected from among eligible volunteers to be the voting members of the IETF nominations committee (NomCom). The NomCom nominates members of the Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), and other bodies as described in [RFC8713]. The number of eligible volunteers in the early years of the use of the NomCom mechanism was around 50 but in recent years has been around 200.¶

It is highly desirable that the random selection of the voting NomCom be done in an unimpeachable fashion so that no reasonable charges of bias or favoritism can be brought. This is as much for the protection of the selection administrator (currently, the appointed non-voting NomCom Chair) from suspicion of bias as it is for the protection of the IETF.¶

A method such that public information will enable any person to verify the randomness of the selection meets this criterion. This document specifies such a method.¶

This method, in the form it appeared in RFC 2777, was also used by IANA in February 2003 to determine the ACE prefix for Internationalized Domain Names ("xn--") [RFC5890] so as to avoid claim jumping.¶

2. General Flow of a Publicly Verifiable Process

A selection of NomCom members publicly verifiable as unbiased or similar selection could follow the three steps given in the subsections below: Determination of the Pool, Publication of the Algorithm, and Publication of the Selection.¶

3. Randomness

The crux of the unbiased nature of the selection is that it is based in an exact, predetermined fashion on random information which will be revealed in the future and thus cannot be known to the person specifying the algorithm. That random information will be used to control the selection. The random information MUST be such that it will be publicly and unambiguously revealed in a timely fashion.¶

     P!
-------------
N! * (P - N)!

4. A Specific Algorithm for Initial Selection

It is important that a precise algorithm be given for canonicalizing and mixing the random sources being used and making the selection based thereon. Sources suggested above produce either a single positive number (i.e., NY Stock Exchange volume in thousands of shares) or a small set of positive numbers (many lotteries provide 6 numbers in the range of 1 through 70 or the like, a sporting event could produce the scores of two teams, etc.). A suggested precise algorithm is as follows:¶

1. For each source producing one or more numeric values, each value is canonicalized by representing the value as a decimal number terminated by a period (or with a period separating the whole from the fractional part), without leading zeroes except for a single leading zero if the integer part is zero, and without trailing zeroes on the fractional part after the period. Some examples follow:¶

   Table 2

   Input	Canonicalized
   0	0.
   0.0	0.
   42	42
   7.0	7.
   013.	13.
   .420	0.42
   12.34	12.34
   1.2340	1.234

2. If a source produced multiple values, order those values from smallest to the largest. This sorting is necessary because the same lottery results, for example, are sometimes reported in the order numbers were drawn and sometimes in numeric order and such things as the scores of two sports teams that play a game have no inherent order.¶
3. If a source produced multiple values, concatenate them and suffix the result with a "/". If a source produced a single number, simply represent it as above with an added "/" suffix.¶
4. At this point you have a string for each source, say s1/, s2/, ... for source 1, source 2, ... Concatenate these strings in a pre-specified order, the order in which the sources were listed when they were announced if no other order is specified, and represent each character as its ASCII code [RFC0020] producing "s1/s2/.../" as the random seed from which selection is derived.¶
5. Produce a sequence of random values derived from a mixing of these sources by calculating the MD5 hash [RFC1321] of the seed specified in step 4 prefixed and suffixed with an all zeros two-byte sequence for the first value, the string prefixed and suffixed by 0x0001 for the second value, etc., treating the two bytes as a big-endian counter. Treat each of these derived "random" MD5 output values as a positive 128-bit multiprecision big endian integer.¶
6. Finally, impose a total pseudo-random ordering on the pool of listed items (e.g., NomCom volunteers) as follows: If there are P pool members, select the first by dividing the first derived random value by P and using the remainder plus one as the position of the selectee in the published list. Select the second by dividing the second derived random value by P-1 and using the remainder plus one as the position in the list with the first selected person eliminated. And so on.¶

Any ambiguity in the above procedure is resolved by consulting the reference code below.¶

Use of alphanumeric random sources is NOT RECOMMENDED due to the much greater difficulty in canonicalizing them in an independently repeatable fashion; however, if the administrator of the selection process chooses to ignore this advice and use an ASCII or similar Roman alphabet source or sources, all white space, punctuation, accents, 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 single number above and suffixed with a "./". The administrator MUST NOT use even more complex and harder to canonicalize quantities such as complex numbers or UNICODE international text.¶

5. Extended Selection

There may be reasons why one or more of the selected members of the pool need to be eliminated and further selections made. This is particularly true given the strong recommendation above that, in case of doubt or not-yet-resolved eligibility dispute, possible pool members should be left in the pool with the understanding that, in the event they are initially selected, they can be later eliminated should it be decided they are not eligible. For the IETF NomCom, there are two types of reasons for elimination as follows:¶

A.

Elimination due to simple rule enforcement by the administrator. Examples would be someone that did not meet the eligibility requirements or whose inclusion would violate the rule limiting the number of voters with the same sponsor or all but one occurrence of someone included multiple times due to a name change or similar confusion. When there are such eliminations in the initial selectees, the administration simply goes further down the ordered list produced with the initial randomness sources until there are the desired number of selectees who are not eliminated by such decisions. The administrator SHOULD announce who has been eliminated and the reason for the administrator's decision to eliminate them.¶

B.

Eliminations due to a selectee, that is, agreement from the selectee to serve cannot be obtained by the administrator before a deadline established by the administrator. For example, either the selectee declines to serve or, despite all reasonable efforts, the selectee is not adequately contactable.¶

(The elimination of someone due to non-contactability may work a hardship for that individual if it was due to no fault of their own and they wanted to serve. But there is no reasonable alternative if a NomCom voting membership of volunteers with a confirmed agreement to serve is to be finalized in a timely manner. Since someone so eliminated will, as provided below, be replaced by another randomly selected pool member, there is no problem from the point of view of NomCom composition.)¶

It will frequently be the case that, after the initial selection from the pool and the handling of any Type A eliminations as above, there will be a small number of Type B eliminations. If no further actions were taken, there will be an insufficient number of people selected and not eliminated. If selection were extended in this case by just going further down the ordered list, as with Type A eliminations, this would give initially selected persons the ability to, by declning to serve, in effect, transfer their voting NomCom membership to a known different person since the entire initial ordered list is, at that point, publicly known. Some perceive this as a problem, so it is resolved by the administrator iteratively using what is essentially a miniature version of the initial selection as follows:¶

1. The new pool consists of the initial pool in the same order without any selectees who have agreed to serve and without any pool members eliminated by any earlier Type A or B eliminations.¶
2. The new randomness is created using a specific instance of a public daily source announced at the same time as the initial randomness sources. Since an extended selection is normally of a much lower number of selectees (typically 1 or 2) from a smaller pool, much less entropy is needed. For example, a 4 or 5 digit daily number announced by a government lottery would be adequate. This random source is treated as an additional source added to the initially announced list of random sources and processed as specified resulting in it being suffixed to the seed produced by the initial randomness sources. (See worked example and reference code below.)¶
3. The administrator publicly announces how many additional selections are needed and the specific future daily random source that will be used. At least a few hours should be allowed between this announcement and the public availability of the extension random source. As soon as the random source is available, the administrator announces the extended selections and any further extension of the extended selections due to Type A eliminations as above.¶
4. The administrator still needs to check for Type B eliminations among the new selectees. At this point in the process, the time constraints are likely to be very tight so contacting extensions selectees to be sure they are still willing to serve MUST be done urgently and with a very tight deadline. Since there may be further Type B eliminations among the extended selectees, more than one cycle of extension may be needed. If so, these steps 1 through 4 are repeated with minor modifications as follows: For Step 1, those in the pool before the next extension are all those from the pool who have not been selected so far or been subject to Type A or Type B elimination. In particular, note that because they have been previous eliminiated and to avoid various complex disuptes and timing race conditions, someone who was uncontactable or declined to serve in an earlier round does NOT become eligible for later rounds even if they later become contactable or change their mind about declining. For Step 2, a different future version of the daily randomness source is used as the additional randomness; when multiple selection extensions have to be run, the additional randomness does not pile up making the pseudo-random seed longer and longer but rather each extension's additional randomness is used with the initial random sources. Step 3 and 4 are unaltered.¶

Unfortunately, multiple extension cycles may be required so the selection administration should allow enough time for up to 5 or so of them. For example, in the selection of the 2022/2023 NomCom, 3 extensions would have been required: The pool was huge with 267 members, the largest ever. In the initial selection, one of the 10 potential selectees was Type B eliminated because confirmation of their willingness to serve could not be obtained in a timely fashion. In the 1st extended selection, the 11th potential selectee was Type B eliminated because they declined to serve and the 12th was Type A eliminated because there were already two selectees with the same sponsor. In the 2nd extended selection, the 13th potential selected also declined to serve. In the 3rd extended selection, the 14th potential selectee became the final voting member of the Nomcom when they confirmed their willingness to serve.¶

6. Handling Real World Problems

In the real world, problems can arise in following the steps and flow outlined in the sections above. Some problems that have actually arisen are described below with recommendations for handling them.¶

7. Fully Worked Example

>> Example needs to also cover the Section 5 Extension provisions. <<¶

1. Assume the eligible volunteers published in advance of selection are the numbered list of 30 past NomCom Chairs appearing below in Appendix A.¶

2. Assume the following (fake example) ordered list of randomness sources:¶

   2.1 The Kingdom of Alphaland State Lottery daily number for 1 November 2022 treated as a single four-digit integer.¶

   2.2 (a) The People's Democratic Republic of Betastani State Lottery six winning numbers for 1 November 2022 and then (b) the seventh "extra number" for that day as if it was a separate random source.¶

Hypothetical randomness publicly produced:¶

Source 1: 9319¶

Source 2a: 9, 61, 26, 34, 42, 41¶

Source 2b: 55¶

Resulting seed string:¶

9319./9.26.34.41.42.61./55./¶

The table below gives the hex of the MD5 of the above key string bracketed with a two-byte string that is successively 0x0000, 0x0001, 0x0002, through 0x0010 (16 decimal). 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.¶

Resulting first ten selected, in order selected:¶

Should one of the above turn out to be ineligible or uncontactable or decline to serve, the next would be J. Halpern, number 16.¶

8. Security Considerations

Careful choice 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 should 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 something like a one-week window for the community of interest to duplicate the calculations should give a reasonable assurance against implementation tampering.¶

10. Reference Code

This code makes use of the MD5 reference code from [RFC1321] ("The MD5 Message-Digest Algorithm"). The portion of the code below dealing with multiple floating point numbers was written by Matt Crawford. The original code in RFC 2777 could only handle pools of up to 255 members and was extended to 2**16-1 by Erik Nordmark. This code has been extracted from this document, compiled, and tested. While no flaws have been found, it is possible that when used with some compiler on some system under some circumstances some flaw will manifest itself.¶

<CODE BEGINS>

<< CODE HAS NOT YET BEEN UPDATED TO COVER EXTENDED SELECTION. >>

/****************************************************************
 *
 *  Reference code for
 *      "Publicly Verifiable Random Selection"
 *          Donald E. Eastlake 3rd
 *              Original February 2004, Updated December 2022
 *
 * Redistribution and use in source and binary forms, with or
 * without modification, is permitted pursuant to, and subject
 * to the license terms contained in, the Revised BSD License
 * set forth in Section 4.c of the IETF Trust's Legal Provisions
 * Relating to IETF Documents
 * (http://trustee.ietf.org/license-info).
 ****************************************************************/

#include <limits.h>
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* From RFC 1321 */
#include "global.h"
#include "MD5.h"

/* local prototypes */
int longremainder ( unsigned short divisor,
                    unsigned char dividend[16] );
long int getinteger ( char *string );
double NPentropy ( int N, int P );


/* limited to up to 16 inputs of up to sixteen integers each */
/* pool limit of 2**8-1 extended to 2**16-1 by Erik Nordmark */
/****************************************************************/

int main ()
{
int         i, j,  k, k2, err, keysize, usel;
unsigned short   remaining, *selected;
long int    pool, selection, temp, array[16];
MD5_CTX     ctx;
char        buffer[257], key [800], sarray[16][256];
unsigned char    uc16[16], unch1, unch2;

/* get basic parameters */
pool = getinteger ( "Type size of pool:\n" );
if ( pool > 65535 )
    {
    printf ( "Pool too big.\n" );
    exit ( 1 );
    }
selected = (unsigned short *) malloc ( (size_t)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" );
else
    {
    err = printf ( "Approximately %.1f bits of entropy needed.\n",
                    NPentropy ( selection, pool ) + 0.05 );
    if ( err <= 0 )
        exit ( 1 );
    }

/* get the "random" inputs. echo back to user so the user may
   be able to tell if truncation or other glitches occur.  */
for ( i = 0, keysize = 0; i < 16; ++i )
     {
     if ( keysize > 500 )
         {
         printf ( "Too much input.\n" );
         exit ( 1 );
         }
     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' )  /* "e"nd */
             break;     /* break out of "for i" */
         else
         {   /* 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], "/" );
         }
    }    /* end "for i" */
if ( i == 0 )
    {
    printf ( "No key input.\n" );
    exit (1);
    }

/* 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] = (unsigned short)(i + 1);
printf ( "index        hex value of MD5        div  selected\n" );
for (   usel = 0, remaining = (unsigned short)pool;
        usel < selection;
        ++usel, --remaining )
    {
    unch1 = (unsigned char)usel;
    unch2 = (unsigned char)(usel>>8);
    /* prefix/suffix extended to 2 bytes by Donald Eastlake */
    MD5Init ( &ctx );
    MD5Update ( &ctx, &unch2, 1 );
    MD5Update ( &ctx, &unch1, 1 );
    MD5Update ( &ctx, (unsigned char *)key, keysize );
    MD5Update ( &ctx, &unch2, 1 );
    MD5Update ( &ctx, &unch1, 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",
usel+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 a positive non-zero integer input */
/****************************************************************/
long int getinteger ( char *string )
{
long int     i;
int          j;
char    tin[257];

while ( 1 )
{
printf ( "%s", string );
printf ( "(or 'exit' to exit) " );
gets ( tin );
j = sscanf ( tin, "%ld", &i );
if (    ( j == EOF )
    ||  ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) )
        )
    exit ( j );
if ( ( j == 1 ) &&
     ( i > 0 ) )
    return i;
}   /* end while */
}

/* get remainder of dividing a 16 byte unsigned int
   by a small positive number */
/****************************************************************/
int longremainder ( unsigned short 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 0.0;     /* degenerate case */
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 */

<< CODE HAS NOT YET BEEN UPDATED TO COVER EXTENDED SELECTION. >>


<CODE ENDS>

11. Normative References

[RFC0020]

Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

[RFC1321]

Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4086]

Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12. Informative References

[RFC3797]

Eastlake 3rd, D., "Publicly Verifiable Nominations Committee (NomCom) Random Selection", RFC 3797, DOI 10.17487/RFC3797, June 2004, <https://www.rfc-editor.org/info/rfc3797>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.

[RFC6151]

Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.

[RFC8713]

Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", BCP 10, RFC 8713, DOI 10.17487/RFC8713, February 2020, <https://www.rfc-editor.org/info/rfc8713>.

[RFC8788]

Leiba, B., "Eligibility for the 2020-2021 Nominating Committee", BCP 10, RFC 8788, DOI 10.17487/RFC8788, May 2020, <https://www.rfc-editor.org/info/rfc8788>.

Appendix A. History of NomCom Member Selection

For reference purposes, here is a list of the IETF Nominations Committee member selection techniques and chairs so far:¶

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 similar concepts to those documented in RFC 2777 and herein.¶

RFC 2777 = Algorithmic selection using the algorithm and reference code provided in RFC 2777 (but not the fake example sources of randomness).¶

RFC 3797 = Algorithmic selection using the algorithm and reference code provided in RFC 3797 (but not the fake example sources of randomness).¶

Appendix B. Changes from RFC 3797

The primary differences between this documenet and [RFC3797], the previous version, are the following:¶

1. Many editorial changes. Add IANA Considerations section.¶
2. Use [RFC0020] as the reference for ASCII.¶
3. Update Appendix A.¶
4. Add Section 5: Extended Selection.¶