1.  Who can get a soft PDC? (BQ 5) 
   • Discussed at 4/22/2010 meeting:
     1. At a minimum, the same community of affiliates as defined by policy (user CPS http://www.pki.vt.edu/vtuca/cps/index.html) for the eToken PDC.
     2. To be determined via focus groups.
     3. Technically we can issue a PDC to VT non-affiliates.
   • Discussed at 8/19/2010 meeting:
     1. This may not be an Internal Audit (IA) call. May be up to VT Management (e.g., Erv) with advice from VT legal.
     2. IA would like to know IT's opinion on the use of a soft PDC, with a higher Level Of Assurance (LOA) than a PID and password, used to access departmental computers instead of using PID and password?
     3. Need to be sure to include in the policy/standard that the soft cert needs to remain password protected and users cannot remove the password assigned the cert when issued.
2. Issue separate signing and encryption certificates? (BQ 6) 
   • Discussed at 4/22/2010 meeting:
     1. Can be done but this would be much more complicated for the end user (maintaining separate certificates).
     2. If using encryption, a recipient of an encrypted file would have to have the corresponding key to decrypt and in the case of multiple certificates, would have to keep track of all the keys that the sender has/uses.
     3. No! This is strongly not recommended. 
   • Discussed at 8/26/2010 meeting:
     1. From a usability standpoint, keeping it simple is preferred.
     2. Striving for a LOA 3 cert would benefit and give the university something we currently do not have and has unexplored possibilities.
     3. For Blacksburg employees the face to face identity proofing is not that big of an inconvenience.
3. Will there be a face to face enrollment requirement or will there be a remote web based enrollment process? (BQ 11)
   • Discussed at 5/6/2010 meeting:
     1. NIST standard says either is acceptable depends on identity proofing used. Nothing VT does today remotely reaches level 3.
     2. Perhaps strategically locate enrollment stations around campus, e.g., CRC, math emporium, however because of support issues for the operators we need to keep that number down to a reasonable number (e.g., 20 at most).
     3. Need to password protect the password for their key.
     4. Currently there is no good way to remotely authenticate the user (without a picture ID and in person) so remote enrollment process may not feasible.
     5. If we are considering remote enrollment we should review NIST standard & InCommon standards and the procedures they use. Mary will investigate this and send something to Susan and Karen for their interpretation before sending for review by this group. If we choose to go down this road we may wish to make that a stated goal or benefit of this project.
     6. Internal Audit should be consulted once we have a better scope of this project defined.
     7. A final decision on face-to-face identity proofing needs further input from focus groups, Internal Audit, to name just two.
   • Discussed at 8/26/2010 meeting:
     1. Depends on what LOA cert issued.
     2. May be possible to use departmental HR people, which would need training from IT. 4Help would need training regardless, on uses of the soft cert.
     3. A suggestion from IA is to have the departments tell us (IT) who would do the identity proofing for their department. As long as the person doing the identity proofing follows procedures it doesn't matter much who they are.
     4. Appeal to DDDH and have them promote use.
     5. We need to decide what the initial roll out is going to be, LOA 2 or LOA 3? This decision will impact the project complexity.
     6. Phase 1 scenarios:
        1. self service soft PDC = LOA 2
        2. face to face identity proofing = LOA 3
4. *What information will be required to validate the identity of users who enroll for a soft PDC? (BQ 12)
   • Discussed at 5/6/2010 meeting:
     1. Susan will draft a description of the implicit identity proofing for the university community.
   • Discussed at 7/1/2010 meeting:
     1. See Susan's Establishing existing relationships for identity proofing for the university community.
     2. We cannot have a definitive answer to this until after the focus group meetings, discussing use cases, and getting input from Internal Audit.
     3. Ideally (eventually) we would have many approvers, all over campus. Some suggestions are HR liaisons, Dept. Network Liaisons.
     4. We need to identify some early adopters, perhaps this will emerge from focus group meetings.
   • Discussed at 9/2/2010 meeting:
     1. It depends on the identity proofing method (remote or in-person) used.
     2. One idea to get started is to acknowledge that their are remote/satellite campuses to consider but to begin concentrate on the Blacksburg campus which is the majority of our user population.
     3. eProvisioning commented that complete functional requirements are necessary before coding can begin.
     4. Kevin commented that the essence of the NIST standard is that identity proofing is a person to person transaction, not automated, and not self-service.
     5. Mary commented that identity proofing varies between (1) VT LOA 3, (2) NIST, (3) InCommon Silver, and (4) I9.
     6. A suggestion is to explore the possibility of HR (for faculty/staff) and Admissions (for students) helping with identity proofing.
5. Can soft PDCs be renewed? (BQ 14) 
   • Discussed at 4/22/2010 meeting:
     1. Yes
   • Discussed at 9/2/2010 meeting:
     1. The goal is for the user to keep the same keys.
     2. Mike (IA) agreed that renewal should be possible.
6. What will the validity period be for soft PDCs? (BQ 15) 
   • Discussed at 5/6/2010 meeting:
     1. 5 years is good for students.
     2. The technology has been static since the 1970's.
   • Discussed at 9/2/2010 meeting:
     1. Mike (IA) agreed that 5 years is good for everyone.
     2. We should have an automatic revocation for employees that leave the university.
     3. A discussion ensued regarding what does it mean if a student or former employee retains their certificates once they leave. What are the consequences, if any, to Virginia Tech? Addressing this concern may not be worth the time and effort put into it.
     4. eProvisioning commented that it is totally up to the application using the certificate to check on cert. revocation.
7. How do soft PDCs fit into the VT Digital Identity LOA standards under development?  (BQ 16)
   • Discussed at 5/6/2010 meeting:
     1. One use case is the graduate school wanted something with a higher LOA than pid and password and eTokens too costly.
     2. A soft pdc is defined as level 3 depending on the identity proofing process. Assumption for this project is to shoot for level 3.
     3. Current LOA: Guest-acct=1, PID=2, eToken=4
   • Discussed at 8/19/2010 meeting:
     1. IA is of the opinion that if we issue soft PDCs with different LOAs (2 & 3 - dependent on identity proofing) to the same user then we need a strong
        education program to educate users on the the uses of the different certificates.
     2. One idea discussed is to brand (name) the different LOA cert's differently to lessen confusion.
   • Discussed at 8/26/2010 meeting:
     1. Branded name could be displayed using the "common name" of the certificate, e.g., Karen Herrington (Pylon), with Pylon being the brand name for a LOA 3 certificate.
     2. Question: Is this worth the complexity required to issue different LOA cert's?
     3. We discussed being in favor of LOA 2 and 3 certificates. eProv recommends doing this in phases with the LOA 2 cert (without in person identity proofing) first.
8. Should soft PDCs be included in a Root Key Signed Trust chain? (having our cert signed by an external provider) (BQ 17)  
   • Discussed at 7/1/2010 meeting:
     1. Yes but only as far as the money stretches. There is probably not enough money to extend this to all students.
     2. Desirable if there are no cost limitations. Examine the cost and decide based on that.
     3. Current RFP decision may determine the answer to this question.
   • Discussed at 9/9/2010 meeting:
     1. The RFP contract negotiations will be completed the week of September 20th.
     2. At this point it appears that it will cover all certificates, i.e., eToken, soft, server.
9. Will soft PDC support encryption and if so will keys be escrowed? (BQ 19) 
   • Discussed at 4/22/2010 meeting:
     1. Yes
   • Discussed at 9/9/2010 meeting:
     1. Frank commented that PKI recommendations for an enterprise rollout with encryption supported is to escrow the keys.
     2. Mike (IA) says yes to encryption and escrow.
     3. It may be interesting to know if VT Legal has ever had a case where someone challenged a "wet" (ink) signature?
10. How will users retrieve their keys from key escrow? Is the process the same as when users request a soft PDC? (BQ 20) 
    • Use of decision tree interface will not require the user to know or understand what is going on in the background to retrieve their key from escrow.
      1. Any procedure that works to get you into the interface (for user getting their own key)
    • Discussed at 7/1/2010 meeting:
      1. See Key Pair Action Table
      2. For Requirements: When are affiliation checks for eligibility done? Answer: At login and if wrong affiliation give an error message with contact information.
      3. Recently fired employees would have their PID locked and not have access to the application.
    • Discussed at 9/9/2010 meeting:
      1. In the Key Pair Action Table change "Face to Face" to "Same as When Issued".
         • Note: Greg updated the table.
      2. Mike (IA) would like to study this more and responded with a "probably yes".
    • Discussed at 9/16/2010 meeting:
      1. Mike (IA) commented that we need to assure that the person requesting key retrieval from escrow is the owner of the keys.
      2. Penn State (referenced on wiki) uses an ID & password credentials for users to perform this function. Is that sufficient?
      3. eProv clarified that when issuing a new certificate to a user the user must enter a password which is used later in the issuance process to download the actual certificate.
11. Will administrators be allowed to retrieve keys? How will administrators retrieve keys that have been escrowed? (BQ 21)
    • Discussed at 6/3/2010 meeting:
      1. If a person loses his/her own key, the RA Admin will be able to approve recovery of a key for that person.
      2. If someone other than the key owner requests retrieval, a request will need to be made to IMS for recovery. Procedure must be created for IMS to approve this type of recovery. Recommendation is that IMS perform the recovery rather than eProv staff. See Key Retrieval
    • Discussed at 9/9/2010 meeting:
      1. The current process (for e-mail) is to filter requests through IMS. Jeb Stewart makes the final approval and sign-off.
      2. IMS may not have the resources to retrieve keys in a timely fashion when scaled to the entire university.
      3. Mike (IA) offered the opinion to use the existing procedure (for e-mail) and see how it scales.
      4. For clarity an "administrator" is defined as a Registration Authority (RA) administrator on campus, e.g., Student Telecommunications office employee.
      5. eProvisioning commented that a RA Admin. would not have the necessary expertise to retrieve keys.
      6. Key retrieval approval would be "in the same manner in which it was issued to the user."
12. Would we have the option to exclude key escrow for future profiles that would not include encryption. (BQ 23)  (If we issue other certificates that do not include encryption, may we forgo escrowing keys for those certificates.) 
    • Discussed at 6/3/2010 meeting:
      1. The technical answer is, "Yes, it is possible to exclude key escrow for profiles that do not include encryption."
    • Discussed at 9/16/2010 meeting:
      1. Mike (IA) commented that he doesn't see a reason why escrow would be needed if the cert does not include encryption. Why would it be necessary?
      2. Same usuability issues already mentioned if we issue certs with and certs without encryption capability.
      3. Someone commented that this does not seem like a good idea at all. What use case is there for issuing a cert without encryption?
13.  Incommon Silver Status for Soft PDCs (PPTQ 1) 
    • Discussed at 7/1/2010 meeting:
      • We are striving for this.
        1. Mary & Karen attend conference calls in InCommon Silver. We need to come up with a scenario on existing relationships for them to discuss on these conference calls.
        2. Ish agreed to run a report that shows the credentials that have been used when issuing eTokens.
        3. eToken approvers use a book for identifying valid credentials. We need to come up with a list or web page with images of approved and not approved credentials.
    • Discussed at 9/16/2010 meeting:
      1. Mike (IA) commented that if we decide not to go for InCommon Silver than we should align ourselves (this project) with some known standard. Like NIST?
      2. NIST is currently the only standard. InCommon Silver is in development and striving to become a standard.
      3. The new VT Standard for Personal Digital Identity Levels of Assurance does not strictly adhere to NIST or InCommon standards. However, it has been deemed good enough for internal use.
      4. Mary has not heard from the CIC advisory group regarding different requirements for identity proofing between InCommon Silver, NIST, and I-9.
      5. We may be able to tweak the issuance procedures for eToken's to bring it inline with InCommon Silver. The "sticking point" is recording information from the credentials used for identity proofing, like driver's license number.
      6. Kevin commented that if we are concerned about security then we want to issue LOA 4 certs, which the eToken already provides except for the issue of recording information from the id proofing documents. Soft certs are not appropriate for anything > LOA 2.
    • Retention of Records Requirement (Are there other sources to which we should look to satisy records retention policies other than InCommon and Commonwealth of Va?)  
      • Discussed at 7/1/2010 meeting:
        1. According to InCommon Silver it is 7 years. Maybe 8 years due to Virginia (state) requirements.
    • Discussed at 9/16/2010 meeting:
      1. Mike (IA) recommends that we stick with whatever standard specifies the longest retention.
      2. State of Virginia specifies that after a certain period of time records should be destroyed.
      3. NIST says to use "your" policies, laws, etc.
      4. Susan commented that for Virginia this would be the "Virginia Library rules".

• Note: Bolded questions have been discussed and/or answered.

Other Notes/Discussion

• Discussed at 8/26/2010 meeting:
  1. What about faculty in a foreign country who need to exchange sensitive data with a colleague at VT? Is a secure fax an option? Kevin Rooney commented that the NIST standard says you can remotely issue someone a LOA 3 cert.
  2. Sharon commented that people around campus will not use these certs if we make them difficult or time consuming to use.
  3. From an IA standpoint to be as secure as needed for some applications we really need a hardware device as opposed to a soft cert. What are we gaining by issuing LOA 3 cert's if a user can just change/remove the password once it is issued?
  4. We need to figure out use cases? What security is needed? Who needs it? How will a soft cert benefit executive management (e.g., VP)?
  5. Once again, what can these soft cert's be used for? IA says if we are going to go through the trouble of issuing soft cert's at all we need an LOA 3 cert for the added security. If PID and password are already LOA 2 why not use it for everything else?