Federal Agencies and PKI

1. Federal Agencies and PKI Richard Guida, P.E. Member, Government Information Technology Services Board Chair, Federal PKI Steering Committee Richard.Guida@cio.treas.gov; 202-622-1552 http://gits-sec.treas.gov

2. E-Transaction Landscape • Intra-agency • personnel matters, agency management • Interagency • payments, account reconciliation, litigation • Agency to trading partner • procurement, regulation • Agency to the public

3. E-Transactions Drivers • Long-term cost savings • Trading partner practices (e.g., banks) • Public expectations • Federal/State Statutes (e.g., GPEA) and policies • International competition

4. Challenges All Applications Face • Authentication of Users • Non-repudiation for transactions • Confidentiality (privacy) • Interoperability • Liability • Scalability/extensibility

5. Public Key Technology • Authentication • Technical non-repudiation • Data integrity • Confidentiality • Interoperability • Scalability/extensibility

6. How PK Technology Works • Two keys, mathematically linked • One is kept private, other is made public • Private not deducible from public • For digital signature: One key signs, the other validates • For confidentiality: One key encrypts, the other decrypts

7. Digital Signature (example) • Sender hashes document, signs hash with private key and sends with document • Recipient hashes document he or she received, creating “raw hash” • Recipient applies public key of sender to signed hash to get sender’s raw hash • If raw hashes are same, transaction validates

8. Confidentiality (example) • Sender generates symmetric encryption key and encrypts document with it • Sender encrypts symmetric key with public key of recipient, sends that and encrypted document to recipient • Recipient decrypts symmetric key with his or her private key • Recipient decrypts document with symmetric key

9. The Critical Questions • How can the recipient know with certainty the sender’s public key? (to validate a digital signature) • How can the sender know with certainty the recipient’s public key? (to send an encrypted message)

10. Public Key Certificate A document which - • is digitally signed by a trusted third party (called Certification Authority) • is based on identity-proofing done by a Registration Authority • contains the individual’s public key and some form of the individual’s identity • has a finite validity period

11. X.509 v3 Certificate

12. Public Key Infrastructure • Registration Authorities to identity proof users • Certification Authorities to issue certificates and CRLs • Repositories (publicly available data bases) to hold certificates and CRLs • Some mechanism to recover data when encryption keys are lost/compromised • Certificate Policy and related paper

13. Intra-Agency PKI Examples • DOD (~50K+ certs => >>4M certs by 2002; high assurance with smartcards) • FAA (~1K certs => 20K+ certs in 2000; software now, migrating to smartcards) • FDIC (~1K certs => 7K+ certs in 2000) • NASA (~1K certs => 25K+ certs in 2000)

14. Potential Interagency Uses • VA and SSA on medical evidence • Dept of Education, SSA, VA on student loan applications, disbursements, etc. • USDA/NFC for on-line payroll matters • DOD/Treasury re: payments • FDIC/other financial regulators re: sharing information

15. Federal PKI Approach • Establish Federal PKI Policy Authority • Develop/deploy Bridge CA using COTS • Four levels of assurance (emulate Canada) • Prototype early 2000, production mid 2000 • Deal with directory issues in parallel • Border directory concept; “White Pages” • Use ACES for public transactions

16. FPKIPA and Bridge CA Topics • Federal PKI Policy Authority Overlay • FBCA Overview • Technical Boundary Conditions • Policy/Political Boundary Conditions • Potential Architectures • Current Status • Schedule

17. Federal Policy Authority Overlay • Federal PKI Policy Authority facilitates interoperability through FBCA (e.g., determines cert policy mappings) • All agencies that interoperate through FBCA are voting members • FPKIPA members = FPKISC members • Interoperability through the FBCA is NOT required (but hopefully attractive)

18. FBCA Overview • Non-hierarchical hub for interagency interoperability • Ability to map levels of assurance in disparate certificate policies • Ultimate “bridge” to CAs external to Federal government • Directory contains only FBCA-issued certificates and ARLs

19. FBCA PKI Architecture US Federal

20. Technical Boundary Conditions • Comply with FIPS (140-1, 186) • Level 3 Crypto Module for FBCA • Meet MISPC to maximum extent practical • Interoperate with as many COTS as possible • Comply with X509V3 (certs, policy processing)

21. Policy/Political Boundary Conditions • Desire to use COTS if possible • Desire solution which is as fully “inclusive” for vendors as possible • Support four levels of assurance • Rudimentary, Basic, Medium, High • Analogous to Canadian PKI • FBCA use not mandatory • Requirements focus on agencies as certificate issuers, not relying parties

22. Potential Architectures • Multiple CAs within membrane, with single signing key • Single CA • Multiple CAs within membrane, cross-certified among themselves

23. Multiple CAs, One Key • Avoids cross-certification within membrane, so: • minimizes certificate path length • reduces overall path processing complexity • May require porting key to other tokens (allowed under 140-1 if encrypted) • Creates complications in directory postings for ARLs and cross-certs to external CAs

24. Single CA • Most straightforward technical solution • Pushes interoperability issues to Bridge membrane • Is worst political solution • one winner, many losers • non-inclusionary

25. Multiple CAs, Cross-certified • In essence, the “quark” model • Certificate path length may be +1 • Adding CAs within membrane should be straightforward albeit not necessarily easy • Requires solving inter-product interoperability issues within membrane rather than outside - which is good

26. Current Status • Decision: cross-certified CAs within membrane • Initial vendor products: Entrust and GTE for “prototype” FBCA • Migration from prototype to production FBCA will entail adding other CAs inside the membrane • GSA/FTS has responsibility to execute

27. Schedule • Draft Bridge Certificate Policy: late 1999 • Draft FPKIPA Charter/CONOPS: late 1999 • Prototype Bridge: early 2000 • Operational Bridge: mid to late 2000

28. Initial Border Directory Concept • Each agency would have Border Directory for certificates and CRLs • may shadow all or part of local directory system (allows for agency discretion) • CAs may publish directly in border directory • unrestricted read access • Directory resides outside agency firewall • chain (X.500 DSP) to FBCA DSA

29. FBCA DSA Initial Border Directory Concept PCA 1 PCA 2 FBCA Agency 2 Agency 1 DSP Internal Directory Infrastructure DSP chaining chaining Internal Directory Infrastructure Border DSA 1 Border DSA 2 X.500 DSA X.500 DSA

30. Concerns with Initial Concept • Agencies must stand up X.500 DSA • But: • Some agencies have no X.500 directories; instead use LDAP servers (and may be tied to OS or major applications), proprietary, or nothing • X.500 DSAs seen as expensive; initial cost, plus care and feeding (X.500 DSAs complex, and chaining can be challenging)

31. Expanding the Concept • Approach must provide for more than just agency X.500 directories • FBCA directory can be directory nexus • Link to X.500 border DSAs via DSP chaining • Link to LDAP oriented agencies via referrals • There are other possibilities • CIO Council “White Pages” • GSA • Commercial services

32. FBCA DSA Border DSA 1 Border DSA 2 LDAP Server X.500 DSA Expanded FBCA Directory Concept Agency 3 PCA 1 Internal Directory Infrastructure PCA 3 PCA 2 FBCA Agency 2 Agency 1 LDAP X.500 - DSP Internal Directory Infrastructure chaining Query-Response Internal Directory Infrastructure

33. Access Certs for Electronic Services • “No-cost” certificates for the public • For business with Federal agencies only (but agencies may allow other uses on case basis) • On-line registration, vetting with legacy data; information protected under Privacy Act • Regular mail one-time PIN to get certificate • Agencies billed per-use and/or per-certificate

34. Access Certs for Electronic Services • RFP 1/99; bids received 4/99; first award 9/99 (DST), second award 10/99 (ORC) • Contract has provisions for ACES-enabling applications • Agency’s do interagency agreement with GSA • Certificates available within three to six months

35. Electronic Signatures under GPEA • Government Paperwork Elimination Act (October 1998) • Technology neutral - agencies select based on specifics of applications (e.g., risk) • Gives electronic signature full legal effect • Focus: transactions with Federal agencies • Draft OMB Guidance 3/99; final 4/00

36. Organization

37. Federal PKI Steering Committee • Over 50 members from two dozen agencies • Three Working Groups • Business • Technical • Legal and Policy • Minutes/activities on the web • http://gits-sec.treas.gov

38. PKI Use and Implementation Issues • Misunderstanding what it can and can’t do • Requiring legacy fixes to implement • Waiting for standards to stabilize • High cost - a yellow herring • Interoperability woes - a red herring • Legal trepidation - the brightest red herring

39. Misunderstanding what it can and can’t do • Technical vs. legal non-repudiation • Probably to the former, possibly to the latter • Establishing a PKI <> making clients PKI-aware • Building the highway is not the same as building the cars that ride on the highway

40. Requiring legacy fixes to implement • Fixing directory anarchy • Don’t expect directory problems to abate - they will be exacerbated • Mapping to legacy data bases • Back end applications remain

41. Waiting for standards to stabilize • Far too much to expect • Evolution is constant process, it does not stop for anyone • And, not necessary • Internet standards are not stable but it still works (fitfully at times…) • PKI standards are good enough for enterprise deployment, getting there for interoperability

42. High cost - a yellow herring • Cost of ownership is not low • Registration, certificates, CRLs, PKI-aware clients, repositories, directories, and so on • But, compared to what? • Multiple stove-piped PIN applications with poor security?

43. Interoperability woes - a red herring • Interoperability often not needed in enterprise applications (single product) • Even where needed, interproduct interoperability getting much better (Federal Bridge CA will help drive) • No reason to delay use of this technology

44. Legal trepidation - the brightest red herring • PK technology is NOT the most complex subject presented in a courtroom • Case law only develops when you use something • Technology and commerce marches on regardless of legal uncertainties • Unreasonable to demand standard of proof higher than in paper world