Dynamic Bridge Concept

1. Dynamic Bridge Concept Ken Stillson Mitretek Systems For presentation to the 3rd Annual PKI R&D Workshop

2. Problem Background • Path discovery scaling problem • During work on path processing for the Federal Bridge CA, indications arose that even in the simplified mesh structure of a bridge, discovery can be very expensive • Time needed for a discovery of a new path increases much faster than linearly with the complexity of the mesh • Big problem when we reach big meshes (e.g. tying bridges together)

3. Path Discovery –The Sense of Direction Problem • A “wrong-turn,” for example entering cloud X or Y, can lead to a wild goose chase during path discovery • Path discovery has no “sense of direction,” no routing protocol, to determine a good route between sender and trust anchor. CA1 CA2 CA3 sender Trust anchor X Y

4. Solution Background • Some solutions noted to date • Pre-caching of objects (a “certificate spider”) • Removes network retrieval time and iterative discovery sequence; objects immediately available. “Some assembly required.” • Pre-caching of partial paths • Attempt to cache common path segments; complicated by non-local constraints(must be cached discovery only, not validation)

5. Dynamic Bridge Concept • Pre-cache all possible paths from trust anchor to issuers (a “trust spider”), store “path minus 1” cached paths as direct cross-certificates from a new CA • The new cross certificates reflect the same trust arrangements as the initial mesh, but they have been “flattened” to combine intermediate hops CA1 CA2 Z Y X Trust anchor A sender Infrastructure creates Dyn(Trust anchor A) automatically YX X Dynamic bridge for Trust anchor A Dyn (Trust anchor A) Automatically issues these cross-certificates

6. Dynamic Bridge Concept • Dynamic bridge automatically creates Dyn(A) using a trust spider • User of trust anchor A change their trust anchor to Dyn(A) • All paths to A now available from Dyn(A) with path length 1 • Walking a typical discovery algorithm: • Sender -> CA1 is easy; issuer in sender’s cert, and often cert is included with message • Next step is to search for other certs with CA’1 subject (searching for cross-certs issued to CA1). This immediately returns Dyn(A), which is known as the trust anchor, so discovery stops before starting. • No need to choose between alternative paths, so no direction needed CA1 CA2 Trust anchor A sender Dynamic bridge for Trust anchor A

7. The Constraints Complication • Consolidation needs to include intermediate constraints • In A -> CA2 -> CA1, the new constraint “YX” is the ordered combination of constraints Y and X. • E.g. if Y requires policy1, and X requires policy2, then YX would require both polices in a single constraint. If Y maps policy1 to policy2, and X maps policy2 to policy3, then YX map policy1 directly to policy3. • It is asserted that all the constraints possible in cross certificates can be combined by a fully implemented  • “Last mile” validation still required for constraint Z CA1 CA2 Z Y X Trust anchor A sender X YX Dynamic bridge for Trust anchor A

8. The Revocation Complication • The dynamic bridge path has “short circuited” CA2 • CA2 should be able to revoke it’s cross-cert to CA1, but dynamic bridge path does not pass through CA2, so removes revocation capability • Solution: Set expiration date for the dynamic bridge’s certificate from Dyn(A) to CA1 to the earliest CRL “next update” for any CAs “flattened” from the path. • A dynamic bridge cross certificate is valid only until the time a CRL update could have invalidated part of the consolidated path • The dynamic bridge continuously re-generates as things expire. It re-performs validation, thus giving the opportunity to revoke. • Yes, the dynamic bridge will be “busy” in a complex mesh, but better a single bridge server per trust anchor than every desktop CA1 CA2 Z Y X Trust anchor A sender X YX Dynamic bridge for Trust anchor A

9. Proposed Benefits • Path discovery- iterative discovery is removed. No wrong turns, as no turns • Path validation- end-user validation is become simpler: path lengths are reduced and cumulative effects of the chained constraints are pre-calculated. • Object location- the dyn-br has collected all objects a relying party will require. If dyn-br’s cross-certs are all stored in a single directory, relying party need only point there. Dyn-br might also populate AIA fields in its cross-certs, to facilitate object location • Construction requires no particular privilege, nor the cooperation of the mesh participants. • Any enterprise, even end-users, can establish their own • Those that utilize the dynamic bridge’s trust anchor will receive the benefits, the existence of the dynamic bridge is non-harmful to those that do not utilize it. • Utilization of a dyn-br does not require any specialized software • In-fact, only a subset of the standard path processing capabilities are needed; some PKI software that is not fully compliant now (due to lack of iterative path discovery, or limited object location capabilities) would be made fully capable

10. Unresolved Issues • Presumably the dynamic bridge must use “on-line” keys • Common one-way push through firewall probably mitigates • The concept hinges on the  function, which is not yet implemented. • Is the X.509 constraint language sufficiently expressive to be associative? • Microsoft Window’s “CAPI” still has an object location challenge • No support for a “default directory” or an “AIA of last resort,” which could point to the dynamic bridge’s directory. • CAPI builds from the sender towards the trust anchor, so addition of AIA fields to dynamic bridge certificates does not help • The spider crawl must start at the known trust anchor(s), and spread outwards. This direction is “the hard way” for object location • AIA is the “wrong direction.” SIA fields can be used for this, but are not widely populated. Bi-directional trust resolves this problem (pass 1 finds the “wrong-way” cert, then pass 2 knows the DN for the right-way). But uni-directional trust chops the search tree.

11. Conclusion • Mitretek Systems is presenting the dynamic bridge concept to the PKI community without intent to assert patent protection, in hopes that its utility may be assessed, and discussions started concerning the possibility of implementation. • Those interested in providing feedback, or joining discussions on the topic, are asked to contact the paper’s author, Ken Stillson, at stillson@mitretek.org.If there is sufficient interest, a mailing list or similar discussion mechanism will be established.