FPKI TWG Meeting 5 September 2002  

The Federal PKI Technical Working Group met at NIST North room 152, at 9:00 AM on 5 September 2002. 

 Agenda

1. Introductions  
2. Document registration
3. Draft agenda review
4. Liaison reports
   - Business Group 
   - Legal Group 
   - Steering Committee 
   - Directory Forum 
5. Operational Bridige CA Cross Certification Status Report
   - Tim Polk
   
6. Federal PKI Directory Profile Version 2.2 (twg-02-19, twg-02-20))
   - Bob Johnson, BAH
   
7. Active Directory
   - Sean Finnegan, Microsoft
   
8. 3rd party PKI Deployment with Active Directory (twg-02-21)
   - Sharon Boeyen
9. Names and Name Constraints (twg-02-22)
   - David Cooper, NIST
   
10. General Discussion of Directory Issues
11. Next meeting's agenda items 
12. Other business
13. Adjourn 

Attendance

Draft Conclusions and Recommendations from Discusion

The Federal Bridge CA Directory will:

• contain only certificates where the FBCA is the issuer or the subject and CRLS issued by the FBCA;
• support LDAP v3 queries from anybody;
• be capable of chaining to X.500 DSAs; · be capable of maintaining knowledge references and referring clients (via LDAP v2 referrals) to agency LDAP directory servers that are not chained to the FBCA Directory;
• maintain separate roots for C=US O=US Government, dc=.gov and (possibly) dc=.mil

Agencies wishing to cross certify with the Federal Bridge CA:

• must make CA certificates, cross certificates and CRLs available externally accessible by: o chaining an X.500 DSA to the Federal Bridge Directory, or; o maintaining an externally accessible LDAP directory;
• may optionally choose to make end entity certificates available in a similar manner.

Agencies wishing to obtain the fullest possible trust connectivity should employ clients able to build and validate certification paths through the Federal Bridge CA and of obtaining needed certificates and CRLs via LDAP and of processing LDAP v3 referrals. Clients that build and validate certification paths from LDAP accesses, but do not process referrals may not be able to obtain certificates from agencies that do not chain their border directory to the FBCA border directory.

The Federal PKI should accommodate both "geopolitical naming" (e.g.: c=US, o=US Government, ou=Department of Commerce, ou=Technology Administration, ou=National Institute of Standards and Technology) and "domain component naming" (e.g.: dc=gov, dc=nist). Geopolitical naming is recommended according to the US Gold.

To indicate the government structure in names and to facilitate the use of name constraints in certificates, agency names used in certificates should be of the form:

c=us, o=U.S. Government; ou=Department Name; ou=Subordinate Department Name

using the names defined in FIPS 95-2 CODES FOR THE IDENTIFICATION OF FEDERAL AND FEDERALLY ASSISTED ORGANIZATION. This will ensure unique names that reflect the organizational structure of the government.

The FPKI however, may also have to accommodate organizations that already have PKIs that do not follow this format. At least one agency in Treasury is apparently using domain component names, but we are not aware of other agencies who may be choosing to stand up PKIs that use domain component naming, either because this fits better with the Microsoft Network Operating System, or because of a philosophical commitment to domain names. The higher education community is apparently primarily (not exclusively) using domain component naming, and companies and governments around the world are split on this. The Government of Canada has standardized on geopolitical names, however some GoC departments wish to use domain component names.

More information is needed on the registration of geopolitical names in the Federal Government and .gov or .mil domain names. This authority was vested at one point in the now abandoned GSA E-Mail PMO. Michele Rubenstein volunteered to research this subject.

Only clients capable of building and validating certification paths through the Federal Bridge CA are of interest. Current clients capable of doing this include:

• most or all versions of the Entrust client;
• the Windows XP CAPI client (may require population of AIA extention in end entity certificates);
• the Windows 2000 clients and below (assuming all the latest service packs or latest version version of IE are installed) can build and process paths, provided that the intermediate certificates for CAs that are directly cross-certified with the BCA are loaded into the intermediate certificate store, and other needed CA certificates can be found via the AIA extension;
• the SUN Java client;
• clients built for the BridgeCA demos with toolkits developed by Cygnacom and Entrust - these apparently are not commercially supported.

Of these, Entrust versions 5 and 6, the Windows XP client and the Sun Java client apparently all will process LDAP v3 referrals. Entrust versions 4 and earlier do not chase referrals - this is probably the only significant installed base of clients that are "bridge capable" but unable to process referrals. Since Win 2000/ME/98 requires pre-population of BCA intermediate certificates, it can be considered semi-bridge enabled and referrals are not an issue.

There also was a discussion about whether it would be possible to pass a referral back from the Bridge Border directory server, through a chained directory path, so that a client that queried a chained X.500 DSA might be passed back, through the chaining process, a referral. We should attempt to determine if that is possible with X.500 DSA products.

This information would tend to lend support the view that chaining is not strongly required to support PKI clients that are otherwise capable of building and processing BCA certification paths, but do not process referrals. There appear to be relatively few of those. However, another argument expressed in the meeting in favor of chaining, however, is that agencies may not be comfortable opening ports in firewalls and allowing individual clients to do LDAP referrals, and would prefer to have clients deal only with the local X.500 DSA, then poke one hole in the firewall for chaining that DSA.

After the meeting David Cooper speculated that it would be comparatively easy to implement an LDAP proxy server that chased referrals for a client that could not process referrals. It occurred to David that the easiest way to do this might be to write a new backend for the OpenLDAP server, slapd, so that, rather than answering a query from a database, the server would turn around and ask other servers, chasing referrals as needed. When David looked at how hard it would be to do this, he found that it had already been done. this might be a quick and dirty answer to how to handle clients that can't process referrals, and the same technique might be used to avoid firewall problems, that is only one hole would need to be punched in a firewall for the PDAP proxy.

Numbered TWG documents listed above can be found at http://csrc.nist.rip/pki/twg/y2002/doc_reg_02.htm.