Federal and State PKI Bridge Evolution Cutting Across

Federal and State PKI Bridge Evolution: Cutting Across Stovepipes EDUCAUSE 2000 October 12 th, 2000

Chip German Rich Guida UVa Policy/Planning Director Federal PKI Steering Committee Chair Shirley Payne Tim Sigmon UVa Security Director 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

Federal PKI Approach

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 (“policy. Mapping”) • Ultimate bridge to CAs external to Federal government • Directory initially contains only FBCAissued 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

Border Directory Concept PCA 1 Internal Directory Infrastructure Agency 3 PCA 2 FBCA Respon LDAP Query- Internal Directory Infrastructure Border DSA 1 LDAP Server SP 0 -D X. 50 ing n chai Agency 1 se FBCA DSA Border DSA 2 X. 500 DSA Agency 2 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 • 500 K “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

Commonwealth of Virginia PKI Approach

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

Lessons Learned - cont’d Most Importantly…. . Get involved in state initiatives and devote sufficient resources y Provides education & help where needed y Helps protect interests of higher education

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

Questions?