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?