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

Bridge CA

C

564

B

3

1

2

A

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!