June 4, 2003
Attendees

* Jim Jokl, U. Virginia
* Renee Frost, Internet2
* Nathan Faut, Educause
* Steven Carmody, Brown
* Jeanette Fielden, Internet2
* Ken Klingenstein, Internet2
* Neal McBurnett, Internet2
* Eric Norman, U. Wisconsin
* Steve Worona, Educause
* Bob Morgan, U. Washington

Discussion

The PKI-Lite recipe draft that Steven's working on is at: http://stc.cis.brown.edu/~stc/Projects/Security/PKI/PKI-how.html. One of the reasons for distributing the document is that there are campuses trying to determine if it's feasible to deploy S/MIME and there might be a real opportunity to move S/MIME usage forward. It was suggested to reactivate the S/MIME lists with the campuses that have expressed interest and try to restart the conversation and bring to closure this time. The first part of the document is an introduction to provide a historical perspective on PKI. It can be prefaced to say that if you're already familiar with PKI you can skip to the development part which talks about PKI-Lite. Other ideas for a document roadmap will be co-coordinated via e-mail. CREN's "Guide for Getting Started with Digital Certificates" http://www.cren.net/crenca/onepagers/guidebook.html may provide a model as well.

Higher Ed root: There are issues that still need resolution that will affect what goes into the CP. One is choosing hardware to hold the new key that does not constrain us exclusively to that hardware. The other is what exactly should be included in the CP. The CP is the activity with the longest latency so moving forward on it is key. The grid community just finished a CP that should be examined for applicability as well as the Citizen and Commerce CP from NIST. (http://www.cio.gov/fpkipa/documents/citizen_commerce_cpv1.pdf). If PKI becomes established within the federal government there will be a need for equivalences early on.

Wisconsin has been thinking about deployment of server certificates and deploying certificates that identify a site as HIPPA compliant. The question has come up, does issuing the certificate mean we're going to audit all their equipment and make sure it is compliant? No, what it does mean is there will be a signed statement from the administrator of the equipment, stating that the equipment is HIPPA compliant.

There has been previous discussions about possibly trying to root the higher ED CA in one that's already in the browsers as opposed to a self signed root. FreeSSL certs (http://www.freessl.com) are signed by Baltimore, which are in turn signed by GTE. There are several questions that need to be understood first. Is there a way of layering root on root? Is there a migratory path? This will need to be determined soon since it will affect the policy and practices that need to be written.

Is there is anything the higher Ed CA imposes beyond the INA? If we talk about any requirements on operational procedures on campuses the most we would ask for is self-audit, or even internal audit in the IT organization. It is reasonable to describe some good practices and have people audit against them but we won't be the ones auditing. We're asserting that we've done a better job of identity proofing on the enterprise, and recommending a set of management practices for the keys but are not warranting that they are followed. All of which will have to be carefully documented and incorporated into the storefront procedures. How do we cover the liability issue for Internet2? The language used in the Abilene agreement will be examined to see if can be used here as well.

Pricing and relationship to Internet2 membership is also a consideration. It could possibly be an additional component to the membership that could be activated. The amount of vetting needed, number of keys, and source of the certificates being used would also be a factor. Ken will check internally on what the considerations are.

To what extent can we upgrade this migratory thing over time and use the same OID? If the policy changes dramatically should the OID also change? The problem is that it would imply retroactive application and that we've been doing that level all along. This argues for starting off with something that seems to meet the basic level for the long term.

With campuses that are not ready to deploy their CA but need server certificates they could decide their distinguished name now. Then, when they take it over they would not have to worry about rounding up all the certificates already out in the field. It would still mean that when they switch over to doing their own CA that they might have to deploy their trusted root. By not changing the names they might be able to avoid reinstalling new certificates everywhere. The details would have to be worked out.

If the management practices are only recommended that implies that we're not going to add any kind of requirement for a school to say they're going to do something like PKI-lite. There might be two flavors of institutional certs with certs issued for Shib signing have one set of rules and ones issued for enterprise, general use, and wildcard having different rules. You could run Shib by getting server certs from InCommon or by getting your institutional cert signed and issuing server certs yourself. This would need stronger requirements would be put on the universities to prevent institution A giving out server certs for institution B's servers, or institution B issuing end user certs at C. The CP should say that if the relying party wants something more it needs to negotiate that out of band with the originating party.

One other thing to consider about the CP is privacy. It can be stipulated in the CP that relying party must not misuse the information it's given. Misuse needs to be defined in some manner and examples provided, i.e. storing names internally fine, selling or using in other context is unacceptable. Stored names from authentication under some applications might wrong.

If there are other dates/releases put into danger by slippage of the date for the CA please let Neal know.

Next call is Wednesday June 18, 2003.