20100812 - Soft PDC project meeting, August 12, 2010

Team

Ismael Alaou i, Phil Benchoff , Susan Brooker-Gross , Al Cooper, Mary Dunker , Frank Galligan , Karen Herrington , Greg Kroll , Randy Marchany
( present, absent)

Agenda

1. Continue discussion of InCommon Silver profile started at last week's meeting.
   1. Review "Meeting Notes" from August 5, 2010  for previous discussion.

Notes:

From August 5, 2010 meeting,
 
2. h. Perhaps a "layered approach" to issuing soft PDCs could be employed. With the first layer being easily obtained "regular" certs perhaps without in-person identity proofing and the next layer being a "silver" cert with all the required identity proofing.

1. 1. 1. Ismael commented that this is "technically" possible but would caution against "closing the door" on those that get regular certs.
      2. Ismael also commented that technically it would not be a problem to issue both types of certs to the same user so they would have a mixture of "regular" and "silver" certs, however, this may be a usability issue for the user.
      3. If a user's role changes they may need to change the type of cert they have. They could either have a mixture or certs or revoke the old cert and get a new one.
      4. What roles would benefit form a silver cert?
      5. Kevin commented that making InCommon Silver a goal for this project would make these certificates less desirable because they would be more difficult to get.
      6. Al commented that the goal should be to get as many certs, into as many users hands as possible, i.e., easy dissemination.
      7. Identity proofing is a barrier to wide dissemination of soft certs.
      8. Perhaps we could issue different "level of assurance" (LOA) certs???
      9. If we issue different LOA certs, different workflows would be required. Also, we would need an upgrade path from LOA 2 to LOA 3 certs.

New questions (and perhaps some answers) from August 12, 2010, meeting:

1. Would a person be able to have both LoA 2 and LoA 3 certificates at once?
2. What LoA would be required for the Self Service PWd reset? Kevin: A LoA 2 certificate that was obtained by authenticating with PID/password and another factor such as SMS/OTP to a cell phone would be sufficient to have the certificate used during the self-service password reset process. The implication (Mary's interpretation) is that authenticating with PID and password alone to request and remotely obtain a soft PDC would not give a high enough level of trust in the PDC to use it to reset a PID (or Hokies or Oracle) password.
3. Password discussion:
   • Is it OK to use the same password on your Key store and your cert? The password is really to access the key store, not the cert. When the cert is issued it is delivered to the user as a PKCS#12 file also containing the keys, and the file will have a password. This password is the transport password, and is selected by the user at the time they request the certificate. Once in IE, you can export the file and not put a password on the file. The key store is whatever holds the privat key and public key (and cert) the transport password is used to protect the PKCS#12 file. The key store has a password also? Private key gets decrypted when imported into key store. The key store can also be part of an applicatioin (Windows key store, Java key store).You can password protect the key store? Yes, but may not be required to do so. If you set a password on the P12 file, we can make sure the pwd is not the same as their PID passwd. Middleware/IMS has a web service that can be called to check whether or not a user-supplied password is the same as their PID password.
   • In the process of importing the P12 file, you could store it without a passwrd,
   • If the password on the P12 file is not the same as the PID password, that would would be good.
4. Key pair discussion:
   • Can you have multiple certificates with the same key pair, each with a different LoA? Yes.
   • After you get your LoA 3 cert (in person), if the LoA2 cert used the same keys, the loA 2 key store could be used to decrypt information encrypted with the LoA 3 cert because the keys would be the same. Is this a problem?
   • This could be a problem if the LoA 2 keys were obtained by an imposter.
   • We need to understand the implications of a person having multiple keys.
   • If you have LoA 2 and want to get an LoA 3, do you need a new key pair? Once you get a Loa 3 cert, we would revoke the LoA 2 cert.
   • We think you should get a new key pair for a new LoA 3 cert, but you could still use the old, revoked LoA 2 cert.
5. When the user requests a Loa 3 cert, if they already have a LoA 2 cert, the appplication that handles the requests will let the user know they have a LoA 2 cert and will tell them their LoA 2 cert will be revoked when their LoA 3 cert is issued to them. The approver should not have to do anything special; the revocation will happen in the background.
6. We have encryption, authentication, signing, with 2 levels of assurance. This makes a matrix:

   LoA	authentication	signing	encryption
   2
   3

What are the use cases and the combinations we need?