November 19, 2003
Attendees

* Jeff Schiller, MIT
* David Wasley, UCOP
* Jim Jokl, U. Virginia
* Barry Ribbeck, UT–HSCH
* Eric Norman, U. Wisconsin
* Nathan Faut, Educause
* Mark Franklin, Dartmouth
* Jeanette Fielden, Internet2
* Neal McBurnett, Internet2

Discussion
Certificate Profiles:

Microsoft requires a CRL distribution point for their profile. Since a goal is to have Microsoft distribute the certificate, the profile will need to meet that requirement. It was agreed to add the AIA back in with LDAP and a pointer to a PKCS7.
[AI] Jim will ask Steve Hanna to review the certificate profile.
USHER and InCommon status:

Usher low and Usher basic are names that have been used. There was concern over low cheapening USHER and basic confusing it with the federal basic. After discussion of using case, level or type, it was agreed to use the term level to describe USHER. For example: US Higher Education Root Level 3 version 1, or Level A version 1.
HEBCA CP draft:

The changes made to the HEPCA Bridge CP draft at the September meeting are up on the HEPCA web site. . RFC 3467 is the finalized version of the son of 2527. David has put together a mapping matrix since the format of the CP is very different.

Volunteers for next TAG activities identified at the Internet2 Member Meeting BoF

1. Hardware tokens – U. Virginia, Dartmouth, U. Texas
2. Windows Domain Authentication – U. Virginia, U. Wisconsin, Texas, Dartmouth is interested but at a later time.
3. CA Audits – U. Virginia, U. Wisconsin, U. Texas
4. TLS – Virginia, Dartmouth will check with others on campus, U. Texas would like to lurk.
5. Update work on S/MIME – Dartmouth, U. Texas, U. Wisconsin, U. Virginia, Brown
6. Intro materials for schools getting started – USC, Dartmouth
7. 45:00 Barry talked about some document, Dartmouth and UT have been doing calls with Educause.
8. Grid integration work – U. Virginia, USC
9. Document and web form signing. – U. Texas, Dartmouth, UCOP, Neal McBurnett
10. CA Private key protection – U. Wisconsin, U. Virginia

Private Key protection discussion:

The goal is to convince people running CA to write up how they’re doing they’re private key protection so practices can be documented and shared.

What exactly is being protected? How careful do we have to be? Are we protecting the university? Grants? What? It depends on the applications and the CA’s level of assurance.

At U. Virginia they have two RA’s, one real, one virtual. The users first go to a web site, request a cert and generate a signed object. The second signed object is generated by the RA, who checks the identity in a physical sense. Those two objects go over a serial port to the object that has the CA in it. It is not totally offline since there are some RS232 ports between machines that are online and the actual CA machine. . It takes a signed object from the virtual CA and a different signed object from a real CA before the CA machine signs the certificate in question. Basically it’s a pass through a machine. Takes signed objects from other locations, and the CA validates them both before issuing the certificate. It’s a compromise between ultimate security and having several RA’s on campus where people can go.

For SURFnet, their CPS has info on how they used to do it. Now they’re using keon and encipher. The box that has the encipher card is on a networked machine with all kinds of protections.

As Wisconsin the key is completely offline and there are seven locks requiring two people to access the key.

MIT has two private keys. The server CA is offline. This key is kept on CD–ROM and loaded on a laptop when needed. The client CA is online for people to get their certificates. That key is in memory on the machine.

In general the convenience of offering certs on demands is why a CA is online. To issue a large number of keys with a completely offline CA, several might be needed to offer the same level of service. It is a balance between security and convenience. How much security does which application deserve? The approach might be to look at the most sensitive application you plan to support from a security point of view.

Action Items

1. [AI] Jim will add the link from Steve Carmody’s document to the Hepki Page.