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

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. s Will also draft a PKI CP/CPS Implementers Guide 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 Based on IETF RFC 2527 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 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

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, given 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, Repository l “the right thing” depends on LOA 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 Other CPs for Comparison v Federal BCA Certificate Policy v EuroPKI 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

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

17. 17 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.internet2.edu/hepki-tag/ v CREN may issue the authority certs

18. 18 CREN Update