March 12, 2003
Attendees
* Jeff Schiller, MIT
* Jim Jokl, U. Virginia
* David Wasley, UCOP
* Renee Frost, Internet2
* Bob Brentrup, Dartmouth
* Neal McBurnett, Internet2
* Eric Norman, U. Wisconsin
* Steve Olshansky, Internet2
* Ken Klingenstein, Internet2
* Jeanette Fielden, Internet2
* Bob Morgan, U. Washington
* Don Douglas, Georgia Tech
University
Discussion
Can a relying party check a CRL in the CREN CA? The CREN CA does not have CRL. It is on the list to do. There's no pointer in the CREN root certificate that would help you find a CRL or a repository. Is there a plan to issue a new root with a CRL pointer? For purposes of stability it won't happen right away. If we generate a new root we probably want a new box, and to think about what the new name would be.
Repeated concerns were expressed over vendors ultimately having control of the key on the boxes they sell. What happens in situations when vendors are acquired, sell, discontinue, cease to exist or are otherwise unable to support a box?
A box like Safekeeper gives you defenses against three types of attacks:
1. Online network attack
against your server. If
a key is in the box no matter
what someone does is terms
of taking over the server
that's plugged into the
box, the worst thing they
can do is sign certificates,
but they can't get the key
out.
2. Auditing against legitimate
people acting inappropriately
because it enforces the
serial number constraint.
If the box were used to
sign a certificate for CREN
without authority and not
put into the repository
there would be a gap in
the serial number and who
generated it.
3. Protects against a rogue
operator since no human
ever gets to know the private
key. It's that protection
that generates concern since
the vendor controls it.
Ken has talked previously about the concept of a laptop token. A laptop computer with a RS232 port or dedicated Ethernet port would talk to the server but the only operations would be PKCS11 type token operations. Essentially it's a smart card implemented in a general-purpose computer. The idea is that the laptop is small so it could be locked up when not being used. It does not give you protection against the rogue employee who could extract the key in an unencrypted form and misuse it. But because you can get the key out you don't have to have it in anyone's particular box.
Jeff expressed interest in a box that you can load the key into but can't take it out of. The key is generated among a group of trusted individuals. All individuals witness the insertion of the key into the box so it can't be extracted. Then the key is placed in a safe deposit box that takes at least two people to access. If there is a failure, a quorum of the trusted individuals can opt to retrieve the key.
Wisconsin is considering addressing the rogue issue by having any operations of the top-level CA manufacturing box witnessed by high-level university employees, the keys will be recorded on floppies and encrypted and only they can decrypt them. While the idea is to build trust concern was expressed that someone might give the key to another employee to "safeguard" for them resulting in a reduction of security. It changes the threat model but does not eliminate it.
There is a strong desire to revise the CREN Certificate Authority Temporary (CAT) very soon and start to offer services. Ken expressed that a policy OID in CREN CAT is highly desirable and that one possible approach is to stair step towards real PKI with a view toward experimentation and managing exposure for all involved.
There are three activities that are closely related in this space.
1. The Higher Ed Bridge
is an overarching activity.
The desire is to find ways
where the operational aspects
of InCommon and CREN CAT
can be leveraged likely
in the vetting process for
both activities.
2. Re-establish the CREN
CAT.
3. In conjunction with Educause
develop an RFP to see if
we can obtain a bulk deal
for higher education from
commercial certificate vendors.
The request is that the
CP they operate under be
as consistent as possible
with the CP the CAT is operating
under to make any later
mappings easy. What level
of assurance should the
Higher Ed policy have? The
requirements for medium
and high are not yet really
established so basic would
be a good target.
The CAT should function at medium and support basic for users. David sent out a document to the list a couple of weeks ago that shows the CP language that distinguishes the different levels of assurance. The difference between basic, medium, and high levels is mostly in the identification process. The operation of the CA is roughly the same. There is a greater distinction between rudimentary and basic. For CREN CAT it was decided that it should function at one level higher than the certificates it issues and currently there is really only a market for basic. The difficulty with the higher levels is ensuring through the vetting process that the person is authorized to represent the institution since forging letterhead and other credentials is not necessarily difficult.
The general consensus was that there should be a separate set of levels that is appropriate for universities. One level of assurance may be fine for most universities and most functions with many or most only needing university basic. Mapping to the Federal levels may not be one on one, i.e. University high may only map to Federal basic. The federal citizen commerce CP is evidently emulating PKI-lite and should be analyzed as well. We also want to be able to cross certify with the feds so going back to the higher Ed policy document in some manner is needed.
Jeff explained that for the CREN CA he has not received consistent feedback if that it's rudimentary or basic. Where does PKI-lite fit right now? If Jeff's were not basic what would we have to do to make it basic? One consideration is whether to follow the Federal levels or redefine and just ensure that we can map to them.
The issues of auditing and liability need to be addressed to move this forward. Liability: Say an institution is running at basic. A student loses a certificate, requests a new one, it's issued, but ID is not checked. Maybe it's not the right student so what liability now accrues to the institution? If the primary interface is clerical workers and students, are you going to trust them to follow procedure and if they don't what's the cost? The federal government doesn't have to worry about liability, due to sovereign immunity; if a federal government misbehaves the government is not liable. If a business employee misbehaves the business is liable.
Where is the balance between limiting liability and ensuring the credentials have value? The relying party gets some benefit from accepting those credentials and they have to accept some risk. What we're really asking the relying party to rely on is that we're doing a reasonable job for our own internal identity process. If you want to rely on what we consider reasonable internally, that's fine.
Can we write a CP that can be extensible over time? If we insert an OID can the object of an OID be evolutionary? What's in the certificate is a CP OID which is used to refer to a level of assurance not the certificate policy itself, at least as the federal agencies have constructed it. That in itself doesn't necessarily refer to a specific policy. There's also a CPS URI that is a URI that points to the certification practices statement that is required to point to the certificate policy. So there is an indirection there that could allow for change of the policy without reissuing certificates.
We can't redefine the levels of assurance but we can add levels of assurance. You can add a level as long as the strictures that related to that issuance are the same. If you change the definition of level of assurance you can't use that same OID. As long as your certificate policy maintains at least an equivalent definition of the level of assurance you can use the same OID.
One of the things that was appealing about PKI-lite is that it said very little. If you look at the higher Ed and Federal policy for basic it's very prescriptive. If all else was equal and you didn't have to worry about everything be perfect every time. PKI-lite would probably be the equivalent of basic. On the liability side, would having something that's prescriptive opens us up to more than something along the lines of a generic disclaimer?
In terms of the liability clause in the current draft CP it does have a dollar value. Remove that and simply say in terms of liability the university issues these certificates for its own benefit, if any one else wants to make use of them that's at their own risk. It's declaiming liability but it's saying these things do have value that's why we're issuing them.
After discussion it was initially agreed that the best approach might be to state something of the nature that: here's what we do, we do our best to make sure it happens, but we can't guarantee 100 % so you assume some risk by using it. We can create mechanisms to educate institutions about the issues, negotiate the learning curve, and not but ourselves in a position that we can't move from if we want to do more later.
There is a distinction between issuance of the credential to right person and verification of that, and fraudulent use of a credential. A verified person can fraudulently use a credential. The issuance of the credential is just one step in the overall reliance. Auditing is another.
Support and infrastructure is another consideration. If only four people on a campus are authorized for a particular level it's not reasonable to have to design an infrastructure for the entire campus based on those four people. Additionally, there is concern that different parts of the Federal government will require different methods.
It is possible to visualize joining the higher Ed Bridge and basically agreeing that we will only put the policy OID's in those certificates of those institutions that have agreed to follow by those policies, but that institutions don't have to do that. You should be able to say, we're not going to meet any of those levels so don't put the policy OID or put the PKI OID that doesn't map to anything that's in the Higher Ed Bridge. A campus could issue certificates with the PKI lite OID in them and for the four magic individuals issue certificates with an OID that follows what the feds say we have to do. That process won't involve the clerical workers and the risk taking of concern on a day-to-day basis.
The way this works, a relying party says I have this certificate and I require this OID, this is my policy that I require this certificate meet before I grant my service. There is an evaluation process where you create the certification path from that certificate in hand to a trusted route. As you go up that chain you follow an algorithm to say, "is the OID I'm interested in present?" The subject has to have the right OID. The subject of the certificate has a matching OID. As you go up the hierarchy you see the issuing certificate has that OID and you keep going up the chain until you find the root. One of the problems is that if you invent a new OID the root doesn't have it, which creates a problem. So you reach the trusted root or the trusted root you reach is the bridge. The bridge can do mapping of OID's. It turns out the certificate may have an OID you don't recognize but it's really equivalent. One of the things bridges do is that mapping. You can also do mapping within a certificate. Finally at the end, given a yes/no answer on did this certificate have the OID I needed? So what would happen is the campus CA would have the set of OID's and the superset of whatever it wants to issue. It would have to handle it's private key in the most prescriptive way of all those OID's. If at different levels in the hierarchy you have a different set of OID's for the policies, it is required that a hierarchy maintains a consistent set of OID's throughout the hierarchy because there is no mapping otherwise. There's no mapping mechanism except in the cross certification.
In essence what the CREN CA has to do is operate at as high as level as is practical. The only thing we should require of campuses is that if you mark a certificate that claims to have the OID for a high level of assurance that it must really be compliant for that level. The practical problem is that is very difficult to get a new OID into the chain.
Questions raised include: How many people are really using this stuff, and how they're using it? How ingrained is the CREN cert, and what are you using it for? How will the student clearing house l be doing their certs, how can the hierarchy be maintained, how can institutions still control who they use, and how to authenticate from a remote site?
The key issue is how to preserve the ability to do something with the federal along with our desire to keep things more in the existing PKI-lite space. How many people understand it at what level how InCommon is doing things and what the different technologies imply in terms of how you would preserve the same notion of trust across the two?
The discussion will be picked up again on the next call Wednesday Match 26th, 2003.