1 / 12

Bridge Certification Architecture

Bridge Certification Architecture. A Brief Demo by Tim Sigmon and Yuji Shinozaki June, 2000. Trust Domain. Trust domain is defined by the root (or self-signed) certificate(s) that the relying party knows and trusts (for reasons outside of PKI)

esben
Download Presentation

Bridge Certification Architecture

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. Bridge Certification Architecture A Brief Demo by Tim Sigmon and Yuji Shinozaki June, 2000

  2. Trust Domain • Trust domain is defined by the root (or self-signed) certificate(s) that the relying party knows and trusts (for reasons outside of PKI) • Very Important: Root certificates are not integrity-protected since they are self-signed • BCA provides for expansion of trust domain • without need for potentially expensive processes to add additional root certs to all relying parties • solves order N2 cross-certification problem

  3. BCA Pilot Implementation • OpenSSL (www.openssl.org) and OpenCA (www.openca.org) open source software running on Red Hat Linux • Bridge booted only to create cross certificates; can remain turned off in secure location most of the time • Cross certificates stored with relying parties and/or stored in LDAP directories (using crossCertificatePair attribute)

  4. Example application • Yuji Shinozaki has developed an example application (digitally signed web forms) to illustrate use of BCA • chose server-based app instead of email • current relying party software can only follow issuer chains (e.g., hierarchical trust relationships) • we cache all needed certs (including cross certs) at application (server); no need for directory • Yuji has implemented more general path construction as part of the server-based app • Note: for federal bridge project, Cygnacom developed Certificate Path Library (CPL) that handles very general trust relationships

  5. BCACA1 CA1BCA BCACA2 CA2BCA Signed form data and CA1Tim Digital Signature Demo in a bridge cross-certification environment Relying Party e.g., web form application 1) path construction CA1Tim CA2CA2 CA1CA1 CA1Tim Trust Domain CA2CA2 Trust Domain CA1CA1

  6. BCACA1 CA1BCA BCACA2 CA2BCA Signed form data and CA1Tim Digital Signature Demo in a bridge cross-certification environment Relying Party e.g., web form application 1) path construction CA1Tim CA2CA2 BCACA1 CA2BCA 2) path validation CA1Tim 3) signature verification Trust Domain CA2CA2 Trust Domain CA1CA1

  7. BCA Demo • http://atg2000.itc.virginia.edu/BridgeDemo

  8. Signed doc and CA1 EEA Simple Hierarchical Trust Relying Party e.g., email or web form application 1) path construction CA1EEA CA1 CA1 2) path validation 3) signature verification CA1 EEA Trust Domain CA1 CA1 Trust Domain CA1 CA1

  9. Trust Domain Expansion Hierarchical CA’s (Governor) Note: relying party follows issuer chain to verify cert of EE1 (SoED) (DGIF) CA5EE1 (UVa) trusted CA1CA1 (Darden) (tms) CA1CA1 CA1CA2 CA1CA3 CA2CA5 CA1CA2 CA2CA4 CA2CA5 CA5CA6 CA5EE1

  10. Trust Domain Expansion Hierarchical CA’s • Multiple root certificates • disservice of Microsoft and Netscape . . . CAACAA CABCAB CACCAC CAZCAZ ... ... ... ... CA1CA1 CA1CA2 CA1CA3 CA2CA4 CA2CA5 Note: if CA1’s private key is compromised, the entire hierarchy collapses CA5CA6 CA5EE1

  11. Trust Domain Expansion (cont’d) Cross certification two CA’s issue certificates to each other (a cross-certificate pair), i.e., sign each other’s public keys • N2 problem if N CA’s want to cross-certify with each other CAACAB CAACAA CABCAB CABCAA ... ... CABEE1

  12. Bridge Certification Architecture addresses the N2 problem by providing a central cross-certification hub for a group of CA’s who wish to interoperate each CA does one cross-certification with the bridge CA • Certificate path processing (construction & validation) CA5EE2 trusted CA1CA1 CAbridgeCA5 CA1CAbridge

More Related