The Evolving Federal PKI

1
The Evolving Federal PKI
Richard Guida, P.E. Member, Government
Information Technology Services Board Chair,
Federal PKI Steering Committee
Richard.Guida_at_cio.treas.gov 202-622-1552 http//g
its-sec.treas.gov
2
E-Transaction Landscape

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

3
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

4
Challenges All Applications Face

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

5
Public Key Technology

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

6
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

7
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 senders raw hash
• If raw hashes are same, transaction validates

8
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

9
The Critical Questions

• How can the recipient know with certainty the
  senders public key? (to validate a digital
  signature)
• How can the sender know with certainty the
  recipients public key? (to send an encrypted
  message)

10

Public Key Certificate

• 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 individuals public key and some
  form of the individuals identity
• has a finite validity period

11
X.509 v3 Certificate
12
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

13
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

14
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)

15
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

16
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

17
Current Status

• Prototype FBCA Entrust and Cybertrust
  (Baltimore) CAs
• Began operation 2/8/00
• Used for EMA Challenge 4/6/00
• Migration from prototype to production FBCA will
  entail adding other CAs inside the membrane
• GSA/FTS has responsibility to execute

18
Schedule

• Draft Bridge Certificate Policy late 1999 (done
  - CIO Council reviewing)
• Draft FPKIPA Charter/CONOPS late 1999 (done -
  CIO Council reviewing)
• Prototype Bridge early 2000 (done - 2/8)
• Operational Bridge late 2000

19
FBCA Directory Concept
Agency 3
Internal Directory Infrastructure
PCA 1
PCA 3
PCA 2
FBCA
Agency 2
Agency 1
LDAP
X.500 - DSP
Internal Directory Infrastructure
chaining
Query-Response
Internal Directory Infrastructure
20
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

21
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 (ATT)
• Contract has provisions for ACES-enabling
  applications
• Potential use with state/local government
• Certificates available very shortly

22
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

23
Organization
24
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

25
PKI Use and Implementation Issues

• Misunderstanding what it can and cant 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