Technical Activities Group Meeting Minutes
HEPKI Tag Conference Call

December 17, 2003
Attendees

* Jim Jokl, U. Virginia
* Eric Norman, U. Wisconsin
* David Wasley, UCOP
* Scott Cantor, OSU
* Steve Worona, Educause
* Barry Ribbeck, UT-HSCH
* Mark Franklin, Dartmouth
* Jeanette Fielden, Internet2
* Renee Frost, Internet2
* Ken Klingenstein, Internet2

Discussions
Profiles Discussion

Jim asked if there was a difference between CRL signing and offline signing. Barry indicated he didn't find anything about offline signing in the RFC. Key usage will be deleted from the next draft. E-mail addresses have been edited out as discussed previously. Language has been inserted in all three profiles explaining what putting in a PKCS7 for authority information access means. Please review.

There may be a cost impact in how the CRL's are handled. There are a couple of options. 1) Having the operator of the USHER CA immediately issue a CRL. 2) A guaranteed monthly refresh, or next business day if there is a request for revocation. If a campus wanted to revoke sooner they could revoke all their certificates while waiting for the USHER CA.

There are two issues: 1) How frequently are we willing to issue a new list/CRL? and 2) How frequently do you expect the relying parties to check for a new list? Internet2 can set the frequency in the Shib code, so it is the generic browser case that's of concern. We can say that we will guarantee an update once a month, it might be updated sooner than that so if it is important to you check for updates more often.

Is next business day soon enough or should it be 24 hours? It may cost more to do 24 hours than next business day. For USHER lite next business day would be fine, but for InCommon 24 hour might be more desirable.
[AI] Mark Franklin will check on costs to do next business day CRL update versus 24 hours.

Eric asked about the MIME type. The one talked about is the one invented by Netscape. What that MIME type means is there are PKCS7 certificates then prompt me and ask me about the first one. What is wanted is an S/MIME one, perhaps application PKCS signature.
[AI] Jim will look at the web server config MIME type and mail the information to the list.

In the InCommon Server Certificates end-entity profile the e-mail addresses have been removed and the authority information access added. Enhanced key usage as server auth and client auth will be left in. The phrase "or the identifier assigned to the institution by the federation." will be added to the current description. Jim will also add a second example to show an actual school name instead of a DNS name.

Should the InCommon CA be combined with the USHER CA? If we are successful with the right set of audit tools it would be nice to have one root that handled everything. The vulnerabilities are small because you need a handle to make sense of things. Other parts of the communication protocols would have to break or be guessed to compromise the system, assuming the key was compromised. If two InCommon keys are issued at once to a campus, a primary and backup, then if one is compromised they could decide if they want to switch to the backup. If the handle server were compromised then either the certs need to be revoked in a timely manner, or something manual might need to be created. An additional option is if the targets update site meta-data frequently that becomes the equivalent of verification. So there will be multiple methods available.

Some institutions have concern over laws in their state that require the use of certificates issued from state approved/qualified vendors and how they may be impacted if InCommon requires the use of the InCommon CA. There are questions over how narrowly or broadly the state requirements should be interpreted. One possibility is to create a list of commercial CA's whose processes create a cert that would be acceptable for InCommon. A surcharge could be assessed for the additional identity proofing and cert verification that would be needed.
S/MIME

Jim has placed the certificates he received in the repository. The next step will be for people to sign and send messages to the list to check inter-operability.
Jim will send messages for Mulberry and Communicate Pro.
Eric will do Pine and is looking for someone with a connection Evolution (Red Had Linux).
Mark will do Thunderbird, and will check with Mac users at Dartmouth since it does not appear that the latest Apple mail client has support for S/MIME.

The current PKI-lite S/MIME Email Clients Summary is at:
http://middleware.internet2.edu/hepki-tag/pki-lite/hepki-tag-pkilite-smime-clients-5.html
The following rows will be added to the table:
Does the client send the whole cert chain?
If an encryption certificate is sent in the S/MIME attributes does the client do a reasonable of job of getting it into the address book and does it expect a Microsoft OID?
For the LDAP checkbox there will be space for comments/details on how well the program looks up certificates in LDAP.
Footnote area for items that are a serious concern.
Compatibility with mailing list software and what S/MIME enabled mailing list software is available.


Action Items

1. [AI] Jim: Will draft a paragraph outlining that for the http URL we expect it to be pointing at a PKCS7 that will operate with Windows.
2. [AI] All: Please send Jim signed messages so he can get the certs up on the PKIdev repository for downloading.
3. [AI] Jim will send e-mail to the list of what certs are available on PKIdev. [AI] Mark Franklin will check on costs to do next business day CRL update versus 24 hours.
4. [AI] Jim will look at the web server config MIME type and mail the information to the list.
5. [AI] Jim will send S/MIME signed messages for Mulberry and Communicate Pro.
6. [AI] Eric will send S/MIME signed Pine and is looking for someone with a connection Evolution (Red Had Linux).
7. [AI] Mark will send S/MIME signed Thunderbird, and will check with Mac users at Dartmouth since it does not appear that the latest Apple mail client has support for S/MIME.