HEPKI-PAG Policy Activities Group David L. Wasley University of California

2 General Issues Certificate Policy & Certification Practice Trust path creation and validation Policy Algebra Building on PKI Labs work Bridge CA and policy mapping mapping currently requires manual process Other policies PKI Subject Directory Management & Access Policy »Privacy, FERPA, HIPAA, etc. »Attribute expression syntax and semantics require agreements Legislation, activities on other communities Federal department initiatives, etc.

3 Policy and Practice The basis for trusting the certificates and everything they enable ! Policy (CP) defines the context and rules CA community obligations of CA, RA, Subject, Relying Party requirements for issuing and management of certs requirements for operation and audit of the CA and RA liability issues, etc. Practice (CPS) defines how policy is implemented in a specific CA registration, renewal, revocation processes, etc. A given Policy may inform several Practices - and vice versa

4 CP Analysis and HE CP draft Comparing CPs from FBCA, EuroPKI, Globus/GSS -- HE, research Tunitas, CHIME -- health community (HIPAA) NACHA, state CIOs (!) Entrust, Digital Signature Trust, Verisign -- commercial Goal is to draft generic CP & CPS for higher ed will aid in establishing mutual trust should be compatible with the FBCA, etc... CREN is sponsoring intensive review & refinement of draft CP Similar CP/CPS for an HEBCA Draft done but needs to be refined

5 Policy - the Establishment of Trust On what basis does a Relying Party “trust” a CA? It has some idea that it knows how the CA operates (much like life) At least these documents are needed: The Certificate Policy »requirements and constraints on the operation of the CA and RA »levels of assurance, meaning of cert contents, etc. A (set of) Certification Practices Statement(s) »how is a cert actually issued? »how is the CA operated in practice? A Directory Management Policy »how is data entered or changed? »what data can be released, and under what circumstances? Bridge Policy Management Authorities need to be able to map your CP/CPS to another CA hierarchy’s CP/CPS commonality is A Good Thing

6 Certification Practices Statement (CPS) Site specific details of operational compliance with a Cert Policy Who/what can be a Subject for this CA? Who is responsible for the physical CA, etc.? How is initial identification/authentication of Subjects accomplished? Where is the CP stored? How is revocation requested? etc. A single Policy might be referenced by a number of Practice Statements A single Practice Statement can support several Policies (CHIME) A Policy Management Authority (PMA) determines if a CPS is an appropriate implementation of a given CP.

7 Inter-organizational trust model components Certificate Policy and Certification Practices statements Hierarchies and cross certification form the technical underpinning Hierarchy starts with a root CA that issues authority certs to other CAs »subordinate CAs may (or may not) do the same »policy and practice conformity is enforced from the top Certification of a CA by another unrelated CA can link 2 hierarchies »policy and practices must be “mapped” - rough equivalency »bi-directional or cross-certification forms a bridge between them »a “bridge CA” can link may different hierarchies Hierarchies vs Bridges a philosophy and an implementation issue the concerns are transitivity and delegation hierarchies assert a common trust model and policy bridges require pairwise agreement on trust models and policy mappings

8 A Bridge CA A “Bridge CA” serves as a clearing house, mapping policy among cooperating CA hierarchies

9 Trust Chains Verifying sender-receiver comfort level by finding a common trusted entity Must be able to traverse branching paths to establish trust paths Must then use CRLs or OCSP to validate certs at each node along path If policy mapping is indicated by a cert in the path, then validation can be quite complex Software to discover and validate complex chains is rare (so far) Current practice avoids this by distributing “trusted authority certs”

10 Attribute Directory Policy Directories (typically LDAP accessible) are needed to: to store issued certs to store attributes (e.g. eduPerson) MAYBE to store private keys - for user mobility to store the CRL How is directory content created and maintained? Certain directory information must be protected institutional policy, FERPA requirements, User preferences, privacy border directories ACLs within the enterprise directory »based on PKI cert authentication! Attribute Authority »a new concept to support controlled release of Subject attributes

11 HEPKI-PAG See Get involved!

12 Certificate Policies Address (CP) Assurance levels determined by initial identification processes and other operational factors Legal responsibilities and liabilities (indemnification issues) Obligations of the parties CA, RA, Subject (cert holder), Relying Party “By making use of [this] certificate, the Relying Party agrees...” Operation of Certificate Management System(s) Archiving and auditing of CMS records Certificate revocation and renewal requirements Accompanying Certification Practices Statement(s) define specifics