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. 


  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 


Michelle Allen, Baltimore Mtchell Arone, Schlumberger
Dan Backo, ORC Sharon Boeyen, Entrust
Robert Borochoff, US Courts Wendy Brown, Getronics
Bill Burr (TWG Chairman), NIST Tin T. Cao, State Dept.
Shu-jen Chang, NIST Michael Chernick, NIST
Sandra Coby, DoD David Cooper, NIST
Matt Cooper, CygnaCom Daniel Curtiss, Software Perf. Sys.
Joe Donahue, Microsoft Brice Eldridge, Novell
Paul Evans, BAH Jonathan L. Faulkner, OCC
Sean Finnegan, Microsoft William Flanigan, DoD/OSD
Srinivas Ganta, SRA Michael R. Gettes, Georgetown Univ.
Anne Gugel, JHU APL Sarbari Gupta, Electrosoft
Nelson Hastings, NIST Jim Heimberg, DOL-MSHA
Michael Henry, MTC Peter M. Hesse, Gemini Security
Matthew Hirsch, A&N Associates Larry Jewett, Entrust
Bob Johnson, BAH Susan Joseph, Getronics
Steven M. Kerr, SRA Franc Levene, DoD
Meng Lin, DoJ Thomas Macklin, SFA, Inc.
Robert Malick, NIH S. Crystal Marshall, Baltimore
DawMason, DoD Derrick McCorvey, Coast Guard
Gene McDowell, Commerce - NOAA Julie Smith McEwen, MITRE
Puja Mehta, BAH Eric Miller, DOJ
Layne Moessing, Gary Moore, Entrust
Todd Myrick, NIH Steve Newbold, ORC
Steve Peterson, Authera Brant Petrick, FPKISC/GSA
Erik Pfeifer, PEC Tim Polk, NIST
Art Purcell, USPTO Steve Roberts, LS3
Michele Rubenstein, BAH David Santosa, USPTO
Tom Santucci, FDA William Scherer, Jr., SRA
Michael Seguinot, VeriSign Mark L. Silverman, NIH
Ann Smith, ValiCert Gib Sorebo, US House of Rep.
Michael F. Stern, Mitretek Jim Tripoli, EDS
Jon Wall, Microsoft Carl Wallace, Cygnacom
Kim Wandersee, Energy Dept. Jim Wyre, Valicert

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.gov/pki/twg/y2002/doc_reg_02.htm.


Last updated: November 2, 2004
Page created: December 28, 1997