Higher Ed PKI – Draft Certificate Policy

1. Higher Ed PKI –Draft Certificate Policy David L. Wasley University of California Common Solutions Group January 9, 2002

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. • 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 • 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. HECP isn’t formidable • It’s 80+ pages but it’s mostly common sense. • Patterned after RFC 2527 - rather dry & technical • Basically … • Who is responsible for the RA/CA operation? • What is the community served? • 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, delegated 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 (RP), Repository • 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 OCSP • Relying 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. 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

16. HE CP Status • Draft completed • Will be vetted to wider audience, e.g. NACUA • Companion HEBCA CP needs to be reviewed for compatibility • Generic OIDs may be acquired for CP, LOAs • Example CPS(s) will be generated • Notes for CA implementers will be created • http://middleware.internet2.edu/certpolicies/

17. PKI-Lite • Minimal requirements • Roughly equivalent to issuing student ID cards • Primarily for intra-campus applications • Should be sufficient for signed e-mail • Simple CP/CPS document now being finalized • CREN may issue the authority certs • CA platform(s) yet to be defined

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