Soft Personal Digital Certificates project meeting

Tuesday, September 27, 2011; 2:00 p.m.; AISB-208

Invited

Ismael Alaoui, Marc DeBonis, Mary Dunker, Daniel Fisher, Frank Galligan, Dave Hawes, Karen Herrington, Greg Kroll, Ken McCrery, Kevin Rooney

Agenda

1. SoftPDCs will be published to ED-ID and Active Directory.
2. User attributes appearing in SoftPDCs include, Name, eMail Address, and UID. If there are privacy issues, visibility of these attributes should be managed by the user and by default published with visibility turned off.
3. SoftPDCs will be published directly to directory considered to be the authoritative source(ED-ID?) using the native EJBCA publication facility at the time a SoftPDC is issued.
4. To help avoid confusion, only the most current certificate issued off a user’s active key pair will be stored in the directory.
5. SoftPDC updates will be propagated to the secondary directory (Active Dir) from the primary. What is the current process for keeping ED-ID and Active Directory in sync?
6. When an active key pair is revoked, its SoftPDC will be removed from the directory.
7. Is there a test directory system that can be used by SIES for ED-ID? For Active Directory?
8. Next steps?

Attended

Ismael Alaoui, Marc DeBonis, Mary Dunker, Daniel Fisher, Frank Galligan, Dave Hawes, Karen Herrington, Greg Kroll, Ken McCrery, Kevin Rooney

Meeting Notes

1. SoftPDCs will be published to ED-ID and Active Directory.
   • No problems or concerns were voiced.
2. User attributes appearing in SoftPDCs include, Name, eMail Address, and UID. If there are privacy issues, visibility of these attributes should be managed by the user and by default published with visibility turned off.
   1. If email address is pid@vt.edu the publishing these with visibility turned on may be a problem for those suppressing their pid.
   2. It was agreed that the preferred email address would be used with the understanding that this must match the email address on the certificate. If the user changes their preferred email address they will have to get a new certificate.
   3. There are issues with suppressing information in the Active Directory.  We can probably make it visble or not but not sure how apps would take that.
3. SoftPDCs will be published directly to directory considered to be the authoritative source(ED-ID?) using the native EJBCA publication facility at the time a SoftPDC is issued.
   1. The authoritative source is the Registry.
   2. Data is propagated from the Registry to the Enterprise Directory (ED).
   3. Daniel's team will design a web service for Frank & Ismael to use.
4. To help avoid confusion, only the most current certificate issued off a user’s active key pair will be stored in the directory.
   1. Not a problem for ED. We can make it work how ever we want.
   2. May be a problem for the Active Directory (AD) as users can insert a certificate into their AD record several different ways. Can be controlled/prevented on the server side (but its all or nothing).
   3. Marc will analyze the production AD and see if any users have published a certificate. (If not then this issue may be mute.)
   4. It was agreed that the simplest/best approach would be to only store the most current certificate. Overwrite any existing certificate with a newly issued certificate.
5. SoftPDC updates will be propagated to the secondary directory (Active Dir) from the primary. What is the current process for keeping ED-ID and Active Directory in sync?
   1. See https://www.middleware.vt.edu/doku.php?id=middleware:ed:architecture
   2. Basically data flows from Banner -> Registry -> ED -> AD
6. When an active key pair is revoked, its SoftPDC will be removed from the directory.
   1. All agreed that this was a good idea and probably a best practice.
7. Is there a test directory system that can be used by SIES for ED-ID? For Active Directory?
   1. SIES should already have access to a develop instance because of work with eTokens.
   2. Access to a develop instance of the Registry will be needed.
   3. Once requirements are completed Daniels team can put web services into develop within one week. A November/December timeframe was mentioned and Daniel said that should not be a problem.
   4. M:SIS have a dev VT AD for SIES to work in.
8. Next steps?
   1. Schedule another meeting of this group next week or later to review action items.
   2. Frank will plan to give an overview and demonstrate a working prototype at next meeting.