Higher Ed Bridge CA

Extending Trust Across Higher Education

- And Beyond

David L. Wasley

University of California

2

The PKI Puzzle

Fed Bridge Educause HE Bridge

PKI provides:• Strong Authentication• Flexible Authorization• Secure Digital Signature• Powerful Data Security

VendorResources

CampusResources

CREN Root CA

CampusSystems

CampusPKI

Directory

ServerCerts

ShibCampusSystems

CampusPKI

Directory

COMPKI

Hierarchy

EDUPKI

Hierarchy

3

What is a “Bridge” ?

A mechanism for creating “trust paths” between otherwise unrelated PKI hierarchies

In essence allows two parties to find a common trusted “root”

The difficult problem is reconciling the basis for trust across PKI domains

In practice, not all “relying party” software knows how to cross a bridge (yet).

4

How does it work?

Two models Cross-certification Trust Broker (M-bridge)

Current Fed bridge uses cross certification Each party “trusts” a common Policy mapping body Trust paths instantiated by x.509 cross-certificates Constraints on “trust” paths defined in cert fields

M-bridge allows for much more granular “trust” Requires new type of server & software

5

Components of Inter-PKI Trust

Hierarchies & cross-certification are technical basis Hierarchy root CA 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 CA can link 2 hierarchies policy and practices must be “mapped” - rough equivalency bi-directional or cross-certification forms a link between them a “bridge CA” can link may different hierarchies

Hierarchies vs Bridges a practical implementation issue concerns include transitivity and delegation

common trust model vs mapped trust

6

A CA can recognize another CA by issuing it a second Authority PKC

Allows Relying Party 4 to “trust” Client 2 They have a common “trusted” point (A) RP1 can’t find a common point WRT C3

RP4

C3

B

RP1

C2

A

7

CAs can cross-certify each other

Allows all parties to “trust” each other Doesn’t scale!

C

RP5

C6

RP1

C2

A

RP4

C3

B

8

Simple Bridge Model

Bridge maps “policy” among PKI domains

Bridge CA

C

RP5

C6

RP1

C2

A

RP4

C3

B

9

Simple Broker Model

Provides more granular control of trust paths New protocol and software required

Trust Broker

???

C

RP5

C6

RP1

C2

A

RP4

C3

B

10

Trust Mapping

Basically mapping “levels of assurance” (LOA) How trustworthy is the credential?

A single “policy” can define multiple LOAs X.509 allows for multiple OID mapping OIDs represent LOAs, not the policy per se

Multiple policies can refer to the same LOA(s) But only if all conditions and requirements are alike Makes mapping simple

Multiple PKIs can reference the same policy!

11

Trust Constraints

How many bridges are you willing to cross? and/or CAs

What SubjectName(s) are you willing to see? both inclusive and/or exclusive naming hierarchies might be supported

This is an area that hasn’t been tested a lot (yet) requires sophisticated Relying Party software e.g. Federal bridge “CAM” software

12

Educause HEBCA

Educause has contracted with Mitretek for a test (cross-cert) bridge

Is prepared to implement a production bridge Wants to understand pros & cons of the 2 models

Bridge policy mapping authority will be constituted with advice from member CIOs

Operation of the HEBCA may be outsourced Mark Luker and Steve Worona are leading this

13

Issues

Goal is to be 100% compatible with FBCA Mapping LOAs will require appropriate CP/CPS

Common CP can help Can all Federal requirements be met?

e.g. I & A, technical, staffing, . . . May start with only lower LOAs . . .

Can commercial PKIs be bridged into HEBCA?? CPs are very different May be resistant . . .