190 likes | 204 Views
This draft document serves as a framework for a PKI implementation in higher education institutions, offering guidelines and standards for trust building among entities. It covers key aspects such as identification, authentication, operational and security controls, and more. The policy aims to enhance inter-domain trust and ensure secure transactions within the educational sector.
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)