1 / 14

Enhancing Federal PKI Interoperability: Strategies and Current Developments

This document outlines the evolving landscape of Federal Public Key Infrastructure (PKI) interoperability as discussed by Richard Guida, a member of the Government Information Technology Services Board and Chair of the Federal PKI Steering Committee. Key elements include technical interoperability through bridges and directory systems, policy mapping, and the establishment of the Federal Bridge CA. Emphasizing the need for effective interagency collaboration, this document also addresses the architecture supporting multiple Certificate Authorities (CAs) and the implementation of trust paths in electronic transactions.

kumiko
Télécharger la présentation

Enhancing Federal PKI Interoperability: Strategies and Current Developments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Interoperability Elements • Technical • CA to CA • RA to CA • Directory to directory • Client to client (most complex element) • Policy • Policy mapping • Cross certification vs. CA Trust Lists

  3. Client Interoperability • Accepting incoming certificates from external PKI domain • Trust path creation, validation • Use and management of trust lists • Engineering clients to use certificates from multiple CA products • Multiple toolkits, multiple plug-ins

  4. Federal PKI Approach • Establish Federal PKI Policy Authority (for policy interoperability) • Implement Federal Bridge CA using COTS (for technical interoperability) • Deal with directory issues in parallel • Border directory concept • Use ACES for public transactions

  5. Federal PKI Policy Authority • Voluntary interagency group - NOT an “agency” • Governing body for interoperability through FBCA • Agency/FBCA certificate policy mappings • Oversees operation of FBCA, authorizes issuance of FBCA certificates

  6. Federal Bridge CA • Non-hierarchical hub (“peer to peer”) • Maps levels of assurance in disparate certificate policies (“policyMapping”) • Ultimate bridge to CAs external to Federal government • Directory initially contains only FBCA-issued certificates and ARLs

  7. Boundary Conditions • Use COTS with “inclusive” architecture • Use X509v3 • Support four levels of assurance • Rudimentary, Basic, Medium, High • Modeled after Canadian PKI • FBCA use cannot be mandatory • Focus requirements on agencies as certificate issuers, not relying parties

  8. FBCA Architecture • Multiple CAs inside membrane, cross certified • Adding CAs straightforward albeit not necessarily easy • Solves inter-product interoperability issues within membrane - which is good • Single consolidated X.500 directory

  9. Current Status • Prototype FBCA: Entrust, Cybertrust • Initial operation 2/8/00 • Production FBCA: add other CAs • Operation by late 00 • FBCA Operational Authority is GSA (Mitretek technical lead and host site) • FBCA Cert Policy 12/99 to early 00 • FPKIPA Charter 12/99 to early 00

  10. 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) or LDAP referral to FBCA DSA

  11. FBCA DSA Border DSA 1 Border DSA 2 LDAP Server X.500 DSA Border 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

  12. 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

  13. Access Certs for Electronic Services • RFP 1/99; bids received 4/99; first award 9/99 (DST), second award 10/99 (ORC), third award 10/99 (AT&T) • Provisions for ACES-enabling applications, and developing customized PKIs • Agencies do interagency agreement with GSA • Certificates available shortly

  14. U.S. Federal Government Participation in PKI Forum • Contribute experience with interoperability (e.g., FBCA) • No desire for voting rights - inappropriate • Contribution in kind in lieu of membership fees • Willing to pay conference fees, and to limit number of participants to reasonable level • Support idea of government “council” as adjunct to PKI Forum

More Related