Technical Activities Group Meeting Minutes
HEPKI-Tag Call

May, 7th 2003
Attendees

* Neal McBurnett, Internet2
* Jeanette Fielden, Internet2
* Eric Norman, U. Wisconsin
* John Douglas, Georgia Tech
* Jim Jokl, U. Virginia
* Gary Chapman, NYU
* Steve Olshansky, Internet2
* Renee Frost, Internet2
* Scott Cantor, OSU
* Keith Hazelton, U. Wisconsin

Discussion

Discussion of tasks to set up a new Higher-Ed trust infrastructure suitable for use by InCommon, Campus CAs, etc. The list is available at: http://bcn.boulder.co.us/~neal/i2/crencat.

With the new CA do we need to put a more stringent requirement on what campuses can and can't do? Is the PKI-Lite policy sufficient? All the CREN one says is due diligence has been done, that the person signing certs is legally qualified to speak for the institution. It is difficult for a relying party to gather any high level assurance on what is going to happen with that campus. It may be sufficient because the relying party should look at the campus CP and determine if they want to trust it.

What would a CP need to do be useful for InCommon? Is Shibboleth going to take campus signed server certs? Can't divorce the two if it's going to work either way. If the only thing Shibboleth accepts is Internet2 issued certs then you can divorce the policy piece. For the purposes of Shib it would not be of any real significance that a particular origin sites key was signed in a chain that was rooted in CREN, since there is no real significance to that root. There would have to be trust meta-data available to establish that trusted connection. If you have something issued by the server CA there would be some implicit trust you can establish.

It was agreed that Shib is a software base that lots of different policies can be implemented with. InCommon is one implementation with a specific set of policies. There is a need for extra meta-data for InCommon. At this point there is no need for an extra level of CP for InCommon. The previous notion of CP for a new higher education CA that is basically very free in terms of what enterprises can roll out will be retained. Does the InCommon CA want to impose some minimal set of policies about what the campuses that it signs for will have to meet or not?

Suppose another option is to have multiple CA's and levels. The Root cert, which can do lots of things, an enterprise CA at the higher education PKI-lite level, and a higher or lower one.

If this CA is going to be cross certified with the Higher Education CA, which will cross certify with the federal bridge, there is probably some need to have a minimal level of assurance imposed on the campuses. If the campus certifies with the bridge they'll have to do a lot more. If the higher Ed CA were what certifies, it would be nice to have something like PKI-lite imposed on the campuses that keeps the policy mapping reasonable. It was agreed in general that it's unlikely that anyone would want to have an on campus CA rooted in the InCommon CA that was anything less than PKI-lite. All it says is that you will do what you do on campus. Can't PKI-lite be gotten to the point it can be certified as basic since it's close now? It was agreed that this should be explored in greater detail.

David Wasley has written a document on assurance levels. Since David was not able to be on the call assurance levels will be discussed on the next call.

The HECA will be the overall root and there will be an InCommon CA just for directly signing InCommon servers. A certificate hierarchy diagram would be helpful to create a picture of this.
There will be one root with two CA's. One of the things that root will sign is a signing certificate that the InCommon CA will use for Shib certs and that same root will also sign the campuses at a parallel level.

During the discussion it was discovered that in the draft PKI lite recipe section 2.1 it is specifically noted that a PKI-Lite CA should not issue an authority certificate for another CA. Jim explained that the intent of that is to prevent campuses from signing other roots, signing certs, i.e. Virginia can't sign certs for Wisconsin. If you're implementing a multi-level CA on your campus there's no prohibition. The phrase will be edited since the intent is not to prohibit hierarchy on campus.

Procedures will need to be added to handle revocation since that wasn't part of the CREN CA.

Keith has mailed out a link to the grid certificate policy draft and has noted that when trying to find a common denominator of trust levels, it would be nice if PKI-lite were mappable to the grid one.

Another suggestion was to make sure a name displays with the certificate download prompt. Because there was no common name in the CREN one it made it an issue when you're trying to help the user find a name in certain complications. It's also important because names are the first and often the only information shown to a user before asked, "Do you trust this?"

There are two companies doing low assurance certs. Both claim to be rooted in Baltimore, but one appears to be rooted at GTE. It may be of interest to investigate the issue further to see if this could be an alternate way to get into the browsers vs. creating a root and trying to get it loaded in all the browsers.

Next call will be Web May 21 2003.