A PKI Certificate Policy for Higher Education

1
A PKI Certificate Policy for Higher Education

• A Work in ProgressDraft 0.010
• David L. Wasley
• University of California

2
Certificate Policy is

• The basis of trust between unrelated entities
• Not a contract
• A framework that informs/constrains a PKI
  implementation
• A way of giving advice to Relying Parties
• One of a number of related documents, incl.
• Certification Practices
• Directory Policy

3
Goals

• A generic CP for higher ed PKI
• Compatible with the Federal BCA policy
• Simple (relatively) to implement at the
  Rudimentary level (PKI Lite)
• Specific requirements intended to foster inter-
  domain trust
• All implementation specific details deferred to
  associated Certification Practices Statement

4
PKI Players

• Policy Management Authority (PMA)
• Responsible for developing end enforcing policy
• Certificate Authority (CA)
• Operational unit(s)
• Term also applies to the entire set of functions
• Registration Authority (RA)
• Optional delegated responsibility for I A
• Relying Parties

5
RFC 2527 CP Sections

• Introduction
• General Provisions
• Identification and Authentication
• Operational Requirements
• Physical, Procedural and Personnel Security Ctrls
• Technical Security Controls
• Certificate and CARL/CRL Profiles
• Specification Administration

6
Introduction

• Distinction between CP and CPS
• CP is transitive throughout the hierarchy
• Authorizing CA has responsibility for authorized
  CA
• Document identity
• OID for the CP and OIDs for each LOA
• On-line copy of CP and CPS must be signed
• Community served may be any defined in the CPS
• Relying Party cant make assumptions unless so
  stated

7
Introduction (cont.)

• Applicability of the issued certificates based on
  Level of Assurance (LOA)
• Test - used for development and testing only
• Rudimentary - very low risk apps data integrity
• Basic - for apps with minimal risk
• Medium - modest risk, including monetary loss
• High - secure apps transactions of significant
  financial consequence

8
General Provisions

• Obligations of the parties
• CA, RA, Subscriber, Relying Party, Repository
• RP is problematic since there is no contract
• In some cases a contract may be needed, e.g.
  FERPA
• Liability limited to 1,000
• Considered necessary to indicate trustworthiness
• Audit requirements
• Must be performed by qualified third party
• Results must be made available

9
Identification and Authentication

• Types of Subject names
• If included, must be meaningful
• Must be unique for all time
• Different requirements for each LOA
• Photo ID required for Medium or High LOA
• Document ID marks must be recorded and archived
• CA rekey requirements
• Must notify PKC Subjects

10
Operational Requirements

• CA may not generate key pairs for Subjects
• PKC acceptance for Med/High require signature
• PKC Suspension or Revocation
• Suspension not used
• Revocation required at Basic or higher LOA
• Requires standard CRL allows for OCSP
• Relying Party required to check for revocation

11
Operational Requirements (cont.)

• Security Audit Procedure
• Everything that might affect the CA or RA
• Simple for Rudimentary
• Records Archival
• Up to 20 years 6 months for High LOA
• (Electronic archive is an activity unto itself)
• Disaster Recovery Requirements
• CA Termination Process

12
Physical, Procedural and Personnel Security
Controls

• CA Roles may change
• Administrator - sysadmin installs configures
• Officer - approves issuance and revocation of
  PKCs
• Operator - routine system operation backup
• Auditor - reviews syslogs oversees external
  audit
• Separation of roles required at higher LOAs
• Some tasks require action by 2 out of 4 persons

13
Technical Security Controls

• FIPS 140 Technical Security
• Level depends on LOA
• Key sizes and private key protection requirements
• Escrow of end-entity decryption (private) key
• CA must have possession of key before issuing PKC
• Must NOT escrow any other private key
• Computer platform and network controls
• Engineering and development controls

14
Certificate and CARL/CRL Profiles

• Certificate profile is x.509v3 or higher
• Details in CPS
• CertPolicyID is the LOA OID
• CPSuri points to the on-line signed CPS
• CPS specifies CP OID and URL where it can be
  found
• Certificate serial number must be unique across
  all PKCs issued by this CA
• CARL/CRL is x.509v2 or higher

15
Specification Administration

• Specifies how the PMA changes or updates this
  policy document, etc.
• See also the Bibliography and Glossary

16
Other Policy Documents

• Certification Practices Statement
• All specific details, e.g. community, IA, etc.
• HE draft example begun
• Directory Policy Statement
• As critical as the credential
• Includes access controls, element definitions,
  etc
• Business Policy Provisions
• The basis for the institution to issue credentials

17
Similar CPs for Comparison

• Federal BCA Certificate Policy
• European PKI certificate policy
• Globus Grid CP
• Draft Model Interstate Certificate Policy
• Commercial PKI CPs (very different)
• CP for the State of Washington
• NACHA CARAT guidelines

18
HE CP Status

• Draft in process for 9 months
• Will be vetted to wider audience ASAP
• Companion HEBCA CP needs to be reviewed to ensure
  compatibility
• Generic OIDs may be acquired for CP, LOAs
• Example CPS(s) will be generated
• Notes for CA implementers will be created
• See http//www.educause.edu/hepki/

19
Acknowledgements

• Richard Guida, Federal PKI Council
• Ken Klingenstein and the I2 HEPKI-PAG
• Judith Boettcher, CREN
• Dan Burke, Legal Council, CREN
• Scott Fullerton -- Wisconsin-Madison
• Art Vandenburg -- Georgia State
• Support Renee Frost, Ellen Vaughan, Nate
  Klingenstein (I2), Michelle Gildea (CREN)