Federal Bridge Certification Authority EMA Challenge 2000

1. Richard A. Guida: Stage setting comments: 1. This effort pushed the boundaries on directories, S/MIME clients, and PKI products - and it did so simultaneously. Bleeding edge doesn’t even begin to describe this effort. 2. Perspective: five different CA products with total of 20 CAs, five different directory products with total of 13 directories, certificate trust paths seven nodes long. This is not your father’s PKI. 3. As Tim Polk of NIST very sagely observed a few months ago, people think PKI interoperability is a hard problem. They are wrong. It is a VERY hard problem. The good news, however, is that even VERY hard problems can be solved. Like the Marine Corps motto (or some believe the Army Combat Engineers motto), the difficult we do immediately, the impossible takes a little longer. 4. A lot of very hard work went into this effort, and while you never achieve as much as you want - only the Deity is perfect - I am very proud of what the team accomplished and delighted to be here to describe it and the many lessons learned in the process. Federal Bridge Certification AuthorityEMA Challenge 2000 • Background • Overview • Test structure • Participants • Results • Conclusions and lessons learned • Path forward

2. Richard A. Guida: 1. Federal PKI developing from the bottom up - agencies are autonomous/independent, we must honor that. 2. FBCA approach has the virtue of supporting disparate PKI domains - disparate in products, policies, you name it. 3. FBCA solves CA interproduct interoperability issue - ability to cross-cert - in an elegant way: within the membrane, and off-line. Cross-certs are published in FBCA directory which is 24X7 on Internet. FBCA itself is “cold silicon” 99% of time - only active to issue new cross-certs and to publish ARLs once a week. Background • FBCA is non-hierarchical, peer-to-peer “hub” • Supports interagency PKI technical interoperability • Policy interoperability framework established by FPKI Policy Authority • Goal: accommodate Federal agency use of any PKI COTS product

3. Richard A. Guida: 1. FBCA effort to date funded by NSA through Treasury Department, and with significant technical input from NSA, NIST and GSA - which demonstrates how the civilian side of government is benefiting from the “best and brightest” PKI minds in government today. 2. FBCA effort proceeds in two phases - prototype (already operational with Entrust and Cybertrust CAs) and production (operational by late 2000), with latter having additional CAs inside the membrane. 3. Bottom line goal: Support agency PKI domain interoperability regardless of what CA product or CP they adopt. Overview • Prototype FBCA operational 2/8/00 • GSA auspices; hosted by Mitretek Systems • Entrust and Cybertrust CAs • PeerLogic i500 directory • Supports EMA Challenge and testing • Production FBCA operational late 2000 • Additional CA products within membrane • Mesh arrangement within membrane

4. Richard A. Guida: 1. Our test structure includes six PKI domains, one of which (DOD) is complex - with three hierarchical or mesh sub-domains 2. Total number of CAs involved in the test structure is 20; max CA trust path length is seven. This is the most complex PKI interoperability test undertaken anywhere on the planet - at least this planet. 3. Selected open standard (S/MIME) and digital signature only to start, but will include encryption and policy mapping later this year. 4. Directories critical; use of X.500 for chaining made it “easier” for clients as opposed to LDAP referrals, but recognize system ultimately must support referrals as well - which will make the clients have to work a bit harder. Test Structure • Six disparate PKI domains cross-certified with FBCA • Five different CA products • Five different X.500 directory products • Interoperability demonstrated via exchange of signed S/MIME messages • X.500 directory framework - chaining between directories, client access via LDAP

5. Federal Bridge CA Canada Cybertrust CA Entrust CA GSA/FTS NIST 2 PCA PCA NSA CYGNACOM DoD Bridge CA CYBERTRUST Entrust PCA PCA PCA PCA SFL Client Entrust Client CA CA CA CA NIST 1 NASA GTRI PCA PCA PCA CA CA CA CA Entrust Entrust Motorola Spyrus Entrust Entrust Entrust Entrust Client Entrust Client SFL Client Entrust Client SFL Client Entrust Client Entrust Client

6. Richard A. Guida: 1. One of the several “hearts” of this effort is the e-mail client - that is where all of the heavy lifting is done with respect to trust path creation and validation. 2. Picked Eudora because easiest to build “plug-ins” and use libraries. 3. This earlier work was sponsored by NSA as part of their Bridge Demonstration effort - which is their PKI domain (with a Cygnacom CA at the hub) that is cross-certified with the FBCA for purposes of the Challenge. So we owe a disproportionate “thanks” to NSA for their ground-breaking effort on this - it provided a firm foundation for our proceeding with the Challenge. 4. The libraries used are publicly available and on web sites; visit the FPKI Steering Committee web site and you can get the hyperlinks. Client Details • Eudora engineered with: • Entrust toolkit (“out of the box”) • CygnaCom libraries • JGVanDyke libraries • Spyrus LYNKS cryptocards for CygnaCom/JGVanDyke enabled client • Private key on hard disk for Entrust enabled client

7. Richard A. Guida: 1. Lots of participants; key here is that the technical work on the Challenge effort really began in earnest in late January; took many months to get agreements in place, lawyers satisfied, then have the carrier pigeons deliver the money. We started with two domains - NIST and DOD - and then in February and March added four more - Canada, GSA, NASA and GTRI. The interoperability we were able to achieve by the EMA Challenge deadline was affected by this process. As is usually the case in these types of efforts, time ran out before we could get it all done. Government of Canada NSA/DOD NIST NASA GSA Georgia Tech Research Institute CA products: Entrust; Cybertrust; CygnaCom; Spyrus; Motorola Directories: PeerLogic; ICL; Nexor; CDS; Chromatix Integrators: Mitretek; JGVanDyke; GNS; Booz Allen; CygnaCom; A&N Associates Participants

8. Richard A. Guida: 1. So here are the results. Now let me explain them. 2. First, to get this far, we had to do three things: (a) cross-cert one of the FBCA nodes with the domain’s principal CA; (b) chain the x.500 directories; and (c) finally, get the clients to send and then more importantly, receive e-mail and create/process the trust path upon receipt. 3. For each of the domains, we were able to effect (a) and (b). Thus, the table would be completely green in color if that is all we had to do. 4. The table instead depicts how well we were able to do (c) - client interoperability - given that we had fully achieved CA and directory interoperability. 5. Right off of the bat, as you can see, we substantially exceeded our original goal of getting two domains interoperating. We intend to continue our efforts until everything does work - which means that this is in some respects a “status report” rather than a “final report” - we are not yet done. And the good news is that we have NOT run into any “speed of light” limitations - we fully expect to complete all of the boxes with additional time and effort. 6. Some points re: the table: a. You see some “NAs” for Not Applicable - because they represent trust paths within a single domain that do not use one or both nodes of the FBCA. Note that I have colored some of the NA boxes green, to reflect the fact that NSA was able to get all of their subdomains to interoperate through their Bridge, which is a single Cygnacom CA; that was a substantial accomplishment in and of itself even though it did not use the FBCA per se. b. A green color in the box indicates that a message sent using a cert issued by the “from” CA was received in the domain of the “to” CA and properly validated. c. The “CUD” indicates that the e-mail client for that application is under development; in essence, we are developing the right plug-ins for Eudora to work within that domain. This was a case of just not having enough time; we did not run into any fundamental problems, time just ran out. We intend to finish this part later, over the next few weeks. d. The “DEB” indicates that as of show-time, we were debugging the paths shown but had not yet achieved success. e. Not shown is the fact that we tested the architecture with revoked certs, and with certs issued by a CA that was not cross-certified with the FBCA; in each case, the signature properly failed to validate. There are no smoke and mirrors. Results

9. Richard A. Guida: 1. So what is the overall assessment of this? 2. First, the concept clearly works - the fact that we were able to get five domains to interoperate demonstrates that. 3. Second, making it work is not yet seamless - we pushed boundaries on the commercial products. Guess that’s why they call this the EMA “Challenge.” 4. Finally, we learned something that others probably know well: many of the tools which are essential to making all of this work - the clients, the toolkits, the directories and their interfaces - can be made to work as desired, but because we are pushing the envelope of their capabilities, they often require a level of technical understanding that is far from commonplace. There are not yet a lot of people out there who understand PKI software; or directory software. 5. So what types of problems did we encounter? The full range: (a) hex vs. decimal numbering for directory ports (another unusual form of “metric” problem); (b) differing cert profiles - even though we tried to ensure consistency, some inconsistencies cropped up - e.g., e-mail address in altsubjname field not equaling e-mail address of sender caused some clients to conclude the cert was valid but reject the signature; (c) CA configuration inconsistencies - e.g., is the signature on the cert DSA or RSA, because almost all clients handle the latter but fewer handle the former; (d) unexpected parsing of ARLs; (e) actual real bugs in client and directory software (no names!) - all fixed quickly by the companies involved; some bugs remain to be stamped out; (f) directory and/or client time-outs - especially a problem during debugging where directory logging is turned on everywhere. Conclusions and Lessons Learned • FBCA concept works • Client ability to develop and process trust path straightforward to implement • Directory interoperability is critical to PKI interoperability • Directory entries must line up with CAs • Lots of details, lots of devils

10. Richard A. Guida: 1. As indicated previously, we will continue this testing to get the remaining elements interoperating, then prepare a report. While we can claim a substantial measure of success from the testing we have done to date, we understand that much remains to be learned from completing this testing. 2. Some final observations: a. As you can see, while the FBCA concept itself is at a stage where we can implement it, and indeed plan to do so, getting the client software to use it is another matter - we have substantial effort ahead of us getting that capability into clients in such a way that it is seamless and transparent to the user. But it can be done - that is what we have shown. b. When trust paths were being created and processed by the client software, the creation could take tens of seconds because of all of the directory lookups for cross-certs and ARLs; people are not going to be comfortable waiting that long. We understand that. We believe that there is a substantial amount of optimization which can get those times way down. Furthermore, for the people you deal with regularly through e-mail, trust paths are cached so that also accelerates the process. Finally, note that trust paths that are seven CAs long, as we tested here, are pretty darn long; in most instances, you would expect lengths of three or four. c. As most of you know, discussion efforts led by NIST and others are beginning on “Internet II,” and I am participating in those discussions, especially around the question of what capabilities would facilitate the use of PKI. Obviously bandwidth would help so that you can locally cache ARLs in the form of a Validation Authority, for example, and not even have to do directory lookups in real time - that would accelerate trust path processing. So I just wanted everyone to understand that issue is on the table in the Internet II discussions. d. All that having been said, we also understand that not every e-mail needs to be signed and encrypted. We would expect most users to continue to employ current “open” e-mail for much of their business, reverting to signed/encrypted when needed. e. Final point: this whole effort put us in the government in a bit of an uncomfortable position. Normally we follow someone else rather than trying to blaze a path ourselves. The reason we have tried to blaze this path is that we desperately need to effect interagency interoperability - everyone is tired of stovepipes. So we have our own internal business need that we are trying to service. Path Forward • Complete testing (get all domains to interoperate fully) and prepare report • Proceed to develop production FBCA • Stand up FPKI Policy Authority under Federal CIO Council • Test encryption and policy mapping • Get trust path creation and processing capability into applications