Higher Ed PKI Certificate Policy David L Wasley

Higher Ed PKI Certificate Policy David L. Wasley University of California I 2 Middleware Camp David L. Wasley 02/02/02 Office of the President University of California

HEPKI-PAG v HEPKI is a cooperative effort of CREN, EDUCAUSE/Net@EDU, and Internet 2 v Policy Activities Group (PAG) works on trust issues and trust framework for PKI l l l Why do you trust? How much trust is enough? Certificate Policy -- now in DRAFT Certification Practices Statement -- T. B. D. s l Will also draft a PKI CP/CPS Implementers Guide Directory Policy -- next “interesting” hurdle 2

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 statement of what a certificate means v a set of rules for certificate holders v a way of giving advice to Relying Parties 3

HEPKI HE CP v. A l l l “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 v Compatible with the Federal BCA policy v Four “levels of assurance” l l from “Rudimentary” level (minimal overhead) to “High” (requires photo IDs & smartcards) 4

CP says basically… v Who is responsible for the RA/CA operation v What is the community served l Important for RP to know what meaning to derive v What are the rules for identifying Subjects v What’s in a certificate v What constraints are there on operation of the CA v What must be done if something goes wrong 5

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 PKI functions v Registration l Authority (RA) Optional, given responsibility for I & A v Subjects and Relying Parties 6

Framework v Document l OID for the CP and OIDs for each LOA v PMA l and community are defined in the CPS Relying Party can’t make assumptions unless so stated v CP l is transitive throughout the hierarchy Authorizing CA has responsibility for authorized CA v Liability l identity limitations CPS can proscribe specific uses of certificates 7

Applicability v Applicability of issued certificates is 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 Relying Party must make the decision about what LOA is required 8

Obligations of the Parties v CA, l “the right thing” depends on LOA v RP l l RA, Subscriber, Relying Party, Repository is problematic since there is no “contract” “Requirements” are advice, e. g. checking CRL Sometimes a contract may be needed, e. g. FERPA v Audit l l requirements CA must be audited by a qualified third party May review audits of subordinate CA’s 9

Identification and Authentication v Different l l Photo ID required for Medium or High LOA ID Document S/N’s must be recorded and archived v Types l l requirements for each LOA of Subject names If included, must be meaningful Must be unique for all time v Association of Subject with “directory data” must be accurate 10

Operational Requirements v CA l must protect its private key appropriately Must not generate key pairs for Subjects v Certificate l Revocation required at Basic or higher LOA s s l Requires standard CRL; allows for OCSP Relying Party required to check for revocation Suspension not used v Security l management Audit Procedure Everything that might affect the CA or RA 11

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 12

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 13

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. Info. Access v CARL/CRL is x. 509 v 2 or higher 14

Other CPs for Comparison v Federal BCA Certificate Policy v Euro. PKI CP, Swedish Univ. CP, SURFnet CPS 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 15

HE CP Status v Draft l l completed http: //middleware. internet 2. edu/certpolicies/ Being 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 16

PKI-Lite v Cookbook approach to getting started w/PKI v Minimal requirements l Roughly equivalent to issuing student ID cards v Primarily for intra-campus applications v Should be sufficient for signed e-mail (S/MIME) v Simple CP/CPS single document l See http: //middleware. internet 2. edu/hepki-tag/ v CREN may issue the authority certs 17