Higher Ed PKI Policy Activities Group October

Higher Ed PKI – Policy Activities Group October 5, 2001 David L. Wasley University of California David L. Wasley http: //www. ucop. edu/irc/staff/david. wasley. html Office of the President University of California

HEPKI-PAG v Trust l l issues and trust framework for PKI Lots of practical problems to grapple with Who do you trust? How much trust is enough? v Attempt to compare trust models in education, research, government and commercial sectors l l All over the map! PKI “bridges” require trust mapping v Attempt to identify trust requirements of apps 2 v A near term goal is generic HE Certificate Policy

Certificate Policy is … v The basis for trust between unrelated entities v Not a formal “contract” (but implied) v A framework that both informs and constrains a PKI implementation v A way of giving advice to Relying Parties v One of a number of related documents, incl. l l Certification Practices Directory Policy 3

Goals v. A “generic” CP for higher ed PKI v All implementation specific details deferred to associated Certification Practices Statement v CP requirements intended to foster interdomain trust v Compatible with the Federal BCA policy v Multiple “levels of assurance” l l “Rudimentary” level (PKI Lite, minimal overhead) 4 “High” (requires photo IDs & smartcards)

PKI Players v Policy l Management Authority (PMA) Responsible for developing and enforcing policy v Certificate l l Authority (CA) Operational unit(s) Term also applies to the entire set of functions v Registration l Authority (RA) Optional, delegated responsibility for I & A v Subjects and Relying Parties 5

RFC 2527 CP Sections Introduction v General Provisions v Identification and Authentication v Operational Requirements v Physical, Procedural and Personnel Security Ctrls v Technical Security Controls v Certificate and CARL/CRL Profiles v Specification Administration v 6

Introduction v Distinction between CP and CPS v CP is transitive throughout the hierarchy l Authorizing CA has responsibility for authorized CA v Document l identity OID for the CP and OIDs for each LOA v Community l served is defined in the CPS Relying Party can’t make assumptions unless so stated v On-line copy of CP and CPS must be signed 7

Introduction (cont. ) v Applicability of the issued certificates based on Level of Assurance (LOA) l l 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 v CPS l can proscribe specific application types In case liability is a concern 8

General Provisions v Obligations l l CA, RA, Subscriber, Relying Party, Repository RP is problematic since there is no “contract” s s “Requirements” e. g. checking CRL, are advice In some cases a contract may be needed, e. g. FERPA v Liability l – limited to $1, 000 Considered necessary to indicate trustworthiness v Audit l of the parties requirements Must be performed by qualified third party 9

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

Operational Requirements v CA l may not generate key pairs for Subjects For encryption certs, an intermediary might… v PKC acceptance for Med/High require signature v PKC Suspension or Revocation l l Suspension not used Revocation required at Basic or higher LOA s s Requires standard CRL; allows for OCSP Relying Party required to check for revocation 11

Operational Requirements (cont. ) v Security l l Everything that might affect the CA or RA Simpler for Rudimentary v Records l l Audit Procedure Archival Up to 20+ years for High LOA (Electronic archive is an activity unto itself) v Disaster Recovery Requirements v CA Termination Process 12

Physical, Procedural and Personnel Security Controls v CA l l Roles Administrator - sysadmin; installs & configures Officer - approves issuance and revocation of PKCs Operator - routine system operation & backup Auditor - reviews syslogs; oversees external audit v Separation l l of roles required at least 2 people (Admin. /Op. & Officer/Auditor) at least 3 at higher LOAs v Some tasks require action by 2 out of 4 persons 13

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

Certificate and CARL/CRL Profiles v Certificate l l l Details in CPS Cert. Policy. ID is the LOA OID CPSuri points to the on-line signed CPS s l l profile is x. 509 v 3 or higher 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 authority. Key. Identifier v CARL/CRL is x. 509 v 2 or higher 15

Specification Administration v Framework for how the PMA changes or updates this policy document l Notifying Subjects is hard s l Notifying Relying Parties is impossible s l Publication is considered sufficient Policy in force at time of issue prevails Significant change requires new OID(s) v See also the Bibliography and Glossary 16

Other Policy Documents v Certification l l All specific details, e. g. community, I&A, etc. HE draft example begun … v Directory l l Policy Statement As critical as the credential Includes access controls, element definitions, etc… v Local l Practices Statement campus Business Policy Provisions The basis for the institution to issue credentials 17

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

HE CP Status v Draft l completed Will be vetted to wider audience, e. g. NACUA v Companion HEBCA CP needs to be reviewed to ensure compatibility v Generic OIDs may be acquired for CP, LOAs v Example CPS(s) will be generated v Notes for CA implementers will be created v See http: //www. educause. edu/hepki/ 19

HE CP Acknowledgements v Richard Guida, Federal PKI Council v Ken Klingenstein and the I 2 HEPKI-PAG v Judith Boettcher and Dan Burke, CREN v Scott Fullerton, Wisconsin-Madison v Art Vandenburg, Georgia State v Ed Feustel, Dartmouth College v Support: Renee Frost, Ellen Vaughan, Nate Klingenstein (I 2), Michelle Gildea (CREN) 20