Side-Effects of Cross-Certification

1. Side-Effects of Cross-Certification April 20, 2005 James L. Fisher, Ph.D.

2. Purpose • Help the inexperienced to wisely avoid pitfalls discovered (and imagined) by others • Motivate the savvy thinkers to advance fixes to help certificate bridge environments progress to the next level of maturity • Give insight into how certain technical decisions impact operational capabilities and/or legal standing if ($my->glass >= 0.5*$full) then { $quote= “Good advice is something a man gives when he is too old to set a bad example. -- La Rouchefoucauld”; } else { $quote= “It may be that your whole purpose in life is simply to serve as a warning to others.”; }

3. Topics To Be Covered • X.500/LDAP certificate directory implementation and interoperability requirements • Transitive and asymmetrical trust • Choosing the proper trust anchor • Cross-certificate policy mappings • Certification & Accreditation requirements

4. Benefits of Certificate Bridges • Allows the relying party to enjoy the efforts and benefits of a larger trust domain while not being required to be an integral part of that domain’s certificate hierarchy… • …while trusting one trust anchor—a public key within your own trust domain • An issued cross-certificate is a tangible representation of trust (and a declaration you accept their CP/CPS) • A trust path (including cross-certificates spanning the issuer’s and relying party’s domains), in part, forms a tangible record of trust storable for: • Future evidence of due diligence • Meeting institutional archival requirements • Satisfying NARA requirements?

5. Bridge Certificate Authorities (BCAs) Establish Border Directories • Border directories: • For publishing CA certificates, cross-certificates, and CRLs [OCSP coming soon] • (For publishing encryption certificates, but typically not signing certificates), and… • For facilitating trust path discovery and validation, by providing: • Chaining to, or referrals to, directories of all other CAs to which cross-certificates have been issued • A one-stop-shop virtual directory for use by local population for retrieving all relevant certificates and CRLs else might not know where to look • DN formatted CRLs? No AIA or SKI fields?

6. Certificate Directory Interoperability: The (Fictitious) Players • A government (Certification) bridge authority (GBA) • A government institution (GI) • A neighboring nation bridge authority (NNBA) • A university bridge authority (UBA) • An older, legacy PKI system at Enormous State Univ (ESU1) • A newer PKI system at the same university (ESU2) • A world-wide council (WWC) • A random transoceanic nation (RTN)

7. NNBA WWC GBA RTN UBA ESU1 ESU2 GI Certificate Directory Interoperability Legend: Purposeful trust path vs. possibly unintended trust path?

8. GBA c=US o=Upr Govt o=edu Directory Configurations Required for Trust Path Discovery/Validation NNBA c=NN cref(dc=int) cref(c=NN) cref(c=RTN) cref(dc=edu) subref(ESU Prov) subref(ou=GI) subref(ou=UBA) GI UBA o=edu, c=US dc=edu cref(o=ESU Prov, c=US) ou=GI, o=Upr Govt, c=US ou=UBA subref(ou=ESU Prov, c=us, dc=esu) ESU o=ESU Prov, c=US ou=ESU Prov, c=us, dc=esu, dc=edu

9. Directory Configuration for Interoperability: Lessons Learned • Each border directory needs to support superior references, subordinate references, cross references; configuration is complicated • MS AD does not support all necessary knowledge references • A BCA directory must be able to resolve (directly or indirectly) any base DN that could ever form a trust path through that BCA • e.g., GBA must be able to retrieve ESU dir entries • A “root” directory must include a knowledge reference for any “root base DN” that could ever form a trust path through it, even though that root directory did not directly cross certify with it • e.g., GBA must include a knowledge reference for c=RTN

10. Design Alternatives? • BCA directory returns referrals to only those directory with which it is directly cross-certified • But many LDAP clients still cannot process referrals • Trust paths traversing multiple bridges not discoverable if only DN-formatted certificate fields • All certificates must have properly formatted AIA fields • One missing or improperly formatted AIA field destroys ability to discover trust path • Dependency on SKI fields constrains path discovery from issuer to relying party • Use DC naming & have special DNS type/entry pointing to enterprise’s border directory

11. Transitive Trust • Cross-certification breeds phenomenon of transitive trust • Such indirect trust may or may not be intended or welcome • Example 1: GI ↔ GBA ↔ NNBA ↔ WWC ↔ RTN • Example 2: Country of Forbiddenstan (c=FB) cross-certifies with WWC…creating (unlawful) trust path back to GI • GI directors prefer there be no valid certificate trust path between GI and Forbiddenstan • Other agencies (humanitarian-oriented) have legitimate needs to trust Forbiddenstan-signed documents • Nation-wide filter might not be appropriate

12. Transitive Trust Scenario:Policy or Design Alternatives? • If rely only on chaining, somebody has to reissue cross-certificates with name constraints or path length constraints • GI re-issues cross-cert to GBA with name constraints • Probably become aware of need only after offense • Cross-certificate re-issuance has costs • Other relying parties need to be aware of this political situation and issue appropriate name constraints • Difficult to envision all necessary path constraint needs (path permitting or path inhibiting) before issuance • Revocation of original cross-certs affects pre-cache systems • GBA re-issues cross-cert with path length constraint and “special need” agencies cross-certify directly WWC • Might squelch longer, acceptable domestic-based trust paths?

13. Choosing the Proper Trust Anchor and Filtering Certificate Policies • Scenario: validation service provider in a multiple cross-certificate environment…which trust anchor? • (Typically chose trust anchor within your own certificate issuance domain) • Acceptable certificate policies: expressed in trust anchor’s policy OID space • Policy mappings in cross-certificates “translate” levels of assurances (LOAs) • Complicating factors: • Asymmetrical policy mappings • Possibility of multiple trust paths • Unidirectional cross-certifications

14. Algonk GBA Choosing the Proper Trust Anchor… (Cont.) Policy mappings: (issuerDomain~subjectDomain) Medium~B C~Medium LOAs: Large Medium Small LOAs…from one CA!!!: Level D Level C Level B Level A

15. Choosing the Proper Trust Anchor: Alternatives? • Is asymmetrical policy mapping necessarily undesirable? • Might be useful in certain environments • If undesirable, both parties should explicitly state and agree upon how each of the applicant’s LOAs relates to the issuing party’s LOAs • Should explicitly state the validation service’s acceptable certificate policy set—and not include the phrase “or equivalent”—and use only the corresponding trust anchor

16. CR GBA CV A1* A1 Post-Issuance CA Subordination • Adv: CR need to ship only one cert in web browser • CR subordinates A1 to demonstrate approval/membership • EEC must have (or be re-issued to include) new CR policy OID –or– new CR asserts policy OIDS of all subordinated CAs; careful policy mappings • Two possible trust paths • Revocation of A1 requires manual notification of CR PMO

17. Operations Policies • Popular misconception: when a BCA is cross-certified with the root CA of a certificate issuer hierarchy, the BCA PMO is required to see only the C&A report corresponding to the remote organization’s root CA, and that organization can be trusted to silently perform C&As on their internal hierarchy • True only for low assurance systems [800-37, 3/2005] • Reality: certification agent needs to be independent of developers, sys admins, anyone responsible for correcting security deficiencies found • Resulting report must be delivered externally (e.g. the BCA PMO) • Impact: the PMO of each BCA should regularly see the C&A of every issuing CA to which the BCA can form a trust chain