Higher Ed PKI – Policy Activities Group

1. Higher Ed PKI –Policy Activities Group October 5, 2001 David L. Wasley University of California http://www.ucop.edu/irc/staff/david.wasley.html

2. HEPKI-PAG • Trust issues and trust framework for PKI • Lots of practical problems to grapple with • Who do you trust? How much trust is enough? • Attempt to compare trust models in education, research, government and commercial sectors • All over the map! • PKI “bridges” require trust mapping • Attempt to identify trust requirements of apps • A near term goal is generic HE Certificate Policy

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 way of giving advice to Relying Parties • One of a number of related documents, incl. • Certification Practices • Directory Policy

4. Goals • A “generic” CP for higher ed PKI • All implementation specific details deferred to associated Certification Practices Statement • CP requirements intended to foster inter- domain trust • Compatible with the Federal BCA policy • Multiple “levels of assurance” • “Rudimentary” level (PKI Lite, minimal overhead) • “High” (requires photo IDs & smartcards)

5. 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 functions • Registration Authority (RA) • Optional, delegated responsibility for I & A • Subjects and Relying Parties

6. RFC 2527 CP Sections • Introduction • General Provisions • Identification and Authentication • Operational Requirements • Physical, Procedural and Personnel Security Ctrls • Technical Security Controls • Certificate and CARL/CRL Profiles • Specification Administration

7. Introduction • Distinction between CP and CPS • CP is transitive throughout the hierarchy • Authorizing CA has responsibility for authorized CA • Document identity • OID for the CP and OIDs for each LOA • Community served is defined in the CPS • Relying Party can’t make assumptions unless so stated • On-line copy of CP and CPS must be signed

8. Introduction (cont.) • Applicability of the issued certificates 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 • CPS can proscribe specific application types • In case liability is a concern

9. General Provisions • Obligations of the parties • CA, RA, Subscriber, Relying Party, Repository • RP is problematic since there is no “contract” • “Requirements” e.g. checking CRL, are advice • In some cases a contract may be needed, e.g. FERPA • Liability – limited to $1,000 • Considered necessary to indicate trustworthiness • Audit requirements • Must be performed by qualified third party

10. Identification and Authentication • Types of Subject names • If included, must be meaningful • Must be unique for all time • Different requirements for each LOA • Photo ID required for Medium or High LOA • Document ID marks must be recorded and archived • CA rekey requirements • Must notify PKC Subjects …

11. Operational Requirements • CA may not generate key pairs for Subjects • For encryption certs, an intermediary might… • PKC acceptance for Med/High require signature • PKC Suspension or Revocation • Suspension not used • Revocation required at Basic or higher LOA • Requires standard CRL; allows for OCSP • Relying Party required to check for revocation

12. Operational Requirements (cont.) • Security Audit Procedure • Everything that might affect the CA or RA • Simpler for Rudimentary • Records Archival • Up to 20+ years for High LOA • (Electronic archive is an activity unto itself) • Disaster Recovery Requirements • CA Termination Process

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

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

15. 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 authorityKeyIdentifier • CARL/CRL is x.509v2 or higher

16. Specification Administration • Framework for how the PMA changes or updates this policy document • Notifying Subjects is hard • Publication is considered sufficient • Notifying Relying Parties is impossible • Policy in force at time of issue prevails • Significant change requires new OID(s) • See also the Bibliography and Glossary

17. Other Policy Documents • Certification Practices Statement • All specific details, e.g. community, I&A, etc. • HE draft example begun … • Directory Policy Statement • As critical as the credential • Includes access controls, element definitions, etc… • Local campus Business Policy Provisions • The basis for the institution to issue credentials

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

19. HE CP Status • Draft completed • Will be 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 • See http://www.educause.edu/hepki/

20. 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)