230 likes | 362 Views
Federal and State PKI Bridge Evolution: Cutting Across Stovepipes. EDUCAUSE 2000 October 12th, 2000. Chip German UVa Policy/Planning Director. Rich Guida Federal PKI Steering Committee Chair. Shirley Payne UVa Security Director. Tim Sigmon UVa Advanced Technology Director. Agenda.
E N D
Federal and State PKI Bridge Evolution: Cutting Across Stovepipes EDUCAUSE 2000 October 12th, 2000
Chip German UVa Policy/Planning Director Rich Guida Federal PKI Steering Committee Chair Shirley Payne UVa Security Director Tim Sigmon UVa Advanced Technology Director
Agenda • Federal PKI Approach • Elements of Interoperability • Bridge Approach • Current Status • Critical Interoperability Issues • Commonwealth of Virginia PKI Approach • Context • Early Conclusions • Final Design Decisions • Lessons Learned
Elements of Interoperability • Technical • Mesh (cross-certification) • Bridge (cross-certification with central hub) • Hierarchy (one-way certification) • Trust list (browser model) • Policy • Levels of assurance for certificates • X.509 policy processing framework
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
Federal PKI Policy Authority • Voluntary interagency group - NOT “agency” • Governing body for interoperability through FBCA • Agency/FBCA certificate policy mappings • Oversees operation of FBCA, authorizes issuance of FBCA certificates • Six charter agency members - DOJ, DOC, Treasury, DOD, OMB, GSA
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 CARLs • Use NOT mandatory • Concept successfully tested - EMA 4/00
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 (but also support LDAP access) • Not susceptible to DOS or intrusive attack
Current Status • Prototype FBCA: Entrust, Cybertrust • Initial operation 2/8/00 • Replacing Cybertrust with Unicert • Production FBCA: add other CAs • Operation by late 00 (funding permitting) • FBCA Operational Authority is GSA (Mitretek technical lead and host site) • FBCA Certificate Policy by late-00 • FPKIPA stood up 7/00
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
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
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 • 500K “free” certs (no issuance cost) • President used ACES in signing E-sign Act 6/00
Critical Interoperability Issues • Directory interoperability • Namespace control • Client ability to create and process trust paths to X.509 standard • Policy mapping of certificate assurance levels • Legal liability
Context • Political environment • Project genesis • State agency and local government pilot projects • University of Virginia’s role
Early Conclusions • No single hierarchy • Multiple PKIs • Focus on identity, not authorization, certificates • Storage of encrypted documents discouraged
Final Decisions • Simplicity in early implementation phase • Virginia Online Transaction (VOLT) Certificates for citizens • Mechanism to expand trust, e.g. bridge architecture • Interoperability promoted through open standards • Attraction, not compulsion
Lessons Learned • Models are important, especially ones that help decide when to use digital signatures • Uses should add value • Process reengineering is essential • Policy content should be deferred in favor of concept • Best help comes from a few experts • Auditors should be involved early on
Lessons Learned - cont’d • Legal and/or political questions still surround most obvious best uses, e.g. online voting • Successful implementation requires range of options, such as: • autonomy for state agencies & local govts. • central PKI service for those who need it • open standards aimed at interoperability with flexibility
Most Importantly….. Get involved in state initiatives and devote sufficient resources Provides education & help where needed Helps protect interests of higher education Lessons Learned - cont’d
Further Information Sources Federal Steering Committee http://gits-sec.treas.gov Commonwealth of Virginia Digital Signatures Initiative http://www.sotech.state.va.us/cots/dsi/index.htm Commonwealth of Virginia Bridge Certification Architecture Project at the University of Virginia http://www.itc.virginia.edu/oit/technology/pki/home.html