Requirements for IETF Nominations Committee Tools
draft-krishnan-nomcom-tools-02

I think it is important to hurry this document through if we are 
serious about developing tools to make the work of NomCom less
arduous. But I also think it is important to get the specification
right so that the tools developed do what is required wasting neither
time nor effort. In view of this, I support a number of the existing
Discusses that focus on the precision of the requirements.

---

We should try to learn from the tools database issues that arose in 
NomCom 2011. How can we ensure that the feedback that has been entered
remains available to the NomCom and does not have to be reconstructed
or retrieved by special action?

---

Section 8

IIRC the current tools do not allow an individual to revist the feedback
that they have already entered for a candidate. Although it is possible 
to request an email copy of the feedback at the time it is entered, it 
is not possible to recall the feedback through the web page. Such a 
feature would be useful as a reminder before an interview, for 
correlation of feedback against multiple candidates, and to allow
updates to feedback as new thoughts arise.

It would be nice to add this feature.

I support this document. However, I have some comments.

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

- When I read:
   "The users of the tools may have different privileges based on their role.  
   The tool needs to support at least three levels of access:Community
   member, Nomcom member, Nomcom chair.

I don't understand the "may".
If you create different levels, isn't because the different levels "must" have different privileges?
From there, I was wondering: what are the different privileges based on the role?
I was hoping to find a definition of Nomcom member and/or Nomcom chair in one of the nomcom RFCs (RFC3777, RFC5078, RFC5633, RFC5680), along with their role definition.
However, it doesn't seem to exist. 
Disclaimer: I have not seen https://www.ietf.org/group/nomcom/2011/private/, so it's difficult to understand if we miss requirements about the role versus privileges, or if this falls into the META-001 requirement.
 

 - "The tool needs to support at least three levels of access:Community
   member, Nomcom member, Nomcom chair.
   
   ...

   o  AUTH-003: The tool MUST allow the secretariat to input an email
      address to be provided the Nomcom chair role and a list of email
      addresses to be provided the Nomcom member role."

So which of the three levels has the Secretariat? Nomcom member?
Or do you need a fourth role just for Secretariat/Tools admin?

Along the same lines:
   o  SEC-005: The data accumulated by the tool MUST be stored in a
      fashion that prevents accidental exposure of the data to people
      who administer the server(s) on which the data is stored.

Do you consider the Secretariat part of the "people who administer the server(s)"? I guess not. So how many roles do you need at the end?


Editorial comments
- OLD:

QR-005: Like all other correspondance on the Nomcom mailing list,
      the questionnaires MUST be encrypted by the Nomcom public key
      before being stored. 

NEW:
QR-005: Like all other correspondance on the Nomcom mailing list,
      the filled in questionnaires MUST be encrypted by the Nomcom public key
      before being stored.

I support the publication of this document and only have the following, non-blocking, comments:

1. The last sentence of the Introduction is missing a period.

2. Why does the security section start numbering at 000 and all the other sections start at 001?

3. With AD-006, is there a need to allow for the specification of time windows when generating statistics?

4. AD-002 refers to "Acceptances and declines".  Is there a reason for the capitalization of "Acceptances", but not of "declines"?

5. The QR requirements also mix and match capitalization of "Questionnaires".

6. I support Barry's feedback on the use of 2119 keywords when referring to the management of the key and encrypted cookie.

Thanks for addressing my Discuss positions and previous Comments.

I have one final nit to point out:

In FB-002:
	
     that, as in FB-002, anonymous feedback is allowed, and thus the

s/FB-002/NOM-002/

1) AUTH-002: should you be explicit about it being datatracker.ietf.org identity?  i.e.,:

o  AUTH-002: The tool MUST allow the members of the community to
    create a new datatracker.ietf.org login with an automated system.
    The system MUST verify that e-mail address used for creating the login.

It's not another kind of login is it?

2) AUTH-003: Do certs get made for the nomcom email address and are those email addresses provided certificates to encrypt email?

3) s9: This is about the noncom chair, but shouldn't we also warn that the nomcom chair better keep that private key private!  Shoul

5) A couple on Appendix A

a) openssl will put the generated key in the file with the -out command so I'm not sure why you need "| tee".

b) It'll do it all in one command :) (provided below)

c) We need to specify SHA-256 because SHA-1 is the default :(

d) hate it that we're not following recommendations and including the right bits  in the right places in the certs.  We could use a .cnf file to fix that (one included).

e) Should the lifetime of the cert be 2 years because that's how long the commitment is?

f) not sure why you did the -pubout command (#2) if the tool is just going to extract it.

g) what is this key used for?  Is it just TLS connections or is it also data at rest (answer changes the key usages)?  I assumed it was TLS and data at rest: hence EKU: clientAuth/serverAuth and KU: digitalSignature/keyEncipherment/dataEncipherment.  I omitted keyCertSign and cRLSign bits because we're not generating additional certs.

h) openssl is phasing out genrsa with genpkey so if you're not going to go for the one stop command should probably add:

   openssl genpkey -algorithm RSA -out rsakey2.pem \
           -pkeyopt rsa_keygen_bits:2048


Here's the nomcom-config.cnf file to prompt the chair for the name, put the email in the right place (yes they'll have to set the address), and include the correct extensions (we can debate which ones those are).

*****BEGIN FILE*****
[ req ]
distinguished_name = req_distinguished_name
string_mask        = utf8only
x509_extensions    = ss_v3_ca

[ req_distinguished_name ]
commonName           = Common Name (e.g., NomcomYY)
commonName_deafault  = Nomcom12

[ ss_v3_ca ]

subjectKeyIdentifier = hash
keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment
basicConstraints = critical, CA:true
subjectAltName = email:nomcom12@ietf.org
extendedKeyUsage= clientAuth,serverAuth

# modify the email address to match the year.

*****END FILE*****

One step command:

  openssl req -config nomcom-config.cnf -x509 -new -newkey rsa:2048 \\
          -sha256 -days 730 -nodes -keyout publicKey.pem \\
          -out nomcom12.cert

- General question and a near-discuss: What, if anything, should
happen to the stored/archived information after the nomcom has
done its work? And if something should happen, (e.g. deletion)
when ought that happen? This may all be in some RFC, but I just
don't know and I could see various good and bad answers being
possible here. 3777 says that: "The nominating committee should
archive the information it has collected or produced for a
period of time not to exceed its term." I don't know what's
actually done now, but could imagine that tools might make
it better or worse.

- Section 2, will those URLs containing 2011 remain good for
sufficiently long to be useful? Maybe s/2011/2012/ at least.

- Section 4, "should be stored using an encrypted cookie" is
wrong. Cookies may disappear (e.g. in http/2.0) and other better
technologies might come along. 

- Section 4, I think you need to say somewhere that each nomcom
MUST use a different key pair.

- Section 4, s/using the procedure/for example, using the
procedure/ would be better.

- 2119 and 3777 should be referenced somewhere in the
text I guess.


- Section 4, I think you need to say somewhere that each nomcom
MUST use a different key pair.

- Section 4, s/using the procedure/for example, using the
procedure/ would be better.

I have moved all of my discuss points to comments on the basis of
my discussion with the Authors and Shepherding AD.

=========

This is basically a sound document, but there are some details that need attention.
Once these are addressed I will be happy to vote yes.

=====

Sec-001 and Sec-005 look the same

=====

This information can only be accessed by the members of the Nomcom.

Does the above mean voting members, voting members + chair.....?

=====

AD-004: The tool MUST allow to view a list of all nominees along
      with their accepance or decline status.

Must allow who?

=====


AD-005: The tool MUST allow the reporting of accepance or decline
      status both per nominee as well as per open position.

Reporting to who?

=====

The nominees fill in a questionnaire for each of the positions for
   which they accept a nomination.

.. and does what with it? Sends an email, posts it on the web site
completes it on the web site?

=====

FB-005: All email received on the Nomcom mailing list MUST be
      archived.  

For what period, and who has access to the archive?

=====
========

AUTH-003: The tool MUST allow the secretariat to input an email
      address to be provided the Nomcom chair role and a list of email
      addresses to be provided the Nomcom member role.

The above requirement does not read correctly - possibly missing some "by"s

=====

The filled in questionnaires are
      received as emails to the Nomcom mailing list.

Surely they are sent as emails

=====