1 / 11

Establishing Trust in Certificate Authorities and Policy Mapping

Explore the concepts of certificate policies and practices, trust path creation and validation, and the mapping of policies among different authorities. Learn about the requirements, obligations, and liability issues involved in the operation and management of certificate authorities.

rhawkins
Download Presentation

Establishing Trust in Certificate Authorities and Policy Mapping

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. HEPKI-PAGPolicy 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 http://www.internet2.edu/hepki/ • Get involved!

More Related