190 likes | 195 Views
This draft outlines a PKI Certificate Policy for the higher education sector. It provides a framework for implementing and managing PKI within universities, ensuring trust and security in digital transactions. The policy covers identification and authentication, operational requirements, security controls, and certificate profiles.
E N D
A PKI Certificate Policy for Higher Education A Work in ProgressDraft 0.010 David L. Wasley University of California
Certificate Policy is … • The basis of trust between unrelated entities • Not a “contract” • A framework that informs/constrains a PKI implementation • A way of giving advice to Relying Parties • One of a number of related documents, incl. • Certification Practices • Directory Policy
Goals • A “generic” CP for higher ed PKI • Compatible with the Federal BCA policy • Simple (relatively) to implement at the “Rudimentary” level (PKI Lite) • Specific requirements intended to foster inter- domain trust • All implementation specific details deferred to associated Certification Practices Statement
PKI Players • Policy Management Authority (PMA) • Responsible for developing end 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 • Relying Parties
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
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 • On-line copy of CP and CPS must be signed • Community served may be any defined in the CPS • Relying Party can’t make assumptions unless so stated
Introduction (cont.) • Applicability of the issued certificates based on Level of Assurance (LOA) • Test - used for development and testing only • 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
General Provisions • Obligations of the parties • CA, RA, Subscriber, Relying Party, Repository • RP is problematic since there is no “contract” • 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 • Results must be made available
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 …
Operational Requirements • CA may not generate key pairs for Subjects • 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
Operational Requirements (cont.) • Security Audit Procedure • Everything that might affect the CA or RA • Simple for Rudimentary • Records Archival • Up to 20 years + 6 months for High LOA • (Electronic archive is an activity unto itself) • Disaster Recovery Requirements • CA Termination Process
Physical, Procedural and Personnel Security Controls • CA Roles [may change] • 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 higher LOAs • Some tasks require action by 2 out of 4 persons
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
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 where it can be found • Certificate serial number must be unique across all PKCs issued by this CA • CARL/CRL is x.509v2 or higher
Specification Administration • Specifies how the PMA changes or updates this policy document, etc. • See also the Bibliography and Glossary
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… • Business Policy Provisions • The basis for the institution to issue credentials
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
HE CP Status • Draft in process for 9 months • Will be vetted to wider audience ASAP • 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/
Acknowledgements • Richard Guida, Federal PKI Council • Ken Klingenstein and the I2 HEPKI-PAG • Judith Boettcher, CREN • Dan Burke, Legal Council, CREN • Scott Fullerton -- Wisconsin-Madison • Art Vandenburg -- Georgia State • Support: Renee Frost, Ellen Vaughan, Nate Klingenstein (I2), Michelle Gildea (CREN)