Higher Ed PKI Certificate Policy

1. 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 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. 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