Bridge  Bridge Interoperability: Technical Consideration Santosh Chokhani (chokhani@orionsec)

1. Bridge  Bridge Interoperability: Technical ConsiderationSantosh Chokhani (chokhani@orionsec.com)

2. Outline of Presentation • Performing Cross Certification Securely • Bilateral • Bridge • Bridge  Bridge • Path Discovery and Path Validation Challenges • OCSP Considerations • SCVP Considerations • Practical Considerations • Impact on Certificate Policies • Summary

3. Scope of this presentation limited to technical topics e.g., policy equivalency mapping not addressed Use nameConstraints extension to ensure that the relying parties in your domain only trust certificates issued to the names appropriate for the cross certified domain Set inhibitPolicyMapping, skipCerts = 0 so that you do not trust other domains cross certified by the “cross-certified domain” If you want to trust those other domains, you will cross certify with them. In other words, trust is bilateral, like other business relationships. Applies to Enterprise, Bridge and BB Environments also Need a strategy for policy assertion. Examples: PKI asserts all lower policies also Cross certificate maps a low policy to all higher policies also Applications include all higher policies in acceptable policy set Cross Certification: Bilateral

4. Bridge uses permittedSubtrees field in nameConstraints extension to allocate name spaces to PCA domains appropriately PCA sets inhibitPolicyMapping, skipCerts = 1 so that Bridge can map to other domains, but other domains can not What if Bridge  Bridge link is taken? What if the old idea of Bridge membrane becomes reality? Bridge sets inhibitPolicyMapping, skipCerts = 0 in PCA certificates Cross Certification: Bridge

5. PCA PCA PCA PKI Trust Model: Bridge PCA PCA Bridge CA PCA

6. Bridges may not be able to use nameConstraints extension to allocate name spaces to other Bridges Too many disjoint name spaces Bridges can ensure bilateral Bridge  Bridge interoperability by: Using excludedSubtrees that asserts names of all other Bridges in a Bridge certificate By asserting inhibitPolicyMapping, skipCerts = 1 in Bridge certificates PCA sets inhibitPolicyMapping, skipCerts = 2 so that Bridge can map to other Bridges May not be as useful since Bridges can be trusted to do this correctly Bridge sets inhibitPolicyMapping, skipCerts = 0 in PCA certificates Bridge sets inhibitPolicyMapping, skipCerts = 1 in Bridge certificates Cross Certification: Bridge  Bridge

7. PCA PCA EBCA FBCA SBCA PCA PKI Trust Model: Bridge  Bridge PCA PCA PCA CBCA

8. Inhibit Policy Mapping Examples skipCerts = 0 PCA m PCA n skipCerts = 1 Bridge CA PCA n PCA m Bridge CA 2 Bridge CA 1 PCA n PCA m skipCerts = 2 Rely on the Bridges to set skipCerts = 0 on outgoing arcs to the PCAs

9. See the Internet Informational RFC 4158 Using DNS redirect, publish the following in your domain “Bridge CA certificates issued by you only” in the Bridge p7c file and/or in the Bridge CA directory entry Bridge CA Certificate depending on which Bridge you are cross certified with (in p7c and/or in the Bridge CA directory entry) If your domain is cross certified by a Bridge, only publish certificate issued by you and no other Bridges or PCAs Else, only publish the certificate issued by the Bridge you are cross certified with In other words For I = 1 to n, BridgeI p7c/cACertificate = Your PCA  BridgeI or BridgeI p7c/cACertificate = BridgeX such that BridgeX  Your PCA is not null These measures will help select the path to your PCA only and that is what you want Certification Path Discovery Challenges

10. No more than other environments Same rules apply More on commercial product limitations under “Practical Considerations” Certification Path Validation Challenges

11. Local policy model (e.g., trust anchor) approach does not scale well for Bridge environment Need to use Delegated or CA model Or use CRL and not OCSP SAFE requires OCSP OCSP Considerations

12. No more than other environments SCVP Server must be able to build and verify paths for various trust models SCVP Considerations

13. Limitations of commercial products in terms of certification path development Some require the use of AIA caIssuers field Some Browsers unduly build paths to roots sent by a Server Implies you can not build paths and hence authenticate yourself across a Bridge Limitations of commercial products in terms of certification path validation Some of the most commonly used products do not pass many of the PKITS tests, specially in the area of name constraints and policy processing Need to push the vendors to comply with RFC 3280 and pass PKITS or PD-VAL tests CAPI behavior if two or more trust anchors from Bridge environment are in the trust store MSFT aware and very responsive Practical Considerations

14. Shared Service providers list of enumerable name spaces for assertion in nameConstraints extension may be too long Alternative One: Use name subordination using Shared Service Provider CA name Alternative Two: Do all of the following PCA issues CA certificates with pathLengthConstraint = 0 CA names are tracked or assigned using some method for the benefit of all Bridges to procedurally ensure that CA names do not collide Use CA software controls to define name spaces for which the CA issues certificates CA ensures that names assigned to an organization are appropriate for the organization Practical Considerations

15. Bridge CP should address PCA Domain (also known as Entity) PKI requirements This is addressed unevenly by the current Bridge CPs Address the shared service provider CA name space and path length requirements Impact on Certificate Policy

16. Rely on the Bridge to assert inhibitPolicyMapping, skipCerts =0 for PCA certificates Rely on nameConstraints whenever possible Assert names of other Bridges in excludedSubtrees field of Bridge  Bridge certificate Press PK enablement toolkits and product vendors to comply with RFC 3280 and PD-VAL Beef up Bridge CP requirements to address Entity PKI requirements Name uniqueness is important Have a strategy for PCA name space coordination Have a strategy for shared service provider CA name space coordination if name constraints are not imposed on shared service provider CAs Have a stretagy for policy assertions Have a strategy for OCSP interoperability DNS redirect for AIA or LDAP entries helps immensely with computational complexity of certification path discovery Summary

17. Questions