How much does the expected benefit of this project depend on having the CA certificate signed by a commonly trusted CA?
Discussed at 4/7/2010 meeting:
It is very important for using S/MIME for e-mail. Even if the root CA is not signed it would benefit VT internally to be able to use S/MIME.
The RFP to have the VT root CA signed by an outside trusted CA has a 4/19/2010 deadline for responses.
The Soft PDC project is not dependent on the result of the RFP.
Ignoring cost, are there other benefits provided by using our own CA?
Discussed at 4/7/2010 meeting:
Flexibility. We will be able to tweak the Soft PDC certs the way we want.
Identify grouping of processes and policies. Please clarify
Is it in scope to discuss the possible creation of ad hoc CAs (with their own root) to serve various user needs, i.e. operating the CA infrastructure as a service to another university entity? Example: A department wants to authenticate access to a web service with certificates. The department takes care of I&A to their satisfaction and requests a cert be issued signed by the department's root cert.
Discussed at 4/7/2010 meeting:
This is outside the scope of this project.
Is an element of this issuing certs to non-affiliated users who someone at the university wants to have a certificate? Example: Department wants some vendors they deal with to have a cert.
Discussed at 4/7/2010 meeting:
Already done for server certs.
The team agreed to table this discussion for now.
Who can get a soft PDC? (IA)
Discussed at 4/22/2010 meeting:
At a minimum, the same community of affiliates as defined by policy (user CPS) for the eToken PDC.
To be determined via focus groups.
Technically we can issue a PDC to VT non-affiliates.
How many active soft PDCs can a user have? Question should really be, "How many active key pairs can a user have?"
Discussed at 7/1/2010 meeting:
One
Note: Active means the certificate has never been revoked.
Issue separate signing and encryption certificates? (IA)
Discussed at 4/22/2010 meeting:
Can be done but this would be much more complicated for the end user (maintaining separate certificates).
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.
No! This is strongly not recommended.
Issue multiple certificates? Multiple certificates OK, but only one active key pair.
Discussed at 4/22/2010 meeting:
Same management issues as 7a.
For simplicity and ease of use we recommend having one active certificate with signing & encryption attributes.
Key escrow would handle lost/compromised keys.
Role certificates (e.g. departmental cert as an alternative to escrow or for role accounts)?
Discussed at 4/22/2010 meeting:
One active certificate per personal profile, other profiles would not have this restriction.
Do not allow encryption for departmental profiles.
Certificates for devices?
Discussed at 4/22/2010 meeting:
This is out of scope for this project, save for future discussion.
Will there be a face to face enrollment requirement or will there be a remote web based enrollment process? (IA)
Discussed at 5/6/2010 meeting:
NIST standard says either is acceptable depends on identity proofing used. Nothing VT does today remotely reaches level 3.
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).
Need to password protect the password for their key, using the Hokie passport.
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.
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.
Internal Audit should be consulted once we have a better scope of this project defined.
Discussed at 7/1/2010 meeting:
A final decision on face-to-face identity proofing needs further input from focus groups, Internal Audit, to name just two.
What information will be required to validate the identity of users who enroll for a soft PDC? (IA)
Discussed at 5/6/2010 meeting:
Susan will draft a description of the implicit identity proofing for the university community.
We cannot have a definitive answer to this until after the focus group meetings, discussing use cases, and getting input from Internal Audit.
Ideally (eventually) we would have many approvers, all over campus. Some suggestions are HR liaisons, Dept. Network Liaisons.
Use the term "Early Adopters" instead of "Pilot". We need to identify some early adopters, perhaps this will emerge from focus group meetings.
Will it be setup as self service or will approval (by supervisor or some other authority) be required to get a soft PDC? (.IA - describe self-service request for cert and in-person approval
.)Discussed at 5/6/2010 meeting:
see number 11
Can soft PDCs be renewed? (IA - describe for IA)
Discussed at 4/22/2010 meeting:
Yes
What will the validity period be for soft PDCs? (IA)
Discussed at 5/6/2010 meeting:
5 years is good for students.
The technology has been static since the 1970's.
How do soft PDCs fit into the VT Digital Identity LOA standards under development? (IA)
Discussed at 5/6/2010 meeting:
One use case is the graduate school wanted something with a higher LOA than pid and password and eTokens too costly.
A soft pdc is defined as level 3 depending on the identity proofing process. Assumption for this project is to shoot for level 3.
Current LOA: Guest-acct=1, PID=2, eToken=4
Should soft PDCs be included in a Root Key Signed Trust chain? (having our cert signed by an external provider) (IA)
Discussed at 7/1/2010 meeting:
Yes but only as far as the money stretches. There is probably not enough money to extend this to all students.
Desirable if there are no cost limitations. Examine the cost and decide based on that.
Current RFP decision may determine the answer to this question.
Sign PGP keys, or provide external signature for key file?
Outside the scope of project for now.
Will soft PDC support encryption and if so will keys be escrowed? (IA)
Discussed at 4/22/2010 meeting:
Yes
Internal Audit wants key escrow so why not offer both signing and encryption attributes for Soft PDCs.
How will users retrieve their keys from key escrow? Is the process the same as when users request a soft PDC? (IA)
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.
Any procedure that works to get you into the interface (for user getting their own key)
For Requirements:When are affiliation checks for eligibility done?Answer:At login and if wrong affiliation give an error message with contact information.
Recently fired employees would have their PID locked and not have access to the application.
Will administrators be allowed to retrieve keys? How will administrators retrieve keys that have been escrowed? (IA)
Discussed at 6/3/2010 meeting:
If a person loses his/her own key, the RA Admin will be able to approve recovery of a key for that person.
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.
Voluntary escrow as a service or mandatory as a disincentive to use our CA? Phil: there is a group on campus that will not use keys if they are escrowed.*
Discussed at 6/3/2010 meeting:
The university must be able to recover the university data if it is encrypted.
Recommend that key escrow be done for the soft PDCs.
Would we have the option to exclude key escrow for future profiles that would not include encryption. (IA - if we issue other certificates that do not include encryption, may we forego escrowing keys for those certificates.)
Discussed at 6/3/2010 meeting:
Yes
Suggestion that employees be required to obtain soft PDC as part of orientation. Should this be required?
Discussed at 6/3/2010 meeting:
This would involve HR. We did not discuss this item very much. Not sure how to pursue.
Should we publish certificates to ED and AD? Should we do it at initial rollout?
Discussed at 6/3/2010 meeting:
Another option is to use the current eProv search.
To put into ED, eProv would need to put into Registry which would require eProv to use a web service.
Can this wait until after initial rollout?
Cannot answer fully until we talk with potential users.
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.
Ish agreed to run a report that shows the credentials that have been used when issuing eTokens.
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.
Retention of Records Requirement (IA - 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:
According to InCommon Silver it is 7 years. Maybe 8 years due to Virginia (state) requirements.
Root Key Signed Trust Chain?
Discussed at 7/1/2010 meeting:
"As far as the money stretches".
eProvisioning would take advantage of this in development if it were available.
Publication to VT Directories/Registry?
Discussed at 7/1/2010 meeting:
eProv would need to know what API's are available.
In response to the question, "Daniel, is there a way to publish the cert to ED without your intervention today?" Daniel Fisher said:
No, there is no self-service publishing mechanism.
Certificates can only be published by someone with DAT access and the appropriate permissions.
However, updating MyVT to do this should be trivial.
What if someone does not want their certificate published? Also, what about a student that requested confidentiality?
Ish commented that the search tool does not discriminate based on confidentiality. One possible solution is to store the certificate in ED and then use the confidentiality flag to expose (or not).
Policy and procedures to request out of band key recovery by someone other than the owner of the keys? (IA: procedures /legal - policy)