Higher Ed PKI Certificate Policy

David L. Wasley

University of California

I2 Middleware Camp

02/02/02

2

HEPKI-PAG

HEPKI is a cooperative effort of CREN, EDUCAUSE/Net@EDU, and Internet2

Policy Activities Group (PAG) works on trust issues and trust framework for PKI Why do you trust? How much trust is enough? Certificate Policy -- now in DRAFT Certification Practices Statement -- T.B.D.

Will also draft a PKI CP/CPS Implementers Guide Directory Policy -- next “interesting” hurdle

3

Certificate Policy is …

the basis for trust between unrelated entities not a formal “contract” (but implied) a framework that both informs and constrains

a PKI implementation a statement of what a certificate means a set of rules for certificate holders a way of giving advice to Relying Parties

4

HEPKI HE CP

A “generic” CP for higher ed PKI Based on IETF RFC 2527 A set of rules and requirements intended to foster

inter-domain trust All implementation specific details deferred to

associated Certification Practices Statement Compatible with the Federal BCA policy Four “levels of assurance”

from “Rudimentary” level (minimal overhead) to “High” (requires photo IDs & smartcards)

5

CP says basically…

Who is responsible for the RA/CA operation What is the community served

Important for RP to know what meaning to derive What are the rules for identifying Subjects What’s in a certificate What constraints are there on operation of the CA What must be done if something goes wrong

6

PKI Players

Policy Management Authority (PMA) Responsible for developing and enforcing policy

Certificate Authority (CA) Operational unit(s) Term also applies to the entire set of PKI functions

Registration Authority (RA) Optional, given responsibility for I & A

Subjects and Relying Parties

7

Framework

Document identity OID for the CP and OIDs for each LOA

PMA and community are defined in the CPS Relying Party can’t make assumptions unless so stated

CP is transitive throughout the hierarchy Authorizing CA has responsibility for authorized CA

Liability limitations CPS can proscribe specific uses of certificates

8

Applicability

Applicability of issued certificates is based on Level of Assurance (LOA) 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 Relying Party must make the decision about what

LOA is required

9

Obligations of the Parties

CA, RA, Subscriber, Relying Party, Repository “the right thing” depends on LOA

RP is problematic since there is no “contract” “Requirements” are advice, e.g. checking CRL Sometimes a contract may be needed, e.g. FERPA

Audit requirements CA must be audited by a qualified third party May review audits of subordinate CA’s

10

Identification and Authentication

Different requirements for each LOA Photo ID required for Medium or High LOA ID Document S/N’s must be recorded and archived

Types of Subject names If included, must be meaningful Must be unique for all time

Association of Subject with “directory data” must be accurate

11

Operational Requirements

CA must protect its private key appropriately Must not generate key pairs for Subjects

Certificate management Revocation required at Basic or higher LOA

Requires standard CRL; allows for OCSPRelying Party required to check for revocation

Suspension not used Security Audit Procedure

Everything that might affect the CA or RA

12

Physical, Procedural and Personnel Security Controls

CA Roles 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 least 2 people (Admin./Op. & Officer/Auditor) at least 3 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 for on-line copy Certificate serial number must be unique across all

PKCs issued by this CA Considering adding URI to authorityInfoAccess

CARL/CRL is x.509v2 or higher

15

Other CPs for Comparison

Federal BCA Certificate Policy EuroPKI CP, Swedish Univ. CP, SURFnet CPS Globus Grid CP Draft Model Interstate Certificate Policy Commercial PKI CPs (very different) CP for the State of Washington NACHA CARAT guidelines

16

HE CP Status

Draft completed http://middleware.internet2.edu/certpolicies/ Being vetted to wider audience, e.g. NACUA

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

17

PKI-Lite

Cookbook approach to getting started w/PKI Minimal requirements

Roughly equivalent to issuing student ID cards Primarily for intra-campus applications Should be sufficient for signed e-mail (S/MIME) Simple CP/CPS single document

See http://middleware.internet2.edu/hepki-tag/ CREN may issue the authority certs