January 28, 2004
Attendees

* Mark Franklin, Dartmouth
* Jim Jokl, U. Virginia
* Jeff Schiller, MIT
* Eric Norman, U. Wisconsin
* Barry Ribbeck, UT-HSCH
* Shelley Henderson, USC
* Bob Morgan, U. Washington
* David Wasley, UCOP
* Jeanette Fielden, Internet2
* Renee Frost, Internet2/Michigan
* Neal McBurnett, Internet2

Discussion
S/MIME certificates

Jim stated that he was unable to import U. Virginia's certificates into the current Apple PKI client so he can't test S/MIME or ETLS functionality. The issue is that Apple rejects any certificate that has basic constraints in it that are not marked critical. They have provided Apple with examples of a number of root certificates in the Microsoft cert store that come with basic constraints not being set to critical. Apple will relax that requirement in their next set of updates. Basic constraints must be marked as critical to use the current version of the Apple PKI. Apple is the only one that rejects the certificate if the basic constraints are not marked critical.

The RFC states that basic constraints should be marked critical. Should the PKI-lite profile be amended to reflect that? It was agreed that the profile should indicate that new profiles should have basic constraints marked critical with a footnote explaining the there are many valid certificates that aren't marked critical in those fields that you should accept. A cert is validated by looking at the attribute. If the attribute is not understood, and only if the attribute is not understood, then look at the critical bit, if it's set and you don't understand the attribute you must reject it.
ETLS

Jim described what he learned regarding how the Microsoft operating systems Windows XP, and 2000 SP4 handle ETLS from documentation Microsoft publishes for on how to use 3rd party certificates for Windows authentication. Inside of subject alt name there is other name where Microsoft specifies their own OID, called principle name, as an unique identifier for the person. That gets passed out to the various Radius servers for authentication and matching lookups. If principle name is not present they use just the common name of the subject name, which may not be unique. If you're trying to make wireless ETLS authentication work well, you will probably need to do this unless you have common names that guaranteed unique and are easy to look up in LDAP. If you use your certs for wireless and want to use the Microsoft client this approach is required.
USHER/InCommon CA discussion

Neal indicated that the because of the timeframe Internet2 will initially administer the InCommon CA. He asked for feedback on how difficult it would be to upgrade to a higher level of security at some future point? How painful would it be for new certificates to be deployed everywhere is there was a security breach? Initially, the number of machines where new certificates are deployed would be manageable but as the federation size increases it may not scale well.
Should two key access be considered for security of the InCommon server? Does the additional risk created by that being a centralized service imply stepping up to an advanced physical security operation or is it just running secure practices? There is a sense that the appropriate route is relying on secure servers, trusted system administrators and proper process oversight as opposed to two key access.

John Sherwood from CANARIE in Canada, which was a CREN member, is interested in USHER. But CANARIE cannot be a member of Internet2. They are wondering if there is an opportunity for them to partner with Internet2 to do one CA to cover higher ed in both the US and Canada. Besides the organizational and policy aspects of the question, this reintroduces the question of whether the name USHER (US Higher Ed Root) would work. If anyone has insights please mail them to Neal.

Barry has started on Windows authentication. 2000 is pretty straightforward but there are significant changes in 2003 and old documentation for implementing a third party CA for authentication against a 2003 directory is inaccurate. Currently Microsoft does not have any new documentation 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. Sorry the action item got omitted:
4. [AI] All: S/MIME, please send signed messages from different clients to the list so we can fill out the table on the S/MIME client data. Barry will arrange for a new Apple client signed message sent to be sent to the list. Eric will send an S/MIME signed message from Pine to the list.