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

2. 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 l Why do you trust? How much trust is enough? l Certificate Policy -- now in DRAFT l Certification Practices Statement -- T.B.D. l Directory Policy -- next “interesting” hurdle

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

4. 4 HEPKI HE CP v A “generic” CP for higher ed PKI l A set of rules and requirements intended to foster inter-domain trust l All implementation specific details deferred to associated Certification Practices Statement v Compatible with the Federal BCA policy v Four “levels of assurance” l from “Rudimentary” level (minimal overhead) l to “High” (requires photo IDs & smartcards)

5. 5 HECP isn’t formidable v It’s 80+ pages but it’s mostly common sense. l Patterned after RFC 2527 - rather dry & technical v Basically … l Who is responsible for the RA/CA operation? l What is the community served? l What are the rules for identifying Subjects? l What’s in a certificate? l What constraints are there on operation of the CA? l What must be done if something goes wrong?

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

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

8. 8 Applicability v Applicability of issued certificates is based on Level of Assurance (LOA) l Rudimentary - very low risk apps; data integrity l Basic - for apps with minimal risk l Medium - modest risk, including monetary loss l High - secure apps; transactions of significant financial consequence v Relying Party must make the decision about what LOA is required

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

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

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

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

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

14. 14 Certificate and CARL/CRL Profiles v Certificate profile is x.509v3 or higher l Details in CPS l CertPolicyID is the LOA OID l CPSuri points to the on-line signed CPS s CPS specifies CP OID and URL for on-line copy l Certificate serial number must be unique across all PKCs issued by this CA l Considering adding URI to authorityInfoAccess v CARL/CRL is x.509v2 or higher

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

16. 16 HE CP Status v Draft completed l Will be vetted to wider audience, e.g. NACUA v Companion HEBCA CP needs to be reviewed for 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 http://middleware.internet2.edu/certpolicies/ http://middleware.internet2.edu/certpolicies/

17. 17 PKI-Lite 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 v Simple CP/CPS document now being finalized v CREN may issue the authority certs v CA platform(s) yet to be defined

18. 18 HE CP Acknowledgements v Richard Guida, Federal PKI Council v Ken Klingenstein and the I2 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 (I2), Michelle Gildea (CREN)