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.
The Federal Bridge CA Directory will:
Agencies wishing to cross certify with the Federal Bridge CA:
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:
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.gov/pki/twg/y2002/doc_reg_02.htm.
Last updated: November 2, 2004
Page created: December 28, 1997