1. Higher Ed Bridge CA Extending Trust Across Higher Education - And Beyond David L. Wasley University of California

2. 2 The PKI Puzzle

3. 3 What is a “Bridge” ? v A mechanism for creating “trust paths” between otherwise unrelated PKI hierarchies v In essence allows two parties to find a common trusted “root” v The difficult problem is reconciling the basis for trust across PKI domains v In practice, not all “relying party” software knows how to cross a bridge (yet).

4. 4 How does it work? v Two models l Cross-certification l Trust Broker (M-bridge) v Current Fed bridge uses cross certification l Each party “trusts” a common Policy mapping body l Trust paths instantiated by x.509 cross-certificates l Constraints on “trust” paths defined in cert fields v M-bridge allows for much more granular “trust” l Requires new type of server & software

5. 5 Components of Inter-PKI Trust v Hierarchies & cross-certification are technical basis l Hierarchy root CA issues authority certs to other CAs s subordinate CAs may (or may not) do the same s policy and practice conformity is enforced from the top l Certification of a CA by another CA can link 2 hierarchies s policy and practices must be “mapped” - rough equivalency s bi-directional or cross-certification forms a link between them s a “bridge CA” can link may different hierarchies v Hierarchies vs Bridges l a practical implementation issue l concerns include transitivity and delegation s common trust model vs mapped trust

6. 6 A CA can recognize another CA by issuing it a second Authority PKC v Allows Relying Party 4 to “trust” Client 2 l They have a common “trusted” point (A) l RP1 can’t find a common point WRT C3

7. 7 CAs can cross-certify each other v Allows all parties to “trust” each other l Doesn’t scale!

8. 8 Simple Bridge Model v Bridge maps “policy” among PKI domains

9. 9 Simple Broker Model v Provides more granular control of trust paths l New protocol and software required

10. 10 Trust Mapping v Basically mapping “levels of assurance” (LOA) l How trustworthy is the credential? v A single “policy” can define multiple LOAs l X.509 allows for multiple OID mapping l OIDs represent LOAs, not the policy per se v Multiple policies can refer to the same LOA(s) l But only if all conditions and requirements are alike l Makes mapping simple v Multiple PKIs can reference the same policy!

11. 11 Trust Constraints v How many bridges are you willing to cross? l and/or CAs v What SubjectName(s) are you willing to see? l both inclusive and/or exclusive l naming hierarchies might be supported v This is an area that hasn’t been tested a lot (yet) l requires sophisticated Relying Party software l e.g. Federal bridge “CAM” software

12. 12 Educause HEBCA v Educause has contracted with Mitretek for a test (cross-cert) bridge v Is prepared to implement a production bridge l Wants to understand pros & cons of the 2 models v Bridge policy mapping authority will be constituted with advice from member CIOs v Operation of the HEBCA may be outsourced v Mark Luker and Steve Worona are leading this

13. 13 Issues v Goal is to be 100% compatible with FBCA v Mapping LOAs will require appropriate CP/CPS l Common CP can help l Can all Federal requirements be met? s e.g. I & A, technical, staffing,... l May start with only lower LOAs... v Can commercial PKIs be bridged into HEBCA?? l CPs are very different l May be resistant...