Jun 2, 2015 3:42:58 PM
PKI Design Considerations for a Non-Contiguous Subscriber Namespace

In this blog, we'll explore taking business enablement to the next level by integrating two security technologies, PKI and Identity Federation.

Business Model: Global partnership with independent territory local firms.

Requirement: Leverage IT to provide a secure business environment for supporting resources, collaboration and sharing.

Goal: Identify and establish a unique distinguished namespace for each individual territory local firm while establishing identity trust relationships among those disjoined namespaces to share resources across territory and security boundaries.

Solution: Public Key Infrastructure (PKI) with federated identity aware.

Recommended PKI view:

Certificate Management System (CMS)

Seamless certificate issuance and management across devices and service 

http://www.css-security.com/cms

Managed PKI

Powerful digital and secure solution for less cost than you ever thought possible. 

http://www.css-security.com/managedpki

Recommended Identity Federation infrastructure view:

Approach for solution architecture, design, and implementation is outlined below:

  • Build global trusted root CA with multi-tiered certification authority hierarchy to support global-scope PKI infrastructure while implementing subordination namespace constraints to restrict territory subordinate CA's certificate issuance within its own local-scope PKI administration and management.
  • Facilitate end-to-end namespace linking mechanism between territory, global and cloud to enable core identity information provisioning/synchronization into linked namespaces at each identity store.
  • Bind certificate to unique identity ID associated with namespace, and enable certificate mapping back to identity.
  • Implement certificate issuance policies (such as high assurance level …) and application/key usage policies (such as non-repudiation, smart card login …) into certificate content, the relying party can leverage it for authentication/authorization/access control purpose without reinventing the wheel. 
  • Equally important, STS (Security Token Service) can translate those policy settings from certificate to claims into a security token, deliver to the relying party which can also do the same for access control purposes. You would see certificate policies enforcement settings being carried out end-to-end in its entire life.
  • Apply key usage to its purpose only. For instance, non-repudiation is very a specific key usage which should not be overloaded. It at least implies the private key is never exported from a secure place, such as a smart card, TPM/virtual smart card, HSM, etc.
  • Due to the nature of dis-joined namespace among global and territories, most windows clients appear to non-domain joined devices when accessing global or foreign resources. Windows 2012 R2, Windows 8.1, and above supports non-domain joined certificate enrollment and key-based renewal via CES/CEP.

keycomp-1