# Presentation: 066650

## Federal Agencies and PKI

**Richard Guida, P.E.**
**Member, Government Information Technology Services Board**
**Chair, Federal PKI Steering Committee**

**Richard.Guida@cio.treas.gov; 202-622-1552**
**http://gits-sec.treas.gov**

## E-Transaction Landscape

**Intra-agency**
**personnel matters, agency management**
**Interagency**
**payments, account reconciliation, litigation**
**Agency to trading partner**
**procurement, regulation**
**Agency to the public**

## E-Transactions Drivers

**Long-term cost savings**
**Trading partner practices (e.g., banks)**
**Public expectations**
**Federal/State Statutes (e.g., GPEA) and policies**
**International competition**

## Challenges All Applications Face

**Authentication of Users**
**Non-repudiation for transactions**
**Confidentiality (privacy)**
**Interoperability**
**Liability**
**Scalability/extensibility**

## Public Key Technology

**Authentication**
**Technical non-repudiation**
**Data integrity**
**Confidentiality**
**Interoperability**
**Scalability/extensibility**

## How PK Technology Works

**Two keys, mathematically linked**
**One is kept private, other is made public**
**Private not deducible from public**
**For digital signature: One key signs, the other validates**
**For confidentiality: One key encrypts, the other decrypts**

## Digital Signature (example)

**Sender hashes document, signs hash with private key and sends with document**
**Recipient hashes document he or she received, creating “raw hash”**
**Recipient applies public key of sender to signed hash to get sender’s raw hash**
**If raw hashes are same, transaction validates**

## Confidentiality (example)

**Sender generates symmetric encryption key and encrypts document with it**
**Sender encrypts symmetric key with public key of recipient, sends that and encrypted document to recipient**
**Recipient decrypts symmetric key with his or her private key**
**Recipient decrypts document with symmetric key**

## The Critical Questions

**How can the recipient know with certainty the sender’s public key? (to validate a digital signature)**
**How can the sender know with certainty the recipient’s public key? (to send an encrypted message)**

**A document which - **
**is digitally signed by a trusted third party (called Certification Authority)**
**is based on identity-proofing done by a Registration Authority**
**contains the individual’s public key and some form of the individual’s identity**
**has a finite validity period**

*Public Key Certificate*

## X.509 v3 Certificate

## Public Key Infrastructure

**Registration Authorities to identity proof users**
**Certification Authorities to issue certificates and CRLs**
**Repositories (publicly available data bases) to hold certificates and CRLs**
**Some mechanism to recover data when encryption keys are lost/compromised**
**Certificate Policy and related paper**

## Intra-Agency PKI Examples

**DOD (~50K+ certs => >>4M certs by 2002; high assurance with smartcards)**
**FAA (~1K certs => 20K+ certs in 2000; software now, migrating to smartcards)**
**FDIC (~1K certs => 7K+ certs in 2000)**
**NASA (~1K certs => 25K+ certs in 2000)**

## Potential Interagency Uses

**VA and SSA on medical evidence**
**Dept of Education, SSA, VA on student loan applications, disbursements, etc.**
**USDA/NFC for on-line payroll matters**
**DOD/Treasury re: payments**
**FDIC/other financial regulators re: sharing information**

## Federal PKI Approach

**Establish Federal PKI Policy Authority**
**Develop/deploy Bridge CA using COTS**
**Four levels of assurance (emulate Canada)**
**Prototype early 2000, production mid 2000**
**Deal with directory issues in parallel**
**Border directory concept; “White Pages”**
**Use ACES for public transactions**

## FPKIPA and Bridge CA Topics

**Federal PKI Policy Authority Overlay**
**FBCA Overview**
**Technical Boundary Conditions**
**Policy/Political Boundary Conditions**
**Potential Architectures**
**Current Status**
**Schedule**

## Federal Policy Authority Overlay

**Federal PKI Policy Authority facilitates interoperability through FBCA (e.g., determines cert policy mappings)**
**All agencies that interoperate through FBCA are voting members**
**FPKIPA members = FPKISC members**
**Interoperability through the FBCA is NOT required (but hopefully attractive)**

## FBCA Overview

**Non-hierarchical hub for interagency interoperability**
**Ability to map levels of assurance in disparate certificate policies**
**Ultimate “bridge” to CAs external to Federal government**
**Directory contains only FBCA-issued certificates and ARLs**

## FBCA PKI Architecture

***FBCA PKI Architecture***

- US Federal

## Technical Boundary Conditions

**Comply with FIPS (140-1, 186)**
**Level 3 Crypto Module for FBCA**
**Meet MISPC to maximum extent practical**
**Interoperate with as many COTS as possible**
**Comply with X509V3 (certs, policy processing)**

## Policy/Political Boundary Conditions

**Desire to use COTS if possible**
**Desire solution which is as fully “inclusive” for vendors as possible**
**Support four levels of assurance**
**Rudimentary, Basic, Medium, High**
**Analogous to Canadian PKI**
**FBCA use not mandatory**
**Requirements focus on agencies as certificate issuers, not relying parties**

## Potential Architectures

**Multiple CAs within membrane, with single signing key**
**Single CA**
**Multiple CAs within membrane, cross-certified among themselves**

## Multiple CAs, One Key

**Avoids cross-certification within membrane, so:**
**minimizes certificate path length**
**reduces overall path processing complexity**
**May require porting key to other tokens (allowed under 140-1 if encrypted)**
**Creates complications in directory postings for ARLs and cross-certs to external CAs**

## Single CA

**Most straightforward technical solution**
**Pushes interoperability issues to Bridge membrane**
**Is worst political solution**
** ****one winner, many losers**
** ****non-inclusionary**

## Multiple CAs, Cross-certified

**In essence, the “quark” model**
**Certificate path length may be +1**
**Adding CAs within membrane should be straightforward albeit not necessarily easy**
**Requires solving inter-product interoperability issues within membrane rather than outside - which is good**

## Current Status

**Decision: cross-certified CAs within membrane**
**Initial vendor products: Entrust and GTE for “prototype” FBCA**
**Migration from prototype to production FBCA will entail adding other CAs inside the membrane**
**GSA/FTS has responsibility to execute**

## Schedule

**Draft Bridge Certificate Policy: late 1999**
**Draft FPKIPA Charter/CONOPS: late 1999**
**Prototype Bridge: early 2000**
**Operational Bridge: mid to late 2000**

## Initial 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) to FBCA DSA

## Initial Border Directory Concept

***Initial Border Directory Concept***

**Internal**
**Directory**
**Infrastructure**

**PCA 2**

**Internal**
**Directory**
**Infrastructure**

**Border**
**DSA 2**

**X.500 DSA**

**Border**
**DSA 1**

**X.500 DSA**

**PCA 1**

**Agency 1**

**Agency 2**

**FBCA**

**DSP**

**chaining**

**DSP**

**chaining**

## Concerns with Initial Concept

**Agencies must stand up X.500 DSA**
**But:**
- Some agencies have no X.500 directories; instead use LDAP servers (and may be tied to OS or major applications), proprietary, or nothing
- X.500 DSAs seen as expensive; initial cost, plus care and feeding (X.500 DSAs complex, and chaining can be challenging)

## Expanding the Concept

**Approach must provide for more than just agency X.500 directories**
**FBCA directory can be directory nexus**
- Link to X.500 border DSAs via DSP chaining
- Link to LDAP oriented agencies via referrals
**There are other possibilities**
- CIO Council “White Pages”
- GSA
- Commercial services

## Expanded FBCA Directory Concept

***Expanded FBCA Directory Concept***

**Internal**
**Directory**
**Infrastructure**

**PCA 2**

**Internal**
**Directory**
**Infrastructure**

**Internal**
**Directory**
**Infrastructure**

**PCA 1**

**PCA 3**

**Agency 1**

**Agency 2**

**Agency 3**

**FBCA**

**LDAP**

**Query-Response**

**X.500 - DSP**

**chaining**

## 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)**
**Contract has provisions for ACES-enabling applications**
**Agency’s do interagency agreement with GSA**
**Certificates available within three to six months**

## Electronic Signatures under GPEA

**Government Paperwork Elimination Act (October 1998)**
**Technology neutral - agencies select based on specifics of applications (e.g., risk)**
**Gives electronic signature full legal effect**
**Focus: transactions with Federal agencies**
**Draft OMB Guidance 3/99; final 4/00**

## Organization

## Federal PKI Steering Committee

**Over 50 members from two dozen agencies**
**Three Working Groups**
**Business**
**Technical**
**Legal and Policy**
**Minutes/activities on the web**
**http://gits-sec.treas.gov**

## PKI Use and Implementation Issues

**Misunderstanding what it can and can’t do**
**Requiring legacy fixes to implement**
**Waiting for standards to stabilize**
**High cost - a yellow herring**
**Interoperability woes - a red herring**
**Legal trepidation - the brightest red herring**

## Misunderstanding what it can and can’t do

**Technical vs. legal non-repudiation**
**Probably to the former, possibly to the latter**
**Establishing a PKI <> making clients PKI-aware**
**Building the highway is not the same as building the cars that ride on the highway**

## Requiring legacy fixes to implement

**Fixing directory anarchy**
**Don’t expect directory problems to abate - they will be exacerbated**
**Mapping to legacy data bases**
**Back end applications remain**

## Waiting for standards to stabilize

**Far too much to expect**
**Evolution is constant process, it does not stop for anyone**
**And, not necessary**
**Internet standards are not stable but it still works (fitfully at times...)**
**PKI standards are good enough for enterprise deployment, getting there for interoperability**

## High cost - a yellow herring

**Cost of ownership is not low**
**Registration, certificates, CRLs, PKI-aware clients, repositories, directories, and so on**
**But, compared to what?**
**Multiple stove-piped PIN applications with poor security?**

## Interoperability woes - a red herring

**Interoperability often not needed in enterprise applications (single product)**
**Even where needed, interproduct interoperability getting much better (Federal Bridge CA will help drive)**
**No reason to delay use of this technology**

## Legal trepidation - the brightest red herring

**PK technology is NOT the most complex subject presented in a courtroom**
**Case law only develops when you use something**
**Technology and commerce marches on regardless of legal uncertainties**
**Unreasonable to demand standard of proof higher than in paper world**