1 / 19

A PKI Certificate Policy for Higher Education

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.

moorelisa
Download Presentation

A PKI Certificate Policy for Higher Education

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A PKI Certificate Policy for Higher Education A Work in ProgressDraft 0.010 David L. Wasley University of California

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

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

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

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

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

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

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

  9. 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 …

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

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

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

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

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

  15. Specification Administration • Specifies how the PMA changes or updates this policy document, etc. • See also the Bibliography and Glossary

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

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

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

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

More Related