# Presentation: 871612

## The Evolving Federal PKI

**Richard Guida, P.E.**
**Chair, Federal PKI Steering Committee**

**Richard.Guida@cio.treas.gov; 202-622-1552**
**(Steering Committee web page: 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**

## 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 an “agency”**
**Governing body for interoperability through FBCA**
** ****Agency/FBCA certificate policy mappings**
**Oversees operation of FBCA, authorizes issuance of FBCA certificates**
**Six charter members**

## 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 ARLs**

## Current Status

**Prototype FBCA: Entrust, Cybertrust (replaced with Baltimore Unicert)**
**Initial operation 2/8/00**
**Production FBCA: add other CAs**
**Operational by late 00**
**FBCA Operational Authority is GSA (Mitretek technical lead and host site)**
**FBCA Cert Policy by mid-00**
**FPKIPA operational 7/00**

## Canada

- Cybertrust CA

- Entrust CA

*Federal Bridge CA*

- SFL
- Client

- Entrust
- Client

*Entrust*

- Entrust
- Client

- SFL
- Client

- DoD Bridge CA

*Entrust*

*Spyrus*

*Motorola*

- Entrust
- Client

*Entrust*

- NSA

- Entrust
- Client

*Entrust*

- Entrust
- Client

*Entrust*

- PCA

*Entrust*

- PCA

- CA

- PCA

- CA

- CA

- CA

- PCA

- CA

- CA

- PCA

- CA

- CA

- PCA

- NASA

- PCA

- GTRI

- PCA

- NIST 1

- Entrust
- Client

- NIST 2

- SFL
- Client

- PCA

*CYBERTRUST*

- GSA/FTS

- CYGNACOM

## Intra-Agency PKI Examples

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

## Planned Interagency Uses

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

## Border Directory Concept

*Border 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), third award 10/99 (AT&T)**
**Provisions for ACES-enabling applications, and developing customized PKIs**
**Agencies do interagency agreement with GSA**
**Certificates available now (President used the first one in signing E-Sign bill 6/30/00)**

## USPS Issues

**USPS very well positioned to serve as RA**
**USPS partnering with AT&T and IBM on branded secure e-mail**
**USPS intends to interoperate with FBCA and thus support multiple CA sources**
**Bottom line: USPS can become important source of PKI products and services to Federal agencies**

## Commercial Implementations

**Scotiabank (300K+ certs; 500K transactions per month)**
**American Express “Blue”**
**Identrus bank consortium**
**Large manufacturing companies for internal uses (GE, automobile manufacturers)**

## Electronic Signatures under GPEA

**Government Paperwork Elimination Act (October 1998)**
**Technology neutral - agencies select based on specifics of applications (e.g., risk)**
**But full recognition of dig sig strengths**
**Gives electronic signature full legal effect**
**Focus: transactions with Federal agencies**
**Draft OMB Guidance 3/99; final 5/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**

## 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**