Bridge bridge interoperability technical consideration santosh chokhani chokhani@orionsec com l.jpg
Advertisement
This presentation is the property of its rightful owner.
1 / 17

Bridge  Bridge Interoperability: Technical Consideration Santosh Chokhani ([email protected]) PowerPoint PPT Presentation

Bridge  Bridge Interoperability: Technical Consideration Santosh Chokhani ([email protected]) Outline of Presentation Performing Cross Certification Securely Bilateral Bridge Bridge  Bridge Path Discovery and Path Validation Challenges OCSP Considerations

Related searches for Bridge  Bridge Interoperability: Technical Consideration Santosh Chokhani ([email protected])

Download Presentation

Bridge  Bridge Interoperability: Technical Consideration Santosh Chokhani ([email protected])

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Bridge bridge interoperability technical consideration santosh chokhani chokhani@orionsec com l.jpg

Bridge  Bridge Interoperability: Technical ConsiderationSantosh Chokhani ([email protected])


Slide2 l.jpg

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


Cross certification bilateral l.jpg

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


Cross certification bridge l.jpg

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


Pki trust model bridge l.jpg

PCA

PCA

PCA

PKI Trust Model: Bridge

PCA

PCA

Bridge CA

PCA


Cross certification bridge bridge l.jpg

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


Pki trust model bridge bridge l.jpg

PCA

PCA

EBCA

FBCA

SBCA

PCA

PKI Trust Model: Bridge  Bridge

PCA

PCA

PCA

CBCA


Inhibit policy mapping examples l.jpg

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


Certification path discovery challenges l.jpg

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


Certification path validation challenges l.jpg

No more than other environments

Same rules apply

More on commercial product limitations under “Practical Considerations”

Certification Path Validation Challenges


Ocsp considerations l.jpg

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


Scvp considerations l.jpg

No more than other environments

SCVP Server must be able to build and verify paths for various trust models

SCVP Considerations


Practical considerations l.jpg

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


Practical considerations14 l.jpg

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


Impact on certificate policy l.jpg

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


Summary l.jpg

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


Questions l.jpg

Questions


  • Login