March 26, 2003
Attendees

* Jim Jokl, Internet2
* Scott Cantor, OSU
* David Wasley, UCOP
* Bob Morgan, U. Washington
* Neal McBurnett, Internet2
* Jeanette Fielden, Internet2
* Eric Norman, U. Wisconsin

Discusssion

CREN CAT: Ken will make a presentation on CREN CAT and InCommon to the NPAAC tomorrow.

There was discussion of granting a set of InCommon signed server certs when a campus successfully completes the INA process. A chicken and egg issue exists with campuses and Shibboleth. We say that you need to supply the name of your handle service, attribute authority and trust anchor that is asserted by a certificate and it has to be validated. So campuses say we want to use our campus CA's for that purpose which raises the question of what's the right thing to do?

If there was a policy OID that was just used for this purpose then it would be easy for the targets to say: "if you go with this OID you're fine." When you finish the INA process you get either a campus root cert signed by the CREN CA and/or the server cert that you need for your Shib servers directly signed by that CA. In a case where the campus wanted to keep their own PKI standalone and not be part of any kind of a hierarchy they would simply take the server certs. Someone who wants to be part of the hierarchies could either take the server certs and/or issue them their selves from their own CA.

If there are getting their campus root signed by InCommon do we want to accept the server certs that campus issues for use with Shibboleth or do we want to get everyone to get a couple of certs directly from InCommon? CREN's philosophy of due diligence was that they made sure they were talking to the right person on campus but they didn't deal with how the campus runs their own CA or what INA process they use after that. We'll be running the InCommon CA so we can be confident about whatever process we use with the server certs that were issued directly by InCommon to Shibboleth. There's a question of: do you want to trust the Campus CA assuming most will work at the PKI-lite level? If you don't trust the campus to manage the CA properly you shouldn't trust them to manage a handle server correctly. If you trust them to issue certificates to end-users you should trust them to issue certs to servers.

The recommendation for the InCommon CERN CA is the INA process yields an institutional cert if the campus wants it, a set of Shibboleth certs if they want it, and Shibboleth won't take commercial CA's. The campus-signing cert can be used to sign the campus Shibboleth certs if desired.

How do you continue service and replace a key after it's been compromised? What would meet Shibboleth's needs for revocation? What kinds of features need to be built into Shibboleth? Getting another certificate implies a fair amount of overhead. If you look at the process CREN has in place already established a secure channel to the institution if that can be reused the process could be pretty quick. Difficulty could be If it's been years and all the PGP keys have been lost, etc. A second possibility is having a second key deployed and ready to use. There needs to be process in place to handle the issue.

What OID should go into the certificates? Is there a single InCommon policy? Is there a set of OID's that should go in that would allow Shibboleth to be separate from InCommon? What are we going to actually require?

There is no policy OID in the CREN piece and no way currently to deal with it. Is the policy OID and the server certs specifically for Shib the same or different from whatever policy we're going to assert when we sign a campus root CA? In theory, the CAT CA operated under the draft Higher Ed CP would require that all CA's that issues authority certs to operate under this same identical CP. It would be able to use the same identical set of CP OIDS. There is no good way of mapping OID's in a hierarchy. There's the cross certificate policy-mapping extensions that is used to indicate how to map from one hierarchy to another but within a hierarchy it's not supported. The only way you know to trust a CP OID is you know what that hierarchy supports so that any certificate issued within that hierarchy will tell you by it's OID what level of assurance to place in it.

Having a PKI-lite OID is possible. There are five defined levels of assurance. You could have a sixth one which could be PKI light which relying party, if they understood what it meant, could choose whether or not to rely on it. In order for the campus CA to issue both very lightweight and more trustworthy certificates it has to operate at the highest level of assurance that those certificates represent. So if light is less than the Shib required basic, the campus CA then has to operate at the basic level of assurance. If we are going to make reuse of OID's then within a hierarchy we should require the use of the same set of CP OID's throughout the hierarchy.

David: We could, whoever runs this CAT could choose another OID to represent PIKI-lite and that OID could be used at root level or by subordinate CA's. Trying to avoid that campus with CREN cert picks own set of CP OID's and no one else knows or understands unless they read their CP. That won't scale very well. Makes CP OID more or less useless. Outside campus no one will bother to find out what they mean. To make them meaningful start with a requirement that in a hierarchy all subordinate CA uses the same set of OID's the root does and it could include an OID that represents PKI-Lite or one for Shibboleth.

Having an OID that says "here's the rules", is useful only if everyone asserts that. Many campuses may say we just want to do it ourselves because there isn't anyone but us relying on this, and we're not promising anything to anyone else. So saying: "pick from this set of OID's and if you want to do cross-campus stuff it's only helpful if you tell us what you're doing", makes logical sense. There's also the issue of campuses that already have vendors relying on their certs and convincing them to switch.

What attribute would we want to have in there so that future Shib code could say, OK I trust the InCommon root and there is an attribute that tells me since it came down through here it's OK and I'll trust that distributed meta-data hierarchy? Essentially something that labels it as an InCommon procedure. I.e. if you join a club you're agreeing to do certain things with the attribute authority and how you're going to protect it. If you agree to follow that set of rules you're allowed to put the InCommon OID in the certificate.

Would this add any real value? When the membership in InCommon is set up, there's an INA process that identifies the responsible party on campus. The meta-data for that campus is created. The name of the platform that will run the handle server and/or the attribute authority is provided. It's presumably trusted because it's done as part of its INA process for the membership. So what the relying party needs to do is believe that the signing certificate or the server identity certificate that's used within the Shibboleth context legitimately belongs to that platform. It's not so much a matter of whether the certificate is labeled as being sufficient for Shib but that it legitimately belongs to that platform, that the issuer of the certificate is one we trust to have done the right thing as that has been defined. In the case of the CAT we can simply define that it does the right thing.

Goes back to the fundamental question of: Is the InCommon CA going to simply do due diligence to identify the campus contacts or is it going to impose policy further down? Also gets back to the question of: "what does it mean for the CAT CA to issue an authority cert?" Does it imply any sort of trust-worthiness or does it simply mean that somebody convinced them to issue a CA's authority cert with a certain name in the subject?