130 likes | 215 Views
Higher Ed Bridge CA. Extending Trust Across Higher Education - And Beyond David L. Wasley University of California. The PKI Puzzle. What is a “Bridge” ?. A mechanism for creating “trust paths” between otherwise unrelated PKI hierarchies
E N D
Higher Ed Bridge CA Extending Trust Across Higher Education - And Beyond David L. Wasley University of California
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).
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
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
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
CAs can cross-certify each other • Allows all parties to “trust” each other • Doesn’t scale!
Simple Bridge Model • Bridge maps “policy” among PKI domains
Simple Broker Model • Provides more granular control of trust paths • New protocol and software required
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!
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
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
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 . . .