NomCom tool requirements: Requirements for IETF Nominations Committee Tools
Tools to help the committee that picks IETF leaders work smoothly and securely.
Krishnan, S. and J. Halpern, "Requirements for IETF Nominations Committee Tools", RFC 6730, DOI 10.17487/RFC6730, September 2012, <https://www.rfc-editor.org/info/rfc6730>.
@misc{rfc6730,
series = {Request for Comments},
number = 6730,
howpublished = {RFC 6730},
publisher = {RFC Editor},
doi = {10.17487/RFC6730},
url = {https://www.rfc-editor.org/info/rfc6730},
author = {S. Krishnan and J. Halpern},
title = {{Requirements for IETF Nominations Committee Tools}},
pagetotal = 10,
year = 2012,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6730 J. Halpern
Category: Informational Ericsson
ISSN: 2070-1721 September 2012
Requirements for IETF Nominations Committee Tools
Abstract
This document defines the requirements for a set of tools for use by
the IETF Nominations Committee.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6730.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Meta Requirement ................................................2
3. Authentication ..................................................3
4. Security and Access Control .....................................3
5. Nominations .....................................................4
6. Accepting and Declining Nominations .............................5
7. Questionnaires ..................................................6
8. Feedback Collection .............................................7
9. Security Considerations .........................................8
10. Acknowledgements ...............................................8
12. Normative References ...........................................8
Appendix A. Example for Key Generation .............................9
1. Introduction
The IETF Nominations Committee (NomCom) is a body that selects
candidates for open IESG, IAB, and IAOC positions following the
process outlined in [RFC3777]. There is a need for a set of tools to
aid the NomCom in efficient operation. This document presents a set
of requirements for such a tool.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Meta Requirement
There is an existing tool for supporting NomCom work. The set of
requirements specified in this document are mainly enhancement
requirements or behavioral changes to the existing tool. Unless
otherwise stated, all of the current functions of the existing NomCom
tool need to be supported in the new tool as well.
o META-001: The tool MUST provide all the functionality that is
provided by the current NomCom tool, except in cases where a
requirement specified in this document overrides a current
behavior. The current NomCom tool can be found at the following
URLs: https://www.ietf.org/group/nomcom/2012/private/ displays the
NomCom private parts of the tool (Private NomCom tool) and
https://www.ietf.org/group/nomcom/2012/ displays the community
member accessible parts of the tool (Public NomCom tool).
3. Authentication
All access to NomCom tools needs to be authenticated. Users of the
tools have different privileges based on their role. The tool needs
to support at least three levels of access: community member, NomCom
member, and NomCom chair. The levels of access are set up by the
staff of the IETF Secretariat. It is to be noted that the
Secretariat staff do not have any access to the tool. They are
responsible for administering the server on which the tool runs;
hence, they set up the access control list for the tool.
Community member access is applicable to the Public NomCom tool. The
NomCom member access and the NomCom chair access are applicable to
the Private NomCom tool. NomCom members can use the interfaces on
the Public NomCom tool in the community member role. The NomCom
chair access authentication applies to the private webpage in the
same fashion as a NomCom member, with the additional ability to
update the information on both webpages (i.e., what is visible in the
various forms, the templates for the automatic emails, etc.).
o AUTH-001: The tool MUST allow members of the community to log in
with their existing datatracker.ietf.org credentials.
o AUTH-002: The tool MUST allow members of the community to create a
new login using the datatracker.ietf.org login system.
o AUTH-003: The tool MUST allow the secretariat to enter the email
address of the NomCom chair and to enter a list of email addresses
of the NomCom members. The logins associated with these email
addresses MUST be accorded the respective roles.
4. Security and Access Control
All communication between the community and the NomCom and amongst
the members of the NomCom needs to be stored in an encrypted form.
This information can only be accessed by members of the NomCom.
o SEC-001: The security procedures for the tool MUST be structured
so that even system administrators do not have routine or
accidental visibility to any data accumulated by the tool. This
data includes all confidential feedback and discussions.
o SEC-002: The tool MUST allow the NomCom chair to input a public
key ("NomCom public key"). This key is generated by the NomCom
chair independent of the tool, for example, using the procedure
described in Appendix A.
o SEC-003: All communication sent to the NomCom mailing list MUST be
encrypted with the NomCom public key before being committed to
persistent storage.
o SEC-004: All community feedback entered using the NomCom tool MUST
be encrypted with the NomCom public key before being committed to
persistent storage.
o SEC-005: After logging in, the tool MUST allow the NomCom members
to input a private key ("NomCom private key") that corresponds to
the NomCom public key. This key will be used to decrypt the
feedback/communications that the member is trying to access. Once
entered, this key MUST be available for the entire length of the
session until the user logs out. This private key MUST NOT be
stored in plaintext form into persistent storage at any point of
time.
o SEC-006: The tool MUST provide a mechanism for the NomCom Chair to
destroy all data collected by the NomCom at the end of the
NomCom's term. Since the NomCom's term overlaps with that of the
next year's NomCom, the tool MUST ensure that data collected by
the next year's NomCom is not affected by this deletion.
5. Nominations
After the NomCom is constituted, the NomCom chair issues a call for
nominations for the open positions. There are two broad ways in
which nominees are introduced into the system. The predominant way
is that nominations are entered into the system directly by members
of the community. The secondary way is that the nominees are entered
in by members of the NomCom. The main difference is that members of
the NomCom can enter nominations that are originated by other
community members. In both of the cases, an email address for the
nominee needs to be entered into the tool. Please note that NomCom
members usually use the Public NomCom tool, not the Private NomCom
tool, to enter their personal nominations and comments.
o NOM-001: The tool MUST allow members of the community to enter
nominations into the Public NomCom tool.
o NOM-002: The tool MUST allow members of the NomCom to enter
nominations into the Private NomCom tool. The tool MUST allow the
NomCom member to optionally enter information about the originator
of the nomination. The tool MUST record the identity of the
originator (if known) of the nomination for audit purposes. Note
that anonymous nominations are allowed; thus, the actual identity
of an originator may not always be entered into the tool.
o NOM-003: The tool MUST allow the NomCom chair to specify
information that is required for the nominations. This
information will be entered by the NomCom chair as freeform text
and will be presented to the individual performing the nomination.
o NOM-004: The tool MUST email the nominee after the nomination and
mention the position(s) that they have been nominated for. This
email MUST NOT disclose to the nominee the identity of the person
who performed the nomination.
o NOM-005: The tool MUST allow the content of this email to be
customized by the NomCom chair.
o NOM-006: The tool MUST automatically attach the questionnaires for
the positions for which the nominee has been nominated to this
email.
o NOM-007: The tool MUST be able to identify duplicate nominations
of the same person with the same email address and consolidate
them to point to the same nominee.
o NOM-008: In case the same person has been nominated multiple times
using different email addresses, the tool MUST allow the NomCom
chair to mark duplicate nominations of the same person and
consolidate them to point to the same nominee.
o NOM-009: The tool MUST allow a communication email address for a
nominee to be set to one different than the email address with
which they were nominated.
o NOM-010: The tool MUST be able to use the datatracker address book
system as the basis for requirements NOM-007, NOM-008, and NOM-009
but MUST allow the NomCom chair to perform manual overrides.
o NOM-011: The tool MUST keep track of the accept and decline status
for the nominees.
6. Accepting and Declining Nominations
After receiving the nomination mail, nominees usually respond to
indicate either that they accept the nomination or that they are
unwilling to do so.
o AD-001: The tool MUST allow nominees to indicate whether they are
accepting or declining their nomination. This is preferably done
by providing distinct hyperlinks in the email that the nominees
receive.
o AD-002: The tool MUST allow the NomCom chair to select specific
email responses from the nominees and flag them as having been
accepted or declined.
o AD-003: The tool MUST allow the NomCom chair to manually flag
nominees as having accepted or declined the nomination without the
need for any nominee action.
o AD-004: The tool MUST allow NomCom members to view the list of all
nominees along with their accept or decline status.
o AD-005: The tool MUST allow NomCom members to view reports of the
accept or decline status both per nominee as well as per open
position.
o AD-006: The tool MUST be configurable to send reminder mails to
all nominees who have not responded, either on specified dates or
at specified intervals. The contents of the reminder mails MUST
be customizable by the NomCom chair.
o AD-007: The tool MUST be able to generate a summary report
containing statistics (total/accept/decline/no response)
concerning nominations by position.
7. Questionnaires
Nominees fill in a questionnaire for each position for which they
accept a nomination. The completed questionnaire is sent in by email
to the NomCom mailing list. If a person has been nominated for
multiple positions, they may elect to send in a combined
questionnaire for a subset (or all) of the positions (QR-002) or fill
in one questionnaire per open position (QR-006).
o QR-001: The tool MUST allow the NomCom chair to enter a different
questionnaire for each open position.
o QR-002: The tool MUST allow the NomCom chair to point to email
responses from the nominees and flag them as questionnaires.
o QR-003: The tool MUST allow NomCom members to directly access
questionnaires completed by nominees.
o QR-004: The tool MUST keep track of the questionnaire receipt
status for the nominees. The completed questionnaires are
received as emails to the NomCom mailing list.
o QR-005: Like all other correspondence on the NomCom mailing list,
the completed questionnaires MUST be encrypted by the NomCom
public key before being stored.
o QR-006: The NomCom chair MUST be able to flag an email as the
completed questionnaire for a nominee corresponding to a specific
open position.
o QR-007: Once flagged, the questionnaire provided by the nominee
for a specific position MUST be directly accessible without
needing to look through all other feedback received for that
nominee.
8. Feedback Collection
Community feedback is very important in the NomCom process.
Community feedback about nominees is the primary mechanism by which
NomCom members evaluate nominees.
o FB-001: The tool MUST allow members of the community to enter
feedback about any of the accepting nominees into the Public
NomCom tool.
o FB-002: The tool MUST allow members of the NomCom to enter
feedback about any of the accepting nominees into the Private
NomCom tool. The tool MUST allow the NomCom member to optionally
enter information about the originator of the feedback. Note
that, as in NOM-002, anonymous feedback is allowed; thus, the
actual identity of an originator may not always be entered into
the tool.
o FB-003: The tool MUST allow NomCom members to view feedback
entered for each nominee. The identity of the submitter should
also be visible with the feedback, unless the submitter wishes to
be anonymous.
o FB-004: The NomCom members MUST be able to enter their interview
comments as feedback for the nominee being interviewed.
o FB-005: All email received on the NomCom mailing list MUST be
archived. This includes all correspondence among the NomCom
members, feedback received over email, as well as completed
questionnaires.
o FB-006: The tool MUST allow the NomCom chair to manually copy any
of the archived mails into the feedback section of one or more
nominees for one or more open positions. This is required because
a single email may contain feedback concerning more than one
nominee or more than one open position.
9. Security Considerations
The tool must authenticate all users and must allow logins to be
classified into three roles: NomCom chair, NomCom member, and
community member. All communications to/from the NomCom and among
members of the NomCom must be stored in an encrypted form.
10. Acknowledgements
The authors would like to thank Russ Housley, Barry Leiba, Brian
Haberman, Phillip Hallam-Baker, Stewart Bryant, Adrian Farrel,
Stephen Farrell, Martin Stiemerling, Benoit Claise, Sean Turner,
Ralph Droms, Mary Barnes, Subramanian Moonesamy, and Menachem Dodge
for their valuable comments to improve this document.
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
and Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
Appendix A. Example for Key Generation
The NomCom chair generates a public/private key pair to be used to
encrypt NomCom correspondence and feedback. As an example, the
NomCom chair can use openssl to generate the key pair using the
following commands:
First, the config file for openssl needs to be created with the
following contents (example for the 2012-2013 NomCom).
[ req ]
distinguished_name = req_distinguished_name
string_mask = utf8only
x509_extensions = ss_v3_ca
[ req_distinguished_name ]
commonName = Common Name (e.g., NomComYY)
commonName_default = NomCom12
[ ss_v3_ca ]
subjectKeyIdentifier = hash
keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment
basicConstraints = critical, CA:true
subjectAltName = email:nomcom12@ietf.org
extendedKeyUsage= emailProtection
# modify the email address to match the year.
Figure 1: nomcom-config.cnf
Then the following command needs to be issued in order to generate
the private key and the certificate.
$ openssl req -config nomcom-config.cnf -x509 -new -newkey rsa:2048
-sha256 -days 730 -nodes -keyout privateKey.pem -out nomcom12.cert
The certificate can then be provided to the tool in order to extract
the public key.
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
EMail: suresh.krishnan@ericsson.com
Joel Halpern
Ericsson
EMail: joel.halpern@ericsson.com
AI ELI5
On this page
§1Introduction
The IETF Nominations Committee (NomCom) is the body responsible for selecting candidates to fill open positions in the Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), and the Internet Administrative Oversight Committee (IAOC). This process requires collecting nominations from the community, accepting or declining from nominees, gathering questionnaires, and most importantly, collecting confidential feedback about candidates. To do this work efficiently and securely, the NomCom needs specialized tools.
This RFC describes the requirements that these tools must meet. It covers everything from user authentication and data encryption to how nominations should be tracked and how community feedback should be collected and organized.
A group picks leaders for the Internet. They need secret forms to collect votes and feedback safely, so nobody knows who said what about whom.
§2Authentication and Access Control
The NomCom tool must support three distinct levels of user access. Community members access a public interface to submit nominations and feedback. NomCom members access a private interface where they can enter nominations on behalf of community members, provide feedback, and review candidate materials. The NomCom chair has full administrative access to configure forms, send emails, and manage the overall process.
All users authenticate using the IETF's datatracker system, which centralizes credential management. The Secretariat staff set up access control lists to assign roles, but importantly, Secretariat staff themselves have no access to the sensitive data the tool stores.
Three groups use the tool: regular members (read-only), committee members (add stuff), and the chair (boss). Everyone logs in the same way, but the tool remembers what each person is allowed to do.
§3Managing Nominations
The tool must allow community members to nominate people for open positions and automatically sends each nominee an email telling them they were nominated, without revealing who nominated them. Nominees can then accept or decline using links in that email. The NomCom chair can also manually enter nominees from nominations the committee receives offline, and can mark people who received multiple nominations for the same position as the same candidate.
The tool tracks which nominees have accepted and which have declined, provides reports by position and by nominee, and can send automatic reminders to people who haven't yet responded. The chair can customize all the messages the tool sends.
The tool collects names of people to consider, tells them they're being considered (secretly), and tracks who said yes or no.
§4Questionnaires and Feedback
Each open position has its own questionnaire that the NomCom chair creates. Nominees who accept their nomination fill out the questionnaire for each position and email it to the NomCom mailing list. The tool tracks which nominees have submitted questionnaires for which positions.
Community feedback is crucial: anyone can submit feedback about any accepting nominee to the public interface. NomCom members can submit feedback to the private interface, optionally anonymously. All questionnaires and feedback submitted via email to the NomCom list are automatically archived, and the chair can route any archive email into a nominee's feedback section if that email discusses multiple candidates or positions.
Each candidate fills out a form. Anyone can write down what they think about a candidate. The tool stores all these opinions so the committee can read them.
§5Security and Data Protection
All communications involving the NomCom, including feedback, questionnaires, and internal discussions, must be encrypted before being stored. The NomCom chair generates a public/private key pair (typically using OpenSSL) and enters the public key into the tool. All sensitive data is then encrypted with this public key before being saved to persistent storage. When NomCom members log in, they enter their private key, which the tool uses to decrypt data but never saves. After the NomCom's term ends, the chair can delete all data collected by the committee, but the tool protects data from the next year's NomCom.
Importantly, the system is designed so that even system administrators cannot see sensitive data at rest. The encryption key is only available to NomCom members during their active session.
All the secret stuff gets locked in a chest with a puzzle lock. Committee members have the puzzle key, but they have to bring it with them each time. When they leave, the key goes away.