Federal and State PKI Bridge Evolution:
Cutting Across Stovepipes
EDUCAUSE 2000
October 12th, 2000
Shirley PayneUVa Security Director
Tim SigmonUVa Advanced Technology Director
Chip GermanUVa Policy/Planning Director
Rich GuidaFederal PKI Steering Committee Chair
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 (“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
InternalDirectory
Infrastructure
PCA 2
FBCADSA
InternalDirectory
Infrastructure BorderDSA 2
X.500 DSA
BorderDSA 1
LDAP Server
InternalDirectory
Infrastructure
PCA 1 PCA 3
Agency 1 Agency 2
Agency 3
FBCA
LD
AP
Que
ry-R
espo
nse
X.500 - D
SP
chaining
Border Directory Concept
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
Commonwealth of VirginiaPKI 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
Provides education & help where needed Helps protect interests of higher education
Further Information Sources
Federal Steering Committeehttp://gits-sec.treas.gov
Commonwealth of Virginia Digital Signatures Initiativehttp://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?