August 27, 2003
Attendees

* Jim Jokl, U. Virginia
* Shawn Geddis, Apple
* Bill Doster, U. Michigan
* Eric Norman, U. Wisconsin
* Bob Morgan, U. Washington
* Bob Brentrup, Dartmouth
* Mark Franklin, Dartmouth
* Barry Ribbeck, UT-HSCH
* Bill Weems, UT-HSCH
* Nathan Faut, EDUCAUSE
* Steve Carmody, Brown
* David Wasley, UCOP
* Jeanette Fielden, Internet2
* Neal McBurnett, Internet2
* Renee Frost, Internet2

Discussion

A HEBCA meeting will happen in Chicago on September 11 and 12, 2003. CP's will be discussed. Neal is working on an USHER CP for that meeting with the goal of ensuring that USHER is in parity with the Higher Ed Bridge CP as much as possible. The latest version of the HEBCA CP is March 8, 2003 v [0.] 02.

Neal discussed naming issues and it was agreed that the old CREN name of Education and Research Client CA would be retained.

Neal also raised the issue of how could USHER or Higher ED bridge enforce that all users will be using FIPS certified stuff for user keys? Only through hardware tokens or onscreen passwords. The token solution is cleaner since it would not require users to continually enter passwords but it's not a software solution.

Shawn Geddis of Apple was on the call to talk about their new browser, plans for OS key stores and PKI support. Jaguar is the name for MAC OS X 10.2. Panther is the name for MAC OS X 10.3 to be released later this year. It was debuted at the Apple Developers Conference in San Francisco.

The Safari browser is shell calling OS services; a web kit that provides a full API set in the OS. The current version of Safari doesn't have support for hardware tokens. It's a complied application but everything it uses is open source.

Apple has taken the design approach of security being built-in not bolted on. Apple's entire PKI infrastructure is open source. Apple is building the crypto and PKI capabilities into the operating system (OS) leveraging the Common Data Security Architecture (CDSA). CDSA began at Intel labs and is managed by the Open Group. http://www.opengroup.org/security/l2-cdsa.htm

CDSA provides all of the crypto and functional capabilities for providing PKI functions within an OS. Keychain is the secure storage of various credentials. While previous versions have allowed account credential storage Panther will enable importing of private/public keys into the desired Keychain, by double clicking on those certificates. The keychain environment is provided at command level as well.

In Jaguar (10.2) certificates in the system Keychain can be modified. The actual filename is referred to as X.509 anchors. On a Jaguar system the X.509 anchors Keychain has all the trusted root certificates for the complete OS. It is not application specific. The certtool in Jaguar can import certificates into various Keychains including the X.509 anchors. Panther will have a certtool version with a better GUI to allow for easier direct user interaction.

In January Apple started providing full support for the department of defense (DOD) common access card. It currently isn't integrated with the Keychain but there is full login, screensaver lock, and PKCS11 support for access to certificates on the card itself. It currently works with about 30 types of smartcard readers. All the capabilities will be available in Panther (10.3).

David asked if the key chain mechanism would always be separate from the support for smart chip devices. Shawn explained that it was felt that the appropriate way to do this going forward is to have a smartcard visible to the system as a Keychain. Then any application looking for certificates doesn't need to physically differentiate between what kind of physical device it is on. Keychain architecture looks in all the available key chain paths for that certificate. If the smart card appeared in that list as a keychain it would resolve for any application.
It won't be in the initial Panther release and a current timeframe isn't available.

David asked about the existence of a standard for physical devices that use smart chips so you can achieve plug and play, like exists for devices like USB disk drives etc without requiring a device driver from the manufacturer? The typical OEM reader is the Microsystems SCR-331 reader. As a result the CCID driver is a defacto standard for a generic driver for communications with hardware tokens. The USB form factor would be another version of that. If there is another vendor that has another physical device and they are not adhering to the command set for CCID for the PCSC lite framework they need to provide their specific driver for their reader. You can have multiple drivers and have the OS recognize which type of device it is. Currently Rainbow hasn't made a driver for the iKey available though if there is sufficient demand they may.

Eric described an issue with a path discovery problem in Jaguar. If you have a trusted anchor installed in the system library it is self-signed. The server verification the chain is three long when you talk to an SSL server. There is an intermediate CA between the server certificate and the trust anchor. If the server end sends that certificate along with the SSL protocol then things are ok. If it fails to do so you cannot get around this problem by installing that intermediate certificate in the X.509 anchors. You can put it in there but the software will not recognize it. Shawn requested a write up so he could research the answer.
[AI] Eric will provide a write up of the Jaguar path validation issue with intermediate CA's.

The software in the OS can follow a path through a bridge by writing a trust policy within CDSA. When you think of a bridge you're essentially creating a mapping between two disparate PKI environments or agencies. The agencies do the mapping via the trust policy and the federal bridge just does the brokering. Within CSDA exist several key management modules. The CSP is the cryptographic service provider. The Certificate Library (CL) does all the parsing, traversing, revocation, and would actually handle the following of the path to the final root certificate. The Data Library (DL) module manages the storage of CDSA data. The final module is the trust policy, which is the logic of what's required before that final authorization or the approved mapping is complete.

Currently finding/gathering certificates is mostly a heuristic to find the directory where authority certs are stored. Someday the authority information access field in the X.509 cert may provide a pointer that makes it more straightforward but that's not the case at the moment. While specific code and API does not exist today, the capability is in the CDSA to allow you to leverage both the trust policy and CL modules to do that traversing and handling of the middleman.

There is very active development going on around CDSA with about 1100 API's in version 2.1. It is not in parity across all platforms however. Information is available at Sourceforge.

OS X and OS X server is in the middle of Common Criteria process at the moment. Common Criteria is the internationally recognized independent lab certification of an evaluated assurance level against a specified protection profile. The Common Criteria process does not search for particular vulnerabilities. It doesn't mean a lower or higher assurance level is any more or less secure it just refers to how much evidence generation is required to provide that level of assurance. It means that for specific functional requirements the products met them and that's it. No external standard is being measured against. FIPS certification may be completed by the end of the year though that's not definite.

Does adapting to another platform create certification problems? If you base a solution on a previously certified component, as long as you have not modified that component your certification process will be reduced in terms of time and cost. Every independent product that is certified still has to go through the Common Criteria certification. CDSA is implemented on each platform. The actual CSP module shipped as part of OS X is what is getting certified. It's not a separate product but a snapshot of the code. For example if you are using version 1.1 of the CSP module, that is what would be FIPS certified as long as you are using CDSA with that CSP module on a specific platform. Leveraging it for another platform might be expedited but it's not guaranteed.

What sorts of defaults and passwords does Apple have on their certs? Within the Keychain environment, any item, called a key, has its own access control list (ACL). Tools and applications are granted access to that item only if the user adds that application to the ACL. Key chains themselves are protected with pass phrases (up to 255 characters). Certificates can be imported but they can't be exported they have to be physically deleted. Six settings can be set: certificate revocation, secure mail, extensible authentication, secure socket layer, x.509 basic policy, and code sign. Even if a Keychain is unlocked an item is not handed back to a requesting application or given access unless that application is in the ACL. If an application tries to access account information in the key chain a dialog pops up asking if access should be granted, denied, allowed once, allowed always.

Currently id certs are not accessible but it is not clear if that will be the case with Panther and if the Safari version that ships with Panther will be end-entity cert enabled.

Eric pointed out there is documentation available on the MAC for secure transport that might give clues on what it can and can't do. Shawn also suggested looking at the code submitted in the Darwin CVS tree as well.

Many campuses have Kerberos environments and use them for local things. While in general it seems that transitioning to smart cards is the direction where things are headed it would be great to be able to get a Kerberos ticket to interface with legacy Kerberos systems in the short term.

It would be very helpful to Shawn if the group could provide a write up of what is critical and must have and why to present in support of creating those features.

[AI] Jim will coordinate creating a write up of critical items for Shawn and ensure Shawn gets copies of the browser requirements doc, the S/MIME and any other relevant materials.