August 13, 2003
Attendees

* Steve Worona, Educause
* Jim Jokl, U. Virginia
* Eric Norman, U. Wisconsin
* Scott Cantor, OSU
* Shelly Henderson, USC
* Nathan Faut, Educause
* Jeanette Fielden, Internet2
* Neal McBurnett, Internet2
* Steve Olshansky, Internet2

Discussion

Auditing: At the PKI summit a document about auditing that might be a good starting point was recommended. Barry has looked at it but was not able to make the call today.

There has been the ongoing discussion of whether the CA should be PKI-lite with no requirements imposed on campuses or audited to offer a higher level of trust. The idea of having two different OID's, one for each method, was revisited. The same I&A process would be done for both. If the campus only does the I&A, they would get one OID. If a campus does the I&A and turns in an audit statement verifying everything, they would qualify for a different OID that would allow them to cross certify. This does not mean the two would cost the same since Internet2 would have to do a different level of work for each. A campus could start at the first level and then later progress to second one if needed/desired. There will need to be research to determine exactly what Internet2 would have to do in terms of reviewing the audits. Jim's understanding is that Internet2 would not have to do audits on the CA. There was general agreement that it worthwhile to try and offer campuses more than one option. The next step will be to investigate more deeply to assess any potential obstacles.

Eric proposed that another way of doing this would be different CA keys. Neal felt that it makes sense to go forward with USHER at the same level as CREN. All the same I&A stuff could be used and then stand up a bridge certified root for schools ready to do bridge certified things. Jim felt it might be a more practical option to have the USHER CA and two different keys. It was agreed to pursue this option.

If USHER is implemented at a basic level what would be the benefits to a campus? If it resulted in being cross-certified it would be a question of which federal application is involved. It is not clear exactly what USHER would have to do to move from basic to medium.

Jim solicited any requests for changes in the profiles. Scott requested that DNS be added to the subject alt name profile since the old technique of using common name as the thing that you compare to in an SSL cert is being deprecated in favor of using a DNS subject alt name. The profiles will be the first official 1.0 draft but can be updated as needed.

Neal is talking with people working on OpenSSL certification about how to frame the issues and what is it that needs to be certified. Jim shared that Peter Alterman has agreed to help in finding the answer to "will there be any problems with medium or basic if you're using a certified crypto module that has OpenSSL as the API where the PKI operations happen in a certified hardware module."

What software to use to issue the CA's hasn't been decided yet. There has been good news about Microsoft's but it's not yet clear how it interoperates with the other sorts of infrastructures people have. Jim pointed out that for Microsoft a client access user (CAL) is required for each user. Without it you can't issue certs.

Scott's ready to put OSU in InCommon as a campus member assuming everything else is worked out, storefront, policy, INA, etc.

The results of the survey on obstacles to PKI as well as a follow-up survey up are available at: http://www.oasis-open.org/committees/pki/obstaclesfollowup.html. The top obstacles listed are signing documents, web server security, web services, and s/mime for e-mail. It appears that many people are trying to use PKI for many different purposes and have different opinions as to what is important. Please visit the link before August 31, 2003 when the follow-up survey expires.

Eric asked for a summary of the differences between the iKey 1000 and 2000. Jim's recollection is that the 1000 is a memory only device. The 2000 does all the crypto operations on the device, key pair generation and you cannot export the key.

Scott is interested in collected knowledge about java hardware acceleration and crypto. If anyone has information please mail it to Scott cantor.2@osu.edu.